最近把慕课上那套 DeepAgentsMCPA2ASkills 的课完整过了一遍又跟着做了几轮实验手上一个内部小助手也被我改成了多智能体集群。整个过程下来最直观的感受是单 Agent 时代拼的是一个模型能记住多少事多 Agent 时代拼的是一群 Agent 能不能像一支团队一样配合。MCP 解决的是 Agent 和工具之间的连接A2A 解决的是 Agent 和 Agent 之间的通信Skills 解决的是把会做一件事沉淀成可复用资产而 DeepAgents 这套思路则是把这些东西编排成一张可以指挥的网络。这篇文章不打算复述课程目录只讲我自己在搭建集群时真正用到的东西为什么单 Agent 会垮MCP/A2A/Skills 各自要解决什么怎么一步步把它们组合成一套可编排、可互通、可扩展的 Agent 集群以及我踩过的坑和排查方法。适合刚接触 Agent 开发、想做多智能体编排或者已经被一堆Agent 框架绕晕的工程师看。1. 为什么单Agent撑不住一个全科医生打不过一家医院1.1 单Agent的天花板在哪里先聊一个很现实的问题为什么一定要拆成多个 Agent我见过不少团队一开始很兴奋把需求文档、代码仓库、数据库表结构全部塞给一个 Agent结果效果一塌糊涂。不是模型不行而是单 Agent 架构有四个绕不过去的天花板。第一是上下文窗口的诅咒。Agent 要干活就得把相关背景都塞进上下文。任务一复杂光是一堆工具定义、系统提示词、历史对话就能吃掉大半窗口真正留给业务数据的位置越来越小模型就开始遗忘前面的内容输出质量肉眼可见地下降。把一个真正的业务系统交给单个 Agent等于让一个全科医生同时负责挂号、问诊、拍片、开刀、写病历他能记得住多少第二是工具爆炸。一个 Agent 接入 5 个工具还行接入 50 个工具之后光让模型在每一步正确选对工具就是一场灾难。工具描述之间还会互相干扰调用参数经常搞错。MCP 能统一工具接入方式但工具数量多了仍然需要把工具按职责拆给不同的 Agent 去持有而不是让一个 Agent 背着一堆瑞士军刀。第三是单点失败。一旦主 Agent 的某个环节卡住、超时、幻觉整个任务就废了。没有拆分就没有隔离没有隔离就没有恢复策略。多 Agent 架构里单个 Agent 挂了可以重试、可以降级、可以换人单 Agent 架构里完全做不到。第四是权限和安全的粒度。一个拥有全部数据库权限的 Agent远比一个只负责查订单表的 Agent 危险。所以我把这一点也看作为什么要拆的重要原因拆成多个专职 Agent才能做到最小权限、最小暴露面。1.2 DeepAgents 核心把任务拆给一群专职 Agent课程里把这种深度拆分的多智能体架构统称为 DeepAgents我自己理解下来它不是什么全新的框架而是一套设计哲学复杂任务不要试图让一个 Agent 大包大揽而是由编排层把任务拆解成多个子任务分配给一批专职 Agent每个 Agent 只做自己最擅长的一件事最后统一汇总结果。听起来像是多个 Agent 跑起来就行但难点在深度两个字。简单并发调用三个 Agent 不是 DeepAgents真正的深度是把任务层级拆透入口 Agent 只负责理解需求规划 Agent 负责拆解任务执行 Agent 负责调工具、写代码、跑测试质检 Agent 负责检查结果监督 Agent 负责兜底和重试。每层之间还要有清晰的数据契约上游的输出就是下游的输入。我实际做下来最值钱的一点是任务拆分之后每个 Agent 的 Prompt 变得极其简单。一个只负责生成前端页面组件的 Agent系统提示词可能只有几百字但效果比一个全知全能的 Agent 好很多。原因也简单上下文干净了工具选择范围窄了模型自然不容易出错。1.3 可编排、可互通、可扩展到底指什么标题里三个关键词值得先掰开揉碎。可编排指的是你把一群 Agent 组织成工作流的能力。谁先执行、谁后执行、哪些可以并行、失败之后重试还是换方案、需不需要人工介入。可编排性差的架构Agent 只能各干各的没法形成一条完整的流水线。可互通指的是异构 Agent 之间能互相调用。现实工程里不会只有一个框架可能是 LangGraph、Spring AI、自研框架搭在一起还可能是 Python、Java、C 写的服务。可互通不是说把它们放同一台机器上而是让它们通过统一协议发现彼此、发起任务、传递结果。可扩展指的是往集群里加新 Agent、加新技能、加新工具时不需要改老代码。扩展性差的系统加一个 Agent 要动一半的编排逻辑那就不是集群是一堆耦合在一起的意大利面。这三个目标刚好对应三件套编排层负责可编排A2A 协议负责可互通MCP 和 Skills 负责可扩展。下面分别展开。2. MCP给Agent装一个通用USB-C口2.1 一次 MCP 调用背后发生的事MCP 全称 Model Context Protocol最早由 Anthropic 提出并开源现在已经成为 Agent 连接外部工具的通用协议。我在课程里学到的最有价值的类比是MCP 之于 AI Agent就像 USB-C 之于电子产品。以前每个设备都有自己的充电口Agent 每接一个工具都要写一套自定义接入逻辑有了 MCP所有工具只要实现一套标准协议Agent 就能即插即用。MCP 的架构分三层Host 是 Agent 应用本身Client 是 Host 内部和远端通信的模块Server 则是暴露工具、资源、提示词的服务。一次完整的 MCP 调用大致是这样的Client 和 Server 先做握手通过initialize确认协议版本和能力。Client 调用tools/list获取 Server 暴露了哪些工具每个工具的 name、description、inputSchema。Agent 根据任务描述决定使用哪个工具然后 Client 发起tools/call把参数按 JSON Schema 传过去。Server 执行工具逻辑返回结构化结果给 Agent。这个设计和 Rest API 最大的区别是工具描述本身也成了给模型看的说明书。tools/list返回的内容会被塞进模型的上下文让模型知道现在手里有哪些牌可以打。所以 MCP Server 里工具的描述写得越清楚Agent 选对工具的概率越高这一点后面避坑部分会细说。传输层面老版本流行 stdio 和 SSE新版本已经在推 Streamable HTTP简单说就是支持普通的 HTTP POST也支持流式返回。我现在的推荐是本地开发用 stdio线上服务用 Streamable HTTP。2.2 10分钟写一个 MCP Server纸上谈兵没用直接写一个。我平时用 Python 的 FastMCP 最多因为它真的能十分钟上线。假设要让 Agent 能读取并统计本地文件代码可以这样from fastmcp import FastMCP mcp FastMCP(文件助手) mcp.tool() def read_file(path: str) - str: 读取指定文本文件的完整内容。当用户需要查看代码、日志或文档时使用。 with open(path, r, encodingutf-8) as f: return f.read() mcp.tool() def word_count(text: str) - dict: 统计一段文本的字数与行数。 lines text.splitlines() return {lines: len(lines), chars: len(text)} if __name__ __main__: mcp.run(http)然后启动pip install fastmcp python mcp_server.py再把它注册到 Agent 客户端里。以 Claude Desktop 为例配置文件里加入{ mcpServers: { file-helper: { command: python, args: [/path/to/mcp_server.py] } } }重启客户端Agent 就能用这两个工具了。这里面有两个细节值得注意。第一工具描述尽量贴近用户意图而不是实现细节。我写的是当用户需要查看代码、日志或文档时使用而不是读取文件路径内容因为模型是根据意图去匹配工具的。第二返回结果最好是结构化数据而不是一行干巴巴的字符串。结构化返回能让 Agent 的下游判断更准确也为后面多 Agent 编排时的结果传递省了很多事。2.3 MCP 已经不只属于 AI 应用MCP 的价值正在出圈。我看热词里有一批很有意思Unreal 5.8 MCP、IDA mcp、x32dbg 的 MCP 插件、ruoyi-vue-pro 合并 MCP 功能。这说明游戏引擎在做 MCP逆向工具在做 MCP甚至开源后台脚手架也在内置 MCP。这件事透露出的信号是MCP 正在变成 AI Agent 时代的标准外设接口。工具方只要做一次 MCP Server就能让所有支持 MCP 的 Agent 使用它而不是为每一家 Agent 单独适配。对做基础软件、开发者工具、行业 SaaS 的团队来说越早支持 MCP越早能被 AI Agent 生态接进去。我自己的判断是短期内优先接 MCP 的领域一定是模型需要动手操作的地方比如查数据库、跑测试、操作设计稿、读写文件、控制浏览器。像前端开发工程师常用的 Figma MCP、蓝湖 MCP其实已经在设计稿转代码的工作流里发挥作用了后面 Skills 部分会提到怎么把它们组合起来用。2.4 MCP 实战中容易踩的坑第一坑权限失控。MCP Server 暴露的工具Agent 都能调。如果你把删除数据库表也暴露出去模型一旦判断错了带来的后果是实打实的。我的经验是线上 Server 默认只读需要写操作的工具单独分类并且加人工审批。第二坑工具返回内容过大。MCP 一次tools/call可能返回几十万字结果不等 Agent 处理上下文先爆了。解决办法是工具内做截断、分页、摘要只返回 Agent 需要的那一小块。第三坑超时和流式输出。很多同学用 MCP Server 执行长时间任务结果客户端早就超时断开了。长任务应该先让 Server 创建一个任务 ID 并立即返回Agent 再轮询结果或者用 Streamable HTTP 的流式更新而不是傻等一个同步结果。第四坑工具描述写得太烂。这个我前面说过MCP 的说明书质量直接决定模型选工具的正确率。花十分钟把每一个工具的 description 写到用户什么意图时该用我比后面调 Prompt 划算得多。3. A2A让Agent之间真正对话3.1 为什么有了 MCP 还不够有同学会问MCP 都让 Agent 能连工具了怎么还要 A2A因为一个是纵向一个是横向。MCP 解决的是 Agent 调用工具、查询数据的问题这是纵向的向下连接但 Agent 之间要互相传递任务、共享结果、协同工作这是横向的平级通信MCP 管不着。举个例子。在前端生成流水线里前端 Agent 完成页面代码后需要把产物交给测试 Agent 去跑检查。如果两个 Agent 之间没有协议我只能把产物写到一个共享文件再让测试 Agent 去读或者用消息队列自己实现一套通知机制。短期能用但每加一对 Agent 就要写一遍自定义接口完全不可扩展。A2A 就是为这个场景设计的公共协议。3.2 Agent Card、Task、Message、ArtifactA2A 的四张核心牌A2A 全称 Agent2AgentGoogle 提出并捐赠给了 Linux 基金会目标是让不同框架、不同语言的 Agent 能像网页服务一样互相发现、互相调用。我把它拆成四张牌来理解。第一张牌是 Agent Card相当于 Agent 在网上的名片。每个 Agent 都要在固定地址暴露一个 JSON 文件通常是/.well-known/agentcard.json里面写清楚这个 Agent 叫什么、能做什么、怎么调用、支持哪些能力。其他 Agent 拿到这张卡就知道我该不该找它、找它的时候怎么开口。第二张牌是 Task代表一次完整的合作。A2A 通信不是简单的请求返回而是围绕一个 Task 来管理生命周期。Task 有状态比如 submitted、working、input-required、completed、failed发起方可以通过tasks/send创建任务用tasks/get查询状态用tasks/cancel取消。第三张牌是 Message是任务进行中的对话单元。双方通过 Message 交换指令、补充信息、反馈进展。第四张牌是 Artifact是任务的产物。前端 Agent 输出的代码、设计稿、测试报告都可以作为 Artifact 在 Agent 之间流转。一句话总结Agent Card 负责发现Task 负责管理生命周期Message 负责沟通Artifact 负责交付。这个抽象和人类团队协作非常像所以很好理解。3.3 把现有 Agent 暴露成 A2A 服务如果你已经有一个 Agent 服务想让它被其他 Agent 发现和调用最快的方式是给它加一个 A2A 协议壳不需要重写内部逻辑。流程分三步。第一步生成 Agent Card。我用 Python 写一个简单的 FastAPI 接口暴露/根地址和/.well-known/agentcard.json。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() agent_card { name: frontend-agent, description: 根据设计稿或需求生成前端页面代码支持 Vue/React, url: https://agent.example.com/, capabilities: { streaming: False, pushNotifications: False } } app.get(/.well-known/agentcard.json) def get_card(): return agent_card class TaskRequest(BaseModel): id: str type: str message: dict {} app.post(/tasks/send) def handle_task(req: TaskRequest): # 这里把 A2A 请求转换成自己 Agent 内部的调用 result my_agent_runner(req) return { id: req.id, status: {state: completed}, artifacts: [{id: artifact-1, content: result}] }第二步把 Agent 内部的 PEP 变成 A2A 的请求结构。这里最重要的是定义好 Message 里的文本内容和 Artifact 的结构让调用方知道怎么解析。第三步将 Agent Card 注册到集群的 Agent 注册中心。注册中心可以是简单的数据库表也可以是 Nacos、Consul 这类服务发现组件。这样编排层就能通过注册中心找到谁能做前端页面生成然后把任务发给它。如果是 Spring 技术栈现在也有 A2A 的 Spring 集成Spring AI 官方已经支持 A2A 协议Java 生态的同学可以直接用 Starter 暴露 Agent CardC 也有社区实现。跨语言的 Agent 互调没有想象中那么难因为 A2A 本身就是 HTTP JSON。3.4 A2A 和 MCP 怎么配合不是替代是两层很多人把 A2A 和 MCP 当成竞争关系其实完全不是。A2A 在上层做 Agent 之间的互操作MCP 在底层做 Agent 与工具的连接。一个典型的调用链是这样的编排 Agent 收到需求发现需要一个数据库查询 Agent于是通过 A2A 发出任务这个数据库查询 Agent 内部再用 MCP 去调用数据库工具取出数据取回的数据以 Artifact 的形式通过 A2A 返回给编排 Agent。我甚至可以在同一个 Agent 里同时用两种协议对外提供 A2A 端点对内用 MCP 调用工具链。所以在架构设计上不要把 MCP 和 A2A 分开规划而要看成一条完整链路的上下游。3.5 跨语言 A2A 不是梦实际项目中技术栈很少是统一的。热词里有 a2a spring C a2a python a2a说明这个痛点大家都在碰。A2A 的好处在跨语言场景体现得最明显只要大家都实现 Agent Card 和 HTTP JSON 端点Python Agent 完全可以调用 Java AgentC Agent 也能给 Node 服务发任务所有 Agent 之间不用关心对方内部是什么框架。协议本身还支持可选的安全认证机制常见做法是在 HTTP 头里带 Bearer token再结合 OAuth2 做授权。我在线上部署时做了两件事内部网络里 A2A Endpoint 只允许集群内网 IP 访问外部调用必须经过 API 网关统一鉴权每个 Agent 有独立的 token。别嫌麻烦协议互通只是第一步安全隔离才是长期跑稳的基础。4. Skills把会做某事封装成可复用的技能包4.1 Skill 不是 Prompt也不等于工具第三个要拆清楚的是 Skills。Skill 这个词最近很热Claude Skills、Codex Skills、Agent Skills 都在讲。我理解 Skill 就是给 Agent 的一份能力说明书 操作手册它不同于一段临时 Prompt也不同于 MCP 暴露的单个工具。和 Prompt 的区别在于Skill 是可复用的、结构化的资产有固定目录、有说明文档、有参考资源、可能有脚本能被 Agent 在合适的场景自动加载而不是每次从零写一段提示词塞进去。和 MCP 工具的区别在于MCP 工具解决的是能调用什么外部能力Skill 解决的是知道怎么把一件事做对。比如写前端页面这件事MCP 可能给你提供 Figma 设计稿读取工具和代码生成 API但 Skill 告诉 Agent 应该遵循什么样的项目规范、用什么组件库、代码风格是什么、完成后要检查哪些东西。Skill 可以把多个 MCP 工具串成一套工作流。4.2 手写一个前端页面生成 Skill动手写一个。Anthropic Agent Skills 规范已经比较成熟目录结构一般是这样的frontend-page-builder/ ├── SKILL.md ├── reference/ │ ├── design-tokens.md │ └── component-guide.md └── scripts/ └── generate_component.pySKILL.md 是核心用 Markdown 编写开头必须带 YAML frontmatter声明 name 和 description。description 非常重要它负责告诉 Agent什么时候该用这个 Skill。--- name: frontend-page-builder description: 当用户要求根据设计稿或需求描述生成前端页面、修改现有页面、创建 Vue/React 组件时使用。包含项目风格规范、组件库选型、设计稿读取方式和代码生成步骤。 --- # 前端页面生成流程 1. 先读取 reference/design-tokens.md了解项目的颜色、间距、字体规范。 2. 如果提供了设计稿链接使用 Figma MCP 工具读取设计稿内容提取布局和文案。 3. 按照 reference/component-guide.md 中的组件库清单选组件。 4. 生成页面代码保持组件原子化拆分。 5. 最后用 scripts/generate_component.py 检查生成结果是否符合规范。reference 目录放的是 Agent 需要翻阅的静态知识比如设计规范、组件文档、项目约定。scripts 目录放的是可执行脚本让 Agent 动手做验证或辅助生成。装好之后Agent 会在合适的任务里自动加载这个 Skill而不是每次都要用户在对话里叮嘱一遍注意项目规范。Codex Skills 的思路也类似只不过默认目录在.codex/skills/下面格式也是 SKILL.md 加资源文件。热词里提到的codex 写论文的 Skills前端开发 Skills基本都是这种模式。自己写 Skill 其实不难难的是把你希望 Agent 长期遵守的做法提炼成可执行的文档。4.3 去哪找 Skill、怎么装找 Skill 的渠道主要有三类官方市场、社区仓库、自己内部沉淀。Claude 有官方 Skills Marketplace 概念Codex 也支持从目录加载社区平台上已经有人分享各种写论文、写前端、做代码审查的 Skill 包可以直接下载放到对应目录里使用。安装这件事本质就是放到 Agent 能扫描到的目录 让描述写清楚两步。比如 Claude 项目里放.claude/skills/Codex 项目里放.codex/skills/。我自己的习惯是任何团队成员在项目里总结出的优秀做法都会沉淀成一个 Skill而不是写成微信群公告。因为公告只进人眼Skill 是进 Agent 的记忆。4.4 Skill 多了也头疼有一点必须泼冷水Skill 不是越多越好。我们内部最早攒了几十个 Skill结果 Agent 经常选错技能甚至同时加载多个互相矛盾的 Skill。后来发现Agent 选择 Skill 主要靠的就是描述文本描述写得模糊就必然选错。我的管理规范是每个 Skill 的 description 限制在一句话以内明确触发场景和禁止场景相同领域的 Skill 合并Skill 里的指令要和 MCP 工具调用解耦描述只讲该怎么做不写死具体工具。还有Skill 内容必须经过代码评审防止有人偷偷往 Skill 里塞忽略安全限制这类危险提示。5. 落地一套可编排、可互通、可扩展的Agent集群5.1 分层架构怎么搭把前面三块串起来之前先给整体架构画个分层图。虽然不能画图但用文字描述很清楚接入层接收用户请求可以是 Webhook、WebSocket、API 网关、甚至钉钉/企微机器人。编排层核心大脑负责需求理解、任务拆分、调度 Agent、状态管理、重试和人工审批。Agent 层一群专职 Agent每个 Agent 通过 A2A 暴露能力内部再用 MCP 连接工具。技能与工具层MCP Server 集群和 Skill 资产库。基础设施层任务队列、数据库、向量库、可观测系统。我的经验是编排层不要和 Agent 混在同一个进程里。编排层要做的事情已经很重了如果还把 Agent 进程跑在它里面一旦某个 Agent 崩溃就会把编排层带走。正确做法是 Agent 独立部署编排层只负责发任务和收结果。5.2 拿一个真实需求串一遍具体一点假设现在接到一个需求根据设计稿生成一个用户管理页面并且把列表接口接上。 在 DeepAgents 架构里流程是这样的入口 Agent 接收需求判断这属于前端生成 后端接口对接任务把原始材料交给编排层。编排层拆成三个子任务前端页面生成、后端接口确认、联调测试。通过 A2A 在注册中心找到前端 Agent发起tasks/sendMessage 里带着设计稿链接和需求描述。前端 Agent 收到任务自动加载frontend-page-builderSkill再通过 Figma MCP 读取设计稿、通过代码生成 MCP 生成页面代码。完成后把代码作为 Artifact 返回给编排层。编排层把前端产物传给后端 Agent。后端 Agent 用 MCP 查询数据库表结构确认列表接口字段生成接口代码同样返回 Artifact。编排层把两端产物下发给测试 Agent。测试 Agent 运行检查发现问题就把错误信息作为 Message 退回给对应的 Agent 修改。最后由编排层汇总所有 Artifact返回给用户。可以看到每个 Agent 只做一件事工具通过 MCP 接入Agent 之间通过 A2A 传递任务与产物做事的流程规范由 Skill 管理而全程的推进节奏由编排层控制。5.3 编排层的核心机制状态机、重试、人工审批编排层是整个集群的心脏我在实际开发里主要做三件事。第一把每个任务建模成状态机。一个任务至少有 pending、running、waiting_input、completed、failed、cancelled 这些状态。所有 Agent 汇报的结果都要先翻译成状态更新而不是直接改业务数据。状态机的好处是流程可回溯、异常可定位、恢复可执行。第二重试不能无限重试。我见过同学写了个 for 循环Agent 失败就重新调一次结果模型反复犯同样的错白白烧掉大量 token。重试要区分错误类型工具超时、网络抖动这类重试有意义任务本身理解错误就得换思路重排而不是重复试。我通常设置最多重试 2 次超过就转人工。第三重要操作必须人工审批。AI Agent 直接执行删除、发邮件、对外支付这类操作风险太高。我的做法是在编排层定义一个 approve 节点Agent 执行到高风险动作时停在 waiting_input 状态通过企业微信推消息给人工人工确认后才继续推进。5.4 Agent怎么扛并发的答案热词里有个很实在的问题AI Agent 怎么扛并发我在这套架构里的答案是不要让 Agent 调用变成同步阻塞。多 Agent 集群在线上的正确姿势是异步任务化 队列削峰。用户请求先进队列编排层消费队列创建任务任务在各个 Agent 之间流转时都是异步状态更新客户端通过轮询或者 Webhook 拿最终结果。只有这样几十个 Agent 实例才能同时处理几百个任务而不是每个请求都占用一条同步连接、把进程堵死。另一个关键点是幂等。因为任务是异步的重试和超时重发在所难免A2A 的每次任务请求都要带上业务方生成的唯一 idAgent 端要做去重处理。我因为这个吃过亏两个重复的前端生成任务同时执行产生了两个不同版本的页面代码浪费了大量 token。可扩展性方面我做到三点新 Agent 上线只需要注册 Agent Card不需要动编排代码新技能通过 Skill 包热加载不用发版新工具只需新增 MCP ServerAgent 通过协议发现它。这三点做到了集群才能真正加人不改架构。6. 实测避坑照着这些经验做少走两个星期弯路6.1 五个高频问题第一个问题MCP Server 起了但 Agent 说找不到工具。排查最先看配置路径和命令参数本地客户端用 stdio 时路径有误很常见线上则先看服务有没有监听正确端口。接着看tools/list返回是否为空如果为空八成是工具装饰器没注册上或者 Server 启动时报错被静默吞掉了。第二个问题A2A 回调地址不通。我最早把 Agent 部署在内网Agent Card 里的 url 写的是http://localhost:8000结果当然调不通。线上环境必须写其他 Agent 能访问的地址同时处理好 NAT、网关映射、HTTPS。还有一个细节Agent Card 的 url 字段应该指向能处理/tasks/send的根地址不是文档页面地址。第三个问题Agent 死循环。常见原因有两个编排层的重试逻辑没有区分错误类型导致同一个错误被无限重试或者某个 Agent 输出的 Message 结构错误调用方解析失败后不断重新发起任务。我后来给每次任务加上 token 预算和最大步骤数超过阈值直接失败并通知人工效果立竿见影。第四个问题Skill 太多导致选错。表现是 Agent 本来应该生成 Vue 页面却加载了一个写论文的 Skill。原因基本是 description 写得含糊或者多个 Skill 的描述里都有生成文档这种重合词。我处理办法是给 Skill 描述加上正反例不要用于……同时降低重复描述效果明显。第五个问题队列积压导致体验差。异步化了之后用户等得太久。优化的核心不在于调快 Agent而在于拆分任务的粒度和并行度。能把一个 5 分钟的长任务拆成 5 个 1 分钟的并行子任务体验提升 5 倍。当然这依赖任务本身能不能拆不能为拆而拆。6.2 排查速查表现象大概率原因排查与解决MCP 工具找不到配置路径、启动参数、Server 崩溃先验证tools/list再看 Server 日志MCP 返回内容丢失返回体过大被截断工具内做摘要/分页只返回必要字段A2A 任务一直 pendingAgent Card url 不可达、回调不通用 curl 测根地址检查 NAT 与鉴权Agent 反复失败重试未区分错误类型重试超过 2 次转人工设置 token 预算Skill 选择错误description 模糊、多个 Skill 重叠收敛 Skill 数量描述加触发和禁止场景并发一高就卡死同步阻塞调用改异步任务队列任务幂等状态持久化6.3 最后几句实在话我个人的体会是这套技术组合里MCP 解决的是脚让 Agent 能碰到真实世界的工具A2A 解决的是嘴让 Agent 之间能沟通协作Skills 解决的是脑把做事的经验沉淀下来DeepAgents 则是一套神经中枢负责让所有部分按节奏协同。四者缺一不可但如果非要选一个最先投入的我还是推荐先把 MCP Server 写好。因为不管编排多漂亮、协议多标准最后能真正交付价值的还是 Agent 能不能可靠地调用工具、拿到结果。还有一个很小的技巧分享一下不管是用 MCP 还是 A2A都要把每一次 Agent 调用的输入输出记录下来存成结构化日志。这套集群排错主要靠日志没有日志再厉害的架构也开不了车。先把工具调用链路、任务状态流转、Skill 加载记录都打全后面加 Agent 才会越来越顺。