打破康威定律困局：Anthropic 官方最新架构，如何将多 Subagents 折叠为单循环与渐进式技能

在构建企业级复杂 AI Agent 的过程中，很多工程团队几乎不可避免地掉进过“多智能体（Multi-Agent）过度设计”的陷阱：遵照康威定律（Conway's Law），公司里有多少个产品线或业务专职，架构师就在系统中堆砌多少个独立的专职子智能体（Subagents），顶层再套一个复杂的中央编排调度器（Orchestrator）。然而，随着系统演进，多层嵌套调用引发的延迟成倍激增、多轮中转造成的上下文失真（“传话游戏”），以及多团队随意给提示词塞私货导致的“科学怪人提示词（Frankenprompt）”，让多智能体系统在工程可维护性上迅速逼近崩溃边缘。

Anthropic 技术团队（Diane Sarkis 等人）刚刚发布了一篇极具工程清醒度的架构实践指南《Building agents: When to fold subagents into your main agent loop》，并开源了配套迁移套件 single-agent-loop-kit。文章指出：随着基础大模型内置推理、自省与多步骤规划能力的跃升，此前由庞大外部调度代码与独立子智能体承担的许多工作，大模型在单一主循环（Single Agent Loop）中已经完全能够高效自洽地解决。业界应当重新将子智能体“折叠”回单主循环，转而依靠 渐进式上下文（Progressive Disclosure）、动态工具检索（Tool Search）与 技能库（Skills）来兼顾系统的可扩展性与高保真度。在精读这份指南并结合我过往构建 Agent 的踩坑经验后，我将在本文中层层拆解从多智能体网络向单主循环演化的核心动因、决策边界与落地方案。

一、康威定律的镜像陷阱：Multi-Agent 架构在企业中的五大崩塌点

在很多企业开始探索 AI 落地时，“为每个业务功能构建一个独立 Agent”往往被视作最理所当然的模块化架构方案：销售团队建一个推荐 Agent，客服团队做一个退换货 Agent，风控团队写一个审核 Agent，然后中央平台组写一个调度器（Orchestrator）在顶层负责意图识别分发。

这种架构表面上职责清晰、契合团队分工，但当真实业务流量涌入时，其固有的分布式脆弱性就会全面爆发。

flowchart TD
    subgraph MultiAgent_Trap["传统多智能体架构的传话与膨胀陷阱"]
        User(["用户请求"]) --> Orch["中央编排调度器 (Orchestrator)"]
        Orch -- "意图路由 (分发)" --> SubA["售后子智能体 A<br/>(独立 System Prompt)"]
        Orch -- "意图路由 (分发)" --> SubB["物流子智能体 B<br/>(独立 System Prompt)"]
        Orch -- "意图路由 (分发)" --> SubC["账务子智能体 C<br/>(独立 System Prompt)"]
        
        SubA -- "有损压缩摘要" --> Orch
        SubB -- "有损压缩摘要" --> Orch
        SubC -- "有损压缩摘要" --> Orch
        
        Orch -- "多级拼接回复" --> UserResp(["最终响应给用户"])
    end
    
    style MultiAgent_Trap fill:#fef2f2,stroke:#f87171,stroke-width:1px

在系统演进过程中，我观察到五个几乎必然出现的工程崩塌点：

1. 上下文严重失真与“传话游戏”（Lossy Context & Telephone Game）

每个 Subagent 拥有独立的上下文窗口（Context Window），当主调度器将任务下发给子智能体，子智能体在内部兜了一大圈工具调用后，最终只能将一段“精简摘要”交回给主调度器。在这个过程中：

底层原始的数据细节、边缘边界条件、中间推理过程全部被抹杀；
多个子智能体相互串联调用时，就像玩“传话游戏”，每一轮上下文转译都会放大语义损耗，导致顶层 Agent 拿到的是严重失真的二手信息。

2. 子智能体野蛮繁衍（Subagent Sprawl）

