AI 应用系统：编排层 — 从框架到协议

2026-05-31

网关层确保 token 稳定、便宜地进入系统。token 进来之后呢？如果只有一个 Agent 在做一件事，不需要编排层。但当有了多个不同专长的 Agent，需要它们协作完成一个任务时，编排层就出现了。

套用四层比喻：模型层是工厂，网关层是批发商，编排层是消费 token 的公司，终端层是卖给消费者的成品。这篇文章讨论怎么"开公司"——但 2026 年的答案跟两年前完全不同。

编排层的定义

回到第一篇的定义：编排层协调多个不同能力的 Agent，打通跨 Agent 上下文，把任务拆解后分发到对应 Agent 并汇聚结果。它不是单次模型调用，也不是固定步骤的链式调用。

如果把编排层比作一家公司，那么：

  • 每个 Agent 是公司里的一个员工，有各自的专长和工具
  • 任务拆解和分发是管理层——收到一个项目，判断需要哪些人、谁来做哪部分、结果怎么拼
  • 跨 Agent 上下文是公司的信息流通——不需要把同一个简报发给每个人重读一遍

范式转移：从框架到协议

过去两年编排层的讨论集中在"选哪个框架"上：写代码还是拖流程？图状态机还是角色扮演 Agent？但这个争论在 2026 年已经没有意义了。

框架是公司内部的 ERP 系统。协议是公司之间的贸易协定。

如果 Agent 只在公司内部协作，框架能搞定。但现实中，Agent 可能需要调用外部搜索引擎、读取第三方数据库、或者跟合作伙伴的 Agent 协同。框架管不到这些边界。协议可以。

2026 年的编排层正在被两个开放协议重新定义：MCP 和 A2A。它们回答了两个根本问题：

问题协议角色推出方
Agent 怎么接入外部工具和数据？MCPAgent ↔ 工具Anthropic
Agent 之间怎么互相通信？A2AAgent ↔ AgentGoogle，Linux Foundation

这两个协议构成了编排层的"通信基础设施"。跟框架不同，协议不绑定语言、不绑定厂商、不绑定 Agent 实现。

MCP：同一个插座

MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月开源的标准，它解决了 Agent 和外部世界之间的连接问题。Anthropic 把 MCP 比作"AI 的 USB-C"——不管什么设备，插同一个口就能通。

在 MCP 出现之前，每个模型提供商、每个工具都有各自的接入方式。Agent 想用 Google Drive 要用 Google 的 API，想用 GitHub 要用 GitHub 的 API，想查数据库要单独写连接。这个集成工作跟 Agent 的数量和工具的数量成倍增长。

MCP 做了一件事：把所有外部系统抽象成统一的 MCP Server 接口。Agent 作为 MCP Client 连接任意 MCP Server，不再关心背后的系统是什么。工具开发者只需要实现一次 MCP Server，所有 MCP 兼容的 Agent 都能直接调用。

市场上支持 MCP 的产品已经不是个位数了：Claude Desktop、ChatGPT、VS Code、Cursor、Replit、Sourcegraph 都内置了 MCP 客户端。MCP 的生态已经从"要不要用"进入了"怎么用"的阶段。

A2A：同一个电话线

如果说 MCP 解决了 Agent 和工具之间的连接，A2A（Agent-to-Agent Protocol）解决的是 Agent 和 Agent 之间的通信。

A2A 是 Google 发起、Linux Foundation 治理的开放协议，2026 年 5 月发布了 v1.0.1。核心设计思路是：Agent 之间不应该暴露内部状态、记忆、工具来实现协作。它们只需要知道对方的"能力卡片"（Agent Card）——类似公司里每个人对外声明自己擅长什么，而不需要知道用的是什么 IDE、配置了什么环境。

A2A 的机制：

  • Agent Card：每个 Agent 公开声明自己的能力、支持的交互方式（文本/表单/媒体）、连接信息
  • 任务生命周期管理：支持同步请求、流式响应（SSE）、异步推送通知。长任务不需要阻塞等待
  • 不透明性：Agent 之间不需要共享内部记忆、prompt、工具配置

