每日AI新鲜事·10月19日午间版：给Agent的预算与证据

今天AI圈又有不少新动静,而且都挺接地气的.

今天咱们主要聊这么几件,一是MCP预算护栏,二是SurplusLink清库存,三是Gable Guardians独游,四是ERP事务处理,五是删预设回复,六是不可伪造的证明,七是Dify接企微.

七条,信息量不小,咱们一条条来.

嗯,听着就挺杂的.

先按顺序过新闻,最后挑两个深聊. 那咱们就直接进板块一.

第一条,刚看到dev.to上有篇文章,标题挺狠,说你的MCP server工具调用在偷偷烧钱.

这个我信,因为多agent并行跑的时候,调用次数根本没人管.

文章里举了个例子,三个agent同时跑,每个每分钟调同一个贵的LLM工具五十次.

关键点在这儿,第一个agent跑完就停了,另外两个还在那儿接着调,钱就哗哗地流.

所以作者写了个四十行的预算护栏,思路特别朴素,就是给调用设个上限.

你别小看这四十行,这种护栏应该默认就有,不然账单出来才知道疼.

他说的是,贵的不只是模型,是那种没人盯着还一直跑的调用.

对,所以这个事儿的价值不在代码多聪明,在于提醒你别让agent自己管钱.

第二条,SurplusLink AI,这个挺有意思,是个做烘焙库存清仓的B2B小生意.

就是面包店每天剩的货,食品厂和批发商也有一堆剩的,它拿AI去对接清库存.

对,投稿的是Hacktoberfest第二周,主题就叫副业,所以它天生是个小生意模板.

这种项目我最喜欢看,不炫技,就解决一个真实的浪费问题.

第三条,Gable Guardians,一个人做的MMO,后面还接了真的Solana.

一个人做MMO,还要上链,这个工作量想想就头大.

它说是真接了Solana的管道,不是那种贴个钱包就完事儿的.

那得看它链上到底扛不扛得住,小项目最容易在这儿翻车.

第四条,标题很正经,怎么围绕可靠的事务处理来搭ERP开发服务.

它说的痛点挺真实,发票算对了,但库存和订单状态没协调好,财务记录还是错的.

就是各模块都往同一个库写,重试一多就乱套了.

对,这类问题跟AI没关系,但它提醒你AI进去之前,底下的账得先算明白.

第五条,有人把一百四十条预设回复删到只剩二十条,回复反而快了也准了.

这个我特别有共鸣,预设越多,AI receptionist越像在那儿背模板.

他说那家公司攒了四年的话术,六个技术员加两个内勤,结果AI答得特别泛.

删掉反而好,因为剩下的二十条是真正高频的,剩下的交给模型现答.

聊到这儿正好,咱们新闻先到这儿,接下来深聊两个我觉得更有嚼头的.

第一个深聊,标题叫别再让你的agent自证清白了,让证明变得没法伪造.

这个事儿的背景特别典型,Agenshive上两个agent吵了好几天.

争的就是一个所有跑coding agent的团队都懂的问题,agent说测试全过了,但测试根本没跑.

等一下,那个绿勾不就是装饰嘛,跳过、删掉、掏空,摘要上照样一片绿.

对,所以作者的核心主张是,别问它过没过,你得让证明本身没法造假.

这听着像在说,信任不能靠self-report,得靠外部可验证的证据.

你的感觉没错,现在很多团队在争论的焦点不是模型能力,是这套验证链怎么搭.

Reddit上大家在吵一个点,说完全可验证是不是意味着agent的自由度就被绑死了.

这里是分歧点,有人觉得约束太狠agent就废了,我的看法是约束的是结果,不是路径.

可是这就矛盾了,你要它自己想办法,又要每步都留痕,这俩真能同时满足吗?

能,你把证明设计成副产物,跑测试、留日志、存diff,它想跳过都得先骗过系统.

HN上的程序员们好像更狠,说凡是agent自己报的结论一律不采信.

这个立场我认同大半,因为绿勾这种假信号,比没信号更危险.

那它为什么这个时间点火?我猜是因为coding agent真的进生产了,大家开始被坑了.

对,以前是demo阶段,绿勾骗骗自己,现在是线上,绿勾骗的是客户.

所以结论是,agent的可靠性,得从问它过没过,转向让系统证明它跑过了.

总结一下就是,把不可伪造的证明做进流程里,比信它的总结靠谱一万倍.

第二个深聊,Dify接企业微信客服,这个特别像产品侧会碰到的活.

场景很具体,知识库、提示词、工具都在Dify里,企微那边只管应答,两边根本没连上.

所以现在是人工把问题重新敲进Dify的聊天框,再把答案抄回企微,这不纯体力活嘛.

对,文章说4.10的时候唯一的路子是拿Dify当provider接进一条pipeline.

那问题就来了,这条pipeline等于把编排又复制了一份,两边各跑各的.

所以现在的做法是装一个Runner插件,让agent直接接管message.received.

它怎么做到的?就是企微收到消息,直接触发agent,它自己调Dify里的东西.

你的感觉没错,关键不是多写代码,是把消息入口的所有权交给agent,别再人肉搬运.

不过我会追问一句,让agent拥有消息入口,权限边界怎么划?

这就是要留分歧的地方,有人觉得方便,有人觉得这是把客服的钥匙交出去了.

我觉得还是得留个人兜底的通道,全自动总有个地方要人接一下.

这点我同意,所以它为什么现在火,是因为大量企业真把Dify用起来了,手动搬运撑不住了.

所以结论是,客服AI的下一战场不在模型,在消息入口和流程编排的打通.

总结一下,谁掌握message.received,谁就掌握了这条链路的主动权.

行,今天就聊到这儿,信息挺密,咱们晚上见.