结构化摘要：Anthropic 企业级 Agent 实践——单 Agent + Skills 为何优于复杂子 Agent 架构

文章主旨：

Anthropic Applied AI 团队的企业级部署实践表明，配备 Skills 的「单 Agent」在输出质量上通常优于复杂的「子 Agent」架构，且单任务成本与延迟更低；企业应以「上下文独立性」为判断标准决定子 Agent 的去留，通过渐进式披露、Skills 与工具把子 Agent 逐步并回主循环，并用端到端评测保障迁移稳定性。

关键要点：

1. 多 Agent 架构多数已过度设计：许多企业按业务或部门层层拆分专家子 Agent，实质是让技术架构照搬组织架构（康威定律）；一个清晰的系统提示词、4～5 个轻量数据工具和严格输出限制即可覆盖大部分用例。
2. 保留子 Agent 的三个必要条件：上下文膨胀导致可测量的性能下降、高并发且各任务上下文独立、工具过载或系统提示词指令相互冲突；不满足则易陷入上下文丢失、子 Agent 泛滥、拼接提示词冲突、评测局部化、高延迟五大失败模式（有客户实测单 Agent 循环速度约为多 Agent 的 2 倍）。
3. 解法是单循环 + 渐进式披露：Agent 初始只看到简短描述，按需加载 Skills 与工具（Tool Search）。其可行性来自三点：共享上下文带来更丰富的回答、渐进式披露防止上下文膨胀（Claude Code 面向先进模型的系统提示词因此缩减 80% 以上）、模型能力持续增强（可把更多决策从 harness 交给模型）。
4. 理想单循环的形态：一个模型、一个上下文窗口运行开放式工具循环，由 harness 设定轮次、成本预算与写操作等约束；写计划与执行计划是同一模型，可中途修订；执行顺序与领域流程移入 Skills，硬性限制（验证、审批、记忆查询）移入工具，代码只处理低成本加载与机械性工作，上下文由 Agent 自行管理。
5. 迁移与协同方法：四步迁移——建任务完成评测判断去留、先合并紧密耦合与高频领域 Agent、过渡期把保留的子 Agent 降级为工具调用、最终拆解为 Skills 与 MCP 工具；组织上由小型中央团队统一审核端到端质量、系统提示词、新工具与新评测，各团队 DRI 管理自有 Skills，工具按用户意图分组（定义超过 30～50 个后模型更难选对）并延迟加载。

内容结构：

引言

提出反差现象：业界热衷拆出大量专家子 Agent，而 Anthropic 官方反向「劝退」。给出文章定位——提供架构判断依据与迁移方法：按上下文独立性决定子 Agent 去留，将提示词和 API 转化为 Skills 与工具，逐步并回主循环，并用端到端评测保障稳定性。

一、多 Agent 架构为什么变复杂，何时可以简化

• 典型叠加路径：意图分类器 → 固定多步推理 → 按用户分群的分支 → 独立推荐分支 → 顶层多 Agent 编排器。示例：某客服 Agent 内部塞入 12 个专家子 Agent，导致品牌调性难统一、延迟大幅增加、体验受损。
• 核心判断：这类架构多在替模型做「不再必要」的工作。
• 子 Agent 仅在三类情况下保留：上下文膨胀致性能下降；高并发且上下文独立、需用完即弃的新窗口；工具过载或指令冲突。
• 盲目推行多 Agent 的五大失败模式：上下文丢失、子 Agent 泛滥、拼接提示词冲突、评测局部化、高昂延迟。

二、解法：在单 Agent 循环中用渐进式披露按需加载

• 放弃「编排器 + 子 Agent」的硬拼凑，回归单 Agent，通过 Skills 与 Tool Search 按需加载上下文与工具。
• 三个可行性原因：共享上下文产出更丰富深入的回答、有损交接更少；渐进式披露防止上下文膨胀（Claude Code 系统提示词缩减 80% 以上）；模型能力更强（自 Opus 4.5 起单循环可处理的工作远超多数团队预期，新模型更会说明进展与自我检查，简单循环也更易迁移到下一代模型）。
• 代价：单循环需要细致设计与维护（系统提示词、Skills 与工具描述的触发时机、上下文窗口与记忆笔记）。
• 治理建议：由精简的中央团队负责端到端质量、系统提示词及新工具与新评测的审核；若走多 Agent 路线，从生成器+验证器、编排器+子 Agent 等最简模式起步，并按上下文而非问题类型划分边界，以保证交接时的信息保真度。

