做过多智能体集群的人应该都有同感单体Agent跑得很欢一旦凑成集群立刻变成三个和尚没水喝。DeepAgents、MCP、A2A、Skills这四个词单独看都懂真正把它们拧成一套能跑的多智能体集群架构中间踩过的坑、绕过的弯路网上能对上的完整实战记录其实很少。这篇文章就是把我自己从单体Agent升级到多智能体集群再用MCP统一工具调用、A2A打通Agent间通信、Skills沉淀可复用能力、DeepAgents负责整体调度的全流程经验整理出来给正在搭多智能体集群或者准备把协同开发落到实处的同学一份可以直接参考的作业。1. 为什么单体Agent跑得欢、集群Agent总翻车1.1 单体能力再强也有四个天花板先说清楚一个现实单体Agent是有明确天花板的。我最早做自动化开发助手时所有逻辑塞一个Agent里刚开始确实爽但随着任务复杂度上来问题一个一个冒头。第一个是上下文窗口。一个复杂任务可能涉及需求文档、多个文件、日志输出、历史对话上下文窗口再大也有极限塞满了模型就开始失忆前面的决定后面就忘了。第二个是工具泛滥。一个Agent挂十几个tool模型做工具选择时反而会犹豫甚至拿错工具工具调用成功率直线下降。第三个是并行瓶颈。串行执行太慢但单体Agent本身不具备合理的并行能力所有事情只能排队。第四个是角色混乱。同一个Agent既要写代码又要做复盘还要管部署角色洁癖根本不存在输出风格和决策逻辑很容易互相污染。这时候多Agent集群就是必然选择。但问题也随之而来集群不是把N个Agent堆在一起就完事它需要一套能让Agent们各干各的但步调一致的底层基础设施。1.2 三个和尚没水喝集群失败的常见形态我见过太多多Agent项目翻车翻车形态高度一致基本逃不出下面三类。第一类是通信靠粘贴——Agent A把结果塞进对话历史Agent B再去读上下文。看起来有协作实际上所有信息都耦合在一段超长文本里上下文数量级增长很快就爆掉。第二类是工具各自为战——每个Agent自己挂一套工具配置同一个数据库操作Agent A写的连接逻辑和Agent B完全不是一套权限也乱出问题根本没法查。第三类是技能不可复用——每个Agent都用一大段prompt描述同一件事比如代码审查三个Agent三套说法改一处要改全部维护成本爆炸。后来我意识到这些问题的本质不是Agent模型不够聪明而是缺三层东西统一的工具接入层、标准的Agent通信层、可沉淀的能力封装层。DeepAgents、MCP、A2A、Skills这四个东西恰好分别补上了调度层、工具层、通信层、能力层。1.3 我的整体架构选择四层模型我最后跑通的架构可以简化为四层。底层是MCP负责把所有外部能力和每Agent能用自己的工具打通——数据库、文件系统、浏览器、代码库、API全部统一成标准协议。往上一层是Skills把怎么做沉淀成可复用的技能包相当于给Agent装了一套标准作业手册。再往上是A2A负责Agent与Agent之间的消息传递、任务分发和结果回执相当于Agent们的电话系统。最顶层是DeepAgents做任务拆解、路由、调度和容错相当于整个集群的项目经理。这套分层思路的核心价值在于每一层都可以独立替换和升级哪一层出问题只动那一层不会牵一发而动全身。2. MCP把工具链做成统一插座2.1 MCP到底是什么不是硬件协议先说一个很多人问过的概念问题MCP到底是软件协议还是硬件协议很多人看到MCP会联想到芯片封装里的Multi-Chip Package容易懵。这里明确一下AI语境下的MCP全称是Model Context Protocol模型上下文协议是Anthropic牵头搞的一种纯软件协议作用是让AI模型和外部工具、数据源之间通过统一标准交互。打个比方MCP之于AI应用就像USB-C之于充电设备。以前每个工具都有自己的私有接口AI要调不同API得写一堆适配代码有了MCP之后工具方只需要实现一个MCP ServerAI这边用通用的MCP Client就能接上协议统一适配成本大幅下降。MCP里定义了三类原语tools——可执行的操作resources——可读取的数据prompts——可复用的提示模板。实际开发中tools用得最多resources适合做数据注入prompts适合把常用交互流程固定下来。2.2 实际接入从MCP Server到Client的最小闭环我当时搭的第一套MCP是为了让集群里的Agent能统一读写项目代码库和数据库。先写一个极简的MCP Server用Python的FastMCP库几行代码就能起一个可用的Server。from fastmcp import FastMCP mcp FastMCP(proj-knowledge) mcp.tool() def query_project_structure(path: str) - list: 读取项目目录结构返回文件列表 import os result [] for root, dirs, files in os.walk(path): level root.replace(path, ).count(os.sep) if level 2: continue result.append({dir: root, files: files}) return result if __name__ __main__: mcp.run()然后在Agent侧配置MCP Client。现在主流Agent框架都支持在配置文件中声明MCP Server我可以直接写进一个统一配置文件里集群内共享。{ mcpServers: { project-knowledge: { command: python, args: [path/to/project_knowledge_server.py], env: { PROJECT_ROOT: /workspace/demo } } } }关键是集群内共享这四个字。MCP Server独立于Agent运行Agent只是Client这样工具层就从中每Agent各自的私有配置中抽离出来了。换工具、加权限、修Bug只改Server侧Agent侧不用动。2.3 集群共享MCP时的权限分离设计MCP统一了接入方式但如果权限没分层所有Agent拿到所有工具集群会乱套。我的做法是权限按Agent角色隔离。规划Agent只读项目结构、需求列表和任务看板编码Agent能读代码库、写代码文件但绝对不能动生产数据库质检Agent能读代码、执行测试、写测试报告但不能直接改业务代码部署Agent只在发布阶段被临时授予部署权限平时默认吊销。这个权限隔离我是在MCP Server暴露工具时做角色映射实现的。每Agent都通过同一套MCP端点连接但认证信息里带有自己的角色声明Server侧做工具名匹配和权限校验。比如AGENT_ROLE { coder: {allowed: [read_code, write_code, search_project]}, qa: {allowed: [read_code, run_tests, write_report]}, deployer: {allowed: [deploy_service, rollback_service]}, } def check_permission(agent_role: str, tool_name: str) - bool: if agent_role not in AGENT_ROLE: return False return tool_name in AGENT_ROLE[agent_role]另外提醒一句MCP Server要么不做鉴权一旦做就要认真做别把验证角色名这种逻辑写在客户端侧客户端是AgentAgent的行为不可控必须服务端兜底。2.4 MCP的Resource/Tool/Prompt分工和几个典型的坑MCP里tools、resources、prompts三个原语容易混。我现在的使用口径是要AI主动执行的动作用tools比如执行SQL、提交文件要往上下文里自动注入的静态数据用resources比如启动时自动读入项目README要把一段高频使用的指令模板固化用prompts。初始我All in tools后来发现很多场景其实更适合做resource比如每个Agent启动时自动加载任务上下文如果用toolAgent还得记得去调用resource就是自动注满。再说几个在实践中踩过的坑都是真实教训。第一不要把敏感数据塞进MCP响应。MCP Server返回的内容会全部进入模型上下文日志、密钥、内部IP一旦被返回就等于暴露给了模型和后续的日志系统。Server侧一定要做字段过滤。第二外部工具API升级会导致MCP Server悄悄失效但不是报错而是返回空列表或者奇怪的字段。我当时对接一个第三方项目管理工具的MCP对方改了一个返回字段名Agent写任务日志时连续两天写不进去查到最后才发现是字段映射变了。所以MCP Server侧要做数据结构校验宁可报错不要静默吞掉异常。第三Agent在调用MCP工具时的工具描述一定要写具体带清晰的参数示例。同一个tools描述是query_database(sql)和查询员工表的离职人数参数sql格式SELECT count(*) FROM users WHERE status resigned后者的成功率要高得多。Agent不是人它就是靠描述猜意图的。3. A2A让Agent之间能说人话3.1 A2A要解决的问题MCP管Agent和工具A2A管Agent和AgentMCP解决的是Agent与外部工具的关系但Agent之间的关系它管不了。A2A也就是Agent2Agent协议专门负责Agent之间的通信。我的理解是MCP像Agent的手负责干活A2A像Agent的嘴负责沟通。一只手不需要和另一只手对话但两个Agent之间要协作就得有共同语言。A2A的模型和MCP不太一样它更偏向传统服务间通信把每个Agent当作一个网络端点通过交换Agent Card来发现对方能力通过发送任务、消息、人工介入请求来完成协作。有个常见误区是A2A是不是就替代了MCP不是。它们是互补的同层解决不同的连接问题。我搭的集群里Agent和工具走MCPAgent和Agent走A2A两个协议各自独立也经常在同一进程中共存。3.2 Agent Card和消息模型发现、任务、回执的流转A2A最核心的三个概念是Agent Card、Task和Message。Agent Card相当于每Agent对外发布的名片是一个JSON文档声明了Agent的标识、支持的技能、通信端点、认证方式还有一个很关键的属性集表示它需要人类介入还是全自动。调度器想找人干活先查Agent Card了解谁会干什么再决定发给谁。Task是A2A里的一次工作单元有状态pending、working、completed、failed、input-required等。任务创建后Agent之间通过Message交换中间结果和元信息Message可以是文本、文件引用、结构化数据。最终结果以Artifact的形式挂在Task上。实际跑通后你会发现这套模型和人类的项目协作非常像Task是任务单Message是过程中的沟通记录Artifact是交付物Agent Card是简历。3.3 用A2A实现需求Agent转给编码Agent我给一个最简单的A2A协作场景做个拆解场景是需求Agent分析完需求文档后需要把开发任务转给编码Agent。第一步需求Agent先通过Agent Card发现编码Agent的能力确认它支持implement_feature这个技能。第二步需求Agent创建一个Tasktask_id标识为T-2025-0214-001放置到编码Agent的端点并将需求文档的引用作为Message附加进去。第三步编码Agent接受任务将Task状态置为working同时回一条Message已收到需求开始实现预计XX分钟。第四步编码Agent实现完成后将Task状态置为completed并提交一个包含代码文件路径、测试结果、变更说明的Artifact。这里最容易被忽略的是Task状态回执。如果发完任务不管状态调度层就无法知道任务到底结局如何要么重复派活要么永远悬空。所以我在所有Agent端点的消息处理逻辑里强制要求每次处理完一轮都回一状态消息并附带上下文摘要。3.4 真实踩坑同步调用死锁、超时、重复执行A2A开发中最折磨我的三个坑值得单独拿出来说。一个是同步调用死锁。最初我把Agent间通信写成同步HTTP调用Agent A等Agent B返回Agent B又在等Agent A返回直接绞死。后来全部改成异步消息轮询Task状态只有短耗时任务才允许同步等待凡是跨Agent的长任务一律异步。一个是超时设计。不同Agent的处理时长完全不可控规划Agent可能30秒就返回编码Agent可能要跑15分钟。我在A2A消息链路里为不同任务类型配置了不同的超时上限并在超时之后触发重试一次再失败则上报调度层的分支逻辑。没有这套超时策略之前我见过调度层傻等一个已经死掉的Agent等了20分钟。还有一个是重复执行。A2A没有原生的消息去重机制网络超时重发、Agent重启、调度层重试都可能导致同一个Task被重复执行。我在每Agent侧加了task_id幂等表已经处理过的task_id直接返回旧结果不重新执行。这个机制看着简单如果没有后果很可怕编码Agent把同一个功能重复提交了三次代码仓库里出现三份不同实现的同名文件。4. Skills把流程沉淀成可复用资产4.1 Skills和普通Prompt的差别可版本化、有前置条件、有验收标准回头看我最初的多Agent集群每个Agent都背着好几千字的prompt里面包含角色设定、工作流程、工具调用范例、输出规范。这些东西刚写时觉得挺完善但真用起来就发现问题三个Agent里的代码审查流程是三个人写的三个版本细节不一样维护时根本找不到正版在哪里。Skills解决的就是这个问题。它把能力封装成结构化、可版本化、可检索的单元。一个Skill不仅能描述目标还包含前置条件、具体步骤、执行时机、输出物、验收标准。它更像一本操作手册而不是一段口号。我自己的定义是Skill是能被调度器自动匹配、能被Agent自动执行的最小能力单元。普通Prompt是一次性的对话配方Skill是可装卸的能力插件。4.2 一个SKILL.md的实际模板和我的写法习惯我接触的Skills实践很多是从SKILL.md这种格式出发的。我的写法用Markdown加YAML frontmatter把元信息和正文分开。--- name: code-reviewer description: 对指定代码文件进行静态审查输出问题清单和严重级别。适用于合入前审查需要代码可访问且至少能通过语法解析。 version: 1.2.0 requires: - mcp.project-knowledge - mcp.code-search triggers: - 收到PR合入前审查请求 - 检测到新提交且变更量超过100行 steps: - 读取变更文件列表中的全部文件 - 逐个文件做静态扫描重点检查空指针、资源泄漏、越界访问、安全性 - 对照项目编码规范检查命名和结构 - 输出审查报告按阻塞级/建议级分类 acceptance: - 所有阻塞级问题都有文件行号定位 - 报告包含问题描述、影响面、建议修改方式 artifacts: - report_path: /output/review/{task_id}.md --- # 执行说明 审查流程核心原则宁可漏报不可误报。无法确定的问题标记为需确认不要给出武断结论。有几个写法心得非常值得分享。description一定不要虚。不要写帮助agent做代码审查要写清楚什么条件下用、依赖什么、输出什么。因为调度器是靠description匹配任务的description模糊能力就白费。steps要写到换个人来也能照做的程度。写分析代码质量不如写检查每个函数是否处理了None返回值。你是让Agent照着做不是在跟它聊理想。每个Skill必须有acceptance字段。Skill执行完Agent照着验收标准自检不满足就补做这样输出质量才会稳定。之前我把输出格式预定写成描述性文字而不是验收清单结果是十个任务有九种输出格式后来改成Checklist形式一次收敛。4.3 技能库的目录组织与动态加载多智能体集群里Skills数量一多组织方式就成了瓶颈。我目前的目录结构是三层分离公共库放所有Agent都能用的通用能力私有库放特定Agent专用技能临时区放正在调试还没稳定的实验型技能。skills/ common/ code-reviewer/ test-runner/ changelog-writer/ coder/ refactor-module/ implement-feature/ optimize-query/ qa/ regression-checker/ performance-profiler/ staging/ experimental-migrator/加载逻辑要动态化。Agent启动时不是一个一个把所有Skill都装进上下文那会直接把上下文撑爆。正确做法是Agent启动只加载基础技能清单实际任务到来时调度器根据任务类型、目标文件、依赖关系去skills目录里做匹配把需要的Skill临时注入Agent的可用能力池。这个按任务调技能的机制说实话比把所有技能塞给Agent效果好了不止一个档次。技能越少Agent决策越干净技能匹配越准Agent执行越靠谱。4.4 设计Skills的心得最小可执行、验收Checklist、别写幻想技能Skills的设计是这里面最考验功力的部分我整理出三条最值钱的教训。最小可执行。一个Skill只干一件事别搞大而全的复合技能。我写过一个大Skill叫完成整个功能模块开发里面包含需求分析、架构设计、编码、自测、文档编写。结果就是Agent执行到一半总是偏航要么在需求分析环节过度展开要么在自测环节草草了事。后来拆成需求分析师、方案设计、编码实现、自测四个独立Skill配合A2A流转效果天差地别。验收Checklist是质量的闸门。Skill里必须写明做完这几件事才算完成。没有验收清单的SkillAgent做完就交质量全靠运气。别写幻想技能。所谓幻想技能就是你写的时候以为模型会但实际上不会。比如逐行审查代码并自动修复所有Bug——听起来是个好技能实际执行时Agent会假装修复或者只改说明不改逻辑。可靠做法是写成像识别三段可疑代码并标记附修改建议不直接改代码这样模型真的有能力做到的粒度。宁可技能小一点、考核严一点也不要技能大而空、输出不可控。5. DeepAgents把集群编排成项目制团队5.1 分工方式路由表、角色卡片、职责清单MCP解决了工具A2A解决了通信Skills解决了能力但还缺一个总调度。我用的DeepAgents核心是把多智能体当作一个团队来编排。具体到操作层面我给集群里的Agent建立了三样东西路由表、角色卡片、职责清单。路由表是一个映射关系维护任务类型→Agent端点的对应关系。需求分析类任务丢给需求Agent编码类任务丢给编码Agent测试和部署各有各的目的地。路由表不是写死的Agent的Agent Card如果有更新路由表同步刷新。角色卡片不只是你是编码Agent这种身份描述它还包括这个Agent能访问的MCP Server白名单、可加载的Skill列表、允许创建的A2A任务类型、输出文档的格式规范。每Agent的上下文里只需放自己的角色卡片不需要知道团队里其他Agent的细节。职责清单比角色卡片更落地它是什么情况算我的活、什么情况必须上报的显式列表。我最开始没有职责清单结果集群一忙起来Agent之间就开始互相踢皮球。后来给每Agent都写清楚了三条属于自身职责清单的任务必须承接无法完成的任务必须明确回复failed并说明原因任何不确定的信息询问调度器不要自己猜。5.2 任务拆解与状态机todo拆解、完成定义、依赖关系DeepAgents的核心工作方式是拆解-分派-回收-汇总。一个大任务进来先拆成多个Todo每个Todo再带上状态和依赖关系状态流转我做成了一套简单的状态机pending → ready → running → completed / failed / blocked。依赖关系是最容易被忽视的。比如创建代码文件和执行单元测试两件事测试永远晚于创建。我一开始没有维护依赖关系图调度器把无依赖的任务先派了出去结果测试Agent比编码Agent还先开工等编码Agent提代码时测试Agent对着空气执行了一大堆失败用例。解决方式很简单每个Todo初始化时就带一个depends_on字段调度器只在所有前置依赖completed之后才将该Todo置为ready状态。empty dependencies的任务才能被派发。5.3 协同开发工作流一次完整任务从分发到合入我用一次具体的协同开发任务来展示这套体系是怎么转的。场景需求Agent收到一条需求给用户列表页增加导出Excel功能。第一步需求Agent拆任务方案设计与接口梳理、Excel导出逻辑实现、页面导出按钮与联调、测试与回归、文档更新与部署。第二步需求Agent把方案设计与接口梳理作为A2A Task发给自己做完后将派生出的Excel导出逻辑实现Task通过A2A发送给编码Agent端点。编码Agent收到Task从Skills公共库里加载excel-export-handler技能从MCP里读取项目代码结构开始实现。第三步编码Agent实现完成后Task置为completed并附Artifact同时创建一个新Task测试与回归发给QA Agent。QA Agent加载test-runner技能通过MCP执行测试用例发现问题则把Task置为failed附失败日志并通过A2A把失败的Task重新路由回编码Agent形成一个写代码→测试→打回→改代码→再测的闭环。第四步测试通过后部署Agent被调度器唤醒加载deployer-skill同时通过MCP临时获取部署权限执行滚动发布。整个过程里DeepAgents调度器不干预Agent和Agent之间怎么聊只负责维护Todo状态机、路由分发和超时处理。这种只做项目管理不做包工头的定位非常重要既保证了效率又不至于因为调度器过度控制压掉Agent们的自主性。5.4 容错与恢复Agent掉线、MCP服务失效、任务幂等集群跑起来之后拼的不是谁在晴天跑得快而是谁在故障时扛得住。我把运行期需要提前做好的容错设计列为三块。Agent掉线。某个Agent的A2A端点无响应时调度器需要有一个健康检查机制。我做一个轮询式的健康状态表每60秒探测一次各Agent端点的存活响应。一旦发现掉线调度器将正在处理的Task标记为blocked并将对应Agent的可派发任务重新路由到备份Agent上——备份Agent不常驻是调度器的一个临时容器需要时被调度器启动。MCP服务失效是另一种常见的灾难模式。某个MCP Server挂了所有依赖它的Agent都会报错。我的兜底方案是MCP Server重启后Server侧自动重建临时索引凡是依赖它的Agent的任务在Server恢复之前自动挂起。不要尝试让Agent在Server不可用的时候用另一条路子硬来Agent会发挥创造力用错误的方式完成任务超惨。任务幂等。这个在A2A部分已经提过但在集群级还要做一层调度器要维护全集群的task_id幂等表。任何Agent上报的已完成Task如果task_id已存在调度器直接丢弃避免重复计费和重复入库。加了对重复Task的拦截之后之前经常出现的一个Bug被两个Agent同时改的问题就消掉了。6. 端到端复盘一次真实多智能体协同开发跑通后的经验6.1 整个栈各层到底怎么配合把四层组装好整个系统运行时大概是这副模样。用户给需求Agent提需求需求Agent只负责理解和拆解它通过MCP读取项目资料通过Skills加载需求拆解手册。拆出任务后需求Agent通过A2A把编码Task发给编码Agent。编码Agent本身不直接绑定任何工具它启动时通过MCP找到自己能用的工具集合同时从Skills里加载对应技术栈的开发规范然后再动手。质检Agent通过A2A接收测试任务通过MCP读取代码库通过Skills加载测试执行流程测完把结果回传。最后DeepAgents调度器在总控台上展示所有Task的状态流转哪个Agent正在干什么、哪些Task卡住了、哪条依赖链路最长一屏全部可见。在这个体系里四层各有各的作用缺一层都玩不转没有MCP工具接入就是一团乱麻没有A2AAgent之间就只能靠上下文传递没有Skills每个Agent都得背几大段提示词没有DeepAgents整个集群就像一艘没有船长的船。6.2 性能与成本观察Token消耗和并行度怎么控踩完各种坑之后集群终于跑起来了接下来面对的是成本和性能问题。我观察到的第一个现象是引入MCP和Skills之后单任务的Token消耗不降反升因为MCP响应、技能清单、验收自检都是额外的token开销。但总成本其实下降了原因是返工次数大幅减少——以前单体Agent做炸了重新改要花大量token现在质检Agent在前置环节就把问题拦住了返工少了很多。第二个现象是并行度不是越高越好。我最初试过同时跑五个Agent并行执行不同模块结果两个Agent同时改同一个配置文件互相覆盖多个Agent同时查询同一个数据库表导致锁等待。后来我把共享资源的写操作串行化读操作放开并行并行度控制在2到3个整体吞吐反而提升了。第三个现象是日志系统必须一开始就建。多Agent集群出问题时排查难度比单体高一个量级。我现在所有Agent的A2A消息进出、MCP调用、Skill加载都会同步落一份结构化日志日志里带task_id和agent_id两个关键维度。没有这两列集群一乱根本没法定位到底是谁在哪个环节丢了任务。6.3 工具选型清单我的最终组合最终我稳定使用的组合是这样的MCP Server侧我用FastMCP搭自定义工具同时也接了几个现成的官方Server比如文件系统、数据库、浏览器自动化。这里插一句很多人问浏览器操作类MCP到底怎么选不同工具的定位差异很大有的偏自动化测试粒度细到可以逐像素操作有的偏信息抓取粒度高到直接给结论。选之前先想清楚你的Agent是要帮用户填表单还是帮用户查资料前者选精细的后者选高层的别拿细粒度工具干粗活token烧得心疼。A2A这块我自己用的是基于JSON-RPC风格的消息端点每个Agent都起一个轻量的HTTP接口Agent Card放在统一的服务注册表里。Skills这边用文本格式的SKILL.md方式管理配合一个简单的技能检索脚本按任务关键词匹配技能文件。DeepAgents调度器我用的是自研的轻量调度器维护Todo状态机和路由表。它的核心代码大概只有几百行但承担了整个集群的大脑角色。6.4 给想上多智能体集群的人一句过来人建议搭建这套集群我最大的体会是多智能体开发真正的难点不是模型是不确定性管理。单体Agent出错可以靠提示词修集群出错得靠架构设计去兜底。如果你也准备做多智能体集群我的建议是不要一上来就追求豪华阵容。从两个Agent起步一个负责拆解和规划一个负责执行先把MCP工具接入跑通再引入A2A通信然后逐步沉淀Skills。每加一层跑一到两周的稳定期别贪多。等你能清楚回答每个Agent此刻在干什么、卡在什么环节、下一步会触发什么动作这三个问题的时候再考虑扩到五个、十个Agent。我最后还想分享一个很小的技巧把其中一个Agent设定为观察员它的任务不参与实际生产只负责监控集群里其他Agent的状态流转把异常行为记录下来。就这么一个不起眼的角色帮我抓到了很多次调度器和A2A的隐性Bug。多智能体集群这东西系统越复杂越需要一个不干活只盯场的角色。这个观察员Agent我至今都留着它是我这套集群里最值的投资。