主页
Anthropic 10 月 22 日发了一篇文章,意思很直接:很多企业 agent 里的子 agent(subagent,一个有自己上下文和工具的小 agent,由主 agent 调度)太多了。把它们折回一个主循环,靠 skill 和按需加载的工具来干活,通常质量更好,还更快更便宜。
On October 22 Anthropic published an article with a blunt message: many enterprise agents carry too many subagents (a small agent with its own context and tools, dispatched by a main agent). Fold them back into one main loop that uses skills and on-demand tools, and you often get better quality, lower latency and lower cost.
但这不是「子 agent 过时了」。文章自己列了三种该留的情况:上下文真的塞爆了、需要并行跑且各自要干净的上下文、单个 agent 选不对工具或指令互相打架。它给的做法是:先建 eval(评测集),一次折一个,分数不掉才算数。
It does not say subagents are obsolete. The article lists three cases where you should keep them: the context really is bloated, you need parallel work with fresh contexts, or one agent cannot pick the right tool or gets conflicting instructions. Its method: build evals first, fold one subagent at a time, and keep the change only if the score holds.
另一份独立数据是 Vals AI 10 月 9 日的实验:同样做 50 个全栈 web app,团队版比单 agent 贵 1.8 到 5.1 倍,质量只在一种配置里显著更好。两份材料放一起读,结论比任何一份都稳:先别加 agent,先量。
A separate data point comes from Vals AI on October 9: on the same 50 full-stack web apps, teams cost 1.8x to 5.1x more than a single agent, and quality was significantly better in only one of four configurations. Read together, the two sources give a steadier conclusion than either alone: do not add agents first; measure first.
文章作者是 Diane Sarkis,出自 Anthropic 的 Applied AI 团队的观察。背景是:企业做 agent,常见做法是每个团队做一个子 agent,再由平台团队放一个 orchestrator(编排者)在最上面。结果是子 agent 越堆越多,出现这些毛病:
The author is Diane Sarkis, writing from what Anthropic's Applied AI team has seen. The usual enterprise pattern: each team builds its own subagent, and a platform team puts an orchestrator on top. Subagents pile up, and you get these problems:
文章的替代方案叫 progressive disclosure(渐进式披露):agent 一开始只看到每个 skill 的短描述,需要时才加载全文;工具也一样,用 tool search 按需加载,而不是一股脑全塞进 prompt。这样一个 agent 可以「很宽」,但每一刻的上下文并不长。
The alternative is progressive disclosure. The agent starts by seeing only a short description of each skill and loads the full text when needed. Tools work the same way: tool search loads them on demand instead of stuffing them all into the prompt. One agent can be broad without carrying a long context at every moment.
文章给了三个理由:一是同一个 agent 看到每一步,能把步骤串起来,比拿到子 agent 回来的摘要更靠谱;二是 Anthropic 说它把 Claude Code 的 system prompt 砍了 80% 以上,一部分靠渐进式披露;三是从 Opus 4.5 起模型能在单个循环里处理更复杂的计划,会自己讲进度、自己检查,很多外部脚手架变成多余。
It gives three reasons. First, one agent that sees every step can connect them, which beats summaries coming back from subagents. Second, Anthropic says it cut the Claude Code system prompt by more than 80% for newer models, partly through progressive disclosure. Third, starting with Opus 4.5, models handle more complex plans inside one loop; they narrate progress and check their own work, which makes some scaffolding redundant.
文章推荐的结构很朴素:一个模型、一个上下文窗口,跑一个开放式的工具循环。每一轮模型吐出一批工具调用,harness(外围运行框架)并行执行,把原始结果返回同一个模型。模型答完或者撞到预算就结束。限制放在 harness 里:轮数预算、成本预算、写操作闸门。
The recommended structure is plain: one model, one context window, one open-ended tool loop. Each turn the model emits a batch of tool calls, the harness (the runtime around the model) runs them in parallel and returns raw results to the same model. The loop ends when the model answers or hits a budget. Limits live in the harness: turn budget, cost budget, write gate.
逻辑放哪儿,文章分得很清楚:
The article is specific about where logic goes:
| 要放的东西 | 放哪儿 | 原因 |
|---|---|---|
| 做事的顺序、领域流程 | skill | 按需加载,不占常驻上下文 |
| 硬性限制(校验、审批)、对话中途的查询 | tool | 把前置条件写进工具,不满足就返回模型能照做的指示 |
| 廉价且几乎总相关的加载(如实体解析) | 代码 | 每次都要的事别让模型来回问 |
| 参考资料(政策、指标定义、产品规格) | 搜索/查询工具,或 skill 里的参考文件 | 别用代码往 prompt 里贴 |
| What | Where | Why |
|---|---|---|
| Order of work, domain procedure | skill | Loaded on demand, no standing context cost |
| Hard limits (validation, approval), mid-conversation lookups | tool | Put preconditions in the tool; if unmet, return an instruction the model can act on |
| Cheap, almost-always-relevant loading (e.g. entity resolution) | code | Do not make the model ask for what is needed every time |
| Reference material (policies, metric definitions, product specs) | search/lookup tool, or reference files inside a skill | Do not paste it into the prompt from code |
工具设计上文章给了一个数:工具定义超过大约 30 到 50 个,选工具的准确度会下降。所以工具按用户意图分组,而不是一个 API 一个工具,并配合 tool search 延迟加载。
On tool design the article gives one number: tool selection tends to degrade beyond roughly 30 to 50 tool definitions in the prompt. So group tools by user intent rather than one tool per API, and defer loading with tool search.
文章没有把子 agent 一棍子打死。它说该留或该加的三种情况:
The article does not write subagents off. It names three cases to keep or add them:
如果留,文章的建议是:从最简单的模式开始(generator-verifier 或 orchestrator-subagent),并且按上下文拆,不按问题类型拆。好的候选是互相独立的调研路径、接口干净的组件、黑盒验证。每个子 agent 应该只需要系统其余部分的一点点信息,返回一个紧凑的结果。另外它警告了「康威定律式」架构:每个团队一个子 agent,agent 就成了组织架构图的镜像。
If you keep them, the advice is to start with the simplest pattern (generator-verifier or orchestrator-subagent) and to split by context, not by problem type. Good candidates: independent research paths, components with clean interfaces, black-box verification. Each subagent should need little from the rest of the system and return a compact result. The article also warns against Conway's-law architectures, where each team gets a subagent and the agent mirrors the org chart.
name 和 description 必填;tools 是白名单,model 可选 sonnet、opus、haiku 等,isolation: worktree 能让它在临时 git worktree 里跑。今天的 Claude Tips 小课会讲怎么写。name and description are required; tools is an allowlist, model can be sonnet, opus, haiku and others, and isolation: worktree runs it in a temporary git worktree. Today's Claude Tips lesson covers how to write one.第一步,先建 eval。一套端到端的共享评测由中央团队负责,再加每个 skill 各自的小评测,各团队负责。十个 golden example(人工认可的标准样例)就能起步。按 rubric 给最终答案打分;还有 orchestrator 时跟踪路由准确率,折掉之后看是不是调用了对的 skill 或 tool。系统难以重放的话,给关键事件记时间戳,之后能回放成针对性的评测。
Step 1: build evals first. One shared end-to-end set owned by a central team, plus smaller per-skill sets owned by each team. Ten golden examples (human-approved reference cases) are enough to start. Grade final answers against a rubric; while an orchestrator exists, track routing accuracy, and after folding check whether the right skill or tool got used. If the system is hard to replay, record timestamps on key events so you can replay them as targeted evals later.
第二步,先合并。从用得最多的子 agent 开始。紧耦合的专科(互相接着对方输出干活、碰同一份数据、总是一起被调用)是合并候选。如果线上大部分流量是「A 之后跟着 B」,那就把它们合成一个。
Step 2: merge first. Start with the most-used subagents. Tightly coupled specialists (they chain on each other's output, touch the same data, or are called together) are merge candidates. If most production traffic runs A followed by B, make them one.
第三步,把子 agent 变成主 agent 的 tool(过渡)。主 agent 保持对话,调用子 agent 当工具。好处:统一响应格式、主 agent 能对照真实数据校验、给合成步骤的输入更精简、不用重写子 agent,而且顺手得到一个基线分数。只有子 agent 必须直接跟用户说话时才做完整 handoff。遗留问题:每个专科仍有自己的 prompt、owner 和 eval,结果仍是有损摘要,每次调用是一个嵌套循环,增加延迟。
Step 3: call subagents as tools (the intermediate step). The main agent keeps the conversation and calls subagents as tools. Benefits: a shared response schema, the main agent can check against real data, tighter input to the synthesis step, no rewrite of the subagents, and a baseline score for free. Use a full handoff only when a subagent must talk to the user directly. What remains: each specialist still has its own prompt, owner and evals, results are still lossy summaries, and each call is a nested loop that adds latency.
第四步,一次折一个。把子 agent 的 prompt 变成 skill,把它调的 API 变成 MCP 工具,然后在同一套 eval 上比「折」和「不折」。不要只看总分,要看哪些任务翻转了。文章里的例子:折掉一个子 agent 后延迟降了,但一个查送达日期的任务坏了,因为以前是物流专科负责那次调用,折掉后主 agent 没调就直接答了。这个退化在两次运行里只出现了一次,所以每个任务要跑多次。
Step 4: fold one at a time. Turn the subagent's prompts into a skill and its API calls into MCP tools, then compare folded against kept on the same evals. Do not stop at the aggregate; look at which tasks flipped. The article's example: folding one subagent cut latency but broke a delivery-date lookup, because the shipping specialist used to make that call and the main agent now answered without making it. The regression showed up in only one of two runs, so run each task more than once.
Vals AI 在 10 月 9 日发了一个对照实验(作者 Katrina Drozdov)。基准是 Vibe Code Bench:50 个全栈 web app,按产品规格做出来,用 Docker Compose 部署,再由浏览器 agent 跑 UI 测试,得分是通过的 UI 测试比例。八种配置,每种只跑一次:两个模型 × 两档推理强度 × 单 agent 或团队。团队版是一个 lead agent 最多同时派五个子 agent,子 agent 不能再派子 agent。
Vals AI published a controlled comparison on October 9 (author Katrina Drozdov). The benchmark is Vibe Code Bench: 50 full-stack web apps built from product specs, deployed with Docker Compose, then graded by browser agents running UI tests; the score is the share of UI tests passed. Eight setups, each run once: 2 models x 2 reasoning efforts x single agent or team. In the team setup a lead agent spawned up to five subagents at once, and subagents could not spawn their own.
| 模型 / 强度 | 单 agent | 团队 | 差值 | 显著? | 成本倍数 |
|---|---|---|---|---|---|
| GPT 6 Sol / medium | 77.6% | 84.9% | +7.3 分 | 是 (p=0.005) | 2.5× |
| GPT 6 Sol / max | 89.0% | 90.4% | +1.4 分 | 否 | 1.8× |
| Claude Opus 5.5 / medium | 91.5% | 91.2% | −0.3 分 | 否 | 2.2× |
| Claude Opus 5.5 / max | 89.8% | 93.2% | +3.4 分 | 否 | 5.1× |
| Model / effort | Single | Team | Diff | Significant? | Cost multiple |
|---|---|---|---|---|---|
| GPT 6 Sol / medium | 77.6% | 84.9% | +7.3 pts | Yes (p=0.005) | 2.5x |
| GPT 6 Sol / max | 89.0% | 90.4% | +1.4 pts | No | 1.8x |
| Claude Opus 5.5 / medium | 91.5% | 91.2% | -0.3 pts | No | 2.2x |
| Claude Opus 5.5 / max | 89.8% | 93.2% | +3.4 pts | No | 5.1x |
几个读法。第一,只有 Sol 的 medium 档团队版显著更好(+7.3 分)。第二,Sol 的 max 档单 agent(89.0%)比它自己的 medium 档团队(84.9%)还高,虽然差距不显著(p=0.08):对 Sol 来说,加推理强度比加团队划算。第三,Opus 最便宜的配置(medium 单 agent,每个 app 4.08 美元,91.5%)和最贵的(max 团队,每个 app 122 美元,93.2%)分数差不多。第四,时间上两家不一样:Sol 的团队在 max 档更快(中位数 27.6 对 38.4 分钟),Opus 的 max 团队更慢(174.1 对 74.7 分钟)。
How to read it. First, only Sol's medium-effort team was significantly better (+7.3 pts). Second, Sol's max-effort single agent (89.0%) beat its own medium-effort team (84.9%), though not significantly (p=0.08): for Sol, more reasoning effort paid off better than a team. Third, Opus's cheapest setup (medium single agent, $4.08 per app, 91.5%) scored about the same as its most expensive (max team, $122 per app, 93.2%). Fourth, runtime differed by model: Sol's teams were faster at max effort (median 27.6 vs 38.4 min), Opus's max teams were slower (174.1 vs 74.7 min).
再补一个背景:今年 1 月有篇 arXiv 论文(2601.04748,Xiaoxiao Li,1 月 8 日提交)提出,多 agent 系统可以「编译」成等价的单 agent + skills,用技能选择换掉 agent 间通信,摘要说能明显降 token 和延迟、准确率保持有竞争力。它还报告了一个现象:skill 库超过某个临界规模后,选择准确率不是缓慢下降而是陡降,而且相似 skill 之间的语义混淆比数量本身更要紧。摘要没给具体数字,所以我不引用数字。这对「折回单循环」是个现实提醒:skill 也不能无限加。
One more piece of background: a January arXiv paper (2601.04748, Xiaoxiao Li, submitted January 8) argues a multi-agent system can be "compiled" into an equivalent single agent with skills, trading inter-agent communication for skill selection; the abstract says this can cut tokens and latency substantially while keeping accuracy competitive. It also reports that skill-selection accuracy holds up to a critical library size and then drops sharply rather than gradually, and that semantic confusability between similar skills matters more than raw count. The abstract gives no figures, so I quote none. It is a practical warning for folding into one loop: you cannot add skills forever.
配套的 GitHub 仓库叫 anthropics/single-agent-loop-kit,是一个 Claude Code skill,按「审计、基线、合并、折叠、当 tool、维护」六个步骤文件带你走。注意它自己标明:这是参考实现,不维护,不接受贡献,Apache-2.0 许可。README 还承认:合并和维护步骤、折完的 single_loop/ 版本,以及两个测试任务(t18、t19)没有在真实模型上跑过。
The companion GitHub repo is anthropics/single-agent-loop-kit, a Claude Code skill that walks you through six step files: audit, baseline, merge, fold, as-tool, upkeep. It labels itself a reference implementation that is not maintained and does not accept contributions, under Apache-2.0. The README also admits the merge and upkeep steps, the finished single_loop/ version, and two test tasks (t18, t19) have not been run on a real model.
# 先跑自带示例(不要 API key,用离线假模型,只验证管道,不出分数)
cd single-agent-loop-kit/examples/support-desk
KIT_MODEL=fake python3 evals/run_eval.py --variant smoke
# 用到自己的仓库
git clone https://github.com/anthropics/single-agent-loop-kit
cp -r single-agent-loop-kit/skill <你的仓库>/.claude/skills/single-agent-loop
# 然后在 Claude Code 里说:Run the single-agent-loop skill.# Run the bundled example first (no API key; offline stand-in model; checks plumbing, produces no scores)
cd single-agent-loop-kit/examples/support-desk
KIT_MODEL=fake python3 evals/run_eval.py --variant smoke
# Use it on your own repo
git clone https://github.com/anthropics/single-agent-loop-kit
cp -r single-agent-loop-kit/skill <your repo>/.claude/skills/single-agent-loop
# Then in Claude Code say: Run the single-agent-loop skill.套件会先审计,让你对每个子 agent 确认结论(折、合并、当 tool、保留),然后一次改一处、跑 eval、对比。每次花钱的运行前它会停下来给 token 估算。README 建议从 10 个任务、2 到 3 次重复开始。它还依赖几个 Claude Code 命令:/claude-api build-eval、hillclimb、prompt-audit、cost-optimize,以及 /skill-creator、/skill-doctor。
The kit audits first and asks you to confirm a verdict per subagent (fold, merge, call as a tool, or keep), then changes one thing at a time, runs the eval, and compares. It pauses before every paid run with a token estimate. The README suggests starting with 10 tasks and 2 to 3 repetitions. It relies on several Claude Code commands: /claude-api build-eval, hillclimb, prompt-audit, cost-optimize, plus /skill-creator and /skill-doctor.