智能体系统的演进：从 Agent 架构选择到运行时控制

引言：为什么 Single Loop 和 Thin Orchestrator 会同时出现？

最近关于 Agent 架构的工程实践，出现了两个看起来方向相反的建议。

一类建议来自 Anthropic：在很多企业 Agent 中，可以把 routers、planners 和 domain subagents 逐步折叠进一个主 Agent Loop，让同一个模型在同一个上下文窗口里制定计划、调用工具、读取结果并继续执行。Skills 和 tool search 负责按需加载能力，Harness 主要负责预算、写操作门禁和终止条件。

另一类建议来自 Meta 的 Thin Orchestrator：中央编排器应该保持“薄”，只承担意图识别、字段收集、可靠性门禁、委派和结果处理，把领域推理交给上下文隔离的 specialist。LangChain 也没有把多 Agent 简化成一种固定架构，而是把 Subagents、Skills、Handoffs 和 Router 视为对应不同约束的模式。

这些建议并不一定互相矛盾。它们分别回答了不同问题：模型应该如何保持推理上下文，哪些能力应该被隔离，哪些步骤必须确定性执行，以及系统如何在生产环境中被评估和治理。

因此，智能体系统的演进不宜简单概括为“从多 Agent 退回单 Agent”。更准确的描述是：模型推理、能力封装、工具行动、上下文隔离、运行时控制、工作流门禁和评估反馈正在重新分层。Agent 的数量只是其中一个表面变量。

一、从按组织拆 Agent，转向按上下文和约束选型

多 Agent 系统最容易出现的一种结构，是每个团队或问题类型各自建设一个 Agent，再由中央平台团队增加一个 Orchestrator。这样的结构与组织分工保持一致，但运行时并不一定因此更清晰。

Anthropic 总结了几类常见问题：Agent 之间反复传递信息时，细节可能在交接中丢失；各团队不断增加自己的 subagent，最终形成重叠、缺少统一标准的 Agent 集合；每个团队向系统提示词中增加一条规则，最后形成相互冲突的 Frankenprompt；局部评估只优化自己的子任务，没人负责整体质量；额外的模型调用还会带来延迟。

这里的关键不在于多 Agent 一定不好，而在于“组织边界”并不是天然的“上下文边界”。两个团队负责的能力，可能共享同一份数据、经常串行调用，甚至需要共同维护一段推理上下文。这时把它们拆成两个 Agent，可能只是增加一次交接。

更适合独立成 Agent 的，通常是能够少依赖系统其他部分的工作：独立研究路径、具有清晰接口的组件、黑盒验证任务，或者需要单独权限和上下文的工作。拆分标准从“谁负责”转向“这段工作能否独立完成、独立验证、独立失败和独立回收”。

二、从大而全 Prompt，到 Skills、Tools 与渐进式披露

Single Agent Loop 并不是把所有能力重新塞进一个超长系统提示词。它依赖的是能力资产的重新组织。

LangChain 将 Skills 描述为一种渐进式披露模式：Agent 启动时只知道技能名称和描述，任务匹配后才加载完整的流程说明、参考资料和资源。Anthropic 的实践也采用类似思路，通过 Skills 渐进加载上下文，通过 tool search 渐进加载工具。

这使得一个 Agent 可以拥有较多专长，但不会在每次任务开始时立即携带全部领域知识。对长运行任务而言，模型还可以把前面步骤的原始结果保留在同一上下文中，减少 subagent 只返回摘要所造成的信息损失。

在这个体系中，三类资产承担不同职责：

这种分工也改变了能力所有权。团队不一定要维护一个完整的专用 Agent，而可以维护自己的 Skills、Tools 和局部评估集；中央团队负责系统提示词和端到端质量。

但渐进式披露并不意味着上下文不会膨胀。Skills 被加载后仍可能留在对话历史中，多域任务也可能积累大量内容。因此，Skills 更适合解决“能力很多但不需要强隔离”的问题；当上下文隔离和并行本身是任务要求时，Subagents 或 Router 仍然有价值。

三、四种架构模式：它们解决的不是同一个问题

