前阵子给团队做内部技术分享我把命题定成了“DeepAgentsMCPA2ASkills 超级多智能体”目标很直接用这四套东西搭一个能真正干活、能互相协作、能不断往里面加新能力的 Agent 集群。折腾了一个多月踩了不少坑也把整套架构从 demo 推到了能稳定跑业务的状态。这篇就把我的设计思路、实操记录和排查经验完整捋一遍。先说结论单 Agent 的困境不是模型不够强而是工程结构太散。工具接入每家一套 SDK换个 Agent 就得重写一遍多个 Agent 放一起各干各的没有统一的协作语言想给 Agent 加一个新能力要么改代码要么靠提示词硬塞维护成本越来越高。这套组合拳的意义在于——MCP 管工具接入A2A 管智能体互联Skills 管知识沉淀DeepAgents 管全局编排四层各司其职组合起来才能形成真正可编排、可互通、可扩展的下一代 Agent 集群。这篇文章不是纯概念科普而是从零搭建的完整实操记录适合正在做 Agent 应用的工程师、准备上多智能体平台的架构师以及想搞清楚这几个协议到底怎么配合的学习者。1. 为什么把四个技术栈叠在一起用1.1 拆解“可编排、可互通、可扩展”三个硬指标我在项目里反复被三个问题折磨第一Agent 的能力边界太死每加一个工具就要改一遍 Agent 的调用逻辑第二多个 Agent 之间没有标准对话方式A 调 B 基本靠硬编码接口第三沉淀下来的经验、流程、提示词散落在各处换个环境就失效。“可编排”指的是调度层能像搭积木一样把多个 Agent 串成一条流水线A 做完一步自动交给 B“可互通”指的是不同团队、不同技术栈实现的 Agent 能用同一种协议对话“可扩展”指的是加一个新工具、新技能、新 Agent不需要动老代码。MCP 解决的是 Agent 和工具的插拔问题A2A 解决的是 Agent 和 Agent 的对话问题Skills 解决的是知识复用问题DeepAgents 解决的是前面三者的组织和调度问题。四者叠加正好覆盖了多智能体系统从底层到顶层的所有需求。1.2 四层架构的分工与协作关系我用一张表格把这四个技术栈的定位先讲清楚方便后续理解技术栈定位解决的核心问题类比MCP工具接入层Agent 如何标准化调用外部工具、API、数据源USB-C 接口Skills知识能力层Agent 如何获得“怎么做某件事”的方法论岗位培训手册A2A智能体互联层异构 Agent 之间如何发现、通信、协作企业间的合同和会话协议DeepAgents编排调度层如何把多个 Agent 组织成一条可监控的工作流项目经理我实际组网的时候顺序是反着搭的先接 MCP 让 Agent 有手再装 Skills 让 Agent 有脑然后通 A2A 让 Agent 能彼此说话最后用 DeepAgents 做编排把这些串起来。1.3 和“全栈自研调度框架”相比这套方案赢在哪说实话我也自己写过 Agent 调度框架核心就是一张函数注册表加一个消息队列搞定过一阵子。但问题很快就暴露了团队里每加一个 Agent 就要约好一套消息格式每个工具都要写一遍适配器跨项目复用基本为零。采用 MCP、A2A 这类开放标准后最大的收益是生态复用。比如官方市场里已经有不少现成的 MCP Server数据库的、浏览器的、设计工具的都有接上就能用A2A 让不同框架实现的 Agent 可以互相发现和委托任务Skills 目录下沉淀了大量现成的技能包不用自己从头写提示词。这不光是省代码的问题而是把团队从“每做一个 Agent 都要做一遍全栈”的泥潭里拉出来让注意力回到业务本身。2. 先把四个组件逐个吃透它们到底干了什么2.1 MCP 不是又一个协议它是 Agent 的工具插槽MCP 全称是 Model Context Protocol一个开放标准定义了大模型应用如何发现和调用外部工具。我第一次听到时也觉得索然无味直到自己接了一个 PostgreSQL 数据源后才发现这套协议把“Agent 每次接入新工具”这件事从改代码变成了改配置。MCP 的架构是 Host、Client、Server 三层。Host 是 Agent 本身Client 负责和 Server 建立连接Server 负责暴露工具。核心原语有三类Tools 是 Agent 可以执行的函数Resources 是只读的数据资源Prompts 是预定义的提示词模板。对普通开发者来说最高频的操作是跑一个 MCP Server把连接信息配进 Agent 的客户端配置里然后 Agent 就能像本地函数一样调用远程工具。我在项目里接过的有 PostgreSQL 数据库、GitHub、Figma、浏览器自动化工具全部走的同一套机制这就是 MCP 的魅力。类比一下它就是工具侧的 USB-C一个接口通吃所有外设。2.2 Skills 是把“怎么做”教给 Agent 的最小知识单元Skills 是另一维度的事。MCP 管的是“Agent 能用什么工具”Skills 管的是“Agent 会用什么方法做事”。它本质上是把一段可复用的方法论——包括提示词指令、模板、脚本——打包成一个结构化文件夹里面通常包含一个 SKILL.md 描述文件、若干参考资源和可选脚本。我用一个实际例子说明写论文技能它不只是给 Agent 一个“帮我写论文”的提示而是一整套流程——先让你确认主题、再产出大纲、逐章撰写、统一润色、校验引用格式。每个环节的指令、模板、注意事项都写在 SKILL.md 里。Agent 加载这个技能后就相当于经过了一次完整的岗位培训。Skills 和 MCP 的边界值得强调MCP 暴露的是“工具函数”Skills 暴露的是“做事的流程”。两者经常搭配使用比如一个 Skills 里负责流程编排其中某一步调用 MCP 工具去查询数据库。2.3 A2A 让不同的 Agent 说同一种语言A2A 全称是 Agent2Agent它填补的空白是智能体之间的互联。MCP 解决的是单体 Agent 内部零件互通的问题A2A 解决的是多个 Agent 之间的业务协作问题。A2A 基于 JSON-RPC 2.0核心概念是 Agent Card——每个 Agent 发布自己的能力描述其他 Agent 通过 Agent Card 发现它能做什么然后发起任务委托。整个流程包括能力发现、任务创建、任务协商、状态更新、结果交付。我自己的理解是MCP 是 Agent 的“手”A2A 是 Agent 之间的“商务谈判协议”。有了 A2A一个用 Python 写的分析 Agent 可以顺畅地委托任务给一个用 TypeScript 写的前端生成 Agent两边不需要共享任何代码。2.4 DeepAgents 负责把前面三样编排成集群DeepAgents 是我的编排核心。所谓编排就是把“多个 Agent、多个工具、多个技能”组织成一条可执行、可监控、可恢复的工作流。它的工作方式类似一个业务流程引擎定义节点、连接依赖、设定输入输出、监控运行状态。每个节点可以是一个 Agent、一个 MCP 工具调用、一个 Skills 执行单元节点之间有先后依赖和数据流向运行过程中记录日志、上报状态、支持失败重试。之前我给团队演示过一个案例一个供应链分析任务拆成了数据采集 Agent、库存分析 Agent、报告生成 Agent 三个节点前一个节点的输出自动成为后一个节点的输入全程没有任何人工干预。这就是 DeepAgents 的编排价值。3. 实操记录从零搭建四层 Agent 集群3.1 先搭 MCP 接入层5 分钟跑起来一个 PostgreSQL 数据服务MCP 是这套架构的地基先落地它。以 Python 环境为例最常用的是fastmcp这个库它帮你封装了协议细节可以专注写工具函数。下面是我项目里一个最小可用的 MCP Server它的作用是查数据库from fastmcp import FastMCP import psycopg2 mcp FastMCP(postgres-service) mcp.tool() def query_stock(product_id: str, days: int 30) - str: 查询指定商品的近 N 天库存数据 conn psycopg2.connect( hostlocalhost, port5432, dbnamebusiness, userreader, passwordxxx ) cur conn.cursor() cur.execute( SELECT date, stock_qty FROM stock_log WHERE product_id%s ORDER BY date DESC LIMIT %s, (product_id, days) ) rows cur.fetchall() conn.close() return \n.join([f{r[0]}:{r[1]} for r in rows]) if __name__ __main__: mcp.run(transportstreamable-http)这个服务启动后监听一个 HTTP 端口暴露一个query_stock工具。关键点有两个一是mcp.tool()装饰器自动帮你做了协议包装二是每个工具函数必须有清晰的 docstring这会被用于生成给 Agent 看的工具描述直接影响 Agent 是否在正确场景下调用它。然后配置客户端。比如在 Claude Desktop 或 Cursor 中需要往配置文件里加 MCP Server 信息{ mcpServers: { postgres-service: { command: python, args: [path/to/mcp_server.py], env: {} } } }配置完成后重启客户端在对话里问“查一下商品 P1001 最近 7 天的库存”Agent 会自动匹配到query_stock工具并返回结果。这一步走通后所有的外部服务统一接入方式就确定了。3.2 再装 Skills让 Agent 学会搜索和读数据库Skills 的安装比想象中简单本质是把一个技能文件夹放到 Agent 能扫描到的目录然后在对话里用技能名触发。下面是一个搜索技能的目录结构skills/ web-research/ SKILL.md reference/ search_tips.md其中 SKILL.md 的关键结构是这样的--- name: web-research description: 使用搜索工具进行多轮网络调研并产出综述报告 --- ## 执行流程 1. 拆解用户问题提取 3-5 个搜索关键词 2. 使用 browser-use MCP 工具执行搜索 3. 对前 10 条结果逐条阅读并记录核心信息 4. 交叉验证信息标注来源 5. 输出带引用来源的综述 ## 注意事项 - 不要只依赖第一个搜索页结果 - 优先采信官方来源与一手数据 - 若搜索失败必须更换关键词重试我个人的经验是一个好 Skills 的灵魂是流程清晰、边界明确、可验证。描述里不要写空话比如“高效地进行搜索”而要把每一步具体动作写出来Agent 才能稳定复现。安装后直接在对话中输入“使用 web-research 技能调研 MCP 和 A2A 在工业界的落地现状”Agent 就会自动进入预设的调研流程而不是凭感觉自由发挥。这种稳定性的提升非常明显尤其是面对重复性任务。3.3 打通 A2A让两个异构 Agent 互相派活A2A 的配置稍微复杂核心是企业级标准。我推荐用官方 SDK 快速搭建两个实验 Agent验证互通后再并入业务。第一个 Agent 定义一个 Agent CardJSON声明自己能做什么{ name: data-analysis-agent, description: 负责数据清洗、统计分析和可视化, skills: [data_processing, statistics], endpoints: [ { path: https://myagent.example.com/a2a, protocol: a2a, version: 1.0 } ] }第二个 Agent 运行时通过 A2A 协议向第一个 Agent 发起任务请求。核心请求格式如下{ jsonrpc: 2.0, id: 1, method: tasks/send, params: { id: task-001, message: { role: user, parts: [ { text: 请分析这份 CSV 数据的趋势并生成一张趋势图 } ] } } }第一个 Agent 收到后返回一个任务状态等执行完成后通过tasks/get拉取最终结果。整个过程就是 A2A 的最小闭环。我踩过的坑是Agent Card 里的name和description一定要写清楚。因为另一个 Agent 会发现你的 Agent Card并根据描述判断是否适合委托任务。描述含糊对方 Agent 就不会把任务派给你。这就像简历写不好面试机会就没有。3.4 DeepAgents 编排层把团队协作变成代码DeepAgents 是最后一步把 MCP、Skills、A2A 全部串起来的编排层。我用一段伪代码说明它的工作方式展示一个多 Agent 协作流程pipeline deepagents.Pipeline(name供应链异常分析流程) pipeline.add_node( name采集库存数据, actionmcp:postgres-service#query_stock, params{product_id: P1001, days: 30} ) pipeline.add_node( name调用数据分析Agent, actiona2a:data-analysis-agent#send_task, params{message: 分析上方库存数据找出异常波动点} ) pipeline.add_node( name生成预警报告, actionskill:report-generation, depends_on[采集库存数据, 调用数据分析Agent] ) pipeline.run()三个节点的依赖关系很清晰前两个节点完成后第三个节点才启动。实际运行中DeepAgents 会记录每一步的输入输出、耗时、状态失败时可以指定重试策略和降级方案。我给团队推荐这套编排方式的核心理由是工作流定义和业务代码分离。调整流程只需要改管线配置不需要改 Agent 内部逻辑非常适合快速迭代。4. 真实项目踩坑实录认证、上下文、兼容性与生产落地4.1 认证授权是第一个拦路虎Figma、蓝湖类 MCP 的 token 问题很多 MCP Server 需要调用第三方 API而这些 API 几乎都要求 OAuth 或 token 认证。比如前阵子接入 Figma 的 MCP我的 Codex 客户端怎么都找不到 MCP后来排查才发现根本不是配置问题——是认证 token 过期了。MCP Server 的认证信息一般通过两种方式传递配置 JSON 里的env字段注入环境变量或写在 MCP Server 的启动脚本里。建议把所有敏感凭证放进环境变量不要硬编码在源码里。还有一点Codex 等客户端的 MCP 配置更新后不一定热加载经常要重启会话才能识别新增的 MCP Server。“找不到 MCP”的时候优先查三件事——配置文件路径是否正确、MCP Server 进程是否真的起来了、认证信息是否有效。4.2 上下文窗口与工具幻觉为什么 Agent 会乱调用MCP 工具接入多了以后你会发现一个新的问题Agent 面对十几个工具分析和选择的时间明显变长偶尔还会选错工具也就是工具幻觉。一次它把查询库存的工具用来查订单状态结果可想而知。原因之一是工具的 description 写得太模糊模型无法区分边界。我给团队的硬性要求是每个工具函数必须有动词开头的描述、明确的输入参数说明、以及典型的调用场景提示。原因之二是上下文窗口有限。MCP Server 返回了大量数据但上下文装不下Agent 就会选择性忽略或干脆编造。解决办法是在 MCP Server 里做数据聚合和采样只返回精简结果。比如上面那个库存查询我在 SQL 里就做了LIMIT控制防止一次性拉回几千行数据。4.3 选型对比browser-use MCP 和 Playwright MCP 怎么选、Skills 去哪找问过我最多的问题是“browser-use MCP 和 Playwright MCP 有什么区别”。两者都是浏览器自动化工具但设计思路不同——browser-use MCP 更偏向 AI 驱动的自动化适合让 Agent 自主探索网页但执行效率和稳定性相对低Playwright MCP 更像传统的自动化测试工具精确控制浏览器行为和断言执行更稳但需要你明确定义每一步操作。我现在的经验是需要让 Agent “看懂”网页并自主决策时选 browser-use MCP需要固定流程的网页操作时选 Playwright MCP。如果追求生产稳定性后者更靠谱。关于 Skills 去哪找官方市场和 GitHub 上有不少高质量技能包包括论文写作、网页调研、数据分析等。注意选择 star 高、更新活跃的项目同时检查 SKILL.md 的流程设计是否清晰。有些技能包其实就是把一堆提示词塞进去质量很低对 Agent 的能力提升很有限。我推荐的筛选标准是看它有没有把任务拆成明确的步骤有没有定义输入输出格式有没有异常处理机制。4.4 生产落地从 demo 到稳定运行的几个关键节点最后聊一下把整套集群从实验环境推向生产会遇到的问题。稳定性是第一位的MCP Server 进程可能因为内存泄漏挂掉、网络抖动导致 A2A 消息丢失、Skills 执行超时——这些问题一定要在架构上预留处理空间。我的做法是用supervisor守护 MCP Server 进程设置自动重启A2A 消息增加超时重试机制Skills 执行控制在合理时间窗口内。监控方面因为涉及多个节点日志分散在各处排查问题非常痛苦。我搭了一套集中日志采集把编排层、每个 Agent、每个 MCP Server 的运行日志统一打到 ELK再配置关键指标告警。实战下来这个投入的收益远超预期。企业系统集成这块我们尝试把一个开源后台管理框架和 MCP 结合做法是把 MCP Server 作为独立服务部署然后在后台系统的配置中心加一个 MCP 配置项——只要实现了标准协议两边不需要定制开发就能打通。这个思路已经在内部跑通了审批流、报表、数据看板都能通过 MCP 一步接入。最后再分享一个我在备课过程中悟出来的经验这些技术栈本身不难真正的难点在边界把控——什么时候用 MCP、什么时候用 Skills、什么时候用 A2A、什么时候用编排层边界清晰了架构才不会乱。我见过很多团队把 Skills 当成 MCP 用或者用 A2A 做内部进程通信到最后就是一团乱麻。判断标准其实很简单工具调用走 MCP方法复用走 Skills智能体协作走 A2A流程组织走 DeepAgents。把这句口诀刻在脑子里你们的集群架构大概率不会跑偏。
MCP+A2A+Skills+DeepAgents：多智能体集群从零搭建全记录
前阵子给团队做内部技术分享我把命题定成了“DeepAgentsMCPA2ASkills 超级多智能体”目标很直接用这四套东西搭一个能真正干活、能互相协作、能不断往里面加新能力的 Agent 集群。折腾了一个多月踩了不少坑也把整套架构从 demo 推到了能稳定跑业务的状态。这篇就把我的设计思路、实操记录和排查经验完整捋一遍。先说结论单 Agent 的困境不是模型不够强而是工程结构太散。工具接入每家一套 SDK换个 Agent 就得重写一遍多个 Agent 放一起各干各的没有统一的协作语言想给 Agent 加一个新能力要么改代码要么靠提示词硬塞维护成本越来越高。这套组合拳的意义在于——MCP 管工具接入A2A 管智能体互联Skills 管知识沉淀DeepAgents 管全局编排四层各司其职组合起来才能形成真正可编排、可互通、可扩展的下一代 Agent 集群。这篇文章不是纯概念科普而是从零搭建的完整实操记录适合正在做 Agent 应用的工程师、准备上多智能体平台的架构师以及想搞清楚这几个协议到底怎么配合的学习者。1. 为什么把四个技术栈叠在一起用1.1 拆解“可编排、可互通、可扩展”三个硬指标我在项目里反复被三个问题折磨第一Agent 的能力边界太死每加一个工具就要改一遍 Agent 的调用逻辑第二多个 Agent 之间没有标准对话方式A 调 B 基本靠硬编码接口第三沉淀下来的经验、流程、提示词散落在各处换个环境就失效。“可编排”指的是调度层能像搭积木一样把多个 Agent 串成一条流水线A 做完一步自动交给 B“可互通”指的是不同团队、不同技术栈实现的 Agent 能用同一种协议对话“可扩展”指的是加一个新工具、新技能、新 Agent不需要动老代码。MCP 解决的是 Agent 和工具的插拔问题A2A 解决的是 Agent 和 Agent 的对话问题Skills 解决的是知识复用问题DeepAgents 解决的是前面三者的组织和调度问题。四者叠加正好覆盖了多智能体系统从底层到顶层的所有需求。1.2 四层架构的分工与协作关系我用一张表格把这四个技术栈的定位先讲清楚方便后续理解技术栈定位解决的核心问题类比MCP工具接入层Agent 如何标准化调用外部工具、API、数据源USB-C 接口Skills知识能力层Agent 如何获得“怎么做某件事”的方法论岗位培训手册A2A智能体互联层异构 Agent 之间如何发现、通信、协作企业间的合同和会话协议DeepAgents编排调度层如何把多个 Agent 组织成一条可监控的工作流项目经理我实际组网的时候顺序是反着搭的先接 MCP 让 Agent 有手再装 Skills 让 Agent 有脑然后通 A2A 让 Agent 能彼此说话最后用 DeepAgents 做编排把这些串起来。1.3 和“全栈自研调度框架”相比这套方案赢在哪说实话我也自己写过 Agent 调度框架核心就是一张函数注册表加一个消息队列搞定过一阵子。但问题很快就暴露了团队里每加一个 Agent 就要约好一套消息格式每个工具都要写一遍适配器跨项目复用基本为零。采用 MCP、A2A 这类开放标准后最大的收益是生态复用。比如官方市场里已经有不少现成的 MCP Server数据库的、浏览器的、设计工具的都有接上就能用A2A 让不同框架实现的 Agent 可以互相发现和委托任务Skills 目录下沉淀了大量现成的技能包不用自己从头写提示词。这不光是省代码的问题而是把团队从“每做一个 Agent 都要做一遍全栈”的泥潭里拉出来让注意力回到业务本身。2. 先把四个组件逐个吃透它们到底干了什么2.1 MCP 不是又一个协议它是 Agent 的工具插槽MCP 全称是 Model Context Protocol一个开放标准定义了大模型应用如何发现和调用外部工具。我第一次听到时也觉得索然无味直到自己接了一个 PostgreSQL 数据源后才发现这套协议把“Agent 每次接入新工具”这件事从改代码变成了改配置。MCP 的架构是 Host、Client、Server 三层。Host 是 Agent 本身Client 负责和 Server 建立连接Server 负责暴露工具。核心原语有三类Tools 是 Agent 可以执行的函数Resources 是只读的数据资源Prompts 是预定义的提示词模板。对普通开发者来说最高频的操作是跑一个 MCP Server把连接信息配进 Agent 的客户端配置里然后 Agent 就能像本地函数一样调用远程工具。我在项目里接过的有 PostgreSQL 数据库、GitHub、Figma、浏览器自动化工具全部走的同一套机制这就是 MCP 的魅力。类比一下它就是工具侧的 USB-C一个接口通吃所有外设。2.2 Skills 是把“怎么做”教给 Agent 的最小知识单元Skills 是另一维度的事。MCP 管的是“Agent 能用什么工具”Skills 管的是“Agent 会用什么方法做事”。它本质上是把一段可复用的方法论——包括提示词指令、模板、脚本——打包成一个结构化文件夹里面通常包含一个 SKILL.md 描述文件、若干参考资源和可选脚本。我用一个实际例子说明写论文技能它不只是给 Agent 一个“帮我写论文”的提示而是一整套流程——先让你确认主题、再产出大纲、逐章撰写、统一润色、校验引用格式。每个环节的指令、模板、注意事项都写在 SKILL.md 里。Agent 加载这个技能后就相当于经过了一次完整的岗位培训。Skills 和 MCP 的边界值得强调MCP 暴露的是“工具函数”Skills 暴露的是“做事的流程”。两者经常搭配使用比如一个 Skills 里负责流程编排其中某一步调用 MCP 工具去查询数据库。2.3 A2A 让不同的 Agent 说同一种语言A2A 全称是 Agent2Agent它填补的空白是智能体之间的互联。MCP 解决的是单体 Agent 内部零件互通的问题A2A 解决的是多个 Agent 之间的业务协作问题。A2A 基于 JSON-RPC 2.0核心概念是 Agent Card——每个 Agent 发布自己的能力描述其他 Agent 通过 Agent Card 发现它能做什么然后发起任务委托。整个流程包括能力发现、任务创建、任务协商、状态更新、结果交付。我自己的理解是MCP 是 Agent 的“手”A2A 是 Agent 之间的“商务谈判协议”。有了 A2A一个用 Python 写的分析 Agent 可以顺畅地委托任务给一个用 TypeScript 写的前端生成 Agent两边不需要共享任何代码。2.4 DeepAgents 负责把前面三样编排成集群DeepAgents 是我的编排核心。所谓编排就是把“多个 Agent、多个工具、多个技能”组织成一条可执行、可监控、可恢复的工作流。它的工作方式类似一个业务流程引擎定义节点、连接依赖、设定输入输出、监控运行状态。每个节点可以是一个 Agent、一个 MCP 工具调用、一个 Skills 执行单元节点之间有先后依赖和数据流向运行过程中记录日志、上报状态、支持失败重试。之前我给团队演示过一个案例一个供应链分析任务拆成了数据采集 Agent、库存分析 Agent、报告生成 Agent 三个节点前一个节点的输出自动成为后一个节点的输入全程没有任何人工干预。这就是 DeepAgents 的编排价值。3. 实操记录从零搭建四层 Agent 集群3.1 先搭 MCP 接入层5 分钟跑起来一个 PostgreSQL 数据服务MCP 是这套架构的地基先落地它。以 Python 环境为例最常用的是fastmcp这个库它帮你封装了协议细节可以专注写工具函数。下面是我项目里一个最小可用的 MCP Server它的作用是查数据库from fastmcp import FastMCP import psycopg2 mcp FastMCP(postgres-service) mcp.tool() def query_stock(product_id: str, days: int 30) - str: 查询指定商品的近 N 天库存数据 conn psycopg2.connect( hostlocalhost, port5432, dbnamebusiness, userreader, passwordxxx ) cur conn.cursor() cur.execute( SELECT date, stock_qty FROM stock_log WHERE product_id%s ORDER BY date DESC LIMIT %s, (product_id, days) ) rows cur.fetchall() conn.close() return \n.join([f{r[0]}:{r[1]} for r in rows]) if __name__ __main__: mcp.run(transportstreamable-http)这个服务启动后监听一个 HTTP 端口暴露一个query_stock工具。关键点有两个一是mcp.tool()装饰器自动帮你做了协议包装二是每个工具函数必须有清晰的 docstring这会被用于生成给 Agent 看的工具描述直接影响 Agent 是否在正确场景下调用它。然后配置客户端。比如在 Claude Desktop 或 Cursor 中需要往配置文件里加 MCP Server 信息{ mcpServers: { postgres-service: { command: python, args: [path/to/mcp_server.py], env: {} } } }配置完成后重启客户端在对话里问“查一下商品 P1001 最近 7 天的库存”Agent 会自动匹配到query_stock工具并返回结果。这一步走通后所有的外部服务统一接入方式就确定了。3.2 再装 Skills让 Agent 学会搜索和读数据库Skills 的安装比想象中简单本质是把一个技能文件夹放到 Agent 能扫描到的目录然后在对话里用技能名触发。下面是一个搜索技能的目录结构skills/ web-research/ SKILL.md reference/ search_tips.md其中 SKILL.md 的关键结构是这样的--- name: web-research description: 使用搜索工具进行多轮网络调研并产出综述报告 --- ## 执行流程 1. 拆解用户问题提取 3-5 个搜索关键词 2. 使用 browser-use MCP 工具执行搜索 3. 对前 10 条结果逐条阅读并记录核心信息 4. 交叉验证信息标注来源 5. 输出带引用来源的综述 ## 注意事项 - 不要只依赖第一个搜索页结果 - 优先采信官方来源与一手数据 - 若搜索失败必须更换关键词重试我个人的经验是一个好 Skills 的灵魂是流程清晰、边界明确、可验证。描述里不要写空话比如“高效地进行搜索”而要把每一步具体动作写出来Agent 才能稳定复现。安装后直接在对话中输入“使用 web-research 技能调研 MCP 和 A2A 在工业界的落地现状”Agent 就会自动进入预设的调研流程而不是凭感觉自由发挥。这种稳定性的提升非常明显尤其是面对重复性任务。3.3 打通 A2A让两个异构 Agent 互相派活A2A 的配置稍微复杂核心是企业级标准。我推荐用官方 SDK 快速搭建两个实验 Agent验证互通后再并入业务。第一个 Agent 定义一个 Agent CardJSON声明自己能做什么{ name: data-analysis-agent, description: 负责数据清洗、统计分析和可视化, skills: [data_processing, statistics], endpoints: [ { path: https://myagent.example.com/a2a, protocol: a2a, version: 1.0 } ] }第二个 Agent 运行时通过 A2A 协议向第一个 Agent 发起任务请求。核心请求格式如下{ jsonrpc: 2.0, id: 1, method: tasks/send, params: { id: task-001, message: { role: user, parts: [ { text: 请分析这份 CSV 数据的趋势并生成一张趋势图 } ] } } }第一个 Agent 收到后返回一个任务状态等执行完成后通过tasks/get拉取最终结果。整个过程就是 A2A 的最小闭环。我踩过的坑是Agent Card 里的name和description一定要写清楚。因为另一个 Agent 会发现你的 Agent Card并根据描述判断是否适合委托任务。描述含糊对方 Agent 就不会把任务派给你。这就像简历写不好面试机会就没有。3.4 DeepAgents 编排层把团队协作变成代码DeepAgents 是最后一步把 MCP、Skills、A2A 全部串起来的编排层。我用一段伪代码说明它的工作方式展示一个多 Agent 协作流程pipeline deepagents.Pipeline(name供应链异常分析流程) pipeline.add_node( name采集库存数据, actionmcp:postgres-service#query_stock, params{product_id: P1001, days: 30} ) pipeline.add_node( name调用数据分析Agent, actiona2a:data-analysis-agent#send_task, params{message: 分析上方库存数据找出异常波动点} ) pipeline.add_node( name生成预警报告, actionskill:report-generation, depends_on[采集库存数据, 调用数据分析Agent] ) pipeline.run()三个节点的依赖关系很清晰前两个节点完成后第三个节点才启动。实际运行中DeepAgents 会记录每一步的输入输出、耗时、状态失败时可以指定重试策略和降级方案。我给团队推荐这套编排方式的核心理由是工作流定义和业务代码分离。调整流程只需要改管线配置不需要改 Agent 内部逻辑非常适合快速迭代。4. 真实项目踩坑实录认证、上下文、兼容性与生产落地4.1 认证授权是第一个拦路虎Figma、蓝湖类 MCP 的 token 问题很多 MCP Server 需要调用第三方 API而这些 API 几乎都要求 OAuth 或 token 认证。比如前阵子接入 Figma 的 MCP我的 Codex 客户端怎么都找不到 MCP后来排查才发现根本不是配置问题——是认证 token 过期了。MCP Server 的认证信息一般通过两种方式传递配置 JSON 里的env字段注入环境变量或写在 MCP Server 的启动脚本里。建议把所有敏感凭证放进环境变量不要硬编码在源码里。还有一点Codex 等客户端的 MCP 配置更新后不一定热加载经常要重启会话才能识别新增的 MCP Server。“找不到 MCP”的时候优先查三件事——配置文件路径是否正确、MCP Server 进程是否真的起来了、认证信息是否有效。4.2 上下文窗口与工具幻觉为什么 Agent 会乱调用MCP 工具接入多了以后你会发现一个新的问题Agent 面对十几个工具分析和选择的时间明显变长偶尔还会选错工具也就是工具幻觉。一次它把查询库存的工具用来查订单状态结果可想而知。原因之一是工具的 description 写得太模糊模型无法区分边界。我给团队的硬性要求是每个工具函数必须有动词开头的描述、明确的输入参数说明、以及典型的调用场景提示。原因之二是上下文窗口有限。MCP Server 返回了大量数据但上下文装不下Agent 就会选择性忽略或干脆编造。解决办法是在 MCP Server 里做数据聚合和采样只返回精简结果。比如上面那个库存查询我在 SQL 里就做了LIMIT控制防止一次性拉回几千行数据。4.3 选型对比browser-use MCP 和 Playwright MCP 怎么选、Skills 去哪找问过我最多的问题是“browser-use MCP 和 Playwright MCP 有什么区别”。两者都是浏览器自动化工具但设计思路不同——browser-use MCP 更偏向 AI 驱动的自动化适合让 Agent 自主探索网页但执行效率和稳定性相对低Playwright MCP 更像传统的自动化测试工具精确控制浏览器行为和断言执行更稳但需要你明确定义每一步操作。我现在的经验是需要让 Agent “看懂”网页并自主决策时选 browser-use MCP需要固定流程的网页操作时选 Playwright MCP。如果追求生产稳定性后者更靠谱。关于 Skills 去哪找官方市场和 GitHub 上有不少高质量技能包包括论文写作、网页调研、数据分析等。注意选择 star 高、更新活跃的项目同时检查 SKILL.md 的流程设计是否清晰。有些技能包其实就是把一堆提示词塞进去质量很低对 Agent 的能力提升很有限。我推荐的筛选标准是看它有没有把任务拆成明确的步骤有没有定义输入输出格式有没有异常处理机制。4.4 生产落地从 demo 到稳定运行的几个关键节点最后聊一下把整套集群从实验环境推向生产会遇到的问题。稳定性是第一位的MCP Server 进程可能因为内存泄漏挂掉、网络抖动导致 A2A 消息丢失、Skills 执行超时——这些问题一定要在架构上预留处理空间。我的做法是用supervisor守护 MCP Server 进程设置自动重启A2A 消息增加超时重试机制Skills 执行控制在合理时间窗口内。监控方面因为涉及多个节点日志分散在各处排查问题非常痛苦。我搭了一套集中日志采集把编排层、每个 Agent、每个 MCP Server 的运行日志统一打到 ELK再配置关键指标告警。实战下来这个投入的收益远超预期。企业系统集成这块我们尝试把一个开源后台管理框架和 MCP 结合做法是把 MCP Server 作为独立服务部署然后在后台系统的配置中心加一个 MCP 配置项——只要实现了标准协议两边不需要定制开发就能打通。这个思路已经在内部跑通了审批流、报表、数据看板都能通过 MCP 一步接入。最后再分享一个我在备课过程中悟出来的经验这些技术栈本身不难真正的难点在边界把控——什么时候用 MCP、什么时候用 Skills、什么时候用 A2A、什么时候用编排层边界清晰了架构才不会乱。我见过很多团队把 Skills 当成 MCP 用或者用 A2A 做内部进程通信到最后就是一团乱麻。判断标准其实很简单工具调用走 MCP方法复用走 Skills智能体协作走 A2A流程组织走 DeepAgents。把这句口诀刻在脑子里你们的集群架构大概率不会跑偏。
