一个 Agent 项目开始变复杂时，最容易出现的画面很像组织架构图。

规划 Agent 在左边，检索 Agent 在右边，代码 Agent、审查 Agent、浏览器 Agent 排成一排。中间再放一个 orchestrator，负责派活、追进度、收结果。图画出来很完整，Demo 跑起来也很有排面。

然后线上开始慢了。

Anthropic Applied AI 团队最近给出的一个建议很逆耳。他们讨论何时该把 router、planner 和领域子 Agent 收回一条主 Agent 循环。报告里提到，带 Skills 的单 Agent 经常能超过「一个提示词包打天下」和多 Agent 方案。一家客户把系统收回单循环后，运行时间约快了两倍。

这不是反对多 Agent。问题在于，很多团队把「多」误当成了「会协作」。

我更愿意把它当成一条工程上的刹车线。Agent 一旦有工具、有状态、有可复用的 Skills，就已经不是聊天窗口里的单次问答。你给它额外套一层角色和消息传递，得到的不只是并行能力，还会得到上下文切片、状态同步和失败归因的账单。

先别急着招更多 Agent

拿一个常见的企业知识助手举例。用户说，帮我查这个告警是不是和昨天发布有关，找到变更单，再给一份处理建议。

为了显得专业，系统可能拆成四段。Router 判断是运维问题。Planner 列步骤。Retriever 搜日志和变更平台。Analyst 归纳证据。最后 Writer 组织成回复。

听起来没有任何问题。

但把链路摊开看，麻烦才刚开始。Router 的分类错了，后面全是无效成本。Planner 不知道 Retriever 实际拿到了哪些字段，只能写一份理想化计划。Retriever 返回十几页原始日志，Analyst 得先花 token 重建现场。Writer 又不知道哪些判断来自事实，哪些只是上游的推测。

每一次交接都在压缩上下文。

而运维场景偏偏最怕压缩。一个时间戳、一个环境名、一次灰度范围，漏掉任何一个，结论就可能从「相关」变成「碰巧同时发生」。很多所谓 Agent 协作失败，模型能力并没有突然下降，只是信息在交接时被打散了。

这块需要注意一下。子 Agent 不会天然让系统更可靠。它首先会让系统多出边界，边界两侧都需要定义输入、输出、权限、重试策略和验收标准。传统微服务能承受这套成本，是因为服务接口稳定、调用频繁、职责长期固定。Agent 任务往往不是这样，它每天都在变。

所以在 Agent 里直接搬微服务的组织方式，多少有点别扭。

单循环不是一个大 Prompt

有人听到「收回单 Agent」，会理解成把所有指令塞进 system prompt。这是另一个极端，也同样不好维护。

一条好的主循环更像一个值班工程师。它有明确目标，可以自己决定先读哪份文档、什么时候查数据库、工具报错后是否换路、证据不足时要不要追问。它的能力不靠一段越来越长的提示词硬撑，而是靠几层可观察的结构。

第一层是任务状态。不要只把目标写在对话历史里。把任务拆成可更新的 checklist，例如已确认事实、待验证假设、下一步动作和停止条件。Java 或 Spring 的团队可以把它看成显式的 command state，而不是藏在某个 Controller 局部变量里。

第二层是 Skills。Skills 不该只是把提示词换个文件名。一个可用的 Skill 至少要写清楚适用时机、输入约束、工具顺序、失败分支和最终产物。比如「排查发布后错误率上升」这个 Skill，应该告诉 Agent 先对比发布窗口前后的指标，再查 Trace ID，最后才关联变更单。顺序本身就是经验。

第三层是工具边界。主循环能调用工具，不代表它能无差别地拥有所有权限。读日志、查询工单、创建草稿、执行生产变更，应该是不同的能力层级。涉及发消息、付款、删除或部署，仍然需要人在关键节点确认。别因为把架构变简单，就把权限也变粗。

第四层是评估。每一次任务都记录走了哪条 Skill、调了什么工具、哪一步重试、最终证据是什么。没有这层记录，讨论 Agent 是否聪明会变成玄学。

单循环的重点是把决策放回同一个上下文，而不是把全部能力糊成一团。

为什么它常常更快

表面上，多 Agent 是并行，单循环是串行，前者理应更快。现实却常常反过来。

原因不复杂。很多「并行」任务并不独立。