LangChain 将常见的多 Agent 设计归纳为四种模式。它们可以作为约束到架构的映射，而不是互斥的技术栈。

因此，架构选型需要先描述任务约束：是否需要并行，是否需要独立上下文，是否存在跨轮状态，specialist 是否需要直接与用户对话，是否存在独立权限边界。

如果这些约束都不明显，单 Agent 加 Tools 或 Skills 往往是更简单的起点。如果存在多域并行和上下文隔离需求，Subagents 或 Router 更合适。如果流程需要持续对话并逐阶段解锁能力，Handoffs 更接近问题结构。

文章中给出的调用次数和 token 数，说明了不同模式在代表性场景下的取舍，但这些数字取决于模型、工具、上下文和任务设定，不能直接作为跨系统的性能排名。

四、从“编排器负责思考”，到控制面与推理面分离

Thin Orchestrator 提供了另一种观察角度。

在 Meta 的案例中，中央编排器被限制在一组确定性职责内：读取 specialist 指令，检查目标是否存在，收集必要字段，自动发现信息，执行可靠性门禁，委派给 specialist，再处理结果。领域代码、配置生成和代码库修改不由编排器完成，而由隔离的 specialist 在自己的上下文中完成。

这种设计并不要求所有系统都采用相同的七步协议，但它清楚地区分了两个部分：

• 控制面：路由、状态检查、字段收集、预算、门禁、委派、重试、升级和终止。
• 推理面：理解领域问题、制定局部计划、调用领域工具、解释结果和完成领域任务。

Single Agent Loop 也在做类似的分离，只是边界位置不同。模型在同一上下文中保留计划和结果，动态决定下一步；Harness 负责轮次上限、成本上限、写操作门禁和硬终止条件。确定性的机械动作、权限检查和硬校验仍然应该由工具或运行时完成。

换句话说，Single Loop 不是取消控制面，而是减少编排器对领域推理的接管；Thin Orchestrator 也不是否定模型的动态规划，而是把确定性控制面从概率性推理中分离出来。

这张图表达的是职责关系，而不是某个具体产品的固定部署结构。一个系统可以在外层使用 Thin Orchestrator，在 specialist 内部使用 Single Agent Loop；也可以用一个主 Loop 直接调用受到 Harness 治理的 Tools 和少量 Subagents。

五、从 Agent 架构，到运行时 Harness 化

如果只看 Single Loop、Subagents、Router 等模式，容易把 Agent 系统理解成“模型加编排器”。但生产化要求还包括状态、权限、预算、审计、可观测性和失败处理，这些内容并不由某一种 Agent 模式自动解决。

可以把系统分成三个职责层次：

1. Framework：提供模型接口、工具调用和组合抽象。
2. Runtime：负责状态持久化、流式输出、恢复和可观测性。
3. Harness：把 Agent 放入一个受预算、权限、工具治理、评估和硬终止条件约束的运行环境。

在 Multi-Agent Harness 的模型中，Agent 负责局部智能，Harness 负责全局控制。Orchestrator 不只是决定调用顺序，还要处理任务生命周期、执行计划裁决、Agent 路由、失败处理和硬终止条件。Tool Registry 则把工具从普通函数调用变成受权限、风险、速率限制和审计约束的资源入口。

Thin Orchestrator 可以看作控制面的一种收窄设计：它强调中央编排器不要承担领域推理。Harness 的范围更大，还包含状态、记忆、成本、工具治理、评估和可观测性。

Single Agent Loop 也不等于“没有 Harness”。相反，越是让模型自主决定下一步，越需要运行时提供预算、写门禁、工具权限、恢复机制和可追踪日志。模型获得的是更大的动态决策空间，运行时则需要把不可越过的边界固定下来。

六、从凭感觉重构，到评估驱动的渐进演进

架构演进的另一个变化，是评估对象从最终答案扩展到整个执行过程。

Anthropic 建议，折叠 subagent 之前先建立端到端评估集，即使只有十个 golden examples，也可以作为起点。仍使用 Orchestrator 时，可以观察路由是否准确；折叠后，则需要观察模型是否加载正确的 Skill、调用正确的 Tool，以及原来必须遵守的流程是否仍然成立。

迁移顺序可以概括为：

