AI Agent 平台搭建：MCP vs A2A 协议选型实战
2026年企业搭建AI Agent平台面临协议选型第一关：MCP还是A2A？本文从协议本质到Dify/Coze/LangGraph/CrewAI四大平台横评，附带金融客户真实选型复盘与MCP端点过多导致延迟爆炸的实战教训。
AI Agent 平台搭建：MCP vs A2A 协议选型与 2026 平台横评
2026 年上半年，我们团队为一家金融客户搭建内部智能体平台时，第一关不是选大模型、不是选框架，而是两个协议的取舍：Anthropic 推的 MCP（Model Context Protocol）和 Google 推的 A2A（Agent-to-Agent）。两套规范定位不同、解决的问题不同，但市面上把它们放一起对比的文章很少——大多数只讲前者，对后者一笔带过。这篇把两个协议的工程本质、平台配套、以及我们踩过的坑一次性讲清楚。
模型上下文协议（MCP）：工具调用的「USB-C」
这套规范由 Anthropic 于 2024 年底开源，2026 年已成为 AI 应用接入外部系统的事实标准。官方定位很直白："像 USB-C 一样标准化 AI 与外部系统的连接"（来源）。它解决的是一类具体问题——LLM 需要调用数据库、文件系统、API、搜索引擎时，过去每个工具都要单独写适配层，该协议统一了这个过程。
核心抽象只有三层：Tools（可调用的功能，如查库）、Resources（可读取的上下文，如文档内容）、Prompts（预定义提示模板）。通过 JSON-RPC 2.0 暴露给 LLM 客户端。Claude、ChatGPT、VS Code、Cursor 等主流 AI 工具已原生支持。我们在另一篇文章中详细拆解过 Safari MCP 端点如何让浏览器自主调试，可见这套规范在终端工具场景的渗透速度。
实际工程中接入成本不高。我们在 LangChain 里集成一个端点只需约 30 行配置：定义 transport（stdio 或 SSE），声明 tools/resources 列表，挂到执行器即可。AutoGen 路径类似——社区已有 autogen-ext[mcp] 扩展。但成本低不意味没坑，第五节细讲。
A2A：智能体之间的「通用语言」
这套规范由 Google 在 2025 年开源，star 数半年冲到 24.7K（来源）。定位和前一套完全不同：前者解决「模型怎么调工具」，A2A 解决「智能体之间怎么通信协作」。
核心机制：每个服务节点对外暴露一张 能力卡片（Agent Card）——一份 JSON 描述文件，列出自身能力、支持的交互模式（文本/表单/媒体）、服务端点。其他节点读取卡片发现对方，以 JSON-RPC 2.0 over HTTP(S) 发起任务委托，结果通过 SSE（Server-Sent Events） 流式回传。全程不暴露内部状态、记忆或工具实现——Google 称之为「不透明协作」。
在其 README 中，Google 明确写了：「A2A complements MCP by enabling agents to collaborate with each other」。不是替代，是互补：一套负责 AI ↔ 工具，一套负责节点 ↔ 节点。2026 年主流架构趋势是叠加使用——通过前者调用企业内部系统，同时通过后者与外部专业服务（如法律合规、数据分析）通信。
DeepLearning.AI 已在 2026 年推出相关专项课程，由 Google Cloud 和 IBM Research 联合授课，涵盖服务暴露、跨框架（LangGraph/BeeAI/ADK）编排多智能体系统等实战内容。
2026 主流平台横向对比
协议选型定了之后，下一个问题是选平台。下面是我们实际评估过的四个选项，按真实使用体验打分（满分 5 分）。
| 维度 | Dify | Coze | LangGraph | CrewAI |
|---|---|---|---|---|
| 部署方式 | Cloud + 自部署 Docker 几分钟拉起 | 仅 Cloud（字节系） | 纯自部署 Python 库 | 纯自部署 Python 库 |
| MCP 兼容 | ✅ 原生集成 可作端点暴露 | ⚠️ 部分支持 插件市场有扩展 | ✅ 社区适配 langchain 适配器 | ⚠️ 社区插件 非一等公民 |
| A2A 兼容 | ❌ 暂无 | ❌ 暂无 | ⚠️ 需自行实现 Card + SSE | ❌ 暂无 |
| 多节点编排 | ⭐⭐⭐ 工作流式串行 | ⭐⭐⭐⭐ 可视化拖拽 | ⭐⭐⭐⭐⭐ 图式并行/条件分支 | ⭐⭐⭐⭐ 角色式任务委派 |
| 企业级权限 | ⭐⭐⭐⭐ RBAC + 工作空间 | ⭐⭐⭐ 团队协作 | ⭐⭐ 需自建 | ⭐ 无 |
| 成本 | 免费版可用 商业版按 seat | 免费 + 按 token | 开源免费 自担 infra 成本 | 开源免费 自担 infra 成本 |
| 适合场景 | 中大型企业 需要可视化 + 权限 | 个人/小团队 快速原型 | 有工程团队的企业 需要深度定制 | 角色明确的多节点 研究/实验场景 |
简单总结：Dify 胜在开箱即用——原生集成模型上下文协议、Docker 几分钟部署、工作空间+RBAC 权限体系完善（官方文档）。Coze 适合轻量级原型但企业级能力弱。LangGraph 灵活度最高但需要较强的工程能力。CrewAI 在角色式多节点场景有独特优势，但协议兼容滞后。
金融客户选型复盘：为什么从 Dify 切到自研 LangGraph
2026 年 Q1，我们为一家金融行业客户搭建内部智能体平台。初始选型是 Dify Cloud，理由很充分：一周内上线、可视化工作流降低业务部门使用门槛、内置 RBAC 满足合规要求。但三个月后切到了基于 LangGraph 的自研架构。PoC 跑通只是开始——真正的工程挑战在生产化部署阶段才暴露，原因有三：
第一，多节点通信受限。该客户的业务场景涉及 5 个专业模块——风控、合规、客服、数据分析、文档处理——需要频繁互调。Dify 的工作流模型本质串行，模块 A 的输出→模块 B 的输入，但我们要的是：风控审核时实时调合规模块的某个检查项、同时客服并行处理用户请求。这在 Dify 里只能「工作流嵌套」勉强模拟，维护成本极高。切到 LangGraph 后，用 StateGraph 多节点条件分支 + 并行执行，两天就搭出了 5 个模块的协作拓扑。
第二，跨服务通信需求。客户有多个外部合规数据源提供商，每个都有自己的 AI 服务。理想形态是内部合规模块通过 A2A 发现外部服务、发起任务、接收流式结果。Dify 不支持这套规范，我们只能在 LangGraph 中自实现 Card + SSE 通道来承载交互。多写了约 800 行代码，但换来完全可控的通信安全层——金融场景下，模块间传什么、不传什么，必须代码层面硬控制。
第三，工具选择延迟问题。这是压垮 Dify 的最后一根稻草——下一节展开。
反面教训：工具端点过多导致延迟从 200ms 飙到 3s
切到 LangGraph 后，我们犯了一个典型工程错误。一开始给主控模块挂了 17 个工具端点——数据库查询、文件检索、OCR、邮件发送、SQL 执行、内部 API 网关……每个端点暴露 3-20 个 tool，主控每次决策前要从总共 140+ 个 tool 里做选择。
结果：单次选择延迟从约 200ms 飙升到 3 秒以上。不是协议本身慢——JSON-RPC 调用都在 50ms 以内——而是 LLM 做 function calling 时，prompt 中塞入 140+ 个 tool schema 导致上下文膨胀。以 GPT-4o 为例，每个 tool 的 JSON schema 平均约 400 token，140 个 × 400 = 56,000 token 的纯描述占用，接近 128K 模型窗口的 43%。还没算 system prompt 和对话历史。
解决方案分三步走：
- 按场景拆分模块——不是一个大而全的主控挂所有 tool，而是 5 个专职模块各挂 3-5 个端点。每个模块的候选从 140+ 降到 15-25 个。
- 引入 tool router——在做 function calling 之前，先过一个轻量路由层（关键词匹配 + embedding 相似度），把候选从 25 再压到 5-8 个。
- 端点侧做 tool 分组——不在一启动时全量暴露，而是按 namespace 分组（
db:query、db:write、file:read），先选 namespace 再选具体 tool，进一步降低 token 开销。
三步下来，选择延迟回到 180-350ms 区间。教训很直白：接入成本低，但治理成本随端点数量线性增长。超过 5 个工具端点就必须上 routing 策略，否则延迟会吃掉整个系统的可用性。
常见问题
MCP 和 A2A 到底选哪个？
不是二选一，是先后顺序。如果 AI 应用需要调企业内部工具（数据库、API、文件系统）→ 先上模型上下文协议。如果需要和其他 AI 服务协作（尤其跨团队、跨公司的）→ 再叠加 A2A。二者的关系可以理解为：一个解决「手」的问题，一个解决「嘴」的问题。
Dify 和 LangGraph 怎么选？
3 个以内模块、不需要跨模块实时互调、团队没有专职 ML 工程师 → Dify。超过 3 个模块、需要并行/条件分支编排、有跨服务通信或深度定制需求 → LangGraph。也可以混用：Dify 做前端交互层，LangGraph 做后端编排引擎。
工具端点多少个算多？
没有绝对数字，但以我们的经验：单个模块挂超过 5 个端点就必须上 routing。实际瓶颈不在协议本身，而在 LLM function calling 的 token 开销。每多一个 tool schema，prompt 就多几百 token，延迟和成本同步上涨。
自研平台的最小工程团队配置？
基于 LangGraph + 模型上下文协议 + 自建 A2A 通道的栈：至少 1 个后端（Python/Go）+ 1 个前端 + 1 个 AI 工程师（懂 prompt engineering 和架构设计）。3 人团队 6-8 周可交付 MVP。如果涉及金融/医疗等强合规领域，建议额外留出安全审计和权限系统开发时间。
参考
如果你的团队正在评估智能体平台选型，或遇到了工具端点治理瓶颈，欢迎联系我们做一次免费技术评估——基于你的业务规模和场景给出具体建议。