多 Agent 拆得越细越好吗？重新思考 Agent Loop、Skills 与 Subagent 的边界
如果一个 Agent 不够专业，我们就创建一个专业 Agent；如果任务太复杂，再增加 Planner、Researcher、Executor 和 Reviewer。最后，由一个 Orchestrator 把它们组织起来。
这是过去一段时间里相当常见的 Multi-Agent 设计思路。它看起来很合理：职责清晰、能力解耦，每个 Agent 都有自己的 Prompt、Tools 和执行循环，架构图也越来越像一支完整的专业团队。
但问题是，大模型真的需要像人类团队那样分工吗？
2026 年 10 月 22 日，Anthropic 发布了 Building agents: When to fold subagents into your main agent loop。他们发现，在一些企业级应用中，把 Router、Planner 和专业 Subagent 重新合并进一个 Agent Loop，通过 Skills 和按需加载的 Tools 提供能力，反而能够改善任务质量、降低成本和时延。其中一个企业客户将多 Agent 改为单 Loop 后，运行速度约提升了一倍。
这不是孤立的观察。Google Research 在今年初对 180 种 Agent 配置进行了对照研究：在适合并行的金融分析任务中，多 Agent 显著提高了表现；但在 PlanCraft 这类强顺序规划任务中，多个 Agent 反而普遍拖累了性能。
这些发现动摇了一个长期存在的架构直觉：既然复杂工作需要专业分工，那么复杂 Agent 系统也应该拆成多个专业 Agent。
但这又引出了一个新的问题：假设我们正在构建一个企业 SaaS 产品管理系统，用户希望修改某款订阅套餐的价格和服务内容。这个任务可能需要分析现有产品、检查客户合同、评估配置兼容性、生成修改草案，并在发现约束冲突后反复调整方案。
这显然不是几个固定 API 调用就能轻易完成的任务。它需要真正的自主规划、探索和决策。过去，我们很自然地会为此创建一个独立的产品配置 Agent，让它拥有自己的 Agent Loop。但按照 Anthropic 的最新思路，我们也可以将专业知识封装成 Skill，让主 Agent 在自己的 Loop 中完成整个任务。
如果 Skill 自己没有 Loop，它凭什么替代一个拥有自主决策能力的专业 Agent？反过来，如果主 Agent 能够完成所有这些工作，独立 Subagent 的价值又在哪里？
在上一篇文章《为什么多 Agent 不只是 Function Calling？》中，我们讨论了多个 Agent 已经存在时，如何通过 Delegation、Handoff 和 Runtime 实现可靠协作。这一次，我们把问题放得更前面一些：在设计复杂 Agent 系统时，究竟应该在哪里画出 Agent 的边界？
一、拆出五个 Agent，为什么可能还不如一个？
一个看似合理的 SaaS 产品配置系统
先来看一个假设的工程场景。
某 SaaS 平台提供一款每月 99 美元的高级订阅套餐。为了吸引新客户，产品团队希望将新销售版本的价格调整为 79 美元，同时适当减少部分服务权益。
但业务中存在一个关键限制：部分存量客户签订了长期合同，在合同到期前，原有价格和权益必须保持不变。
我们设计了一套看起来相当规范的 Multi-Agent 架构：Pricing Agent 负责分析新价格，Configuration Agent 负责生成产品配置，Impact Analysis Agent 负责分析客户影响，最后由 Validation Agent 验证结果。Main Agent 则负责协调这些专业 Agent，并向用户报告结果。
问题出在第一次交接。
Pricing Agent 在分析过程中已经了解到存量合同的限制，并判断不能直接覆盖所有客户的现有套餐。但它向 Main Agent 返回结果时，重点描述了新价格、服务权益和推荐配置，却没有完整保留合同保护条件。
Main Agent 将这些结果整理成新的配置任务，转交给 Configuration Agent：“将高级套餐价格从每月 99 美元调整为 79 美元，并更新相关服务权益。”
Configuration Agent 收到的是一个看似完整的配置需求。它定位现有产品、修改价格字段、调整服务内容，生成新的配置草案。随后调用配置校验工具，检查字段合法性、价格计算和服务依赖，所有结果均显示通过。
接下来，Impact Analysis Agent 基于新配置分析客户影响。如果它拿到的只是经过整理的产品变更描述，而缺少完整的存量合同约束，就可能无法识别需要保护的客户范围。Validation Agent 最后检查配置结构、价格规则和影响分析结果，同样可能认为整个任务已经完成。
从执行日志看，所有 Agent 都正常结束，所有工具调用都成功，验证结果也是绿色的。但如果修改最终错误地覆盖了存量客户合同，整个业务结果依然是错的。
每个 Agent 都可能正确完成了自己的局部任务，却没有任何一个环节真正保证全局目标得到满足。局部正确，不等于全局正确。
这种风险不一定表现为模型生成了错误的事实，也可能表现为某个重要约束根本没有进入下游上下文。对后续 Agent 来说，没有收到的约束就相当于不存在。更麻烦的是，下游 Agent 可能把缺失约束的结果继续加工成逻辑通顺、格式规范的报告，使问题越来越难从最终输出中识别。
如果验证 Agent 也只检查已经生成的配置草案，而没有重新获取原始合同条件，那么即使增加一层验证，也无法保证发现这个错误。
真正需要检查的是：这条 Agent 边界为什么存在？跨越边界时有哪些信息必须保留？谁负责对全局业务约束进行最终验证？
当然，取消 Subagent 并不能自动解决这个问题。即使只有一个 Agent，如果底层业务服务没有强制执行合同保护规则，它仍然可能产生错误变更。
但如果业务任务本身具有很强的连续性，将定价分析、配置设计和修改决策保留在同一个 Loop 中，就能减少不必要的上下文重建。与此同时，业务规则还应通过确定性工具、原始数据复核和提交前验证真正生效。
多 Agent 的“传话筒税”
很多团队在设计 Multi-Agent 时，容易掉进一种“拟人化分工”的陷阱。
人类软件团队有产品经理、架构师、开发工程师和测试工程师，于是我们也给同一个基础模型配置四段不同的 System Prompt，让它们分别扮演这些角色。
但给同一个模型换四个角色，并不会自动产生四套互补的知识体系。真正改变的是每个模型实例看到的上下文、能够调用的工具，以及被要求完成的任务。
如果这些任务本来就高度依赖，那么拆分会立刻引入额外的协调成本。
例如，在刚才的产品配置任务里，Pricing Agent 可能根据合同约束排除了一种定价方式，Configuration Agent 却不知道这种方式为什么被排除；Impact Analysis Agent 又可能使用另一套客户范围定义。每个 Agent 都在自己的上下文中做出看似合理的判断，但没有机制能够自动保证这些隐含决策彼此一致。
这种问题比普通的工具调用失败更难排查。工具调用失败通常可以从错误码、参数或返回数据中找到原因；跨 Agent 的语义错误却可能需要开发者重新检查多个 Agent 的输入、输出、执行轨迹和中间产物，才能发现究竟在哪一次交接中丢失了约束。
Cognition 在 2026 年 4 月发布的 Multi-Agents: What's Actually Working 中，特别强调了类似的问题：Agent 的行动往往包含没有显式记录的决策。多个 Agent 并行处理同一份可变对象时，即使没有文件冲突，也可能因为选择不同的实现方式、边界条件或行为约定，最终产生不一致的结果。
Google Research 的实验进一步说明，这种协调成本会直接影响任务质量。在其 Towards a Science of Scaling Agent Systems 研究中，中心化 Multi-Agent 架构在可并行的 Finance-Agent 任务上取得了约 81% 的相对提升；但在严格顺序规划的 PlanCraft 任务中，测试的所有 Multi-Agent 变体都出现了 39% 到 70% 的性能下降。
两类任务的差别，不在于哪个更复杂，而在于工作能否真正独立分解。
金融分析可以让不同 Agent 分别研究收入、成本和市场数据，再将相对独立的结果汇总。但在强顺序规划中，下一步往往必须建立在上一步的具体判断之上。不断切换上下文，反而破坏了持续推理所需要的信息连续性。
更强的模型也不能自动消除这种协作成本。一个 Agent 可能很擅长理解业务，却不知道上游 Agent 曾经否定了哪些方案；另一个 Agent 可能具有很好的工具调用能力，却无法从不完整的任务描述中恢复原始约束。
因此，Multi-Agent 的收益不能简单归因于“更多模型参与思考”。我们需要区分额外计算投入带来的收益、上下文隔离带来的收益，以及多 Agent 架构本身带来的协调开销。
业务流程可以拆成多个步骤，不代表每个步骤都值得拥有独立的 Agent Loop。
如果一个任务需要反复观察结果、修正假设、重新规划，那么首先应该考虑如何保持这条认知过程的连续性，而不是按照业务步骤为它安排不同的 Agent。
二、Skill 没有 Loop，为什么仍然能够承担复杂任务？
Skill 不需要独立 Loop，但执行它的 Agent 需要
回到前面的 SaaS 产品配置系统。
如果取消 Pricing Agent 和 Configuration Agent，把这些能力封装成 Pricing Skill、Configuration Skill，再交给一个 Agent Loop 处理，系统是否就失去了原来的专业自主决策能力？
答案是否定的。因为这里混淆了两个不同的问题：一个任务是否需要自主推理，以及这段自主推理是否需要独立的 Loop。
Skill 本身没有独立的模型循环，但调用 Skill 的 Agent 本来就在一个完整的循环中运行。
假设用户提出：“把高级套餐价格降低到 79 美元，但不要影响现有长期合同客户。”
Agent 加载产品配置 Skill 后，可以先查询当前产品定义，再检查合同规则和客户适用范围。如果发现修改现有产品会影响存量客户，它可以决定采用新产品版本或其他兼容方式；如果某种配置不满足业务约束，就根据校验结果调整方案；如果用户的要求存在歧义，还可以直接提出澄清问题。
整个过程中，模型一直在执行“规划—行动—观察—修正”的自主循环。它并没有因为产品配置被封装成 Skill，就退化为只能按固定步骤工作的 Workflow。
这里真正发生的变化是：领域知识从独立 Subagent 的 System Prompt，转移到了当前 Agent 可以按需加载的 Skill 中；而自主决策的执行位置，从子 Agent Loop 转移到了当前 Agent Loop。
Skill 不需要拥有自己的 Loop，因为自主探索发生在执行 Skill 的 Agent Loop 中。
这正是 Anthropic 最新文章推动的架构变化。
过去我们常常将一个复杂领域封装为独立 Agent，是因为不希望 Main Agent 同时承担太多业务知识、操作规则和工具调用。如今，更强的模型加上 Skills 和 Tool Search，使一部分原来必须通过拆分 Agent 解决的问题，可以直接在上下文管理层得到缓解。
但这并不意味着原先由 Subagent 负责的所有事情都能直接消失。
如果某个专业 Agent 原本拥有独立模型配置、特殊权限、专用执行状态或长期任务责任，那么将它的 Prompt 转换成 Skill，只完成了知识和操作方法的迁移，并没有自动解决其他执行语义。
这也是为什么从 Multi-Agent 转向单 Loop，不应该只是一次 Prompt 文件重组，而应该重新检查自主决策、执行状态、工具权限和业务验证分别由谁负责。
单 Loop 不等于巨大 Prompt
如果只是把原来四个专业 Agent 的 Prompt 拼接到一起，那并不是真正的架构改进。
这样做只会得到一个更庞大、更难维护的 System Prompt。模型不仅需要理解当前业务目标，还要同时面对大量无关的规则、工具和参考资料。
Anthropic 推荐的关键机制是 Progressive Disclosure（渐进式披露）。
Agent 初始只需要知道有哪些能力可用，以及在什么情况下应该加载它们。真正执行产品修改时，才读取产品配置 Skill 和相关知识；需要合同数据时，再调用合同查询工具；需要影响评估时，再加载对应规则与数据。
模型不必从一开始就携带整个企业的业务知识。
这套机制实际上改变了单 Agent 架构的扩展方式。过去，为了避免主 Agent 上下文过大，开发者可能创建十几个专业 Agent，每个 Agent 预先装载一组固定工具和领域知识。现在，同一个 Agent 可以通过简短的 Skill 描述和 Tool Search 按需获取能力，不必让所有工具定义和业务规则长期驻留在上下文中。
Anthropic 在新文章中提到，当 System Prompt 中包含大约 30 到 50 个工具定义时，工具选择质量可能开始下降，因此建议通过 Tool Search 延迟加载工具。这个数字是他们的实践观察，真正影响选择效果的还包括工具描述质量、功能重叠程度和任务上下文，而不只是工具数量。
对于复杂业务，还需要进一步明确 Skill、Tool 和 Runtime 的责任。
Skill 应当提供操作方法和判断依据，例如怎样理解产品版本、哪些因素会影响兼容性，以及遇到约束冲突时应当检查什么。Tool 则负责可靠地读取业务数据、维护草案、执行配置检查，并返回结构化结果。
Runtime 或 Harness 负责执行预算、工具调用控制、权限校验、事件记录和恢复等通用机制。对于具有业务副作用的操作，真正的一致性保障还需要由后端业务服务承担。
更关键的是，业务硬约束不应该仅仅写成一段 Skill 文本。
例如，未完成合同影响检查的草案不能提交，未获得授权的用户不能修改产品，不符合版本规则的配置必须拒绝。这些限制应该由确定性工具或业务服务真正执行，而不是完全依赖模型记住一条提示词。
Tool 甚至可以通过明确的错误反馈引导模型调整行动。例如，当 Agent 尝试提交一个尚未完成合同检查的草案时，提交工具可以拒绝执行，并返回缺失的验证条件。Agent 再根据反馈决定补充哪些查询或如何修改方案。
这样，执行顺序中的硬性约束由工具保证，而执行过程中需要探索和判断的部分仍然交给模型自主决定。
但单 Loop 也不是没有代价
事情到这里似乎很简单：既然一个 Agent 加载 Skills 后可以完成复杂任务，为什么不把所有业务都合并进去？
因为问题并没有消失，只是从 Agent 之间的协作成本，转变为单个 Agent 内部的上下文管理成本。
假设 SaaS 平台不仅需要修改产品价格，还需要连续完成市场调研、客户影响分析、财务预测和迁移方案设计。每个阶段都可能产生大量检索结果、候选方案、失败记录和中间计算。
这些信息虽然属于同一个用户目标，却不一定需要全部保留在同一个上下文窗口中。
当上下文持续增长时，模型可能开始混淆不同阶段的假设，无法有效关注当前任务所需的证据，甚至把早已被否定的候选方案重新引入后续决策。
Progressive Disclosure 能够控制信息如何进入上下文，但并不能自动解决已经进入上下文的内容何时被压缩、淘汰或重新加载。
上下文压缩本身也有代价。压缩可以减少 Token，但如果没有明确区分已确认事实、临时假设、被否定的方案以及必须持续遵守的约束，就可能在后续执行中引入新的信息损失。
因此，单 Loop 仍然需要有效的 Context Management，包括中间数据的外部存储、结构化 Artifact、必要的状态持久化，以及在需要时重新获取原始证据的机制。
更重要的是，单 Loop 避免的是不必要的跨 Agent 上下文重建，并不意味着它能够天然保留所有信息。一次错误的上下文压缩，同样可能造成与 Agent 交接类似的约束丢失。
这也是 Anthropic 并未建议彻底取消 Subagent 的原因。
单 Loop 的优势，是让需要共享信息的推理过程保持连续；独立 Subagent 的优势之一，则是让不需要共享的信息留在自己的上下文中。
对于彼此紧密关联的决策，我们希望上下文尽可能连续；对于大量独立探索，我们反而希望上下文尽可能隔离。真正的架构边界，需要根据任务结构而不是功能名称来确定。
三、真正的 Agent 边界，应该画在哪里？
不按业务功能拆，而按认知任务拆
在很多系统中，Agent 的边界最初来自业务模块。
产品设计是一个 Agent，产品修改是另一个 Agent，影响分析又是一个 Agent。这样的划分与现有业务模块甚至开发团队结构天然一致，实现时也容易分配职责。
但 Agent 的认知边界未必与业务模块边界相同。
创建产品和修改产品，看起来是两种不同能力，但它们可能使用相同的产品模型、资源约束、配置工具和验证逻辑。对于一个需要“先设计、再修改、再验证”的连续任务，如果每一步都切换 Agent，就会让模型反复重新建立对同一个产品的理解。
相反，一项大规模客户影响分析虽然仍然属于产品业务，却可能需要独立搜索大量客户记录、合同条款和使用情况。它能够接收明确的分析目标，在自己的上下文中完成探索，再返回结构化报告。
后者反而比按功能划分的两个专业 Agent 更具有独立执行的价值。
这里有必要区分两种经常被统称为 Subagent、但设计动机并不相同的架构形态。
一种是任务型 Subagent（Task-oriented Subagent）。 它通常为某个明确的子任务临时启动，拥有相对独立的输入、上下文和产物。例如，对三种数据库分别进行技术研究，或者对一份配置草案进行独立验证。任务完成后，执行上下文可以结束，只保留必要的结果和证据。
另一种是领域型 Agent（Domain Agent）。 它长期承载某类专业任务，拥有专用领域知识、工具集合和交互责任。例如，一个产品管理 Agent 可以持续处理产品创建、修改和配置问题，并根据不同用户目标加载不同的 Skills。
这两类 Agent 虽然都可能拥有独立 Loop，却回答着不同的架构问题。
对于任务型 Subagent，我们需要判断：这一次子任务是否值得拥有独立上下文，能否在不频繁依赖主 Agent 的情况下完成？
对于领域型 Agent，我们还需要判断：某类专业任务是否值得由独立的执行主体持续负责，它与其他领域之间是否具有清晰的交互和状态边界？
因此，我倾向于把 Agent 拆分判断建立在两个基本问题上。
第一个问题：当前任务是否需要自主决策与持续探索？
对于参数明确、步骤固定、结果确定的操作，普通 Workflow 或 Tool 就足够了。没有必要为了把一个字段写入数据库，就创建一个具有自主推理能力的 Agent。
但如果任务需要根据不确定的输入不断检索、分析、试错和修改计划，就应该由 Agent Loop 承担。
第二个问题：这段自主探索是否值得拥有独立的上下文和执行责任？
如果探索过程高度依赖当前任务的历史决策、用户意图和工具反馈，就更适合留在现有 Loop 中。如果它能够独立完成、产生大量只对自身有用的中间信息，或者需要独立的验证和执行生命周期，那么建立 Subagent 才有更明确的理由。
注意，这个判断与任务“有多复杂”并不是一回事。
一个需要二十次工具调用的复杂任务，如果每一步都紧密依赖前一步，可能更适合单 Loop。另一个只需要几次工具调用的独立安全审查任务，却可能值得放在具有干净上下文的 Subagent 中执行。
复杂性决定是否需要持续自主推理，独立性决定是否值得启动另一个 Agent。
企业系统不必在一个大 Agent 和几十个小 Agent 之间二选一
继续使用前面的 SaaS 平台作为例子，我们可以比较三种常见的架构组织方式。
第一种是 Anthropic 当前重点推荐的简化方向。只要模型能够稳定管理业务知识和工具，减少多余的 Agent 边界通常意味着更少的上下文交接、更直接的工具反馈，以及更简单的整体执行过程。
第二种保留了领域级 Agent Loop，但不再为每一个业务操作创建独立 Agent。例如，产品管理 Agent 可以同时通过 Skills 提供创建、修改和查询能力。用户进入产品管理领域之后，由这个 Agent 直接完成后续交互，不必每次都经过通用 Main Agent 转述。
这种模式也与我们在上一篇文章中讨论的 Handoff 相对应：发生转移的不只是一次任务调用，还可能包括当前任务的执行主导权与用户交互责任。
第三种则允许领域 Agent 在必要时继续委派。例如，产品管理 Agent 保留产品变更的整体目标和上下文，而将长期客户影响分析交给一个只读 Subagent。分析完成后，子 Agent 返回报告、证据和风险项，领域 Agent 再决定是否继续修改。
这三种结构并不是严格互斥的技术类型。
单 Loop 可以运行在领域 Agent 内部，而领域 Agent 又可以在必要时调用独立 Subagent。Handoff 和 Delegation 也解决着不同的问题：前者主要涉及当前执行主导权或交互责任的转移，后者则是在保留总体任务责任的情况下委派一个独立子任务。
对于边界清晰的单领域请求，统一入口甚至不一定需要启动完整的推理 Loop，可以直接路由到领域 Agent，避免出现“入口先分析一次、领域 Agent 再分析一次、最后入口重新汇总一次”的重复过程。
只有当用户目标横跨多个领域，且确实需要持续协调不同专业任务时，才有必要让上层协调 Agent 长期参与执行。
这里还有一项容易被忽略的设计原则：如果用户在两个领域之间频繁往返，例如先设计产品、再配置、然后因为配置约束重新修改设计，就说明这两个领域在实际任务中存在较强耦合。它们可能需要共享更完整的上下文、统一的任务负责人，甚至合并部分执行 Loop，而不是不断进行 Handoff。
因此，领域型 Agent 的边界也不应该完全由业务模块决定，而应该根据真实任务中的上下文依赖和交互模式持续调整。
哪些 Subagent 最值得保留？
从目前公开的研究和工程经验来看，有几类场景的拆分理由相对充分。
独立的广度探索。 例如，同时研究多种数据库、多家供应商或多个候选技术方案，每条探索路径都可以拥有自己的上下文。主 Agent 不需要掌握所有原始检索记录，只需要能够追溯证据的结果。这类任务不仅适合上下文隔离，也更容易通过并行执行缩短整体时间。
干净上下文的独立验证。 生成者需要掌握完整的探索过程，而验证者有时只需要原始要求、最终产物和明确的检查标准。两者不共享所有中间推理，能够减少同一假设反复影响判断的问题。Cognition 在实际开发中观察到，独立的 Devin Review 即使检查 Devin 自己生成的代码，仍然能够发现相当数量的问题。它的价值来自独立审查，而不只是多调用一次模型。
长期的领域交互与执行。 某项业务可能需要多轮与用户澄清、独立维护任务状态，并允许暂停、恢复或取消。此时，独立领域 Agent 可以拥有明确的执行责任。但这些要求也可以部分通过通用 Runtime 实现，因此仍需要判断是否真的有必要增加一个模型 Loop。尤其当领域 Agent 需要直接与用户交互时，完整 Handoff 往往比主 Agent 反复转述更加自然。
上下文与工具空间的有效能力退化。 当一个 Agent 持续出现工具选择错误、领域规则冲突或上下文退化，而改进 Skill 组织、Tool Search 和上下文管理仍无法解决时，拆分可能成为更有效的工程方案。这里不必等到上下文窗口达到物理上限，真正应该观察的是任务质量是否已经出现可测量的下降。
这些场景有一个共同点：我们能明确说明新增的 Agent 边界解决了什么问题，而不是仅仅说明这个 Agent 负责什么功能。
此外，涉及写操作的任务还需要特别谨慎。
多个 Agent 可以并行研究不同候选方案，但如果它们同时修改同一个业务对象，可能产生显式的数据冲突，也可能产生更隐蔽的决策冲突。因此，对于同一个业务变更范围，应当建立清晰的提交责任，并通过版本控制、事务、幂等操作和确定性校验保证一致性。
这不意味着整个企业系统只能有一个写操作 Agent，而是不能让多个自主执行者在缺少协调的情况下同时决定同一份可变业务状态。
让评测决定边界，而不是让架构图决定
既然单 Loop 和 Multi-Agent 的收益都依赖任务结构，最终就不能只靠架构直觉做决定。
对于刚才的 SaaS 产品配置系统，完全可以构建一组覆盖真实复杂性的测试任务：简单修改价格、创建新产品、处理合同例外、修改多个相互依赖的配置、执行客户影响分析，以及在工具返回冲突信息后重新规划。
然后使用同一套模型与业务工具，比较三种架构能否可靠完成任务。
这里最重要的不是比较哪个架构生成的回答更流畅，而是检查最终产品配置、客户适用范围和业务约束是否真正正确。一个 Agent 可以给出非常漂亮的解释，但如果最终业务状态错误，就不能算任务成功。
除了任务完成率，还应当记录工具调用轨迹、上下文峰值、交接次数、Token 成本和端到端时延。对于重要任务，需要重复执行以观察可靠性，避免只凭一次成功就认定架构正确。
尤其值得关注的是 Pass^k 这类可靠性指标：如果同一个任务重复执行多次，系统是否每次都能成功？对于企业业务而言，偶尔成功与稳定成功之间存在很大差距。
比较时还应尽量控制推理预算。否则，一个多 Agent 系统可能只是因为使用了更多模型调用和更多 Token 而获得更好结果，并不能证明拆分本身有价值。
但评测也不能只看最终正确率。
如果某项任务最终失败，需要进一步判断原因来自哪里：是入口路由错误、Skill 没有正确加载、Tool 选择错误、上下文交接丢失了业务约束，还是某个 Agent 自主探索时选择了错误路径？
这些错误对应的优化手段完全不同。有些需要改善 Skill 或工具描述，有些需要修正上下文管理，有些需要增加确定性校验，而只有一部分真正需要改变 Agent 拆分结构。
对于已经上线的 Multi-Agent 系统，不必一次性重构。可以先选择经常共同调用、处理同一份数据、存在强依赖关系的专业 Agent 作为合并候选，并在每次调整后比较任务完成率、成本和执行轨迹。
Anthropic 在最新文章中也强调，迁移时不能只看整体评估分数，还要关注哪些具体任务从成功变成了失败。因为在一个 Agent 合并实验中，主 Agent 获得工具后绕过了原本必须调用的专业 Agent，导致之前正常的流程出现问题。
这个案例值得警惕：原先由拓扑强制执行的某项业务步骤，如果合并后只是写进 Prompt，就可能从确定性约束变成模型可以自行选择是否执行的行为。
因此，架构简化不能仅仅删除 Agent，还需要重新检查必要的业务规则是否已经转移到可靠的工具校验、权限机制和执行约束之中。
正确的目标不是追求最少的 Agent，而是在满足任务质量与可靠性要求的前提下，避免不必要的 Agent。
结语：减少不必要的 Agent，而不是减少必要的自主性
回头看过去几年的 Agent 架构演进，一个明显的变化是：越来越多的系统能力，正在从应用层预先编写的固定编排逻辑，转移到模型自身的规划和执行能力中。
早期模型不擅长处理复杂的多阶段任务，因此开发者通过 Router、Planner、多个专业 Agent 和固定工作流，替模型完成大量决策。
随着模型在工具调用、上下文理解和自主规划方面不断进步，一部分原本必要的外部结构开始变成额外负担。Anthropic 最新提出的单 Loop + Skills，并不是否定多 Agent，而是在提醒开发者重新检查这些结构是否仍然创造价值。
但另一个极端同样不可取。
如果把“减少 Subagent”理解成“所有复杂任务都应该放进一个超级 Main Agent”，那么我们很快又会面对上下文膨胀、领域规则冲突、任务状态混杂和独立验证不足的问题。
而如果坚持每个业务功能都必须拥有独立 Agent，又会让系统陷入不必要的交接、重复推理和协调开销。
真正值得坚持的，并不是 Single-Agent First 或 Multi-Agent First 这样的口号，而是一种更具体的设计原则：
一个需要持续探索和修正的认知任务，应当尽可能保持完整的推理循环；只有当独立上下文、并行执行、验证视角或执行责任能够创造明确价值时，才值得建立新的 Agent 边界。
Skill 可以封装复杂领域知识，但不需要拥有自己的 Loop。Subagent 可以拥有独立的 Loop，但不应该仅仅因为某项业务复杂就被创建。领域型 Agent 可以承担长期的专业交互，任务型 Subagent 则可以为某个独立目标临时提供上下文隔离和自主探索。
Runtime 负责让这些自主执行过程在真实工程环境中受到约束，并能够可靠地运行。业务服务则必须对权限、数据一致性和不可违反的业务规则承担最终责任。
最终，Multi-Agent 架构不应该是业务功能列表的另一种表达方式，也不应该简单复制企业的组织结构。
好的 Agent 架构，不在于能够启动多少个 Agent，而在于是否知道什么时候不需要启动另一个 Agent。
而当我们确实决定拆分时，接下来才需要回答上一篇文章讨论的问题：这些拥有独立 Loop 的 Agent，应该如何委派任务、移交控制权、异步协作，以及如何通过 Runtime 保证整个系统的可靠执行。
