Agent 少了一层，原来能办的事还办得成吗？

回答快了，为什么用户还在追问？#

设想一个客服助手。以前，订单、物流和退货分别交给不同的 Agent；改造后，主助手直接调用工具，回答明显快了。团队正准备上线，却发现用户还在追问：“所以，到底哪天能送到？”

这是假设场景，不是本文实测。它提醒我们：减少一次交接，可能省掉等待，也可能顺手省掉一项必须完成的检查。

我认为，简化 Agent 时应该先保住原来能完成的事情，再讨论省了多少调用。平均分和平均耗时可以看，但上线决定还需要另一张清单：哪些任务从成功变成了失败？

官方建议是逐步改造，不是全部合并#

Anthropic 的 Diane Sarkis 在 2026 年 10 月 22 日发布减少子 Agent 的工程文章。这里的子 Agent，指拥有独立上下文、工具和指令的执行者。

文章建议把高度依赖共同信息的规划、路由或领域处理，尝试收回主助手；业务步骤放进按需读取的 Skills，实际查询和操作交给工具。独立研究、并行工作和权限隔离仍可能值得保留子 Agent。

原文也给了一个反例：示例客服改造后延迟下降，却有一次没有向物流专员查询送达日期，直接凭订单查询结果回答。这个问题在两次运行中只出现一次。它不能代表一般故障率，却足以说明：只跑一次、只看总分，可能放过一条刚被破坏的流程。

这篇文章是本周回看时补充的工程来源，不是今天的新模型发布；本文没有运行其示例，也不据此给单 Agent 和多 Agent 排名。

先找出不能省的那一步#

如果我负责这样的迁移，会先整理用户真正要拿到的结果，而不是沿用旧架构中的角色名称。

例如，“查订单”和“查物流”是系统步骤，“告诉用户可信的送达时间”才是任务。退货也一样：回答政策、核对资格、生成申请和实际提交，不能被一个“已处理”状态混在一起。

我会把每条典型请求拆成三件事：

• 完成结果： 用户最后应拿到什么，能否从系统数据或实际产物核对。
• 必要检查： 哪些信息必须查，哪些条件必须满足，不能用流畅回答替代。
• 禁止动作： 即使多数任务因此更快，也不能越权读取、重复提交或跳过确认。

这张清单可以帮助团队区分“删掉旧流程的负担”和“删掉业务保障”。同样是少一次调用，意义可能完全相反。

同一批任务，逐条看结果怎样变化#

我的验证办法是先保留旧版本，用相同的输入材料、工具权限、模型设置和完成标准测试新旧方案。一次只调整一处交接方式；如果连模型和业务规则也一起换，很难知道问题从哪里来。

除了总体完成率，还应把每项任务归入四种变化：一直成功、由失败变成功、由成功变失败、一直失败。这里最需要先解释的是第三类。

比如，常见问答快了，但“用户补充了新地址后重新查物流”变得不稳定。此时不应让大量简单问答的收益掩盖这条失败路径。可以暂时保留原交接方式，补上新地址与旧查询结果的处理规则，再用同一批任务复测。

耗时和费用也要按完整任务记录。第一次答复更快，若用户需要追问、人工要补查，最终省下的时间可能很少。这是待验证的产品假设，不是本文测得的收益。

官方示例留下的空白，比漂亮结论更有用#

配套的 Single agent loop kit提供逐步迁移和比较工具，但明确属于不持续维护的参考实现，不保证单循环一定胜出。

它公开的第一次运行记录使用 Claude Opus 5，在 2026 年 10 月 8 日对十二项示例任务分别重复两次，只改了退货处理这一处。记录坦言：没有测试政策禁止的退货，也漏掉了先查账号再退货的组合路径。后来补进测试集，不等于历史运行已经覆盖。

第二次运行记录则把诊断子 Agent 改为工具调用。十七项任务各跑两次后，决策仍需要对两项任务追加测试，新旧两侧合计又跑了十六段对话。记录还保留了未覆盖的情况，包括用户第二轮才提供序列号，以及序列号不存在。

这些是同一示例的小规模记录，运行日期也早于工程文章，不是企业生产环境的大样本验证。它们值得借鉴的地方，在于没有把“脚本跑完”和“所有风险已经验证”写成一回事。

对我来说，测试报告应该同时回答：覆盖了什么、漏了什么、为什么仍决定保留或撤回修改。缺口能被明确说出来，下一轮才知道该补哪里。

简化之后，谁继续对整件事负责？#

减少子 Agent 并不会自动减少业务复杂度。规则仍需要有人维护，工具仍需要检查权限，新增能力仍可能影响已有流程。

我的建议是，业务团队负责自己那部分规则和样例，另有明确负责人检查完整用户任务。每次新增或调整能力，都带上对应的失败样本，尤其是跨步骤、补充信息、拒绝操作和重复请求。

初期可以小范围使用，保留回到旧版本的办法。如果单一助手随着能力增加，出现找错工具、漏读规则或信息混淆，就重新评估拆分，而不是为了“架构更简单”坚持合并。

最终值得保留的方案，是用户少等待、关键事项没有漏办、出了问题也能找到原因的方案。Agent 数量只是实现选择，不应该成为验收目标。

来源与边界#

• 工程来源： Anthropic，Diane Sarkis，Building agents: When to fold subagents into your main agent loop，原署期 2026 年 10 月 22 日，未提供时区。对象是企业 Agent 设计与逐步迁移，物流查询遗漏来自文中示例；本文不把它当普遍故障概率。
• 实现来源： 官方迁移工具包。它强调在相同评测下比较变更，同时披露尚未用真实模型验证的部分；参考实现不持续维护，不能直接当成熟生产方案。
• 运行设置： 第一次记录为 10 月 8 日、Claude Opus 5、十二项任务、每项两次；第二次记录为 10 月 9 日、同模型、十七项任务、每项两次，随后对两项任务追加十六段对话。两次变更不同，不能混为一次统一对照。
• 证据限制： 原记录有缺失场景，工具包后来也有改动。本文没有复现实验，没有计算或承诺速度、成本、业务成功率收益，更没有把参考示例推广到所有客服系统。
• 本文判断： 按任务检查成功与失败的变化、先守住必要步骤和禁止动作、保留小范围发布与回退，是产品验收建议，不是上述来源已经验证的业务成果。