Single-Agent Loop（单智能体循环）

单智能体循环（Single-Agent Loop） 是 Agent Loop（智能体循环）的一种极简架构取向：一个模型、一个上下文窗口，运行开放式工具循环——每轮模型发出一批工具调用，harness 并行执行并把原始结果返回同一模型，由它自己决定下一步：再发一批、问用户，还是作答。它与 Orchestrator-Workers（编排者-执行者）式多智能体编排的核心区别是：写计划的模型就是执行计划的模型，规划者可以在同一上下文里随结果随时修改计划，而不是把计划交给无法回改的子线程去执行。

这个说法由 Anthropic Applied AI 团队在《Building agents: When to fold subagents into your main agent loop》中系统化，配套发布了 single-agent-loop-kit 迁移工具，用于评估现有多智能体系统哪些部分应收敛回主循环。它属于企业部署经验导向的新兴提法，不是形式化的架构术语；Anthropic 自己的多智能体研究系统（见 Multi-Agent Research System（多智能体研究系统））也仍在生产中运行——收敛是方向性建议，不是对多智能体的否定。

单循环设计的要素

一个模型、一个上下文窗口的开放式工具循环；turn 数与成本预算、写入门控等硬限制设在 harness 中
每轮批量工具调用 → 并行执行 → 原始结果回填同一模型
循环在模型作答或触达预算时停止；作答后可选运行 goal 或 verifier 检查
模型在第一轮把计划写在上下文里，随结果到达持续修订
上下文仍要管理，但归属变了：
- “用代码从规则目录重写计划"的步骤不再需要——每步由模型自己决定
- 排序知识与领域流程移入 Agent Skills
- 硬限制（校验、审批门）和对话中途出现的杂项（如记忆查找）移入 tools
- 代码仍可用于加载"便宜且几乎总相关"的内容（如实体消解），以及处理工具内部的机械部分（payload 构造、流解析、恢复澄清对话）

为什么现在收敛

共享上下文产生更好的答案：长时间运行的 Agent 应让多个任务的结果留在主上下文窗口里。见过每一步结果的模型能把这些步骤连接起来，产出比消化一组子智能体有损摘要更丰富的洞见——也就是更少的上下文窗口和更少的有损交接。
渐进披露消除了拆分的主要理由：过去团队拆 subagent，多半是因为所有上下文必须预先塞进一个长系统 prompt。现在渐进披露让 Agent 只看 skills 和 tools 的短描述，命中才全量加载；Anthropic 借此把面向新一代模型的 Claude Code 系统提示削减了 80% 以上。
模型更强了：从 Opus 4.5 起，单循环能管理的工作量远超多数团队预期；Opus 5.5 和 Fable 5.1 不可关闭 thinking，近期模型还会自述进度、边走边自查，让不少 harness 元素变得冗余。每代新模型都允许把更多决策从 harness 移回模型——迁移中，僵化的多智能体结构常常正是阻碍新模型发挥的那一层。

企业多智能体的失败模式

当每个能力由独立团队拥有、每个团队再交付自己的 subagent、中央平台团队在其上建编排器时，会出现一组结构性问题：

有损交接：Agent 之间交换什么上下文需要逐对决定，来回传递中细节丢失
Subagent 蔓延：每团队都发自己的 subagent，最终数百个重叠、无标准、无 owner
Frankenprompt：每团队往系统 prompt 加一句，规则互相冲突、声音不一致
本地化过拟合的 evals：各团队只优化自己子任务的评测，无人维护全集，管理层基于稀释后的分数做决策
延迟：一家客户的多智能体 harness 对比单循环，后者快约 2 倍

其根源常是 Conway’s Law（康威定律）：Agent 架构变成了组织架构的复制品。

何时保留子智能体

子智能体在研究前沿和以下场景仍有明确价值：

单循环因上下文膨胀出现可测量的性能退化
多个任务需要并行，且需要用完即可丢弃的新鲜上下文窗口
单智能体难以选对工具，或系统 prompt 中存在互相冲突的指令

若确需拆分，拆分原则是按上下文拆，不按问题类型拆：给每个 subagent 一块几乎不需要系统其余部分参与的工作，让它交回紧凑结果——独立研究路径、接口干净的黑盒验证都是好候选。按问题类型拆分会陷入“传话游戏”，每次交接都在损失保真度。原文配图给了一个编码侧的对照：

