多智能体系统从概念验证走到生产落地中间隔着的不是模型能力而是协同架构。我过去大半年一直在折腾 DeepAgents、MCP、A2A 和 Skills 这套组合从最初单 Agent 跑通一个任务就兴奋半天到后来被多智能体之间的通信乱序、工具调用冲突、上下文爆炸折磨得怀疑人生再到现在能比较从容地设计一个几十个 Agent 协同的集群这个过程踩的坑比写的代码多得多。这篇文章不打算复述官方文档而是把我实际搭建多智能体集群时关于架构分层、协议选型、技能封装、协同调度的完整思路和盘托出适合已经了解 Agent 基本概念、准备往多智能体方向深入的开发者也适合正在评估 MCP 和 A2A 到底该怎么用的技术负责人。1. 先把四个概念的角色分清楚否则架构一定乱很多人一上来就把 DeepAgents、MCP、A2A、Skills 混在一起讲结果设计出来的系统职责边界模糊调试时根本不知道问题出在哪一层。我在早期项目里就吃过这个亏一个 Agent 既负责规划又负责调工具还负责跟别的 Agent 通信最后代码变成一团乱麻。所以第一部分我想先把这四个东西各自的定位讲透这是后面所有架构设计的地基。1.1 DeepAgents 是编排层不是模型层DeepAgents 这个名字容易让人误以为它是一个更强的模型其实它解决的是多个 Agent 怎么组织起来完成复杂任务的问题。你可以把它理解成一个项目经理它本身不干具体的活但它知道整个任务需要拆成哪几步、每一步交给谁、中间结果怎么汇总。在我实际使用中DeepAgents 提供的核心价值是任务分解、Agent 调度和状态管理这三件事。任务分解指的是把一个模糊的用户请求拆成可执行的子任务。比如用户说帮我分析这份财报并生成一份投资简报DeepAgents 需要把它拆成数据提取、指标计算、趋势分析、文案生成几个子任务。Agent 调度指的是决定每个子任务由哪个 Agent 执行这里涉及能力匹配和负载均衡。状态管理则是最容易被低估的部分多智能体系统里每个 Agent 都有自己的上下文如何维护一个全局一致的状态视图直接决定了系统会不会出现各说各话的情况。我踩过的一个典型坑是早期我让 DeepAgents 只做任务分解不做状态管理结果两个 Agent 并行处理关联任务时各自基于过时的数据做决策最后汇总出来的结果自相矛盾。后来我在编排层加了一个共享状态存储所有 Agent 的关键输出都写回这个存储下一个 Agent 执行前先读取最新状态问题才解决。1.2 MCP 解决的是 Agent 与工具之间的标准化连接MCP 是一个软件协议它的核心目标是让 Agent 调用外部工具、数据源、服务的方式标准化。在没有 MCP 之前每接一个工具就要写一套适配代码接十个工具就是十套维护成本极高。MCP 出现之后工具提供方按照 MCP 规范暴露自己的能力Agent 侧只需要一个统一的 MCP 客户端就能调用所有符合规范的工具。这里有个概念需要澄清热词里有人问mcp 是软件协议硬件协议那个概念叫什么来着硬件领域对应的标准化接口概念通常叫总线协议或者接口标准比如 USB、PCIe 这类它们解决的是物理设备和主机之间的标准化连接问题。MCP 在软件层面扮演的角色类似只不过连接的是 Agent 和软件工具。在实际项目中MCP 带来的最大好处是工具生态的复用。我可以在一个项目里同时接入数据库查询 MCP、文件操作 MCP、浏览器自动化 MCP而不需要为每个工具单独写胶水代码。但要注意MCP 只解决连接标准化不解决调用时机和调用顺序那是编排层的事。1.3 A2A 是 Agent 之间的通信协议A2A 解决的是 Agent 与 Agent 之间怎么对话的问题。在多智能体集群里Agent 之间需要传递任务、交换中间结果、协商冲突如果没有统一协议每个 Agent 之间的通信都要定制系统规模一上来就崩了。A2A 定义了一套标准的消息格式和交互模式让不同来源、不同框架实现的 Agent 能够互相通信。我理解 A2A 的价值时喜欢用一个类比MCP 像是 Agent 和工具之间的 USB 接口A2A 像是 Agent 和 Agent 之间的通用语言。一个管纵向的能力扩展一个管横向的协同通信。在实际集群里这两个协议往往同时存在一个 Agent 既通过 MCP 调用工具又通过 A2A 跟其他 Agent 协作。1.4 Skills 是可复用的能力封装单元Skills 这个概念最近特别火热词里出现了大量跟 skills 相关的内容比如 codex skills、claude agent skills、skills 开发、skills 推荐等等。我的理解是Skills 是把某类特定任务的处理逻辑、提示词、工具调用序列打包成一个可复用的单元。它比单个工具调用更高级比一个完整 Agent 更轻量。举个例子一个财报分析 Skill可能包含读取 PDF 的提示词模板、提取关键财务指标的调用逻辑、计算同比环比的公式、生成分析结论的输出格式。当任何 Agent 需要做财报分析时直接加载这个 Skill 即可不需要重新设计流程。Skills 让能力沉淀成为可能这是多智能体系统能够持续演进的关键。下面这张表是我总结的四个概念的核心定位对比建议在设计架构前先对照一遍概念解决的问题类比在架构中的位置DeepAgents任务分解与 Agent 调度项目经理编排层MCPAgent 与工具的标准化连接USB 接口连接层A2AAgent 之间的通信通用语言通信层Skills可复用能力封装标准作业流程能力层2. 多智能体集群的分层架构设计把四个概念的角色理清之后接下来要解决的是怎么把它们组装成一个能跑起来的集群。我在设计架构时最大的体会是不要一上来就追求大而全而是先确定分层让每一层只关心自己的职责层与层之间通过明确的接口交互。这样即使某一层出了问题排查范围也是可控的。2.1 我实际采用的四层架构经过几轮重构我最终稳定下来的架构分为四层接入层、编排层、能力层、通信层。接入层负责接收用户请求并做初步的意图识别决定这个请求是交给单个 Agent 还是启动多智能体协同。编排层就是 DeepAgents 所在的位置负责任务分解、Agent 调度、状态管理。能力层由各种 Skills 和 MCP 工具组成是真正干活的地方。通信层由 A2A 协议支撑负责 Agent 之间的消息传递。这个分层的好处是职责清晰。比如当系统出现任务执行到一半卡住的问题时我可以先看编排层的调度日志确认是任务分解有问题还是 Agent 调度失败如果编排层正常再看通信层是不是消息丢了如果通信也正常那就是能力层的某个 Skill 或工具执行超时。排查路径是线性的不会像早期那样到处乱找。2.2 为什么编排层要独立于能力层我见过一些实现把任务分解逻辑直接写在 Agent 内部Agent 既做规划又做执行。这种设计在单 Agent 场景下没问题但一旦扩展到多智能体就会出大问题。原因是规划逻辑和执行逻辑的变更频率完全不同规划逻辑相对稳定执行逻辑经常要接新工具、改新流程。如果混在一起每次改一个工具都要动到规划代码回归测试成本极高。把编排层独立出来之后我可以在不改动任何 Agent 的情况下调整任务分解策略。比如原来是把数据分析作为一个整体任务后来发现拆成数据清洗和指标计算两个子任务效果更好只需要改编排层的分解规则能力层的 Agent 完全不用动。这种解耦在多智能体系统里是刚需因为系统越复杂变更的连锁反应越难控制。2.3 通信层的消息可靠性设计A2A 通信最容易出问题的地方是消息丢失和重复消费。我在早期项目里遇到过 Agent A 给 Agent B 发了任务B 没收到A 一直等结果整个流程卡死。后来我在通信层加了三个机制消息确认、超时重传、幂等处理。消息确认是指接收方收到消息后必须回一个 ACK发送方收到 ACK 才认为投递成功。超时重传是指发送方在指定时间内没收到 ACK 就重发重发次数有上限超过上限就上报编排层处理。幂等处理是指接收方对同一条消息的多次投递只处理一次通过消息 ID 去重。这三个机制加上之后通信层的稳定性有了质的提升。提示消息 ID 的生成一定要全局唯一我早期用时间戳生成结果高并发下出现了重复导致幂等去重失效。后来改成 UUID 加 Agent 标识的组合才彻底解决。2.4 状态存储的选型与一致性权衡多智能体系统的状态存储是个绕不开的话题。我试过三种方案纯内存、关系型数据库、Redis 加持久化。纯内存最快但重启就丢适合纯实验场景。关系型数据库一致性最好但读写慢适合状态变更不频繁的场景。Redis 加持久化在性能和可靠性之间比较平衡是我目前生产环境的主力方案。一致性方面需要做个权衡。强一致性意味着每次状态变更都要等所有相关 Agent 确认延迟高但不会出现数据冲突。最终一致性则是各 Agent 先各自更新后台异步同步延迟低但短时间内可能读到旧数据。我的经验是涉及金额、库存这类不能出错的场景用强一致性涉及推荐、分析这类可以容忍短暂不一致的场景用最终一致性。3. MCP 工具接入的实操细节与常见坑MCP 是整个系统里跟外部世界打交道最多的部分也是最容易出问题的地方。我接过数据库 MCP、文件系统 MCP、浏览器自动化 MCP、各种 SaaS 服务的 MCP踩过的坑五花八门。这一部分我把工具接入的完整流程和典型问题讲清楚。3.1 MCP 服务端与客户端的连接建立接入一个 MCP 工具的第一步是建立连接。MCP 支持多种传输方式常见的有标准输入输出和基于 HTTP 的传输。标准输入输出适合本地进程启动快、延迟低但只能本机使用。HTTP 传输适合远程服务可以跨机器调用但需要处理网络问题。我在实际项目里的选择原则是本地工具优先用标准输入输出远程服务用 HTTP。比如文件操作、本地数据库这类肯定在本机用标准输入输出最省事。而像云端 API 封装的服务必须用 HTTP。配置的时候要注意标准输入输出方式下MCP 服务端的日志不能往标准输出打否则会污染协议数据导致解析失败。这个坑我踩过排查了大半天才发现是服务端把调试日志打到了标准输出。3.2 工具描述的质量直接决定调用准确率MCP 工具接入之后Agent 怎么知道该调用哪个工具靠的是工具的描述信息。很多人写工具描述很随意就写一句查询数据结果 Agent 经常调错工具或者该调的时候不调。我的经验是工具描述要包含四个要素这个工具做什么、什么场景下用、输入参数的含义和格式、输出的结构。举个例子一个数据库查询工具的描述不应该只写查询数据库而应该写根据 SQL 语句查询业务数据库适用于需要获取结构化业务数据的场景输入为合法的 SQL 查询语句输出为 JSON 格式的结果集包含 columns 和 rows 两个字段。描述越具体Agent 的调用准确率越高。我做过对比测试把工具描述从一句话扩展到包含场景和格式说明后调用准确率从六成多提升到了九成以上。3.3 工具调用的超时与重试策略外部工具调用失败是常态网络抖动、服务限流、临时故障都会导致失败。如果不做超时和重试一个工具卡住就会拖垮整个流程。我的做法是给每个 MCP 工具配置独立的超时时间和重试策略。超时时间根据工具类型来定。查询类工具一般三到五秒写入类工具十到三十秒涉及大批量处理的可以到几分钟。重试策略要区分错误类型网络超时这类可重试错误才重试参数错误这类不可重试错误直接返回失败。重试次数我一般设两到三次每次重试间隔递增避免瞬间打爆下游服务。工具类型建议超时重试次数重试间隔轻量查询3-5 秒2 次1 秒递增数据写入10-30 秒3 次2 秒递增批量处理60-300 秒1 次5 秒外部 API5-15 秒3 次1 秒递增3.4 多个 MCP 工具之间的调用顺序协调当一个任务需要调用多个 MCP 工具时顺序很重要。有些工具之间有依赖关系必须串行有些工具相互独立可以并行。我在编排层专门做了一个依赖分析模块根据工具描述里的输入输出关系自动判断依赖。比如先查询用户信息再根据用户 ID 查询订单这个流程两个工具有明确的数据依赖必须串行。而同时查询三个不同数据源的数据然后汇总三个工具相互独立可以并行。并行调用能显著缩短总耗时但要注意下游服务的承载能力我一般会限制并行度避免把下游打挂。4. A2A 协议下的 Agent 协同模式A2A 让 Agent 之间能够对话但怎么对话、按什么模式协同是需要设计的。我在实践中总结了几种常用的协同模式每种适合不同的任务类型。4.1 主从模式一个主 Agent 调度多个从 Agent主从模式是最容易理解和实现的协同模式。一个主 Agent 负责接收任务、分解任务、分配给从 Agent、收集结果、汇总输出。从 Agent 只负责执行分配到的子任务不关心全局。这种模式适合任务可以清晰分解且子任务之间依赖较少的场景。比如批量数据处理主 Agent 把数据分片每个从 Agent 处理一片最后汇总。优点是结构简单、易于调试缺点是主 Agent 容易成为瓶颈从 Agent 数量多了之后主 Agent 的调度压力很大。我在用主从模式时的一个优化是给主 Agent 加了一个任务队列从 Agent 主动从队列拉取任务而不是主 Agent 推送。这样主 Agent 只需要往队列里放任务不用关心哪个从 Agent 空闲负载均衡自然就实现了。4.2 对等模式Agent 之间平等协商对等模式里没有明确的主从关系Agent 之间通过协商来推进任务。每个 Agent 都有自己的专长遇到自己擅长的问题就主动承担遇到不擅长的就转给其他 Agent。这种模式适合任务边界模糊、需要动态调整的场景。比如复杂的问题诊断一开始不知道问题出在哪需要多个领域的 Agent 各自排查发现线索后逐步聚焦。对等模式的实现复杂度高需要解决协商机制、冲突消解、死锁避免等问题。我在实现时用了一个简单的投标机制需要处理某个子任务时广播给所有相关 Agent各 Agent 根据自己的能力和当前负载投标出价最高的获得任务。4.3 流水线模式Agent 按固定顺序处理流水线模式是把任务拆成固定的几个阶段每个阶段由一个专门的 Agent 处理前一个阶段的输出是后一个阶段的输入。这种模式适合流程固定的场景比如文档处理流水线解析 Agent 负责提取文本清洗 Agent 负责去噪分析 Agent 负责提取信息生成 Agent 负责输出报告。流水线的优点是每个 Agent 职责单一、易于优化缺点是灵活性差流程一旦定下来就很难调整。我在用流水线模式时会预留一些旁路允许某些阶段被跳过或者插入额外的处理步骤增加一点灵活性。4.4 协同模式的选择依据选哪种协同模式我一般看三个维度任务的可分解性、子任务之间的依赖程度、对灵活性的要求。任务容易分解且依赖少用主从任务边界模糊需要动态调整用对等流程固定且追求效率用流水线。实际项目里往往是混合使用。比如一个数据分析系统整体用流水线但流水线中的分析阶段内部用主从模式并行处理多个数据源遇到异常情况时切换到对等模式做诊断。不要拘泥于单一模式根据实际需要组合才是正道。5. Skills 的设计、封装与复用Skills 是我认为多智能体系统里最值得投入的部分因为它决定了系统能不能沉淀能力、越用越强。一个设计良好的 Skill 可以让多个 Agent 复用避免重复造轮子。5.1 一个 Skill 应该包含哪些要素我设计的 Skill 一般包含五个要素触发条件、输入规范、处理逻辑、工具依赖、输出规范。触发条件描述什么情况下该用这个 Skill输入规范定义需要哪些参数处理逻辑是核心的提示词和步骤工具依赖列出需要哪些 MCP 工具输出规范定义返回结果的格式。以合同条款提取 Skill为例触发条件是需要从合同文本中提取关键条款输入是合同文本和需要提取的条款类型处理逻辑包含分块读取、逐块识别的提示词工具依赖是文件读取 MCP 和文本处理 MCP输出是结构化的条款列表。把这五个要素定义清楚这个 Skill 就能被任何需要合同处理的 Agent 直接加载使用。5.2 Skill 的粒度怎么把握Skill 的粒度是个需要反复权衡的问题。粒度太粗一个 Skill 包山包海复用性差改一处影响一片。粒度太细一个简单任务要加载十几个 Skill编排复杂度飙升。我的经验是一个 Skill 对应一个完整的、有明确输入输出的业务动作。判断标准是如果这个动作在多个场景下都会被完整调用就适合做成一个 Skill。如果它总是作为某个更大动作的一部分出现那它应该被包含在更大的 Skill 里而不是单独拆出来。我早期把读取文件和解析文件拆成两个 Skill结果发现它们几乎总是一起出现后来合并成一个文件解析 Skill反而更合理。5.3 Skill 的版本管理与灰度发布Skill 会不断迭代怎么管理版本是个实际问题。我的做法是给每个 Skill 打版本号Agent 加载时指定版本。新版本先在小范围 Agent 上灰度观察效果稳定后再全量切换。这样即使新版本有问题影响范围也可控。版本管理还要注意向后兼容。如果新版本改了输入输出格式所有依赖这个 Skill 的 Agent 都要同步更新成本很高。所以我在设计 Skill 接口时会尽量预留扩展字段新版本增加功能时通过可选字段实现不破坏老接口。这个习惯让我的 Skill 迭代顺畅了很多。5.4 Skill 组合形成能力网络单个 Skill 能力有限但多个 Skill 组合起来就能形成强大的能力网络。我在系统里维护了一个 Skill 注册中心记录每个 Skill 的能力、输入输出、依赖关系。当编排层需要完成一个复杂任务时可以先查询注册中心看哪些 Skill 组合能覆盖这个任务。比如生成季度经营分析报告这个任务可以组合数据查询 Skill指标计算 Skill趋势分析 Skill报告生成 Skill来完成。编排层不需要知道每个 Skill 内部怎么实现只需要知道它们的输入输出能对接上就行。这种基于能力组合的设计让系统的扩展性大大增强新增一个 Skill 就可能解锁一批新的任务类型。6. 全流程实战从需求到集群跑通前面讲的都是分模块的内容这一部分我把它们串起来讲一个完整的实战流程。假设需求是搭建一个能自动处理客户咨询并生成回复建议的多智能体系统。6.1 需求拆解与 Agent 角色设计首先拆解需求。客户咨询处理可以分成几个环节接收咨询、理解意图、检索知识、生成回复、质量检查。对应的 Agent 角色有接待 Agent 负责接收和初步分类理解 Agent 负责意图识别和实体提取检索 Agent 负责从知识库找相关信息生成 Agent 负责组织回复审核 Agent 负责质量把关。角色设计的原则是每个 Agent 职责单一、边界清晰。我见过把理解和检索合在一个 Agent 里的设计结果这个 Agent 既要判断意图又要查知识库提示词写得极其复杂效果反而不好。拆开之后每个 Agent 的提示词都很聚焦整体效果提升明显。6.2 为每个 Agent 配置 MCP 工具和 Skills接待 Agent 需要消息接收 MCP理解 Agent 需要文本处理 MCP 和意图识别 Skill检索 Agent 需要向量数据库 MCP 和知识检索 Skill生成 Agent 需要文本生成 MCP 和回复模板 Skill审核 Agent 需要质量评估 Skill。配置的时候要注意权限最小化。每个 Agent 只配置它真正需要的工具不要图省事给所有 Agent 配全套工具。这不仅是安全考虑也能减少 Agent 的选择困难提高调用准确率。我早期给所有 Agent 配了全部工具结果 Agent 经常调用不相关的工具后来按需配置后准确率提升了不少。6.3 编排层的任务流设计编排层需要设计任务流接待 Agent 收到咨询后先交给理解 Agent 识别意图根据意图决定是否需要检索。如果是简单问题直接生成回复如果是复杂问题先检索再生成。生成后交给审核 Agent审核通过则输出不通过则打回重新生成。任务流里要设置好异常处理。比如检索 Agent 查不到相关信息怎么办生成 Agent 超时怎么办审核 Agent 连续打回怎么办。我的做法是每个环节都设置最大重试次数和降级方案检索不到就基于通用知识生成生成超时就返回简化版回复审核连续打回就转人工处理。6.4 联调与性能压测所有 Agent 配置好之后进入联调阶段。联调的重点是验证 Agent 之间的消息传递是否正确、状态是否一致、异常处理是否生效。我会构造一批测试用例覆盖正常流程和各种异常分支逐个验证。联调通过后做性能压测。压测关注三个指标单次咨询的处理耗时、系统的并发处理能力、各 Agent 的负载分布。我压测时发现生成 Agent 是瓶颈因为文本生成耗时最长后来给生成 Agent 做了水平扩展部署了多个实例并发能力才上来。6.5 上线后的监控与迭代上线不是终点监控和迭代才是长期工作。我监控的指标包括各 Agent 的调用成功率、平均耗时、错误分布、Skill 的命中率、MCP 工具的调用频次。这些指标能帮我快速定位问题。迭代方面我会定期分析失败案例看是哪个环节出了问题。如果是某个 Skill 效果不好就优化 Skill如果是某个 Agent 提示词不清晰就改提示词如果是工具不稳定就换工具。多智能体系统的优化是个持续过程没有一劳永逸的方案。7. 那些让我熬夜的坑与排查思路这一部分我专门讲几个印象深刻的坑以及我是怎么排查的。这些经验在官方文档里找不到但实际项目里一定会遇到。7.1 Agent 之间消息乱序导致的状态不一致有一次系统出现诡异现象生成 Agent 拿到的检索结果和实际检索 Agent 返回的不一致。排查了很久才发现是消息乱序。检索 Agent 返回了两条消息一条是中间状态一条是最终结果由于网络原因最终结果先到中间状态后到生成 Agent 用了后到的中间状态。解决方案是给消息加序号接收方按序号排序后再处理。同时约定只有最终结果消息才触发下一步中间状态消息只更新状态不触发流程。这个坑让我意识到多智能体系统里的消息顺序不能想当然必须显式保证。7.2 MCP 工具返回格式不一致引发的解析失败接入多个 MCP 工具后发现有些工具返回 JSON有些返回纯文本有些返回带额外包装的结构。Agent 解析时经常失败。排查后发现是不同工具的实现方对 MCP 规范的理解不一致。解决方案是在 MCP 客户端加一层适配统一把各种返回格式转换成内部标准格式。适配层还负责处理字段命名不一致的问题比如有的工具用 result 有的用 data。这层适配虽然增加了一点复杂度但让上层 Agent 不用关心底层差异整体收益很大。7.3 Skill 加载顺序导致的提示词冲突有两个 Skill 的提示词里都定义了输出格式加载顺序不同导致最终生效的格式不同Agent 行为不稳定。排查时发现是 Skill 加载没有明确的优先级规则。解决方案是给 Skill 定义优先级高优先级的 Skill 的提示词覆盖低优先级的。同时约定每个 Skill 只定义自己职责范围内的提示词不要越界定义全局规则。这个约定加上之后Skill 冲突问题基本消失了。7.4 上下文爆炸导致 Agent 响应变慢系统跑了一段时间后Agent 响应越来越慢。排查发现是上下文越积越多每个 Agent 的上下文里塞满了历史消息和中间结果。上下文太长不仅慢还会导致模型注意力分散效果下降。解决方案是给上下文设置上限超过上限就做摘要压缩把历史信息浓缩成关键要点。同时区分长期记忆和短期上下文长期记忆存到外部存储按需检索短期上下文只保留当前任务相关的信息。这个优化让响应速度恢复到了正常水平。7.5 排查思路的通用方法论踩了这么多坑我总结出一套排查方法论先定位问题出在哪一层是编排、通信、能力还是接入然后在那一层里看日志确认是逻辑错误还是数据错误如果是数据错误往前追溯数据来源如果是逻辑错误检查最近的变更。这套方法论让我排查效率提升了很多不再像早期那样盲目试错。注意日志一定要打全尤其是 Agent 之间的消息内容和 MCP 工具的调用参数与返回。我早期为了省事只打关键节点日志结果排查时发现关键信息缺失只能复现问题重新打日志浪费了大量时间。8. 集群扩展时绕不开的工程问题当 Agent 数量从几个扩展到几十个系统会遇到一些在小规模时不明显的问题。这一部分讲讲集群扩展时的工程挑战。8.1 Agent 注册与发现机制Agent 多了之后编排层怎么知道有哪些 Agent 可用、它们各自有什么能力需要一个注册与发现机制。我的做法是每个 Agent 启动时向注册中心注册自己的标识、能力、地址编排层从注册中心获取可用 Agent 列表。注册中心还要处理 Agent 下线的情况。Agent 正常关闭时主动注销异常崩溃时靠心跳超时自动剔除。心跳间隔我设的是十秒超时阈值三十秒这样既能及时发现故障又不会太敏感。8.2 负载均衡与任务分配多个同类型 Agent 同时在线时任务怎么分配最简单的轮询但没考虑 Agent 的实际负载。我后来改成了基于负载的分配每个 Agent 定期上报自己的当前任务数和资源占用编排层优先把任务分配给负载低的 Agent。还要考虑任务亲和性。有些任务需要访问特定的缓存或数据分配给最近处理过类似任务的 Agent 能命中缓存提升效率。我在分配算法里加了亲和性权重效果不错。8.3 分布式追踪与可观测性集群规模大了之后一个请求可能经过十几个 Agent出问题时很难定位。分布式追踪是必须的。我给每个请求分配一个全局追踪 ID所有 Agent 处理时都带上这个 ID日志里也记录。这样通过追踪 ID 就能把整个请求链路串起来。可观测性还包括指标采集和告警。我采集的指标有各 Agent 的 QPS、延迟、错误率MCP 工具的调用成功率Skill 的命中率等。关键指标设置告警阈值异常时及时通知。8.4 资源隔离与限流不同 Agent 消耗的资源差异很大有的吃 CPU 有的吃内存有的吃网络。如果不做隔离一个 Agent 出问题可能拖垮整个集群。我的做法是把 Agent 按资源类型分组部署组之间做资源隔离。同时对每个 Agent 设置资源上限超过上限就限流。限流策略要区分优先级。核心链路的 Agent 优先级高限流阈值设得宽辅助功能的 Agent 优先级低限流阈值设得严。这样在资源紧张时优先保障核心链路。9. 关于这套架构的一些个人体会折腾了这么久我对多智能体系统最大的体会是架构设计的重要性远大于单个 Agent 的能力。一个能力平平但架构清晰的系统比一堆能力很强但协同混乱的 Agent 要靠谱得多。我早期总想着用更强的模型、更复杂的提示词来提升效果后来发现真正的瓶颈在协同在架构。另一个体会是不要过度设计。我见过一些项目一上来就设计极其复杂的多智能体架构结果连基本流程都跑不通。正确的做法是先跑通最小可用版本两个 Agent 加一个 MCP 工具验证协同流程没问题后再逐步扩展。每扩展一步都确保系统是稳定的这样即使出问题也容易定位。还有一点是关于 Skills 的沉淀。多智能体系统的价值不仅在于能完成任务更在于能积累能力。每次解决一个新问题都应该思考能不能把它沉淀成一个 Skill让下次遇到类似问题时直接复用。这种积累效应是系统越用越强的关键。最后说个实操小技巧在开发阶段我会给每个 Agent 加一个调试模式开启后 Agent 会把完整的思考过程、工具调用参数、返回结果都打印出来。这个模式在排查问题时极其有用虽然日志量大但能让你看清 Agent 到底在想什么。生产环境关掉调试模式只保留关键日志避免日志爆炸。这套 DeepAgents 加 MCP 加 A2A 加 Skills 的组合目前在我的几个项目里跑得比较稳从单机几个 Agent 到分布式几十个 Agent 都验证过。当然它也不是银弹遇到需要极低延迟或者极强一致性的场景还是得针对性地做优化。但作为一个通用的多智能体协同框架它的分层设计和协议标准化确实让开发和维护省心了很多。