AI Code With
开发教程Developer Workflow

别急着堆子 Agent：按 Anthropic 建议把流程收成 Claude Code Skill（附最小对照）

Anthropic 指出许多企业多 Agent 编排更慢、更丢上下文。本文把它映射到 Claude Code：何时用 Skill、何时留 Subagent；给出 PR 前检查的最小 Skill/Agent 文件对照，并说明 security-audit 这类「必须独立反驳」的流程为什么不能硬折。

5 分钟阅读
别急着堆子 Agent：按 Anthropic 建议把流程收成 Claude Code Skill（附最小对照）

Anthropic 最近有一篇工程向长文：Building agents: When to fold subagents into your main agent loop。核心判断很直白——很多企业把「每个团队 / 每种问题」都做成子 Agent，再叠一个编排层，结果上下文来回摘要丢失、延迟翻倍、品牌语气也不统一；换成「一个主循环 + Skill 渐进披露 + 工具」往往又快又稳。

X 上开发者讨论把它概括成「别再堆子 Agent，收成 Skill」。结合 Claude Code 的现实用法，我们核对了官方建议、在本地搭了一组「Skill vs 子 Agent」最小文件，并对照本站刚测过的 security-audit（刻意保留多 Agent 隔离）说明：什么时候该折进去，什么时候不该。

先说结论：

  • 默认形态：一个主会话、一份系统提示、按需加载的 Skill、少量工具；计划由「正在干活的同一个模型」边做边改。
  • 子 Agent 仍适合：上下文会被过程垃圾撑爆、必须并行新鲜窗口、或权限/指令互相打架时。
  • 在 Claude Code 里，「折进去」通常等于：把子 Agent 的步骤写成 SKILL.md，只在触发时加载正文；不要一上来就 Agent 派工。
  • 我们搭的最小示例：Skill 正文 233 字、子 Agent 定义 128 字；但 Skill 在会话开始只暴露 name + description（约 60 字量级），正文按需加载——这就是渐进披露。
  • 反例：security-audit 这种要「猎手写、验证者反驳」的流程，隔离本身就是产品能力，硬折进主循环会丢掉独立反驳。

创建 API Key →

官方到底建议什么

文章里对企业多 Agent 的批评可以收成四类病：

  • 上下文在子 Agent 之间电话传话，细节丢失
  • 子 Agent 按组织架构疯长，标准不统一
  • 系统提示变成 Frankenprompt，语气和规则互相打架
  • 延迟：有客户对比多 Agent 编排与单循环，单循环大约快一倍

他们建议的目标态：

  • 一个模型、一个上下文窗口、开放式工具循环
  • 每轮可并行一批工具，结果回到同一模型再决定下一步
  • 流程与领域知识放进 Skill；硬限制（校验、审批）放进工具
  • 一次只折一个子 Agent，靠端到端 eval 决定去留

官方也列了仍然该留子 Agent 的条件：主循环已能量化地被上下文拖垮；任务必须并行且用完即弃；或单一 Agent 选不好工具 / 指令冲突。

映射到 Claude Code：CLAUDE.md、Skill、Subagent

机制何时进上下文适合别用来
CLAUDE.md几乎总在项目命令、边界、验证标准塞长篇流程百科
Skill名称/描述常驻，正文按需可重复的多步流程一次性闲聊提示
Subagent独立窗口，只回最终摘要深搜、日志海、只读审查每个小步骤都派一个

写 Skill 的细则见 怎么写 SKILL.md；装通用 Skill 见 Agent Skills 怎么用。子 Agent 要省额度时，可把执行模型配成 Haiku：配置 Haiku 5.5 子 Agent。

最小对照：把「PR 前检查」收成 Skill

假设你原来有一个 pr-reviewer 子 Agent，主会话动不动就 Agent 出去做「跑测试 + 看 diff」。按官方思路，若步骤短、还要你在主对话里接着改，就应收成 Skill。

我们在空项目里放了两份最小文件（只为对照结构，不绑定某一框架）：

markdown
---
name: pr-check
description: 在提交或开 PR 前做一次本地检查：跑测试、看 diff、列出风险点。用户说「提交前检查」「PR 前检查」时用。
---