既然每个业务部门都可以发布 Agent，公司内部很快就会滋生几十甚至上百个功能重叠的 Subagent。这些子智能体缺乏统一的代码规范、生命周期管理与确权负责人（DRI），演变成难以清理的技术债务泥潭。

3. 科学怪人提示词（Frankenprompt）

由于顶层主调度器需要识别何时唤醒哪个子智能体，每个业务团队都会向中央调度器的 System Prompt 里强塞一两句“特定业务规则”或“兜底人设”。日积月累，主提示词变成了各方利益妥协下的“缝合怪”（Frankenprompt），规则自相矛盾、模型注意力被严重分散，哪怕微调一句话都会引发意想不到的线上回归 Bug。

4. 缺乏全局视角的碎片化评测（Unvetted Localized Evals）

每个团队只针对自己那个小 Subagent 编写评测集（Evals），并且极易对自身场景过度拟合（Over-optimization）。业务汇报时每个子 Agent 的单项打分都在 95% 以上，但端到端串联起来的真实用户任务完成率却惨不忍睹。管理层面对局部虚高的指标，根本无法定位全局劣化的根因。

5. 多层嵌套带来的致命延迟雪崩（Latency Avalanche）

一个用户请求需要经历“主调度模型推理 → 意图分类 → 子智能体模型推理 → 工具调用 → 子智能体二次总结 → 主调度模型合并输出”。每一次嵌套都是一次完整的大模型端到端调用与网络往返。根据 Anthropic 官方在大型企业客户中的对照实测：在同等复杂任务下，单循环架构（Single Agent Loop）的运行耗时通常比多智能体编排快约 2 倍！

二、范式转移的底层逻辑：为什么现在的模型能扛起 Single Agent Loop？

回顾技术发展史，很多一年前合理的设计模式，放在当下往往会沦为冗余枷锁。业界开发者当初之所以不得不搞复杂的外部调度器与状态机，本质上是因为早期的模型（如 GPT-3.5 时代）推理窗口狭窄、指令遵循弱、缺乏长程自省能力，必须依赖外部 Python Harness 代码强行约束它的决策步进。

但今天的基础模型已经发生了根本性蜕变。

flowchart LR
    subgraph Evolution["Agent 决策执行中枢的演化"]
        direction TB
        OldPattern["【过去】外部代码硬编码编排<br/>• 外部 Python 状态机强行切分步骤<br/>• 外部代码根据规则目录重写 Plan<br/>• 刚性 Multi-Agent 架构限制模型发挥"]
        NewPattern["【现在】内置推理的单主循环 (Single Loop)<br/>• 模型在首轮上下文原生拟定执行 Plan<br/>• 随工具返回的原始数据动态修正计划<br/>• Harness 仅保留成本预算、安全拦截门禁"]
        OldPattern == "模型原生推理跃升" ==> NewPattern
    end

1. 模型内置推理与自检能力的跃迁

从 Claude 3.5 Sonnet 到最新的模型体系，原生思考推理（Built-in Thinking）已深度融入核心架构，模型会在生成最终动作前在内部进行详细的思考链展开、进度自述（Self-narration）以及实时结果复核。

动态规划代替代码死板约束：模型现在有能力在上下文的第一轮中直接生成长程计划，并在每一批工具调用返回原始数据后，原生审视执行偏差并动态调整下一步动作，不再需要外部脆弱的业务规则重写器；
自适应升级：极简的单循环不仅降低了复杂度，更使得后续模型版本升级变得轻而易举。在过去的迁移案例中，往往是那些僵化死板的多智能体 Harness 代码，阻碍了更强大新模型施展拳脚。

2. 渐进式披露（Progressive Disclosure）：用 Skills 治愈上下文膨胀

既然单循环要把所有任务放在同一个上下文里，会不会导致上下文迅速撑爆（Context Bloat）？