flowchart TB
    subgraph S1["按问题类型拆"]
        direction LR
        A1["Agent 1
写功能"] -->|handoff| A2["Agent 2
写测试"] -->|handoff| A3["Agent 3
审查代码"]
    end
    subgraph S2["按上下文拆"]
        direction LR
        B1["一个 Agent
写功能与测试
（上下文已具备）"] --> B2["Verifier
只跑测试、报告结果"]
    end

按问题类型拆时，写测试的 Agent 不知道实现决策为何如此，每次 handoff 都丢失上下文；按上下文拆时，同一个 Agent 因为已持有上下文而顺带写好测试，只需一个不需要实现上下文的 verifier 在外部跑测试——这与 Generator-Verifier 类模式并不冲突：拆出去的是客观校验，不是共享判断。

收编路径

从多智能体迁往单循环不必一步到位，典型顺序是：

flowchart LR
    A["Orchestrator\n+ 领域子智能体"] --> B["子智能体\n作为工具调用"] --> C["Skills + Tools\n收编进主循环"]
    C --> D{"Eval 对比\n收编 vs 保留"}
    D -->|"收编版不差"| C
    D -->|"收编版更差"| E["保留为子智能体"]

评测先行：中央团队拥有一套共享的端到端 eval，每个 skill 附带其 owner 团队维护的小 eval 集；10 个 golden 样例就够起步。起步时对最终消息按 rubric 评分；仍有编排器时跟踪路由准确率（是否选对了 subagent），收编后改为检查是否加载了正确 skill、调用了正确工具。内部系统难以回放时，可给关键事件打时间戳，事后重放成定点 eval。任务完成型 eval 是对比架构时最有说服力的信号。
合并领域 agent：把串联彼此输出、触碰同一数据、或经常被一起调用的专家合并——生产流量中"一个专家后面常常跟着另一个"就是紧耦合对，是合并的候选。
子智能体作为工具：保留 subagent，但让主 Agent 以工具形式调用它，自己继续与用户对话；只有需要直接与用户对话的场景才值得完整 handoff。这一步不用重写 subagent，还能带来统一响应 schema、主 Agent 用真实数据核验结论、裁剪最终综合步骤的输入，并为 eval 提供基线。但三个失败模式仍在：各有各的 prompt、上下文、owner 和 eval；每次调用仍返回有损摘要；每次调用都是嵌套模型循环，叠加延迟。
逐个收编为 skills + tools：把 subagent 的 prompt 变成 skill，API 调用变成 MCP 工具，收编一个、对比一次 eval。对比时不要只看总分，要看哪些任务翻转了：某支持 agent 收编一个子智能体后延迟下降，却打破了一条原本通过的流程——主 Agent 自己拿着订单查询工具直接回答，没有向物流专家要送达日期。因此收编前，eval 必须覆盖生产中共同运行的每条 agent 链和每条不可破坏的规则，且每个任务至少跑两遍——这类破坏在两次运行中只显现了一次。

团队如何共同贡献单一 agent

各团队把所有权从"agent"转移到"skills + tools”；一个小型中央团队拥有系统 prompt 和端到端质量，任何新 skill、tool、eval 上线前都由它审查。中央团队保持小规模有利于快速迭代、降低跨组织协调成本。

Tools：适合需要执行动作、读取实时数据或以固定形状返回结果的场景。按用户意图分组（不是每个 API 一个工具）——系统 prompt 中工具定义超过 30–50 个后，工具选择开始退化；更多细节见面向 Agent 的工具设计。
Skills：适合承载"团队如何做事"——步骤、规则和过去由专家 prompt 持有的判断。防蔓延的做法是把维护权交回写 skill 的人：每团队设 DRI，用 skill-creator 审计修剪，用 skill-doctor 查成本与实际使用率、删除死重。
Knowledge bases：偶发需要的引用材料（政策、指标定义、产品规格）放在检索/查找工具后面，或作为 skill 内的参考文件；避免让代码检索后把内容粘贴进 prompt。

配套工具

Anthropic 同时发布了一组 Claude API skills，并由 single-agent-loop-kit 串成迁移工作流：

/claude-api build-eval：搭建中央团队的端到端 eval 集或各团队的 skill 级小集
/claude-api prompt-audit：标记 prompt、skill 与工具描述中为旧模型写的指令，以 diff 形式给出修复
/claude-api hillclimb：对照既有 eval 迭代改进应用，可用于"收编 vs 保留"对比——收编后让它在 skill 和工具描述上迭代，看收编版能否追平或超过 subagent
/claude-api cost-optimize：逐项尝试提示缓存、裁剪输入输出、effort 与模型选择，压成本与延迟