Anthropic 发布智能体构建指南：多数场景应把子智能体并回单一主循环，靠 Skills 与工具按需加载；一家客户实测提速约 2 倍

核心背景与行业痛点

过去一年，「主调度器 + 一群专职子智能体」几乎成了企业智能体的默认架构。Anthropic 应用 AI 团队在这篇官方文章里指出，很多公司的智能体架构其实变成了组织架构图的翻版（康威定律）：每个团队各造一个子智能体，平台团队再在上面加一个调度器。结果是四类问题：智能体之间传上下文会丢细节；子智能体泛滥，最后有上百个重叠且无人负责的子智能体；每个团队往系统提示词里加一句，变成规则互相冲突的「拼凑提示词」；各团队的评测只针对自己的子任务，没人维护整体。

架构亮点与底层机制

文章建议改用一个模型、一个上下文窗口的开放式工具循环：每一轮模型发出一批工具调用，框架并行执行后把原始结果交回同一个模型，由它决定下一步；轮数、成本预算和写入审批放在框架里控制。领域流程和顺序沉淀为 Skills，校验、审批和记忆查询放进工具，模型只看到简短描述，需要时再加载全文，也就是渐进式披露。Anthropic 给出三个理由：共享上下文能把前面每一步串起来；渐进式披露消除了拆分子智能体的主要动机；从 Opus 4.5 开始，模型在单循环里能管理的事情远超多数团队预期。

权威 Benchmark 与实测跑分对比

文章没有公布标准化跑分，具体评测数据官方未公布。可核对的厂商口径数据有三项：在多个企业部署的对比中，单一智能体加 Skills 的质量常常同时胜过单提示词和子智能体两种设计；一家客户换成单循环后运行时间快约 2 倍；Claude Code 面向高级模型的系统提示词被精简 80% 以上。文章也坦白了反例：在一个示例客服智能体上合并子智能体降低了延迟，却让一条原本通过的流程失败，而且这个问题两次运行只出现一次。

开发者实战落地与开箱指南

如果你已经有多智能体系统，可以按官方配套的 single-agent-loop-kit 分三步走：先建端到端评测给现状打分，10 条黄金样例就能起步；再合并总是连续调用、读写同一数据的子智能体；最后把剩下的子智能体逐个改成 Skills 加 MCP 工具，每次前后对比，并逐条查看哪些任务翻转。确需保留的子智能体，建议让主智能体把它当工具调用，只有需要直接和用户对话时才完整移交。这对用 Claude Code、Agent SDK 或自建框架的团队都适用。