解决这一问题的工程答案正是 渐进式披露（Progressive Disclosure）。

其核心机制分为两翼：

上下文渐进披露（via Skills）：不要在初始 System Prompt 里把全公司的业务规范、操作手册全量注入。系统提示词只保留技能的高层简短描述（Short Descriptions）。只有当模型判断当前任务确实命中了该领域时，才按需将完整的技能指令（Steps, Rules & Judgment calls）动态挂载到上下文中。Anthropic 在优化 Claude Code 官方编码智能体时，通过引入渐进式披露技能机制，成功将其高级模型的 System Prompt 篇幅削减了 80% 以上；
工具渐进披露（via Tool Search）：实战经验表明，当系统提示词中同时声明的工具数量超过 30 ~ 50 个时，模型对工具名称和参数模式的选择准确率就会发生断崖式下跌。通过将工具元数据延时加载，并配合工具检索机制（Tool Search），模型在需要时先检索相关工具，再按需激活对应 Schema，既保证了工具库容量的无限扩展，又守护了注意力焦点。

三、何时该折？何时该留？子智能体决策矩阵

这是否意味着所有的 Subagents 都应该一律消灭？并非如此。Anthropic 在指南中非常严谨地划定了边界。

保留独立的子智能体，必须严格满足以下三项客观物理条件之一；若不满足，则应果断将其折叠入主循环：

flowchart TD
    Start(["评估现有 Subagent 是否折叠"]) --> Q1{"1. 单循环上下文是否出现<br/>可测量的不可逆膨胀与质量劣化？"}
    Q1 -- 是 --> Keep["【保留为 Subagent】<br/>实施严格上下文物理隔离"]
    Q1 -- 否 --> Q2{"2. 是否需要高并发投机执行？<br/>(且完成后上下文可直接丢弃)"}
    Q2 -- 是 --> Keep
    Q2 -- 否 --> Q3{"3. 是否存在根本冲突的指令/人设？<br/>(或工具选择发生不可调和的混乱)"}
    Q3 -- 是 --> Keep
    Q3 -- 否 --> Q4{"4. 是否需要该子智能体直接接管对话<br/>与人类用户进行专属深聊 (Handoff)？"}
    Q4 -- 是 --> Keep
    Q4 -- 否 --> Fold["【果断折叠】<br/>下沉为 Skills + MCP Tools<br/>纳入 Single Agent Loop"]
    
    style Keep fill:#fef3c7,stroke:#f59e0b,stroke-width:1px
    style Fold fill:#dcfce7,stroke:#22c55e,stroke-width:1px

对照上述四道判定闸门，可以清晰建立如下架构映射表：

场景分类	架构推荐	核心技术方案	判定依据与典型案例
独立探索与黑盒验证	保留 Subagent	独立 Context 探索，仅回传确定性结论	深度论文检索、长篇代码库并行静态扫描、独立验证器（Verifier）。
人类专属会话接管	保留 Subagent	完整会话移交（Full Handoff）	涉及特定合规认证的专家面谈、真人坐席平滑承接。
常见业务流程与领域查询	折叠入主循环	下沉为 Skill（业务规则）	退换货审批政策、会员权益判定、打折计算逻辑。
外部系统交互与数据读写	折叠入主循环	下沉为 MCP Tool（意图封装）	订单数据库查询、CRM 状态更新、邮件发送 API。
跨模块数据依赖串联	折叠入主循环	主循环批量并发工具调用	用户画像读取 → 消费记录分析 → 优惠券发放。

[!NOTE]
上下文共享的降维打击：将多个业务专职折叠进同一上下文后，主智能体能够同时看见之前所有工具返回的未经压缩的原汁原味数据。相比于接收子智能体有损压缩后的摘要，拥有完整全局上下文的模型所做出的洞察、推理和决策质量，要远远高出一个量级。

四、平滑折叠三步法：从 Multi-Agent 到单循环的演进管线

