去年我做过一个极其愚蠢的架构决策把一个数据分析智能体的工具列表从 3 个一路加到 17 个挂了 6 个 MCP Server、塞了 8 个自定义函数系统 prompt 写得跟一本操作手册一样厚。结果你应该能猜得到——准确率不升反降模型开始自由发挥明明有专用工具不用偏要东拼西凑一次数据库连接失败就能让整条流程全部翻车。后来我痛定思痛把这堆东西全部拆掉重构为一个四个角色组成的 DeepAgents 组织规划、数据、前端、验收再用 MCP、A2A、Skills 把接口和技能全部标准化。系统不但稳定了迭代速度也明显变快。这篇文章就把从单体到组织的超级多智能体工程逻辑完整讲清楚适合正在搞多智能体、AI 工作流自动化或者被单一 Agent 的上下文爆炸折磨的朋友。1. 单体 Agent 的失控现场为什么必须走向组织化1.1 工具塞得越多模型越容易犯糊涂单体 Agent 最典型的问题就是什么都往里塞。我那个失败案例里17 个工具每个都要在上下文里带一份描述和参数 schema平均下来每个占用 150 到 300 token光工具定义就吃掉了四五千 token。别小看这个数字在多轮对话和工具调用循环里模型每次做工具选择都要重新评估所有候选而上下文中关键指令的比例被稀释之后误选率会肉眼可见地上升。我自己的经验数据是同一个模型5 个以内工具时基本稳定几乎不会张冠李戴到 10 个左右开始出现把参数传错、漏用正确工具的情况15 个以上就需要频繁人工纠正这时候整个系统的可靠性已经完全不可接受了。这种情况和真实团队一个道理——一个人同时背钳工、电工、厨师、会计四套操作手册高压力下他大概率会拿错工具而不是更全能。1.2 自己写代码自己验收是伪命题单体 Agent 另一个被忽视的问题是验证环节的独立性。同一个上下文里它既当分析师又当执行者还要当验收员模型天然倾向于认同自己之前的产出。我做个内部 Demo 时测试过让同一个 Agent 写完代码再做 Review它大概率会说看起来没有问题同一个任务拆给另一个独立的 Review Agent却能找出明显的边界条件漏洞和潜在 bug。人尚且不能给自己当裁判模型也一样。这就是为什么组织化必须包含独立的验证角色。复杂任务的本质是规划、执行、验证三个动作的反复循环硬塞在同一个 Agent 里上下文会互相干扰而且没有真正的制衡机制。1.3 组织化其实就是在做三件事拆解、连接、治理把单体拆成组织核心动作只有三个拆解把任务按职责边界切成独立单元每个 Agent 只保留一个领域上下文prompt 短了、注意力集中了、误调用率自然下降。连接既定好接口。工具和数据用 MCP 接Agent 之间互相委托用 A2A领域方法论用 Skills 打包。没有连接规范拆出来的 Agent 就是信息孤岛。治理任务状态机、超时重试、权限边界、全链路追踪。这是单体架构根本不需要、而组织架构必须补齐的东西。从单体到组织的对比我用一张表说明维度单体 AgentDeepAgents 组织上下文全部塞进一个上下文容易被稀释每个角色聚焦自己的上下文按需共享工具边界所有工具对同一模型开放每个 Agent 只挂自己需要的 MCP最小化权限验证机制自写自验缺少独立性独立 Review 角色形成制衡故障影响一个环节失败全流程翻车局部失败可重试、可降级不影响其他角色迭代方式改一处可能影响全局单个 Agent 独立升级接口不变即可拆、连、治是后面所有技术选型的总纲。下面逐个讲 MCP、A2A、Skills 在组织里分别承担什么。2. MCP先把智能体和外部世界之间的USB-C打通2.1 MCP 到底是什么以及三个原语怎么用MCP 全称 Model Context Protocol是一个软件协议。很多人拿 USB-C 来类比我觉得这个类比非常贴切USB-C 不是某个具体的硬件设备而是让鼠标、硬盘、显示器都能通过同一个物理接口接进电脑的标准。MCP 也一样它定义了 AI 应用和外部工具、数据源之间的统一会话协议让任意支持 MCP 的 Agent 都能接上任意实现了 MCP 的服务端。它的架构是典型的三端MCP Host 是 AI 应用本身MCP Client 负责与 Server 通信MCP Server 提供具体能力。真正要理解 MCP重点是它的三个原语Tools可执行的工具Agent 决定调用会产生副作用。比如执行 SQL、发消息、创建工单。Resources可读取的资源一般用 URI 定位让 Agent 按需加载上下文。比如项目文档、数据库 schema、配置文件。Prompts预设好的可复用提示模板类似把常用操作流程固化下来。这里面最容易踩坑的是 Resources 被忽视。很多人接 MCP 时习惯把什么都做成 Tool但静态数据和按需查询的内容更适合做成 Resource。比如数据库表结构它不构成一次操作只是一个需要被模型读取的信息源。我在实际项目里有一个体会把那种喂进去太占 token、不喂又不行的大段背景资料做成 Resource让 Agent 在处理任务时自己去 resource 拉取比硬塞进 system prompt 要强得多。这正是网上一堆人问mcp resource 实战的答案——大部分数据都不需要做成工具按需读取的效率更高。2.2 一个 MCP Server 的最小实现模板FastMCP 这个 Python 包可以非常快地写一个 Server我贴一个实际用过的骨架from fastmcp import FastMCP mcp FastMCP(ops-data) mcp.tool() def query_postgres(sql: str, limit: int 100) - str: 对只读账号执行 SQL 查询自动限制返回条数。 # 这里连数据库强制加 LIMIT避免 Agent 把表拖爆 return str(run_readonly_query(sql[:500], limit)) mcp.resource(schema://orders) def orders_schema() - str: 订单表结构信息Agent 写 SQL 前按需读取。 return get_table_schema(orders) if __name__ __main__: # 本地用 stdio远程服务用 streamable-http mcp.run()注意最后这行mcp.run()默认走 stdio 传输适合 Claude Desktop、IDE 插件这类本地宿主。如果你要做成远程多智能体共享的服务就要换成 streamable HTTP 模式。工具定义里那个 docstring 很重要模型是靠它判断什么时候该调用这个工具的写得越明确误调率越低。2.3 传输方式怎么选以及 Browser Use MCP 和 Playwright MCP 的区别MCP 传输方式目前主流就三种stdioServer 作为本地子进程运行走标准输入输出。安全、简单适合单个开发者自己的环境但没法跨机器。SSEServer 暴露 HTTP 端点支持服务端向客户端推送事件。适合远程部署。streamable HTTPSSE 的升级版支持请求-响应和流式两种模式是目前官方推荐的方向。选型逻辑其实很朴素进程内能用 stdio 就别远程化因为远程化马上会引入认证、网络延迟、并发控制一堆问题。只有当多个 Agent 需要共享同一个 MCP Server 时才值得把 Server 独立部署出来。至于网上一大堆人纠结的browser use mcp 跟 playwright mcp 有什么区别——它们定位完全不同。Browser Use MCP 是把浏览器变成一个通用遥控器适合搜索资料、点击按钮、读取网页内容这类自由探索任务模型自己决定看哪个页面、点哪里特点是灵活但结果不确定性高。Playwright MCP 则是把浏览器操作变成确定性极强的自动化原语每一步都可以精确控制、可以断言适合必须可重复、要写测试的场景。选哪个取决于你的任务是需要探索还是需要确定性——数据看板验收这种场景用 Playwright MCP 更稳竞品调研这种场景用 Browser Use MCP 更省事。3. A2A智能体之间怎么派活而不是裸聊3.1 为什么有了 MCP 还不够MCP 解决的是 Agent 与外部工具、数据源之间的关系。但多智能体组织里还有一种更关键的关系Agent 和 Agent 之间的任务委托。你可以在自己的系统里写自定义 API 让 A 调用 B但一旦 Agent 数量多起来、跨团队协作每次都要定制点对点接口维护成本直线上升。A2AAgent2Agent协议解决的就是这个问题。这个协议由 Google 联合一批公司推动开放目标很简单让不同厂商、不同框架实现的 Agent 能够互相发现、互相通信、互相委托任务。我更愿意用这个类比MCP 相当于你把手伸进别人的工具箱拿工具A2A 相当于你给同事派一个活然后等他交付结果。一个是操作物件一个是协调人与人之间的关系两者完全不是一个层面。如果 Agent 之间只靠自然语言裸奔、各自对接各自的 API那相当于每台电脑都自己焊一条私有的串口线而不是插到标准网线上。3.2 A2A 的四个核心抽象Agent Card、Message、Task、ArtifactA2A 协议并不复杂核心是四个抽象Agent CardAgent 能力的名片通常是一个 JSON 文件声明这个 Agent 能做什么、支持什么协议、暴露在哪个端点、需要什么认证方式。别人拿到名片就能决定要不要把任务交给它。MessageAgent 之间传递的消息可以是文本也可以是结构化内容。Task一次任务从提交到完成的全过程。它有明确的生命周期submitted → working → input-required → completed / failed。这个状态机是 A2A 的灵魂。Artifact任务执行产生的成果物。比如生成的代码、分析报告、处理好的图片。为什么要做 Task 而不是简单的消息一来一回因为智能体协作是长时任务发起方把任务委托出去之后需要随时能问进展到哪了、是否卡住、有没有产出物。Task 状态机让协作过程可查询、可追踪这是生产环境的基本要求。实际上即使你短期内不打算全量引入 A2A也完全值得借鉴它的思想内部编排里给每个任务定义清晰的 submitted/working/completed/failed 状态用 Agent Card 管理角色清单——这个改动成本极低但会让后面的治理轻松很多。3.3 A2A 与 MCP 的边界划分实际工程里最让人困惑的就是什么时候走 MCP什么时候走 A2A。我给团队定的判断规则很简单如果调用的是工具或数据走 MCP如果调用的是另一个智能体的能力走 A2A。比如 Agent A 需要读数据库直接挂 PostgreSQL 的 MCP ServerAgent A 需要让 Agent B 做一份市场分析报告那就通过 A2A 提交 Task、轮询状态、拿 Artifact。两者可以串联。我现在的架构里实际链路经常是编排 Agent 收到用户请求 → 拆解任务 → 通过 A2A 把子任务派给专业 Agent → 专业 Agent 自己通过 MCP 调工具完成执行 → 产物通过 Artifact 回传给编排者。A2A 是骨架MCP 是肌肉这句话我反复跟人讲。4. Skills把领域经验打包成智能体的职业技能4.1 一个 Skill 的内部结构长什么样如果说 MCP 是给智能体接上手那 Skills 就是给智能体发职业训练手册。一个 Skill 通常是一个目录里面有核心说明文件、参考模板、示例脚本。以 Codex 生态的 Skill 结构为例核心是 SKILL.md带 frontmatter 声明技能名称和触发条件正文是具体的方法论、步骤、注意事项目录下还可以挂脚本和示例文件。code-review-skill/ ├── SKILL.md # 技能说明 触发条件 审查方法论 ├── checklist.md # 审查清单 ├── prompt-templates/ # 可复用的审查提示词模板 └── examples/ # 典型问题示例SKILL.md 开头的 frontmatter 至关重要它决定 Agent 在什么场景下会想起这个技能。description 不要写成关键词堆砌比如代码审查、代码质量而要写成场景化描述比如当用户要求审查代码、检查 PR、或分析潜在 bug 时使用。模型是靠语义匹配来触发技能的描述越贴近真实任务表达触发率越高。4.2 生态里的 Skills 实践从 Codex 到 Claude 到 SuperpowersSkills 这个概念在 2025 年快速普及。OpenAI 的 Codex 支持把 Skills 放在~/.codex/skills目录下社区里有大量现成技能包可以下载Claude Agent Skills 也采用了类似的目录加载机制Superpowers 这类社区项目则进一步把技能包的创建、组合、版本管理做成了体系。我实际在用的几个场景前端开发的技能包包含组件书写规范、样式约定、无障碍检查清单、论文写作技能包管理结构模板和引用格式、代码审查技能包沉淀了我过去踩过的坑。这些技能的本质是把我脑子里那些遇到 X 情况就按 Y 步骤处理的经验变成了 Agent 可装载的文件资产。IDE 插件也开始支持加载 Skills——现在很多人在 IDEA 里直接配 Codex 或通义灵码相关的 MCP/Skills 能力把模型和本地开发工具链串起来这已经是日常操作了。Skills 安装有几个常见坑我一开始都踩过目录或者 frontmatter 里的 name 写错Agent 加载不到description 写得太窄触发条件永远不满足最致命的是有人把数据库密码写进 Skill 的参考文档里——Skill 内容会被当作上下文交给模型等于把机密明文送进对话。这一条必须死守。4.3 Skill 和 MCP 的分界线在哪里团队里经常有人问这个东西到底是写成 Skill 还是做成 MCP Server我的判断顺序是有外部副作用、需要操作真实系统发消息、改数据库、调 API→ 做成 MCP Tool有稳定的数据源需要按需读取 → 做成 MCP Resource有固定的方法论、决策规则、流程模板主要教模型怎么想 → 写成 Skill。举例说明Git 操作是 Tool它是真实副作用代码审查方法则应该写成 Skill因为它是一套判断标准和检查流程。同理部署流程写成 SkillKubernetes 的 API 操作做成 MCP Tool。一句话概括Skill 管方法论MCP 管执行力。两者互补不存在二选一的问题。5. DeepAgents 的组织编排规划、执行、验证如何共治5.1 DeepAgents 不是又一个框架而是一种把 Agent 做深的范式网上对 DeepAgents 的解读有点乱我自己给它一个工作定义DeepAgents 代表的不是某个具体开源项目而是一类深度智能体组织的工程范式——每个 Agent 不是堆一个又长又全的 system prompt而是靠专业上下文 领域 Skills 最小化 MCP 工具集三个组件支撑形成有深度的单点能力组织层面则通过明确的任务拆解、执行、验证循环来保证系统的整体可靠性。这个定义和传统 multi-agent 系统的差别非常明显。传统多智能体常见做法是让几个 Agent 轮流发言看起来像开会实际上没有严格分工也没有任务状态管理开完会质量全靠运气。DeepAgents 是有编制的组织Orchestrator 负责拆任务Worker 各自负责干活Reviewer 专门挑刺。单看每个组件都很简单但组合起来能扛复杂任务——这恰恰是超级多智能体真正的含义超级不是指单点能力夸张而是组织形态带来的整体能力跃迁。5.2 三种编排拓扑顺序、并行、事件驱动我在实际项目中常用三种编排方式顺序管道任务天然有先后依赖比如查询数据 → 生成图表 → 写分析报告每个阶段一个 Agent前一个输出是后一个输入。实现最简单但吞吐量受限延迟是叠加的。并行扇出Orchestrator 把一个大任务拆成 N 个独立子任务分发给多个 Worker 同时执行然后聚合结果。适合市场调研、多文件分析这类可并行场景能大幅缩短总耗时。事件驱动Agent 之间通过任务队列和事件回调联动不强制同步等待。最灵活也最难治理必须有任务状态机和超时机制兜底。这三种拓扑不是互斥的同一个系统里可以混合使用。比如我那个数据看板案例里取数和读设计稿就是并行的而验收必须等两者都完成后再串行执行。5.3 上下文治理防止组织退化回单体把 Agent 拆开之后如果每个 Agent 还是把所有信息都加载一遍那就等于把单体的问题复制到了组织里。上下文必须分层治理编排层只保留任务拆解、状态汇总、产物索引不加载执行细节执行层只加载自己职责范围内的上下文通过 MCP Resource 按需读取数据而不是全量塞进 prompt共享记忆单独放一个存储比如向量库或专门的记忆 Agent谁需要谁去查不广播。这就好比公司里CEO 只需要看各部门的 KPI 汇报不需要每个部门把原始发票都抄送一遍。上下文隔离是 DeepAgents 组织能长期稳定运行的关键一旦乱了token 成本飙升、响应变慢、误判率上升一步步退回原来的乱局。5.4 可观测性与权限边界组织架构里最容易漏掉的两块最后讲两个工程上不可妥协的点。第一是可观测性。多智能体系统排错比单体难十倍因为没有明确的调用栈。我的做法是在任务层面贯穿一个 trace_id用户请求进来生成一个 ID子任务、A2A 的 Task、MCP 调用全部带上这个 ID日志系统里就能用一条 trace 链路看到用户请求 → 编排 Agent 拆解 → 数据 Agent 调 SQL → 前端 Agent 读设计稿 → Reviewer 输出结论的全过程。A2A 的 Task 状态机本身就是一个天然的追踪骨架这个设计意外地好用。第二是权限边界。每个 Worker Agent 只应该挂完成自己职责所必需的那些 MCP Server永远不要图省事给所有 Agent 开全量工具。一个前端 Agent 不需要数据库写权限一个数据分析 Agent 不需要文件删除权限。最小权限原则在真实团队里是常识在 AI 组织里反倒经常被忽略等模型乱调工具闯祸了才后悔。权限配置越细系统的容错能力越强。6. 从零搭一个最小多智能体组织完整落地链路与踩坑日志6.1 一个具体的四角色小组怎么跑通拿我做过的数据看板改版任务来拆解。任务需求是根据最新订单数据改版数据看板页面并验收效果。我搭了一个四个角色的最小组织Orchestrator负责拆解任务。收到需求后拆成取数、改前端、验收三个子任务并维护任务状态。Data Agent挂 PostgreSQL MCP Server负责查订单数据、输出结构化数据摘要。Frontend Agent挂 Figma MCP 读取设计稿、加载前端开发的 Skill 包负责产出改版代码。Reviewer Agent挂代码审查 Skill 和自动化测试工具负责检查代码质量和功能正确性。流程是这样的Orchestrator 先并行派单给 Data Agent 和 Frontend AgentData Agent 通过只读账号执行 SQL 取数Frontend Agent 通过 Figma MCP 拿设计稿、按 Skill 里的组件规范改代码两个子任务完成后Orchestrator 把产物汇总派给 Reviewer 验收Reviewer 检查不通过就带着原因打回给对应 Agent 重做。整个过程中每个 Agent 的上下文都是隔离的Orchestrator 只存任务状态和产物索引数据量再大也不会失控。6.2 授权与资源配置里最容易踩的坑这个案例里最折磨人的不是写 prompt而是授权和资源。逐一说说我踩过的坑Figma MCP 的授权问题。Codex 接入 Figma MCP 时OAuth token 有有效期过期之后工具调用直接失败而且报错信息很隐晦不细看还以为 Server 挂了。解决方法是把 token 刷新逻辑写成一个小的定时任务或者在编排层加一个授权检查前置步骤。血泪教训token 绝对不要写进 Skill 的参考文件里那是明文进上下文的。PostgreSQL MCP 的权限。接数据库 MCP 时千万不要图省事用生产账号务必用只读账号并且在 SQL 相关的 Tool 描述里显式要求所有查询自动加 LIMIT 100。我还见过 Agent 拿到写权限之后直接执行 DELETE 的案例当场把测试库清了一部分自此以后我的所有数据库 MCP 一律只读写操作必须走人工审批流程。Resource 与 Tool 的选择会影响配置复杂度。像表结构、字段说明这种静态信息做成 Resource 后 Agent 需要时自己去拉取又省 token 又省事如果做成 ToolAgent 反而要决定是否调用多一层判断就多一层误用风险。6.3 踩坑日志现象、根因、解法现象根因解法MCP Server 能连上但工具列表为空Server 内部 import 报错工具注册失败stdio 进程异常退出看 MCP Server 的 stderr 日志检查依赖是否装全A2A 任务一直卡在 working子任务执行 Agent 超时或崩溃没有超时机制兜底给 Task 加上 timeout超时后自动标记 failed 并触发重试Skill 一直不触发SKILL.md 的 description 写成了关键词堆砌缺少场景描述改成当用户要求……时使用的触发式描述上下文 overflow 频繁长文档全量塞进 system prompt把长文档做成 MCP Resource让 Agent 按需读取工具调用张冠李戴单个 Agent 挂了 10 个以上 Tool模型选择困难按职责拆分 Agent每个 Agent 只挂 3 到 5 个高内聚工具这套排查链路我沉淀了很久才稳定下来。核心心法就是出问题先分层定位先看协议层MCP Server 是否正常注册、A2A 状态机卡在哪一步再看上下文层是不是信息超载最后才看模型层。大多数所谓模型太笨的问题往上查一层都会发现是工程配置的锅。最后再分享一点我个人的实操体会多智能体系统的难点从来不在搭起来而在约束。我现在动手做任何 Agent 组织第一件事都是先画角色卡片明确每个 Agent 的职责边界、MCP Server 白名单、Skills 目录和任务状态机角色卡片定稿了才开始写 prompt。这个顺序千万别反过来。另一个很实用的小技巧是把 A2A 的 Agent Card 思想用在团队内部不同系统之间一张 JSON 名片就能让多个项目组互相发现彼此的能力接口省掉大量点对点联调这个思路值得所有做 AI 工程化的人试试。
从单体到组织：DeepAgents多智能体架构的MCP、A2A与Skills工程实践
去年我做过一个极其愚蠢的架构决策把一个数据分析智能体的工具列表从 3 个一路加到 17 个挂了 6 个 MCP Server、塞了 8 个自定义函数系统 prompt 写得跟一本操作手册一样厚。结果你应该能猜得到——准确率不升反降模型开始自由发挥明明有专用工具不用偏要东拼西凑一次数据库连接失败就能让整条流程全部翻车。后来我痛定思痛把这堆东西全部拆掉重构为一个四个角色组成的 DeepAgents 组织规划、数据、前端、验收再用 MCP、A2A、Skills 把接口和技能全部标准化。系统不但稳定了迭代速度也明显变快。这篇文章就把从单体到组织的超级多智能体工程逻辑完整讲清楚适合正在搞多智能体、AI 工作流自动化或者被单一 Agent 的上下文爆炸折磨的朋友。1. 单体 Agent 的失控现场为什么必须走向组织化1.1 工具塞得越多模型越容易犯糊涂单体 Agent 最典型的问题就是什么都往里塞。我那个失败案例里17 个工具每个都要在上下文里带一份描述和参数 schema平均下来每个占用 150 到 300 token光工具定义就吃掉了四五千 token。别小看这个数字在多轮对话和工具调用循环里模型每次做工具选择都要重新评估所有候选而上下文中关键指令的比例被稀释之后误选率会肉眼可见地上升。我自己的经验数据是同一个模型5 个以内工具时基本稳定几乎不会张冠李戴到 10 个左右开始出现把参数传错、漏用正确工具的情况15 个以上就需要频繁人工纠正这时候整个系统的可靠性已经完全不可接受了。这种情况和真实团队一个道理——一个人同时背钳工、电工、厨师、会计四套操作手册高压力下他大概率会拿错工具而不是更全能。1.2 自己写代码自己验收是伪命题单体 Agent 另一个被忽视的问题是验证环节的独立性。同一个上下文里它既当分析师又当执行者还要当验收员模型天然倾向于认同自己之前的产出。我做个内部 Demo 时测试过让同一个 Agent 写完代码再做 Review它大概率会说看起来没有问题同一个任务拆给另一个独立的 Review Agent却能找出明显的边界条件漏洞和潜在 bug。人尚且不能给自己当裁判模型也一样。这就是为什么组织化必须包含独立的验证角色。复杂任务的本质是规划、执行、验证三个动作的反复循环硬塞在同一个 Agent 里上下文会互相干扰而且没有真正的制衡机制。1.3 组织化其实就是在做三件事拆解、连接、治理把单体拆成组织核心动作只有三个拆解把任务按职责边界切成独立单元每个 Agent 只保留一个领域上下文prompt 短了、注意力集中了、误调用率自然下降。连接既定好接口。工具和数据用 MCP 接Agent 之间互相委托用 A2A领域方法论用 Skills 打包。没有连接规范拆出来的 Agent 就是信息孤岛。治理任务状态机、超时重试、权限边界、全链路追踪。这是单体架构根本不需要、而组织架构必须补齐的东西。从单体到组织的对比我用一张表说明维度单体 AgentDeepAgents 组织上下文全部塞进一个上下文容易被稀释每个角色聚焦自己的上下文按需共享工具边界所有工具对同一模型开放每个 Agent 只挂自己需要的 MCP最小化权限验证机制自写自验缺少独立性独立 Review 角色形成制衡故障影响一个环节失败全流程翻车局部失败可重试、可降级不影响其他角色迭代方式改一处可能影响全局单个 Agent 独立升级接口不变即可拆、连、治是后面所有技术选型的总纲。下面逐个讲 MCP、A2A、Skills 在组织里分别承担什么。2. MCP先把智能体和外部世界之间的USB-C打通2.1 MCP 到底是什么以及三个原语怎么用MCP 全称 Model Context Protocol是一个软件协议。很多人拿 USB-C 来类比我觉得这个类比非常贴切USB-C 不是某个具体的硬件设备而是让鼠标、硬盘、显示器都能通过同一个物理接口接进电脑的标准。MCP 也一样它定义了 AI 应用和外部工具、数据源之间的统一会话协议让任意支持 MCP 的 Agent 都能接上任意实现了 MCP 的服务端。它的架构是典型的三端MCP Host 是 AI 应用本身MCP Client 负责与 Server 通信MCP Server 提供具体能力。真正要理解 MCP重点是它的三个原语Tools可执行的工具Agent 决定调用会产生副作用。比如执行 SQL、发消息、创建工单。Resources可读取的资源一般用 URI 定位让 Agent 按需加载上下文。比如项目文档、数据库 schema、配置文件。Prompts预设好的可复用提示模板类似把常用操作流程固化下来。这里面最容易踩坑的是 Resources 被忽视。很多人接 MCP 时习惯把什么都做成 Tool但静态数据和按需查询的内容更适合做成 Resource。比如数据库表结构它不构成一次操作只是一个需要被模型读取的信息源。我在实际项目里有一个体会把那种喂进去太占 token、不喂又不行的大段背景资料做成 Resource让 Agent 在处理任务时自己去 resource 拉取比硬塞进 system prompt 要强得多。这正是网上一堆人问mcp resource 实战的答案——大部分数据都不需要做成工具按需读取的效率更高。2.2 一个 MCP Server 的最小实现模板FastMCP 这个 Python 包可以非常快地写一个 Server我贴一个实际用过的骨架from fastmcp import FastMCP mcp FastMCP(ops-data) mcp.tool() def query_postgres(sql: str, limit: int 100) - str: 对只读账号执行 SQL 查询自动限制返回条数。 # 这里连数据库强制加 LIMIT避免 Agent 把表拖爆 return str(run_readonly_query(sql[:500], limit)) mcp.resource(schema://orders) def orders_schema() - str: 订单表结构信息Agent 写 SQL 前按需读取。 return get_table_schema(orders) if __name__ __main__: # 本地用 stdio远程服务用 streamable-http mcp.run()注意最后这行mcp.run()默认走 stdio 传输适合 Claude Desktop、IDE 插件这类本地宿主。如果你要做成远程多智能体共享的服务就要换成 streamable HTTP 模式。工具定义里那个 docstring 很重要模型是靠它判断什么时候该调用这个工具的写得越明确误调率越低。2.3 传输方式怎么选以及 Browser Use MCP 和 Playwright MCP 的区别MCP 传输方式目前主流就三种stdioServer 作为本地子进程运行走标准输入输出。安全、简单适合单个开发者自己的环境但没法跨机器。SSEServer 暴露 HTTP 端点支持服务端向客户端推送事件。适合远程部署。streamable HTTPSSE 的升级版支持请求-响应和流式两种模式是目前官方推荐的方向。选型逻辑其实很朴素进程内能用 stdio 就别远程化因为远程化马上会引入认证、网络延迟、并发控制一堆问题。只有当多个 Agent 需要共享同一个 MCP Server 时才值得把 Server 独立部署出来。至于网上一大堆人纠结的browser use mcp 跟 playwright mcp 有什么区别——它们定位完全不同。Browser Use MCP 是把浏览器变成一个通用遥控器适合搜索资料、点击按钮、读取网页内容这类自由探索任务模型自己决定看哪个页面、点哪里特点是灵活但结果不确定性高。Playwright MCP 则是把浏览器操作变成确定性极强的自动化原语每一步都可以精确控制、可以断言适合必须可重复、要写测试的场景。选哪个取决于你的任务是需要探索还是需要确定性——数据看板验收这种场景用 Playwright MCP 更稳竞品调研这种场景用 Browser Use MCP 更省事。3. A2A智能体之间怎么派活而不是裸聊3.1 为什么有了 MCP 还不够MCP 解决的是 Agent 与外部工具、数据源之间的关系。但多智能体组织里还有一种更关键的关系Agent 和 Agent 之间的任务委托。你可以在自己的系统里写自定义 API 让 A 调用 B但一旦 Agent 数量多起来、跨团队协作每次都要定制点对点接口维护成本直线上升。A2AAgent2Agent协议解决的就是这个问题。这个协议由 Google 联合一批公司推动开放目标很简单让不同厂商、不同框架实现的 Agent 能够互相发现、互相通信、互相委托任务。我更愿意用这个类比MCP 相当于你把手伸进别人的工具箱拿工具A2A 相当于你给同事派一个活然后等他交付结果。一个是操作物件一个是协调人与人之间的关系两者完全不是一个层面。如果 Agent 之间只靠自然语言裸奔、各自对接各自的 API那相当于每台电脑都自己焊一条私有的串口线而不是插到标准网线上。3.2 A2A 的四个核心抽象Agent Card、Message、Task、ArtifactA2A 协议并不复杂核心是四个抽象Agent CardAgent 能力的名片通常是一个 JSON 文件声明这个 Agent 能做什么、支持什么协议、暴露在哪个端点、需要什么认证方式。别人拿到名片就能决定要不要把任务交给它。MessageAgent 之间传递的消息可以是文本也可以是结构化内容。Task一次任务从提交到完成的全过程。它有明确的生命周期submitted → working → input-required → completed / failed。这个状态机是 A2A 的灵魂。Artifact任务执行产生的成果物。比如生成的代码、分析报告、处理好的图片。为什么要做 Task 而不是简单的消息一来一回因为智能体协作是长时任务发起方把任务委托出去之后需要随时能问进展到哪了、是否卡住、有没有产出物。Task 状态机让协作过程可查询、可追踪这是生产环境的基本要求。实际上即使你短期内不打算全量引入 A2A也完全值得借鉴它的思想内部编排里给每个任务定义清晰的 submitted/working/completed/failed 状态用 Agent Card 管理角色清单——这个改动成本极低但会让后面的治理轻松很多。3.3 A2A 与 MCP 的边界划分实际工程里最让人困惑的就是什么时候走 MCP什么时候走 A2A。我给团队定的判断规则很简单如果调用的是工具或数据走 MCP如果调用的是另一个智能体的能力走 A2A。比如 Agent A 需要读数据库直接挂 PostgreSQL 的 MCP ServerAgent A 需要让 Agent B 做一份市场分析报告那就通过 A2A 提交 Task、轮询状态、拿 Artifact。两者可以串联。我现在的架构里实际链路经常是编排 Agent 收到用户请求 → 拆解任务 → 通过 A2A 把子任务派给专业 Agent → 专业 Agent 自己通过 MCP 调工具完成执行 → 产物通过 Artifact 回传给编排者。A2A 是骨架MCP 是肌肉这句话我反复跟人讲。4. Skills把领域经验打包成智能体的职业技能4.1 一个 Skill 的内部结构长什么样如果说 MCP 是给智能体接上手那 Skills 就是给智能体发职业训练手册。一个 Skill 通常是一个目录里面有核心说明文件、参考模板、示例脚本。以 Codex 生态的 Skill 结构为例核心是 SKILL.md带 frontmatter 声明技能名称和触发条件正文是具体的方法论、步骤、注意事项目录下还可以挂脚本和示例文件。code-review-skill/ ├── SKILL.md # 技能说明 触发条件 审查方法论 ├── checklist.md # 审查清单 ├── prompt-templates/ # 可复用的审查提示词模板 └── examples/ # 典型问题示例SKILL.md 开头的 frontmatter 至关重要它决定 Agent 在什么场景下会想起这个技能。description 不要写成关键词堆砌比如代码审查、代码质量而要写成场景化描述比如当用户要求审查代码、检查 PR、或分析潜在 bug 时使用。模型是靠语义匹配来触发技能的描述越贴近真实任务表达触发率越高。4.2 生态里的 Skills 实践从 Codex 到 Claude 到 SuperpowersSkills 这个概念在 2025 年快速普及。OpenAI 的 Codex 支持把 Skills 放在~/.codex/skills目录下社区里有大量现成技能包可以下载Claude Agent Skills 也采用了类似的目录加载机制Superpowers 这类社区项目则进一步把技能包的创建、组合、版本管理做成了体系。我实际在用的几个场景前端开发的技能包包含组件书写规范、样式约定、无障碍检查清单、论文写作技能包管理结构模板和引用格式、代码审查技能包沉淀了我过去踩过的坑。这些技能的本质是把我脑子里那些遇到 X 情况就按 Y 步骤处理的经验变成了 Agent 可装载的文件资产。IDE 插件也开始支持加载 Skills——现在很多人在 IDEA 里直接配 Codex 或通义灵码相关的 MCP/Skills 能力把模型和本地开发工具链串起来这已经是日常操作了。Skills 安装有几个常见坑我一开始都踩过目录或者 frontmatter 里的 name 写错Agent 加载不到description 写得太窄触发条件永远不满足最致命的是有人把数据库密码写进 Skill 的参考文档里——Skill 内容会被当作上下文交给模型等于把机密明文送进对话。这一条必须死守。4.3 Skill 和 MCP 的分界线在哪里团队里经常有人问这个东西到底是写成 Skill 还是做成 MCP Server我的判断顺序是有外部副作用、需要操作真实系统发消息、改数据库、调 API→ 做成 MCP Tool有稳定的数据源需要按需读取 → 做成 MCP Resource有固定的方法论、决策规则、流程模板主要教模型怎么想 → 写成 Skill。举例说明Git 操作是 Tool它是真实副作用代码审查方法则应该写成 Skill因为它是一套判断标准和检查流程。同理部署流程写成 SkillKubernetes 的 API 操作做成 MCP Tool。一句话概括Skill 管方法论MCP 管执行力。两者互补不存在二选一的问题。5. DeepAgents 的组织编排规划、执行、验证如何共治5.1 DeepAgents 不是又一个框架而是一种把 Agent 做深的范式网上对 DeepAgents 的解读有点乱我自己给它一个工作定义DeepAgents 代表的不是某个具体开源项目而是一类深度智能体组织的工程范式——每个 Agent 不是堆一个又长又全的 system prompt而是靠专业上下文 领域 Skills 最小化 MCP 工具集三个组件支撑形成有深度的单点能力组织层面则通过明确的任务拆解、执行、验证循环来保证系统的整体可靠性。这个定义和传统 multi-agent 系统的差别非常明显。传统多智能体常见做法是让几个 Agent 轮流发言看起来像开会实际上没有严格分工也没有任务状态管理开完会质量全靠运气。DeepAgents 是有编制的组织Orchestrator 负责拆任务Worker 各自负责干活Reviewer 专门挑刺。单看每个组件都很简单但组合起来能扛复杂任务——这恰恰是超级多智能体真正的含义超级不是指单点能力夸张而是组织形态带来的整体能力跃迁。5.2 三种编排拓扑顺序、并行、事件驱动我在实际项目中常用三种编排方式顺序管道任务天然有先后依赖比如查询数据 → 生成图表 → 写分析报告每个阶段一个 Agent前一个输出是后一个输入。实现最简单但吞吐量受限延迟是叠加的。并行扇出Orchestrator 把一个大任务拆成 N 个独立子任务分发给多个 Worker 同时执行然后聚合结果。适合市场调研、多文件分析这类可并行场景能大幅缩短总耗时。事件驱动Agent 之间通过任务队列和事件回调联动不强制同步等待。最灵活也最难治理必须有任务状态机和超时机制兜底。这三种拓扑不是互斥的同一个系统里可以混合使用。比如我那个数据看板案例里取数和读设计稿就是并行的而验收必须等两者都完成后再串行执行。5.3 上下文治理防止组织退化回单体把 Agent 拆开之后如果每个 Agent 还是把所有信息都加载一遍那就等于把单体的问题复制到了组织里。上下文必须分层治理编排层只保留任务拆解、状态汇总、产物索引不加载执行细节执行层只加载自己职责范围内的上下文通过 MCP Resource 按需读取数据而不是全量塞进 prompt共享记忆单独放一个存储比如向量库或专门的记忆 Agent谁需要谁去查不广播。这就好比公司里CEO 只需要看各部门的 KPI 汇报不需要每个部门把原始发票都抄送一遍。上下文隔离是 DeepAgents 组织能长期稳定运行的关键一旦乱了token 成本飙升、响应变慢、误判率上升一步步退回原来的乱局。5.4 可观测性与权限边界组织架构里最容易漏掉的两块最后讲两个工程上不可妥协的点。第一是可观测性。多智能体系统排错比单体难十倍因为没有明确的调用栈。我的做法是在任务层面贯穿一个 trace_id用户请求进来生成一个 ID子任务、A2A 的 Task、MCP 调用全部带上这个 ID日志系统里就能用一条 trace 链路看到用户请求 → 编排 Agent 拆解 → 数据 Agent 调 SQL → 前端 Agent 读设计稿 → Reviewer 输出结论的全过程。A2A 的 Task 状态机本身就是一个天然的追踪骨架这个设计意外地好用。第二是权限边界。每个 Worker Agent 只应该挂完成自己职责所必需的那些 MCP Server永远不要图省事给所有 Agent 开全量工具。一个前端 Agent 不需要数据库写权限一个数据分析 Agent 不需要文件删除权限。最小权限原则在真实团队里是常识在 AI 组织里反倒经常被忽略等模型乱调工具闯祸了才后悔。权限配置越细系统的容错能力越强。6. 从零搭一个最小多智能体组织完整落地链路与踩坑日志6.1 一个具体的四角色小组怎么跑通拿我做过的数据看板改版任务来拆解。任务需求是根据最新订单数据改版数据看板页面并验收效果。我搭了一个四个角色的最小组织Orchestrator负责拆解任务。收到需求后拆成取数、改前端、验收三个子任务并维护任务状态。Data Agent挂 PostgreSQL MCP Server负责查订单数据、输出结构化数据摘要。Frontend Agent挂 Figma MCP 读取设计稿、加载前端开发的 Skill 包负责产出改版代码。Reviewer Agent挂代码审查 Skill 和自动化测试工具负责检查代码质量和功能正确性。流程是这样的Orchestrator 先并行派单给 Data Agent 和 Frontend AgentData Agent 通过只读账号执行 SQL 取数Frontend Agent 通过 Figma MCP 拿设计稿、按 Skill 里的组件规范改代码两个子任务完成后Orchestrator 把产物汇总派给 Reviewer 验收Reviewer 检查不通过就带着原因打回给对应 Agent 重做。整个过程中每个 Agent 的上下文都是隔离的Orchestrator 只存任务状态和产物索引数据量再大也不会失控。6.2 授权与资源配置里最容易踩的坑这个案例里最折磨人的不是写 prompt而是授权和资源。逐一说说我踩过的坑Figma MCP 的授权问题。Codex 接入 Figma MCP 时OAuth token 有有效期过期之后工具调用直接失败而且报错信息很隐晦不细看还以为 Server 挂了。解决方法是把 token 刷新逻辑写成一个小的定时任务或者在编排层加一个授权检查前置步骤。血泪教训token 绝对不要写进 Skill 的参考文件里那是明文进上下文的。PostgreSQL MCP 的权限。接数据库 MCP 时千万不要图省事用生产账号务必用只读账号并且在 SQL 相关的 Tool 描述里显式要求所有查询自动加 LIMIT 100。我还见过 Agent 拿到写权限之后直接执行 DELETE 的案例当场把测试库清了一部分自此以后我的所有数据库 MCP 一律只读写操作必须走人工审批流程。Resource 与 Tool 的选择会影响配置复杂度。像表结构、字段说明这种静态信息做成 Resource 后 Agent 需要时自己去拉取又省 token 又省事如果做成 ToolAgent 反而要决定是否调用多一层判断就多一层误用风险。6.3 踩坑日志现象、根因、解法现象根因解法MCP Server 能连上但工具列表为空Server 内部 import 报错工具注册失败stdio 进程异常退出看 MCP Server 的 stderr 日志检查依赖是否装全A2A 任务一直卡在 working子任务执行 Agent 超时或崩溃没有超时机制兜底给 Task 加上 timeout超时后自动标记 failed 并触发重试Skill 一直不触发SKILL.md 的 description 写成了关键词堆砌缺少场景描述改成当用户要求……时使用的触发式描述上下文 overflow 频繁长文档全量塞进 system prompt把长文档做成 MCP Resource让 Agent 按需读取工具调用张冠李戴单个 Agent 挂了 10 个以上 Tool模型选择困难按职责拆分 Agent每个 Agent 只挂 3 到 5 个高内聚工具这套排查链路我沉淀了很久才稳定下来。核心心法就是出问题先分层定位先看协议层MCP Server 是否正常注册、A2A 状态机卡在哪一步再看上下文层是不是信息超载最后才看模型层。大多数所谓模型太笨的问题往上查一层都会发现是工程配置的锅。最后再分享一点我个人的实操体会多智能体系统的难点从来不在搭起来而在约束。我现在动手做任何 Agent 组织第一件事都是先画角色卡片明确每个 Agent 的职责边界、MCP Server 白名单、Skills 目录和任务状态机角色卡片定稿了才开始写 prompt。这个顺序千万别反过来。另一个很实用的小技巧是把 A2A 的 Agent Card 思想用在团队内部不同系统之间一张 JSON 名片就能让多个项目组互相发现彼此的能力接口省掉大量点对点联调这个思路值得所有做 AI 工程化的人试试。
