DeepAgents组合拳：用MCP、A2A、Skills构建多Agent集群-平芜编程栈

1. 先拆解这个标题到底在说什么

如果你最近关注AI Agent开发，一定被这几个词反复刷屏：DeepAgents、MCP、A2A、Skills。说实话，我第一次把这四个词放到一起时也有点懵——每一个单独拎出来都能讲半天，组合在一起更像是一个“既要又要还要”的技术愿景。但真正上手做过Agent项目的人，三分钟就能明白这个标题背后的痛点在哪。

我之前的项目是这样的：公司要做一个内部AI助手，能查数据库、能看工单、能对接企业微信机器人、还能调外部天气接口。一开始我按老办法，每个工具写一个Python函数，硬编码在Agent的Prompt里让模型自己选。结果呢？Agent的上下文长度被我塞爆，工具参数格式不统一，换一个模型就得重调所有调用逻辑，最难受的是公司另一个小组也在做类似的事，我们各写了一套工具调用，完全没法互通。这就是没有协议和标准化的下场。

后来我彻底重构了一版，用的就是标题里这套组合思路：MCP统一工具接入，A2A打通Agent之间的通信，Skills沉淀可复用的能力，再用编排层把多个Agent组合成集群。跑通之后，整个系统从“一个什么都会一点的单体机器人”变成了“一群各司其职、能互相调度的智能体团队”。这篇内容就是把我重构过程中踩过的坑、验证过的方案、实际能落地的配置完整梳理出来，适合正在做多Agent系统、或者想从单体Agent升级到可编排集群的开发者参考。

我先用一句话说清楚它们各自解决什么问题：

MCP（Model Context Protocol）：解决Agent“用什么工具”的问题——统一接入外部数据和工具，规范化工具描述和调用协议。
A2A（Agent-to-Agent）：解决Agent“怎么互相配合”的问题——让不同Agent能发现彼此、派发任务、回传结果。
Skills：解决Agent“具备什么能力”的问题——把一套可复用的知识、步骤、规则打包成标准化能力单元。
DeepAgents：解决Agent“如何自主决策”的问题——让Agent具备任务拆解、规划执行、长上下文处理的能力，充当集群中的核心执行体。

这套组合想做的事情就一句话：把Agent从一个个孤立的“对话接口”，升级成可观测、可管理、可扩展的分布式智能体网络。

2. 架构设计：从单体Agent到智能体集群的关键拆解

2.1 单体Agent的瓶颈：所有事情都塞给一个大脑

先说说为什么非要做集群。很多人一开始觉得，一个Agent让模型多轮思考、配上ReAct框架，不就能干所有事了吗？确实能，但只是在小规模、低复杂度场景下能。

我用过一个对比很直观：单体Agent就像一家公司里只有一个“全能员工”，你什么都问他，他的办公桌（上下文窗口）堆满了文件，他联系的每个系统（工具）都要靠人肉翻译（自定义封装）。一旦任务变多：

上下文窗口被工具描述、历史记录、中间推理占满，真正有用的业务信息反而塞不进去；
每次新增工具都要改Prompt、改JSON Schema、改调用后处理逻辑，改一处动全身；
Agent在长链路任务中容易出现“遗忘”——第一轮规划好的事，第三轮就忘了关键约束；
没有并发隔离，一个新任务正在执行，另一个任务又挤进来，互相污染上下文。

而集群化的核心思路是“拆分+协作”：让专门Agent负责专门领域，由编排层统一调度。每个Agent只需要维护自己的上下文、自己的工具清单、自己的Skills库，体量小、响应快、可以独立扩展。

2.2 一个类比：MCP+A2A+Skills 如何组成团队

我用“跨部门项目组”来类比这四者的关系：

DeepAgents编排器= 项目经理，负责拆解用户需求、分派任务、汇总结果；
MCP服务器= 公司的标准化接口系统——每个部门（数据、工单、邮件）都按同一套接口规范暴露能力，项目经理不需要关心每个系统内部的调用细节；
A2A协议= 部门间的协作流程，A部门做完一件事，按标准格式把任务单传给B部门；
Skills= 员工培训和SOP手册，把那些“怎么做好一件事”的经验固化成标准作业流程。

有人可能要问，MCP不是已经能让Agent调用外部工具了吗？为什么还要A2A？因为MCP是“Agent调用工具”，A2A是“Agent调用Agent”。这两者是不同层级的关系，不是替代关系。MCP是纵向的，连接Agent与外部资源；A2A是横向的，连接Agent与Agent。