如果你手头已经有一套运行在生产环境中的 Multi-Agent 复杂系统，直接推倒重来绝对是高危工程灾难。必须采用“单变量演进、度量驱动”的平滑迁移管线。

flowchart TD
    Step0["第 0 步：构建端到端黄金评测基准 (Task-Completion Evals)<br/>• 采集 10~50 个跨模块真实复杂案例<br/>• 记录时间戳用于确定性回放"] --> Step1
    Step1["第 1 步：合并强耦合的领域专家 (Combining Domain Agents)<br/>• 找出经常成对链式调用、共享同一批数据的 Subagents<br/>• 将其合并为单一领域专家"] --> Step2
    Step2["第 2 步：将 Subagents 降级为工具调用 (Called as Tools)<br/>• 主智能体维持对话主权，不交出会话<br/>• 将 Subagent 封装为标准 Tool 唤起，统一响应 Schema"] --> Step3
    Step3["第 3 步：彻底消解为 Skills 与 MCP Tools<br/>• 提取 Subagent Prompt 规则为渐进式 Skill<br/>• 将底层 API 封装为基于用户意图的 MCP Tool"]
    
    style Step0 fill:#f1f5f9,stroke:#94a3b8,stroke-width:1px
    style Step3 fill:#dcfce7,stroke:#22c55e,stroke-width:1px

第一步：确立端到端黄金基准（Task-Completion Evals）

折叠前最关键的基础设施是建立一套由中央团队统领的全局端到端完成率评测集。哪怕起步只有 10 ~ 20 个具有代表性的真实业务案例，也必须覆盖生产环境中各个子 Agent 串联执行的全部典型路径。

[!WARNING]
防范“任务翻转（Task Flipped）”暗坑：
在对比折叠前后效果时，绝不能只看整体胜率平均分，必须逐项排查“原先通过、折叠后反而失败”的翻转任务！
Anthropic 在测试一个客服 Agent 的折叠实验中就踩过这样一个典型暗坑：当他们把一个负责发货的子 Agent 融合进主 Agent 后，虽然总延迟大幅下降，但原本一直表现完美的“退货换货”流程却偶发性报错。根因在于：主 Agent 手里直接拿到了订单查询工具，模型认为自己已经看懂了订单，于是擅自直接给用户回复了预估到货时间，跳过了原本必须向物流专员严格核验船期规则的关键步骤。
这种由于执行权限汇聚引发的边界漂移，只有通过端到端用例多轮重复运行（至少每个 Case 跑 3 次以上排除模型方差）才能彻底筛查出来。

第二步：合并紧密耦合的领域专家（Combining Domain Agents）

在梳理生产日志时，统计所有子智能体之间的调用关系矩阵。凡是在流量链路上总是前后顺序触发、互相传递中间产物、或者读写同一类业务实体的子 Agent（例如“订单状态检索”与“物流轨迹跟踪”），应当第一时间将其合并为一个领域模块，从物理链路上砍掉一次 LLM 路由调度。

第三步：过渡期折衷：将子智能体作为普通 Tool 调用（Subagents Called as Tools）

在完全重写某个复杂子智能体之前，最具性价比的过渡方案是：收回子智能体的会话接管权，将其作为主循环的一个内部 Tool 来唤起。

主智能体保持会话连续性：主 Agent 始终面对用户，持有完整的交互记忆；
强制规整输出 Schema：子 Agent 不再自由倾倒非结构化自然语言，而是通过定义严格的 JSON Schema 吐出结论；
主智能体复核结果：主模型拿到结论后，可以利用手中直连的真实只读工具进行交叉校验（Cross-validation），消除子 Agent 的幻觉风险。

这一步无需改写子 Agent 内部提示词，却能在保留原有人力分工的同时，立即斩断主流程上的层层 Handoff 状态混乱。

第四步：终局落地：彻底消解为 Skills 与 MCP Tools

