多智能体工程化落地：MCP、A2A与Skills协同架构实践

近两年多智能体工程化的话题确实火了但大部分讨论都停留在单机Demo和玩具场景里真正能把多个智能体拉进生产环境、让它们像团队一样协作的人并不多。我自己从单体Agent转向多智能体架构折腾了大半年中间推翻了三版设计方案最后沉淀下来一套还算清晰的路子把MCP当连接器、把A2A当通信总线、把Skills当团队能力资产。DeepAgents这种深度工作流才真正有了落地的形状。这篇文章不聊概念包装只讲我实际是怎么拆解、怎么落地、踩了哪些坑的。如果你正在做Agent平台、想改造现有单体Agent系统、或者只是想知道MCP和A2A之间到底什么关系这篇内容应该能帮你少走不少弯路。1. 单体智能体为什么撑不起复杂业务1.1 单体智能体的天花板不在模型而在容器很多人以为Agent的能力上限取决于底层大模型模型强一切就强。实际跑过复杂业务之后你会发现真正卡脖子的地方是单体架构自身的容器边界。单体Agent把所有能力塞在一个上下文窗口里要读数据库、要调API、要操作浏览器、要写文件、还要理解用户意图。表面上看着全能但一旦任务链条变长问题立刻暴露。第一是上下文污染一个任务里残留的工具调用痕迹会干扰下一个任务的决策第二是工具规模受限一个模型会话里塞几十个工具定义之后光工具选择的token消耗就占了推理成本的很大比例响应速度肉眼可见地变慢第三是故障半径太大任何一个工具连接出问题整个Agent就瘫痪了。更麻烦的是单体架构没法做能力治理。部门A想复用部门B沉淀的某个业务技能只能把人家的代码连带上下文一起拷过来既没有版本概念也没有权限边界时间一长整个系统变成一锅粥。1.2 组织的本质是定义边界和协作契约从单体走向组织这跟公司从小作坊变集团是同一个逻辑。小作坊一个全能师傅从头干到尾集团则需要多个专业团队、按标准接口协作。多智能体架构也一样核心不是在技术上做分布式而是给每个Agent划清楚责任边界再定义它们之间的协作契约。谁负责理解用户意图谁负责任务拆解谁负责执行具体工具调用谁负责校验结果这些角色一旦分清楚每个Agent的上下文窗口就只需要关注自己的那一小块领域。模型能力不需要提升整体系统的复杂度和可靠性反而上了一个台阶。这也是为什么我后来理解DeepAgents这个词的时候倾向于把它理解成深度专业化的Agent而不是更聪明的Agent。它不靠某一两个模型变强而是靠架构上让每个智能体在自己的职责圈内做到极致。2. MCP、A2A、Skills三者到底各管哪一段2.1 MCP把工具和数据的连接标准化MCPModel Context Protocol解决的其实是最底层的问题智能体如何以统一方式连接外部工具、数据和系统。没有MCP之前Agent接一个工具写一套集成代码。接数据库要写数据库驱动接飞书要调飞书SDK接浏览器要搞Playwright五花八门的实现方式导致Agent开发量一半都花在适配器上。MCP出现之后工具提供方把它封装成MCP Server暴露一组标准化的工具、资源和promptAgent这边只需要按MCP协议去发现和调用就行。对接新工具的成本从几天降到了几小时。打个比方MCP对于Agent世界相当于USB-C对于硬件世界。现在各种设备都是USB-C口认证握手、供电、数据传输都在一个口里完成。MCP就是Agent的USB-C标准化之后生态才能指数级增长。我实际试下来MCP对工程化最有价值的还不是调用本身而是它定义了完整的生命周期管理工具列表可以动态发现、参数schema自带校验、能力变化能被客户端感知。这让Agent系统具备了热插拔能力新增一个数据源不需要重新发布整个应用。2.2 Skills能力从代码走向资产MCP解决了工具接入的问题但工具的粒度往往比较细碎。一个MCP Server可能提供二十多个工具Agent拿到这些工具之后依然不知道先做什么后做什么。Skills解决的是让能力变成可复用、可传授的方法论。我理解的Skills不仅仅是函数的集合而是将目标、流程、知识、工具调用方式打包成一个完整单元。比如一个市场调研Skill它内部定义了调研计划怎么制定、用哪些检索工具、结果按什么格式归档甚至包括不同场景下的分支处理逻辑。Agent加载这个Skill之后相当于一个刚入职的分析师拿到了一份SOP手册照着做就能达到及格线。Skills的价值还在于组织沉淀。单个Agent的能力会随着会话消亡但Skills可以被保存、版本化、分发、复用。团队里一个Agent跑通了一套优质工作流沉淀成Skill之后所有其他Agent都能瞬间获得这块能力增量。这种机制让系统整体能力随使用时长增长而不是每次都从零开始。我在实际落地中会把Skills和MCP配合使用MCP负责能连什么Skills负责该怎么做。一个是插头一个是操作手册两个都不冲突也都不可替代。2.3 A2A智能体之间怎么产生组织MCP和Skills解决的是单个智能体的能力问题A2AAgent-to-Agent协议则面向多智能体之间的通信协作。A2A协议要解决的核心问题有三个任务分发、能力发现、结果共享。任务分发是指一个Agent把自己搞不定的子任务交给另一个Agent去处理。能力发现是指主Agent知道团队里其他Agent各自擅长什么、谁可以接手什么任务。结果共享则是指不同Agent产出的中间结果如何互相传递、校验和汇编。比较常见的实现方式是Agent通过A2A协议暴露自己的能力卡片描述自己会做什么、输入输出格式是什么、价格与性能特征是什么。调度Agent维护一张能力列表拿到任务后做匹配匹配就派发派发后跟踪执行状态直到结果返回。A2A和多智能体框架里的编排是有区别的。编排往往是中心化的一个调度中枢控制所有子Agent而A2A更强调去中心化的握手协作。A2A场景中调度Agent和干活Agent之间是相对对等的协议关系任何一方挂了另一方都能感知并进行相应处理这更接近真实组织里部门与部门之间配合的样子。3. 一套可落地的多智能体架构是怎么搭起来的3.1 顶层设计先画能力地图再分层我搭这套架构的时候最重要的一步不是在写代码而是先画了一张能力地图把业务要干的事情拆成最小功能单元再按照责任归属归拢到不同的Agent。举个例子一个内容生产类业务会拆成这样主编Agent接收需求、制定选题方向、拆任务、审稿资料Agent负责检索资料、整理素材、输出事实核查报告写作Agent负责根据选题和素材产出初稿校对Agent负责语法、事实、风格的终审和修改每个Agent只做一件事但每个Agent都有自己的上下文、MCP工具列表和Skills。分工明确之后协作路径自然也很清晰主编拆完任务把资料需求发给资料Agent资料Agent完成后把素材包交回主编主编连同写作需求一起派给写作Agent写作Agent出的初稿交给校对Agent校对结果回主编。架构分层的逻辑是这样的最底层是工具和连接层走MCP协议再往上是能力层每个Agent通过加载Skills获得岗位能力再往上是协作层走A2A做任务分发与结果汇总最顶层是调度入口层负责接收外部请求、维护全局状态。每一层单独演进互不过度耦合。3.2 MCP资源、Skill注册表、A2A节点三个核心部件落地的时候有三个核心部件每个都要认真做。第一个是MCP资源网关。我并没有让每个Agent各自去连各种MCP Server而是做了一个统一的网关层把所有MCP Server的认证信息、访问控制、可用状态集中管理。Agent发起工具调用请求时网关负责鉴权、转发和限流。这样做有几个实际的好处一是权限控制集中不用每个Agent配一套密钥二是调用审计集中谁调了什么一目了然三是故障排查集中工具超时了在网关层就能看到不用每个Agent翻日志。网关层还需要做协议转换与缓存。有的MCP Server走标准Streamable HTTP有的是本地stdio进程网关把连接方式差异屏蔽掉对内统一暴露一种调用方式即可。对于一些高频只读工具比如查库存、查价格网关还能做短TTL缓存大幅降低对上游系统的压力。第二个是Skill注册表。由中央注册表实现本质是一个带版本控制、标签索引、依赖管理的Skill仓库。每个Skill包里面包含SKILL.md描述文件定义触发条件和能力边界、工作流定义、关联的MCP工具列表、提示词模板和示例。在Skill注册表里我给每个Skill定义了三类元数据触发条件什么任务会用到它、所需MCP工具运行它需要连接哪些外部能力、输出契约产出什么格式的结果。有了这三类元数据调度Agent才能正确决策哪个Skill适合当前任务。Skill一定要做版本管理我踩过坑有一次更新了一个Skill的prompt模板没注意所有下游Agent还在用旧版本缓存结果改了不生效。后来所有Skill加载都走注册表动态拉取并且在大版本变更时强制刷新。第三个是A2A节点网络。每个Agent部署为一个A2A节点对外暴露能力描述。调度层维护一张拓扑表来跟踪节点健康状况和能力路由信息。A2A节点的具体实现我采用了类似这样结构节点信息名称、职责、支持的任务类型输入接收任务时的数据schema输出任务完成后的交付物schema状态回调执行进度怎么同步给调用方有了这三个部件之后新增一个Agent角色就变成了标准操作挂一个新的A2A节点加载对应的Skills在网关里开通所需的MCP权限。整个过程不需要改其他Agent的代码这就是组织化带来的伸缩性。3.3 一个完整任务链路的长什么样我拿一个客户投诉分析报告场景讲一下完整链路。用户在入口提交需求入口层的编排Agent先做任务拆解把一句话需求拆成检索投诉工单、做分类统计、生成分析结论、输出报告。编排Agent向A2A能力路由发起匹配找出负责检索的Agent。检索Agent加载了工单检索Skill该Skill关联的MCP Tools包含工单系统的查询接口和数据库读取接口。检索Agent通过MCP网关完成数据拉取后按Skill定义的格式整理出结构化结果通过A2A协议把数据包传回编排Agent。编排Agent再把结构化数据下发给分析Agent分析Agent加载投诉归因分析Skill它的MCP工具链里有分类模型API和可视化组件库输出图表和归因结论。再经过审核Agent做事实核验后最终汇总成报告。这个链路里每个环节之间传递的都是结构化数据不是自然语言的自由文本这是工程化落地最关键的细节。自由文本容易被理解和演绎但很难被下游稳定消费。技能包内部的中间数据格式一旦用JSON Schema约定好下游Agent的解析就是确定性操作这比让模型二回目去理解文本可靠得多。4. MCP实战里的关键设计决策4.1 MCP工具设计粒度、命名、参数约束MCP工具的设计如果只图省事把内部服务的方法原样暴露后面一定会被自己坑到实践。我建议工具粒度遵循能够独立完成一项业务原子操作的原则。比如一个订单系统创建订单查询订单状态取消订单可以拆成三个工具但如果做成一个通用的订单操作工具参数里再塞操作类型Agent在调用时的决策负担就会成倍增加。工具命名也很重要要让Agent一看就懂。描述文本一定要写清楚工具适用场景、边界或不适用的情况、参数含义尤其是在模型做函数调用时描述质量直接决定工具命中率。我建议每个工具的Description不少于50个汉字包含触发条件、返回内容概要、常见错误原因三个要点。参数约束要尽量用强类型。能用number就不要用string能用枚举就不要自由输入。MCP的schema理论上支持JSON Schema全文特性但最终执行时还得看各个Agent框架的兼容水平。保守起见避免用过于复杂的嵌套类型很多Agent框架在解析深层嵌套时容易出问题。4.2 资源、提示词和工具三类能力的合理分工MCP规范中除了工具还定义了资源和提示词两类能力。很多人的使用误区是把所有东西都塞进Tools实际上这三类有明确分工。Tools解决的是数据操作问题属于动态执行单元。Resources解决的是数据读取问题适合暴露文档内容、数据库schema、配置文件等可以被Agent读取但不需要参数过滤的信息。Agent在需要检索或参考某份特定内容如查询用户协议全文的时候直接读取Resource即可不占用工具调用的token开销。Prompts则是面向特定任务的复用模板。比如一个审计日志分析的MCP Prompt内置了分析步骤和输出格式。Agent加载这个Prompt就可以了比自己组织一套分析指令要稳定得多。实践里比较推荐的组合方式是高频、可参数化的操作定义为工具低频、大体积的参考内容定义为资源带特定方法论的分析任务定义为提示词。三者共同构成MCP Server的能力矩阵。4.3 没有现成MCP Server的场景怎么做适配有一点要说在前面MCP生态还在早期阶段目前很多企业内部系统根本没有现成的MCP Server可以用。常见的应对思路这么看如果目标是存量HTTP API可以直接做一层轻量MCP适配器把OpenAPI规范转换成MCP工具定义。现在市面上已经有比较好用的转换工具了读取OpenAPI的schema之后自动生成MCP Server骨架再针对性的补充描述和参数约束即可。适配层要注意鉴权方式对齐企业内部系统常见的token、OAuth或AK/SK签名在MCP Server里都能封装。如果目标是数据库不要直接把数据库开放成MCP Server。更好的做法是做一个受限的查询服务只暴露经过审批的只读查询并且加LIMIT、超时、结果集大小限制。直接开放原始SQL查询风险太高Agent生成的SQL质量和安全性都没有保证。如果目标是遗留命令行工具可以用shell封装的方式做成MCP Server接收结构化参数、拼装命令执行、返回结果。这种方案开发成本最低但要注意命令注入的防范参数白名单验证是必须的不能把原始传参拼进shell。真到了找不到任何适配思路的那一步就要反思一下边界了。有些事情目前确实不适合接给Agent硬接只会带来无尽的维护成本这是排优先级的时候必须看清的问题。5. A2A协作里的靠谱实践5.1 能力发现Agent怎么让别人知道我会什么A2A组织里多个Agent要先知道彼此能力才能协同作业。协议上我采用了能力卡片的思路每个Agent启动的时候把自己支持的任务类型、输入输出schema、版本号上报到路由表。路由表维护当前系统里有谁、会什么、状态是否健康。能力卡片应该比人写的职责描述更严谨。我实践的写法是把能力描述拆成机器可读的声明式schematask_type明确任务类型input_schemaJSON Schema声明确切输入结构output_schema明确交付物结构quality_metrics声明交付标准如准确率、覆盖率等有了这份卡片调度层的路由匹配就变成确定性过程把任务需求用同样的schema描述出来然后做结构匹配而不是靠大模型猜应该派给谁。确定性的匹配机制配合上兜底式的大模型智能路由实际效果比较理想。5.2 任务生命周期管理状态机是A2A可靠性的底座Agent之间协作最怕什么最怕任务发出去之后没有任何状态反馈调用方一直在干等最后超时崩溃。我给所有A2A任务引入一个生命周期状态机包含这些状态submitted已提交等待接收方确认working接收方已接单正在执行blocked阻塞等待更多信息或人工介入completed已完成并返回结果failed执行失败canceled被取消协议规定无论哪方调用都必传当前状态。接收方每完成一个关键节点都要回调一次状态更新。这样调用方可以清晰地知道任务卡在哪一环上超时之后也能准确判断是应该重试还是标记失败换路。超时重试也有讲究。我一般分三个阶梯快速失败网络抖动类短超时快重试、中级重试执行不稳定类指数退避、人工介入超过设定次数后直接上报警。这个机制让A2A协作的容错能力有了保障。5.3 结果校验A2A链路里最容易被忽略的环节跨Agent传输结果时最隐蔽的问题是格式对了但内容错了。接收方按schema解析没有报错但业务上结果根本不可用。我在实践中加入了双重复核机制。第一重是契约校验Schema解析纯确定性检查字段类型、必填项、取值范围都核对一遍这一个环节能拦截大部分低级错误。第二重是语义校验用一个小模型快速评估结果是否满足任务要求输出结构化满意度评分。这一重不是全量做只针对关键任务、关键交付物来做。比如写报告任务就会让另一个Agent快速检查数据引用是否来自检索结果、结论是否有据可依。这两重校验做下来兜住了大部分低级错误。剩下的就是偶发的业务逻辑漏洞了那是另一个范畴的问题。6. Skills体系的设计与落地6.1 Skills该拆多细该合多拢Skills的颗粒度是设计中最考验功力的部分之一。拆太细会产生大量碎片化Skill管理成本变高拆太粗则跟单体Agent没区别灵活性大打折扣。我采用的参考标准是一个Skill应该能独立完成一条完整的能力链路。比如生成周报是一个Skill它内部会调用数据查询、文案撰写、格式排版三个工具可能对应三个MCP Server。但查询销售数据就不应该做成Skill那个是工具层的功能直接由MCP提供就好。区分Skill和MCP工具的一条实用原则Skill里可以包含流程、判断和知识工具则只是孤立操作。如果某个能力需要先查A再根据A的结果决定要不要查B最后把结果组合成特定格式这就要做成Skill如果只是单纯的查一下那是工具。6.2 Skill包内部的结构长什么样一个标准的Skill包我习惯这样组织SKILL.md人类可读的能力说明包含触发条件、使用场景、执行步骤概览flow.md执行流程定义包含分支逻辑和异常处理路径tools.yaml依赖的MCP工具清单及调用顺序参考prompts/各环节使用的提示词模板按步骤命名examples/典型输入输出的示例其中SKILL.md是最关键的文件。它不光是给人看的文档实际上也会被模型读取。Skill的描述写得清晰程度直接决定了Agent识别它并正确调用的概率。我见过一个很糟糕的情况Skill能力明明存在但因为描述里没有写清触发场景Agent死活没有想起来用。后来我把每个Skill的描述都改成固定模板包含适用任务、前置条件、输出效果、不适用场景调用率提升非常明显。Skills还应该定义自己的退出条件。什么时候算干完了、结果该有哪些字段、需要交付给谁。没有退出条件的Skill往往会无限执行下去因为Agent不知道任务做到什么程度就算完成。6.3 Skills的版本控制和分发机制Skill一旦成为组织资产就必须有版本意识。我把Skill仓库独立成一个服务类似内部软件源有统一的仓库地址支持版本标记和依赖声明。Agent加载Skill时指定版本范围默认拉取满足要求的最新兼容版本。如果某个Skill行为有变化先在测试环境用历史版本跑回归再发布新版本并通知全体Agent做缓存刷新。代码层面Skill仓库可以直接用Git做版本控制release tag对应版本号再配一个简单的索引文件类似packages.jsonAgent每次启动时拉一次索引按需拉取具体Skill内容。这样既保证了加载速度也保证了更新的可达性。还有一点值得补充Skill的覆盖面监控。我会定期统计每个Skill被调用的次数、成功率和平均耗时。长期不用的Skill要审视是不是Agent根本不知道怎么触发或者触发条件写得有问题。调用失败率高的Skill则要复盘是不是流程定义有缺陷。这套运营机制保证Skill资产不是建完就完。7. 从单体到组织的最小落地路径7.1 先别急着推翻现有系统我见过不少团队一上来就想把全部Agent系统重构成多智能体大中台然后项目陷入泥潭半年出不了成果。理性的做法是渐进式改造。单体Agent先继续跑着核心链路在不影响主线的情况下把高频依赖的独立能力抽取出来做成第一个独立Agent或者MCP Server。等这个独立模块跑稳了再把第二个模块拆出来慢慢形成协作关系。这个过程的第一个里程碑不需要完全展开A2A协议的优势只要出现一次一个Agent搞不定、两个Agent配合就搞定了的场景就足以证明方向的价值。7.2 第一步先接好MCP如果系统目前什么都还没有第一步一定是先把MCP基础设施做好。因为MCP的收益最小但确定性最高把最后一公里工具连接标准化之后后续Agent的扩展才有基础。实操建议步骤盘点现有Agent会用到的所有外部系统列出优先级。优先为2~3个最高频系统开发MCP Server或接入现成的Server。在客户端Agent框架配置好MCP客户端连通性测试通过。定义好统一的工具命名和描述风格。跑几个典型案例验证工具调用的稳定性和准确率。7.3 第二步沉淀第一个SkillMCP通了之后选一个日常工作里最高频的流程把它沉淀成第一个Skill。不必追求通用只要能在自己的场景里稳定产出。关键在于让Skill被跑起来、被用起来。我建议从步骤超过3步、每周至少用一次的任务入手。实践过的流程才能真正暴露Skill设计里的缺陷哪个环节解释不清楚会导致Agent走偏、哪个工具调用顺序不合理容易超时、哪个输出格式下游消费不顺畅。这些坑没有真实业务跑一遍是发现不了的。7.4 第三步引入A2A做第一个协作场景基础设施齐了就可以选一个适合做协作验证的流程。建议选择拆分后每个子任务边界清晰的类型比如调研写作校对每个子任务都由不同Agent独立完成协作关系也只是简单的顺序传递复杂度可控。跑通之后重点关注调度准确率、任务交接成功率、超时重试的触发率。这三个指标落在预期范围内再考虑更复杂的编排逻辑条件分支、并行执行、多级汇总等。8. 常见问题与排查经验8.1 MCP工具调用报工具不存在怎么办这个问题的排查方向我一般按固定顺序来先确认MCP Server地址配置的是否正确分开网络地址和本地进程两种情况。再看工具列表是否成功拉到连接建立之后要能动态列出工具才说明协议握手成功。如果工具列表正常但调用报不存在检查是否拼写错误或者版本不一致导致的字段变更。最后确认权限网关是否放行。网关拦截会非常隐蔽坑人——工具在列表里能看到但真正调用时认证不过。8.2 Agent之间任务丢失、状态不同步多智能体系统里最常见的故障就是状态不一致。我遇到过的真实场景任务已经完成了但调用方还一直显示排队中最后调度层超时重试重复派单导致数据重复写入。排查要点先核对A2A协议的状态回调和状态推进是否每一步都落地了有没有哪一步漏发。再看异步消息是否存在丢失或乱序我遇到过连接重连之后消息重复消耗导致状态回拨的情况对幂等和去重处理要求比较高。最后注意流程收敛机制是否有全局统一的状态存储。重试的时候以数据库里的状态为准而不是以某个Agent的内存状态为准。8.3 Skill加载了但Agent表现跟没加载一样这是Skill体系里最有迷惑性的问题。表层是应该生效但没生效实际调查下来大多指向三个原因第一描述文件的触发条件写得不清晰Agent根本没有在决策时想到这个Skill。第二Skill里的工具清单跟当前Agent的MCP客户端配置不一致Skill要求调用某个工具但Agent连不上表现为技能执行失败然后被忽略。第三提示词模板写得又长又虚模型读了跟没读一样沿用自己的默认行为。我的排查顺序先看调用日志里有没有Skill被选中的记录没有就重点修描述有但执行失败就查工具连通性执行成功但输出不正常再打磨流程定义和提示词。8.4 调度Agent变成新的性能瓶颈分散了单体Agent的压力结果所有请求都汇聚到调度Agent那里它自己成了瓶颈。这是多智能体架构常见的反噬问题十分讽刺。实践中我用几个办法化解调度Agent不直接参与具体业务处理只做任务拆解和路由决策把算力留给推理。路由决策尽量用确定性规则优先规则覆盖不了的场景才动用大模型判断。调度逻辑做缓存相同任务模式的调度方案直接复用避免反复计算。8.5 常用排查命令与工具每个人的技术栈不一样但通用的排查方法可以分享一下MCP连接测试用标准客户端直接发起一次工具列表拉取看通信是否正常。A2A链路排查在路由表里查看各节点心跳和最近状态变化异常节点一目了然。Skill加载问题直接看Agent的会话日志里Skill选择记录和工具调用记录这两处的关联分析能定位大部分问题。我还会给所有Agent挂一个统一的可观测性面板展示每个Agent的活跃度、工具调用成功率、任务平均耗时和错误分布。多智能体系统比单体复杂一个数量级没有观测手段的排查会非常痛苦。9. 工具选型与生态现状观察9.1 MCP生态里值得关注的开源项目说实话MCP生态现在非常活跃但Fork多、精品少。我实际用下来值得关注的方向有这么几类官方参考实现方面MCP的Python SDK和TypeScript SDK目前最活跃新出的能力基本都优先支持。如果你要写正式项目优先用官方SDK不要用各种个人封装的第三方库。协议调试方面MCP Inspector是必装工具支持交互式地浏览和分析MCP Server的工具列表、资源列表、调用结果。我每次写好一个Server都会先用Inspector完整测一遍。连接器方面各主流应用数据库、浏览器、开发工具、办公套件的官方MCP Server陆续在出质量参差不齐。判断标准很简单看它维护频率和issue响应速度。社区热门的个人项目风险相对高生产环境选型要谨慎。9.2 A2A协议的成熟度盘点相比MCPA2A协议的落地状态更早期。规范本身已经有框架但跨框架的互操作还需要时间沉淀。目前比较好的实践分两类一类是完全自研Agent框架内部用自洽的A2A实现协作成熟度是够的另一类是不同开源框架之间的互通更多还在实验阶段。我的建议是如果全部Agent都是自己开发的就大胆引入A2A收益是实打实的如果指望不同公司的Agent系统互通现阶段还是要做适配层。9.3 Skills的获取与来源Skill生态目前比较分散不同框架各有各的Skill格式和使用方式。如果你需要找现成Skills可以按框架名Skills搜或者到Agent社区里找相关讨论。自制Skill更现实。我建议从自己的业务中最痛的流程开始用上文说的结构组织好跑通之后不断完善。自制的Skills一定是最了解自己业务的这也是核心竞争力所在。至于那些宣称包罗万象的30分钟造100个Skill的方案听听就好实际落地效果通常不会太理想。深度比数量重要太多。10. 架构演进的下一步思考多智能体架构用了大半年我最大的感受是技术选型不是最难的部分最难的是设计组织方式和协作契约。MCP、A2A、Skills三者搬起来容易但怎么在具体业务里裁剪、怎么定义好每个Agent的边界、怎么沉淀优质工作流这才是功夫所在。我个人在实际操作中的体会是从单体到组织心态上要从造一个神转变成带一支队伍。单体架构时期所有期待都押在模型能力上总想塞更多工具、更多上下文、更多规则。组织化之后重心转移到怎么让每个Agent把一件事做到极致怎么让它们之间配合顺畅怎么把优秀个体的能力复制给整个团队。想通这个转变之后MCP、A2A、Skills其实都是顺理成章的工具选择。如果你正在规划自己的多智能体系统我的建议很简单先把MCP基础设施打好沉淀一个核心Skill跑通一个协作场景。这三个节点做完你对这套架构的理解会超过大多数停留在PPT层面的人。再往后能走多远取决于你敢不敢把越来越核心的业务交给这个组织。