# 一个什么都干的 agent，什么都干不好 当一个 agent 不够好用时，本能反应是给它加东西——再加一个工具、更多指令、更多上下文。可这只会让它更糟，而且这是被量化出来的，不是品味问题。解药是工程里最古老的那条规则：单一职责。一个 agent，一份职责，少数几个工具，简短的上下文。一个上帝智能体就是一万行的函数披了件风衣——它失败的原因一模一样。 - **Author:** Fedor Chishchin - **Published:** 2026-06-03 - **Tags:** agents, architecture, methodology - **Source:** https://fedorthinks.com/zh/blog/one-agent-that-does-everything --- 你的 agent 还差点意思，于是你做了那件最显而易见的事：给它加东西。为它办不到的事再加一个工具。在 prompt 里多写几行，覆盖它弄错的那种情况。塞进更多上下文，好让它手头有一切可能用得上的东西。每一次添加都合情合理。每一次添加都让这个 agent 变差了一点。 这个反直觉的结论我花了好一阵子才相信，而它不是品味问题——它是被量化出来的。通往一个能干的 agent 的路，方向恰恰与本能相反：不是更多，而是更少。 ## 更多让它更糟，这里有证明 一个语言模型的注意力预算是固定的。你放进它上下文窗口里的一切——每一段工具描述、每一条指令、每一份检索到的文档——都在争抢同一份预算。过了某个临界点，添加信息并不能给模型更多可用的东西；它只是稀释了原本就在那儿的东西。 相关研究说得很直白。长上下文模型饱受一种有充分记录的[**"lost in the middle"**（迷失在中间）效应](https://medium.com/@999daza/why-your-ai-agents-fail-the-context-overload-problem-and-the-slice-framework-that-fixes-it-873653ce0db6)之苦：埋在长 prompt 中段的指令，比同样的指令放在短 prompt 里更不容易被遵守。一项分析发现，准确率[纯粹因为上下文超载就从 **92% 跌到 63%**](https://medium.com/@999daza/why-your-ai-agents-fail-the-context-overload-problem-and-the-slice-framework-that-fixes-it-873653ce0db6)——同一个模型、同一个任务，只是窗口里塞得太多。工具也是一样的脾气：把二十个工具堆到一个 agent 身上，它就开始[有一半时间调错那一个](https://dev.to/nebulagg/the-god-agent-mistake-why-one-mega-agent-always-fails-in-production-1fk1)，等它深入到任务里时，已经忘了上下文顶端那条指令，并且把一次糟糕的调用变成接连三次更糟的调用。 这就是 **god agent（上帝智能体）**模式，它有一个标志性特征：在演示里光彩夺目，在生产环境里分崩离析。在演示里你跑的是你排练过的那唯一一条路径。在生产里，那些漫长、分叉、真实的工作流每一次都撞上稀释之墙。 ## 解药已经四十岁了 解药不是某个巧妙的 prompt，也不是更大的模型。它是[**单一职责原则（Single Responsibility Principle）**](https://www.alation.com/blog/general-vs-specialized-enterprise-ai-agents/)，就是我们早已用在函数和类上的那条规则：**一个 agent，一份职责。**给每个 agent 一项单一、定义清晰的职责，给它那份工作真正需要的三四个工具，只给它与之相关的上下文。现在没有任何东西在争抢注意力预算，因为窗口里没有任何多余的东西。每个 agent 在它那一件事上出类拔萃，恰恰是因为它没有试图把另外九件事也干好。 数字朝这个方向猛烈地移动。Chroma 的评测发现，一个[聚焦的约 300-token 的 prompt 和一个臃肿的约 113K-token 的 prompt](https://medium.com/@stawils/more-agents-more-tools-worse-results-the-2026-evidence-for-radical-simplification-7bad6c1858a5)之间存在巨大的准确率差距；那种把单一用途硬撑成万事通的通用 agent，被测出来只有约 58% 的成功率，而且随着任务铺得越开还会继续下跌。把范围收窄，同一个底层模型就变得可靠得多，因为你不再逼它去做选择。 ## 这一课我们早就学过了，在写代码的时候 接下来这部分应该让每一个工程师点头。我们不会写一个一万行、带两百个分支的函数然后管它叫强大——我们管它叫不可维护，然后把它拆成各自只做一件事的小函数。我们不会造一个什么都干的类；我们会去分解。一个 god agent 不过就是那个反模式只是披了件风衣：一个单一组件被要求同时扛起所有关切，失败的原因和那个巨型函数一模一样——一处塞了太多东西，没有分离，每个部分都在干扰其他每个部分。 所以该走的这一步，是我们早就知道的那一步。分解不是什么新的"agent 技巧"。它就是那个催生了[单一职责、小单元和清晰边界](/blog/cheap-code-is-expensive)的同一种本能，被应用到了一种新的组件上。它之所以管用，理由很具体，而非审美层面的：一个聚焦的 agent 有着未被稀释的上下文，所以它能守住任务——就像一个聚焦的函数是你真正读得懂的那种。 而且它的副作用恰恰是你想要的那些。一个一份职责的 agent 是可测试的——你可以为"它有没有把那一件事做好"写一个 [eval](/blog/evals-or-it-didnt-ship)，而这对一个二十工具的万事通 agent 你根本做不到。它更便宜，因为一份范围窄、定义清晰的工作往往[在更小的模型上就能跑得很好](/blog/cheap-model-most-of-the-work)。它也更易于调试，因为当某处出问题时，你知道是哪个 agent 拥有那份职责。 ## 老实交代的代价 把一个 agent 拆成十个，并不会让问题凭空消失——它把问题换成了另一个。现在你有十个聚焦的 agent 需要被协调：得有什么东西去路由工作、在它们之间传递结果、并决定什么时候跑什么。那个协调层——编排——是实打实的工程，它配得上单独一篇文章。 但请留意你做的是哪种交换。你把*"我的 agent 忘了自己的指令、调了错的工具"*——一种发生在你修不了的黑盒内部的失败——换成了*"我需要协调一些组件"*——一个有着寻常工程答案的寻常工程问题。这两者里有一个是可解的。另一个只是 god agent 在你加得越多时变得越糟。 让一个 agent 包揽一切的冲动，就是想跳过分解的冲动，而它在 agent 身上失败的原因，和它在代码上一直以来失败的原因一模一样。把每个 agent 做得足够小，好让它出类拔萃。一件事做好，胜过十件事各做到 58%。