尧图网站建设 
做 Agent 开发的人大概率都经历过这么一幕你辛辛苦苦把单个 Agent 调教得挺聪明会规划、会拆任务、会调工具、能写代码结果真要把它丢进业务流程里发现根本不够用。一个人干不完一个团队的活这是单 Agent 架构绕不过去的天花板。这篇文章写的是慕课上一门叫「DeepAgents MCP A2A Skills 超级多智能体」课程项目的核心内容沉淀目标很明确用 MCP 把 Agent 的手接长用 A2A 让 Agent 之间能对话派活用 Skills 把高频能力沉淀成可复用积木最后用 DeepAgents 把这一切串成一个可编排、可互通、可扩展的 Agent 集群。文章里没有照抄 PPT 的理论全是落地过程中真实踩过的机制、配置和坑适合已经跑通过单 Agent、正打算往多 Agent 集群方向走的开发者。下面按我的实操顺序来讲。1. 单 Agent 做得再聪明也只是一个人干活1.1 我踩过的单 Agent 天花板先说我自己踩过的坑。早期我做过一个能自动整理会议纪要、查数据库、发邮件的 Agent单跑起来体验相当好发出去给同事试用大家都觉得有点东西。但一旦把它真正放进公司业务流程里问题就全暴露了。工具越挂越多系统提示词越来越长模型开始遗忘某些工具的正确用法甚至自己在工具列表里瞎编参数。一个任务往往要串多个系统——查 CRM、算价格、写合同、走审批单个 Agent 的上下文窗口和推理带宽根本扛不住做到一半就开始胡说。出问题就是一锅端Agent 在第 8 步崩了前 7 步全白干如果中间还有写库、发消息这类有副作用的操作还得人工去擦屁股。这些问题的共性是把太多职责塞进了同一个 Agent。解决办法说起来也很简单——拆让多个 Agent 各干各的。但拆完以后更麻烦的问题来了Agent 之间怎么互相调用怎么共享工具怎么避免每个 Agent 都重复造一轮轮子这就完全进入了另一个复杂度层级也是多智能体和单 Agent最本质的区别。1.2 集群化绕不开的三个问题编排、互通、扩展把问题拆开看多 Agent 集群要解决的无非三件事。编排谁来决定任务怎么拆、每步交给谁、结果怎么汇这需要一层独立的大脑或者说控制面而不是让 Agent 们互相猜来猜去、抢活干。互通A Agent 需要的数据在 B 那里B 需要调的工具在 C 的机器上它们之间怎么互相发现、互相调用这需要一套跨语言、跨框架的标准通信协议。扩展今天集群里只有 3 个 Agent明天要加到 30 个今天只接 PostgreSQL明天要接企业微信。加一个组件能不能不动其他组件这需要标准化的插拔机制。课程给的答案就是标题里那四个词MCP 管工具互通A2A 管 Agent 互通Skills 管能力复用DeepAgents 管全局编排。这四个东西对应的解决的问题完全不同把它们的分工搞清楚整个集群的骨架就立起来了。2. 四层技术栈分工MCP 管手、A2A 管嘴、Skills 管脑、DeepAgents 管全局如果你在网上搜这四个概念很容易被各种术语绕晕。我建议用一句话记MCP 是 Agent 伸出去干活的手A2A 是 Agent 之间交流的嘴Skills 是 Agent 脑内积淀的经验DeepAgents 是统筹全局的神经中枢。各自解决一个层面千万别混为一谈。2.1 MCPAgent 与外部世界的标准插头MCP 全称 Model Context Protocol最早由 Anthropic 开源。它解决的问题非常具体过去 Agent 每接一个新工具都要为它单独写一套接入代码工具一多维护成本直接爆炸。MCP 的做法是把工具接入这件事标准化——工具方只需要实现一个 MCP Server对外暴露统一接口Agent 侧通过 MCP Client 去连接一套逻辑到处复用。打个比方MCP 之于工具就像 USB-C 接口之于电子设备。以前每个厂商一个充电口现在协议统一了插上就能用。在我这个项目里接入过的 MCP Server 包括文件系统类读写本地目录、处理 PDF、OCR、数据类PostgreSQL / MySQL / SQLite 查询查完直接返回结构化行数据、外部服务类GitHub 仓库操作、钉钉/企业微信通知、Figma 设计稿取数。社区里甚至有人把 IDA、x32dbg 都搓成了 MCP 插件用于逆向工程场景说明这套协议的生命力确实在爆发。现在连 Dify 这类低代码平台、ruoyi-vue-pro 这类后台管理脚手架都开始有人做 MCP 功能合并MCP 已经不只在 LLM 圈子里玩而是在渗透各种业务系统。接入方式上MCP Client 侧主要是配一个 JSON 配置文件框架里通常叫 mcp_config.json声明 server 的 name、command、args、env框架会自动完成握手、发现工具、按需调用。2.2 A2A让 Agent 之间真正能互相派活MCP 解决的是 Agent 到工具的问题但 Agent 到 Agent 的问题它管不了。A2AAgent2Agent协议解决的就是后者——它由 Google 在 2025 年提出后来捐给了 Linux 基金会核心目标是让不同厂商、不同框架的 Agent 能够互相发现、互相通信。A2A 协议里有两个关键概念。一个是 Agent Card相当于每个 Agent 的电子名片用 JSON 描述这个 Agent 能干什么、接受什么输入、产生什么输出供其他 Agent 发现和调用。另一个是 Task 生命周期A2A 把一次 Agent 之间的协作建模成一个 Task有明确的输入、状态pending、working、completed、failed、输出并且支持长任务的状态查询和消息流推送。我的理解是MCP 是命令式的你调工具、工具返回结果A2A 是会话式的Agent 之间可以来回协商、分派、汇报。两者定位差异非常清晰别拿 MCP 去做 Agent 间通信也别拿 A2A 去接数据库工具。另外在 Spring 生态里A2A 已经有 spring.ai.a2a 这样的现成 starterJava 后端团队的接入成本很低这也是为什么最近a2a spring的搜索热度突然很高。2.3 Skills把高频能力包成即插即用的积木Skills 这个概念Claude 的 Agent Skills 普及得很到位但说实话它并不神秘本质上就是把一段带指令的代码/脚本/模板打包成一个标准目录。目录里有一个 SKILL.md 写明技能说明、使用步骤、注意事项旁边放着可执行的脚本或参考文件。Agent 在需要时加载这个技能就能立刻按规范行事。这里的关键在于按需加载。如果你把所有能力的说明都塞进系统提示词上下文会被撑爆模型反而什么都干不好。Skills 的做法是渐进式披露——只有任务需要时才把相关技能目录内容加载进上下文。用起来很像人脑的肌肉记忆平时不占用注意力关键时刻自动调用。目录结构大概是这样的skills/ web-search/ SKILL.md search.py templates/query_guide.md pdf-report/ SKILL.md report_tool.pySKILL.md 里写清楚元信息name、description、适用场景、具体操作步骤和禁忌框架按需解析加载。现在社区里现成的 skills 是真的多GitHub 上find skillsskills 推荐这类关键词热度不减官方市场里也能直接装现成的技能包。很多团队开始把内部经验整理成 skills 发布前端开发的、代码审查的、写论文的都有下载下来就能直接用。这才是 skills 真正厉害的地方——经验可以打包、分发、复用。2.4 DeepAgents编排层把三条线串成一张网讲完三个协议/规范最后说 DeepAgents。这个名字在课程语境里指的是一套面向深度多智能体的编排框架与设计模式——它不生产具体的智能而是负责把 MCP、A2A、Skills 组合成一套可运行的集群。DeepAgents 的核心职责有三块读取全局任务并拆解为子任务根据 Agent Card 和能力注册信息把子任务分配给合适的 Agent汇合子结果、处理错误与重试产出最终答案。很多人分不清 harness脚手架和 agent 的区别我这里顺带说清楚harness 是跑 Agent 的脚手架负责处理 prompt 组装、模型调用、工具循环agent 是脚手架里干活的工人而 DeepAgents 更像是一套管理多个脚手架的集群运营体系。你可以把它理解成一个项目经理手下有前端 Agent、后端 Agent、数据 Agent、测试 Agent项目经理解活、派活、验活而不是自己亲自下手写代码。3. 集群架构落地控制面、执行面、注册中心如何分权理论讲完下面讲架构。这一节是我踩坑最多的地方——一开始我把所有逻辑都揉在一个进程里结果一扩展就乱。最终收敛下来的架构是严格区分控制面、执行面和注册中心三个角色。3.1 三个角色的职责边界注册中心Registry一台轻量服务维护所有 Agent 的 Agent Card、已挂载的 MCP Server 列表、Skills 目录索引。它不干活只管谁知道谁会什么。控制面Orchestrator接收用户请求拆任务、派活、收结果。它是最聪明的那个 Agent但聪明只用在决策上不直接碰工具。执行面Workers一批专职 Agent每个 Agent 挂载自己职责范围内的 MCP Server 和 Skills。比如数据 Agent 只挂数据库 MCP 和 SQL 分析 Skill前端 Agent 只挂浏览器 MCP 和组件生成 Skill。这个拆分最直接的好处某个 Worker 挂了控制面可以把它标记为不可用把任务转给其他同类 Worker整个集群不至于瘫痪。职责边界清晰也方便逐个调优——数据 Worker 慢就优化数据 Worker不会牵连到报告 Worker。3.2 从请求到结果能力注册与发现的完整流程用一个实际例子说明三者如何协作。假设用户说帮我看下这周的销售数据并写一份带图表的周报控制面 Agent 先解析任务拆成三个子任务查数据、算指标、生报告。控制面查询注册中心发现数据 Agent挂 PostgreSQL MCP和报告 Agent挂文件输出 MCP都在线。控制面通过 A2A 协议向数据 Agent 发起一个 Task传入 SQL 需求和参数。数据 Agent 通过 MCP 调用数据库工具拿到结构化结果再通过 A2A 的 Task 状态回调回报。报告 Agent 拿到数据后加载图表生成 Skill通过 MCP 写入文件返回报告路径。控制面汇总把最终结果返回给用户。这个流程里的每一步消息体都是标准化的。新增一个 Agent 时只要向注册中心登记自己的 Agent Card、挂好 MCP Server 和 Skills控制面就能在下一轮任务中发现并使用它——这就是可扩展的落地含义而不是写在方案里的一句口号。3.3 编排器的任务分解策略任务分解是编排器最核心的能力也直接决定集群的智商上限。课程里介绍的三角色模型我实践后很认同分析器把用户意图转化为目标清单判断需要哪些能力规划器生成 DAG有向无环图明确执行顺序和依赖关系调度器把 DAG 里的每个节点分配到具体的 Worker并跟踪执行状态。这里有一个血泪教训规划粒度太细Agent 之间的 A2A 通信次数爆炸延迟飙升粒度太粗单个 Agent 又退化回大而全的老问题。我目前的经验是子任务控制在一次 A2A 能完成、结果可独立验证的粒度最合适——宁可让执行面的每个 Agent 多做几步内部操作也尽量不要跨 Agent 做半步协作。跨 Agent 的每一次消息传递都是潜在的失败点和延迟点。3.4 三种通信模式怎么选部署形态上我分别试过三种通信模式列个表供参考模式适用场景优点缺点同进程内函数调用验证概念、学习阶段零延迟、好调试无法跨语言、无法水平扩展stdin/stdout 本地进程本机多 Agent、轻量生产进程隔离、故障不牵连不适合跨主机HTTP A2A 协议生产集群跨语言、跨主机、标准协议需要处理网络错误和重试课程项目最终走的是 HTTP A2A因为要演示的正是可互通的价值——不同语言写的 Agent 也能协作。这一点实操章节会详细展开。4. 从零跑通最小集群的实操记录下面进入动手环节。按最小可用的原则从空白环境搭出一套两个 Worker 一个控制面的集群。全程不依赖任何商业闭源组件都是开源工具和标准协议。4.1 环境准备与目录设计我用的是 Python 3.11 Node.js 20 的混合环境原因是有意让控制面和执行面跑在不同语言用来验证 A2A 的跨栈能力。本地需要装好Python 3.11用于实现 A2A 控制面和其中一个 WorkerNode.js 20用于实现另一个 Worker顺便演示跨语言互通一个 MCP Server 实例我选的是最常用的 Filesystem MCP一个支持 MCP Client 调用的 LLM 网关框架里一般内嵌选你熟悉的即可。目录结构建议这么搭agent-cluster/ orchestrator/ # 控制面 main.py planner.py workers/ >{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /workspace/data], env: {} } } }写完后data-worker 启动时框架会自动拉起这个子进程完成 MCP 握手。此时做个简单的冒烟测试让数据 Worker 列出 /workspace/data 目录。能返回目录列表说明 MCP 链路通了。这一步如果失败九成是 npx 下载依赖的网络问题或者目录权限问题先把这两点排除。这里要特别强调环境变量MCP Server 大多通过 env 传密钥数据库密码、API Key千万别直接写进代码仓库。我在课程项目里踩过这个坑后来统一改成环境变量注入配置文件和秘钥完全分离。生产集群里这一步是硬性要求。4.3 打通 A2A 双 Agent 会话接下来是重头戏让两个不同语言的 Worker 通过 A2A 互相通信。以 A2A 协议的开源参考实现为例每个 Worker 起一个 HTTP 端点对外暴露自己的 Agent Card。>{ name: data-worker, description: 负责数据库与文件数据操作可执行 SQL、读取目录, url: http://localhost:8001/a2a, skills: [sql-query, file-read], capabilities: { task: true, streaming: true } }report-worker 的 Agent Card 类似只是描述换成负责生成报告与图表。两个 worker 启动后访问它们的 /a2a 端点能看到各自的 Agent Card然后让控制面去调用控制面 POST 一个 Task 到> 多智能体集群实战：MCP、A2A与Skills如何协同构建DeepAgents编排体系
做 Agent 开发的人大概率都经历过这么一幕你辛辛苦苦把单个 Agent 调教得挺聪明会规划、会拆任务、会调工具、能写代码结果真要把它丢进业务流程里发现根本不够用。一个人干不完一个团队的活这是单 Agent 架构绕不过去的天花板。这篇文章写的是慕课上一门叫「DeepAgents MCP A2A Skills 超级多智能体」课程项目的核心内容沉淀目标很明确用 MCP 把 Agent 的手接长用 A2A 让 Agent 之间能对话派活用 Skills 把高频能力沉淀成可复用积木最后用 DeepAgents 把这一切串成一个可编排、可互通、可扩展的 Agent 集群。文章里没有照抄 PPT 的理论全是落地过程中真实踩过的机制、配置和坑适合已经跑通过单 Agent、正打算往多 Agent 集群方向走的开发者。下面按我的实操顺序来讲。1. 单 Agent 做得再聪明也只是一个人干活1.1 我踩过的单 Agent 天花板先说我自己踩过的坑。早期我做过一个能自动整理会议纪要、查数据库、发邮件的 Agent单跑起来体验相当好发出去给同事试用大家都觉得有点东西。但一旦把它真正放进公司业务流程里问题就全暴露了。工具越挂越多系统提示词越来越长模型开始遗忘某些工具的正确用法甚至自己在工具列表里瞎编参数。一个任务往往要串多个系统——查 CRM、算价格、写合同、走审批单个 Agent 的上下文窗口和推理带宽根本扛不住做到一半就开始胡说。出问题就是一锅端Agent 在第 8 步崩了前 7 步全白干如果中间还有写库、发消息这类有副作用的操作还得人工去擦屁股。这些问题的共性是把太多职责塞进了同一个 Agent。解决办法说起来也很简单——拆让多个 Agent 各干各的。但拆完以后更麻烦的问题来了Agent 之间怎么互相调用怎么共享工具怎么避免每个 Agent 都重复造一轮轮子这就完全进入了另一个复杂度层级也是多智能体和单 Agent最本质的区别。1.2 集群化绕不开的三个问题编排、互通、扩展把问题拆开看多 Agent 集群要解决的无非三件事。编排谁来决定任务怎么拆、每步交给谁、结果怎么汇这需要一层独立的大脑或者说控制面而不是让 Agent 们互相猜来猜去、抢活干。互通A Agent 需要的数据在 B 那里B 需要调的工具在 C 的机器上它们之间怎么互相发现、互相调用这需要一套跨语言、跨框架的标准通信协议。扩展今天集群里只有 3 个 Agent明天要加到 30 个今天只接 PostgreSQL明天要接企业微信。加一个组件能不能不动其他组件这需要标准化的插拔机制。课程给的答案就是标题里那四个词MCP 管工具互通A2A 管 Agent 互通Skills 管能力复用DeepAgents 管全局编排。这四个东西对应的解决的问题完全不同把它们的分工搞清楚整个集群的骨架就立起来了。2. 四层技术栈分工MCP 管手、A2A 管嘴、Skills 管脑、DeepAgents 管全局如果你在网上搜这四个概念很容易被各种术语绕晕。我建议用一句话记MCP 是 Agent 伸出去干活的手A2A 是 Agent 之间交流的嘴Skills 是 Agent 脑内积淀的经验DeepAgents 是统筹全局的神经中枢。各自解决一个层面千万别混为一谈。2.1 MCPAgent 与外部世界的标准插头MCP 全称 Model Context Protocol最早由 Anthropic 开源。它解决的问题非常具体过去 Agent 每接一个新工具都要为它单独写一套接入代码工具一多维护成本直接爆炸。MCP 的做法是把工具接入这件事标准化——工具方只需要实现一个 MCP Server对外暴露统一接口Agent 侧通过 MCP Client 去连接一套逻辑到处复用。打个比方MCP 之于工具就像 USB-C 接口之于电子设备。以前每个厂商一个充电口现在协议统一了插上就能用。在我这个项目里接入过的 MCP Server 包括文件系统类读写本地目录、处理 PDF、OCR、数据类PostgreSQL / MySQL / SQLite 查询查完直接返回结构化行数据、外部服务类GitHub 仓库操作、钉钉/企业微信通知、Figma 设计稿取数。社区里甚至有人把 IDA、x32dbg 都搓成了 MCP 插件用于逆向工程场景说明这套协议的生命力确实在爆发。现在连 Dify 这类低代码平台、ruoyi-vue-pro 这类后台管理脚手架都开始有人做 MCP 功能合并MCP 已经不只在 LLM 圈子里玩而是在渗透各种业务系统。接入方式上MCP Client 侧主要是配一个 JSON 配置文件框架里通常叫 mcp_config.json声明 server 的 name、command、args、env框架会自动完成握手、发现工具、按需调用。2.2 A2A让 Agent 之间真正能互相派活MCP 解决的是 Agent 到工具的问题但 Agent 到 Agent 的问题它管不了。A2AAgent2Agent协议解决的就是后者——它由 Google 在 2025 年提出后来捐给了 Linux 基金会核心目标是让不同厂商、不同框架的 Agent 能够互相发现、互相通信。A2A 协议里有两个关键概念。一个是 Agent Card相当于每个 Agent 的电子名片用 JSON 描述这个 Agent 能干什么、接受什么输入、产生什么输出供其他 Agent 发现和调用。另一个是 Task 生命周期A2A 把一次 Agent 之间的协作建模成一个 Task有明确的输入、状态pending、working、completed、failed、输出并且支持长任务的状态查询和消息流推送。我的理解是MCP 是命令式的你调工具、工具返回结果A2A 是会话式的Agent 之间可以来回协商、分派、汇报。两者定位差异非常清晰别拿 MCP 去做 Agent 间通信也别拿 A2A 去接数据库工具。另外在 Spring 生态里A2A 已经有 spring.ai.a2a 这样的现成 starterJava 后端团队的接入成本很低这也是为什么最近a2a spring的搜索热度突然很高。2.3 Skills把高频能力包成即插即用的积木Skills 这个概念Claude 的 Agent Skills 普及得很到位但说实话它并不神秘本质上就是把一段带指令的代码/脚本/模板打包成一个标准目录。目录里有一个 SKILL.md 写明技能说明、使用步骤、注意事项旁边放着可执行的脚本或参考文件。Agent 在需要时加载这个技能就能立刻按规范行事。这里的关键在于按需加载。如果你把所有能力的说明都塞进系统提示词上下文会被撑爆模型反而什么都干不好。Skills 的做法是渐进式披露——只有任务需要时才把相关技能目录内容加载进上下文。用起来很像人脑的肌肉记忆平时不占用注意力关键时刻自动调用。目录结构大概是这样的skills/ web-search/ SKILL.md search.py templates/query_guide.md pdf-report/ SKILL.md report_tool.pySKILL.md 里写清楚元信息name、description、适用场景、具体操作步骤和禁忌框架按需解析加载。现在社区里现成的 skills 是真的多GitHub 上find skillsskills 推荐这类关键词热度不减官方市场里也能直接装现成的技能包。很多团队开始把内部经验整理成 skills 发布前端开发的、代码审查的、写论文的都有下载下来就能直接用。这才是 skills 真正厉害的地方——经验可以打包、分发、复用。2.4 DeepAgents编排层把三条线串成一张网讲完三个协议/规范最后说 DeepAgents。这个名字在课程语境里指的是一套面向深度多智能体的编排框架与设计模式——它不生产具体的智能而是负责把 MCP、A2A、Skills 组合成一套可运行的集群。DeepAgents 的核心职责有三块读取全局任务并拆解为子任务根据 Agent Card 和能力注册信息把子任务分配给合适的 Agent汇合子结果、处理错误与重试产出最终答案。很多人分不清 harness脚手架和 agent 的区别我这里顺带说清楚harness 是跑 Agent 的脚手架负责处理 prompt 组装、模型调用、工具循环agent 是脚手架里干活的工人而 DeepAgents 更像是一套管理多个脚手架的集群运营体系。你可以把它理解成一个项目经理手下有前端 Agent、后端 Agent、数据 Agent、测试 Agent项目经理解活、派活、验活而不是自己亲自下手写代码。3. 集群架构落地控制面、执行面、注册中心如何分权理论讲完下面讲架构。这一节是我踩坑最多的地方——一开始我把所有逻辑都揉在一个进程里结果一扩展就乱。最终收敛下来的架构是严格区分控制面、执行面和注册中心三个角色。3.1 三个角色的职责边界注册中心Registry一台轻量服务维护所有 Agent 的 Agent Card、已挂载的 MCP Server 列表、Skills 目录索引。它不干活只管谁知道谁会什么。控制面Orchestrator接收用户请求拆任务、派活、收结果。它是最聪明的那个 Agent但聪明只用在决策上不直接碰工具。执行面Workers一批专职 Agent每个 Agent 挂载自己职责范围内的 MCP Server 和 Skills。比如数据 Agent 只挂数据库 MCP 和 SQL 分析 Skill前端 Agent 只挂浏览器 MCP 和组件生成 Skill。这个拆分最直接的好处某个 Worker 挂了控制面可以把它标记为不可用把任务转给其他同类 Worker整个集群不至于瘫痪。职责边界清晰也方便逐个调优——数据 Worker 慢就优化数据 Worker不会牵连到报告 Worker。3.2 从请求到结果能力注册与发现的完整流程用一个实际例子说明三者如何协作。假设用户说帮我看下这周的销售数据并写一份带图表的周报控制面 Agent 先解析任务拆成三个子任务查数据、算指标、生报告。控制面查询注册中心发现数据 Agent挂 PostgreSQL MCP和报告 Agent挂文件输出 MCP都在线。控制面通过 A2A 协议向数据 Agent 发起一个 Task传入 SQL 需求和参数。数据 Agent 通过 MCP 调用数据库工具拿到结构化结果再通过 A2A 的 Task 状态回调回报。报告 Agent 拿到数据后加载图表生成 Skill通过 MCP 写入文件返回报告路径。控制面汇总把最终结果返回给用户。这个流程里的每一步消息体都是标准化的。新增一个 Agent 时只要向注册中心登记自己的 Agent Card、挂好 MCP Server 和 Skills控制面就能在下一轮任务中发现并使用它——这就是可扩展的落地含义而不是写在方案里的一句口号。3.3 编排器的任务分解策略任务分解是编排器最核心的能力也直接决定集群的智商上限。课程里介绍的三角色模型我实践后很认同分析器把用户意图转化为目标清单判断需要哪些能力规划器生成 DAG有向无环图明确执行顺序和依赖关系调度器把 DAG 里的每个节点分配到具体的 Worker并跟踪执行状态。这里有一个血泪教训规划粒度太细Agent 之间的 A2A 通信次数爆炸延迟飙升粒度太粗单个 Agent 又退化回大而全的老问题。我目前的经验是子任务控制在一次 A2A 能完成、结果可独立验证的粒度最合适——宁可让执行面的每个 Agent 多做几步内部操作也尽量不要跨 Agent 做半步协作。跨 Agent 的每一次消息传递都是潜在的失败点和延迟点。3.4 三种通信模式怎么选部署形态上我分别试过三种通信模式列个表供参考模式适用场景优点缺点同进程内函数调用验证概念、学习阶段零延迟、好调试无法跨语言、无法水平扩展stdin/stdout 本地进程本机多 Agent、轻量生产进程隔离、故障不牵连不适合跨主机HTTP A2A 协议生产集群跨语言、跨主机、标准协议需要处理网络错误和重试课程项目最终走的是 HTTP A2A因为要演示的正是可互通的价值——不同语言写的 Agent 也能协作。这一点实操章节会详细展开。4. 从零跑通最小集群的实操记录下面进入动手环节。按最小可用的原则从空白环境搭出一套两个 Worker 一个控制面的集群。全程不依赖任何商业闭源组件都是开源工具和标准协议。4.1 环境准备与目录设计我用的是 Python 3.11 Node.js 20 的混合环境原因是有意让控制面和执行面跑在不同语言用来验证 A2A 的跨栈能力。本地需要装好Python 3.11用于实现 A2A 控制面和其中一个 WorkerNode.js 20用于实现另一个 Worker顺便演示跨语言互通一个 MCP Server 实例我选的是最常用的 Filesystem MCP一个支持 MCP Client 调用的 LLM 网关框架里一般内嵌选你熟悉的即可。目录结构建议这么搭agent-cluster/ orchestrator/ # 控制面 main.py planner.py workers/ >{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /workspace/data], env: {} } } }写完后data-worker 启动时框架会自动拉起这个子进程完成 MCP 握手。此时做个简单的冒烟测试让数据 Worker 列出 /workspace/data 目录。能返回目录列表说明 MCP 链路通了。这一步如果失败九成是 npx 下载依赖的网络问题或者目录权限问题先把这两点排除。这里要特别强调环境变量MCP Server 大多通过 env 传密钥数据库密码、API Key千万别直接写进代码仓库。我在课程项目里踩过这个坑后来统一改成环境变量注入配置文件和秘钥完全分离。生产集群里这一步是硬性要求。4.3 打通 A2A 双 Agent 会话接下来是重头戏让两个不同语言的 Worker 通过 A2A 互相通信。以 A2A 协议的开源参考实现为例每个 Worker 起一个 HTTP 端点对外暴露自己的 Agent Card。>{ name: data-worker, description: 负责数据库与文件数据操作可执行 SQL、读取目录, url: http://localhost:8001/a2a, skills: [sql-query, file-read], capabilities: { task: true, streaming: true } }report-worker 的 Agent Card 类似只是描述换成负责生成报告与图表。两个 worker 启动后访问它们的 /a2a 端点能看到各自的 Agent Card然后让控制面去调用控制面 POST 一个 Task 到>