举个例子：一个通过 Agent SDK 实现的写手 Agent 和另一个不同框架的审校 Agent，只要都实现了 A2A，就能在一个任务里协作——写手产出草稿后委托给审校，审校返回修改意见，写手再改。两者不需要知道对方"内部"怎么实现的。

A2A 已经提供 Python、Go、JavaScript、Java、.NET 五种语言的 SDK。任何框架只要能接入 A2A，就能跟其他 A2A 兼容的 Agent 合作。

协议和框架的关系

协议出现之后，框架的价值在哪里？

框架仍然是编排层的实现手段，但不再是锁定的入口。一个 Agent 可以基于框架 A 实现，另一个基于框架 B，第三个是自己写的纯 Python 循环——但只要都支持 A2A 和 MCP，它们就能在一个任务里协作。

这意味着三件事：

  • 框架变得可替换了。选框架 A 还是框架 B 变成一个局部决策，不影响全局架构。换框架不需要重写其他 Agent。
  • 编排的逻辑上移。不再是"在框架内部安排 Agent 的执行顺序"，而是"定义 Agent 之间如何通过 A2A 交换任务和结果"。编排从一个编码问题变成了一个协议设计问题。
  • 工具的接入成本趋近于零。新的外部能力以 MCP Server 形式接入，Agent 无需改动。

用公司的比喻来总结：以前每开一家子公司，都要自己设计组织架构软件。现在所有公司的员工都讲同一种"工作语言"（A2A），所有供应商都接同一个接口（MCP）。开公司变得更快，员工可以来自不同的人才市场，组织架构软件（框架）换成什么都行。

什么时候需要编排层

这个判断没有因为协议的出现而改变。回到 Anthropic 在 Building Effective Agents 中的核心建议：找到最简单的解决方案，只在必要时增加复杂度。

当满足以下三个条件时，才需要编排层：

  1. 多个不同专长的 Agent 需要协作（不是一个 Agent 反复调工具）
  2. 任务结构不可预知（不知道需要多少步、多少 Agent）
  3. 跨 Agent 需要共享上下文（不是一个接一个传递结果）

如果现在的场景是：

  • 单个 Agent 用多种工具完成任务 → 不需要编排层，终端层就够
  • 固定步骤的链式调用 → Anthropic 说的 prompt chaining 就够了
  • 按任务类型路由到不同模型 → 网关层的路由功能就够了

编排层不是架构进化的必然终点。大多数项目永远不需要它。

编排层的新陷阱

协议解决了一些老问题，也引入了一些新问题：

协议不等于编排。A2A 让 Agent 能互相通信，但它不帮助设计任务拆解逻辑。Agent 之间"能说话"和"能协作做事"是两回事。协议是基础设施，编排是业务逻辑，后者还是需要写。

协议版本管理。MCP 和 A2A 都在快速迭代。MCP 的规格和 SDK 每几个月就有破坏性变更。生产环境里如果三个 Agent 各自绑定了不同版本的协议，兼容性会是一个持续的工作。

过早采用。MCP 和 A2A 已经是事实标准，但并不是所有场景都需要它们。如果只有两个 Agent 在同一个 Python 进程里协作，直接调函数比走 A2A 网络协议更快、更简单。协议多了一层网络开销和序列化成本，在不需要跨进程、跨语言、跨系统的场景里反而是一种过度设计。

团队的学习成本。用框架的 API 写一个 Agent 门槛不高。但要理解 Agent Card 的设计、任务生命周期、A2A 的 push notification 机制、MCP Server 的实现，需要额外的学习。这笔投入在大规模、多团队协作时有回报，在小项目里不划算。

总结

编排层是四层架构里最容易被"建了不该建"的一层。2026 年，判断标准不是"我该用哪个框架"，而是：

  • 我真的有多个不同专长的 Agent 需要协作吗？
  • 如果是，这些 Agent 是否通过 MCP 接入工具、通过 A2A 互相通信？
  • 如果不是，我还不需要编排层。

参考

https://blog.logfun.xyz/blog/feed.xml