多智能体系统这两年从论文里的概念一路卷到了工程落地但真正动手搭过的人都知道把几个Agent凑在一起跑通Demo只是起点难的是让它们可编排、可互通、可扩展——也就是标题里说的那三件事。DeepAgents、MCP、A2A、Skills这四个词放在一起其实对应了四个不同层面的问题Agent怎么组织、工具怎么接、Agent之间怎么通信、能力怎么复用。我最近花了不少时间把这套组合拳从零搭了一遍踩的坑比想象中多尤其是协议边界和能力封装这两块文档里基本不会告诉你哪里会翻车。这篇就把整个搭建思路、关键决策和实测经验完整摊开讲适合已经写过单Agent、想往多Agent集群方向走的开发者也适合正在评估MCP和A2A到底该不该上的技术负责人。1. 先把四个概念的关系理清楚别一上来就写代码很多人看到DeepAgents、MCP、A2A、Skills这四个词第一反应是这是不是四个竞品然后开始纠结选哪个。我一开始也这么想过后来发现完全搞错了方向——它们根本不在一个层面上是互补关系。1.1 四个概念各自解决什么问题用一个类比来说把整个多智能体集群想象成一家公司。DeepAgents是公司的组织架构和岗位设计。它决定了有哪些Agent、每个Agent负责什么、谁向谁汇报、任务怎么拆解和汇总。它管的是编排这件事——一个复杂任务进来怎么拆成子任务分给哪些Agent最后怎么把结果拼回去。MCPModel Context Protocol是员工手里的工具箱和操作手册。它定义了Agent怎么调用外部工具、怎么读取外部资源。以前每个Agent接一个工具就要写一套适配代码MCP把这个过程标准化了——工具方按MCP规范暴露能力Agent方按MCP规范调用双方解耦。A2AAgent to Agent是部门之间的沟通机制。当Agent A需要Agent B帮忙时它们怎么发现对方、怎么发起请求、怎么传递上下文、怎么返回结果。MCP解决的是Agent调工具A2A解决的是Agent调Agent这是两个完全不同的通信模式。Skills是员工的技能包。一个Agent会什么、怎么把一项能力封装成可复用的模块、怎么在不同Agent之间共享同一套技能。它管的是能力复用和能力扩展。理清这层关系之后架构就清晰了DeepAgents负责顶层编排MCP负责工具接入A2A负责Agent间通信Skills负责能力封装。四者叠加才构成一个完整的、可扩展的Agent集群。1.2 为什么这四个必须一起上单独用任何一个都能跑但都会遇到天花板。只用DeepAgents不用MCP每个Agent的工具调用都要硬编码接一个新工具就要改Agent代码扩展性极差。只用MCP不用A2AAgent之间没法直接协作所有协调都得靠中心化的编排器一旦编排逻辑复杂起来就变成一团乱麻。只用A2A不用Skills每个Agent的能力都是散装的同样的能力在多个Agent里重复实现维护成本爆炸。我实测下来的感受是MCP和A2A是基础设施Skills是复用层DeepAgents是调度层。基础设施不稳上面盖多高都会塌。所以搭建顺序应该是先MCP、再A2A、然后Skills、最后DeepAgents编排。很多人反过来做先搭编排框架结果发现底层通信和工具接入全是坑返工成本极高。1.3 一个容易混淆的点MCP和A2A的边界这是我在实际搭建中踩得最深的一个坑。MCP和A2A看起来都是通信协议很容易混用。我一开始甚至想过用MCP来让Agent互相调用结果发现完全走不通。核心区别在于MCP是Client-Server模式A2A是对等模式。MCP里Agent是Client工具是ServerServer是被动的、无状态的它不会主动发起请求。而A2A里两个Agent是对等的任何一方都可以主动发起任务、可以有自己的状态和记忆、可以拒绝或协商。举个具体例子你要让一个研究Agent去查资料然后交给写作Agent成文。查资料这个动作研究Agent通过MCP调用搜索工具这是MCP的范畴。但研究Agent把结果交给写作Agent这个动作是A2A的范畴因为写作Agent是一个有自己判断能力的实体它可能觉得资料不够要求补充这种双向协商MCP做不了。记住一条判断准则如果对方是一个无状态的能力提供方用MCP如果对方是一个有状态、会思考、能协商的Agent用A2A。混用这两个协议是多Agent系统里最常见的架构错误。2. MCP接入工具层的标准化是整个集群的地基MCP这一层看起来最简单实际上最容易埋雷。我见过太多项目在这一层偷懒后面全部返工。2.1 MCP Server的三种接入方式怎么选MCP Server的接入方式主要有三种各有适用场景选错了后期很痛苦。接入方式适用场景优点缺点本地进程stdio单机开发、工具轻量启动快、调试方便无法跨机器、并发能力弱HTTP/SSE生产环境、多Agent共享可跨机器、支持并发需要处理连接管理、超时容器化部署工具依赖复杂、需要隔离环境干净、易扩展启动慢、资源占用高我的建议是开发阶段用stdio快速验证生产环境一律上HTTP/SSE。stdio方式在单Agent场景下很爽但一旦多个Agent要共享同一个工具stdio的进程模型就会出问题——每个Agent起一个进程工具状态不共享缓存全废。容器化部署适合那些依赖特别重的工具比如需要特定Python版本、特定系统库的工具。但要注意容器启动有冷启动延迟如果你的Agent对响应时间敏感得做预热或者常驻。2.2 工具描述写得好不好直接决定Agent会不会用这是最容易被忽视的一点。MCP工具的description字段不是写给人看的文档是写给模型看的prompt。我踩过的坑是工具描述写得太简略模型根本不知道什么时候该调用它要么不调用要么乱调用。一个好的工具描述应该包含四个要素这个工具做什么一句话说清楚核心功能什么时候用明确触发条件最好给出典型场景输入参数的含义和格式每个参数都要说明尤其是格式敏感的返回什么让模型知道调用后能拿到什么举个例子一个搜索工具的描述搜索互联网获取实时信息。当需要查询最新新闻、实时数据、 或训练数据之外的信息时使用。输入query为搜索关键词 返回包含标题、摘要、链接的结果列表。对比一个糟糕的描述搜索工具。后者模型基本不会正确使用。我实测下来工具描述从能用优化到好用Agent的任务完成率能提升30%以上这个投入产出比极高。2.3 MCP Resource和Tool的区别别搞混MCP里有两个核心概念Tool和Resource。很多人一开始分不清。Tool是动作会改变状态或产生副作用比如发送邮件写入文件调用API。Resource是数据是只读的比如读取配置文件获取数据库schema读取文档内容。为什么要区分因为模型对这两类的处理逻辑不同。Tool调用需要谨慎因为可能有副作用通常需要确认或限制频率。Resource读取相对安全可以更自由地调用。我见过有人把所有东西都做成Tool结果模型频繁调用读取类操作浪费token还拖慢速度。正确的做法是只读的、幂等的能力做成Resource有副作用的做成Tool。2.4 流式输出到文件的实战细节热词里提到使用mcp工具流式输出内容到文件这是个很实用的场景但坑不少。核心问题是MCP工具调用默认是请求-响应模式一次性返回结果。如果要流式输出需要在工具实现里做特殊处理。我的做法是让工具返回一个流式句柄或者分块返回Agent侧做拼接。具体实现上要注意几点分块大小要合理太小则调用频繁太大则失去流式意义。我一般用1-4KB一块要处理中断流式过程中如果Agent决定停止工具侧要能感知并清理资源要处理错误流到一半出错已经写入的部分怎么处理要有明确策略流式输出到文件时建议先写到临时文件全部完成后再原子性地重命名到目标文件。否则中途失败会留下半截文件后续读取会出问题。3. A2A通信Agent之间怎么说话才不乱A2A是多Agent系统里最复杂的部分因为它涉及状态、协商、错误处理。我在这块踩的坑最多。3.1 Agent CardAgent的名片怎么设计A2A里有个核心概念叫Agent Card可以理解为Agent的名片。它描述了这个Agent是谁、能做什么、怎么调用它、需要什么输入、返回什么输出。Agent Card设计得好不好直接决定了Agent之间能不能顺利协作。我一开始把Agent Card写得很简单结果发现Agent A根本不知道该怎么跟Agent B沟通经常传错参数或者发起B处理不了的任务。一个好的Agent Card应该包含身份信息Agent的名称、版本、描述能力列表这个Agent能处理哪些类型的任务输入规范接受什么格式的输入必填和选填字段输出规范返回什么格式的结果调用端点怎么找到它、怎么发起请求限制条件速率限制、并发限制、超时设置这里的关键是输入输出规范要足够明确最好用schema定义。模型看到明确的schema才知道怎么构造请求。3.2 任务生命周期从发起到完成的完整链路A2A的任务不是简单的请求-响应它有完整的生命周期。我把它拆成几个阶段发现阶段Agent A怎么知道Agent B的存在和能力。这靠Agent Card的注册和查询机制。协商阶段Agent A发起任务Agent B评估自己能不能做。如果不能可以拒绝或建议转给其他Agent。执行阶段Agent B执行任务期间可能通过流式事件汇报进度。完成阶段Agent B返回结果Agent A接收并处理。异常阶段任何阶段出错都要有明确的错误传递机制。我踩的坑主要在协商阶段。一开始我假设Agent B总是能处理Agent A发来的任务结果经常出现B处理不了但又不知道怎么拒绝的情况任务就卡住了。后来加了明确的能力评估环节B收到任务先判断自己能不能做不能做就明确返回拒绝并附上原因A再决定是重试、转派还是放弃。3.3 上下文传递传什么、传多少Agent之间传递上下文是个微妙的问题。传太少接收方信息不足做不了决策传太多token爆炸还引入噪声。我的经验是分层传递必传任务目标、关键约束、期望输出格式选传相关背景、历史对话摘要、参考案例不传完整的原始对话、无关的中间过程、大段原始数据具体怎么把握我一般遵循接收方需要什么就传什么的原则。在Agent Card里明确定义输入schema发送方按schema构造接收方按schema解析。这样既不会漏传也不会多传。还有一个技巧用引用代替内联。如果上下文里有大段数据不要直接塞进消息里而是传一个引用比如文件路径、资源ID接收方需要时再去取。这样消息体积小传输快也避免了重复传输。3.4 错误处理和重试别让一个Agent挂掉拖垮整个集群多Agent系统里错误是常态。网络抖动、工具超时、模型输出格式错误任何一个环节都可能出问题。如果错误处理做不好一个Agent挂掉可能引发连锁反应。我的做法是三层防护单次调用层每个A2A调用都有超时设置超时后返回明确的错误而不是无限等待重试层对可重试的错误网络超时、临时不可用做指数退避重试对不可重试的错误参数错误、能力不匹配直接失败降级层如果某个Agent持续不可用编排层要能感知并切换到备用方案比如换一个Agent、或者用简化流程这里有个细节重试要幂等。如果Agent B的任务有副作用比如写文件、发请求重试可能导致重复执行。所以要么任务设计成幂等的要么在A2A协议里加去重机制比如用任务ID去重。我实测下来A2A调用里最容易出问题的是超时设置。默认超时往往太长一个Agent卡住会拖慢整个流程。建议根据任务类型设置差异化超时简单查询5-10秒复杂任务30-60秒超长任务用异步轮询模式。4. Skills封装让能力真正可复用、可扩展Skills这一层是决定系统能不能规模化的关键。如果每个Agent的能力都是散装的Agent越多维护成本越高。4.1 Skill的粒度怎么把握Skill粒度是个需要反复权衡的问题。太粗复用性差太细组合成本高。我的经验法则是一个Skill对应一个完整的、有明确输入输出的能力单元。判断标准是这个能力能不能独立测试能不能被不同Agent以相同方式调用如果能就是一个合适的Skill粒度。举个例子发送邮件是一个Skill格式化邮件内容是另一个Skill选择收件人又是一个Skill。这三个可以组合成发送通知邮件这个更复杂的能力但底层是三个独立Skill。这样设计的好处是写作Agent可能只需要格式化邮件内容通知Agent需要完整的发送通知邮件各取所需。反过来如果把发送通知邮件做成一个大Skill写作Agent想复用它的一部分就做不到只能重新实现复用性就没了。4.2 Skill的接口设计稳定比灵活更重要Skill一旦被多个Agent依赖接口就不能随便改。所以设计Skill接口时要面向稳定设计而不是面向当前需求设计。具体做法输入输出用结构化schema不要用自由文本用明确的字段定义预留扩展字段用可选字段而不是位置参数方便后续加参数而不破坏兼容性版本化Skill要有版本号重大变更时升版本老版本保留一段时间错误码标准化不同Skill的错误码要统一规范方便调用方统一处理我踩过的坑是早期Skill接口设计得太贴合当前需求用了很多位置参数和隐式约定。后来需求一变接口就得改所有调用方都得跟着改痛苦不堪。后来改成结构化schema可选字段扩展就顺畅多了。4.3 Skill的发现和加载机制当Skill多起来之后怎么让Agent知道有哪些Skill可用、怎么加载就成了问题。我的方案是注册中心按需加载所有Skill在注册中心登记包含名称、描述、schema、版本Agent启动时只加载元数据名称、描述不加载实现真正调用某个Skill时才动态加载其实现这样做的好处是启动快、内存占用低。缺点是首次调用有加载延迟可以通过预热常用Skill来缓解。Skill的发现可以基于语义匹配Agent描述自己需要什么能力注册中心返回匹配的Skill列表。这比硬编码Skill名称灵活得多新增Skill时不需要改Agent代码。4.4 Skill的测试和版本管理Skill要被多个Agent复用质量必须过关。我的做法是每个Skill都要有单元测试验证Skill在各种输入下的行为契约测试验证Skill的输入输出符合schema集成测试验证Skill在真实Agent调用下的表现版本管理上我用语义化版本主版本号变更表示不兼容的接口变更次版本号表示向后兼容的功能新增修订号表示bug修复。Agent依赖Skill时指定版本范围避免意外升级导致的问题。一个实用技巧给每个Skill加一个健康检查接口返回Skill的可用状态和依赖状态。编排层可以定期检查发现异常Skill及时告警或降级。5. DeepAgents编排把前面三层串起来前面三层搭好之后DeepAgents这一层就是做调度和协调。这层看起来是上层建筑实际上最容易出问题因为它要处理的是全局的复杂性。5.1 编排模式的选择中心化还是去中心化多Agent编排有两种基本模式中心化编排和去中心化编排。中心化编排有一个主Agent或编排器负责拆解任务、分配子任务、汇总结果。所有Agent都向主Agent汇报。优点是逻辑清晰、容易调试、全局状态可控。缺点是主Agent是瓶颈复杂任务下主Agent的上下文会爆炸。去中心化编排Agent之间直接协作没有中心节点。优点是扩展性好、没有单点瓶颈。缺点是全局状态难追踪、调试困难、容易出现死循环或任务丢失。我的实测结论是混合模式最实用。顶层用中心化编排做任务拆解和结果汇总子任务内部用去中心化协作。这样既有全局可控性又有局部灵活性。具体来说主Agent负责把大任务拆成几个子任务每个子任务交给一个子编排Agent子编排Agent内部可以自由调用其他Agent和Skill完成后把结果返回给主Agent。主Agent不需要知道子任务内部的细节只需要知道子任务的输入输出。5.2 任务拆解的粒度拆到多细才合适任务拆解粒度直接影响系统效率和可靠性。拆得太粗单个Agent负担重、容易失败拆得太细Agent间通信开销大、协调复杂。我的经验是按可独立完成的最小单元拆解。判断标准这个子任务能不能由一个Agent独立完成不需要中途和其他Agent协商如果能就是一个合适的拆解粒度。举个例子写一篇技术文章可以拆成调研资料列大纲写正文校对。这四个子任务各自可以由一个Agent独立完成中间不需要协商除了大纲到正文的传递。如果拆成写第一段写第二段就太细了因为段落之间需要连贯性拆开反而增加协调成本。还有一个技巧拆解时预留缓冲。不要把任务拆得刚刚好留一些余量给Agent自主发挥。比如调研任务不要规定查5个来源而是说查足够多的来源以支撑论点让Agent自己判断。5.3 结果汇总怎么把多个Agent的输出拼成完整答案结果汇总是编排层的关键环节。多个Agent的输出格式可能不同、质量参差不齐、甚至互相矛盾。怎么汇总成一致的最终答案我的做法是结构化汇总冲突消解每个子任务返回结构化结果包含内容、置信度、来源汇总时先做格式归一化统一成标准结构如果有冲突比如两个Agent给出矛盾信息触发冲突消解流程要么让一个Agent仲裁要么补充调研要么在最终答案里标注分歧这里要注意不要简单拼接。我见过很多实现是把各Agent的输出直接拼起来结果读起来像大杂烩。好的汇总应该是融合——提取各输出的核心信息重新组织成连贯的答案。5.4 可观测性多Agent系统没有日志就是灾难多Agent系统最怕的就是黑盒——出了问题不知道哪个环节错了。所以可观测性必须从第一天就做。我的做法是全链路追踪每个任务有唯一ID贯穿所有Agent调用每次Agent调用、Skill调用、MCP调用都记录输入、输出、耗时、状态关键决策点记录决策依据比如为什么选择这个Agent、为什么重试提供可视化界面能看到任务的完整执行链路这样出问题时能快速定位是哪个Agent、哪个Skill、哪个工具出了问题。没有这套机制多Agent系统的调试基本靠猜。一个实用建议日志里记录token消耗。多Agent系统token消耗很容易失控有了消耗数据才能做优化。我一般会统计每个Agent、每个Skill的平均token消耗找出消耗大户重点优化。6. 实测中踩过的坑和对应的解法前面讲了架构和设计这一节专门讲实测中遇到的具体问题。这些坑文档里基本不会写但实际搭建时几乎都会遇到。6.1 Agent之间死循环调用这是最危险的问题。Agent A调用Agent BB又调用A无限循环token烧光。根因Agent之间没有调用深度限制也没有循环检测。解法在A2A协议里加调用链追踪。每次调用携带调用链谁调用了谁接收方检查调用链里有没有自己如果有就拒绝。同时设置最大调用深度超过就中断。我实测下来光加调用链检测还不够因为有些循环是间接的A→B→C→A。所以还要加全局的调用计数单个任务的总调用次数超过阈值就告警。6.2 上下文爆炸导致模型输出质量下降多Agent协作时上下文会不断累积。Agent A的对话历史传给BB又传给C上下文越来越长最后模型被淹没在无关信息里输出质量急剧下降。根因上下文无节制传递没有做压缩和筛选。解法分层传递摘要压缩。必传的信息直接传选传的信息做摘要不传的信息丢弃。我一般会在Agent之间传递时把历史对话压缩成一段摘要只保留关键决策和结论。还有一个技巧用结构化上下文代替自然语言上下文。把关键信息提取成结构化字段任务目标、约束、已知事实、待解决问题比传一大段对话有效得多。6.3 Skill版本不兼容导致Agent行为异常Skill升级后依赖它的Agent行为变了甚至报错。根因Skill升级没有做兼容性检查Agent依赖没有锁定版本。解法Skill用语义化版本Agent依赖时指定版本范围。Skill升级时跑契约测试确保向后兼容。重大变更时升主版本号老版本保留给Agent迁移时间。我踩过的坑是早期Skill没有版本管理直接覆盖升级结果一个Agent的行为突然变了排查了半天才发现是Skill升级导致的。后来加了版本管理这类问题就没了。6.4 MCP工具超时导致整个任务卡住某个MCP工具响应慢Agent一直等整个任务卡住。根因MCP调用没有超时设置或者超时设置太长。解法每个MCP调用都要有超时超时后返回明确错误Agent根据错误决定重试还是降级。超时时间根据工具类型设置查询类5-10秒写入类30秒长任务用异步模式。还有一个细节超时后要清理资源。如果工具调用已经发起了外部请求超时后要确保请求被取消避免资源泄漏。6.5 Agent能力重叠导致任务分配混乱多个Agent都能做某件事编排层不知道该分配给谁或者分配了但效果不好。根因Agent能力定义不清晰没有优先级和专长区分。解法Agent Card里明确能力范围和专长领域。编排层分配任务时优先选专长匹配的Agent没有专长匹配的再选通用Agent。同时记录每个Agent的历史表现作为分配依据。我一般会给Agent加一个能力评分表示它在某个领域的擅长程度。编排时按评分排序选最高的。这样既避免了混乱又能持续优化分配策略。7. 从单Agent到集群的渐进式演进路线如果你现在还在写单Agent想往多Agent集群演进我的建议是渐进式不要一步到位。7.1 第一阶段单AgentMCP先把单Agent跑通接入MCP工具。这个阶段的重点是把工具描述写好、把MCP调用封装好、把错误处理做好。这个阶段不需要A2A和Skills但要把基础打牢。我见过很多人跳过这个阶段直接上多Agent结果基础不牢后面全是坑。单Agent阶段把MCP玩熟了后面接A2A和Skills会顺很多。7.2 第二阶段引入Skills把单Agent的能力拆成Skill做封装和复用。这个阶段的重点是Skill粒度设计、接口稳定性、版本管理。这个阶段还是单Agent但能力已经模块化了。这个阶段的好处是当你后面要加第二个Agent时可以直接复用已有的Skill不用重新实现。7.3 第三阶段引入A2A两个Agent协作从两个Agent开始引入A2A。这个阶段的重点是Agent Card设计、任务生命周期、错误处理。两个Agent的协作比单个Agent复杂得多但比多个Agent简单适合练手。我建议先做最简单的场景一个Agent负责调研一个Agent负责写作调研Agent通过A2A把结果交给写作Agent。跑通这个场景A2A的核心机制就掌握了。7.4 第四阶段DeepAgents编排扩展到多Agent有了前面的基础再引入DeepAgents做编排扩展到多个Agent。这个阶段的重点是编排模式选择、任务拆解、结果汇总、可观测性。这个阶段最容易出问题的是全局复杂性。Agent一多交互路径爆炸调试困难。所以可观测性必须提前做好否则后面寸步难行。7.5 每个阶段的验证标准每个阶段都要有明确的验证标准达标了再进下一阶段阶段验证标准单AgentMCP工具调用成功率95%错误处理覆盖主要异常引入SkillsSkill可独立测试接口稳定版本管理规范引入A2A两Agent协作任务完成率90%无死循环DeepAgents编排多Agent任务完成率85%全链路可追踪这些标准不是绝对的但能帮你判断是否准备好进入下一阶段。我见过太多项目在基础不牢的情况下强行上多Agent最后推倒重来。8. 一些关于扩展性和长期维护的思考多Agent集群搭起来只是开始长期维护才是真正的挑战。这一节聊聊扩展性和维护方面的经验。8.1 新增Agent的成本要尽可能低一个好的多Agent架构新增一个Agent应该是低成本的写好Agent Card、实现核心逻辑、复用已有Skill、注册到编排层就能用。如果新增一个Agent要改很多地方改编排逻辑、改其他Agent、改通信协议说明架构有问题。我在设计时会刻意追求新增Agent零侵入——新Agent通过标准接口接入不影响已有Agent。8.2 Skill的复用率是衡量架构好坏的关键指标如果你的Skill大部分只被一个Agent使用说明Skill粒度或设计有问题。好的Skill应该被多个Agent复用。我一般会统计Skill的复用率复用率低的Skill要么合并、要么重新设计。这个指标能反映架构的健康度。8.3 协议变更要向后兼容MCP和A2A的协议可能会演进Agent Card的schema可能会变。任何变更都要考虑向后兼容否则已有Agent会全部失效。我的做法是协议变更时保留旧版本支持新版本并行运行一段时间给Agent迁移时间。重大变更时提供迁移工具和文档。8.4 定期做混沌测试多Agent系统的健壮性很难通过正常测试验证。我一般会定期做混沌测试随机让某个Agent不可用、随机让某个MCP工具超时、随机注入错误看系统能不能正确处理。这种测试能发现很多正常测试发现不了的问题比如错误处理不完整、降级逻辑有bug、重试机制失效等。混沌测试的关键是可控——要能精确控制注入什么故障、在哪个环节注入。我一般会做一个故障注入开关测试时打开生产时关闭。9. 写在最后的一些个人体会这套东西我从零搭到能跑前后花了大概两个月中间返工了好几次。最大的体会是多Agent系统的难点不在单个技术点而在整体的协调和边界划分。MCP、A2A、Skills、DeepAgents每一个单独看都不复杂但组合起来边界在哪里、谁负责什么、怎么交互这些才是真正花时间的地方。另一个体会是不要追求一步到位。我一开始想直接搭一个完整的多Agent集群结果处处是坑进度极慢。后来改成渐进式先把单AgentMCP跑稳再加Skills再加A2A最后上编排每一步都验证通过再往下走反而快了很多。最后一个实用建议从第一天就做可观测性。多Agent系统没有日志和追踪调试就是噩梦。我早期偷懒没做后来补的时候发现很多历史问题已经无法复现了。现在我的做法是任何Agent、Skill、MCP调用都必须记录宁可多记也不要漏记。这套架构目前在我自己的项目里跑得还算稳任务完成率在85%以上主要的失败case集中在复杂任务的拆解和汇总环节这也是我接下来要重点优化的方向。如果你也在搭类似的东西欢迎交流踩坑经验尤其是A2A的错误处理和Skill的版本管理这两块我觉得还有很大的优化空间。