在基准测试达标后，正式开启“物理溶解”：

Prompt 逻辑 → Skills：把子智能体中沉淀的执行 SOP、判断规则、行业黑话约束提取出来，放入标准 Skill 描述文件中；
API 调用 → MCP Tools：把原先由子智能体专职代理的外部 API，统一收敛为高内聚的 Model Context Protocol（MCP）服务。

五、多团队协同新秩序：解耦中央平台与业务小组

很多人之所以拥护 Multi-Agent，根本原因不是技术最优，而是组织架构博弈：每个业务部门都想在 AI 项目中占山为王，拥有属于自己团队的“独立 Agent”。

如果把所有 Agent 都折叠为一个 Single Agent Loop，如何维持多团队高效敏捷协同，避免中央团队成为研发阻塞瓶颈？

Anthropic 在文章中给出了极其精巧的组织架构解耦方案：将团队资产的交付形态，从交付独立的 Agent，转变为交付 Skills 与 MCP Tools。

flowchart TD
    subgraph CentralPlatform["中央平台团队 (Platform Core)"]
        CP1["全局系统提示词 (System Prompt 核心骨架)"]
        CP2["Harness 执行闭环 (Turn/Cost 预算、安全门禁)"]
        CP3["端到端黄金评测集 (E2E Evals) 与接入准入审计"]
    end

    subgraph FeatureTeams["垂直业务团队 (Feature Team DRIs)"]
        direction TB
        FT1["业务团队 A<br/>交付资产:【MCP Tools】<br/>(按意图封装，内置鉴权拒绝)"]
        FT2["业务团队 B<br/>交付资产:【Skills】<br/>(业务 SOP、决策准则，自测 Evals)"]
        FT3["业务团队 C<br/>交付资产:【Knowledge Bases】<br/>(按需检索的知识库与参考文件)"]
    end

    FeatureTeams == "提交通用协议资产" ==> CentralPlatform
    
    style CentralPlatform fill:#eff6ff,stroke:#3b82f6,stroke-width:1px
    style FeatureTeams fill:#f8fafc,stroke:#64748b,stroke-width:1px

1. MCP Tools：基于意图封装，而非 API 机械照搬

业务团队向主智能体贡献工具时，必须遵循两大铁律：

按用户意图聚合（User-Intent Grouping）：严禁把后端的微服务 REST API 按照 1:1 照搬暴露给大模型（如暴露 queryUserById、checkUserStatus、fetchBalance 等一堆零碎接口）。大模型不是底层 RPC 网关，工具必须封装成高内聚的意图动作（如 get_account_overview）；
权限内嵌与自解释拒绝（In-tool Access Control）：不要为了区分“管理员”和“普通用户”去维护两套不同的 Agent。所有权限校验直接移入 MCP Tool 内部执行。当普通用户越权调用敏感工具时，工具底层直接返回清晰的自然语言拒词（如 {"status": "denied", "reason": "需要管理员权限"}），主模型读取该结果后即可自然而然地转述给用户，同一套单循环优雅服务所有权限等级。

2. Skills：把维护的权力还给业务负责人

业务专家的智慧体现在执行步骤与决策裁量权上。这些逻辑被沉淀为独立的 Skill 文件。
为了避免业务团队疯狂堆砌冗余 Skill 引发新的“技能膨胀”，Anthropic 在官方实践中引入了两个自动化命令：

/skill-creator：帮助业务团队按照最佳规范撰写初始结构清晰的 Skill，并自动进行去重与精简审计；
/skill-doctor：监控技能库中每个 Skill 的实际被唤醒频次、消耗的 Token 成本与评测表现，无情标记并剔除长期未被使用的“僵尸技能”。

3. Knowledge Bases：严禁在代码层硬编码拼接