1. 建立端到端任务完成度基线。
2. 找出高频、串行耦合、共享数据的 specialist，评估是否可以合并。
3. 对必须保留的 specialist，先让主 Agent 以 Tool 方式调用，保留统一对话和最终校验。
4. 再逐个把 prompt 转为 Skill，把 API 调用转为 MCP Tool。
5. 每次只改一个 subagent，多次运行并比较关键任务是否发生翻转。
6. 如果折叠后质量下降或出现关键流程遗漏，保留原有隔离边界。

生产级评估至少包括四层：组件是否选对工具，轨迹是否有多余步骤或循环，任务是否完成，最终是否带来用户采纳率、返工率、处理时长和单位成本的变化。

由此，架构重构不再是一次性迁移，而更像带有测试约束的渐进式重构。

七、当前可以观察到的演进方向

把这些材料放在一起，可以看到几条同时发生的变化。

1. 架构选择从模式偏好转向约束识别

过去容易先选择某种框架，再把任务塞进去。现在的讨论更强调先写清楚任务需要什么：共享上下文、独立上下文、并行、跨轮状态、直接用户交互、权限隔离，还是确定性门禁。

2. Agent 能力从实例转向可组合资产

专用 Agent 的一部分职责正在被拆成 Skills、Tools、Knowledge Base 和可复用 workflow。这样做不代表专用 Agent 消失，而是让可以复用和治理的部分脱离一次性的 Agent 实例。

3. 编排从“替模型计划”转向“约束模型执行”

在 Single Loop 中，模型可以自己制定和修订计划；在 Thin Orchestrator 和 Harness 中，运行时仍然负责权限、预算、门禁、失败处理和终止。编排的重点从替模型完成所有步骤，转向规定哪些步骤必须满足、哪些资源可以使用、何时必须停下。

4. 可靠性从 Prompt 约束转向运行时和评估约束

Prompt、Skill 描述和工具说明仍然重要，但它们不应独自承担权限、安全和完成判定。生产系统需要把硬边界放到 Tool、Runtime、Harness 和确定性脚本中，再用轨迹和端到端评估检查系统是否持续满足目标。

这些变化共同构成了智能体系统的“架构演进”，但它并不是从一种架构整齐地迁移到另一种架构，而是系统职责持续重新分配的过程。

八、实际选型：什么时候用哪一种？

可以用下面的判断表作为初步入口：

这个表格不是互斥选择。同一个产品可以在不同任务上使用不同模式，也可以在更大的 Harness 中同时存在主 Loop、Skills、Tools、Router 和少量 specialist。

结语

从这几篇工程材料来看，智能体系统当前的变化，不只是模型能力变强，也不只是 Agent 从多个变成一个。

更明显的变化是职责被重新分层：模型负责动态推理，Skills 负责流程知识，Tools 负责实时行动和硬前置条件，Knowledge Base 负责按需参考，Orchestrator 或 Harness 负责控制边界，Eval 负责验证系统是否真的完成了任务。

Single Agent Loop、Subagents、Skills、Handoffs、Router 和 Thin Orchestrator 因而不是一组等待决出胜负的方案。它们分别处理共享上下文、隔离、并行、状态转移、渐进加载和确定性控制等不同问题。

在这个意义上，智能体系统的演进更接近运行时系统的演进：能力越来越可组合，边界越来越明确，控制越来越可验证。真正需要回答的问题，也从“要不要多 Agent”，转向了“哪些决策可以交给模型，哪些边界必须由运行时固定，以及哪些能力应该沉淀为可复用资产”。

参考资料

• Diane Sarkis, “Building agents: When to fold subagents into your main agent loop”, Anthropic, 2026-10-25. 文章链接
• Sydney Runkle, “Choosing the Right Multi-Agent Architecture”, LangChain, 2026-10-25. 文章链接
• Plawan Rath, “The Thin Orchestrator: How We Made Our AI Agents More Reliable by Giving the Router Less to Do”, Meta Engineering, 2026-10-19. 文章链接
• “刚刚，Anthropic公开内部Sub-Agent+Loop最佳实践”，微信文章剪藏，2026-10-25。文章链接