尧图网页设计 
最近在准备一门关于DeepAgents、MCP、A2A、Skills 的超级多智能体课程前后把文档翻了个底朝天也顺手在真实业务里搭了两套 Agent 集群做验证。越做越觉得2025 年以后的 Agent 开发真正拉开差距的不再是模型选型而是工程化的那张网MCP 解决工具接线Skills 解决经验沉淀A2A 解决 Agent 之间的协同DeepAgents 解决任务编排——这四个东西拼在一起才是完整的下一代 Agent 集群。这篇不写课程目录只把我在实操里验证过的思路、代码和掉进去过的坑记录下来给各位打算入坑多智能体、或者正在被“一个 Agent 写不出复杂业务”卡住的朋友做个参照。1. 先看清设计为什么偏偏是这四个词很多同学第一次看到“DeepAgents MCP A2A Skills”这套组合第一反应是名词堆砌MCP 我听过A2A 是什么Skills 和 Plugin 有什么区别DeepAgents 又是哪家的框架其实这四个词不是并列的四个工具而是从四个不同维度补全了一套 Agent 工程的拼图。理解清楚它们各自的职责后面的实践才不会跑偏。1.1 把四个词翻译成团队里的角色我习惯把他们类比成一个公司的项目组MCP 像是终端设备的物理接口标准。你不需要给每个外设单独设计针脚只要大家都遵守同一个协议插上就能用。MCP 就是 AI 应用层面的“外设总线”让大模型可以统一调用各种外部工具、数据源。Skills 则是老员工手里的工作手册。同一个技能比如写周报手册里包含了完整的步骤、模板、注意事项和调用工具的顺序。Agent 装上 Skill相当于新人拿到了老师傅的 SOP。A2A 是部门之间的对接流程。两个 Agent 分属不同系统时怎么发请求、怎么回结果、怎么处理中间状态需要一套双方都认可的通信规范。A2A 就是 Agent 对 Agent 的“商务谈判标准”。DeepAgents 则是项目经理。它负责把一个大目标拆成子任务分给不同的专家 Agent盯进度、收结果、做汇总。用一个具体场景串起来你让系统“每周一早上九点生成一份最新的行业竞品分析报告”。DeepAgents 先拆任务信息采集、数据分析、报告撰写。采集任务分给负责资讯的 Agent它通过 MCP 连接全网数据源数据分析 Agent 调用数据库查询 Skill按经验流程清洗数据最后写报告的 Agent 通过 A2A 向前面两个 Agent 要结果汇总成文档。全程由 DeepAgents 编排四个角色一个都不少。1.2 从“单兵模型”到“集群作战”的三个台阶大部分人接触 AI Agent第一步是单 Agent 加工具一个大模型配上搜索、计算器等工具。这个阶段的问题很典型——上下文越堆越长工具选择容易出错任务一旦跨多个领域就顾此失彼。第二个台阶是多 Agent也就是让几个 Agent 各管一摊。但这个阶段很快会碰到集成痛苦每个 Agent 的通信方式不一样、工具接法不一样。这时候如果没有 MCP 统一工具接口、没有 A2A 统一通信协议系统会变成一团乱麻。第三个台阶也就是这个课程想讲的“超级多智能体集群”核心就是标题里那三个能力词可编排所有 Agent 被一个调度中枢统一管理任务可以拆分、组合、回滚、重试。可互通工具层互通MCPAgent 层互通A2A。可扩展新增一个能力不需要改主系统放一个 Skill 或者接一个 MCP Server 就行。进入第三台阶之后系统的复杂度不再体现在“模型有多聪明”而是“整个团队能不能有序协作”——这也是为什么课程会特意把协议MCP/A2A和技能封装Skills放在一起讲。1.3 这套方案适合谁以及它的边界说句实在话不是所有场景都适合上多智能体集群。如果你只是做一个“帮用户查天气、写文案”的轻量助手单 Agent 完全够用强行上集群只会增加延迟和故障点。但如果你遇到的是以下情况这套组合拳会非常值业务跨越多个领域需要多个专家角色协同数据源和系统接口非常多且经常更换任务流程有明确阶段或者需要人机交接希望把团队的作业方法论沉淀成可以复用的资产。我个人的判断是2025 到 2026 年企业真正缺的不是“一个能写代码的 Agent”而是一套能把业务能力和 Agent 系统衔接起来的工程规范。MCP、Skills、A2A 这套体系恰好就是在补这块短板。2. MCP 与 Skills先把单个 Agent 的手脚和肌肉记忆造出来集群再大基础单元还是一个个干活的 Agent。所以第一步不是急着让 Agent 互相通信而是先把单个 Agent 的能力边界做扎实。这一章重点拆解 MCP 和 Skills 这两个最基础也最容易搞混的组件。2.1 MCP 的本质把工具从 prompt 里捞出来MCPModel Context Protocol是一个开放的、标准化的协议全称很直白——“模型上下文协议”。它解决的是大模型应用接入外部工具时“接口碎片化”的问题。在 MCP 出现之前每接一个外部系统你都得为模型写一遍工具描述、函数定义、参数 schema还要处理鉴权、错误信息、返回格式。不同平台各有各的格式迁移一次成本极高。MCP 的解法是定义了一套统一的客户端-服务器架构Host模型宿主比如 Claude Desktop、IDE 插件或者你自研的应用Client在 Host 内部负责和 MCP Server 建立连接Server把具体工具封装成标准接口暴露给 Client原语三件套Tools可执行动作、Resources可读取的数据、Prompts可复用的提示模板。有人问过MCP 既然是软件协议那硬件协议那个概念叫什么答案是硬件领域对应的是总线标准和接口规范比如 USB、HDMI、PCIe。软件协议管的是数据交换规则硬件协议管的是物理连接规则但底层逻辑一样——都是“定义两端达成共识的语言”。你可以把 MCP 理解成 AI 应用层的 USB-C只要设备支持这个标准插上就能用不用管另一端是什么牌子。实际开发里一个典型的 MCP Server 长这样from fastmcp import FastMCP # 创建服务声明服务名 mcp FastMCP(orders-server) mcp.tool() def get_order(order_id: int) - dict: 查询订单基本信息返回订单状态与金额 # 内部可以接数据库、第三方API全部对模型隐藏 return {order_id: order_id, status: paid, amount: 199.0} mcp.resource(schema://orders) def get_order_schema() - str: 暴露订单表结构给模型方便它生成查询语句 return orders(id, user_id, status, amount, created_at) if __name__ __main__: mcp.run(transportstdio)跑起来之后模型层不需要关心“订单数据到底是存在 MySQL 还是来自某个网关”它只看到get_order这个工具和返回的 JSON。这就是 MCP 最大的价值让工具接入从“点对点”变成“一点对面”。有同学常问 browser-use 的 MCP 和 Playwright 的 MCP 有什么区别。粗看都是“控制浏览器”实际定位很不一样browser-use 的 MCP 偏“任务语义”给模型提供的是阅读网页、点击、填表、总结这样抽象动作Playwright 的 MCP 偏“自动化测试语义”面向的是精准控制元素、断言状态、录制回放这类需求。选型时别只看都会操作浏览器而是看你需要模型理解“意图”还是“步骤”。2.2 Skills 机制让 Agent 拥有可复用的肌肉记忆Skills 是最近一年才被大规模重视的概念来自 Anthropic 推出的 Agent Skills 规范。简单说Agent Skill 是一个自包含的技能包通常包含一份SKILL.md主文件里面用 Markdown 描述技能的使用场景、执行步骤、注意事项可能附带一些脚本、模板、配置文件。为什么不能把技能直接写进系统 prompt因为 prompt 会越来越长、越来越乱而且每个任务都用同一套规则会互相干扰。Skills 把“如何做一件事”固化成独立单元在需要的时候才加载进上下文。用的时候相当于翻出工作手册不用的时候就放回抽屉。这套机制在 Codex Skills 上体现得尤其明显。你可以给 Codex 装“写论文”的技能技能包里会拆解成确定主题和研究问题检索相关资料评估来源可靠性生成大纲和用户确认结构分段撰写插入引用统一格式化并按规范输出参考文献。注意每个步骤如果需要调用工具技能描述里会写明“本步骤调用什么工具、传什么参数”。这样技能就和 MCP 天然衔接上了。社区里还出现了超级技能Superpowers之类的组合包把调研、写作、编程、复盘等一系列技能打包成一个“方法论体系”本质还是对 SKILL.md 的组织和编排。目前找 Skills 的途径主要有几类官方市场、GitHub 开源仓库、付费付费平台。挑选时至少看三样东西主文件是否完整、依赖脚本是否干净、权限声明范围是否合理。装完技能先在小样本上跑一遍不要一上来就上生产。2.3 两者配合的正确姿势菜谱和厨房的关系MCP 和 Skills 很容易搞混因为看起来都是“给 Agent 加能力”。我用一个比喻帮你理清楚MCP 是厨具锅、灶、烤箱代表 Agent 现在能调用什么资源Skills 是菜谱代表“做出一道菜”的流程和配方。只有菜谱没有厨具步骤写得再漂亮也执行不了只有厨具没有菜谱Agent 面对满厨房工具不知道从何下手。反过来说一个合格 Skill 的正确形态不是从头教你“打开数据库”而是告诉你“先查哪些表、用哪几个 MCP 工具、按什么顺序处理结果、有哪些坑要避开”。实践中最容易犯的错误就是把业务逻辑写死在 MCP Server 里面。比如在工具函数里直接写“生成报告”的完整流程。这样做的结果是每次流程调整都要改服务端代码而且其他 Agent 复用不了这套逻辑。正确的做法是MCP 保持原子能力只暴露“查询数据”“生成图表”“渲染模板”之类的最小工具流程编排交给 Skill 描述由 Agent 自主组合。这样当业务规则更新时改一个 SKILL.md 文件就够了服务端完全不用动。3. A2A 与 DeepAgents让集群真正协作起来单个 Agent 的能力做完之后才轮到集群层面。A2A 解决“Agent 之间怎么对话”DeepAgents 解决“谁指挥谁干活”。这一章是最容易出彩的部分也是最容易踩坑的部分。3.1 A2A 协议的设计亮点A2AAgent2Agent协议的目标是让不同厂商、不同框架的 Agent 能够直接互通。你可以类比成 HTTP 之于 Web大家都遵守同一个协议浏览器才能访问任意网站。A2A 就是“Agent 世界里的 HTTP”。核心设计有以下几点使用 JSON-RPC 2.0 over HTTP(S) 作为通信方式和大多数现代服务架构天然契合每个 Agent 通过一份 Agent Card 来自我描述说明自己的能力、支持的任务类型、推送方式类似“AI 名片”引入 Task 生命周期管理任务从 submitted 到 working再到 completed或者需要用户补充信息时进入 input-required 状态。长任务可以异步轮询不用一直占着连接允许传递多模态内容文本、图片、结构化数据都行底层通过 JSON base64 等方式编码。A2A 在 Spring 生态里也有落地Spring AI 项目已经提供对 A2A 协议的支持封装。如果你所在的团队是 Java 技术栈可以在已有 Spring Boot 服务里直接加上 A2A 端点不用另起炉灶。Python 侧同样有官方示例本质上都是把 Agent 的请求入口标准化。需要注意A2A 和 MCP 不是竞争关系而是互补关系。MCP 管的是“Agent 调用工具”A2A 管的是“Agent 调用另一个 Agent”。工具是确定性的函数接口Agent 是有状态、会推理的协作方两者的语义完全不是一个层次。3.2 DeepAgents 编排层的职责一个会拆任务的调度器“DeepAgents”在这里更像一类角色的统称。课程里讲的 DeepAgents不是某个特定框架而是指多智能体系统里的“深度编排层”。你可以把它落地成 LangGraph、AutoGen、自研调度服务甚至是一组云函数加队列。重要的是编排层至少要承担以下职责任务规划把用户一个模糊的指令拆成可执行的子任务并排列依赖关系任务分配根据 Agent Card 和能力描述把子任务分给合适的执行 Agent上下文管理维护全局共享状态避免每个 Agent 各拿一段信息导致“盲人摸象”结果汇总把多个 Agent 的输出合并、去重、格式化成最终答案异常处理某个 Agent 超时或失败时决定重试、降级还是换一条路径。比如用户请求“对比近三个月销售额和营销支出的关系出一份分析报告”。编排层拆出一个 Agent 拉取销售数据一个 Agent 拉取营销投放数据一个 Agent 做相关性分析一个 Agent 写报告。前两个可以并行跑第三个要等前两个完成第四个在最后执行。这种依赖关系就应该在编排阶段显式定义好。工程上要特别留意上下文状态的传递。很多系统崩溃不是 Agent 能力不行而是 A Agent 产出的中间结果没有正确传给 B Agent。我的建议是所有跨 Agent 的交接数据统一用结构化格式JSON并且集中存到共享存储里而不是靠 Agent 自己“记住”。3.3 集群拓扑三种可以落地的排布根据任务的协作模式多智能体集群一般有三种拓扑。不用纠结哪种最好按场景选。第一种是星型结构Hub-Spoke也是最好理解、最容易排查问题的一种。中心编排器负责所有任务的接收、拆分、回收每个子 Agent 只和中心通信。适合任务边界清晰、执行节点独立的场景比如“信息搜集 数据分析 报告生成”。第二种是流水线结构Pipeline适合有固定先后顺序的流程比如代码评审流水线A 写代码B 做静态检查C 跑测试D 评审合并。前一个节点的输出就是后一个节点的输入全程线性推进。优点是逻辑简单缺点是链路一长单个节点故障会阻塞整条流水线。第三种是网状结构Mesh适合高度协作、角色互相依赖的场景比如多智能体编程团队里架构师、后端、前端、测试之间需要反复同步和交换意见。网状结构灵活但状态同步和冲突处理成本极高不太适合业务稳定性要求高的系统。选型的时候我的判断标准是优先把任务依赖图画出来如果依赖关系呈线性用流水线呈树状汇合用星型无规律网状纠缠先反思一下是不是任务划分有问题——多数情况下重新划分任务可以避免网状结构。4. 实操5 分钟拉起一个最小 MCP A2A 集群光讲概念容易飘直接给一套可以本机复现的最小集群。我们做一个业务场景用户丢来一个订单号系统自动完成“查订单 → 查库存 → 判断履约状态”三步操作。这么小的需求也要上集群纯粹是为了演示怎么把 MCP、Skills、A2A、DeepAgents 串起来。整个环境预计 20 分钟内搞定含踩坑时间。4.1 环境准备与目录设计先保证本地有 Python 3.11建议用 uv 或者 conda 建独立环境。MCP 我用 FastMCP 这个库够轻量A2A 部分直接用官方 Python SDK 或者最小实现不引入过重的框架。目录结构大概长这样agent-cluster-demo/ ├── pyproject.toml ├── skills/ │ └── fulfillment-check/ │ ├── SKILL.md │ └── checklist.md ├── mcp_servers/ │ ├── order_server.py │ └── inventory_server.py ├── a2a_gateway/ │ └── gateway.py └── orchestrator/ └── main.py四个目录对应四个角色后面一个个填。4.2 用 FastMCP 写两个技能型服务先写订单服务和库存服务。每个服务都是一个独立的 MCP Server通过标准输入输出stdio和宿主通信。# mcp_servers/order_server.py from fastmcp import FastMCP mcp FastMCP(order-service) mcp.tool() def get_order(order_id: str) - dict: 根据订单号查询订单状态。返回订单详情。 # 真实项目这里接订单数据库这里用模拟数据 data { A1001: {status: paid, items: [SKU-X1, SKU-Y2], amount: 328.00}, A1002: {status: pending, items: [SKU-Z3], amount: 99.00}, } return data.get(order_id, {error: order not found}) if __name__ __main__: mcp.run(transportstdio)库存服务类似# mcp_servers/inventory_server.py from fastmcp import FastMCP mcp FastMCP(inventory-service) mcp.tool() def check_stock(sku: str) - dict: 查询SKU的可用库存。返回库存数量与状态。 stock {SKU-X1: 25, SKU-Y2: 0, SKU-Z3: 128} available stock.get(sku, 0) return {sku: sku, available: available, in_stock: available 0} if __name__ __main__: mcp.run(transportstdio)为什么这里要用 MCP 而不是直接写两个 Python 函数因为在实际集群里这两个服务可能由不同团队维护部署在不同机器上甚至使用不同语言。业务 A 只关心“order-service 提供了 get_order 工具”不需要知道它内部是 Django 还是 Express。这就是接口标准化的收益。接着写一个 Skill 文件把“履约检查”这个业务流程沉淀下来--- name: fulfillment-check description: 根据订单号判断订单能否正常履约 allowed-tools: - get_order - check_stock --- # 履约检查 SOP 1. 调用 get_order 获取订单状态确认订单已支付。 2. 读取订单商品列表 items。 3. 对每个 SKU 调用 check_stock检查是否都有库存。 4. 若任何 SKU 缺货返回 could_not_fulfill 并列出缺货 SKU。 5. 若全部有货返回 fulfillment_ok。 ## 注意事项 - 订单状态为 pending 时不要继续查库存直接提示用户支付未完成。 - 多个 SKU 并行查询不要串行等待。看到没有这个 Skill 没有重复实现任何查询逻辑它只描述了“按什么顺序调用哪些 MCP 工具、遇到什么情况怎么处理”。这就是 Skills 和业务胶水代码的正确关系。4.3 给 Agent 接一层 A2A 通信网关单个 MCP Server 是给大模型用的工具但现在我们要让“Agent A”能直接请求“Agent B”。此时引入 A2A 网关。网关的核心工作有两个一个是维护本组 Agent 能力的 Agent Card另一个是接收外部 Agent 发来的任务请求并转发给内部执行器。# a2a_gateway/gateway.py # 基于 a2a 官方 Python SDK 的极简示例本地 8001 端口 from a2a.server import InMemoryAgentServer from a2a.types import AgentCard, Task card AgentCard( nameinventory-agent, description检查商品库存与履约状态, urlhttp://127.0.0.1:8001/, ) def handle_task(task: Task): # 收到外部Agent请求后内部翻译成工具调用 # 例如 task.message 里包含 {action: check_stock, sku: SKU-X1} # 这里实际调用 MCP 工具返回结构化结果 result check_stock(task.message.payload[sku]) return result server InMemoryAgentServer(cardcard, handlerhandle_task) server.start()网关这层最大的好处是隔离。外部 Agent 不关心你的库存数据存在哪里、MCP Server 跑在什么环境它只认 A2A 协议向你的网关发任务、拿结果。内部改造升级时网关接口不变外部系统感知不到。这里的InMemoryAgentServer是官方 SDK 里的内存实现好处是本地演示方便坏处是不适合生产。生产环境建议换成带持久化任务队列的版本避免进程重启后任务状态丢失。4.4 编排器把任务串起来最后是 DeepAgents 编排器。它对外接收用户请求对内同时作为 MCP Client 和 A2A Client。也就是说它既能调用 MCP 工具也能通过 A2A 网关调用其他 Agent 的能力。核心调度逻辑伪代码如下# orchestrator/main.py import asyncio async def handle_fulfillment(order_id: str): # 1. 调用订单 MCP Server获取订单详情 order await mcp_client.call_tool(order-service, get_order, {order_id: order_id}) if order[status] ! paid: return {result: payment_pending, tip: 请先完成支付} # 2. 从 Skill 定义中读取流程发现需要检查每个SKU库存 tasks [] for sku in order[items]: tasks.append(mcp_client.call_tool(inventory-service, check_stock, {sku: sku})) # 多个SKU并行检查 stock_results await asyncio.gather(*tasks) # 3. 判断是否缺货 out_of_stock [r[sku] for r in stock_results if not r[in_stock]] if out_of_stock: return {result: could_not_fulfill, out_of_stock: out_of_stock} # 4. 通过A2A通知下游仓储Agent执行出库 a2a_result await a2a_client.send( agentwarehouse-agent, payload{action: deliver, order_id: order_id}, ) return {result: fulfillment_ok, delivery: a2a_result}注意第 2 步的“从 Skill 定义中读取流程”。真实实现里编排器会把 SKILL.md 喂给大模型让模型决定调用哪些工具、按什么顺序调用。我这个示例是手工写死流程方便演示。生产系统中更常见的是“Skill 提供规则大模型按规则决策”两者并不矛盾。到这里一个最小集群已经跑通用户输入订单号 → 编排器拆任务 → 调订单服务 → 并行调库存服务 → 凭结果决策 → 通过 A2A 通知下游。整个过程是四个协议/组件各司其职MCP 连接工具、Skills 定义流程、A2A 连接 Agent、DeepAgents 做编排。5. 排坑实录我踩过的那些深坑工程实践里最值钱的从来不是成功路径而是失败路径。这一章整理了我实际搭建 Agent 集群时遇到的高频问题以及对应排查思路。这些都是网上一般教程里不会写的内容。5.1 客户端配置了 MCP 却找不到服务“Codex 无法找到 MCP”这种问题在社区里已经成了日经贴。我排查下来80% 是下面几类原因现象可能原因排查思路客户端提示连接失败MCP Server 启动路径不对确认command可执行、args是绝对路径先手动在终端跑一遍看报错能启动但立即退出缺少 Python 环境变量确保使用当前项目的虚拟环境绝对路径比如uv run python -m mcp_server连接成功后工具列表为空stdio 模式与 HTTP 模式不匹配检查 Server 端 transport 是否和客户端配置一致stdio 和 sse 不能混用多个 Server 互相冲突端口或服务名重复给每个 Server 起独立服务名HTTP 模式分配不同端口一个特别容易被忽略的点当 MCP Server 是 Python 脚本时客户端里的command不能直接写python因为客户端的 PATH 环境可能不包含你的虚拟环境。建议写成/path/to/venv/bin/python或者用uv run显式指定。5.2 Skills 目录和权限声明惹的祸SKILL.md 不是放在任意目录就能被识别多数实现要求技能目录位于约定的根目录下且主文件名严格为SKILL.md。我见过有人把文件名写成skill.md或SKILL.MD结果 Agent 怎么都加载不到。名称大小写在部分系统上敏感建议统一全大写。另一个坑是权限声明。不少框架支持在 SKILL.md 的 frontmatter 里声明 allowed-tools 和 allowed-domain。一旦声明了Skill 执行时在权限名单外的工具会被拦截。刚开始建议把权限声明放宽跑通后再收紧否则“为什么 Skill 调不了工具”会浪费你半小时。还有工具名冲突同一个集群里两个 Skill 依赖了同名但不同作用的 MCP 工具容易互相覆盖。解决办法是 MCP Server 暴露的工具名尽量带业务前缀比如order_get、inventory_check避免泛化命名。5.3 Agent 之间状态不同步任务卡死A2A 引入了任务状态机但实际运行中两个 Agent 很容易因为状态不同步而互相等待。最典型的场景是Agent A 通过 A2A 给 Agent B 发了一个任务B 在处理过程中需要用户补充信息进入input-required状态。但如果 A 没有实现对这个状态的处理逻辑它会一直傻等最终超时。解决思路有两条一是 Agent A 在发起任务时明确声明自己能处理input-requiredB 一旦进入该状态A 会代为向用户提问并把答案传回去。这要求双方的 Agent Card 里把能力协议写得清清楚楚。二是网关层做超时兜底。不要无限等下去建议设置可配置的超时时间比如 60 秒。超时后把任务标记为失败并触发编排层的重试或降级策略。另外一个教训任务结果尽量结构化。A2A 虽然支持文本消息但如果是机器之间的协作直接传纯文本会让下游 Agent 解析困难。统一用 JSON 格式并且在 Agent Card 里声明字段定义能少非常多沟通成本。5.4 令牌、授权和数据边界问题MCP 生态火热之后安全问题被我排在第一位。最常见的问题是令牌泄露有人为了演示方便把带 token 的 WebSocket 地址、API Key 直接写进配置文件甚至推到公共仓库。这等于把家门钥匙放在脚垫下面风险极高。我见过连接 Figma MCP、蓝湖 MCP、同花顺 MCP 时授权模式搞混的情况。特别提醒像 Figma 这类 SaaS 工具的授权要区分“部署态”和“用户态”。部署态令牌是服务端运行专用权限也必须收敛建议只开最小必需的 scope用户态令牌属于终端用户应该在用户侧完成 OAuth 授权流程而不是拿一个全局令牌给所有用户共享。在集群内部每个 Agent 的身份也要清晰。A 调用 B 的能力时B 需要知道自己服务的调用方是谁、权限范围是什么。如果集群规模小可以在 A2A 网关层做简单的令牌认证规模一大建议上标准的服务间身份体系比如 mTLS 或者带签名的 JWT。多智能体系统的安全边界一定不能在最后一个环节才考虑要在一开始做进协议选择里。收尾就写到这里这几套东西我完整做了三版第一版被协议概念带着跑第二版被工具选型绊住脚第三版才真正把 MCP、Skills、A2A 和编排串成一条线。最大的感受是——任何一个被吹上天的名词放到工程里都只是一道选择题MCP 不是银弹A2A 也拯救不了没有清晰边界的系统。真正让 Agent 集群跑得稳的是你对业务任务域的拆解能力以及一套能兜住异常、管住权限的工程底座。如果你正准备从单 Agent 往集群方向走建议先别急着堆组件拿一个最简单的“查询-处理-汇总”流程把这一整套链路跑通再逐步往上加节点。路是一步步踩稳的集群也是一层层搭出来的。 从MCP到A2A：下一代多智能体集群的工程实践
最近在准备一门关于DeepAgents、MCP、A2A、Skills 的超级多智能体课程前后把文档翻了个底朝天也顺手在真实业务里搭了两套 Agent 集群做验证。越做越觉得2025 年以后的 Agent 开发真正拉开差距的不再是模型选型而是工程化的那张网MCP 解决工具接线Skills 解决经验沉淀A2A 解决 Agent 之间的协同DeepAgents 解决任务编排——这四个东西拼在一起才是完整的下一代 Agent 集群。这篇不写课程目录只把我在实操里验证过的思路、代码和掉进去过的坑记录下来给各位打算入坑多智能体、或者正在被“一个 Agent 写不出复杂业务”卡住的朋友做个参照。1. 先看清设计为什么偏偏是这四个词很多同学第一次看到“DeepAgents MCP A2A Skills”这套组合第一反应是名词堆砌MCP 我听过A2A 是什么Skills 和 Plugin 有什么区别DeepAgents 又是哪家的框架其实这四个词不是并列的四个工具而是从四个不同维度补全了一套 Agent 工程的拼图。理解清楚它们各自的职责后面的实践才不会跑偏。1.1 把四个词翻译成团队里的角色我习惯把他们类比成一个公司的项目组MCP 像是终端设备的物理接口标准。你不需要给每个外设单独设计针脚只要大家都遵守同一个协议插上就能用。MCP 就是 AI 应用层面的“外设总线”让大模型可以统一调用各种外部工具、数据源。Skills 则是老员工手里的工作手册。同一个技能比如写周报手册里包含了完整的步骤、模板、注意事项和调用工具的顺序。Agent 装上 Skill相当于新人拿到了老师傅的 SOP。A2A 是部门之间的对接流程。两个 Agent 分属不同系统时怎么发请求、怎么回结果、怎么处理中间状态需要一套双方都认可的通信规范。A2A 就是 Agent 对 Agent 的“商务谈判标准”。DeepAgents 则是项目经理。它负责把一个大目标拆成子任务分给不同的专家 Agent盯进度、收结果、做汇总。用一个具体场景串起来你让系统“每周一早上九点生成一份最新的行业竞品分析报告”。DeepAgents 先拆任务信息采集、数据分析、报告撰写。采集任务分给负责资讯的 Agent它通过 MCP 连接全网数据源数据分析 Agent 调用数据库查询 Skill按经验流程清洗数据最后写报告的 Agent 通过 A2A 向前面两个 Agent 要结果汇总成文档。全程由 DeepAgents 编排四个角色一个都不少。1.2 从“单兵模型”到“集群作战”的三个台阶大部分人接触 AI Agent第一步是单 Agent 加工具一个大模型配上搜索、计算器等工具。这个阶段的问题很典型——上下文越堆越长工具选择容易出错任务一旦跨多个领域就顾此失彼。第二个台阶是多 Agent也就是让几个 Agent 各管一摊。但这个阶段很快会碰到集成痛苦每个 Agent 的通信方式不一样、工具接法不一样。这时候如果没有 MCP 统一工具接口、没有 A2A 统一通信协议系统会变成一团乱麻。第三个台阶也就是这个课程想讲的“超级多智能体集群”核心就是标题里那三个能力词可编排所有 Agent 被一个调度中枢统一管理任务可以拆分、组合、回滚、重试。可互通工具层互通MCPAgent 层互通A2A。可扩展新增一个能力不需要改主系统放一个 Skill 或者接一个 MCP Server 就行。进入第三台阶之后系统的复杂度不再体现在“模型有多聪明”而是“整个团队能不能有序协作”——这也是为什么课程会特意把协议MCP/A2A和技能封装Skills放在一起讲。1.3 这套方案适合谁以及它的边界说句实在话不是所有场景都适合上多智能体集群。如果你只是做一个“帮用户查天气、写文案”的轻量助手单 Agent 完全够用强行上集群只会增加延迟和故障点。但如果你遇到的是以下情况这套组合拳会非常值业务跨越多个领域需要多个专家角色协同数据源和系统接口非常多且经常更换任务流程有明确阶段或者需要人机交接希望把团队的作业方法论沉淀成可以复用的资产。我个人的判断是2025 到 2026 年企业真正缺的不是“一个能写代码的 Agent”而是一套能把业务能力和 Agent 系统衔接起来的工程规范。MCP、Skills、A2A 这套体系恰好就是在补这块短板。2. MCP 与 Skills先把单个 Agent 的手脚和肌肉记忆造出来集群再大基础单元还是一个个干活的 Agent。所以第一步不是急着让 Agent 互相通信而是先把单个 Agent 的能力边界做扎实。这一章重点拆解 MCP 和 Skills 这两个最基础也最容易搞混的组件。2.1 MCP 的本质把工具从 prompt 里捞出来MCPModel Context Protocol是一个开放的、标准化的协议全称很直白——“模型上下文协议”。它解决的是大模型应用接入外部工具时“接口碎片化”的问题。在 MCP 出现之前每接一个外部系统你都得为模型写一遍工具描述、函数定义、参数 schema还要处理鉴权、错误信息、返回格式。不同平台各有各的格式迁移一次成本极高。MCP 的解法是定义了一套统一的客户端-服务器架构Host模型宿主比如 Claude Desktop、IDE 插件或者你自研的应用Client在 Host 内部负责和 MCP Server 建立连接Server把具体工具封装成标准接口暴露给 Client原语三件套Tools可执行动作、Resources可读取的数据、Prompts可复用的提示模板。有人问过MCP 既然是软件协议那硬件协议那个概念叫什么答案是硬件领域对应的是总线标准和接口规范比如 USB、HDMI、PCIe。软件协议管的是数据交换规则硬件协议管的是物理连接规则但底层逻辑一样——都是“定义两端达成共识的语言”。你可以把 MCP 理解成 AI 应用层的 USB-C只要设备支持这个标准插上就能用不用管另一端是什么牌子。实际开发里一个典型的 MCP Server 长这样from fastmcp import FastMCP # 创建服务声明服务名 mcp FastMCP(orders-server) mcp.tool() def get_order(order_id: int) - dict: 查询订单基本信息返回订单状态与金额 # 内部可以接数据库、第三方API全部对模型隐藏 return {order_id: order_id, status: paid, amount: 199.0} mcp.resource(schema://orders) def get_order_schema() - str: 暴露订单表结构给模型方便它生成查询语句 return orders(id, user_id, status, amount, created_at) if __name__ __main__: mcp.run(transportstdio)跑起来之后模型层不需要关心“订单数据到底是存在 MySQL 还是来自某个网关”它只看到get_order这个工具和返回的 JSON。这就是 MCP 最大的价值让工具接入从“点对点”变成“一点对面”。有同学常问 browser-use 的 MCP 和 Playwright 的 MCP 有什么区别。粗看都是“控制浏览器”实际定位很不一样browser-use 的 MCP 偏“任务语义”给模型提供的是阅读网页、点击、填表、总结这样抽象动作Playwright 的 MCP 偏“自动化测试语义”面向的是精准控制元素、断言状态、录制回放这类需求。选型时别只看都会操作浏览器而是看你需要模型理解“意图”还是“步骤”。2.2 Skills 机制让 Agent 拥有可复用的肌肉记忆Skills 是最近一年才被大规模重视的概念来自 Anthropic 推出的 Agent Skills 规范。简单说Agent Skill 是一个自包含的技能包通常包含一份SKILL.md主文件里面用 Markdown 描述技能的使用场景、执行步骤、注意事项可能附带一些脚本、模板、配置文件。为什么不能把技能直接写进系统 prompt因为 prompt 会越来越长、越来越乱而且每个任务都用同一套规则会互相干扰。Skills 把“如何做一件事”固化成独立单元在需要的时候才加载进上下文。用的时候相当于翻出工作手册不用的时候就放回抽屉。这套机制在 Codex Skills 上体现得尤其明显。你可以给 Codex 装“写论文”的技能技能包里会拆解成确定主题和研究问题检索相关资料评估来源可靠性生成大纲和用户确认结构分段撰写插入引用统一格式化并按规范输出参考文献。注意每个步骤如果需要调用工具技能描述里会写明“本步骤调用什么工具、传什么参数”。这样技能就和 MCP 天然衔接上了。社区里还出现了超级技能Superpowers之类的组合包把调研、写作、编程、复盘等一系列技能打包成一个“方法论体系”本质还是对 SKILL.md 的组织和编排。目前找 Skills 的途径主要有几类官方市场、GitHub 开源仓库、付费付费平台。挑选时至少看三样东西主文件是否完整、依赖脚本是否干净、权限声明范围是否合理。装完技能先在小样本上跑一遍不要一上来就上生产。2.3 两者配合的正确姿势菜谱和厨房的关系MCP 和 Skills 很容易搞混因为看起来都是“给 Agent 加能力”。我用一个比喻帮你理清楚MCP 是厨具锅、灶、烤箱代表 Agent 现在能调用什么资源Skills 是菜谱代表“做出一道菜”的流程和配方。只有菜谱没有厨具步骤写得再漂亮也执行不了只有厨具没有菜谱Agent 面对满厨房工具不知道从何下手。反过来说一个合格 Skill 的正确形态不是从头教你“打开数据库”而是告诉你“先查哪些表、用哪几个 MCP 工具、按什么顺序处理结果、有哪些坑要避开”。实践中最容易犯的错误就是把业务逻辑写死在 MCP Server 里面。比如在工具函数里直接写“生成报告”的完整流程。这样做的结果是每次流程调整都要改服务端代码而且其他 Agent 复用不了这套逻辑。正确的做法是MCP 保持原子能力只暴露“查询数据”“生成图表”“渲染模板”之类的最小工具流程编排交给 Skill 描述由 Agent 自主组合。这样当业务规则更新时改一个 SKILL.md 文件就够了服务端完全不用动。3. A2A 与 DeepAgents让集群真正协作起来单个 Agent 的能力做完之后才轮到集群层面。A2A 解决“Agent 之间怎么对话”DeepAgents 解决“谁指挥谁干活”。这一章是最容易出彩的部分也是最容易踩坑的部分。3.1 A2A 协议的设计亮点A2AAgent2Agent协议的目标是让不同厂商、不同框架的 Agent 能够直接互通。你可以类比成 HTTP 之于 Web大家都遵守同一个协议浏览器才能访问任意网站。A2A 就是“Agent 世界里的 HTTP”。核心设计有以下几点使用 JSON-RPC 2.0 over HTTP(S) 作为通信方式和大多数现代服务架构天然契合每个 Agent 通过一份 Agent Card 来自我描述说明自己的能力、支持的任务类型、推送方式类似“AI 名片”引入 Task 生命周期管理任务从 submitted 到 working再到 completed或者需要用户补充信息时进入 input-required 状态。长任务可以异步轮询不用一直占着连接允许传递多模态内容文本、图片、结构化数据都行底层通过 JSON base64 等方式编码。A2A 在 Spring 生态里也有落地Spring AI 项目已经提供对 A2A 协议的支持封装。如果你所在的团队是 Java 技术栈可以在已有 Spring Boot 服务里直接加上 A2A 端点不用另起炉灶。Python 侧同样有官方示例本质上都是把 Agent 的请求入口标准化。需要注意A2A 和 MCP 不是竞争关系而是互补关系。MCP 管的是“Agent 调用工具”A2A 管的是“Agent 调用另一个 Agent”。工具是确定性的函数接口Agent 是有状态、会推理的协作方两者的语义完全不是一个层次。3.2 DeepAgents 编排层的职责一个会拆任务的调度器“DeepAgents”在这里更像一类角色的统称。课程里讲的 DeepAgents不是某个特定框架而是指多智能体系统里的“深度编排层”。你可以把它落地成 LangGraph、AutoGen、自研调度服务甚至是一组云函数加队列。重要的是编排层至少要承担以下职责任务规划把用户一个模糊的指令拆成可执行的子任务并排列依赖关系任务分配根据 Agent Card 和能力描述把子任务分给合适的执行 Agent上下文管理维护全局共享状态避免每个 Agent 各拿一段信息导致“盲人摸象”结果汇总把多个 Agent 的输出合并、去重、格式化成最终答案异常处理某个 Agent 超时或失败时决定重试、降级还是换一条路径。比如用户请求“对比近三个月销售额和营销支出的关系出一份分析报告”。编排层拆出一个 Agent 拉取销售数据一个 Agent 拉取营销投放数据一个 Agent 做相关性分析一个 Agent 写报告。前两个可以并行跑第三个要等前两个完成第四个在最后执行。这种依赖关系就应该在编排阶段显式定义好。工程上要特别留意上下文状态的传递。很多系统崩溃不是 Agent 能力不行而是 A Agent 产出的中间结果没有正确传给 B Agent。我的建议是所有跨 Agent 的交接数据统一用结构化格式JSON并且集中存到共享存储里而不是靠 Agent 自己“记住”。3.3 集群拓扑三种可以落地的排布根据任务的协作模式多智能体集群一般有三种拓扑。不用纠结哪种最好按场景选。第一种是星型结构Hub-Spoke也是最好理解、最容易排查问题的一种。中心编排器负责所有任务的接收、拆分、回收每个子 Agent 只和中心通信。适合任务边界清晰、执行节点独立的场景比如“信息搜集 数据分析 报告生成”。第二种是流水线结构Pipeline适合有固定先后顺序的流程比如代码评审流水线A 写代码B 做静态检查C 跑测试D 评审合并。前一个节点的输出就是后一个节点的输入全程线性推进。优点是逻辑简单缺点是链路一长单个节点故障会阻塞整条流水线。第三种是网状结构Mesh适合高度协作、角色互相依赖的场景比如多智能体编程团队里架构师、后端、前端、测试之间需要反复同步和交换意见。网状结构灵活但状态同步和冲突处理成本极高不太适合业务稳定性要求高的系统。选型的时候我的判断标准是优先把任务依赖图画出来如果依赖关系呈线性用流水线呈树状汇合用星型无规律网状纠缠先反思一下是不是任务划分有问题——多数情况下重新划分任务可以避免网状结构。4. 实操5 分钟拉起一个最小 MCP A2A 集群光讲概念容易飘直接给一套可以本机复现的最小集群。我们做一个业务场景用户丢来一个订单号系统自动完成“查订单 → 查库存 → 判断履约状态”三步操作。这么小的需求也要上集群纯粹是为了演示怎么把 MCP、Skills、A2A、DeepAgents 串起来。整个环境预计 20 分钟内搞定含踩坑时间。4.1 环境准备与目录设计先保证本地有 Python 3.11建议用 uv 或者 conda 建独立环境。MCP 我用 FastMCP 这个库够轻量A2A 部分直接用官方 Python SDK 或者最小实现不引入过重的框架。目录结构大概长这样agent-cluster-demo/ ├── pyproject.toml ├── skills/ │ └── fulfillment-check/ │ ├── SKILL.md │ └── checklist.md ├── mcp_servers/ │ ├── order_server.py │ └── inventory_server.py ├── a2a_gateway/ │ └── gateway.py └── orchestrator/ └── main.py四个目录对应四个角色后面一个个填。4.2 用 FastMCP 写两个技能型服务先写订单服务和库存服务。每个服务都是一个独立的 MCP Server通过标准输入输出stdio和宿主通信。# mcp_servers/order_server.py from fastmcp import FastMCP mcp FastMCP(order-service) mcp.tool() def get_order(order_id: str) - dict: 根据订单号查询订单状态。返回订单详情。 # 真实项目这里接订单数据库这里用模拟数据 data { A1001: {status: paid, items: [SKU-X1, SKU-Y2], amount: 328.00}, A1002: {status: pending, items: [SKU-Z3], amount: 99.00}, } return data.get(order_id, {error: order not found}) if __name__ __main__: mcp.run(transportstdio)库存服务类似# mcp_servers/inventory_server.py from fastmcp import FastMCP mcp FastMCP(inventory-service) mcp.tool() def check_stock(sku: str) - dict: 查询SKU的可用库存。返回库存数量与状态。 stock {SKU-X1: 25, SKU-Y2: 0, SKU-Z3: 128} available stock.get(sku, 0) return {sku: sku, available: available, in_stock: available 0} if __name__ __main__: mcp.run(transportstdio)为什么这里要用 MCP 而不是直接写两个 Python 函数因为在实际集群里这两个服务可能由不同团队维护部署在不同机器上甚至使用不同语言。业务 A 只关心“order-service 提供了 get_order 工具”不需要知道它内部是 Django 还是 Express。这就是接口标准化的收益。接着写一个 Skill 文件把“履约检查”这个业务流程沉淀下来--- name: fulfillment-check description: 根据订单号判断订单能否正常履约 allowed-tools: - get_order - check_stock --- # 履约检查 SOP 1. 调用 get_order 获取订单状态确认订单已支付。 2. 读取订单商品列表 items。 3. 对每个 SKU 调用 check_stock检查是否都有库存。 4. 若任何 SKU 缺货返回 could_not_fulfill 并列出缺货 SKU。 5. 若全部有货返回 fulfillment_ok。 ## 注意事项 - 订单状态为 pending 时不要继续查库存直接提示用户支付未完成。 - 多个 SKU 并行查询不要串行等待。看到没有这个 Skill 没有重复实现任何查询逻辑它只描述了“按什么顺序调用哪些 MCP 工具、遇到什么情况怎么处理”。这就是 Skills 和业务胶水代码的正确关系。4.3 给 Agent 接一层 A2A 通信网关单个 MCP Server 是给大模型用的工具但现在我们要让“Agent A”能直接请求“Agent B”。此时引入 A2A 网关。网关的核心工作有两个一个是维护本组 Agent 能力的 Agent Card另一个是接收外部 Agent 发来的任务请求并转发给内部执行器。# a2a_gateway/gateway.py # 基于 a2a 官方 Python SDK 的极简示例本地 8001 端口 from a2a.server import InMemoryAgentServer from a2a.types import AgentCard, Task card AgentCard( nameinventory-agent, description检查商品库存与履约状态, urlhttp://127.0.0.1:8001/, ) def handle_task(task: Task): # 收到外部Agent请求后内部翻译成工具调用 # 例如 task.message 里包含 {action: check_stock, sku: SKU-X1} # 这里实际调用 MCP 工具返回结构化结果 result check_stock(task.message.payload[sku]) return result server InMemoryAgentServer(cardcard, handlerhandle_task) server.start()网关这层最大的好处是隔离。外部 Agent 不关心你的库存数据存在哪里、MCP Server 跑在什么环境它只认 A2A 协议向你的网关发任务、拿结果。内部改造升级时网关接口不变外部系统感知不到。这里的InMemoryAgentServer是官方 SDK 里的内存实现好处是本地演示方便坏处是不适合生产。生产环境建议换成带持久化任务队列的版本避免进程重启后任务状态丢失。4.4 编排器把任务串起来最后是 DeepAgents 编排器。它对外接收用户请求对内同时作为 MCP Client 和 A2A Client。也就是说它既能调用 MCP 工具也能通过 A2A 网关调用其他 Agent 的能力。核心调度逻辑伪代码如下# orchestrator/main.py import asyncio async def handle_fulfillment(order_id: str): # 1. 调用订单 MCP Server获取订单详情 order await mcp_client.call_tool(order-service, get_order, {order_id: order_id}) if order[status] ! paid: return {result: payment_pending, tip: 请先完成支付} # 2. 从 Skill 定义中读取流程发现需要检查每个SKU库存 tasks [] for sku in order[items]: tasks.append(mcp_client.call_tool(inventory-service, check_stock, {sku: sku})) # 多个SKU并行检查 stock_results await asyncio.gather(*tasks) # 3. 判断是否缺货 out_of_stock [r[sku] for r in stock_results if not r[in_stock]] if out_of_stock: return {result: could_not_fulfill, out_of_stock: out_of_stock} # 4. 通过A2A通知下游仓储Agent执行出库 a2a_result await a2a_client.send( agentwarehouse-agent, payload{action: deliver, order_id: order_id}, ) return {result: fulfillment_ok, delivery: a2a_result}注意第 2 步的“从 Skill 定义中读取流程”。真实实现里编排器会把 SKILL.md 喂给大模型让模型决定调用哪些工具、按什么顺序调用。我这个示例是手工写死流程方便演示。生产系统中更常见的是“Skill 提供规则大模型按规则决策”两者并不矛盾。到这里一个最小集群已经跑通用户输入订单号 → 编排器拆任务 → 调订单服务 → 并行调库存服务 → 凭结果决策 → 通过 A2A 通知下游。整个过程是四个协议/组件各司其职MCP 连接工具、Skills 定义流程、A2A 连接 Agent、DeepAgents 做编排。5. 排坑实录我踩过的那些深坑工程实践里最值钱的从来不是成功路径而是失败路径。这一章整理了我实际搭建 Agent 集群时遇到的高频问题以及对应排查思路。这些都是网上一般教程里不会写的内容。5.1 客户端配置了 MCP 却找不到服务“Codex 无法找到 MCP”这种问题在社区里已经成了日经贴。我排查下来80% 是下面几类原因现象可能原因排查思路客户端提示连接失败MCP Server 启动路径不对确认command可执行、args是绝对路径先手动在终端跑一遍看报错能启动但立即退出缺少 Python 环境变量确保使用当前项目的虚拟环境绝对路径比如uv run python -m mcp_server连接成功后工具列表为空stdio 模式与 HTTP 模式不匹配检查 Server 端 transport 是否和客户端配置一致stdio 和 sse 不能混用多个 Server 互相冲突端口或服务名重复给每个 Server 起独立服务名HTTP 模式分配不同端口一个特别容易被忽略的点当 MCP Server 是 Python 脚本时客户端里的command不能直接写python因为客户端的 PATH 环境可能不包含你的虚拟环境。建议写成/path/to/venv/bin/python或者用uv run显式指定。5.2 Skills 目录和权限声明惹的祸SKILL.md 不是放在任意目录就能被识别多数实现要求技能目录位于约定的根目录下且主文件名严格为SKILL.md。我见过有人把文件名写成skill.md或SKILL.MD结果 Agent 怎么都加载不到。名称大小写在部分系统上敏感建议统一全大写。另一个坑是权限声明。不少框架支持在 SKILL.md 的 frontmatter 里声明 allowed-tools 和 allowed-domain。一旦声明了Skill 执行时在权限名单外的工具会被拦截。刚开始建议把权限声明放宽跑通后再收紧否则“为什么 Skill 调不了工具”会浪费你半小时。还有工具名冲突同一个集群里两个 Skill 依赖了同名但不同作用的 MCP 工具容易互相覆盖。解决办法是 MCP Server 暴露的工具名尽量带业务前缀比如order_get、inventory_check避免泛化命名。5.3 Agent 之间状态不同步任务卡死A2A 引入了任务状态机但实际运行中两个 Agent 很容易因为状态不同步而互相等待。最典型的场景是Agent A 通过 A2A 给 Agent B 发了一个任务B 在处理过程中需要用户补充信息进入input-required状态。但如果 A 没有实现对这个状态的处理逻辑它会一直傻等最终超时。解决思路有两条一是 Agent A 在发起任务时明确声明自己能处理input-requiredB 一旦进入该状态A 会代为向用户提问并把答案传回去。这要求双方的 Agent Card 里把能力协议写得清清楚楚。二是网关层做超时兜底。不要无限等下去建议设置可配置的超时时间比如 60 秒。超时后把任务标记为失败并触发编排层的重试或降级策略。另外一个教训任务结果尽量结构化。A2A 虽然支持文本消息但如果是机器之间的协作直接传纯文本会让下游 Agent 解析困难。统一用 JSON 格式并且在 Agent Card 里声明字段定义能少非常多沟通成本。5.4 令牌、授权和数据边界问题MCP 生态火热之后安全问题被我排在第一位。最常见的问题是令牌泄露有人为了演示方便把带 token 的 WebSocket 地址、API Key 直接写进配置文件甚至推到公共仓库。这等于把家门钥匙放在脚垫下面风险极高。我见过连接 Figma MCP、蓝湖 MCP、同花顺 MCP 时授权模式搞混的情况。特别提醒像 Figma 这类 SaaS 工具的授权要区分“部署态”和“用户态”。部署态令牌是服务端运行专用权限也必须收敛建议只开最小必需的 scope用户态令牌属于终端用户应该在用户侧完成 OAuth 授权流程而不是拿一个全局令牌给所有用户共享。在集群内部每个 Agent 的身份也要清晰。A 调用 B 的能力时B 需要知道自己服务的调用方是谁、权限范围是什么。如果集群规模小可以在 A2A 网关层做简单的令牌认证规模一大建议上标准的服务间身份体系比如 mTLS 或者带签名的 JWT。多智能体系统的安全边界一定不能在最后一个环节才考虑要在一开始做进协议选择里。收尾就写到这里这几套东西我完整做了三版第一版被协议概念带着跑第二版被工具选型绊住脚第三版才真正把 MCP、Skills、A2A 和编排串成一条线。最大的感受是——任何一个被吹上天的名词放到工程里都只是一道选择题MCP 不是银弹A2A 也拯救不了没有清晰边界的系统。真正让 Agent 集群跑得稳的是你对业务任务域的拆解能力以及一套能兜住异常、管住权限的工程底座。如果你正准备从单 Agent 往集群方向走建议先别急着堆组件拿一个最简单的“查询-处理-汇总”流程把这一整套链路跑通再逐步往上加节点。路是一步步踩稳的集群也是一层层搭出来的。