# Runtime 架构与多 Agent 系统：从工具栈分层到生产级编排

## 概述

随着 agent 系统从实验室走向生产环境，行业亟需回答一系列架构问题：agent 工具栈应该如何分层？多 agent 协作的最佳模式是什么？token 成本如何权衡？SDK 应该为开发者提供什么级别的抽象？本文综合三篇来自 LangChain 和 Anthropic 的技术文章，系统梳理 Framework / Runtime / Harness 三层分类法、orchestrator-worker 多 agent 架构的生产实践、token 经济学的残酷现实、以及 Agent SDK 和 MCP 生态所代表的标准化趋势。

## Framework / Runtime / Harness 三层分类法

LangChain 在一篇简短但影响深远的文章中，为混乱的 agent 工具生态提出了清晰的三层分类 [^34]：

**Agent Framework**（如 LangChain、Vercel AI SDK、CrewAI、OpenAI Agents SDK、Google ADK）提供心智模型和抽象，降低入门门槛，标准化开发方法。Framework 的价值在于让开发者不必从零开始理解 agent 系统的运作方式——它提供了"如何思考 agent"的认知框架。但其代价是抽象可能遮蔽实现细节，当需要深度定制时开发者可能需要"打破"抽象层。

**Agent Runtime**（如 LangGraph、Temporal、Inngest）聚焦于生产部署的基础设施能力：durable execution（持久执行，确保 agent 在系统故障后可恢复）、streaming support（流式支持）、human-in-the-loop 能力和 persistence 机制。Runtime 比 framework 更底层——LangChain 1.0 本身就构建在 LangGraph 之上，体现了 framework 建立在 runtime 之上的架构关系。对于生产环境而言，runtime 层的 durable execution 是 agent 可靠性的基石 [^34]。

**Agent Harness**（如 DeepAgents、Claude Code）是最高层抽象，采用"batteries included"方法，提供默认 prompt、预设工具处理、规划工具和文件系统访问等。LangChain 将 harness 描述为"通用版的 Claude Code" [^34]。Harness 的本质是将领域最佳实践固化为开箱即用的系统——LangChain 的 harness engineering 实践已经证明，仅优化 harness 层就能将 benchmark 排名从第 30 名提升至第 5 名 [^32]。

这一分类法的实用意义在于帮助技术管理者精确定位需求：快速原型可用 harness，定制化需求用 framework，生产可靠性投资 runtime。三者并非互斥，而是构成了由底向上的抽象光谱。

## 编排者-工作者（Orchestrator-Worker）架构

Anthropic 的多 agent 研究系统提供了 orchestrator-worker 模式的第一手生产经验 [^35]。其架构清晰明了：一个 **lead agent**（Claude Opus 4）分析查询并制定搜索策略，多个 **subagent**（Claude Sonnet 4）并行执行不同方面的搜索任务，结果汇聚回 lead agent 进行综合分析。

这一架构的关键设计决策包括：

**模型分层**：lead agent 使用更强大的 Opus 4 配合 planning 模式的 extended thinking，负责策略制定和结果综合；subagent 使用更经济的 Sonnet 4 配合 interleaved thinking，负责具体执行。这种分层既优化了成本，也符合任务的内在复杂度差异 [^35]。

**独立 context window**：每个 agent 拥有独立的 context window，避免了单 agent 架构中 context 长度的瓶颈。这意味着多 agent 系统的有效 context 容量是 N 倍于单 agent——但代价是 agent 之间的信息共享只能通过显式的消息传递 [^35]。

**Effort Calibration（努力校准）**：根据任务复杂度动态分配资源。简单事实查找使用 1 个 agent 配 3-10 次工具调用，复杂研究使用 10+ 个 subagent 并分配不同职责。这种动态资源分配避免了简单任务的过度投入和复杂任务的资源不足 [^35]。

性能数据令人印象深刻：在需要广度优先并行探索的查询上，多 agent 系统相比单 agent Opus 4 **提升了 90.2%** [^35]。但 Anthropic 坦诚指出，多 agent 系统**不适合**需要大量共享 context 或高度相互依赖的任务——在这些场景中，agent 之间的通信开销可能抵消并行带来的收益。

## Token 经济学：15× 开销的残酷现实

Anthropic 的多 agent 研究系统提供了行业内罕见的 token 消耗数据 [^35]：

- 单 agent 对话：约 1x token 消耗（基准线）
- 单 agent 研究：约 4x token 消耗
- 多 agent 研究：约 **15x** token 消耗

更关键的发现是：**token 使用量本身解释了 BrowseComp evaluation 中 80% 的性能方差**。这一数据揭示了一个深层次的行业问题——许多多 agent 架构声称的性能优势，可能主要来自于更多的 token 投入（即更多的"思考时间"），而非架构本身的创新 [^35]。

