1. 四件套的定位谁在干活、谁在传话、谁在记账这两年做智能体开发最容易被绕晕的一件事就是概念太多。今天看到一个框架叫DeepAgents明天又冒出来MCP后天又有人聊A2A再往后还有Skills。每个单独拎出来都能找到教程但真正动起手来最大的困惑往往是这几个东西到底什么关系是不是重复了我到底该学哪个我最初也踩过这个坑。今天聊的这套“DeepAgents MCP A2A Skills”组合如果只看名字会觉得是四门课其实拆开看正好对应了智能体工程里四个完全不同层面的问题。先说结论后面逐层展开组件解决什么问题类比DeepAgents多智能体系统的编排与执行框架决定智能体怎么思考、怎么拆任务、怎么调度公司的管理层和项目流程MCP让智能体能调用外部工具、访问外部数据的统一协议所有电器通用的三孔插座A2A智能体与智能体之间互相发现、通信、协作的协议不同公司之间的外交公文Skills把一套固定的处理套路沉淀成可复用的文件包老员工的操作手册和SOP如果你只想做单个智能体不涉及外部工具那MCP可以不用如果你只做一个单体Agent不涉及多智能体协作那A2A可以暂时不碰但只要你做一个真正落地的智能体系统DeepAgents这种编排框架和Skills这套沉淀机制几乎跑不掉。为什么这么说核心原因在于单个大模型再聪明它也只有一次对话上下文一次只能做一件事但真实业务需求往往是“调研一下竞品 → 写一份分析报告 → 转成PPT大纲 → 生成配图素材 → 统稿发布”这种链路不是一次推理能完成的。你需要一个框架把大任务拆成小任务你需要协议让各个环节能调用外部能力你需要一套机制让下一次做类似任务时不用从头教。这套书的理论基础是“把智能体当作一个可以组合的系统而不是一个孤立的聊天窗口”。下面我逐个拆解重点讲清楚每个组件的底层机制和它们之间的衔接关系。2. MCP与A2A的分工边界一个管工具一个管协作2.1 一个请求从用户到外部系统的完整路径先说MCP也就是Model Context Protocol。它是Anthropic在2024年底开源的一套协议目的非常纯粹统一大模型调用外部工具的方式。如果没有MCP你想让智能体查数据库就要写一段数据库查询代码想让它调Figma就要写一套Figma API封装每个工具一套对接方式开发量巨大而且换一个模型可能就要重写一遍。有了MCP之后所有工具都通过同一个协议暴露出来——MCP Server提供工具MCP Client连接Server模型通过标准接口发现工具、调用工具、接收结果。举个最简单的例子我做一个企业采购助手需要对接ERP系统查库存。传统做法是写一个Python函数调用ERP接口然后把函数描述写进System Prompt里告诉模型“你可以用这个函数”。这种做法的痛点是每次换供应商的系统就要重新写一遍对接而且模型对工具描述的理解高度依赖Prompt写得是否详细。而用MCP之后ERP系统只需要实现一个MCP Server暴露一个query_inventory工具智能体通过MCP客户端自动发现这个工具、自动读取工具的参数Schema、按需发起调用。标准化的意义在于任何一个支持MCP的智能体框架接入之后都能直接使用这个工具不需要针对每个模型定制适配。再来看A2A——Agent-to-Agent协议这是Google在2025年4月推出的智能体通信协议。它解决的是另一个层面的问题假设你有一个智能体负责写文案另一个智能体负责做图这两个智能体可能是不同团队、不同框架开发的一个基于DeepAgents另一个是微服务封装的老系统它们之间怎么协作A2A定义了智能体的能力声明方式、任务创建与状态查询机制、消息传递格式让智能体之间可以像人和人之间发邮件、发公文一样协作。为了更好地理解两者的关系我通常会给学员画这样一条路径用户给主智能体下了一个指令主智能体通过A2A协议向另一个子智能体发起协作请求子智能体在执行自己的任务时通过MCP协议调用真实世界的工具查数据库、调API、访问文件等子智能体把执行结果通过A2A协议回传给主智能体。所以MCP管的是“智能体如何连接世界”A2A管的是“智能体之间如何连接彼此”。一个是纵向的工具接入一个是横向的智能体协作两者不冲突反而天然互补。2.2 A2A协议1.0版本与0.3版本的重要差异A2A协议从0.3迭代到1.0最核心的变化有几个我结合自己实际接入的经验整理如下Agent Card智能体卡片的结构大幅升级。0.3版本里Agent Card只是一份简单的JSON-LD描述文件记录智能体名称、描述、URL、能力列表主要作用就是让其他智能体通过/.well-known/agent.json发现你。到了1.0版本Agent Card变成了一个更完整的机器可读档案里面不仅有基本信息还明确区分了capabilities的结构化声明增加了对流式响应streaming、多轮任务中断恢复interruption、**结构化任务状态机task state machine**的支持说明并且对认证方式authentication字段的规范性做了大幅增强不再让智能体自己去猜对方要用哪种认证。任务状态机更严格。A2A的核心操作是创建一个task而任务是异步的双方需要协商状态流转。0.3版本的状态定义比较松散智能体之间的状态同步经常出现歧义。1.0版本把状态机定义得更加严格从submitted到working再到input-required或completed每一步的流转条件和可允许的操作都做了明确约束。投入生产的一些硬性要求补齐了。1.0版本加入了一个非常现实的东西成本与配额信息cost and rate limits可以让调用方提前知道调用这个智能体要花多少钱、有多大的并发限制。这意味着A2A协议开始面向商业化落地而不仅是一个学术实验协议。我自己在项目里遇到的一个典型问题是0.3版本里服务端向客户端返回任务状态时headers的传递方式没有统一标准导致用不同语言实现的A2A客户端对接时会遇到莫名奇妙的兼容问题——A说状态已经更新了B却因为事件订阅的推送通道没打通一直以为任务还在排队。1.0版本在这个位置花了大力气统一了消息信封结构和事件推送机制。如果你是从0.3版本升级过来的一定要重点检查Agent Card中protocolVersion字段并确认两边的版本号一致否则握手阶段就会直接失败。2.3 MCP协议的两个容易误解的点MCP本身不算复杂但有两个地方我见过太多人理解偏差。第一个误区MCP只能用来暴露API工具。其实MCP的原语Primitive有三类tools工具、resources可读资源、prompts提示词模板。也就是说MCP不仅能暴露可执行函数还能暴露一份文档、一个数据库视图、一段标准Prompt模板。我在实际项目中经常用resources来暴露企业内部的业务术语表让智能体在回答前先读取一份“知识库”而不是把所有知识都塞进工具调用结果里。第二个误区MCP Server只能部署在本机。很多人以为MCP Server是给本地文件用的其实MCP在设计上支持远程服务端通过streamable HTTP或WebSocket进行通信。只是目前主流框架对远程MCP的支持还有不少坑比如鉴权方式不统一、超时重试策略不一致。我的建议是优先用本地进程内的MCP Server等系统规模真正需要微服务化的时候再考虑把Server抽出来独立部署。3. DeepAgents的多智能体编排从主管到一线的完整干活逻辑3.1 DeepAgents的架构核心Harness机制与Agent的循环在拆解DeepAgents之前先理清一个词——Harness。在这一轮多智能体热词里大量出现了“大模型 Skills Harness 深入理解”“基于Harness架构的多智能体企业采购助手”这类表述。简单说Harness是“给模型套上的一整套控制逻辑”它负责管理模型的思考循环观察当前状态 → 决定下一步动作 → 执行动作 → 观察结果 → 再决定下一步。原始的大模型API只有一次性的input → output而Harness把它变成了一套带反馈闭环的循环系统。主流的多智能体框架包括DeepAgents类框架和AgentsScope 2.0、Data Science Helper这类工具都大同小异核心都是Harness 工具注册 多智能体路由。区别在于调度策略、记忆管理方式和可观测性。DeepAgents的价值在于它把“深度任务分解”和“多智能体协同”做成了显式的一等公民而不是模型自己即兴发挥。一个典型的DeepAgents多智能体系统结构大概是这样的主管智能体Supervisor/Planner接收用户需求做任务拆解决定要调用哪些子智能体分发子任务执行智能体Worker/Executor实际干活的智能体可能是一个读文档的、一个写代码的、一个做数据分析的、一个做PPT的质检智能体Reviewer/Reflector对执行结果做检查、提出修改意见如果不过关就打回重做记忆与上下文管理器确保任务在执行过程中上下文不丢失。这种结构不是拍脑袋想出来的。它的优势正好对应多智能体系统要解决的三个核心问题上下文窗口有限。一个Agent处理不了特别长的任务拆给多个Agent各自负责一段它们的上下文彼此独立不会互相污染职责隔离。不同任务角色可以用不同的模型、不同的温度参数、不同的工具集。比如写代码的Agent可以用推理能力更强的模型做排版设计的Agent可以用多模态模型这样整个系统的性价比更高可观测可干预。如果一个Agent出了问题其他Agent不受影响。这个在单体Agent里几乎不可能实现。3.2 主管智能体是如何拆任务的任务拆解是DeepAgents最容易“看起来不错、实际很弱”的环节。很多初学者以为只要在Prompt里写一句“你是一个任务规划专家请把任务拆解成多个子任务”就可以了。但真实生产中模型给出的拆解结果往往有两个典型毛病第一拆解粒度不稳定。今天拆出来5个子任务明天同一个需求可能拆出9个后天可能拆成3个每个子任务的描述水平参差不齐。这个问题的根源在于模型没有“约束性结构化”的提示。我的做法是给主管智能体一个固定的JSON Schema输出模板要求它严格按照Schema填写task_id、task_type、task_desc、dependencies、assigned_agent、success_criteria这几个字段。Schema约束比任何Prompt都要稳定。第二拆解结果不考虑子智能体的实际能力边界。主管Agent只凭描述文字做判断不会验证子Agent是否真有对应的工具或数据权限。这也是为什么很多系统需要加一个“能力注册表”——每个子智能体在上线时要把它的能力、可用工具、数据范围、权限等级登记到一张表里。主管智能体在拆任务时先查注册表再做分配而不是纯粹靠模型“猜”。这一步听起来很工程化却是把多智能体系统从Demo推向生产环境的关键一步。3.3 智能体之间到底怎么“对话”很多人会问多个Agent之间是怎么协作的是直接把长文本互相传来传去吗其实在DeepAgents框架里子智能体之间通常不是直接对话而是通过一条“消息总线”交换结构化任务。也就是说主管把任务写成JSON消息发给某个子智能体子智能体完成后把结果同样以JSON格式写回。但这里有一个现实问题如果所有Agent都在一个进程里用内部函数调用就够了完全不需要走网络协议但如果Agent跨服务部署就需要一个通信协议把“任务”这个概念标准化——这正是A2A协议发挥作用的地方。结合A2A来设计多智能体协作通常有两种方式紧耦合调用同进程内Router模式主管直接通过内存函数调子Agent。优点是开销极低适合所有Agent都是同一技术栈、部署在同一个服务里的场景。缺点是扩展性差一旦Agent数量超过几十个进程内的消息协调会变得难以维护。松耦合调用A2A远程协议模式主管通过A2A协议向远程子Agent发起任务请求。优点是可以跨语言、跨框架、跨团队协作每个智能体都可以独立升级、独立扩容。缺点是多了一次网络开销任务状态同步和错误处理都要自己设计。我自己的经验是初期用紧耦合模式跑通业务逻辑等真的需要把某个智能体独立出去的时候再包一层A2A接口。不要一开始就把所有Agent都做成远程服务否则调试一次链路要开七八个终端非常痛苦。3.4 实战企业采购助手的Harness设计热词里多次出现了“基于Harness架构的多智能体企业采购助手”这个案例非常典型我展开讲讲它是怎么把上面这些机制串起来的。一个采购助手的典型需求是“帮我找5家符合A类资质要求的供应商对比它们的报价生成一份采购建议报告。”这个需求看起来简单实际拆解下来要涉及供应商库查询、资质文件核验、报价单解析、历史合作记录分析、价格对比计算、报告生成六个步骤。如果不用多智能体而是让一个Agent从头做到尾最大的麻烦是每一步涉及的上下文类型完全不同。查供应商库需要读结构化字段资质核验需要看扫描件PDF分析历史合作记录需要跑数据统计生成报告又要调用文档模板。这些操作塞进同一个Agent的上下文会严重挤占窗口空间可能导致Agent在最后一步生成报告时“忘记”前面的关键信息。用DeepAgents的思路怎么做主管智能体接收用户需求拆出6个子任务并按依赖关系排好序调用“供应商检索Agent”它通过MCP协议连接CRM系统的MCP Server执行query_supplier工具返回候选列表调用“资质审核Agent”它通过MCP协议连接文档解析服务逐个解析PDF文件并生成资质核验结果调用“分析Agent”对候选供应商的报价和历史数据进行统计分析调用“报告Agent”使用采购报告Skills生成最终文档。在这个链路里MCP解决了“怎么拿到数据和文件”A2A解决了“Agent之间怎么申请任务和回传结果”Skills解决了“报告格式怎么保证每次都合标”DeepAgents则是承载这一切的编排框架。4. Skills技能库构建把“这次会了”变成“以后都会”4.1 Skills和MCP到底有什么区别热词里有很多人在搜“Agent Skill 和MCP有什么区别”这确实是最容易混淆的一点。我给一个最简明的区分MCP解决的是“智能体没有的手怎么借过来”的问题——借力的标准化协议Skills解决的是“智能体会做但做得不稳定的活怎么固定下来”的问题——经验的标准化沉淀。举一个前端开发的例子。假设你经常让智能体帮你做网页改版需要一个“Figma设计稿转代码”的技能。如果用MCP你接一个Figma MCP Server智能体就能通过API读取Figma设计稿的文件信息和图层结构——这是“借到了读设计稿的手”。但读完设计稿之后怎么把设计稿的布局、颜色、字体转换为Tailwind CSS代码这是MCP解决不了的它只负责把设计稿数据拿回来。真正让智能体“每次都能产出风格统一的代码”的是一个写好的Skills文件包里面定义了转换规则、组件库映射表、代码输出格式、常见问题的处理策略。Skills的本质是**“夹在模型和Prompt之间的第二层大脑”**。它不像System Prompt那样每次都要占用大量上下文而是按需加载——只有当任务命中某个技能时系统才把对应的Skill文件注入上下文。这种设计大幅节省了Context开销也改善了响应质量。以OpenAI Codex和Claude Code为代表的编码工具中Skills机制在2025年被大量采用。简单来说一个Skill通常包含SKILL.md技能说明文件告诉系统这个技能是什么、适用于什么场景包括触发条件、使用步骤、注意事项参考脚本或模板可执行的脚本、示例代码、常用配置片段元数据技能的名称、版本、作者、依赖条件。4.2 从零编写一个“数据分析报告Skills”的具体步骤我建议每个做智能体的人都从写一个自己能反复用到的Skill开始练习。下面用一个“电商周报自动生成”的Skill作为案例拆解完整步骤。第一步定义技能的适用范围和触发条件。在SKILL.md开头就明确--- name: ecommerce_weekly_report description: 根据电商平台的订单数据、流量数据、客服数据生成周报。 适用的数据源MySQL数据库中的 orders 表、traffic_log 表、service_records 表。 当用户请求中包含周报周复盘销售分析等关键词且要求分析时间段为一周时优先使用本技能。 version: 1.0.0 ---这里的核心是触发条件要写得足够具体否则智能体可能在不该用的时候用了或者该用的时候没用。触发条件写得越精确技能的命中率越高。第二步编写详细的执行步骤。Skill和普通Prompt最大的区别是Prompt给出的是一段描述性的要求而Skill给出的是一套可执行的流程。比如从MySQL中读取订单数据按日汇总GMV、订单量、客单价读取流量数据计算UV、转化率、广告花费读取客服数据统计客诉量和主要问题分类将三部分数据合并计算环比和同比变化率按固定模板输出周报Markdown文档包含数据概览、趋势图、异常预警、下周行动建议四部分如果发现数据异常如GMV环比下降超过15%自动调用data_anomaly_analyzer工具进行分析。第三步附上可复用的代码模板。这一步决定了Skill的“工程含量”。把查询SQL、数据处理脚本、图表生成代码都放进Skill目录里智能体在执行时可以直接读取这些文件而不需要自己从零写代码。ecommerce_weekly_report/ ├── SKILL.md ├── scripts/ │ ├── fetch_order_data.sql │ ├── calculate_metrics.py │ └── generate_charts.py ├── templates/ │ └── weekly_report_template.md └── examples/ └── sample_output.md第四步提供高质量的示例输出。这一点很多人忽略但它是让模型快速学会格式的最有效方式。在examples里放一份标准的周报示例相当于告诉模型“照着这个格式来”。对于新读者而言一个成功的Skill案例不仅有文字流程还有别人做好的输出样例可以临摹。4.3 Skills的触发与维护超出预期的那些坑在实际运行中Skill最容易翻车的地方是**“写好了却永不触发”**。常见的原因有三个一是description写得太模糊。比如你写“数据周报生成Skill”并且期望模型自动判断何时使用模型很难判断“什么时候该用”。更稳妥的做法是同时维护一个“路由规则文件”——在系统Prompt里显式写清楚当用户请求中包含“周报”且时间范围是近7天时必须加载ecommerce_weekly_report技能。这个思路跟人类的项目管理其实很相似新增一个技能就像把一个新同事引入团队光发一份简历不够还需要告诉团队主管“什么情况应该找这个同事”。二是Skill文件太长加载后占据了大量上下文窗口。如果一份Skill超过3000个token模型在这种压力下的表现会明显下降。建议把Skill拆为“快速启动版”和“完整版”两个版本。快速启动版只包含核心指令完整版在需要时再通过读取文件的方式加载。三是Skills版本管理混乱。同一个技能改了三四版之后老的代码模板还残留在目录里模型可能随机加载到旧版本。建议明确规定每个Skill目录中只保留当前版本的有效文件历史版本统一放在archive/子目录下并加上版本号。5. 全流程实战从用户需求到多智能体交付的完整链路5.1 一个可复用参考的实战目标下面用一套“多智能体内容生产流水线”串联全文。RSS订阅助手负责追踪技术博客更新内容分析Agent负责摘要提炼和选题挖掘写作Agent负责生成初稿编辑Agent负责校验优化最后通过发布Agent推送到微信公众号后台。这个流水线可以直接迁移到“商品评论分析”“竞品监控”“数据分析报告生成”等场景。这套系统和热词里提到的“Inkos多智能体网文创作流水线架构解析”以及“多智能体企业采购助手”在架构思路上完全一致有主管做调度有专门的Worker干细活有质检环节做质量把关再用Skills固定每个环节的产出风格。5.2 主管智能体的任务拆解Workflow在整个流程启动时主管智能体会收到用户的原始需求。它要做的事情是把用户需求标准化成一个任务对象包含goal、constraints、deadline、requirements等字段查询能力注册表确认所需的子智能体是否在线、是否有权限把任务拆分为多个子任务为每个子任务指定负责人、输入和输出标准按依赖关系建好任务队列递交给执行层。这里有一个实战环节值得重点说说如何写好一个让子智能体不会有歧义的任务指令。我通常要求任务描述包含五要素背景为什么做这件事输入数据源在哪里、以什么格式提供输出最终交付物是什么、格式长什么样边界什么不能做、什么要拒绝验收标准怎么判断做得好不好。很多失败的多智能体项目问题不是模型能力不行而是任务描述含糊不清子智能体只能靠猜。5.3 子智能体通过MCP调用外部数据内容生产流水线里最依赖MCP的是数据接入环节。RSS订阅助手本身就是一个MCP Server暴露fetch_article、list_sources、mark_read等工具。内容分析Agent通过MCP客户端连接这个Server定期拉取文章列表和正文。整套对接对模型是透明的模型只需要知道自己有一个工具可以“拉取技术博客最新文章”系统会在调用时自动把MCP Server返回的数据转换成模型能读懂的文本。这里有个很实用的经验MCP工具的“描述”决定成败。MCP Server暴露的每个工具它的description字段会直接影响模型的调用准确率。比如你把工具描述写成“获取文章列表”模型可能只会在“需要文章列表”时调用但如果你写成“获取当前订阅的所有技术博客的最新文章列表支持按标签过滤和按时间范围过滤用于内容分析和热点追踪”模型就能更准确地决定在什么时候使用、传入什么参数。工具描述写得越具体Agent的调度效果越好。5.4 子智能体之间通过A2A协作在内容生产流水线中写作Agent和编辑Agent往往是由不同的团队维护的甚至可能是不同框架开发的。写作Agent基于DeepAgents框架编辑Agent可能就是一个独立的LangGraph服务。这种情况下让它们直接共享内部上下文是不现实的最合适的方式就是走A2A协议。具体过程是写作Agent完成初稿后通过A2A协议向编辑Agent发起一个新的任务任务内容包括“初稿Markdown文本、目标公众号排版风格、需要检查的维度清单”。编辑Agent收到任务后进行错别字检查、逻辑连贯性检查、格式规范检查然后把修改意见或修改后的版本通过A2A协议返回。注意这里和我们在MCP里讲的“工具调用”不同——写作Agent不是在“调一个编辑工具”而是真的在“给另一个独立的智能体安排任务”。这个区别很重要如果编辑Agent本身就是一个完整的多智能体系统有自己的外部工具和内部调度逻辑那么A2A的松耦合模型会带来非常大的灵活性。5.5 用Skills把任务经验固化下来流水线跑完几轮后你会发现一个明显的现象每次生成周报或者初稿时模型产出的风格和结构都会有细微的波动。例如编辑Agent第一次改语病改得很勤快第五次可能就只改了错别字其他问题都放过去了。这不是模型在“偷懒”而是Prompt对细节的约束能力存在上限。解决方式就是前面说的Skills。把编辑Agent的“编辑规范”整理成一个editor_checklist技能里面包含错别字检查清单、敏感词过滤规则、公众号排版格式模板、标题优化策略。每次编辑Agent启动时系统按需加载这个技能产出的质量稳定性会好很多。我自己跑通这套流水线之后最大的感受是多智能体系统的上限由框架决定下限由Skills决定。框架保证任务能拆得开、分得下去、结果收得回来Skills保证每个环节的产出风格稳定、不发挥失常。两者缺一不可。6. 跑通闭环后避坑三个翻车现场的排查链路6.1 症状一子智能体“假装调用”了MCP工具这是一个比较隐蔽的问题。用MCP之后模型有时会在生成内容里“说”自己调用了某个工具但实际上并没有真正发起MCP请求。比如分析Agent的回复里写了“已从数据库获取订单数据”但数据库的访问日志里根本没有对应记录。这种情况常被称作“工具幻觉”或“半接通”。排查链路如下先确认MCP Server的工具是否成功注册到了Agent的可用工具列表里。方法是在调试界面打印Agent当前的工具列表如果看不到目标工具说明MCP Client的注册逻辑有问题确认工具描述是否足够具体。如果描述太模糊模型可能会“以为”自己已经具备了某个能力而忽略了调用工具这个动作。解决办法是把工具描述写得更准确并加上“必须调用工具来获取最新数据不得编造”的指令确认系统内部有没有对“调用结果”做校验。我通常会在框架里加一个拦截器如果Agent的输出中包含了“已调用工具”之类的声明但实际没有对应的工具调用记录就抛出一个警告并强制Agent重新执行工具调用。这个问题一旦出现排查成本很高所以更推荐用“先验证工具链路再跑业务”的方式避免。每次新增MCP Server第一件事不是跑业务而是发一条“请调用工具查询当前状态”的测试指令确认工具链路完全打通后再开展后续开发。6.2 症状二A2A协议0.3与1.0版本握手失败如果你的A2A客户端和服务端版本不一致最常见的报错是握手阶段返回protocolVersion不匹配。这个问题看起来很好解决——升级版本就行但实际中有不少麻烦老的服务端Agent可能只实现了0.3版本升级需要动到整个部署而你的客户端已经用了1.0版本的SDK两边的消息信封结构和状态机定义差异很大。我的处理建议是在A2A的服务端做协议版本协商先把两端支持的版本列表读出来如果有交集就用最高公共版本没有交集就直接断开并返回错误码。这相当于在握手时加了一个版本兼容判断层。在网关层记录每次A2A握手的协议版本并监控版本分布。这样你能知道生产环境里还有多少旧版本客户端在跑方便排期升级。如果确实无法同步升级建议在内部加一套“协议转换适配器”将0.3版本的请求转换成1.0版本再转发给新服务端。但尽量不要长期依赖这种适配层它会让排查问题的成本变得很高。6.3 症状三Skills写好了却不命中这是最有挫败感的问题明明把技能文件写得很详细模型却总是“视而不见”该用技能的时候还是按通用能力硬答。排查链路如下检查SKILL.md的description是否包含足够的触发关键词。如果你期望“周报生成”场景命中description里最好明确写上“周报”“周复盘”“销售分析报告”等词检查技能加载机制。如果框架是“按关键词匹配加载”那关键词设计就很关键如果是“由模型自己决定加载”那description要写成第三人称的客观描述而不是第一人称“我能做什么”做一个对照测试先不加载技能跑一次业务再加载技能跑一次业务对比输出质量。如果差异很小说明技能内容本身没有提供足够的增量信息需要反思技能里写的内容是不是模型本来就会的。Skill的价值必须体现在“模型不会或者做不好的地方”。6.4 排查清单汇总现象可能原因首选检查项Agent回复“已调用工具”但实际未调用工具描述不精确 / 注册链路中断 / 缺少调用结果校验打印工具列表与调用日志A2A通信失败版本不一致 / 认证方式不匹配 / Agent Card地址错误检查protocolVersion与握手日志Skills不触发命中关键词缺失 / description质量差 / 技能无增量信息对照测试有技能与无技能的差异子Agent任务执行结果与预期偏差大任务描述五要素缺失 / 能力注册表过期审查任务描述中的边界与验收标准排查问题的原则很统一先确认链路是通的再去调模型行为。链路不通调多少次Prompt都没用。从我个人的实战体会来说这套“DeepAgents MCP A2A Skills”的组合最大的价值不在于某个单独技术有多新而在于它把智能体开发从“写Prompt”推进到了“设计系统”的阶段。以前我们关心的是“怎么让模型答对”现在关心的是“怎么搭一个体系让它稳定产出”。如果你刚开始接触建议别急着追求大而全先做一个最小闭环一个Agent、一个MCP Server、一个Skill跑通之后再往上加第二个Agent、加A2A通信。这个顺序能让你在每一步都知道问题出在哪个层面也便于积累排查经验。 DeepAgents、MCP、A2A与Skills：智能体四件套实战指南
1. 四件套的定位谁在干活、谁在传话、谁在记账这两年做智能体开发最容易被绕晕的一件事就是概念太多。今天看到一个框架叫DeepAgents明天又冒出来MCP后天又有人聊A2A再往后还有Skills。每个单独拎出来都能找到教程但真正动起手来最大的困惑往往是这几个东西到底什么关系是不是重复了我到底该学哪个我最初也踩过这个坑。今天聊的这套“DeepAgents MCP A2A Skills”组合如果只看名字会觉得是四门课其实拆开看正好对应了智能体工程里四个完全不同层面的问题。先说结论后面逐层展开组件解决什么问题类比DeepAgents多智能体系统的编排与执行框架决定智能体怎么思考、怎么拆任务、怎么调度公司的管理层和项目流程MCP让智能体能调用外部工具、访问外部数据的统一协议所有电器通用的三孔插座A2A智能体与智能体之间互相发现、通信、协作的协议不同公司之间的外交公文Skills把一套固定的处理套路沉淀成可复用的文件包老员工的操作手册和SOP如果你只想做单个智能体不涉及外部工具那MCP可以不用如果你只做一个单体Agent不涉及多智能体协作那A2A可以暂时不碰但只要你做一个真正落地的智能体系统DeepAgents这种编排框架和Skills这套沉淀机制几乎跑不掉。为什么这么说核心原因在于单个大模型再聪明它也只有一次对话上下文一次只能做一件事但真实业务需求往往是“调研一下竞品 → 写一份分析报告 → 转成PPT大纲 → 生成配图素材 → 统稿发布”这种链路不是一次推理能完成的。你需要一个框架把大任务拆成小任务你需要协议让各个环节能调用外部能力你需要一套机制让下一次做类似任务时不用从头教。这套书的理论基础是“把智能体当作一个可以组合的系统而不是一个孤立的聊天窗口”。下面我逐个拆解重点讲清楚每个组件的底层机制和它们之间的衔接关系。2. MCP与A2A的分工边界一个管工具一个管协作2.1 一个请求从用户到外部系统的完整路径先说MCP也就是Model Context Protocol。它是Anthropic在2024年底开源的一套协议目的非常纯粹统一大模型调用外部工具的方式。如果没有MCP你想让智能体查数据库就要写一段数据库查询代码想让它调Figma就要写一套Figma API封装每个工具一套对接方式开发量巨大而且换一个模型可能就要重写一遍。有了MCP之后所有工具都通过同一个协议暴露出来——MCP Server提供工具MCP Client连接Server模型通过标准接口发现工具、调用工具、接收结果。举个最简单的例子我做一个企业采购助手需要对接ERP系统查库存。传统做法是写一个Python函数调用ERP接口然后把函数描述写进System Prompt里告诉模型“你可以用这个函数”。这种做法的痛点是每次换供应商的系统就要重新写一遍对接而且模型对工具描述的理解高度依赖Prompt写得是否详细。而用MCP之后ERP系统只需要实现一个MCP Server暴露一个query_inventory工具智能体通过MCP客户端自动发现这个工具、自动读取工具的参数Schema、按需发起调用。标准化的意义在于任何一个支持MCP的智能体框架接入之后都能直接使用这个工具不需要针对每个模型定制适配。再来看A2A——Agent-to-Agent协议这是Google在2025年4月推出的智能体通信协议。它解决的是另一个层面的问题假设你有一个智能体负责写文案另一个智能体负责做图这两个智能体可能是不同团队、不同框架开发的一个基于DeepAgents另一个是微服务封装的老系统它们之间怎么协作A2A定义了智能体的能力声明方式、任务创建与状态查询机制、消息传递格式让智能体之间可以像人和人之间发邮件、发公文一样协作。为了更好地理解两者的关系我通常会给学员画这样一条路径用户给主智能体下了一个指令主智能体通过A2A协议向另一个子智能体发起协作请求子智能体在执行自己的任务时通过MCP协议调用真实世界的工具查数据库、调API、访问文件等子智能体把执行结果通过A2A协议回传给主智能体。所以MCP管的是“智能体如何连接世界”A2A管的是“智能体之间如何连接彼此”。一个是纵向的工具接入一个是横向的智能体协作两者不冲突反而天然互补。2.2 A2A协议1.0版本与0.3版本的重要差异A2A协议从0.3迭代到1.0最核心的变化有几个我结合自己实际接入的经验整理如下Agent Card智能体卡片的结构大幅升级。0.3版本里Agent Card只是一份简单的JSON-LD描述文件记录智能体名称、描述、URL、能力列表主要作用就是让其他智能体通过/.well-known/agent.json发现你。到了1.0版本Agent Card变成了一个更完整的机器可读档案里面不仅有基本信息还明确区分了capabilities的结构化声明增加了对流式响应streaming、多轮任务中断恢复interruption、**结构化任务状态机task state machine**的支持说明并且对认证方式authentication字段的规范性做了大幅增强不再让智能体自己去猜对方要用哪种认证。任务状态机更严格。A2A的核心操作是创建一个task而任务是异步的双方需要协商状态流转。0.3版本的状态定义比较松散智能体之间的状态同步经常出现歧义。1.0版本把状态机定义得更加严格从submitted到working再到input-required或completed每一步的流转条件和可允许的操作都做了明确约束。投入生产的一些硬性要求补齐了。1.0版本加入了一个非常现实的东西成本与配额信息cost and rate limits可以让调用方提前知道调用这个智能体要花多少钱、有多大的并发限制。这意味着A2A协议开始面向商业化落地而不仅是一个学术实验协议。我自己在项目里遇到的一个典型问题是0.3版本里服务端向客户端返回任务状态时headers的传递方式没有统一标准导致用不同语言实现的A2A客户端对接时会遇到莫名奇妙的兼容问题——A说状态已经更新了B却因为事件订阅的推送通道没打通一直以为任务还在排队。1.0版本在这个位置花了大力气统一了消息信封结构和事件推送机制。如果你是从0.3版本升级过来的一定要重点检查Agent Card中protocolVersion字段并确认两边的版本号一致否则握手阶段就会直接失败。2.3 MCP协议的两个容易误解的点MCP本身不算复杂但有两个地方我见过太多人理解偏差。第一个误区MCP只能用来暴露API工具。其实MCP的原语Primitive有三类tools工具、resources可读资源、prompts提示词模板。也就是说MCP不仅能暴露可执行函数还能暴露一份文档、一个数据库视图、一段标准Prompt模板。我在实际项目中经常用resources来暴露企业内部的业务术语表让智能体在回答前先读取一份“知识库”而不是把所有知识都塞进工具调用结果里。第二个误区MCP Server只能部署在本机。很多人以为MCP Server是给本地文件用的其实MCP在设计上支持远程服务端通过streamable HTTP或WebSocket进行通信。只是目前主流框架对远程MCP的支持还有不少坑比如鉴权方式不统一、超时重试策略不一致。我的建议是优先用本地进程内的MCP Server等系统规模真正需要微服务化的时候再考虑把Server抽出来独立部署。3. DeepAgents的多智能体编排从主管到一线的完整干活逻辑3.1 DeepAgents的架构核心Harness机制与Agent的循环在拆解DeepAgents之前先理清一个词——Harness。在这一轮多智能体热词里大量出现了“大模型 Skills Harness 深入理解”“基于Harness架构的多智能体企业采购助手”这类表述。简单说Harness是“给模型套上的一整套控制逻辑”它负责管理模型的思考循环观察当前状态 → 决定下一步动作 → 执行动作 → 观察结果 → 再决定下一步。原始的大模型API只有一次性的input → output而Harness把它变成了一套带反馈闭环的循环系统。主流的多智能体框架包括DeepAgents类框架和AgentsScope 2.0、Data Science Helper这类工具都大同小异核心都是Harness 工具注册 多智能体路由。区别在于调度策略、记忆管理方式和可观测性。DeepAgents的价值在于它把“深度任务分解”和“多智能体协同”做成了显式的一等公民而不是模型自己即兴发挥。一个典型的DeepAgents多智能体系统结构大概是这样的主管智能体Supervisor/Planner接收用户需求做任务拆解决定要调用哪些子智能体分发子任务执行智能体Worker/Executor实际干活的智能体可能是一个读文档的、一个写代码的、一个做数据分析的、一个做PPT的质检智能体Reviewer/Reflector对执行结果做检查、提出修改意见如果不过关就打回重做记忆与上下文管理器确保任务在执行过程中上下文不丢失。这种结构不是拍脑袋想出来的。它的优势正好对应多智能体系统要解决的三个核心问题上下文窗口有限。一个Agent处理不了特别长的任务拆给多个Agent各自负责一段它们的上下文彼此独立不会互相污染职责隔离。不同任务角色可以用不同的模型、不同的温度参数、不同的工具集。比如写代码的Agent可以用推理能力更强的模型做排版设计的Agent可以用多模态模型这样整个系统的性价比更高可观测可干预。如果一个Agent出了问题其他Agent不受影响。这个在单体Agent里几乎不可能实现。3.2 主管智能体是如何拆任务的任务拆解是DeepAgents最容易“看起来不错、实际很弱”的环节。很多初学者以为只要在Prompt里写一句“你是一个任务规划专家请把任务拆解成多个子任务”就可以了。但真实生产中模型给出的拆解结果往往有两个典型毛病第一拆解粒度不稳定。今天拆出来5个子任务明天同一个需求可能拆出9个后天可能拆成3个每个子任务的描述水平参差不齐。这个问题的根源在于模型没有“约束性结构化”的提示。我的做法是给主管智能体一个固定的JSON Schema输出模板要求它严格按照Schema填写task_id、task_type、task_desc、dependencies、assigned_agent、success_criteria这几个字段。Schema约束比任何Prompt都要稳定。第二拆解结果不考虑子智能体的实际能力边界。主管Agent只凭描述文字做判断不会验证子Agent是否真有对应的工具或数据权限。这也是为什么很多系统需要加一个“能力注册表”——每个子智能体在上线时要把它的能力、可用工具、数据范围、权限等级登记到一张表里。主管智能体在拆任务时先查注册表再做分配而不是纯粹靠模型“猜”。这一步听起来很工程化却是把多智能体系统从Demo推向生产环境的关键一步。3.3 智能体之间到底怎么“对话”很多人会问多个Agent之间是怎么协作的是直接把长文本互相传来传去吗其实在DeepAgents框架里子智能体之间通常不是直接对话而是通过一条“消息总线”交换结构化任务。也就是说主管把任务写成JSON消息发给某个子智能体子智能体完成后把结果同样以JSON格式写回。但这里有一个现实问题如果所有Agent都在一个进程里用内部函数调用就够了完全不需要走网络协议但如果Agent跨服务部署就需要一个通信协议把“任务”这个概念标准化——这正是A2A协议发挥作用的地方。结合A2A来设计多智能体协作通常有两种方式紧耦合调用同进程内Router模式主管直接通过内存函数调子Agent。优点是开销极低适合所有Agent都是同一技术栈、部署在同一个服务里的场景。缺点是扩展性差一旦Agent数量超过几十个进程内的消息协调会变得难以维护。松耦合调用A2A远程协议模式主管通过A2A协议向远程子Agent发起任务请求。优点是可以跨语言、跨框架、跨团队协作每个智能体都可以独立升级、独立扩容。缺点是多了一次网络开销任务状态同步和错误处理都要自己设计。我自己的经验是初期用紧耦合模式跑通业务逻辑等真的需要把某个智能体独立出去的时候再包一层A2A接口。不要一开始就把所有Agent都做成远程服务否则调试一次链路要开七八个终端非常痛苦。3.4 实战企业采购助手的Harness设计热词里多次出现了“基于Harness架构的多智能体企业采购助手”这个案例非常典型我展开讲讲它是怎么把上面这些机制串起来的。一个采购助手的典型需求是“帮我找5家符合A类资质要求的供应商对比它们的报价生成一份采购建议报告。”这个需求看起来简单实际拆解下来要涉及供应商库查询、资质文件核验、报价单解析、历史合作记录分析、价格对比计算、报告生成六个步骤。如果不用多智能体而是让一个Agent从头做到尾最大的麻烦是每一步涉及的上下文类型完全不同。查供应商库需要读结构化字段资质核验需要看扫描件PDF分析历史合作记录需要跑数据统计生成报告又要调用文档模板。这些操作塞进同一个Agent的上下文会严重挤占窗口空间可能导致Agent在最后一步生成报告时“忘记”前面的关键信息。用DeepAgents的思路怎么做主管智能体接收用户需求拆出6个子任务并按依赖关系排好序调用“供应商检索Agent”它通过MCP协议连接CRM系统的MCP Server执行query_supplier工具返回候选列表调用“资质审核Agent”它通过MCP协议连接文档解析服务逐个解析PDF文件并生成资质核验结果调用“分析Agent”对候选供应商的报价和历史数据进行统计分析调用“报告Agent”使用采购报告Skills生成最终文档。在这个链路里MCP解决了“怎么拿到数据和文件”A2A解决了“Agent之间怎么申请任务和回传结果”Skills解决了“报告格式怎么保证每次都合标”DeepAgents则是承载这一切的编排框架。4. Skills技能库构建把“这次会了”变成“以后都会”4.1 Skills和MCP到底有什么区别热词里有很多人在搜“Agent Skill 和MCP有什么区别”这确实是最容易混淆的一点。我给一个最简明的区分MCP解决的是“智能体没有的手怎么借过来”的问题——借力的标准化协议Skills解决的是“智能体会做但做得不稳定的活怎么固定下来”的问题——经验的标准化沉淀。举一个前端开发的例子。假设你经常让智能体帮你做网页改版需要一个“Figma设计稿转代码”的技能。如果用MCP你接一个Figma MCP Server智能体就能通过API读取Figma设计稿的文件信息和图层结构——这是“借到了读设计稿的手”。但读完设计稿之后怎么把设计稿的布局、颜色、字体转换为Tailwind CSS代码这是MCP解决不了的它只负责把设计稿数据拿回来。真正让智能体“每次都能产出风格统一的代码”的是一个写好的Skills文件包里面定义了转换规则、组件库映射表、代码输出格式、常见问题的处理策略。Skills的本质是**“夹在模型和Prompt之间的第二层大脑”**。它不像System Prompt那样每次都要占用大量上下文而是按需加载——只有当任务命中某个技能时系统才把对应的Skill文件注入上下文。这种设计大幅节省了Context开销也改善了响应质量。以OpenAI Codex和Claude Code为代表的编码工具中Skills机制在2025年被大量采用。简单来说一个Skill通常包含SKILL.md技能说明文件告诉系统这个技能是什么、适用于什么场景包括触发条件、使用步骤、注意事项参考脚本或模板可执行的脚本、示例代码、常用配置片段元数据技能的名称、版本、作者、依赖条件。4.2 从零编写一个“数据分析报告Skills”的具体步骤我建议每个做智能体的人都从写一个自己能反复用到的Skill开始练习。下面用一个“电商周报自动生成”的Skill作为案例拆解完整步骤。第一步定义技能的适用范围和触发条件。在SKILL.md开头就明确--- name: ecommerce_weekly_report description: 根据电商平台的订单数据、流量数据、客服数据生成周报。 适用的数据源MySQL数据库中的 orders 表、traffic_log 表、service_records 表。 当用户请求中包含周报周复盘销售分析等关键词且要求分析时间段为一周时优先使用本技能。 version: 1.0.0 ---这里的核心是触发条件要写得足够具体否则智能体可能在不该用的时候用了或者该用的时候没用。触发条件写得越精确技能的命中率越高。第二步编写详细的执行步骤。Skill和普通Prompt最大的区别是Prompt给出的是一段描述性的要求而Skill给出的是一套可执行的流程。比如从MySQL中读取订单数据按日汇总GMV、订单量、客单价读取流量数据计算UV、转化率、广告花费读取客服数据统计客诉量和主要问题分类将三部分数据合并计算环比和同比变化率按固定模板输出周报Markdown文档包含数据概览、趋势图、异常预警、下周行动建议四部分如果发现数据异常如GMV环比下降超过15%自动调用data_anomaly_analyzer工具进行分析。第三步附上可复用的代码模板。这一步决定了Skill的“工程含量”。把查询SQL、数据处理脚本、图表生成代码都放进Skill目录里智能体在执行时可以直接读取这些文件而不需要自己从零写代码。ecommerce_weekly_report/ ├── SKILL.md ├── scripts/ │ ├── fetch_order_data.sql │ ├── calculate_metrics.py │ └── generate_charts.py ├── templates/ │ └── weekly_report_template.md └── examples/ └── sample_output.md第四步提供高质量的示例输出。这一点很多人忽略但它是让模型快速学会格式的最有效方式。在examples里放一份标准的周报示例相当于告诉模型“照着这个格式来”。对于新读者而言一个成功的Skill案例不仅有文字流程还有别人做好的输出样例可以临摹。4.3 Skills的触发与维护超出预期的那些坑在实际运行中Skill最容易翻车的地方是**“写好了却永不触发”**。常见的原因有三个一是description写得太模糊。比如你写“数据周报生成Skill”并且期望模型自动判断何时使用模型很难判断“什么时候该用”。更稳妥的做法是同时维护一个“路由规则文件”——在系统Prompt里显式写清楚当用户请求中包含“周报”且时间范围是近7天时必须加载ecommerce_weekly_report技能。这个思路跟人类的项目管理其实很相似新增一个技能就像把一个新同事引入团队光发一份简历不够还需要告诉团队主管“什么情况应该找这个同事”。二是Skill文件太长加载后占据了大量上下文窗口。如果一份Skill超过3000个token模型在这种压力下的表现会明显下降。建议把Skill拆为“快速启动版”和“完整版”两个版本。快速启动版只包含核心指令完整版在需要时再通过读取文件的方式加载。三是Skills版本管理混乱。同一个技能改了三四版之后老的代码模板还残留在目录里模型可能随机加载到旧版本。建议明确规定每个Skill目录中只保留当前版本的有效文件历史版本统一放在archive/子目录下并加上版本号。5. 全流程实战从用户需求到多智能体交付的完整链路5.1 一个可复用参考的实战目标下面用一套“多智能体内容生产流水线”串联全文。RSS订阅助手负责追踪技术博客更新内容分析Agent负责摘要提炼和选题挖掘写作Agent负责生成初稿编辑Agent负责校验优化最后通过发布Agent推送到微信公众号后台。这个流水线可以直接迁移到“商品评论分析”“竞品监控”“数据分析报告生成”等场景。这套系统和热词里提到的“Inkos多智能体网文创作流水线架构解析”以及“多智能体企业采购助手”在架构思路上完全一致有主管做调度有专门的Worker干细活有质检环节做质量把关再用Skills固定每个环节的产出风格。5.2 主管智能体的任务拆解Workflow在整个流程启动时主管智能体会收到用户的原始需求。它要做的事情是把用户需求标准化成一个任务对象包含goal、constraints、deadline、requirements等字段查询能力注册表确认所需的子智能体是否在线、是否有权限把任务拆分为多个子任务为每个子任务指定负责人、输入和输出标准按依赖关系建好任务队列递交给执行层。这里有一个实战环节值得重点说说如何写好一个让子智能体不会有歧义的任务指令。我通常要求任务描述包含五要素背景为什么做这件事输入数据源在哪里、以什么格式提供输出最终交付物是什么、格式长什么样边界什么不能做、什么要拒绝验收标准怎么判断做得好不好。很多失败的多智能体项目问题不是模型能力不行而是任务描述含糊不清子智能体只能靠猜。5.3 子智能体通过MCP调用外部数据内容生产流水线里最依赖MCP的是数据接入环节。RSS订阅助手本身就是一个MCP Server暴露fetch_article、list_sources、mark_read等工具。内容分析Agent通过MCP客户端连接这个Server定期拉取文章列表和正文。整套对接对模型是透明的模型只需要知道自己有一个工具可以“拉取技术博客最新文章”系统会在调用时自动把MCP Server返回的数据转换成模型能读懂的文本。这里有个很实用的经验MCP工具的“描述”决定成败。MCP Server暴露的每个工具它的description字段会直接影响模型的调用准确率。比如你把工具描述写成“获取文章列表”模型可能只会在“需要文章列表”时调用但如果你写成“获取当前订阅的所有技术博客的最新文章列表支持按标签过滤和按时间范围过滤用于内容分析和热点追踪”模型就能更准确地决定在什么时候使用、传入什么参数。工具描述写得越具体Agent的调度效果越好。5.4 子智能体之间通过A2A协作在内容生产流水线中写作Agent和编辑Agent往往是由不同的团队维护的甚至可能是不同框架开发的。写作Agent基于DeepAgents框架编辑Agent可能就是一个独立的LangGraph服务。这种情况下让它们直接共享内部上下文是不现实的最合适的方式就是走A2A协议。具体过程是写作Agent完成初稿后通过A2A协议向编辑Agent发起一个新的任务任务内容包括“初稿Markdown文本、目标公众号排版风格、需要检查的维度清单”。编辑Agent收到任务后进行错别字检查、逻辑连贯性检查、格式规范检查然后把修改意见或修改后的版本通过A2A协议返回。注意这里和我们在MCP里讲的“工具调用”不同——写作Agent不是在“调一个编辑工具”而是真的在“给另一个独立的智能体安排任务”。这个区别很重要如果编辑Agent本身就是一个完整的多智能体系统有自己的外部工具和内部调度逻辑那么A2A的松耦合模型会带来非常大的灵活性。5.5 用Skills把任务经验固化下来流水线跑完几轮后你会发现一个明显的现象每次生成周报或者初稿时模型产出的风格和结构都会有细微的波动。例如编辑Agent第一次改语病改得很勤快第五次可能就只改了错别字其他问题都放过去了。这不是模型在“偷懒”而是Prompt对细节的约束能力存在上限。解决方式就是前面说的Skills。把编辑Agent的“编辑规范”整理成一个editor_checklist技能里面包含错别字检查清单、敏感词过滤规则、公众号排版格式模板、标题优化策略。每次编辑Agent启动时系统按需加载这个技能产出的质量稳定性会好很多。我自己跑通这套流水线之后最大的感受是多智能体系统的上限由框架决定下限由Skills决定。框架保证任务能拆得开、分得下去、结果收得回来Skills保证每个环节的产出风格稳定、不发挥失常。两者缺一不可。6. 跑通闭环后避坑三个翻车现场的排查链路6.1 症状一子智能体“假装调用”了MCP工具这是一个比较隐蔽的问题。用MCP之后模型有时会在生成内容里“说”自己调用了某个工具但实际上并没有真正发起MCP请求。比如分析Agent的回复里写了“已从数据库获取订单数据”但数据库的访问日志里根本没有对应记录。这种情况常被称作“工具幻觉”或“半接通”。排查链路如下先确认MCP Server的工具是否成功注册到了Agent的可用工具列表里。方法是在调试界面打印Agent当前的工具列表如果看不到目标工具说明MCP Client的注册逻辑有问题确认工具描述是否足够具体。如果描述太模糊模型可能会“以为”自己已经具备了某个能力而忽略了调用工具这个动作。解决办法是把工具描述写得更准确并加上“必须调用工具来获取最新数据不得编造”的指令确认系统内部有没有对“调用结果”做校验。我通常会在框架里加一个拦截器如果Agent的输出中包含了“已调用工具”之类的声明但实际没有对应的工具调用记录就抛出一个警告并强制Agent重新执行工具调用。这个问题一旦出现排查成本很高所以更推荐用“先验证工具链路再跑业务”的方式避免。每次新增MCP Server第一件事不是跑业务而是发一条“请调用工具查询当前状态”的测试指令确认工具链路完全打通后再开展后续开发。6.2 症状二A2A协议0.3与1.0版本握手失败如果你的A2A客户端和服务端版本不一致最常见的报错是握手阶段返回protocolVersion不匹配。这个问题看起来很好解决——升级版本就行但实际中有不少麻烦老的服务端Agent可能只实现了0.3版本升级需要动到整个部署而你的客户端已经用了1.0版本的SDK两边的消息信封结构和状态机定义差异很大。我的处理建议是在A2A的服务端做协议版本协商先把两端支持的版本列表读出来如果有交集就用最高公共版本没有交集就直接断开并返回错误码。这相当于在握手时加了一个版本兼容判断层。在网关层记录每次A2A握手的协议版本并监控版本分布。这样你能知道生产环境里还有多少旧版本客户端在跑方便排期升级。如果确实无法同步升级建议在内部加一套“协议转换适配器”将0.3版本的请求转换成1.0版本再转发给新服务端。但尽量不要长期依赖这种适配层它会让排查问题的成本变得很高。6.3 症状三Skills写好了却不命中这是最有挫败感的问题明明把技能文件写得很详细模型却总是“视而不见”该用技能的时候还是按通用能力硬答。排查链路如下检查SKILL.md的description是否包含足够的触发关键词。如果你期望“周报生成”场景命中description里最好明确写上“周报”“周复盘”“销售分析报告”等词检查技能加载机制。如果框架是“按关键词匹配加载”那关键词设计就很关键如果是“由模型自己决定加载”那description要写成第三人称的客观描述而不是第一人称“我能做什么”做一个对照测试先不加载技能跑一次业务再加载技能跑一次业务对比输出质量。如果差异很小说明技能内容本身没有提供足够的增量信息需要反思技能里写的内容是不是模型本来就会的。Skill的价值必须体现在“模型不会或者做不好的地方”。6.4 排查清单汇总现象可能原因首选检查项Agent回复“已调用工具”但实际未调用工具描述不精确 / 注册链路中断 / 缺少调用结果校验打印工具列表与调用日志A2A通信失败版本不一致 / 认证方式不匹配 / Agent Card地址错误检查protocolVersion与握手日志Skills不触发命中关键词缺失 / description质量差 / 技能无增量信息对照测试有技能与无技能的差异子Agent任务执行结果与预期偏差大任务描述五要素缺失 / 能力注册表过期审查任务描述中的边界与验收标准排查问题的原则很统一先确认链路是通的再去调模型行为。链路不通调多少次Prompt都没用。从我个人的实战体会来说这套“DeepAgents MCP A2A Skills”的组合最大的价值不在于某个单独技术有多新而在于它把智能体开发从“写Prompt”推进到了“设计系统”的阶段。以前我们关心的是“怎么让模型答对”现在关心的是“怎么搭一个体系让它稳定产出”。如果你刚开始接触建议别急着追求大而全先做一个最小闭环一个Agent、一个MCP Server、一个Skill跑通之后再往上加第二个Agent、加A2A通信。这个顺序能让你在每一步都知道问题出在哪个层面也便于积累排查经验。