再说的直白一点：如果一个任务需要调用两个不太相关的工具，比如先查天气再查航班，MCP就够了。但如果一个任务需要“先让规划Agent生成方案，再让研究员Agent收集资料，最后让报告Agent汇总输出”，这中间流转的是任务状态和结果内容，单纯靠工具调用协议是表达不清楚的，就必须有A2A这种Agent间通信协议。

2.3 四层架构：协议栈的分工边界

我落地时的分层大概是这样的：

层级	组件	职责	典型实现
编排层	DeepAgents编排器	任务拆解、路由、状态管理	LangGraph / 自研编排器
通信层	A2A协议	Agent与Agent之间的任务分发、结果回传	A2A SDK / HTTP JSON-RPC
工具层	MCP服务器	统一接入外部工具、API、数据库	FastMCP / Python SDK
能力层	Skills	沉淀可复用的知识流程与操作规范	SKILL.md + 配套资源目录

这个分层的关键在于：每一层只关心自己的事，互相之间通过标准协议沟通。当你需要新增一个Agent时，只需要实现A2A接口、挂上自己的MCP工具和Skills，改动只局限在一个模块内部；当你需要新增一种工具时，写一个MCP服务器，注册到网关；完全不影响其他Agent。这就是“可扩展”的真正含义——不是加功能，而是加节点。

3. 核心机制逐个拆：MCP、A2A、Skills到底怎么用

3.1 MCP：Agent的工具插线板

MCP我从实际使用角度讲三个要点：架构角色、传输方式、注册流程。

MCP架构里三个角色：Host（Agent宿主程序）、Client（宿主内与服务器建立连接的客户端）、Server（暴露工具资源的服务器）。说白了，Agent是Host，它内部会启动一个Client，Client负责与各个MCP Server建立连接、列举资源、调用工具。

传输层目前主流就两种：

stdio：Agent与MCP Server走标准输入输出，适合本地启动的子进程式服务器，配置简单，适合局域网内自己用；
Streamable HTTP：通过HTTP端点暴露，适合远程部署、跨服务调用，也是目前多Agent集群场景下的首选。

我的建议是，生产环境尽量用Streamable HTTP，原因很直接：stdio服务器生命周期跟随Agent宿主，Agent挂了工具也跟着挂了，而且无法被多个Agent共享。HTTP端点则可以独立部署、独立扩容，多个Agent可以同时连一个工具服务。后面我实操部分就是用HTTP模式部署的。

一个MCP服务器核心就是三件事：定义tools（工具描述）、处理call_tool（工具调用）、返回结构化响应。用FastMCP写一个工具几乎是模板化的。跑通一次之后，后面加工具就是往里填函数。

另外，MCP里资源（Resources）和提示词（Prompts）也值得提一下。Resources适合暴露非工具类的读数据，比如把一份文档、一个配置文件暴露给模型；Prompts可以预置“怎么使用这个服务器”的指令片段。做复杂服务器时，三者配合能显著降低模型对工具用法的理解成本。

3.2 A2A：Agent与Agent之间怎么互相“派活”

A2A协议的核心概念有这么几个：Agent Card（能力名片）、Task（任务实体）、Message（消息）、Artifact（产物）、Part（内容分片）。

A2A对我的价值在于它定义了一套标准的“Agent对接Agent”语义：

Agent Card是一个JSON描述文件，包含Agent名称、能力说明、端点地址。其他Agent拿到这个Card就能知道“这个Agent能做什么、怎么调”。
Task是通信的基本单元。一个客户端Agent向服务端Agent发出tasks/send请求，传入任务内容；服务端Agent返回任务状态（如completed、failed）和产物。异步场景下还有tasks/get轮询，或者用SSE订阅任务状态变化。
Message和Part定义了消息结构，Part内可以携带文本、文件、结构化数据，且能标记内容的类型。

刚才说过A2A和MCP是互补的。实际场景里，每个Agent内部用MCP接自己的工具，Agent之间用A2A互通消息。换句话说，MCP管“Agent能调用哪些资源”，A2A管“Agent能请求哪些其他Agent”。

如果你用Spring开发后端，社区已经有A2A的Spring实现，把Agent定义成Bean、暴露成HTTP服务。C++也有对应的SDK支持。所以语言不是大问题，关键是遵循协议。我在项目里用Python实现了一个轻量级A2A服务端，本质上就是在FastAPI里实现几个JSON-RPC端点：tasks/send、tasks/get、tasks/cancel，然后提供一个符合规范的Card JSON。就这么简单。