这意味着在评估多 agent 系统的价值时，必须引入**单位 token 产出**作为核心指标。一个消耗 15 倍 token 但性能提升 90% 的系统，其 token 效率实际上是下降的。多 agent 架构的经济合理性取决于任务价值——对于高价值的研究任务，15 倍 token 成本可能完全合理；对于日常的信息查询，则显然不经济。

Anthropic 团队还观察到一个实用的 **effort calibration** 规则 [^35]：不是所有查询都需要多 agent 的全力投入。通过根据查询复杂度动态调整 agent 数量和调用次数，可以在性能和成本之间找到更优的平衡点。这与 LangChain 在 harness engineering 中发现的 reasoning sandwich 策略 [^32] 异曲同工——关键不是"更多计算"，而是"在正确的地方分配计算资源"。

## Agent SDK 设计理念：程序员工具即 Agent 工具

Anthropic 的 Claude Agent SDK（从 Claude Code SDK 更名而来）代表了一种独特的 agent 工具设计哲学：**赋予 agent 与人类专业人员相同的工具** [^36]。

传统 agent framework 倾向于为 agent 设计专门的抽象层——定制化的 API 调用接口、结构化的动作空间、预定义的工具描述。Claude Agent SDK 则反其道而行之，让 agent 直接访问 bash 命令、文件系统和代码执行环境。其设计逻辑是：如果一个人类开发者通过终端命令和代码编辑来完成任务，那么 agent 也应该使用相同的工具链。

SDK 的核心架构是一个四阶段反馈循环 [^36]：

1. **Gather Context**：通过 agentic search（文件系统导航）、semantic search、subagent 并行任务收集信息，支持长时间运行操作的自动 context compaction
2. **Take Action**：通过 custom tools、bash scripting、code generation 和 MCP 集成执行动作
3. **Verify Work**：通过 rules-based feedback（如 linting）、visual feedback 和 LLM-as-judge 验证结果
4. **Iterate**：基于验证结果迭代改进

将 Verify Work 作为核心循环的必需环节而非可选步骤，这一设计决策与 LangChain 的 Build-and-Self-Verify Loop 发现高度一致 [^32]——agent 最常见的失败模式恰恰是跳过验证。

从 Code SDK 到 Agent SDK 的更名本身也传递了一个重要信号：编码 agent 的核心能力——文件系统访问、终端命令、迭代执行——实际上是**通用 agent 能力的基础**。无论是金融分析、客服还是研究场景，agent 都需要读写文件、执行命令和迭代验证 [^36]。

## MCP 生态系统的架构标准化趋势

Model Context Protocol（MCP）作为 Claude Agent SDK 的核心集成协议 [^36]，代表了 agent 生态标准化的重要趋势。MCP 为连接外部服务提供标准化接口，意味着开发者可以通过统一协议扩展 agent 的能力边界，而无需为每个外部服务编写定制集成代码。

MCP 的标准化价值体现在三个层面：

**工具发现与描述**：MCP 提供了工具能力的标准化描述格式，使得 agent 能够自动发现和理解可用工具。这与 OpenAI 的 SKILL.md 文件 [^27] 以及 Anthropic 多 agent 系统中 tool-testing agent 的实践 [^35] 形成了呼应——工具描述的质量直接影响 agent 的工具选择正确性。

**跨 framework 互操作**：在 LangChain 的三层分类中 [^34]，MCP 有潜力成为连接不同 framework 和 runtime 的通用接口层。无论底层使用 LangGraph、Temporal 还是其他 runtime，MCP 服务端的实现可以保持一致。

**生态系统效应**：随着更多工具和服务支持 MCP 协议，agent 的能力边界将不再受限于单个 SDK 或 framework 的内置工具集。这类似于 REST API 对 Web 服务生态的标准化效应——一旦协议成为行业共识，生态增长将呈指数级 [^36]。

Anthropic 多 agent 研究系统中 tool-testing agent 的实践 [^35]——用一个专门的 agent 测试工具匹配质量，将后续任务完成率提升 40%——暗示了 MCP 生态成熟后的一种可能模式：agent 不仅使用工具，还能评估和选择工具。

## 并行化对研究时间的 90% 压缩效果

Anthropic 多 agent 研究系统最引人注目的性能数据之一是：在需要广度优先并行探索的查询上，相比单 agent 系统实现了 **90.2% 的性能提升** [^35]。这一提升的核心驱动力是**并行化**——多个 subagent 同时探索问题的不同方面，而非单个 agent 串行处理。

并行化的优势在特定任务类型上尤为显著：当研究问题可以分解为多个相对独立的子问题时（如"从不同来源验证某个事实"、"分别调研技术 A 和技术 B 的优劣"），并行执行可以将墙钟时间压缩到接近单个最慢子任务的时长。但这一优势有明确的边界条件——高度依赖共享 context 或需要串行推理链的任务并不适合并行化 [^35]。

从架构角度看，并行化的实现依赖于 orchestrator-worker 模式的两个关键特性：（1）lead agent 具备将问题分解为可并行子任务的能力；（2）每个 subagent 拥有独立的 context window，不会因共享 context 而产生竞争 [^35]。这与 runtime 层 [^34] 提供的并发执行能力形成了上下层的配合。

