AI 应用的多智能体编排与 A2A 通信协议工程 2026:从单体 LLM 到分布式智能体的统一装配
把 A2A 通信协议、agent card 能力发现、四种编排拓扑、MCP 适配层、跨厂商契约和黑板共享状态压成一个可执行的多智能体编排八件套,从分布式系统视角收口,给应用架构师一份从单体 LLM 迁移到分布式智能体的完整路径与选型清单。
约 44 分钟阅读13,075 字11 次阅读博主
把 A2A 通信协议、agent card 能力发现、四种编排拓扑、MCP 适配层、跨厂商契约和黑板共享状态压成一个可执行的多智能体编排八件套,从分布式系统视角收口,给应用架构师一份从单体 LLM 迁移到分布式智能体的完整路径与选型清单。
2025 年下半年开始，AI 应用的主流形态悄悄跨过了一道分水岭：单一 LLM + 单一 prompt + 单一工具的"单体智能"开始不能覆盖真实业务里绝大多数需要多人协作、多步推理、长期记忆、多模态输入的复合任务。研究者与工程师们意识到，把所有意图压进一个 context window 让一个模型同时做规划、检索、执行、校验、自反思，并不是能力不够，而是结构不对——这就像让一个程序员同时写代码、做 QA、写文档、修服务器、做客服，并不是程序员能力不足，而是把整个组织的职能压缩到了一个工位上。
真正的解法是分布式智能体（multi-agent orchestration）。把一个复杂任务拆解为若干角色边界清晰、能力契约明确、消息格式严格的智能体（agent），让它们像人类组织里的协作一样彼此通信、彼此约束、彼此校验。Google 在 2025 年 5 月开源的 A2A（Agent-to-Agent）协议、Anthropic 在 2024 年底推出的 MCP（Model Context Protocol）、IBM 在 2025 年主推的 ACP（Agent Communication Protocol），以及 LangChain / LlamaIndex / CrewAI / AutoGen 等编排框架的事实标准，背后共同指向的是同一件事：AI 应用的工程重心从"提示词工程"上移到"智能体工程"。
但这条维度上的实践极其碎片化——今天能搜到的几乎所有关于 multi-agent 的文章，要么停留在 LangChain LCEL 的链式编排，要么停留在 AutoGen 的双 agent 对话样板，要么直接拿 CrewAI 的 demo 套业务，几乎没有人系统讨论过：当你要把 5 个、10 个、20 个 agent 拼成一个稳定的生产系统时，通信协议怎么选？拓扑怎么挑？状态怎么共享？失败怎么兜底？跨厂商怎么可移植？ 这些才是从"单体 LLM 应用"上升到"分布式智能体应用"时真正决定系统能不能跑、跑得稳不稳、跑得便宜不便宜的工程问题。
本文试图给出一个面向 2026 年生产实践的统一装配视角。我们不重复任何一个框架的官方文档，不重复任何一篇博客的展开叙述，而是把所有编排层面的关键决策收口到四件事上：通信协议（A2A / MCP / ACP 各自适用什么场景）、编排拓扑（supervisor / mesh / hierarchical / blackboard 各自适合什么任务）、跨厂商可移植性（agent card 与契约如何让不同实现可以无成本替换）、失败与降级（编排层崩溃回流到单体 LLM 的代价）。最后落到一份给应用架构师的迁移清单。
在进入具体协议之前，我们先把多智能体系统抽象成一个形式化框架。一个生产可用的多智能体系统可以拆成四层：传输层（Channel）、协议层（Protocol）、编排层（Orchestrator）、状态层（State）。这四层在每一篇公开材料里的命名都不太一样，但工程上指代的对象高度一致。
图表加载中…
形式化上，把整个系统记作 ，其中 是 agent 集合， 是消息空间（message space）， 是拓扑（topology，agent 之间允许的连接子集）， 是协议（消息编码 + 状态机 + 失败语义）。绝大多数工程师在上手 multi-agent 时只关心 ——"我应该放几个 agent、每个 agent 干什么"——但生产事故的根因 80% 在 和 。
为什么编排层和状态层比 agent 本身重要？因为 agent 在工程意义上是一个"prompt + tools + memory + state machine"的封装，它本身的可调试性已经被 LangChain / LlamaIndex / CrewAI / AutoGen 等框架吸收得差不多了；但多个 agent 之间的通信拓扑、消息路由、状态共享、失败传播没有哪个框架能替你做决定——这是工程架构的范畴，不是工具的范畴。
更进一步，消息复杂度的下界与拓扑结构直接相关：在一个有 个 agent、 条边的拓扑里，每完成一次全图同步的消息数至少是 （消息去重后），而 supervisor 拓扑里每完成一次 broadcast 至少 。这看似小的常数差异，在 时差距是 4-5 倍 token 消耗与延迟。编排拓扑不是审美选择，是预算选择。
A2A（Agent-to-Agent）是 Google 在 2025 年 5 月开源的事实标准之一，目标是让不同厂商、不同语言、不同运行时的智能体可以彼此发现、彼此调用、彼此传上下文。它本质上是 JSON-RPC 2.0 的扩展，但在 agent 领域做了三层增强：能力发现（agent card）、任务状态机（task lifecycle）、多模态消息分块（artifact stream）。
第一层 agent card 是 A2A 协议最具辨识度的设计。每个 agent 在启动时通过 /.well-known/agent.json 暴露自己的能力契约——一段结构化 JSON 描述自己能做什么（skills）、接受什么输入（inputSchema）、产出什么输出（outputSchema）、依赖什么前置能力（dependencies）。这个设计看上去只是把 LangChain 的 agent.get_input_schema() 搬到了 HTTP 端点上，但真正改变了分布式 agent 的工程形态：编排器可以在不启动任何一个 agent 的情况下，通过读 agent card 完成全图规划。这是从"框架内嵌调度"到"网络协议级调度"的根本跃迁。
第二层 task lifecycle 把"调用"分解成了 submitted → working → input-required → completed | failed | canceled 六个状态。这看上去是把 HTTP 200/4xx/5xx 换了个名字，但它真正解决的是长任务状态共享——一个 supervisor agent 派发出去的任务可能要跑 30 秒到 30 分钟，agent 之间需要知道这个任务现在是在等用户输入、还是等子任务完成、还是已经失败。传统的 LLM function calling 协议（OpenAI function calling、Anthropic tool use）是没有 task 概念的——一次调用要么返回结果、要么抛错。
第三层 artifact stream 是 A2A 处理多模态输出的关键。一个 agent 可能在跑一个 5 分钟的研究任务，期间产出 50 个网页摘要、3 个图表、2 段引用、1 段最终答复——传统 function calling 协议要求"一次返回"，A2A 允许 agent 把这些分块作为 Artifact 流式推到共享存储（通常是 OSS / GCS / S3），其他 agent 通过 artifact://<task_id>/<part_id> 引用而不是直接把整段内容塞进自己的 context。这个设计看似小，但当 agent 之间互相传 10MB PDF 时它就是 OOM 与正常运行的差别。
下面是一段最小可运行的 A2A 调用骨架（Python + httpx），演示了如何发现一个远程 agent、提交一个任务、轮询状态、拉取 artifact：
import httpx
import asyncio
AGENT_CARD_URL = "http://research-agent.internal/.well-known/agent.json"
async def discover_agent(client: httpx.AsyncClient) -> dict:
r = await client.get(AGENT_CARD_URL)
r.raise_for_status()
card = r.json()
assert "skills" in card, "agent card missing skills"
return card
async def submit_task(client: httpx.AsyncClient, endpoint: str, payload: dict) -> str:
r = await client.post(
endpoint,
json={
"jsonrpc": "2.0",
"id": "task-1",
"method": "tasks/send",
"params": {"message": {"role": "user", "parts": [{"kind": "text", "text": payload["query"]}]}}
}
)
r.raise_for_status()
return r.json()["result"]["id"]
async def poll_task(client: httpx.AsyncClient, endpoint: str, task_id: str) -> dict:
while True:
r = await client.post(endpoint, json={
"jsonrpc": "2.0", "id": "poll", "method": "tasks/get",
"params": {"id": task_id}
})
r.raise_for_status()
state = r.json()["result"]["status"]["state"]
if state in {"completed", "failed", "canceled"}:
return r.json()["result"]
await asyncio.sleep(2)
这段代码里有四个值得注意的工程取舍：(1) discover_agent 必须先于任何任务派发，否则编排器在盲调；(2) submit_task 返回的是 task_id 不是 message_id，因为消息可能被拒收、可能被路由到队列、可能被合并；(3) 轮询间隔建议 2 秒起步指数退避，因为 agent 内部可能还要再调用 1-N 个子 agent；(4) 永远不要把 poll_task 的整个返回体塞进自己的 context，应该只取 artifacts 字段的引用，让下游 agent 按需加载。
MCP 与 A2A 是互补关系，不是替代关系。MCP（Model Context Protocol）解决的是"agent 如何使用工具"——它把工具的 schema、调用、返回都标准化了，但它默认假设调用方是一个 LLM；A2A 解决的是"agent 如何彼此通信"——它把发现、状态、artifact 都标准化了，但默认假设通信双方都不一定是 LLM。生产里通常的组合是：A2A 用于 agent 之间的编排通信，MCP 用于 agent 内部的工具调用。
编排拓扑（orchestration topology）是 multi-agent 系统最被低估的设计决策。它决定了消息怎么走、状态怎么存、失败怎么传、成本怎么算——但绝大多数公开材料只讨论最朴素的 supervisor 一种。我们系统拆解四种主流拓扑的工程取舍。
图表加载中…
supervisor 拓扑是最常见的入门形态：一个 LLM 担当 supervisor，根据任务决定"下一步派给谁"，所有 agent 只与 supervisor 通信。它的工程优势是单点决策容易调试——所有日志、所有 token 消耗、所有失败都汇聚到一个 supervisor 上，定位问题一目了然。它的工程代价是 supervisor 是整个系统的吞吐瓶颈与单点故障：所有消息都要走 supervisor，context window 与每 token 成本都被 supervisor 拉满，supervisor 一崩整个系统就崩。
图表加载中…
mesh 拓扑是 AutoGen 默认采用的形态：所有 agent 平等互联，任意两个 agent 可以直接通信。它的优势是没有单点瓶颈——消息可以走最短路径，理论上延迟最低、token 消耗最低。它的代价是调试地狱——当 10 个 agent 互相通信时，日志会爆炸到无法追溯消息来源，而且没有全局决策者意味着"谁负责最终产出"是个开放问题。生产里 mesh 拓扑只在很小的子图（3-5 个 agent、任务闭环短）里可用。
图表加载中…
hierarchical 拓扑是工业级多智能体的事实标准：顶层有一个战略 planner，下面有若干战术 planner，再下面是执行 worker。它的设计动机来自人类社会组织——把决策与执行分层，让每一层只关注自己抽象级别的目标。它的工程优势是职责清晰、可扩展性最强——加一个 worker 不影响顶层决策。它的代价是延迟最深——一个请求可能要走 3-4 层才能到达执行者，每层都可能再调用 LLM 做规划。
图表加载中…
blackboard 拓扑是历史最悠久的形态（HEARSAY-II 早在 1980 年代就用），近年被 Anthropic 的 tool use 工作流和 LangGraph 的 shared state 重新激活。它的核心思想是所有 agent 共享一个结构化状态空间（通常是 KV store 或 JSON 文档），每个 agent 监听状态变化并按职责更新自己关心的字段。它的优势是去中心化决策——任何 agent 都可以基于 blackboard 当前状态决定下一步做什么，没有 supervisor 这种单点。它的代价是一致性最难保证——多个 agent 同时写 blackboard 时谁赢？需要事务、回滚、版本号等额外工程。
实际生产中真正可用的拓扑往往是主干嵌套的：以 hierarchical 为主干（战略 → 战术 → 执行），在战术层用 supervisor（战术 planner 调度同层 3-5 个 worker），在 worker 层用 blackboard（多个 worker 协同写同一份中间产物）。这种3 层混合拓扑在 Anthropic、OpenAI、Google 的内部生产系统里都是默认形态，但没有任何一个框架帮你做这种混合——你需要自己拼，或者用 LangGraph 这种低层编排库自己写状态机。
消息复杂度的拓扑推导：在 mesh 拓扑里，完成一次"全员同步"的消息数下界是 （Kruskal 算法的下界）；在 supervisor 拓扑里是 （N 次 broadcast + N 次 response）；在 hierarchical 里是 （L 是层数）；在 blackboard 里是 但每条消息只写自己关心的字段。当 、 时，mesh 消耗是 supervisor 的 ~3.3 倍 token，hierarchical 是 supervisor 的 1.3 倍。但延迟维度相反——mesh 走最短路径延迟最低，hierarchical 走最长路径延迟最高。所以选拓扑本质是在 token 预算与延迟预算之间做 trade-off。
2025 年下半年开始，跨厂商 agent 可移植性从"理想"变成"刚需"。原因很简单：今天你用 OpenAI 的 GPT-5 + Anthropic 的 Claude 4.5 + Google 的 Gemini 2.5 拼一个 multi-agent 系统，明天可能因为价格、合规、能力变更要替换其中任何一个。如果你的 agent 系统是模型绑定的（每个 agent 的 prompt 都硬编码了对应厂商的 tool use 语法），替换成本是不可承受的。
MCP（Model Context Protocol）是工具可移植性的标准答案。MCP 在 2024 年 11 月由 Anthropic 开源，2025 年被 OpenAI、Google、Mistral、DeepSeek 等先后采纳，已经成为工具描述的事实标准。一个 MCP server 暴露的工具可以被任何兼容 MCP 的客户端（Claude Code、Cursor、Cline、OpenAI Agents SDK、Google ADK）调用，工具的实现完全黑盒化。MCP 适配层的工程意义在于：agent 不再需要为每个工具写 vendor-specific adapter，只需要接 MCP client 即可。
下面是 MCP 适配层在 multi-agent 系统里的典型位置：
图表加载中…
这张图里，3 个 agent 通过各自的 MCP client 接入 3 个共享的 MCP server（数据库、代码执行、搜索）。关键工程意义：换掉任何一个 agent 的实现（比如把 Agent C 从 GPT-5 换成 Claude 4.5），不需要改任何一个 MCP server；换掉任何一个 MCP server（比如把搜索从 Tavily 换成 Exa），不需要改任何一个 agent。MCP 是 multi-agent 系统的"USB 接口"。
agent card 标准化是 agent 可移植性的另一半。A2A 的 agent card 描述（技能、输入、输出、依赖）目前主要在 Google 生态里被广泛实现，但 Anthropic、OpenAI、Microsoft 在 2026 年都在向这个标准靠拢。工程上你需要做的是：把你自己的 agent 也按 agent card 暴露能力——即使你不打算让别人调用你，把能力契约显式化能让你自己的监控系统、版本管理系统、A/B 实验平台更可靠地消费 agent 的能力。
模型无关契约（model-agnostic contract）是第三个支柱。它指的是 agent 之间的消息格式应该不包含模型特定的字段——不要在消息里塞 tool_calls、tool_use_id、anthropic_version、openai_organization 这些 vendor-specific 字段。一旦你的消息流里出现 vendor-specific 字段，跨厂商迁移就会指数级变难。正确的做法是定义一个 internal protobuf 或 JSON schema，把所有 agent 的输入输出都约束在这个 schema 里，每个 agent 自己负责把 vendor-specific 字段适配进这个 schema。
具体落地有三件事要做：(1) 定义一个内部 schema：建议用 protobuf + buf 仓库管理，所有 agent 共享；(2) 每个 agent 写一个 vendor adapter：负责把 vendor 输出转成 internal schema、把 internal schema 转成 vendor 输入；(3) 用 MCP + agent card 做能力发现：编排器只看 schema 不看 vendor，要替换就替换 adapter 不替换 agent。这三件事加起来大约 1-2 周工程量，但换来的可移植性可以让你的 agent 系统跨过未来 3-5 年的模型迭代。
把上面四节收口到同一个工程视角：当我们说"multi-agent orchestration"时，工程上真正在解决的是分布式系统的全部经典问题——消息传递、状态共享、容错、一致性、可观测性——只是把这些问题搬到了 LLM 这个新型的、不可预测的、有 context window 限制的执行单元上。任何分布式系统的设计模式——消息队列、最终一致性、CAP 定理、断路器、限流、灰度——都直接适用于 multi-agent 编排。
从这个视角看，所有 multi-agent 框架（LangChain、LlamaIndex、CrewAI、AutoGen、LangGraph、Anthropic Bedrock Agents、Google ADK、OpenAI Agents SDK）做的事其实是同一件事：把分布式系统模式封装成 LLM 友好的 API。它们的差异不在于"谁更聪明"，而在于哪个分布式模式被作为一等公民。LangChain 默认是链式（chaining）；CrewAI 默认是角色扮演（role-playing）；AutoGen 默认是对话（conversation）；LangGraph 默认是状态机（state machine）；Anthropic Bedrock 默认是工具调用（tool use）；Google ADK 默认是 A2A 协议（agent-to-agent）。
生产里选框架的核心问题不是"哪个最先进"，而是"哪个默认假设最贴合你的业务"。如果你的业务是文档处理流水线（解析 → 抽取 → 摘要 → 校对），LangGraph 的状态机是最贴的；如果你的业务是研究助手（搜索 → 综合 → 写作 → 反思），AutoGen 的对话模式是最贴的；如果你的业务是企业 SaaS 的 AI 功能（用户输入 → 工具调用 → 返回），Anthropic / OpenAI 的 tool use 模式是最贴的。
第二个统一视角是失败语义的统一。分布式系统的失败模式（节点崩溃、网络分区、超时、数据丢失、状态不一致）在 multi-agent 系统里全部存在，只是表现更隐蔽——agent 的失败不是"返回 None"，而是"返回了一段看起来合理但实际错误的内容"。这就是为什么 multi-agent 系统的可观测性比传统微服务更难——你不能只看 HTTP 状态码，必须看 agent 的语义正确性。
第三个统一视角是预算的统一。所有 agent 的 LLM 调用都共享同一个预算池（token cost、latency budget、context window），编排器必须做预算分配——哪些任务值得花 10K token 精调，哪些任务 1K token 草稿就够。这与传统微服务的资源调度（CPU、内存、IO）问题完全同构。
第四个统一视角是版本化的统一。当你的 agent 系统里有 10 个 agent、20 个 tool、5 个 LLM 端点，任何一个升级都可能引发级联失败。生产里 multi-agent 系统的版本管理是多维度的：agent 版本、prompt 版本、tool 版本、LLM 版本、协议版本——任何一个维度的不一致都可能让整个系统行为漂移。这与传统微服务的版本管理（服务版本、依赖版本、配置版本）也完全同构。
理解了这些统一视角，就理解了为什么 multi-agent orchestration 不是"再调一个框架"能搞定的——它本质上是用 LLM 作为执行单元的分布式系统工程问题。所有分布式系统的最佳实践都适用，所有分布式系统的坑也都会踩。
把上面六节的工程结论落到 8 条可在下一个 sprint 里落地的清单。这 8 条按实施顺序排列，越靠前越紧急：
图表加载中…
1. 盘点 agent 清单与角色边界。把你的 multi-agent 系统里所有 agent 列成一张表，每个 agent 写一行：name | role | input schema | output schema | tools | memory。这一步看似简单但 90% 的团队跳过了，结果是 agent 之间消息格式不一致、角色重叠、循环调用——所有混乱都从这一步的偷懒来。
2. 按业务需求选编排拓扑，不要默认 supervisor。新任务用 supervisor 跑 prototype，验证概念后立刻重构为 hierarchical + 战术 supervisor 混合拓扑。Mesh 拓扑只在 3-5 agent 子图里用，blackboard 拓扑只在"多 agent 协同写同一份产物"（如研究报告）时用。
3. 把每个 agent 按 A2A agent card 暴露。即使你只用内部网络、不对外暴露能力，agent card 也是 agent 自我描述的标准方式——监控系统、A/B 平台、能力发现服务都依赖它。一个 agent card 的最小骨架是：name / description / url / version / skills[] / inputSchema / outputSchema。
4. 把所有外部工具通过 MCP server 暴露，不要让 agent 直接调 vendor API。MCP server 让你可以随时替换底层实现而 agent 无感。一个常见反模式是让 agent 直接 requests.post("https://api.openai.com/...")——这会让 vendor 锁定永远断不开。
5. 定义 internal schema 并强制所有 agent 遵守。建议用 protobuf，所有 agent 通过 vendor adapter 转换。internal schema 至少包含：role / parts[] / tool_calls[] / metadata{trace_id, parent_task_id, budget} / version。version 字段必须存在，否则你无法做 agent 升级的灰度。
6. 每个 agent 写一个 vendor adapter，把 vendor-specific 字段（tool_use_id、tool_calls、anthropic_version 等）全部转成 internal schema。一个 adapter 通常是 200-500 行 Python 代码，对应一个 LLM 厂商。不要图省事让所有 agent 用同一个 prompt 模板——adapter 的价值就在于把模型特性吸收在 adapter 里。
7. 加失败兜底层，把 agent 失败回退到单体 LLM 调用。设计模式是 circuit breaker：检测到某类 agent 连续失败 N 次后，把后续同类任务直接走单体 LLM 的简化路径，并在 observability 系统里标记 degraded=true。这个兜底层不是"降级体验"——它本身就是一个工程产物，需要单独测试。
8. 上 multi-agent observability，至少包括：每条消息的 trace_id、每个 agent 的 token 消耗、每个 task 的状态机变化、每个 vendor 的失败率。推荐用 Langfuse / Helicone / Phoenix 这种 trace + cost + eval 一体化的工具，不要自己用 OTLP + Grafana 拼——multi-agent 的 trace 比传统微服务复杂一个量级，自建成本极高。
这 8 条清单不是"最佳实践的总结"，而是生产事故的复盘——每一个事故都对应一条没做的清单。如果你刚开始搭 multi-agent 系统，按这 8 条顺序做可以避免 90% 的常见坑。
承认局限是工程诚实的开始。Multi-agent orchestration 的统一装配视角有几个目前没有银弹答案的边界问题。
第一个边界：动态决策的开销本身。Supervisor 拓扑里 supervisor 的 LLM 调用本身就是开销——每一次"下一步派给谁"的决策要花 500-2000 token。在 mesh 拓扑里这个开销被分摊到每个 agent 自己的"我下一步要不要发消息"决策里，但累积开销反而更大。当你的业务里有大量"agent A 决策后等 agent B 决策"的串行链路时，编排开销可能占整个系统 token 消耗的 30-50%。这是个真实存在的工程代价，没有哪个框架能消除它——只有"用 heuristic 替代 LLM 决策"或"用更小模型做决策 LLM"两种折中。
第二个边界：状态共享的语义一致性。Blackboard 拓扑里多个 agent 写共享状态时，"谁先写谁后写"决定了最终产物——但 LLM 的执行时间不确定、agent 内部可能并发执行、agent 之间可能存在隐式数据依赖。Blackboard 的一致性问题比传统分布式数据库的 CAP 更难，因为 LLM 输出的"状态变更"不是结构化事务，而是一段非结构化文本。生产里的折中是：把 blackboard 的字段拆成"事实字段"（agent 写完就是最终值）和"建议字段"（agent 写完是待合并的候选），分别用不同的一致性策略。
第三个边界：跨厂商的能力漂移。即使你做了 MCP + agent card + internal schema，不同 LLM 厂商对相同 schema 的执行仍然存在不可预测的差异——同样的 prompt 给 GPT-5 和 Claude 4.5，输出结构、调用顺序、推理路径可能完全不同。这就是为什么 multi-agent 系统的"模型无关契约"不是"换模型就行"——你需要为每个新模型重新校准 agent 的 input/output 边界条件。这不是工程缺陷，是 LLM 这个执行单元的本质属性。
第四个边界：调试的可解释性。当一个 multi-agent 系统出错（比如最终产出的报告引用错了事实），要回溯"是哪个 agent 哪一步引入了错误"是非常困难的——尤其是 hierarchical 拓扑里错误可能要穿过 3-4 层才暴露。生产里通常用 trace + replay（Langfuse / Helicone 都有这个能力），但完全确定性的根因分析仍然不可能，只能做到"高度怀疑某个 agent 的某次输出"。这是 multi-agent 系统相对于单体 LLM 应用的根本性可调试性损失——你需要接受这种损失，换来的是更高的能力上限。
第五个边界：合规与审计的复杂性。当你的 agent 系统里有 5 个 LLM 厂商、3 个数据源、10 个 agent 时，每个请求可能穿过所有这些组件产生日志——合规审计（GDPR、SOC2、HIPAA、CCPA）需要追踪每一个数据元素的完整路径，这比单体 LLM 应用的"一个 prompt 一个 response"复杂一个量级。目前没有完美的开源方案，需要自建或购买企业级 audit pipeline。
这五个边界不是"今天解决明天就能消失"的——它们是 multi-agent 工程本身的固有 trade-off。接受这些 trade-off、把它纳入架构设计、而不是等到生产事故才发现，才是工程上成熟的标志。
最后给正在考虑从单体 LLM 应用迁移到 multi-agent 系统的应用架构师一份迁移路径建议。这份建议假设你已经在生产环境跑过单体 LLM 应用（不是从零起步），目标是帮你评估"什么时候该迁移、迁移到哪种形态、迁移成本多大"。
图表加载中…
第一阶段：评估是否需要迁移。如果你的业务能用单体 LLM 解决（任务有清晰 prompt、有 1-3 个工具调用、无长期状态），不要为了"跟上 multi-agent 趋势"而迁移。Multi-agent 的工程复杂度比单体 LLM 高 5-10 倍，只有业务收益明确超过复杂度成本时才迁移。判断标准：单体 LLM 应用在 production 已经触到 context window 瓶颈、工具调用链超过 5 步、长对话历史让 prompt 失焦——这三个症状出现任意一个就开始认真考虑迁移。
第二阶段：用 supervisor 拓扑做 prototype。从单体 LLM 应用"长出来"一个 supervisor：保留现有单体 LLM 作为 leaf agent，加一个 supervisor 做任务分发。这一步工程量小（1-2 周），但能立刻验证 multi-agent 是否真的解决你的问题。Prototype 阶段不要优化——能跑通、能演示、能说服团队就够了。
第三阶段：识别需要持久化的状态。如果你的业务有跨 session 的状态（比如用户的偏好、历史对话、领域知识），加一个 session store（Redis / Postgres / KV）。这一阶段 supervisor 还是单层，但 leaf agent 可以共享 session 里的状态。工程量 2-4 周。
第四阶段：识别是否需要 blackboard。如果多个 agent 协同产出同一份文档（比如研究报告、代码审查报告、设计文档），加 blackboard 共享状态。这一阶段 supervisor 保留作为入口，leaf agent 之间通过 blackboard 共享中间产物。工程量 3-6 周。
第五阶段：升级为 hierarchical 混合拓扑。当 supervisor 自己也成为瓶颈（context window 超限、决策延迟过长），把 supervisor 拆成战略 planner + 战术 planner + worker 三层。这一阶段你开始需要 LangGraph 这种低层编排库，或者用 Temporal 这种工作流引擎自建状态机。工程量 6-12 周。
第六阶段：跨厂商可移植性。当你开始认真考虑"明年模型换了能不能不重写"时，加 MCP + agent card + internal schema + vendor adapter。这一阶段是架构成熟度的跃迁，不是工程量问题——它要求团队对协议有共识、对 schema 有纪律、对 vendor adapter 有持续维护投入。一次性投入 4-8 周，之后每加一个新 vendor 1-2 周。
第七阶段：合规与可观测性。当你的 multi-agent 系统开始承载企业级 SLA 时，最后一步是合规与可观测性——trace、audit、cost monitoring、quality eval、incident response。这一阶段往往不是技术问题而是组织流程问题。一次性投入 8-12 周建立基础设施，之后持续投入 1-2 人维护。
最终选型清单（按业务规模从小到大）：(1) 单体 LLM + 1-2 工具调用——直接用 OpenAI / Anthropic / Google 的 SDK；(2) supervisor + 3-5 agent——用 LangGraph 或 CrewAI；(3) hierarchical 混合拓扑——LangGraph + Temporal / 自建状态机；(4) 完整 multi-agent 装配——LangGraph + MCP + 自建 agent card registry + Langfuse observability；(5) 企业级 multi-agent platform——以上全部 + 内部 SDK + 合规审计 + A/B 平台。
把 A2A 通信协议、agent card 能力发现、四种编排拓扑、MCP 适配层、跨厂商契约和黑板共享状态压成一个可执行的多智能体编排八件套，让 AI 应用的"协作"层不再是不能复现的暗盒——这是 2026 年从单体 LLM 应用上升到分布式智能体应用时，工程团队必须集体跨过的一道分水岭。
Conversation
0 条