Planner 需要等检索结果才能修正计划。审查 Agent 需要看到代码 Agent 的完整改动和运行日志。写作 Agent 需要知道研究 Agent 排除了哪些证据。它们如果提前并行，只能各自带着不完整的信息猜一遍。之后还要让 orchestrator 归并冲突、补发任务、处理互相矛盾的结论。

你以为省掉了等待，实际是在制造回合。

单循环把「观察、行动、校验、再行动」留在一个连续轨迹中。模型刚读到日志异常，就能立刻决定查哪个服务和哪次发布，不需要把判断翻译成一份任务卡再交出去。对依赖链很强的任务，这种上下文连续性往往比表面并发值钱得多。

这里还有一个经常被忽略的成本。每个子 Agent 都需要重新理解任务。即便共享了摘要，摘要也不是原始上下文。摘要会删掉它认为不重要的东西，而故障定位、代码审查和需求澄清里，最要命的常常就是那个当时看起来不重要的细节。

这也是为什么我不太相信「只要加一个 orchestrator，一切自动涌现」的说法。orchestrator 不是魔法，它只是把调度逻辑从代码搬到了模型输出里。没有约束时，它会变成一位非常勤快、但不停创建会议的人。

那多 Agent 到底什么时候值得

先替多 Agent 说句公道话。有些任务确实该拆。

如果工作可以真正并行，而且每份子任务的输入输出清楚，多 Agent 很合适。比如同时扫描多个独立代码仓库、为一批互不依赖的文档做抽取、让不同的浏览器会话覆盖多个站点。它们共享的只是一开始的目标和最后的汇总，中途不需要不断交换细节。

另一个适合拆分的场景是权限隔离。负责检索内部知识的 Agent 不该顺手拥有生产发布权限。负责执行变更的 Agent 也不应该能任意读取所有业务数据。此时拆分不是为了让模型更聪明，而是为了让审计和授权更清楚。

还有一种情况是专业工具差异很大。一个子 Agent 固定使用 SQL、指标和 Trace，另一个固定处理浏览器表单与客服系统。只要接口足够稳定，把它们封成专用 worker 会比让主循环临场学习更稳。

关键不在于有几个 Agent，而在于任务之间是否存在高频、强依赖的信息交换。

如果答案是有，先合并。如果答案是没有，再并行。

给 LangGraph 和 Spring 团队的一份落地路线

对已经搭了图式 Agent 工作流的团队，我不会建议推倒重来。更实际的做法是做一次减法实验。

先挑一个高频任务，不选最炫的 Demo。最好是告警排查、研发问答、发布检查这类有真实反馈的场景。把当前图跑一周，记录总时延、模型调用次数、人工接管率、任务成功率和失败原因。没有基线，后面的优化都是凭感觉。

然后把 router、planner、domain worker 合成一个主 Agent 节点。保留原来的工具，把原先写在节点之间的契约整理成 Skills 和结构化状态。LangGraph 很适合做这件事。图不必消失，只要把主路径收窄，把真正独立的并行节点留在边上。

接着做 shadow run。同一批脱敏任务，一路走旧图，一路走单循环。不要只比较最后答案，也比较证据完整度和错误类型。一个答案看似正确，但引用了错误环境的日志，这类问题比语气不够自然严重得多。

最后再决定要不要把某个能力拆回 worker。拆分应该由数据触发，例如某类任务占用主循环太久、工具调用相互独立、权限边界无法在同一节点内表达，而不是因为架构图空着一块不好看。

这条路线对 Java 团队也友好。把 Agent 的状态看成不可变的领域对象，把工具调用封装成有 schema 的 application service，把审批和审计放在模型外。模型负责选择下一步，人类熟悉的工程约束负责兜底。别把可靠性寄托在 prompt 写得足够长。

真正该优化的是交接，不是角色数

最近 Agent 系统很像早年的分布式系统热潮。大家一旦发现可以拆服务，就很容易忘了网络调用不是免费的。今天的 Agent 也是一样。每一次任务委派都要付 token、延迟、上下文损耗和调试难度。

角色多不等于协作好。

一个能读状态、会选 Skill、能调用受限工具、并且留下完整证据的主 Agent，往往已经能把大多数任务做得很扎实。等你确认它真的被独立工作拖慢，再把那部分拿出来并行。这个顺序不酷，但省钱，也更容易定位问题。

那张看上去很热闹的 Agent 架构图，未必是成熟的标志。有时它只是提醒你，系统还没有想清楚谁该知道什么。

先让一条主循环跑明白，再考虑给它开分身。

参考资料