1. 这门课到底在解决什么问题这几年做 Agent 开发的人应该都有一个共同的感受单机单 Agent 的玩法已经快到头了。无论你用的是 Claude、GPT 还是本地模型单个 Agent 再聪明它也就是一个“能干活但只能干自己那份活”的个体。一旦遇到跨系统联动、多角色协作、工具权限隔离、能力复用这些场景光靠一个 Agent 加一套 Function Call根本撑不住。这个项目的标题——DeepAgents MCP A2A Skills 超级多智能体——就是把这一代 Agent 开发的核心拼图凑齐了。它本质上讲的是四层东西DeepAgents 是编排骨架MCP 是让 Agent 能调用外部工具的统一协议A2A 是让 Agent 之间能互相通信的协作协议Skills 则是把一些可复用的能力沉淀成可加载的技能包。四者合起来构成一个不仅能单打独斗、还能组队作战的多智能体集群。我看过很多开发者卡在同一个地方明明思路都有模型也能返回正确意图但一跑到真实环境就垮了。要么是工具越加越多每个 Agent 的上下文被塞爆要么是各种 API 对接方式五花八门维护成本远超收益要么是做完了多个 Agent却发现它们之间的通信要靠手工传参。这不是模型能力的问题是缺少一套规范的架构设计。这门课的价值就在于把上面四个概念串起来真正落地到一套可以跑起来的集群架构里。对于还在用单 Agent 做原型、想升级到多 Agent 生产环境的团队或者刚接触 Agent 开发、想搞清楚 MCP 和 A2A 到底是什么关系的新手这个项目能帮你少走很多弯路。下面的内容我会按照“编排、互通、扩展”这条主线拆解这套技术栈的核心思路、关键实现、以及我在实际动手过程中踩过的坑。2. 整体架构拆解为什么是这四个东西组合在一起2.1 从单体 Agent 到 Agent 集群的演化逻辑要理解这套技术栈就得先理解 Agent 架构的演化路径。第一代 Agent 基本就是个“大模型 工具调用”的直筒子用户提问模型决定要不要调用某个工具工具返回结果模型组织答案。这个模式在单场景、少工具的情况下是可行的但一旦工具数量超过几十个模型做工具选择的准确率就会明显下降每次调用还要把大量工具描述塞进上下文token 消耗感人。第二代演化是“Agent 工作流引擎”。比如 LangGraph 那种带状态机的编排方式——把任务拆成节点每个节点是一个 Agent 或工具节点之间用边连接通过图执行来控制流程。这种方案解决了一部分“谁先谁后”的问题但仍然偏中心化工作流的编排逻辑是写死的Agent 本身没有太多自主决策空间。到了第三代就是这套方案的主场多个智能 Agent 组成一个松耦合的集群。DeepAgents 负责调度和编排MCP 把外部工具和内部能力统一成标准接口A2A 让集群内的 Agent 可以像服务一样互相发现和调用Skills 则允许把常用能力打包成即插即用的模块。这个组合不再假设所有能力都在同一个 Agent 里而是假设一个集群里每个 Agent 各有专长彼此可以通过标准协议协作。这是从“单个全能选手”到“一个各司其职的团队”的架构转变。2.2 四层分工编排层、工具层、通信层、能力层我习惯把这套技术栈分成四个层次来看这样更容易理解各自承担的角色层次对应技术解决的问题生活化类比编排层DeepAgents谁来调度、按什么顺序调度、任务如何分配项目总指挥工具层MCPAgent 如何标准化地调用外部工具和数据USB 统一接口通信层A2AAgent 之间如何发现对方、如何传递任务和结果团队内部的对讲机能力层Skills如何把领域知识和方法沉淀为可复用模块员工培训手册分开看都很简单但真正关键的是怎么把它们组合起来。比如MCP 和 A2A 容易被混淆MCP 解决的是 Agent 访问工具的问题方向是“Agent 向下接入系统”A2A 解决的是 Agent 之间互访的问题方向是“Agent 横向连接 Agent”。Skills 则不是独立的网络协议它更像是知识和流程的封装单位既可以挂在 MCP 工具上也可以挂在 A2A 服务能力上。2.3 选这套组合而不是其他方案的理由在最初设计架构时我也对比过另一条路线直接用 Message Queue JSON Schema 自研一套 Agent 通信协议再加一个中心化调度器。后来放弃的原因有三个。第一自研协议的兼容成本太高。AGENTS即 A2A 前身协议和 MCP 已经是一线厂商在推的开放标准社区生态、SDK、调试工具都相对成熟。如果自己定义协议就意味着每一个接入方都要按你的约定来写代码而用开放标准等于直接获得了跨厂商的互操作能力。第二纯中心化调度会把编排逻辑变成一个大泥球。DeepAgents 这类编排框架的调度模型是“协商式”的——不是所有任务都由一个中心节点拍板而是 Agent 之间可以互相请求、拒绝、转派这在任务边界模糊的场景下比死板的流程引擎灵活得多。第三Skills 的价值被严重低估。很多人觉得 Skill 就是“提示词 几个工具函数”但实际上一个设计良好的 Skill 模块应该包含完整的“触发条件、使用步骤、输出格式、错误处理”四要素。它不是零散的工具而是半个 Agent 的“肌肉记忆”。3. MCP 实操细节让 Agent 真正摸到外部世界3.1 MCP 的本质是“协议”而不是“框架”不少初学者会把 MCP 理解成一个 SDK 或一个服务框架其实不对。MCPModel Context Protocol的核心是一套 JSON-RPC 风格的消息约定定义了两类角色MCP Host 和 MCP Server。Host 是 Agent 运行时它负责收集用户的意图按需调用工具Server 是被动的能力提供者它把工具、资源、提示词三种能力暴露给 Host。实操中你需要理解 MCP 中最关键的三种原语Tools可被模型调用的函数执行后返回结构化结果适合“做一件事”比如查天气、发邮件、写文件Resources可被读取的数据类似 RESTful GET 接口适合“取数据”比如读一个配置文件、拉一份报表Prompts可被复用的提示信息模板适合“引导模型”比如一个固定的排障流程的前置指引。我在第一版实现时只注册了 Tools后来发现很多只读查询场景用 Resources 更合理——模型可以自主决定“读哪个数据”而不是硬编码一个工具调用。两者虽然都能实现类似效果但 Resources 更轻量不占用工具选择的复杂度。3.2 用 30 行代码实现一个最小 MCP Server为了直观理解我当时用 Python 写了一个最小化的 MCP Server只暴露一个读取服务器负载的工具。这里贴一下核心代码关键点我都写在注释里from mcp.server import Server from mcp.server.stdio import stdio_server from mcp.types import Tool, TextContent app Server(metrics-server) app.list_tools() async def list_tools() - list[Tool]: return [ Tool( nameget_cpu_load, description获取当前服务器的 CPU 负载百分比, inputSchema{ type: object, properties: { mode: { type: string, enum: [1m, 5m], description: 负载统计周期默认 1m } } } ) ] app.call_tool() async def call_tool(name: str, arguments: dict) - list[TextContent]: if name get_cpu_load: # 实际场景这里可以对接 psutil 或 /proc/loadavg load_value 12.5 return [TextContent(typetext, textf当前CPU负载: {load_value}%)] raise ValueError(f未知工具: {name}) async def main(): async with stdio_server() as (read_stream, write_stream): await app.run(read_stream, write_stream) if __name__ __main__: import asyncio asyncio.run(main())注意MCP 的 stdio 传输模式适合本地开发调试Host 和 Server 在同一台机器上通过标准输入输出通信。如果要部署到远程需要切换到 Streamable HTTP 传输模式并处理鉴权、心跳、流式响应等额外逻辑。很多第一次接触 MCP 的人会忽略inputSchema的重要性。这个 schema 不是写给人看的而是给模型的。模型需要根据这个 schema 决定传什么参数。schema 写得越精确模型调用越不容易出错。尤其要注意字段的description部分实测表明它比字段名更能影响模型的理解这也是最容易优化的一环。3.3 Host 端接入的两种方式和参数选择MCP Host 端接入时常见的做法有两种SDK 直连在 Agent 的代码里直接注册 MCP Server用mcp客户端库建立会话配置文件加载通过mcp.json这类配置文件声明多个 ServerHost 启动时自动加载。我推荐生产环境用方案二。把 Server 的地址、传输模式、鉴权信息放到配置中心里运维人员不需要改 Agent 代码就能增减工具。这相当于把工具接入变成了“配置驱动的热插拔”。在超时和并发参数的选择上我的经验值是单次工具调用超时设为 15-30 秒长任务用异步任务机制而不是同步等待Host 到 Server 的连接数起步设 5-10 个长连接再根据并发压测结果调整。不要盲目开高并发很多 MCP Server 是 IO 密集型的连接数多了反而容易触发背压问题。3.4 MCP 与安全边界最后必须强调 MCP 的安全边界问题。MCP Server 是直接暴露给模型的“手和脚”模型的幻觉如果落到工具调用上后果可能很严重。所以我在每个 Server 上做了三层防护输入层校验所有参数都必须过 JSON Schema 校验和类型白名单权限层隔离Host 只给 Server 分配最小权限的凭证比如只读的数据库账户、限流的 API Key审计层记录每次工具调用的参数和结果都写入审计日志方便回溯异常行为。此外涉及写操作的工具比如发邮件、改数据库、执行 Shell建议在 Server 端设置人工确认回调。模型可以“建议”执行但真正落盘必须经过人工确认。否则一旦用户的提示词被注入Agent 可能做出非预期的高危操作。4. A2A 互操作让 Agent 之间像服务一样对接4.1 A2A 的诞生背景和核心特征A2AAgent-to-Agent协议是在 MCP 已经解决“Agent 调用工具”之后出现的互补协议解决的是另一个问题AgentA 需要调用 AgentB 的专业能力怎么办在没有 A2A 之前常见的做法是把 AgentB 封装成 RESTful API再把它注册成 AgentA 的一个工具。这种方案能用但有几个问题无法表达 Agent 的意图和能力边界没有任务状态的交互定义回传结果的方式也要自己造轮子。A2A 的思路是把每个 Agent 看成一个“自带能力描述的 HTTP 服务”通过标准化的 JSON 格式对外暴露自己是谁、能干什么、如何连接。核心组件包括Agent Card一个 JSON 文件描述 Agent 的名称、描述、能力、通信端点Task 对象定义一次任务请求的完整生命周期包括输入、状态、输出Message 与 Artifact任务过程中的消息流和最终交付物。用类比来说MCP 相当于给 Agent 装了各种 USB 外设A2A 则让 Agent 之间有了通用的“网络协议”可以相互发现、握手、分包、回传。没有 A2A 时多 Agent 协作靠“点对点硬编码”有了 A2A协作变成了“服务发现 标准通信”。4.2 Agent Card 的推荐最小配置Agent Card 是 A2A 互操作的起点相当于服务的“自我介绍”。我先放一个实测过的最小可运行配置字段解释放在表格里{ name: data-analyst-agent, description: 负责数据分析、图表生成与指标解读的专用Agent, url: https://agent.example.com/a2a, version: 1.0.0, capabilities: { skills: [data_analysis, chart_generation, report_writing], maxConcurrentTasks: 3 }, defaultInputModes: [text], defaultOutputModes: [text, json], security: { authentication: { schemes: [bearer], credentials: env:A2A_API_TOKEN } } }字段作用我的建议nameAgent 唯一标识用语义化名称方便其他 Agent 理解description能力概述要写得像“招聘 JD”能让他人判断何时调用你urlA2A 通信端点必须是外网可访问的 HTTPS 地址内网需借助网关capabilities.skills能力标签要与下文 Skills 体系对应便于路由security鉴权配置生产环境绝不能用无鉴权方案至少要 bearer token这里有一个容易踩坑的点description不是写给人看的是写给“其他 Agent 的模型”看的。它直接影响下游 Agent 会不会把这个 Agent 纳入自己的工具选择范围。写得含糊这个 Agent 基本不会被调用到。我初期写的是“提供数据分析功能”后来改成“当用户需要分析CSV、Excel或数据库指标并生成可视化图表时调用”调用率明显上升。4.3 实战中如何暴露一个 Agent 为 A2A 端点在项目里把 Agent 暴露成 A2A 端点核心是三步在 Agent 外层包一个 A2A 兼容的 HTTP 服务接收POST请求请求体里的task对象解析出来后交给内部 Agent 处理轮询或回调方式返回任务状态和最终结果。如果 Agent 是异步执行的长任务我建议用“任务创建 状态查询”的模式客户端先POST /task拿到taskId再定期GET /task/{id}获取状态。不要尝试在一个请求里同步等待长任务完成否则整个集群的吞吐都会被拖垮。另一个容易被忽略的是callback机制。A2A 的 spec 允许 Server 端主动向 Client 推送任务状态变更。如果你实现了回调Client 就不需要轮询。但回调 URL 的接收方也要是公网可访问的服务否则回调消息发不出去。团队内部部署时这个回调地址往往是内网 IP需要在网关层做映射容易漏配置。4.4 A2A 和 MCP 的配合方式在实际架构里A2A 和 MCP 并不是互斥的而是前后串联的一个 Agent 在收到 A2A 任务请求后内部可能再用 MCP 去调用底层工具。比如数据分析 Agent 接到“生成上周销售报表”的任务通过 A2A 路由到这个 Agent这个 Agent 内部再用 MCP 调用数据库查询工具、图表生成工具。所以布线方式是“外部通信走 A2A内部工具走 MCP” —— 这是最清晰的分层。我在初期架构里犯过一个错试图把所有功能都做成 MCP 工具然后让调度 Agent 直接调用。结果工具越来越多每个 A2A Agent 变得像一个空的壳子价值没有体现出来。后来调整思路MCP 负责“原子操作”A2A 负责“复合服务”Skills 负责“标准流程”三层职责立刻清晰了。5. Skills 的沉淀与复用能力不是写在提示词里的5.1 Skill 到底是什么Skills 是这四个概念里最容易被低估、也最容易被误解的一个。很多人以为 Skills 就是一段精心编写的 Prompt 模板真正用起来才发现远不止如此。我理解的 Skill 是一个“最小可复用能力单元”它要包含四部分触发条件、执行步骤、输出规范、边界约束。触发条件决定“什么情况下该用这个 Skill”执行步骤是一套有序的操作流程可能包含多个工具调用和模型推理输出规范定义了结果的格式方便下游程序处理边界约束则限定适用范围防止 Skill 被用到不合适的地方。举个例子一个“SQL 调优” Skill 的触发条件是“用户给出了一个 SQL 查询语句且对执行效率不满意”执行步骤通常包括解析 SQL 计划、识别全表扫描、建议索引、生成优化版本、对比两次执行计划。它不只是“请帮我优化 SQL”这句话而是把调优的整个方法论封装进了可执行流程。5.2 如何设计一个可扩展的 Skills 目录在项目里我把 Skills 统一放在一个skills/目录下每个 Skill 占一个子目录用SKILL.md描述元信息scripts/放可执行脚本或提示词模板。规范的目录结构如下skills/ ├──> DeepAgents+MCP+A2A+Skills：超级多智能体集群架构实战解析
1. 这门课到底在解决什么问题这几年做 Agent 开发的人应该都有一个共同的感受单机单 Agent 的玩法已经快到头了。无论你用的是 Claude、GPT 还是本地模型单个 Agent 再聪明它也就是一个“能干活但只能干自己那份活”的个体。一旦遇到跨系统联动、多角色协作、工具权限隔离、能力复用这些场景光靠一个 Agent 加一套 Function Call根本撑不住。这个项目的标题——DeepAgents MCP A2A Skills 超级多智能体——就是把这一代 Agent 开发的核心拼图凑齐了。它本质上讲的是四层东西DeepAgents 是编排骨架MCP 是让 Agent 能调用外部工具的统一协议A2A 是让 Agent 之间能互相通信的协作协议Skills 则是把一些可复用的能力沉淀成可加载的技能包。四者合起来构成一个不仅能单打独斗、还能组队作战的多智能体集群。我看过很多开发者卡在同一个地方明明思路都有模型也能返回正确意图但一跑到真实环境就垮了。要么是工具越加越多每个 Agent 的上下文被塞爆要么是各种 API 对接方式五花八门维护成本远超收益要么是做完了多个 Agent却发现它们之间的通信要靠手工传参。这不是模型能力的问题是缺少一套规范的架构设计。这门课的价值就在于把上面四个概念串起来真正落地到一套可以跑起来的集群架构里。对于还在用单 Agent 做原型、想升级到多 Agent 生产环境的团队或者刚接触 Agent 开发、想搞清楚 MCP 和 A2A 到底是什么关系的新手这个项目能帮你少走很多弯路。下面的内容我会按照“编排、互通、扩展”这条主线拆解这套技术栈的核心思路、关键实现、以及我在实际动手过程中踩过的坑。2. 整体架构拆解为什么是这四个东西组合在一起2.1 从单体 Agent 到 Agent 集群的演化逻辑要理解这套技术栈就得先理解 Agent 架构的演化路径。第一代 Agent 基本就是个“大模型 工具调用”的直筒子用户提问模型决定要不要调用某个工具工具返回结果模型组织答案。这个模式在单场景、少工具的情况下是可行的但一旦工具数量超过几十个模型做工具选择的准确率就会明显下降每次调用还要把大量工具描述塞进上下文token 消耗感人。第二代演化是“Agent 工作流引擎”。比如 LangGraph 那种带状态机的编排方式——把任务拆成节点每个节点是一个 Agent 或工具节点之间用边连接通过图执行来控制流程。这种方案解决了一部分“谁先谁后”的问题但仍然偏中心化工作流的编排逻辑是写死的Agent 本身没有太多自主决策空间。到了第三代就是这套方案的主场多个智能 Agent 组成一个松耦合的集群。DeepAgents 负责调度和编排MCP 把外部工具和内部能力统一成标准接口A2A 让集群内的 Agent 可以像服务一样互相发现和调用Skills 则允许把常用能力打包成即插即用的模块。这个组合不再假设所有能力都在同一个 Agent 里而是假设一个集群里每个 Agent 各有专长彼此可以通过标准协议协作。这是从“单个全能选手”到“一个各司其职的团队”的架构转变。2.2 四层分工编排层、工具层、通信层、能力层我习惯把这套技术栈分成四个层次来看这样更容易理解各自承担的角色层次对应技术解决的问题生活化类比编排层DeepAgents谁来调度、按什么顺序调度、任务如何分配项目总指挥工具层MCPAgent 如何标准化地调用外部工具和数据USB 统一接口通信层A2AAgent 之间如何发现对方、如何传递任务和结果团队内部的对讲机能力层Skills如何把领域知识和方法沉淀为可复用模块员工培训手册分开看都很简单但真正关键的是怎么把它们组合起来。比如MCP 和 A2A 容易被混淆MCP 解决的是 Agent 访问工具的问题方向是“Agent 向下接入系统”A2A 解决的是 Agent 之间互访的问题方向是“Agent 横向连接 Agent”。Skills 则不是独立的网络协议它更像是知识和流程的封装单位既可以挂在 MCP 工具上也可以挂在 A2A 服务能力上。2.3 选这套组合而不是其他方案的理由在最初设计架构时我也对比过另一条路线直接用 Message Queue JSON Schema 自研一套 Agent 通信协议再加一个中心化调度器。后来放弃的原因有三个。第一自研协议的兼容成本太高。AGENTS即 A2A 前身协议和 MCP 已经是一线厂商在推的开放标准社区生态、SDK、调试工具都相对成熟。如果自己定义协议就意味着每一个接入方都要按你的约定来写代码而用开放标准等于直接获得了跨厂商的互操作能力。第二纯中心化调度会把编排逻辑变成一个大泥球。DeepAgents 这类编排框架的调度模型是“协商式”的——不是所有任务都由一个中心节点拍板而是 Agent 之间可以互相请求、拒绝、转派这在任务边界模糊的场景下比死板的流程引擎灵活得多。第三Skills 的价值被严重低估。很多人觉得 Skill 就是“提示词 几个工具函数”但实际上一个设计良好的 Skill 模块应该包含完整的“触发条件、使用步骤、输出格式、错误处理”四要素。它不是零散的工具而是半个 Agent 的“肌肉记忆”。3. MCP 实操细节让 Agent 真正摸到外部世界3.1 MCP 的本质是“协议”而不是“框架”不少初学者会把 MCP 理解成一个 SDK 或一个服务框架其实不对。MCPModel Context Protocol的核心是一套 JSON-RPC 风格的消息约定定义了两类角色MCP Host 和 MCP Server。Host 是 Agent 运行时它负责收集用户的意图按需调用工具Server 是被动的能力提供者它把工具、资源、提示词三种能力暴露给 Host。实操中你需要理解 MCP 中最关键的三种原语Tools可被模型调用的函数执行后返回结构化结果适合“做一件事”比如查天气、发邮件、写文件Resources可被读取的数据类似 RESTful GET 接口适合“取数据”比如读一个配置文件、拉一份报表Prompts可被复用的提示信息模板适合“引导模型”比如一个固定的排障流程的前置指引。我在第一版实现时只注册了 Tools后来发现很多只读查询场景用 Resources 更合理——模型可以自主决定“读哪个数据”而不是硬编码一个工具调用。两者虽然都能实现类似效果但 Resources 更轻量不占用工具选择的复杂度。3.2 用 30 行代码实现一个最小 MCP Server为了直观理解我当时用 Python 写了一个最小化的 MCP Server只暴露一个读取服务器负载的工具。这里贴一下核心代码关键点我都写在注释里from mcp.server import Server from mcp.server.stdio import stdio_server from mcp.types import Tool, TextContent app Server(metrics-server) app.list_tools() async def list_tools() - list[Tool]: return [ Tool( nameget_cpu_load, description获取当前服务器的 CPU 负载百分比, inputSchema{ type: object, properties: { mode: { type: string, enum: [1m, 5m], description: 负载统计周期默认 1m } } } ) ] app.call_tool() async def call_tool(name: str, arguments: dict) - list[TextContent]: if name get_cpu_load: # 实际场景这里可以对接 psutil 或 /proc/loadavg load_value 12.5 return [TextContent(typetext, textf当前CPU负载: {load_value}%)] raise ValueError(f未知工具: {name}) async def main(): async with stdio_server() as (read_stream, write_stream): await app.run(read_stream, write_stream) if __name__ __main__: import asyncio asyncio.run(main())注意MCP 的 stdio 传输模式适合本地开发调试Host 和 Server 在同一台机器上通过标准输入输出通信。如果要部署到远程需要切换到 Streamable HTTP 传输模式并处理鉴权、心跳、流式响应等额外逻辑。很多第一次接触 MCP 的人会忽略inputSchema的重要性。这个 schema 不是写给人看的而是给模型的。模型需要根据这个 schema 决定传什么参数。schema 写得越精确模型调用越不容易出错。尤其要注意字段的description部分实测表明它比字段名更能影响模型的理解这也是最容易优化的一环。3.3 Host 端接入的两种方式和参数选择MCP Host 端接入时常见的做法有两种SDK 直连在 Agent 的代码里直接注册 MCP Server用mcp客户端库建立会话配置文件加载通过mcp.json这类配置文件声明多个 ServerHost 启动时自动加载。我推荐生产环境用方案二。把 Server 的地址、传输模式、鉴权信息放到配置中心里运维人员不需要改 Agent 代码就能增减工具。这相当于把工具接入变成了“配置驱动的热插拔”。在超时和并发参数的选择上我的经验值是单次工具调用超时设为 15-30 秒长任务用异步任务机制而不是同步等待Host 到 Server 的连接数起步设 5-10 个长连接再根据并发压测结果调整。不要盲目开高并发很多 MCP Server 是 IO 密集型的连接数多了反而容易触发背压问题。3.4 MCP 与安全边界最后必须强调 MCP 的安全边界问题。MCP Server 是直接暴露给模型的“手和脚”模型的幻觉如果落到工具调用上后果可能很严重。所以我在每个 Server 上做了三层防护输入层校验所有参数都必须过 JSON Schema 校验和类型白名单权限层隔离Host 只给 Server 分配最小权限的凭证比如只读的数据库账户、限流的 API Key审计层记录每次工具调用的参数和结果都写入审计日志方便回溯异常行为。此外涉及写操作的工具比如发邮件、改数据库、执行 Shell建议在 Server 端设置人工确认回调。模型可以“建议”执行但真正落盘必须经过人工确认。否则一旦用户的提示词被注入Agent 可能做出非预期的高危操作。4. A2A 互操作让 Agent 之间像服务一样对接4.1 A2A 的诞生背景和核心特征A2AAgent-to-Agent协议是在 MCP 已经解决“Agent 调用工具”之后出现的互补协议解决的是另一个问题AgentA 需要调用 AgentB 的专业能力怎么办在没有 A2A 之前常见的做法是把 AgentB 封装成 RESTful API再把它注册成 AgentA 的一个工具。这种方案能用但有几个问题无法表达 Agent 的意图和能力边界没有任务状态的交互定义回传结果的方式也要自己造轮子。A2A 的思路是把每个 Agent 看成一个“自带能力描述的 HTTP 服务”通过标准化的 JSON 格式对外暴露自己是谁、能干什么、如何连接。核心组件包括Agent Card一个 JSON 文件描述 Agent 的名称、描述、能力、通信端点Task 对象定义一次任务请求的完整生命周期包括输入、状态、输出Message 与 Artifact任务过程中的消息流和最终交付物。用类比来说MCP 相当于给 Agent 装了各种 USB 外设A2A 则让 Agent 之间有了通用的“网络协议”可以相互发现、握手、分包、回传。没有 A2A 时多 Agent 协作靠“点对点硬编码”有了 A2A协作变成了“服务发现 标准通信”。4.2 Agent Card 的推荐最小配置Agent Card 是 A2A 互操作的起点相当于服务的“自我介绍”。我先放一个实测过的最小可运行配置字段解释放在表格里{ name: data-analyst-agent, description: 负责数据分析、图表生成与指标解读的专用Agent, url: https://agent.example.com/a2a, version: 1.0.0, capabilities: { skills: [data_analysis, chart_generation, report_writing], maxConcurrentTasks: 3 }, defaultInputModes: [text], defaultOutputModes: [text, json], security: { authentication: { schemes: [bearer], credentials: env:A2A_API_TOKEN } } }字段作用我的建议nameAgent 唯一标识用语义化名称方便其他 Agent 理解description能力概述要写得像“招聘 JD”能让他人判断何时调用你urlA2A 通信端点必须是外网可访问的 HTTPS 地址内网需借助网关capabilities.skills能力标签要与下文 Skills 体系对应便于路由security鉴权配置生产环境绝不能用无鉴权方案至少要 bearer token这里有一个容易踩坑的点description不是写给人看的是写给“其他 Agent 的模型”看的。它直接影响下游 Agent 会不会把这个 Agent 纳入自己的工具选择范围。写得含糊这个 Agent 基本不会被调用到。我初期写的是“提供数据分析功能”后来改成“当用户需要分析CSV、Excel或数据库指标并生成可视化图表时调用”调用率明显上升。4.3 实战中如何暴露一个 Agent 为 A2A 端点在项目里把 Agent 暴露成 A2A 端点核心是三步在 Agent 外层包一个 A2A 兼容的 HTTP 服务接收POST请求请求体里的task对象解析出来后交给内部 Agent 处理轮询或回调方式返回任务状态和最终结果。如果 Agent 是异步执行的长任务我建议用“任务创建 状态查询”的模式客户端先POST /task拿到taskId再定期GET /task/{id}获取状态。不要尝试在一个请求里同步等待长任务完成否则整个集群的吞吐都会被拖垮。另一个容易被忽略的是callback机制。A2A 的 spec 允许 Server 端主动向 Client 推送任务状态变更。如果你实现了回调Client 就不需要轮询。但回调 URL 的接收方也要是公网可访问的服务否则回调消息发不出去。团队内部部署时这个回调地址往往是内网 IP需要在网关层做映射容易漏配置。4.4 A2A 和 MCP 的配合方式在实际架构里A2A 和 MCP 并不是互斥的而是前后串联的一个 Agent 在收到 A2A 任务请求后内部可能再用 MCP 去调用底层工具。比如数据分析 Agent 接到“生成上周销售报表”的任务通过 A2A 路由到这个 Agent这个 Agent 内部再用 MCP 调用数据库查询工具、图表生成工具。所以布线方式是“外部通信走 A2A内部工具走 MCP” —— 这是最清晰的分层。我在初期架构里犯过一个错试图把所有功能都做成 MCP 工具然后让调度 Agent 直接调用。结果工具越来越多每个 A2A Agent 变得像一个空的壳子价值没有体现出来。后来调整思路MCP 负责“原子操作”A2A 负责“复合服务”Skills 负责“标准流程”三层职责立刻清晰了。5. Skills 的沉淀与复用能力不是写在提示词里的5.1 Skill 到底是什么Skills 是这四个概念里最容易被低估、也最容易被误解的一个。很多人以为 Skills 就是一段精心编写的 Prompt 模板真正用起来才发现远不止如此。我理解的 Skill 是一个“最小可复用能力单元”它要包含四部分触发条件、执行步骤、输出规范、边界约束。触发条件决定“什么情况下该用这个 Skill”执行步骤是一套有序的操作流程可能包含多个工具调用和模型推理输出规范定义了结果的格式方便下游程序处理边界约束则限定适用范围防止 Skill 被用到不合适的地方。举个例子一个“SQL 调优” Skill 的触发条件是“用户给出了一个 SQL 查询语句且对执行效率不满意”执行步骤通常包括解析 SQL 计划、识别全表扫描、建议索引、生成优化版本、对比两次执行计划。它不只是“请帮我优化 SQL”这句话而是把调优的整个方法论封装进了可执行流程。5.2 如何设计一个可扩展的 Skills 目录在项目里我把 Skills 统一放在一个skills/目录下每个 Skill 占一个子目录用SKILL.md描述元信息scripts/放可执行脚本或提示词模板。规范的目录结构如下skills/ ├──>