3.3 Skills：Agent能力的标准化封装

Skills这个词在Anthropic的Agent Skills规范出来之后火了一波。所谓Skill，本质上是一套带特定结构的目录：一个SKILL.md文件作为入口，里面用frontmatter写name、description，正文部分写这个技能的详细使用步骤、规则、注意事项，还可以附带脚本、模板、示例文件。

它和MCP Tools的区别很重要。MCP Tool是一个可调用的具体函数，比如get_weather(city)；Skills是一套“做事情的方法论”，它最终会指导模型怎么去调用一个或多个工具、按照什么顺序处理信息、输出什么格式。

举个例子。我做一个“竞品分析”Skill，SKILL.md里写了：

获取竞品官网信息；
用搜索工具收集用户评价；
按SWOT框架整理输出。

这里每一步都对应工具调用，但Skill本身封装的是“分析流程”，不是单个工具。所以Skill可以理解成“把优秀经验固化下来，让任何Agent都能复现同样高质量的工作方式”。

我在实际项目中踩过一个坑：一开始把方法论写进系统Prompt，结果改一版Prompt就要重新测试整个链路，非常痛苦。改成Skill之后，按需加载，不同任务加载不同Skill，上下文只塞当前需要的，效率提升很明显。

现在GitHub上已经有大量Skills市场，官方也出了Marketplace机制，类似npm的Agent技能生态正在形成。你可以直接下载别人写好的Skills，也可以自己写Skill发布。我在团队里推的规范是：每个Agent必须把常用的工作流程沉淀成Skill，不允许只写在个人笔记里。

4. 实操落地：搭一个最小可运行的DeepAgents集群

4.1 搭建目标与总体流程

纸上谈兵讲了这么多，现在进入能直接抄作业的部分。我搭了一个最小集群，包含三个Agent：调度Agent（负责入口与规划）、搜索Agent（负责信息检索）、报表Agent（负责生成汇总）。其中一个Agent通过MCP接入两个外部工具，Agent之间通过A2A通信，公共能力用Skills封装。

整个流程分五步：

搭建MCP服务器并暴露HTTP端点；
编写Skill目录并接入Agent上下文；
实现A2A服务端和Agent Card；
编写调度Agent完成Task分发；
联调测试并验证全链路。

我用Python来实现，主要依赖：FastMCP（搭建MCP服务器）、FastAPI（搭建A2A HTTP服务）、LangGraph（编排调度逻辑）。你也可以换成你熟悉的框架，核心逻辑是一致的。

4.2 第一步：搭建MCP服务器

我先建了一个最简单的信息查询MCP服务器，暴露两个工具：

search_web(query)：模拟一个搜索引擎接口，返回相关链接列表；
fetch_article(url)：抓取文章内容并提取正文摘要。

用FastMCP实现大致是这个样子：

