全部笔记
一个什么都干的 agent,什么都干不好

2026年6月3日

一个什么都干的 agent,什么都干不好

当一个 agent 不够好用时,本能反应是给它加东西——再加一个工具、更多指令、更多上下文。可这只会让它更糟,而且这是被量化出来的,不是品味问题。解药是工程里最古老的那条规则:单一职责。一个 agent,一份职责,少数几个工具,简短的上下文。一个上帝智能体就是一万行的函数披了件风衣——它失败的原因一模一样。

你的 agent 还差点意思,于是你做了那件最显而易见的事:给它加东西。为它办不到的事再加一个工具。在 prompt 里多写几行,覆盖它弄错的那种情况。塞进更多上下文,好让它手头有一切可能用得上的东西。每一次添加都合情合理。每一次添加都让这个 agent 变差了一点。

这个反直觉的结论我花了好一阵子才相信,而它不是品味问题——它是被量化出来的。通往一个能干的 agent 的路,方向恰恰与本能相反:不是更多,而是更少。

更多让它更糟,这里有证明

一个语言模型的注意力预算是固定的。你放进它上下文窗口里的一切——每一段工具描述、每一条指令、每一份检索到的文档——都在争抢同一份预算。过了某个临界点,添加信息并不能给模型更多可用的东西;它只是稀释了原本就在那儿的东西。

相关研究说得很直白。长上下文模型饱受一种有充分记录的"lost in the middle"(迷失在中间)效应之苦:埋在长 prompt 中段的指令,比同样的指令放在短 prompt 里更不容易被遵守。一项分析发现,准确率纯粹因为上下文超载就从 92% 跌到 63%——同一个模型、同一个任务,只是窗口里塞得太多。工具也是一样的脾气:把二十个工具堆到一个 agent 身上,它就开始有一半时间调错那一个,等它深入到任务里时,已经忘了上下文顶端那条指令,并且把一次糟糕的调用变成接连三次更糟的调用。

这就是 **god agent(上帝智能体)**模式,它有一个标志性特征:在演示里光彩夺目,在生产环境里分崩离析。在演示里你跑的是你排练过的那唯一一条路径。在生产里,那些漫长、分叉、真实的工作流每一次都撞上稀释之墙。

解药已经四十岁了

解药不是某个巧妙的 prompt,也不是更大的模型。它是单一职责原则(Single Responsibility Principle),就是我们早已用在函数和类上的那条规则:**一个 agent,一份职责。**给每个 agent 一项单一、定义清晰的职责,给它那份工作真正需要的三四个工具,只给它与之相关的上下文。现在没有任何东西在争抢注意力预算,因为窗口里没有任何多余的东西。每个 agent 在它那一件事上出类拔萃,恰恰是因为它没有试图把另外九件事也干好。

数字朝这个方向猛烈地移动。Chroma 的评测发现,一个聚焦的约 300-token 的 prompt 和一个臃肿的约 113K-token 的 prompt之间存在巨大的准确率差距;那种把单一用途硬撑成万事通的通用 agent,被测出来只有约 58% 的成功率,而且随着任务铺得越开还会继续下跌。把范围收窄,同一个底层模型就变得可靠得多,因为你不再逼它去做选择。

这一课我们早就学过了,在写代码的时候

接下来这部分应该让每一个工程师点头。我们不会写一个一万行、带两百个分支的函数然后管它叫强大——我们管它叫不可维护,然后把它拆成各自只做一件事的小函数。我们不会造一个什么都干的类;我们会去分解。一个 god agent 不过就是那个反模式只是披了件风衣:一个单一组件被要求同时扛起所有关切,失败的原因和那个巨型函数一模一样——一处塞了太多东西,没有分离,每个部分都在干扰其他每个部分。

所以该走的这一步,是我们早就知道的那一步。分解不是什么新的"agent 技巧"。它就是那个催生了单一职责、小单元和清晰边界的同一种本能,被应用到了一种新的组件上。它之所以管用,理由很具体,而非审美层面的:一个聚焦的 agent 有着未被稀释的上下文,所以它能守住任务——就像一个聚焦的函数是你真正读得懂的那种。

而且它的副作用恰恰是你想要的那些。一个一份职责的 agent 是可测试的——你可以为"它有没有把那一件事做好"写一个 eval,而这对一个二十工具的万事通 agent 你根本做不到。它更便宜,因为一份范围窄、定义清晰的工作往往在更小的模型上就能跑得很好。它也更易于调试,因为当某处出问题时,你知道是哪个 agent 拥有那份职责。

老实交代的代价

把一个 agent 拆成十个,并不会让问题凭空消失——它把问题换成了另一个。现在你有十个聚焦的 agent 需要被协调:得有什么东西去路由工作、在它们之间传递结果、并决定什么时候跑什么。那个协调层——编排——是实打实的工程,它配得上单独一篇文章。

但请留意你做的是哪种交换。你把*"我的 agent 忘了自己的指令、调了错的工具"——一种发生在你修不了的黑盒内部的失败——换成了"我需要协调一些组件"*——一个有着寻常工程答案的寻常工程问题。这两者里有一个是可解的。另一个只是 god agent 在你加得越多时变得越糟。

让一个 agent 包揽一切的冲动,就是想跳过分解的冲动,而它在 agent 身上失败的原因,和它在代码上一直以来失败的原因一模一样。把每个 agent 做得足够小,好让它出类拔萃。一件事做好,胜过十件事各做到 58%。

评论

暂无评论

登录以参与讨论。

做第一个分享想法的人。