值得注意的是，90% 的性能提升伴随着 15 倍的 token 消耗。但在研究场景中，时间往往比 token 成本更有价值——一个需要人类研究员数小时完成的文献调研，在几分钟内以更高质量完成，其经济账是显然划算的。

## 跨文章洞见

**共识模式：验证是核心环节而非可选步骤。** Claude Agent SDK 将 Verify Work 嵌入四阶段核心循环 [^36]，LangChain 的 harness engineering 证明 self-verification 是最大的单项改进 [^32]，Anthropic 多 agent 系统也将结果验证作为 lead agent 的核心职责 [^35]。行业正在收敛到一个共识：agent 的验证能力与生成能力同等重要。

**共识模式：抽象层次的选择是核心架构决策。** LangChain 的三层分类 [^34] 和 Claude Agent SDK 的设计哲学 [^36] 从不同角度阐明了同一个问题——过高的抽象牺牲控制力，过低的抽象增加开发成本。最佳选择取决于团队的定制化需求和生产可靠性要求。

**张力点：专用工具 vs. 通用工具。** 传统 agent framework 为 agent 设计专门的工具接口，而 Claude Agent SDK 主张让 agent 使用人类的工具 [^36]。这两种哲学的长期竞争将决定 agent 工具生态的演化方向。MCP 作为标准化协议，可能在两者之间架起桥梁。

**隐性挑战：多 agent 系统的可观测性。** Anthropic 坦言需要"监控决策模式和交互结构而非对话内容" [^35] 来实现隐私安全的可观测性。当系统从单 agent 扩展到多 agent，调试和监控的复杂度不是线性增长而是组合爆炸。Rainbow deployment（彩虹部署）这种 agent 独有的部署策略的出现 [^35]，预示着 agent ops 将成为一个独立的工程领域。

**经济学张力：token 成本 vs. 任务价值。** 15 倍 token 开销 [^35] 意味着多 agent 系统的经济合理性高度依赖任务价值。这将自然导致 agent 架构的分化——高价值任务使用多 agent 深度研究，低价值任务使用单 agent 快速响应，effort calibration 成为必备的系统能力。

## 对技术管理者的建议

1. **用三层分类法审计现有 agent 技术栈**。明确团队在 framework、runtime 和 harness 各层的技术选型，识别薄弱环节。特别关注 runtime 层的 durable execution 能力——这是生产可靠性的基石 [^34]。

2. **多 agent 架构的采用需要明确的经济论证**。15 倍 token 开销意味着只有高价值任务才能证明多 agent 系统的合理性。建立 token 成本监控和单位产出指标，避免"为多 agent 而多 agent" [^35]。

3. **实现 effort calibration 机制**。不是所有请求都需要多 agent 的全力投入。根据查询复杂度动态调整 agent 数量和计算资源，是控制成本的关键杠杆 [^35]。

4. **优先投资 harness 工程而非盲目追求更强的模型**。LangChain 的实践证明 harness 优化的 ROI 可以非常高 [^32]。Self-verification middleware、context injection 和 loop detection 是三个高优先级方向。

5. **关注 MCP 生态的发展**。MCP 作为标准化的工具连接协议，有潜力大幅降低 agent 与外部服务集成的开发和维护成本。在工具接口设计中优先考虑 MCP 兼容性 [^36]。

6. **为多 agent 系统建立专门的运维能力**。Rainbow deployment、决策模式监控、error compounding 检测——这些是多 agent 系统独有的运维挑战，需要专门的工具和流程 [^35]。

7. **在 agent 工具设计中遵循"程序员工具即 agent 工具"原则**。优先让 agent 使用现有的开发者工具链（终端、文件系统、代码执行），而非为 agent 设计全新的抽象层。这降低了工具开发成本，也使 agent 的行为对人类开发者更可理解 [^36]。

8. **将并行化作为性能优化的首选策略**。对于可分解的研究和分析任务，orchestrator-worker 模式的并行化效果远超单 agent 的推理优化。但要明确识别不适合并行化的任务类型（高度串行依赖、共享 context 密集型） [^35]。

## 引用来源

- [^27]: [Testing Agent Skills Systematically with Evals (OpenAI)](../notes/27-openai-eval-skills.md)
- [^32]: [Improving Deep Agents with Harness Engineering (LangChain)](../notes/32-langchain-improving-with-harness.md)
- [^34]: [Agent Frameworks, Runtimes, and Harnesses (LangChain)](../notes/34-langchain-frameworks-runtimes-harnesses.md)
- [^35]: [How We Built Our Multi-Agent Research System (Anthropic)](../notes/35-anthropic-multi-agent-research.md)
- [^36]: [Building Agents with the Claude Agent SDK (Anthropic)](../notes/36-anthropic-claude-agent-sdk.md)