Anthropic《谨慎使用子 Agent》全面分析
这篇文章把 Agent 架构问题从「怎样拆角色」改成「上下文要不要隔离、任务要不要并行、模型能不能选对工具」。它的建议值得优先验证，但它不是「单 Agent 已被证明普遍更优」的定论。本页逐条拆开主张与证据，并把企业建议和个人工作流建议分开。
架构建议
先评估一个主循环加渐进披露的 Skills 与工具能不能完成任务。文章重点列出三个适合保留子 Agent 的场景：可测量的性能下降、需要全新上下文的并行任务、选不准工具或指令冲突。
经验性发现
Anthropic 在多个企业部署里观察到，带 Skills 的单 Agent「经常」胜过两种对照设计。文章没有给出样本数、评分方法和具体数字。
实施原则
用同一套端到端 eval 比较改造前后，一次只改一处，让实测结果决定哪些子 Agent 该消失、哪些该保留。
文章里的每个数字，都带着它自己的适用范围
下面五个数字最常被转述。每张卡标出证据级别和不能被省略的限定语。
对象是 Claude Code 面向新模型的系统提示词内容。原文说「编码评估未测得损失」。它不等于总 token、成本或延迟下降 80%，也不覆盖所有任务与模型。
来自一家匿名客户换成单循环后的结果。文章没有给任务类型、模型配置和计时方法。不能当作一般性能提升比例。
系统提示词里工具定义超过这个区间，模型选工具的准确性倾向下降。Tool search 官方文档用同一区间，但两处都是经验性观察，不是硬性阈值。
原文说「10 个黄金样例足够起步」。它是可行起点，不是统计上充分的样本量。优先选真实、高频、有代表性的任务。
合并一个子 Agent 后，主 Agent 直接作答，漏问配送专家，一个原本通过的流程失败。这个故障在两次运行里出现一次。它说明单次结果会误导判断，不是失败率估计。
文章批评的多层结构，与它推荐的单循环
左图是文章概括的组织型反模式：各团队各做子 Agent，平台团队搭编排器，架构变成组织架构图的翻版。它不是所有多 Agent 系统的共同形态。右图是文章推荐的替代方案。
多层结构（文章批评的形态）
（团队 A）
（团队 B）
（团队 C）
每一层交接都压缩一次信息。文章用「传话游戏」形容按问题类型拆分后的信息衰减。
单循环（文章推荐）
按需加载流程与领域知识
tool search 按需加载定义
放在搜索工具后面
每一步结果都在同一窗口里
先看简短描述，需要时才完整加载
从 Opus 4.5 起单循环能管的事超出预期
文章给单循环三个理由。第三个理由（模型能力）会随版本变化，见「结论的适用期限」。
大型组织搭 Agent 的五个常见问题
这五条是文章作者在多个企业部署里反复看到的现象。它们是观察，不是统计结论。
| 问题 | 文章怎么描述 | 根因在哪 | 个人工作流里的对应形态 |
|---|---|---|---|
| 上下文管理 | 子 Agent 之间交接时丢细节；主 Agent 只拿到摘要。 | 每次交接都是一次有损压缩。 | 多个 Agent 反复读同一批文件，主 Agent 还要重述和纠错。 |
| 子 Agent 泛滥 | 几百个功能重叠的子 Agent，没人知道该用哪个。 | 各团队各做一套，没有统一的审核与合并。 | 多个仓库、脚本、Agent 配置各自维护，互相冲突。 |
| 缝合怪提示词 | 系统提示词由多个团队拼接，指令互相矛盾（原文 Frankenprompt）。 | 没有单一负责人，没有人看完整版。 | Skills 和提示词里有重复内容和冲突条件。 |
| 未经审核的局部 evals | 各团队只测自己那一段，端到端没人测。 | 局部指标高，不等于任务完成率高。 | 只跑单元检查，没有可重复的端到端任务集。 |
| 延迟 | 嵌套循环叠加等待时间；一家客户换单循环后约快 2 倍。 | 每次交接都加 token 和秒级延迟。 | 一个任务里多次启动子进程、重建缓存。 |
什么时候仍该用子 Agent
文章重点列出三个场景。每个场景都带关键限定词，不能压缩成「复杂任务就用多 Agent」。它们不是穷尽清单：文章同时说子 Agent 擅长验证、并行工作和按模块划分权限。
上下文膨胀导致可测量的性能下降
关键词是「可测量」。
上下文长不是拆分理由。要先用 eval 证明信息干扰和性能下降真实存在，再拆。
多个任务需要并行，且各自需要全新的上下文窗口
并行本身不是充分条件。
如果任务共享大量上下文、需要频繁协调，拆开反而增加交接成本。两个条件要同时满足。
单 Agent 选不准工具，或系统提示词指令冲突
先试更简单的修法。
可以先尝试 tool search、改工具描述、精简指令、调整权限边界，再比较实际效果与成本。这些都不管用时才拆。
按上下文拆，不按问题类型拆
这是设计启发式，不是定律。目的是让每个子 Agent 的工作很少依赖系统其他部分，并且只交回一个精简结果。
按问题类型拆（文章不推荐）
- 写功能一个 Agent，写测试一个 Agent，审查一个 Agent。
- 三者共享同一份代码上下文，却各带一套提示词和 evals。
- 信息来回传递，每交接一次保真度降一次。原文叫「传话游戏」。
按上下文拆（文章推荐）
- 写功能和写测试放在同一个 Agent，因为它们共享代码上下文。
- 验证器只跑测试、只看结果，不看实现过程。它靠隔离的上下文提供独立检查。
- 合适的候选：相互独立的研究路径、接口清晰的独立组件、黑盒验证。
单循环怎么跑：每轮做什么，harness 管什么
文章说单循环「需要纪律」。纪律体现在系统提示词、Skill 与工具描述的触发时机，以及上下文窗口、记忆和笔记的处理方式。
什么东西放到哪里
| 内容类型 | 放到哪 | 为什么 |
|---|---|---|
| 顺序、领域流程、操作步骤 | Skills | 模型先看简短描述，需要时才完整加载。不占常驻上下文。 |
| 硬限制、审批、权限 | 工具内部 | 工具先检查前提与权限，拒绝时返回模型能读懂的说明。限制不靠提示词兜底。 |
| 廉价且每次都要的内容 | 代码直接加载 | 便宜又必需的东西不值得让模型多做一次决策。 |
| 知识库 | 搜索工具后面，或打包进 Skill | 避免代码检索后整段粘进提示词，那会让上下文膨胀。 |
从多子 Agent 到单循环：四步，每步都要先有分数
文章和它的工具包都强调同一件事：没有分数，迁移就只是意见。每一步都写出做什么、测什么、什么情况回退或仍有哪些局限。
建端到端的任务完成 eval
- 做什么
- 选真实、高频、有代表性的任务。10 个黄金样例可以起步。给事件打时间戳，方便回放。
- 测什么
- 先看路由准确率，再看 Skill 与工具加载是否正确，最后看任务完成率、成本、延迟。
- 何时回退
- 这一步没有回退。没有 eval 就不开始后面三步。
按共享上下文合并领域 Agent
- 做什么
- 找出经常被连续调用、读同一批上下文的子 Agent，合成一个。从使用量最高的开始。
- 测什么
- 对比合并前后的 eval。看哪些任务由成功变失败、由失败变成功，不只看总分。
- 何时回退
- 合并后关键任务翻转为失败，并且可以重复复现。
保留的子 Agent 改为主 Agent 的工具调用
- 做什么
- 主 Agent 像调用工具一样调用子 Agent，拿结果继续。作者建议完全交接的特殊场景是：子 Agent 需要直接和用户对话。
- 测什么
- 交接次数、摘要是否丢失关键信息、嵌套循环带来的延迟。
- 仍有哪些局限
- 每个专家 Agent 仍有自己的提示词、上下文、团队和 evals；交回的仍是有损摘要；每次调用仍是嵌套循环。文章明说这一步只解决一部分问题。
一次并入一个：提示词变 Skills，API 调用变 MCP 工具
- 做什么
- 每次只动一个子 Agent。它的提示词改写成 Skill，它调用的 API 改成 MCP 工具。
- 测什么
- 同一套 eval 跑多次。示例客服 Agent 合并后漏问配送专家的故障只在两次里出现一次，单跑一次会漏掉。
- 何时回退
- 翻转的任务里出现不可接受的失败，或成本与延迟变差且无法解释。
eval 里还应该加什么
文章聚焦任务完成率。对会自动改代码、提交变更、调用外部 API 的个人工作流，模型答对不等于工作流可靠。建议 eval 同时记录：权限与副作用检查是否触发、人工返工量、延迟和成本。写操作关卡要独立于模型判断。
企业治理方案，与个人工作流能借用的部分
文章一半在讲组织问题。中央团队、各团队 DRI、上线审核，都是针对企业里职责分散和重复建设。独立开发者不需要照搬中央平台团队，但对应的风险会换一种形态出现。
| 文章的企业方案 | 企业里解决什么 | 个人工作流的对应做法 | 不能直接外推的地方 |
|---|---|---|---|
| 小型中央团队负责系统提示词与端到端质量 | 防止缝合怪提示词，统一质量标准 | 自己充当质量负责人；系统提示词只有一份、只有一个修改入口 | 个人没有协调成本问题，但有「多份配置互相覆盖」的问题 |
| 每个新工具、每套新 eval 上线前审核 | 减少重复建设和冲突 | 新 Skill 或工具加入前，先跑一遍现有 eval 集 | 个人审核容易流于形式；eval 是审核的主要依据 |
| 各团队维护自己的 Skills、工具、知识库 | 领域知识留在最懂的人手里 | 按项目或工作流划分 Skills 的维护边界；共享流程只有一个来源 | 「每个团队一套 Skills」不等于「每个工作流一套 Skill」。重复 Skills 会把组织冗余换成个人维护负担 |
| Skills 由各团队 DRI 负责，用 /skill-creator、/skill-doctor 维护 | Skill 质量有人兜底 | 定期清理重复 Skills、冲突指令、不明确的触发条件 | 工具本身不会判断 Skill 该不该存在；去留仍要看 eval |
| 工具按用户意图组织，权限检查放进工具 | 避免工具定义过多、拒绝不可解释 | 高风险工具（写文件、发消息、付费）内置前提检查，返回可读的拒绝原因 | 个人环境里工具数量少，30–50 的区间未必触及，但权限检查仍必要 |
渐进披露怎么落到 MCP 工具、Skills 和知识库上
MCP 工具
- 按用户意图组织，不按后端系统组织。
- 工具定义多了用 tool search 延迟加载。官方文档建议：工具数 10 个以上，或定义超过 10k token 时使用；最常用的 3–5 个工具不延迟加载。
- 工具内部检查前提和权限，拒绝时返回模型可读的说明。
A 阈值来自官方文档，可核对。它是使用建议，不是实验结论。
Skills
- 领域流程、操作顺序进 Skills。模型先看一句描述，命中时才加载全文。
- 每个 Skill 有一个明确负责人。
- 用 /skill-creator 建、/skill-doctor 查。
A 两个命令在 Claude Code 文档里可核对。
知识库
- 放在搜索工具后面，或打包进对应 Skill。
- 避免「代码先检索，再把结果整段贴进提示词」。那是上下文膨胀的常见来源。
B 这是作者的实践建议，没有附对比数据。
加速工具：/claude-api 的四个 Skill
- build-eval：帮你建 eval。
- prompt-audit：审查提示词。
- hillclimb：按 eval 迭代提示词。
- cost-optimize：优化成本。
A 四个名字在原文可核对。它们辅助建 eval 和改提示词，不会自动证明哪种架构更优。
迁移工具包是参考实现，不是生产保证
GitHub 仓库 anthropics/single-agent-loop-kit 的 README 自述：Reference implementation，不维护，不接受贡献。两次真实模型运行由一个人在一个模型上完成。merge 和 upkeep 两个步骤没有在真实模型上跑过。核对时仓库显示 4 星、单次提交。
这些信息不推翻它的方法论，反而指出正确用法：把它当实验脚手架，复用它的评估思路（同一套 eval 前后打分、不假设单循环总是赢），不要把它当成熟的迁移工具。
A README 原文可核对。
逐条列出：原文怎么说、证据在哪、缺什么、能得出什么
这张表是本页的核心。它既不替 Anthropic 放大结论，也不把「未公开」写成「无效」。
按下表 12 条主张的主级别计数。多数 B 级条目同时带 D 级局限，表中单列。
| 主张 | 级别 | 证据来源 | 缺什么 | 允许得出的结论 |
|---|---|---|---|---|
| 带 Skills 的单 Agent 经常同时胜过「一个提示词包揽」和「多子 Agent」 | B | 原文：frequently outperformed both。引用的商业 Agent 文章（2026-09）用词是 consistently has outperformed。 | 样本数、任务分布、评分方法、具体数字。 | Anthropic 自家部署里的常见观察。不能写成「已证明普遍更优」。两篇文章措辞强度不同，应分别标注。 |
| 一家客户换单循环后约快 2 倍 | C | 原文一句话。 | 任务类型、模型、计时方法、是否多次测量。 | 一个匿名案例。只能说「有客户观察到约 2 倍」。 |
| Claude Code 系统提示词为新模型削减 80% 以上 | B | claude.dev 博客 2026-07-24 原句：removed over 80%，with no measurable loss on our coding evaluations。 | 内部 eval 内容与数据。 | 提示词内容削减 80%+，编码 eval 未测得损失。不等于成本或延迟下降 80%，不覆盖其他任务。 |
| 工具定义超过 30–50 个，选工具准确性下降 | B | 原文与 tool search 官方文档都写 30–50。 | 测量方法与数据。 | 两处一致的经验性观察。不是硬性阈值。 |
| tool search 的使用建议：10 个工具以上或定义超 10k token；3–5 个常用工具不延迟加载 | A | 官方文档原文。 | 它是使用建议，与架构论证不是同一层证据。 | 可直接照做的配置建议。 |
| 仍用子 Agent 的三个适用场景 | A | 原文三句，措辞已逐字核对。 | 没有给出判定每个场景的量化方法；原文未声明三条穷尽所有用途。 | 三个场景是作者的设计判断，用 eval 验证每个场景是否成立。 |
| 作者建议完全交接的特殊场景：子 Agent 需直接与用户对话 | A | 原文给出的特殊理由。 | 原文没有说其他场景一概禁止交接。 | 它是原文强调的交接场景，不是所有权转移的普遍定律。 |
| 10 个黄金样例足够起步 | B | 原文：Even a set of 10 golden examples is enough to start。 | 统计上的充分性。 | 起步门槛，不是推荐样本量。 |
| 示例客服 Agent 合并后漏问配送专家，故障出现 1/2 | B | 原文：only showed up in one run out of two。 | 这是说明用的示例，不是失败率。 | 每个任务要跑不止一次。 |
| 迁移工具包 README 自述不维护、真模型运行有限 | A | GitHub README 原文；页面显示 4 星、单次提交。 | 无。 | 它是实验脚手架。 |
| 四个 /claude-api Skill 与 /skill-creator、/skill-doctor | A | 原文与 Claude Code 文档。 | 无。 | 工具存在。效果仍要自己测。 |
| 模型能力结论存在版本适用与外推风险：文章说 Opus 4.5 起单循环能管更多，Opus 5.5 与 Fable 5.1 不能关闭 thinking | D | 原文陈述。「能管更多」是作者经验判断；模型版本事实可核对。 | 「能管更多」没有量化；结论会随模型版本变化。 | 这是结论的适用期限，不是永久性论据。见下方说明。 |
结论的适用期限：为什么模型能力这一段要单独看
文章说，每一代新模型都能把更多决策从 harness 交还给模型自己，更简单的循环也更容易迁移到下一个模型。这是作者在协助客户迁移时的经验：僵硬的多 Agent 结构常常阻碍新模型承担更多工作。
这段话的性质是对趋势的判断。模型版本、thinking 行为、自检能力都会变化。不能用某个版本的表现推导未来所有模型，也不能据此断言单循环在当前或未来始终足够。你的 eval 要在换模型后重跑一次。
先诊断，再决定合并什么
对维护多个 Claude Code / Codex 工作流和一套 Skills 库的人，这篇文章最有行动价值的不是「合并所有 Agent」，而是下面的自查。勾选符合你现状的项。
建议的第一步
先选两三个工作流，不是全部
选交接成本高、上下文高度重叠的那几个。为它们各建一套端到端 eval，10 个真实任务起步，每个任务跑两次以上。
一次只改一处
先合并，跑 eval；再把保留的子 Agent 改成工具调用，跑 eval；最后把提示词改成 Skill，跑 eval。每一步看翻转的任务，不只看总分。
让分数决定去留
eval 变好就留下改动。eval 变差且可复现就回退。不因为「单 Agent 更符合某种架构偏好」预先决定结果。文章和它的工具包都把这一条放在最后：度量，一次只改一处，留下经得起检验的。
本页核对过的原始资料
前五项是本页判定的直接依据，均在 2026-10-23 访问。公众号文章里的 14 张配图未纳入分析。
- Diane Sarkis，Anthropic，《Building agents: When to fold subagents into your main agent loop》，2026-10-22。claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop
- AGI Hunt 转译，《Anthropic：谨慎使用子 Agent》，2026-10-23。mp.weixin.qq.com/s/Ec4UJeYBnVqcVnOSzduWxQ
- GitHub，anthropics/single-agent-loop-kit，README。github.com/anthropics/single-agent-loop-kit
- Thariq Shihipar，claude.dev 博客，《The new rules of context engineering for Claude 5 generation models》，2026-07-24。claude.dev/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
- Anthropic 平台文档，Tool search tool。platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool
- Anthropic 博客，《A guide to the anatomy of effective commerce agents》，2026-09-02。claude.com/blog/the-anatomy-of-effective-commerce-agents
- Anthropic 博客，《Building multi-agent systems: when and how to use them》。claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them
- Anthropic Engineering，《How we built our multi-agent research system》。anthropic.com/engineering/multi-agent-research-system
- Anthropic 平台文档，Task budgets。platform.claude.com/docs/en/build-with-claude/task-budgets
- Anthropic 博客，《Seeing like an agent》。claude.com/blog/seeing-like-an-agent
- Claude Code 文档，Commands（含 /skill-creator、/skill-doctor）。code.claude.com/docs/en/commands