from fastmcp import FastMCP mcp = FastMCP( "InfoService", host="0.0.0.0", port=8001, transport="streamable-http", # 关键：使用HTTP模式 ) @mcp.tool() def search_web(query: str) -> list[dict]: """搜索引擎查询，返回相关链接与标题""" # 实际场景中可接入SerpAPI、Bing API等 return [ {"title": f"{query} - 相关结果1", "url": "https://example.com/1"}, {"title": f"{query} - 相关结果2", "url": "https://example.com/2"}, ] @mcp.tool() def fetch_article(url: str) -> dict: """抓取文章内容并返回摘要""" # 实际可调用爬虫或Jina Reader return {"url": url, "content": "文章摘要内容示例"} if __name__ == "__main__": mcp.run()

注意这里我用的是transport="streamable-http"，而不是默认的stdio模式。这在多Agent场景下非常关键：单独启动该服务后，其他Agent可以通过HTTP端点http://localhost:8001/mcp访问这些工具，而不是依赖某个Agent的进程内环境。

我需要再强调一下为什么这样设计：如果你用stdio的MCP服务器，只在某个Agent内部可用；改成HTTP模式后，它实际上变成了一个对集群内所有Agent开放的公共工具服务。这个差异在多Agent场景里是本质性的。

4.3 第二步：让Agent上下文支持Skills

接着我建了一个skills/目录，每类能力一个子目录，里面包含SKILL.md。这就是Agent Skills的标准结构，Anthropic官方规范就是这个思路，现在很多框架也都支持直接读取这个结构：

skills/ ├── deep_research/ │ ├── SKILL.md │ ├── templates/ │ └── examples/ └── weekly_report/ ├── SKILL.md └── scripts/

一个SKILL.md文件长这样：

--- name: deep_research description: 用于从互联网收集信息，整理成结构化研究报告。适合竞品调研、行业分析等场景。 --- # 深度调研技能 1. 先调用 search_web 获取相关主题的信息来源 2. 对每个有价值的来源调用 fetch_article 获取全文 3. 提取关键信息：数据、观点、趋势 4. 按照"摘要、核心发现、数据支撑、结论"的格式输出

在实际开发Agent时，这个skills/目录会被作为Reference注入到Prompt里，或者通过检索按需加载。这样Agent就知道它有哪些可用能力，并且知道每个能力的具体执行流程。

这里有一个我踩过的坑要提醒大家：不要把所有Skill一骨碌全塞进上下文。每个Skill的正文几百字到几千字不等，十几个Skill全部加载下来，上下文就废了。正确做法是让Agent先看Skill的description，根据当前任务加载相关的1-2个完整Skill正文。这就是Skills检索增强，类似于RAG的思路。

4.4 第三步：实现A2A服务端与Agent Card

接下来我实现了一个A2A兼容服务端。A2A协议的传输层本质是JSON-RPC 2.0，我基于FastAPI自己实现了一个轻量版本。核心是暴露tasks/send端点：

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI(title="SearchAgent") class TaskMessage(BaseModel): task_id: str message: dict @app.post("/a2a/tasks/send") async def send_task(req: TaskMessage): # 实际逻辑：接收调度Agent发来的搜索任务 result = process_search_task(req.message) return { "id": req.task_id, "status": "completed", "artifacts": [ {"name": "result.md", "content": result} ] } @app.get("/.well-known/agent-card.json") async def agent_card(): return { "name": "search-agent", "description": "负责信息检索与来源收集", "skills": ["deep_research"], "endpoints": ["/a2a/tasks/send"], "version": "1.0.0" }

这个/.well-known/agent-card.json就是Agent Card的存放位置，类似Web世界的robots.txt。其他Agent可以通过读取这个Card知道“这个Agent叫什么、擅长什么、端点是什么”。这是A2A协议设计中很关键的一点，整个Agent发现机制就是靠这个Card文件。

我在实操中发现，虽然A2A规范里定义了复杂的Task生命周期（submitted、working、completed、failed等状态），但最小实现其实只要实现send和get两个端点就够跑通了。复杂的cancel、progress等功能可以后续按需加。

4.5 第四步：编排Agent的Task分发逻辑

所有子Agent就绪后，最后是顶层调度Agent。它的职责是：

接收用户输入；
判断任务类型；
决定是自己直接调用MCP工具，还是把子任务通过A2A派发给其他Agent；
汇总结果，输出最终答案。

我用LangGraph做了一个简单编排，核心思路是让大模型输出一个结构化计划，然后代码按计划执行。一个关键动作是：编排器通过agent-card.json获取可用Agent列表，这是动态发现的。当集群里新注册了一个数据Agent，编排器下一次就能自动感知到，不需要改代码。

a2a_clients = discover_agents("http://internal-registry:8000/agents") # 返回 [{ # "name": "search-agent", # "endpoint": "http://search-agent:8101/a2a/tasks/send" # }, ...]

然后按任务类型路由。

到这一步，你就可以看到一个典型的跨Agent协作流程了：

用户输入“帮我调研一下AI编码工具的最新趋势” → 调度Agent判断需要搜索 → 发起A2A请求到搜索Agent → 搜索Agent内部使用MCP工具search_web和fetch_article收集信息 → 返回结构化结果 → 调度Agent生成最终报告。

这个链路里每个技术都找到了自己的位置：MCP在子Agent内部打通工具，A2A在子Agent之间传递任务，Skills规范了子Agent处理任务的方法，DeepAgents编排器控制了整体流程。

4.6 性能与配置优化的几个实测数据

整个集群在本机跑通之后，我做了几轮压测，把热词里大家关心的“ai agent怎么扛并发”这个问题也整理了出来：

瓶颈往往在MCP服务器，因为工具调用是IO密集操作。我用简单连接池把并发从5提升到50，关键在于复用HTTP会话；
A2A的Task状态轮询会占用大量请求。长任务用轮询没问题，但短任务直接把结果在tasks/send响应里返回更高效，避免多一轮请求；
上下文管理是硬伤。实测发现，调度Agent如果保留所有子Agent的完整产出，上下文很快会爆。我的方案是：调度Agent只保留子Agent产出的摘要和关键结论，原始全文写入本地文件，用户需要时再按需读取。

还有一点和模型选型相关的经验：集群里不同Agent用不同模型是合理的。调度Agent建议用推理能力强的大模型（比如带深度思考能力的），因为它负责规划；子Agent可以用响应快的小模型，因为它们的任务边界已经通过Prompt和Skills收窄了，不需要太强的全局推理能力。

5. 常见问题与排查技巧实录

5.1 问题速查表

下面这份排查清单全部来源于我实际跑集群时遇到的真实报错，按出现频率排序：

问题现象	可能原因	解决方案
MCP服务器启动正常，但Agent找不到工具	传输模式不匹配，Agent端用stdio配置去连HTTP端点	统一配置为`streamable-http`，检查`endpoint`地址是否带`/mcp`路径
A2A请求一直超时	子Agent的HTTP服务没注册到服务中心，或者编排器拿到了错误地址	启动时校验Agent Card可达性，用`curl`测试`tasks/send`端点
Agent执行Skill时步骤错乱，跳过关键步骤	SKILL.md的步骤说明不够结构化，模型自由发挥空间太大	在Skill里用“必须/禁止”等约束词，把步骤写成强制有序列表
多Agent并发调用同一MCP工具时互相阻塞	MCP服务器的连接池太小	换成Streamable HTTP模式并配置连接池，或者用异步处理
调度Agent上下文爆炸	把所有子Agent的完整产出都保留了	只保留摘要，完整内容落盘，按需读取
Agent反复调用同一个失败工具，不停重试	缺少错误反馈机制	在工具返回中附带`error`字段，告诉Agent该换一种方案

5.2 我踩过的三个深刻的坑

第一个坑：MCP工具的返回数据塞满上下文。

我第一次接入搜索工具时，把搜索结果和文章全文直接从工具返回到Agent上下文。结果一个调研任务跑下来，上下文里堆了几万字原始资料，后续生成报告时模型已经“记不住”最初的任务要求了。后来我把工具返回改成“压缩信息+全文落盘”，工具只返回标题、摘要和文件路径，Agent需要特定信息时再通过read_file工具读取。

第二个坑：A2A协议里Task ID必须全局唯一，否则状态会串。

我一度用自增数字当Task ID，结果两个子Agent同时运行，任务状态全部错乱。改成uuid4之后一切正常。这看着像个低级错误，但实际在分布式系统里，ID设计问题真的会晚上做梦都梦见。

第三个坑：Skills写得太抽象，等于没写。

我写过一份描述为“分析市场机会”的Skill，正文只有三句话。模型看了等于没看，输出质量一点没提升。后来我把Skill改成了带明确判断标准、输出模板、检查清单的版本，效果立竿见影。Skill不是写给程序员看的文档，是写给模型看的标准作业程序，必须足够具体、足够可执行。

5.3 关于调试，强烈建议做的三件事

给A2A配一个可视化页面。我后来给集群加了一个简单的状态看板，能直接看到每个Agent当前执行的任务、运行状态、Token消耗。排查问题的时候，能直观看到任务卡在哪一跳，比瞎猜效率高太多了。
MCP服务器一定要能单独测试。用mcp-inspector或直接Curl调用工具，确认工具本身没问题再接入Agent。不然Agent调用失败了，你分不清是模型选错了工具还是工具本身bug。
日志里打上Task ID和Agent名。这是分布式系统的基础素养，但真的很多人忽略。多Agent联调时，没有Trace ID，日志就是一团乱麻。

6. 最后分享一点我的体会

做这套东西的过程中，我最大的感受是：Agent领域的“标准化红利”才刚刚开始。MCP解决了工具接入的碎片化问题，A2A正在解决Agent互联的碎片化问题，Skills市场则试图解决能力复用的碎片化问题。这个演进路径很像当年Web开发从“每个网站自己写一套HTTP解析”走向“统一协议+框架生态”的过程。

我个人觉得，接下来半年内，多Agent集群会成为企业AI落地的常规形态，而不是少数人玩的概念。现在动手搭建一个最小的MCP+A2A+Skills集群，比到时候再仓促追赶要划算得多。

最后再留一个小经验：不要一开始就追求架构的完备性。先用最简单的模式让两个Agent、一个MCP工具、一个Skill跑通全链路。架构的复杂度跟着业务需要慢慢长，这才是最稳的方式。