政策法规、指标定义、产品技术文档等静态资料，统一沉淀为知识库（Knowledge Bases）。主循环中必须通过语义搜索（Lookup Tool）由模型按需动态调取，或者直接作为 Skill 内部的附带参考文件（Reference Files）按需读取。绝对禁止在外部 Python 代码里写死任何“根据关键词直接将大段背景知识机械拼接进 Prompt”的硬编码逻辑。

六、官方加速工具链实测：Anthropic Migration Kit 拆解

为了降低企业向 Single Agent Loop 演进的实操门槛，Anthropic 在 GitHub 开源了 single-agent-loop-kit 迁移工具库，并深度打通了官方 Claude API 命令行生态：

flowchart LR
    A["/claude-api build-eval<br/>基于生产回放快速生成初始 E2E 评测"] --> B["/claude-api prompt-audit<br/>静态审计历史陈旧规则，生成精简 Diff"]
    B --> C["/claude-api hillclimb<br/>爬山法迭代优化 Skill 描述与提示词"]
    C --> D["/claude-api cost-optimize<br/>热点分析，Prompt Caching 与成本精细调优"]

在实际工程落地中，这套工具链展现了极高的自动化效率：

/claude-api build-eval：
直接分析历史交互日志与时间戳记录，自动提炼出覆盖主流分支的高保真评测样本集，瞬间抹平从零手写 Evals 的巨大工作量；
/claude-api prompt-audit：
针对存量系统提示词与各个 Subagent 的指令进行深度静态扫描。很多提示词里充斥着“必须输出严格 JSON 且绝不能带思考过程”等为两年前老模型设立的过度防御指令，该工具会自动生成去除历史冗余的优化 Diff；
/claude-api hillclimb：
在执行“折叠还是保留”的 A/B 对比实验时，利用爬山法（Hill Climbing）针对已折叠的 Skill 描述和工具注释进行自适应微调迭代，直到单循环版本的任务完成率持平或反超原有多智能体系统；
/claude-api cost-optimize：
对单循环运行中的 Token 流水进行细粒度剖析，精准定位哪些静态前缀契合 Anthropic 的 Prompt Caching（提示词缓存），并针对不同思考强度（Effort）与模型规格进行分级匹配，实现极致的降本提速。

七、总结与思考：极简主义是智能体工程的最高境界

在长达数月的 Agent 开发与架构重构历程中，我最深刻的体悟就是：软件工程中最强大的诱惑往往是“把问题拆分得过度复杂”，因为复杂的分布式系统总给人一种“架构宏大、工程量充实”的错觉。

然而，在 AI Agent 的世界里，多智能体网络往往掩盖了思考的惰性——当开发者懒得去调校一个高内聚的系统提示词、懒得去设计优雅的渐进式检索，最容易想到的偷懒方案就是“再甩一个 Subagent 出来”。其代价，就是把系统推向高延迟、传话失真与维护噩梦的深渊。

Anthropic 发布的这一演进法则，不仅是一份技术迁移手册，更是一剂及时的架构清醒剂：

以单主循环为基石：把完整的全局上下文还给模型，利用大模型原生跃升的推理规划能力，直面真实任务；
以渐进披露为屏障：用 Skills 和 Tool Search 筑起防线，杜绝无脑上下文堆叠；
以端到端评测为罗盘：度量先行，一次只做单变量微调，让真实数据决定系统的留与折。

未来的工业级 Agent 竞争，绝不再是比拼谁的子智能体拓扑图画得更花哨，而是比拼谁能在最克制、最简洁的单循环闭环中，释放出基础模型最澎湃的智能潜能。

原文链接与参考资料

Anthropic 官方研究原文：Building agents: When to fold subagents into your main agent loop
Anthropic 官方开源迁移套件：anthropics/single-agent-loop-kit
Anthropic 上下文工程最佳实践：The new rules of context engineering for Claude 5 generation models
Anthropic 动态工具检索规范：Tool Search Tool Documentation
Anthropic 多智能体系统构建准则：Building multi-agent systems: When and how to use them

lijianfei.com