1. 从单体到集群为什么需要超级多智能体1.1 一个智能体扛不住的真实场景做过 Agent 项目的人大概都有这种体验一开始写个单体 Agent接几个工具跑个问答或者简单任务感觉挺美好。可一旦业务复杂起来比如要同时处理文档解析、数据查询、代码生成、外部系统调用、结果校验这几件事单体 Agent 就开始露怯了。上下文窗口被塞爆、工具调用互相干扰、一个环节出错整个链路崩掉调试起来像在拆炸弹。我去年接过一个需求让 Agent 自动完成读取合同 PDF → 提取关键条款 → 比对内部风控规则 → 生成审查报告 → 推送到审批系统这条链路。最开始用一个 Agent 硬扛结果就是提示词越写越长工具描述堆到几千 token模型开始幻觉式调用——明明该查数据库它去调了文件写入。后来拆成三个 Agent 各管一段问题立刻缓解了一大半。这就是多智能体Multi-Agent最朴素的价值分而治之各司其职。但拆开之后新问题又来了Agent 之间怎么通信谁来决定任务分给谁某个 Agent 挂了怎么办外部工具怎么统一接入这时候就需要一套完整的架构来支撑也就是标题里说的DeepAgents MCP A2A Skills这套组合拳。1.2 四个关键词各管什么先把这四个概念用大白话捋清楚不然后面全是空中楼阁。DeepAgents可以理解成智能体的编排大脑。它负责定义有哪些 Agent、每个 Agent 的职责边界、任务怎么流转、状态怎么维护。你可以把它类比成一支球队的教练组不直接上场踢球但决定谁上、打什么阵型、什么时候换人。MCPModel Context Protocol是模型和外部世界之间的标准插座。以前每接一个工具就要写一套适配代码数据库一套、文件系统一套、浏览器一套重复劳动。MCP 把这些统一成一种协议工具方按协议暴露能力Agent 方按协议调用插上就能用。热词里有人问mcp 是软件协议还是硬件协议那个概念答案是软件协议而且是应用层的通信协议跟硬件没关系。A2AAgent to Agent解决的是 Agent 之间的对话问题。MCP 管的是Agent 调工具A2A 管的是Agent 找 Agent。一个负责采购的 Agent 需要财务 Agent 审批预算它俩之间怎么传消息、怎么协商、怎么回传结果这就是 A2A 的活儿。Skills是 Agent 的技能包。一个 Agent 会什么取决于它加载了哪些 Skill。写代码是一个 Skill查数据库是一个 Skill画流程图是一个 Skill。Skills 让 Agent 的能力可以像插件一样装卸而不是写死在提示词里。提示这四个概念不是互斥的而是分层协作。DeepAgents 在顶层编排MCP 在底层接工具A2A 在横向连 AgentSkills 在纵向扩能力。理解这个分层后面所有设计都不会乱。1.3 这套架构适合谁如果你只是做个玩具 Demo单体 Agent 完全够用别过度设计。但如果你遇到下面任意一种情况这套架构就值得认真考虑任务链路超过 5 个步骤且步骤之间有依赖关系需要接入 3 个以上的外部系统或工具多个业务方各自维护自己的 Agent需要互通对可靠性有要求单个环节失败不能拖垮全局需要动态扩展能力今天加个新工具明天加个新技能说白了当你开始觉得一个 Agent 管不过来的时候就是该上多智能体编排的时候。这篇文章我会把整套架构从设计思路到落地细节拆开讲包括参数怎么定、坑在哪里、怎么排查尽量让你看完能直接抄作业。2. 整体架构设计与选型考量2.1 分层架构把复杂度关进笼子多智能体系统最容易犯的错是把所有逻辑揉在一起最后变成一坨谁也不敢改的意大利面。我的做法是严格分层每层只干一件事层级职责对应技术类比编排层任务分解、路由、状态管理DeepAgents教练组通信层Agent 间消息传递、协商A2A对讲机能力层技能定义、加载、执行Skills球员技能接入层外部工具、数据源统一接入MCP标准插座执行层具体模型调用、推理LLM Runtime球员上场这样分层的好处是任何一层出问题都能快速定位。比如 Agent 调不到工具先看接入层 MCP 服务是否正常Agent 之间不通信先看通信层 A2A 的消息格式对不对。排查范围被压缩到单层而不是全链路大海捞针。2.2 为什么选 MCP 而不是自己写适配有人会问我直接写函数调用不行吗为什么要引入 MCP 这层协议我踩过的坑告诉你答案。早期项目里我让 Agent 直接调 Python 函数工具描述写在提示词里。三个工具还好到第八个工具的时候提示词里光工具描述就占了两千多 token而且每次加工具都要改提示词、改代码、重新测试。更麻烦的是不同模型对工具描述的格式要求还不一样换模型就得重写一遍。MCP 的价值在于把工具能力和模型调用解耦。工具方只需要按 MCP 协议暴露一个服务声明我能做什么、需要什么参数、返回什么Agent 方通过标准客户端去发现和调用。换模型不用改工具加工具不用改 Agent 核心逻辑。热词里ruoyi-vue-pro 合并 mcp 功能说的就是这种思路——把 MCP 能力集成进现有系统让老系统也能被 Agent 调用。2.3 A2A 与 MCP 的边界这两个最容易混。记住一句话MCP 是纵向的Agent 向下调工具A2A 是横向的Agent 平级找 Agent。举个例子一个报告生成 Agent需要数据它通过 MCP 调用数据库工具拿到原始数据这是纵向。但它发现数据需要财务部门确认于是通过 A2A 发消息给财务 Agent请求审核这是横向。财务 Agent 审核完又通过 MCP 调用审批系统接口提交结果这又是纵向。边界清晰了设计时就不会纠结这个功能该放 MCP 还是 A2A。判断标准很简单被调用方是工具还是智能体。工具没有自主决策给参数就返回结果走 MCP智能体有自主决策需要理解意图再行动走 A2A。2.4 Skills 的加载策略Skills 的设计核心是按需加载。一个 Agent 可能拥有几十个 Skill但一次任务只用得上三五个。如果全量加载上下文直接爆炸。我的策略是三级加载元数据常驻每个 Skill 只保留名称、一句话描述、触发条件占几十 token按需注入任务路由阶段判断需要哪些 Skill把完整定义注入上下文执行后卸载Skill 执行完从上下文移除释放窗口这样即使 Agent 挂载了 50 个 Skill单次任务的上下文占用也能控制在合理范围。实测下来三级加载比全量加载的 token 消耗降低约 60%响应速度提升明显。3. 核心组件实操从零搭起一个可编排集群3.1 DeepAgents 编排层怎么落地编排层的核心是三个东西Agent 注册表、任务路由器、状态机。Agent 注册表记录每个 Agent 的 ID、能力描述、可接收的任务类型、当前负载。任务路由器根据任务特征决定分给谁。状态机跟踪整个任务链路的执行状态哪个环节完成、哪个环节卡住、哪个环节失败。先看注册表的数据结构我用 JSON 定义{ agent_id: report_generator, capabilities: [document_parse, data_query, report_write], accepts: [generate_report, revise_report], max_concurrent: 3, current_load: 1, endpoint: a2a://report-agent.local }任务路由器的逻辑我建议用能力匹配 负载均衡双因子。先按任务类型筛出能接的 Agent再按当前负载排序选最闲的那个。别用复杂的打分模型初期没必要规则清晰反而好调试。状态机的实现要点是每个状态转移都要可追溯。我习惯给每个任务分配一个 trace_id所有状态变更都带上这个 ID 写日志。出问题时按 trace_id 一捞整条链路清清楚楚。3.2 MCP 服务接入的完整流程接入一个 MCP 服务分四步发现、握手、调用、回收。发现阶段Agent 通过 MCP 客户端向服务端请求能力清单。服务端返回一个 tools 列表每个 tool 包含名称、描述、参数 schema。这一步的关键是缓存能力清单别每次调用都重新拉浪费往返时间。握手阶段确认协议版本、认证方式、超时配置。这里有个坑不同 MCP 服务端的超时默认值不一样有的 30 秒有的 5 分钟。我建议在客户端统一设一个上限比如 60 秒超过就判定失败并重试。调用阶段就是标准的请求-响应。参数校验一定要做别指望服务端帮你兜底。我见过因为参数类型不对导致服务端直接崩的情况客户端传了个字符串服务端期望整数。回收阶段容易被忽略。MCP 连接是长连接用完不释放会占资源。我的做法是连接池管理空闲超过 5 分钟自动回收池子大小按并发量设一般 10 到 20 够用。# MCP 客户端调用示例伪代码展示结构 class MCPClient: def __init__(self, endpoint, pool_size10, idle_timeout300): self.endpoint endpoint self.pool ConnectionPool(sizepool_size, idle_timeoutidle_timeout) self.capabilities None def discover(self): # 拉取能力清单并缓存 if self.capabilities is None: self.capabilities self._request(list_tools) return self.capabilities def call(self, tool_name, params, timeout60): # 参数校验 schema self._get_schema(tool_name) self._validate(params, schema) conn self.pool.acquire() try: return conn.request(tool_name, params, timeouttimeout) finally: self.pool.release(conn)3.3 A2A 通信的消息设计A2A 的消息格式我建议参考信封 正文的结构。信封放路由信息发送方、接收方、消息类型、trace_id正文放业务内容。消息类型至少要有四种请求、响应、通知、错误。请求是我需要你做件事响应是做完了结果在这通知是我这边状态变了同步给你错误是出问题了需要处理。这里有个设计决策值得说同步还是异步。同步调用简单但一个 Agent 卡住会阻塞整条链路。异步解耦好但状态管理复杂。我的经验是短任务预期 10 秒内完成用同步长任务用异步。异步的话接收方处理完通过回调或者消息队列通知发送方。消息幂等性必须考虑。网络抖动导致重发是常事接收方要能识别重复消息。做法是在信封里放一个 message_id接收方维护一个已处理 ID 的集合重复的直接丢弃。3.4 Skills 的定义与注册一个 Skill 的定义包含五部分名称、描述、触发条件、执行逻辑、输出格式。skill: name: contract_clause_extract description: 从合同文本中提取关键条款 triggers: - 提取条款 - 合同审查 input_schema: text: string clause_types: array output_schema: clauses: array confidence: float executor: contract_skill.py触发条件的设计很关键。写得太宽Skill 会被误触发写得太窄该用的时候用不上。我的做法是用语义相似度而不是关键词匹配。把触发条件转成向量任务描述也转成向量相似度超过阈值就触发。阈值一般设 0.75 左右具体看业务调。Skill 注册到 Agent 时只注册元数据。真正执行时才加载 executor。这样 Agent 启动快内存占用低。4. 完整实操搭一个合同审查 Agent 集群4.1 场景定义与 Agent 拆分光讲理论没意思我用一个完整案例串起来。需求是用户上传合同 PDF系统自动完成条款提取、风险比对、报告生成、审批推送。拆成四个 Agent解析 Agent负责 PDF 转文本、分段落、识别条款结构风控 Agent负责拿条款去比对内部规则库标记风险点报告 Agent负责把风险点组织成人类可读的审查报告审批 Agent负责把报告推送到审批系统并跟踪状态四个 Agent 通过 A2A 串联各自通过 MCP 调用所需工具。解析 Agent 调文件解析 MCP风控 Agent 调规则库 MCP报告 Agent 调模板 MCP审批 Agent 调审批系统 MCP。4.2 任务流转的完整链路用户上传 PDF 后编排层生成一个 trace_id启动状态机。第一步任务路由器把解析合同任务分给解析 Agent。解析 Agent 通过 MCP 调用 PDF 解析工具拿到结构化文本通过 A2A 把结果发给风控 Agent同时更新状态机。第二步风控 Agent 收到条款通过 MCP 调用规则库查询接口逐条比对。这里有个性能优化点批量查询而不是逐条查询。我一开始逐条查100 条条款查了 100 次耗时 40 秒。改成批量后一次查完耗时降到 3 秒。第三步风控 Agent 把风险标记结果发给报告 Agent。报告 Agent 通过 MCP 调用模板工具把风险点填入模板生成报告。第四步报告 Agent 把报告发给审批 Agent。审批 Agent 通过 MCP 调用审批系统接口推送拿到审批单号回传给编排层。整个链路的状态机长这样阶段负责 Agent输入输出失败处理解析解析 AgentPDF结构化条款重试 2 次仍失败则终止风控风控 Agent条款风险标记降级为人工审核报告报告 Agent风险标记报告文本重试 1 次审批审批 Agent报告审批单号入队重试4.3 关键参数的计算与选择并发数怎么定我的公式是并发数 平均任务耗时 / 目标吞吐量。假设单个合同处理平均 30 秒目标是每分钟处理 10 个那并发数 30 / 6 5。再留 50% 余量设 8 个并发。超时怎么定超时 平均耗时 × 3。平均 30 秒超时设 90 秒。超过就判定失败触发重试或降级。别设太短网络抖动会误杀别设太长卡住的连接会拖垮整个池子。重试次数怎么定最多 2 次。第一次失败可能是偶发第二次失败大概率是系统性问题再重试就是浪费资源。重试间隔用指数退避1 秒、2 秒、4 秒。上下文窗口怎么分配假设模型窗口 128K我的分配是系统提示 5K、Skill 定义 10K、任务上下文 20K、工具返回 30K、预留 63K 给推理和输出。预留一定要留足不然推理到一半被截断结果就是半截话。4.4 实操现场记录实际跑起来的时候我遇到几个有意思的现象。第一个是解析 Agent 的输出格式不稳定。同样的 PDF有时候返回的条款是数组有时候是嵌套对象。原因是 PDF 解析工具对表格的处理不一致。解决办法是在解析 Agent 后面加一个格式归一化步骤不管上游返回什么统一转成标准结构再往下传。第二个是风控 Agent 的规则库查询超时。规则库数据量大单次查询慢。除了前面说的批量查询我还加了本地缓存热门规则缓存在内存里命中率大概 70%查询耗时进一步降低。第三个是报告 Agent 生成的报告太长。模型倾向于把所有细节都写进去导致报告几千字审批人根本看不完。后来在 Skill 里加了摘要优先的约束先给 200 字摘要再附详细内容审批体验好很多。5. 常见问题与排查技巧实录5.1 Agent 调用工具失败的排查路径工具调用失败是最常见的问题排查按这个顺序走看 MCP 服务是否存活直接 curl 服务端健康检查接口看能力清单是否拉到客户端缓存的能力清单是否包含目标工具看参数是否匹配 schema类型、必填项、枚举值逐个核对看超时配置客户端超时是否小于服务端处理时间看认证token 是否过期权限是否足够我遇到最多的是第 3 步参数类型不对。比如 schema 要求 integer传了 string 123服务端直接拒绝。加一层参数校验能省很多事。5.2 Agent 之间消息丢失怎么办A2A 消息丢失通常有三个原因网络抖动、接收方未启动、消息队列满。网络抖动靠重试解决但重试要幂等。接收方未启动的话消息要持久化等接收方上线再投递。消息队列满的话要么扩容要么限流。我的做法是消息落库 确认机制。发送方发消息前先写库接收方处理完回一个 ack发送方收到 ack 才标记消息完成。超时没收到 ack 就重发。这样即使中间环节挂了消息也不会丢。5.3 上下文爆炸的应急处理跑着跑着上下文满了模型开始胡言乱语这是多智能体系统的经典故障。应急处理立即截断历史只保留最近 3 轮对话 系统提示 当前任务。然后重新触发。根治方案上下文压缩。把历史对话用一个小模型总结成摘要摘要控制在 500 字以内替换原始历史。我实测下来压缩后上下文占用降低 70%任务成功率基本不受影响。还有一个技巧是分阶段清理。任务进入新阶段时把上一阶段的中间结果清理掉只保留最终结论。比如解析阶段完成后原始 PDF 文本就不需要了只留结构化条款。5.4 常见问题速查表现象可能原因排查动作解决方案工具调用超时服务端慢或网络差查服务端日志、测网络延迟加超时重试、优化服务端Agent 不响应消息未送达或 Agent 挂了查消息队列、查 Agent 心跳重发消息、重启 Agent结果格式错乱上游输出不稳定对比多次输出加格式归一化层上下文溢出历史累积过多查 token 计数压缩历史、分阶段清理任务卡住不动状态机未推进查 trace_id 日志手动推进或重置状态重复执行消息重发未幂等查 message_id 去重加幂等校验5.5 几个踩过的坑坑一Agent 注册表没做版本管理。改了 Agent 能力描述老任务还在用旧描述导致路由错误。后来加了版本号任务绑定创建时的版本升级时灰度切换。坑二MCP 连接池泄漏。异常路径下连接没释放跑一天池子就满了。后来用 try-finally 强制释放加了泄漏检测告警。坑三Skill 触发条件冲突。两个 Skill 的触发条件相似任务来了不知道该用哪个。解决办法是给 Skill 加优先级冲突时高优先级胜出同时记录冲突日志定期人工review。坑四A2A 消息没有大小限制。有个 Agent 把整个 PDF 文本塞进消息里几 MB 的消息把队列撑爆了。后来加了消息大小上限超过 1MB 的走对象存储消息里只传引用。6. 扩展方向与个人体会6.1 从单机到分布式的演进上面这套跑在单机上没问题但任务量上来后要分布式。演进路径我建议分三步第一步Agent 无状态化。把 Agent 的状态全部外置到 Redis 或数据库Agent 本身可以随意启停、扩容。第二步消息队列解耦。A2A 通信从直连改成走消息队列发送方和接收方彻底解耦一方挂了不影响另一方。第三步编排层分片。按 trace_id 哈希把任务分到不同编排节点每个节点管一部分任务水平扩展。这三步不用一次做完按业务量逐步推进。我见过一上来就搞全套分布式的结果复杂度爆炸调试成本远超收益。6.2 Skills 生态的想象空间Skills 最大的价值是让能力可以像 App 一样分发。今天你写了个合同条款提取 Skill明天别人写了个发票识别 Skill大家通过标准接口互相调用不用重复造轮子。热词里codex 好用的 skillsskills 推荐反映的就是这种需求。未来可能会出现 Skill 市场开发者上传 SkillAgent 按需订阅。这需要一套标准Skill 怎么描述、怎么版本管理、怎么计费、怎么保证安全。目前还在早期但方向是明确的。6.3 我个人在实际操作中的体会搭这套系统最大的感受是复杂度是守恒的你不在架构上花时间就要在调试上花时间。单体 Agent 看起来简单但业务一复杂提示词会变成一坨谁也不敢动的黑箱。多智能体架构前期投入大要设计协议、要写编排、要处理通信但一旦跑通后续加功能就是加 Agent、加 Skill边际成本很低。另一个体会是别过度设计。我一开始想搞一套通用的 Agent 编排框架支持各种花哨的路由策略、动态扩缩容、智能负载均衡。结果写了两个月发现 80% 的功能用不上真正跑起来就是能力匹配 轮询最简单。后来砍掉一半代码反而更稳。最后一个建议日志和可观测性一定要从第一天就做。多智能体系统的调用链路长出问题时没有完整日志就是盲人摸象。trace_id 贯穿全链路、每个状态变更都记录、关键参数都打点这些前期花的时间后期排查时能十倍百倍地还回来。这套架构还在快速演进MCP 协议在更新A2A 的标准也在完善Skills 的生态刚起步。但核心思路是稳的分层解耦、标准接口、按需加载。抓住这三点具体技术怎么变都能跟上。