这周 HN 上挂着篇《Agent 文明的兴衰》，配着这周几十篇 multi-agent 论文一起看，我反而越来越怀疑一件事：多数被拆成多 Agent 的系统，拆的是 prompt，不是职责。真正需要多 Agent 的信号，按我现在看只有两个——上下文互相污染，和权限边界必须分开。剩下的大多数场景，单 Agent 加工具调用就能跑，还跑得更稳。
大家其实在给同一个 Agent 写更多 prompt
这周有篇热帖叫 My agent.md to improve LLM-assisted code quality，讲的是怎么用一份精心维护的 agent.md 让模型在代码库里的行为更可控。同类的还有 Serve Markdown to AI Agents with Accept Headers，说白了就是给 Agent 专门准备一种友好的内容格式。还有那篇 Domain-Driven Agents，把 DDD 那套搬进 Agent 设计——先划清领域边界，再谈 Agent 职责。
这几篇放一起看很有意思：都在说同一件事，怎么让模型在特定场景下更精确、更少瞎猜。但它们全部是围绕单个 Agent 做的。没有编排层，没有消息总线，没有任务分发。我见过不少自称 multi-agent 的项目，打开代码一看，就是同一个模型被用不同的 system prompt 调了几次，外面包了一层 router。这叫多职责配置，不叫多 Agent 编排。你能说一个 Controller 带着三个 Worker 跑就是系统架构了吗——看着像，其实你只是给一个员工写了三份不同的岗位说明书。
两个信号，占一个才考虑拆
Agentic Context Management 这篇论文把问题说得很明白：上下文管理不是调优问题，是架构问题。记忆越堆越多，成本非线性往上涨，最后不是模型不够聪明，是它装不下自己的历史。这种时候拆分才有意义——每个 Agent 只看自己那一段上下文，别的东西不往它脑子里塞。这叫上下文隔离。
另一个信号是权限边界。你有三个 Agent：一个读代码库，一个写代码库，一个跑部署。你不想让读代码的那个拿到部署密钥，也不想让跑部署的看到源码里的密钥。拆开，因为它们的身份本来就不一样。这跟多 Agent 没关系，这是安全边界的需求。
除此之外的理由，什么"一个负责思考一个负责行动"——模型自己已经内置了思考和行动循环，你人工切成两块，除了增加一次进程间通信，没有任何信息论上的增益。
调试成本是指数级长的
反面意见我完全同意，而且想说得更难听一点：多 Agent 的调试成本是指数级的，因为一个环节漂移，会被下游放大。单 Agent 出错，错在最后一个 token。多 Agent 出错，你分不清是上游理解出了问题、中间路由传错了话、还是下游执行的时候跑偏了。三个 Agent 以上，任何一个环节概率不超过 95%，整体成功率就已经跌到 85% 附近，而你还不知道是哪一环掉的链子。
《The Rise and Fall of Agent Civilizations》 那篇长文聊得挺漂亮，但"文明的兴衰"这个比喻本身就在提醒你：文明内部是有秩序的，跨文明的交互出了岔子，你没法在一个进程里打日志把它查清楚。事实上大多数 Agent 系统的结局不是崩溃，是没人敢信它的输出。于是大家又开始往上叠验证层、审计日志、人审环节——成本从模型调用变成了整个系统工程。
这周 ArXiv 上那篇多 Agent 数学发现我也看了，领域很酷，但我怀疑它的多 Agent 是堆出来的。数学发现本质上是一个搜索问题——你需要的不是一群专家互相讨论，而是一个能记录哪些路走不通、哪些引理已证、然后持续往深处钻的系统。这个用单 Agent 加外部记忆工具也能做，还省掉了 Agent 之间传递定理证明时的理解损耗。
反例：什么时候单 Agent 加工具就够
举一个具体的：给代码库写 Review 意见。输入是一个 PR，输出是几条改进建议。你需要读 diff、查相关函数、偶尔翻一下 issue 记录——这就是三次工具调用，同一个 Agent 完全可以做。它的上下文清晰，反馈闭环短，不需要跨系统的长期状态。就这场景，你拆成"读代码 Agent"和"写建议 Agent"，多出来的全是通信成本和语义损耗，没有任何收益。
再放宽一点：内部客服问答、周报生成、合同要点提取。这类任务的共性是，输入结构相对固定、输出直接对应输入、没有多个系统之间的状态同步。这种场景拆多 Agent，就像去楼下便利店开个临时讨论会——三个人的组织成本，只干了半个钟头的活。
我的判断是，多 Agent 编排是建筑风格，不是建筑材料。它解决的问题是组织问题，解决不了模型本身的能力问题。先把单 Agent 调明白，把它的 prompt、工具、上下文管好，再问自己一遍：要拆，是因为职责真的不同，还是因为代码里看起来更"架构"？