Anthropic 在最新工程博客里提出一个反行业主流的结论，很多团队盲目堆叠子 Agent、搭建编排器 + 专家智能体的多层架构，反而会带来信息丢失、token 消耗暴涨、延迟上升、效果不稳定的问题；推荐优先采用单循环 Agent+Skills架构，只用一个模型、一套上下文窗口做主推理循环，把原本分散在各个子 Agent 里的业务流程、领域规则封装成模块化 Skills，按需加载调用，在多数企业落地场景里，这套方案的回答质量、成本、延迟表现都优于多层子 Agent 方案，这不是完全否定多 Agent，而是明确划分适用边界：常规业务优先单循环 + Skills，只有任务需要大规模并行探索、跨完全独立领域时，才适合启用子 Agent。下面从传统多子 Agent 痛点、单循环架构流程、Skills 机制、两种架构对比、落地边界逐一拆解。
一、传统多层子 Agent 架构的典型痛点清单
- 上下文割裂：规划 Agent、路由 Agent、各个专业子 Agent 之间传递信息，每次转交都会丢失细节、摘要失真
- 成本偏高：多 Agent 体系 token 消耗通常是单 Agent 方案的 3–10 倍，每个独立 Agent 都要维护自身上下文和提示词
- 延迟更长：多轮调用、消息传递、结果汇总叠加，端到端响应速度变慢
- 维护复杂：子 Agent 数量持续膨胀，提示词、规则版本分散，修改一个业务规则要同步多个 Agent
- 容易复刻组织架构：团队习惯按照部门分工拆 Agent，架构跟着组织走，而不是跟着任务逻辑走
二、单循环 Agent 核心运行流程
单循环 Agent 的核心是规划和执行由同一个模型完成，不再单独分出编排器和执行者：
- 初始化：模型在第一轮生成任务计划，写入上下文，后续可以根据工具返回结果动态修改计划
- 每一轮推理：模型一次性批量输出工具调用指令
- 执行层（Harness）：并行执行工具，内置预算上限、轮次上限、写操作审批闸门（write gates），高危操作（下单、退款、数据修改）需要人工 / 规则校验
- 结果回传：原始执行结果直接返回同一个模型，不经过中间摘要 Agent
- 分支判断：模型决定继续调用工具、向用户提问、输出最终答案
- 终止条件：输出答案，或者达到预算、轮次上限；可选后置校验器（Verifier）复核答案正确性
三、Skills 是什么，以及它的加载机制
Skills 用来承载原本放在子 Agent 提示词里的流程、业务规则、判断标准，是模块化的能力包：
- 存储形式：独立目录，包含 SKILL.md 主描述文件、配套模板、脚本、参考资料
- 渐进式加载（Progressive Disclosure）：平时只加载简短元信息，只有模型判断匹配当前任务时，才加载完整流程文档，避免上下文塞满全部技能
- 权限归属：每个 Skill 指定唯一负责人（DRI），配套评测用例，防止技能无序泛滥
- 配套工具：内置 Skill 创建、审计工具，自动统计调用频次、成本，清理长期不用的冗余 Skill
- 可组合：Skill 内部可以调用其他 Skill，形成能力嵌套，但不会独立成一个新 Agent
四、架构对比简表
| 架构模式 | 核心逻辑 | 优势 | 短板 | 适合场景 |
|---|---|---|---|---|
| 单循环 Agent+Skills | 单模型统一规划执行，能力封装为 Skill，按需加载 | 上下文连贯、token 少、延迟低、维护简单 | 受单上下文窗口限制，不适合大规模并行探索 | 电商客服、企业内部流程、文档分析、常规业务自动化 |
| 编排器 + 多个子 Agent | 主 Agent 拆分任务，分发给不同专家 Agent，汇总结果 | 天然支持并行、适合跨独立领域深挖 | 信息损耗、成本高、延迟高、维护难 | 大规模调研、多方向独立探索、跨完全不相关的专业领域 |
五、什么时候才适合继续用子 Agent？
Anthropic 强调这套架构不是一刀切禁用多 Agent，满足下面条件才考虑子 Agent：
- 任务需要同时向多个互不相关方向并行探索，单一模型很难覆盖
- 领域差异极大，全部塞进同一个上下文会严重干扰主推理
- 任务体量巨大，天然需要独立隔离的算力、权限、安全边界
除此之外，绝大多数 B 端业务 Agent，优先落地单循环 + Skills 方案。
六、落地实施的实操建议
- 先拆能力，不要先拆 Agent：梳理业务，把流程、规则整理成 Skill，而不是直接新建一个子 Agent
- Harness 必须加硬限制：轮次上限、成本预算、写入审批闸门，防止 Agent 无限循环
- 配套评测体系：每个 Skill 都有对应的测试用例，迭代时持续回归
- 渐进改造：现有多 Agent 系统，逐步把高频子 Agent 收敛为 Skill，保留少数必要的并行子 Agent
- 观测埋点：统计 Skill 调用频次、失败率、token 消耗，定期清理闲置 Skill
【相关 FAQ】
问题 1：Anthropic 提出单循环 Agent+Skills 架构，核心观点是不是所有场景都不能用子 Agent？
回答 1：Anthropic 的观点不是完全禁止子 Agent，而是子 Agent 不是越多越好；常规业务优先使用单循环 Agent+Skills，解决上下文割裂、成本高的问题；只有需要大规模并行探索、跨差异极大的独立领域时，才适合使用子 Agent 架构。
问题 2：Anthropic 单循环 Agent+Skills 架构里面，Skills 和普通工具的区别是什么？
回答 2：工具偏向单次原子动作（调用接口、搜索）；Skills 是一套完整业务流程、判断规则、专家方法论的封装包，支持渐进式加载，承载原本放在子 Agent 提示词里的领域知识，还可以嵌套调用其他 Skill。
问题 3：和多层子 Agent 相比，Anthropic 这套单循环 Agent+Skills 架构有哪些明显优势？
回答 3：单循环 Agent+Skills 里规划和执行是同一个模型，上下文不会在多个 Agent 之间传递丢失；token 消耗更低、端到端延迟更小；能力按 Skill 模块化管理，版本维护简单，不容易出现子 Agent 泛滥的问题。
问题 4：在 Anthropic 单循环 Agent 架构里，Harness 执行层起到什么作用？
回答 4：Harness 是单循环 Agent 的运行底座，负责执行模型输出的批量工具调用、并行返回原始结果，同时设置轮次上限、成本预算、写操作审批闸门，管控高危修改类操作，防止 Agent 无限循环和越权操作。
【参考资料】
[2026-10-22]（Building agents: When to fold subagents into your main agent loop）Anthropic Claude 官方博客
[2026-11-09]（Anthropic：子 Agent 不是越多越好，单循环 Agent+Skills 架构详解）与非网
[2026-01-22]（Building Agents with Skills: Equipping Agents for Specialized Work）Anthropic Claude 官方博客
[2026-01-23]（When to use multi-agent systems (and when not to)）Anthropic Claude 官方博客
[2026-09-02]（A guide to the anatomy of effective commerce agents）Anthropic Claude 官方博客
【免责声明】
本文内容基于 Anthropic 官方博客公开的 Agent 工程实践分享，架构选择需要结合业务场景、模型能力、权限安全要求综合判断；技术方案解读仅为资讯科普参考，不构成生产系统 Agent 架构选型、开发落地的确定性方案；具体实现细节、SDK 接口、能力边界以 Anthropic 官方最新文档为准。