三、理想的单循环设计长什么样？

• 一个模型、一个上下文窗口运行开放式工具循环，harness 负责轮次与成本预算、写操作限制等约束。
• 每轮模型发出批量工具调用，harness 并行执行并回传原始结果，由模型决定继续调用、向用户提问还是作答；作答或触及预算即停止，可选运行目标检查或验证器检查。
• 关键差异：计划由同一模型写入上下文并随结果修订，无需代码按规则清单改写计划。
• 职责再分配：执行顺序与领域流程 → Skills；硬性限制、审批关卡、记忆查询等 → 工具；低成本且几乎始终相关的内容加载（如实体解析）与构造请求体、解析数据流等机械性工作 → 代码；上下文由 Agent 自行管理。
• 该形态与「Agent 理解高层目标并代为行动」的最终形态一致，因信息始终保留在同一上下文中。

四、实战指南：如何分步将子 Agent 并回主循环

• 第一步，用任务完成评测判断去留：中央团队维护共享端到端评测集，各团队提供围绕自有 Skills 的小评测集，10 个黄金样例即可起步；用评分标准给最终回复打分；保留编排器时追踪路由准确率，并回后改查 Skills 加载与工具调用是否正确；在难以重放的环境中，可为重要事件记录时间戳后重放并运行针对性评测。
• 第二步，先合并紧密耦合的领域 Agent：合并前先建小型端到端评测集；优先处理使用最频繁的子 Agent；输出彼此串联、访问同一数据或经常被相邻调用的专家 Agent 应合并（示例：大量流量先调 A 再调 B，则二者紧密耦合）。
• 第三步，过渡期把保留的子 Agent 降级为「工具」：主 Agent 通过工具调用子 Agent，仅在子 Agent 需直接与用户对话时才完整交接；可为子 Agent 定义统一响应结构，便于核验结论、精简汇总输入；优点是无需重写、可先获得基线，但仍存在各自提示词与上下文、有损摘要、嵌套模型循环增加延迟等问题。
• 第四步，彻底拆解为 Skills 与工具：逐个处理，把提示词转成 Skills、API 调用转成 MCP 工具并入主 Agent，再分别评测比较。示例：某客服 Agent 合并后延迟下降，但一个原本通过的流程失败——主 Agent 持有订单查询工具，未向配送专家询问送达日期便自行作答；因此变更前评测需覆盖生产中共同运行的每条调用链与不可违反的规则，且每个任务至少运行两次（该问题两次运行只出现一次）。

四（原文编号重复）、组织协同：多个团队如何共建一个单 Agent？

子 Agent 拆解后，业务团队的交付物由「独立 Agent」变为「知识库、Skills 和 MCP 工具」，统一交由小型中央团队审核上线。

• MCP 工具（执行操作、读取实时数据、返回固定结构）：按用户意图分组而非每个 API 一个工具；使用 tool search 延迟加载；尽量减少硬性前置条件，必要的依赖检查放进工具内部返回可处理指令；用户级权限由各工具自主校验并返回明确拒绝说明，使同一循环服务不同权限用户。
• Skills（承载业务步骤、规则与判断方法，即原专家 Agent 的提示词）：把维护责任交还给编写者，可用 Claude 以 Skills 构建、测试、精简其他 Skills；每个团队的 DRI 管理各自 Skills 以防无序扩张；/skill-creator 帮助编写与审查、精简去重重组，/skill-doctor 查看各条目成本与使用频率并清理无用条目。
• 知识库（偶尔需要的静态参考资料）：政策、指标定义、产品规格等放在搜索或查询工具后按需调用，或作为参考文件放入 Skills；避免用代码检索后粘贴进提示词。

写在最后

最佳实践会随模型演进持续刷新，因此比具体架构更重要的是工程原则：建立测量基线、每次只改一个变量、只保留经评测验证的方案。简化不必一步到位——先建含 10 个样例的小型端到端评测集，挑一个最常用的子 Agent 并回主循环，只有在并回版本得分确实更低时才保留它，否则用 Skills 和工具取代，并不断重复这一过程。

文章总结：

文章主张以「先测基线、单变量改动、以评测决定去留」的工程方法，把复杂多 Agent 架构渐进收敛为单 Agent + Skills 的简单循环，而不是追逐某一种固定架构。

Datawhale

查看原文：Anthropic最新长文：请谨慎使用子智能体！

文章来源：

Datawhale

扫码关注公众号