按下面顺序做，结果写回主对话，不要另起子 Agent：

1. 用 git status / git diff 看改了什么
2. 跑项目里已有的测试命令（从 package.json 或 README 找）
3. 用三条以内要点说明：通过了什么、失败了什么、建议提交前再改什么

对比旧的子 Agent 头：

markdown
---
name: pr-reviewer
description: 独立审查当前改动并返回摘要
tools: Read, Grep, Bash
---

你是只读审查员。检查当前 git diff，返回：风险列表、测试建议、是否建议合并。不要修改文件。

体积对照（本机 wc 级统计）：Skill 全文 233 字符 / 11 行；子 Agent 128 字符 / 8 行。差别不在谁更短，而在 加载时机：Skill 会话开始只挂 name + description（我们这段 description 约 60 字），正文等任务匹配或你输入 /pr-check 再进主上下文；子 Agent 则新开窗口，中间推理你看不见，只剩摘要。

迁移口诀：

  • 把子 Agent 系统提示里的「步骤」搬进 Skill 正文
  • 把「必须打外部系统」的动作变成 MCP / 工具，而不是另一个 Agent
  • 主会话自己跑流程时，Skill 里写明「不要另起子 Agent」
  • 需要隔离噪声时再用 context: fork 或真正的 Subagent——官方 Skills 文档支持 Skill 在 fork 的 Explore 里跑研究任务

什么时候不要折：security-audit 反例

本站刚用第三方 Key 跑过 Cloudflare 的 security-audit skill：DVNA 一轮 standard 用了 49 个 Agent，专门让「没写过这条候选的新 Agent」去反驳。这里的多 Agent 不是组织架构幻觉，而是 验证独立性。若折进单一主循环，写候选和反驳的是同一段上下文，评审价值会塌。

所以决策表可以更硬一点：

信号倾向
步骤要你边看边改、共享刚读过的文件Skill + 主循环
只要一份摘要，中间输出是噪声Subagent
必须并行且互不污染Subagent / fork
第二个 Agent 的存在是为了「没见过上一手」保留隔离，不要折

和 Claude Code 近期能力怎么配合

  • 2.1.310 包装里已有 ProposeSkills 工具类型：可从记忆/过程提案新 Skill 或改进旧 Skill——适合当你准备「折子 Agent」时先让模型起草 SKILL.md，再人工审。
  • 长任务后台看日志用 Monitor（见 Monitor 2.1.310 教程），不必再开一个「日志子 Agent」。
  • 官方迁移套件挂在 /claude-api 相关 skill 上（build-eval、hillclimb 等），偏 Claude API / Agent SDK 工程；纯 CLI 工作流先从「一个 Skill 替代一个派工」做起即可。

实操检查清单

  • 列出你过去一周真正派过的子 Agent 名称与触发原因
  • 对每个问：若正文在主会话展开，质量会更好还是更乱？
  • 更好 → 写成 Skill，description 写清触发词；更乱 → 留下，并收紧 tools
  • 一次只迁一个，迁完用同一批真实任务回归

配置第三方 Key 仍按 接入教程；想让 Claude 与 Codex 互审计划和代码，见 claudex-loop 实测——那是「保留两家模型」而不是「一家里叠十个子 Agent」。

创建 API Key →

常见问题

折进主循环会不会把上下文撑爆？

Skill 的正文按需加载；工具可用 tool search / 延迟加载。官方提到他们曾把更先进模型上的 Claude Code 系统提示砍掉八成以上，其中就包括把能力改成渐进披露。真撑爆时再对「深搜 / 日志海」开子 Agent。

Skill 和 Subagent 能组合吗？

能。Skill 可 context: fork 到 Explore；Subagent 也可 skills: 预加载知识。官方把前者叫「Skill 带着任务去隔离环境」，后者叫「隔离助手带着手册上岗」。

这和「多模型路由」冲突吗？

不冲突。文章批评的是同一产品里按组织架构复制子 Agent；跨 Claude / Codex 的分工仍可按任务类型选客户端，只是各自内部先保持单循环干净。

相关文章