1. 四块拼图各自扮演什么角色为什么非要凑齐它们上个月我帮一家电商公司搭智能工单系统遇到一个非常典型的问题他们之前已经把GPT-4接进了客服后台也接了几个API但效果一直上不去。客服说AI答非所问技术说接口都通了两边都委屈。后来我意识到问题不在模型而在整个架构只有一块拼图——一个单体Agent被赋予了太多职责工具接入靠临时写代码业务经验完全没沉淀多个Agent之间根本没有协作关系。这个场景应该是很多团队的真实写照。近几年Agent框架层出不穷但真正落到企业级生产环境目前最务实的技术栈组合就是标题里这四样DeepAgents、MCP、A2A、Skills。这篇文章我会用一套完整的电商智能工单系统作为贯穿案例讲清楚每一块拼图解决什么问题、为什么选它、落地时有哪些必须注意的细节。适合正在做Agent选型的技术负责人也适合已经跑通单Agent demo、想往多智能体方向升级的开发者。先说结论MCP负责把工具接入标准化Skills负责把业务经验固化成可执行的操作手法DeepAgents负责大脑层面的任务分工与编排A2A负责不同Agent之间的通信与协作。四者叠加才能从一个什么都会但什么都不精的实习生进化成一个分工明确、经验沉淀、协同有序的项目组。1.1 从单体Agent到超级多智能体为什么大型prompt路线走不通了很多团队最初的做法是把系统提示词越写越长把所有工具说明、业务流程、输出要求全塞进一个Agent里。一开始感觉还行但到某个临界点就会崩。我见过一个prompt超过两万字的生产Agent每次任务的处理逻辑越来越不可控改一个业务规则要动整个prompt模型输出也经常偏离预期。单体Agent的核心问题是上下文爆炸和职责耦合。所有知识、所有工具、所有规则都挤在同一个上下文窗口里模型在做具体任务时被大量无关信息干扰准确率自然下降。你让同一个Agent既查订单又写退款话术又处理物流异常它每个环节都会做得将就。多智能体系统用工程手段解决了这个问题。每个Agent只需关心自己的职责范围上下文窗口用来容纳本任务相关的内容工具集按需挂载业务经验沉淀成Skills按需加载。就像你不可能要求一个全栈工程师同时具备医生执照但可以让一个团队里有人擅长看病、有人擅长写代码再定好协作流程。1.2 MCP——把工具接入变成USB-C口MCP全称Model Context Protocol模型上下文协议Anthropic在2024年底提出并开源。它是干什么的一句话标准化的工具接入层。我给你打个比方。早年的智能硬件充电口有Micro-USB、Lightning、Type-C每换一个设备就要换一根线Apple用户出门还要带两根线。MCP做的事情就是把AI应用和外部工具之间的连接统一成一个标准接口——对AI应用来说任何MCP Server都长一个样对工具方来说写一次MCP Server所有支持MCP的客户端都能直接调用。这带来的实际价值非常直接。以前你要给AI接入公司内部数据库、蓝湖设计稿、浏览器自动化能力每接一个新工具都要为不同客户端各写一套Function Calling适配代码工程量不小维护更麻烦。现在团队只要把一个工具封装成MCP ServerClaude Desktop能用、DeepAgents能用未来换个客户端还能用。这就是企业级部署最看重的资产复用价值。1.3 Skills——AI的业务手法包光有工具远远不够很多团队在接完MCP之后特别兴奋好了AI现在能调用蓝湖、能开浏览器、能查数据库了。然后实测发现效果还是很拉胯。为什么因为能用工具和会干活是两码事。你给新同事一台专业单反相机这是MCP给了他工具使用权但没教他光圈怎么调、构图怎么选、什么场景用什么镜头他拍出来的照片就是不如老摄影师。AI也是一样模型知道MCP工具的存在、知道参数的格式但它不知道在具体业务流程里该按什么顺序调用、每一步的验收标准是什么、哪些坑要提前避。Skills做的就是这件事。一个Skill是一套结构化的操作手法包通常包含一份SKILL.md主文件里面有触发条件、执行步骤、输出规范、常见错误处理还可以附带参考脚本和模板文件。当Agent面对某个业务场景时它加载对应的Skill按里面沉淀好的SOP去执行而不是临场瞎发挥。MCP解决了能不能的问题Skills解决的是会不会、专不专的问题。1.4 DeepAgents和A2A一个管大脑分工一个管同事协作DeepAgents是LangChain推出的多智能体框架核心概念是sub-agents。主Agent在收到任务后会动态规划目标拆分子任务创建负责各个子任务的子Agent子Agent甚至还能再创建孙Agent。它解决的是任务编排的问题——谁来做、做什么、按什么顺序做、结果怎么汇总。A2A则是Agent2Agent协议Google在2025年主导推动的开放标准解决的是异构Agent之间的协作问题。DeepAgents内部子Agent可以用自己的调度机制但如果你想让它跟外部团队开发的Agent、或者另一个厂商的Agent系统协同干活就需要A2A这种公共语言来做任务交接。这里有个常见误区需要澄清DeepAgents和A2A不是绑定关系。DeepAgents负责你系统内部的组织架构A2A负责你系统与外部世界的外交辞令。一个大型企业内部可能有多个团队各自维护自己的Agent系统A2A就是让这些系统能互相接任务、传结果的标准协议。2. MCP企业化落地的关键细节与配置实操聊完概念我们进入具体落地。MCP是整个架构的基础因为所有的工具能力都要通过它暴露给Agent。这一节我会从连接形态、配置示例、安全管理三个角度讲清楚。2.1 三种连接形态stdio本地进程、SSE远程、Streamable HTTPMCP Server的连接方式经历过一个演进现在实际部署主要遇到三种连接形态原理适用场景典型例子stdio客户端启动子进程通过标准输入输出通信本地开发工具、单机部署Playwright MCP、文件系统MCPSSEServer-Sent Events单向推送 HTTP POST请求远程服务但协议较老早期远程MCP ServerStreamable HTTP基于HTTP的双向流式通信2025年MCP规范更新的推荐方式企业级远程部署内部订单系统MCP、网关转发MCP企业生产环境我建议直接选Streamable HTTP。SSE有两个毛病一是它的连接模型在NGINX或其他反向代理后面经常要额外配置缓冲关闭很烦二是很多场景下客户端需要轮询才能拿到完整状态交互效率不高。Streamable HTTP是官方现在推荐的远程通信方式兼容性会越来越好。2.2 一份可直接套用的多Server配置下面这是一个比较典型的企业级MCP配置文件同时挂了三个Server。注意每个Server都声明了type、command/url、以及最关键的工具描述信息来源MCP Server内部会提供工具列表但客户端配置文件里的描述能帮你做第一层收敛{ mcpServers: { playwright: { command: npx, args: [-y, playwright/mcplatest] }, lanhu: { type: http, url: https://mcp.example-internal.com/lanhu, headers: { Authorization: Bearer ${LANHU_MCP_TOKEN} } }, order-system: { type: http, url: https://mcp.example-internal.com/order, headers: { Authorization: Bearer ${ORDER_MCP_TOKEN} } } } }如果你需要自研一个内部MCP Server用Python FastMCP库是成本最低的路径。比如把订单查询能力快速暴露成工具核心代码就这么多from fastmcp import FastMCP mcp FastMCP(order-mcp) mcp.tool def query_order(order_id: str) - dict: 根据订单号查询订单状态、商品明细和当前物流节点 # 这里连接公司内部的订单数据库或调用已有API return order_service.query(order_id) if __name__ __main__: mcp.run(transportstreamable-http)FastMCP的好处是装饰器声明极简从写代码到上线一个MCP Server快的话半天就够。关键是mcp.tool下方的docstring一定要写清楚这个工具是干嘛的、参数含义、适用场景因为模型的工具选择能力直接看这段描述。2.3 多Server场景下的工具命名与权限安全MCP接入多了以后我遇到的第一个坑是工具名冲突。比如订单系统里有query用户系统里也可能有query模型很容易调错。解决办法是在工具名上加域前缀order_query、user_profile_query同时在docstring里写清楚本工具仅用于查询订单域信息如需查询用户资料请使用user_profile_query。安全这条要重点说。MCP给模型的是真实权限不是沙盒模拟。我见过团队上线第一个MCP Server就把数据库写权限直接暴露给Agent的这种操作一旦被错误调用后果相当严重。几个企业级部署必须遵守的原则提示MCP Server默认只暴露只读能力写操作、删除操作必须单独封装成需要高级权限的工具。对外网映射的MCP Server必须配认证鉴权API Key、OAuth或者至少Header Token并且每一次工具调用都要留审计日志。工具最小权限原则和人员最小权限原则一样重要别觉得内部系统就安全。3. Skills技能包从一篇SKILL.md到可复用的团队技能库这一节讲Skills我认为是整个架构里最被低估的部分。很多团队MCP接得漂漂亮亮最后效果不行问题八成出在Skills这块。3.1 一个能跑起来的Skill长什么样社区里常见的Skill格式Claude Code、Codex、DeepAgents都兼容这个思路是一个目录里放一份SKILL.md主文件配上必要的脚本、模板、示例资源。SKILL.md是核心它定义了这个Skill在什么场景下被触发、按什么步骤干活、产出什么格式的结果。一个合格的SKILL.md至少要包含五块内容前置条件执行前必须确认什么比如已打开蓝湖项目MCP Server已连接。触发场景什么类型的用户问题会用到这个Skill。执行步骤按顺序的操作清单这是SOP的核心。输出规范产出的格式、字段、代码风格。常见错误与回退遇到某个异常时怎么办这一条很容易被忽略但恰恰是老手经验的沉淀点。3.2 手写一个设计稿切图Skill的实际例子我们用前端团队最常用的场景举例让Agent通过蓝湖MCP读取设计稿标注然后输出符合项目规范的前端样式代码。如果没有Skill模型会因为不知道先看哪一屏、该提取哪些值、项目用什么单位体系而输出一坨不能用的东西。有了Skill它才能像老前端一样干活。下面是一份经过实际项目验证的SKILL.md简化版你可以直接改成自己团队的内容# Skill: 蓝湖设计稿标注提取与组件代码生成 ## 触发场景 用户要求根据蓝湖设计稿实现/还原某个前端组件时调用。 典型表达按设计稿把这个按钮做出来 样式按蓝湖来 还原这个页面 ## 前置条件 1. 蓝湖MCP Server已连接可读取设计稿标注。 2. 用户已确认目标页面和组件名称。 3. 已知当前项目的样式方案Tailwind / CSS变量 / 内联样式。 ## 执行步骤 1. 调用 lanhu_list_pages 获取当前项目页面列表定位目标页面。 2. 调用 lanhu_get_annotations 读取页面详情参数需包含页面ID和目标组件名称。 3. 提取关键样式值色值、字号、行高、间距、圆角、阴影。 4. 将px值换算为项目基准值本项目设计稿宽度375pxrem基准为16px。 5. 按项目规范生成组件代码优先使用Tailwind原子类非常规值用CSS变量覆盖。 ## 输出规范 - 组件代码JSX Tailwind className关键变更处加注释。 - 样式规格表Markdown表格列出属性 | 设计稿值 | 实现值 | 来源坐标。 - 差异说明如果实现值与设计稿有偏差必须单独列出原因。 ## 常见错误与回退 - lanhu_get_annotations 返回404目标组件可能未命名改用 lanhu_get_layers 手动遍历图层。 - 设计稿内没有标注截图后调用 vision 能力自行估算并在差异说明里标注估算值。 - 项目样式方案未确认先询问用户绝不默认假设。这个Skill看起来不长但已经有SOP那味儿了。关键是把团队踩过的坑写进常见错误与回退这就是从个人经验到组织资产的转化。3.3 Skills怎么安装、怎么管理从GitHub手动装到企业内部私有库热词里有个很常见的问题claude code怎么手动装github上的skills。网上很多Skill是公开在GitHub仓库里的手动安装的路径很简单把仓库里的skills目录克隆到本地的~/.claude/skills/用户级或者项目的.claude/skills/项目级重启客户端后Agent就能识别。企业内部我更建议走另一条路把Skills当代码一样管。建一个内部Git仓库专门放团队技能包目录按域划分前端还原、订单售后、数据分析、安全测试等新增或修改Skill要走MR评审评审重点不是格式漂不漂亮而是执行步骤是否和当下业务一致、回退策略是否有实际踩坑依据。3.4 Skills和MCP的搭配哲学工具手法缺一不可Skills不只是MCP的辅助它承载的是方法论。我给你举一个实际对比只给Agent Playwright MCP它能打开浏览器、能点击页面但你让它跑一遍登录流程回归测试它每次写的用例都不一样今天忘了等验证码、明天忘了断言跳转。接上E2E回归Skill之后Agent知道要先加载登录页、填写账号、等待验证码自动识别、断言URL变化输出一套稳定的测试用例。Skills是让Agent从会的模型变成做得好用的助手的关键一层。没有Skills的MCP接入只是给了模型一堆遥控器没教它怎么开飞机。4. DeepAgents编排层sub-agents任务委派与架构设计工具和能力都准备好了接下来是超级多智能体的核心大脑分工。4.1 为什么选DeepAgents而不是裸写LangGraphLangGraph是LangChain的低阶编排库灵活度非常高但代价是很多东西要自己造轮子子Agent的状态管理、任务断点、上下文传递、失败重试全要自己写。DeepAgents在这之上封装了一层开箱即用地提供Sub-agent管理、动态任务规划和结果汇总对团队来说意味着从搭框架变成填业务逻辑。企业项目最怕的不是框架不够灵活而是开发周期太长、排错太困难。DeepAgents的另一个好处是可观测性好每个子Agent的执行过程都有独立追踪出了问题能快速定位是哪个环节。这一点我在生产环境里深有体会——裸写LangGraph的时候一个跨五个Agent的流程挂掉光查状态就要一小时用DeepAgents的追踪机制五分钟就能定到具体节点。4.2 一个可落地的工单场景总控Agent、执行Agent、质检Agent回到电商工单案例我实际设的架构是这样的你可以把这个结构直接搬到你自己的业务里总控Agent入口接收用户工单识别意图判断工单类型退款、物流、商品咨询决定创建哪个执行Agent最后汇总质检结果回复用户。退款处理Agent挂载订单查询MCP和退款政策Skill负责查订单、算退款金额、核对退款条件。成功后输出结构化结果。物流追查Agent挂载物流查询MCP和物流异常处理Skill负责查物流节点判断异常、生成催件/赔付建议。质检Agent不碰业务工具只做复核——检查退款金额是否符合政策、话术是否包含承诺时效、是否有遗漏信息。这是防止AI直接面对用户的最后一道安全阀。这个架构的精髓在于每个Agent业务边界非常清晰上下文窗口只装自己需要的信息。总控Agent不需要知道退款计算逻辑质检Agent不需要知道物流接口长什么样它们只需要交换结构化结果。4.3 什么任务该拆给sub-agents什么不该拆很多团队刚上手DeepAgents时特别兴奋什么任务都想拆给子Agent干结果性能不升反降。我总结了一个简单判断标准任务特征是否拆分子Agent需要不同的专业工具集如查订单查物流写话术拆需要并行探索多个方案如竞品分析、多个技术选型对比拆执行链路线性、上下文很短如把这段文字翻译成英文不拆要求强上下文一致性如长文书稿的逐章续写谨慎拆拆了要设计好汇总协议需要大量历史会话记忆不拆单Agent带长期记忆更简单拆分的本质是降低单次任务的上下文负担。当你发现一个Agent的prompt里塞了太多角色和职责时就是该拆的时候了。4.4 给子Agent的指令模板与终止条件设置在DeepAgents里子Agent的成功率很大程度取决于创建时给的指令。我经过多次实测发现一个比较稳的指令模板包含四段信息任务目标用一句话说清楚完成什么、标准是什么。输入来源明确交代从哪个上下文变量里拿数据。输出对象结果交给谁用什么格式JSON还是Markdown。错误处理什么情况下可以直接重试什么情况下必须上报。终止条件方面DeepAgents底层支持设置子Agent的迭代上限或者是判定条件。实务中我强烈建议每个子Agent都设一个**任务状态标记**completed任务完成、needs_review需要人工介入、failed无法继续。总控Agent拿到标记后再决定汇总还是重新派发这样比靠Response为空判断成功靠谱得多。5. A2A协议让不同体系的Agent能互相交接任务DeepAgents解决的是系统内部的分工但企业里往往还有别的部门用别的框架建的Agent甚至会有供应商提供的Agent服务。这时候A2A就派上用场了。5.1 A2A解决的核心问题与几个基础概念A2A的定位和MCP完全不同MCP管的是Agent到工具A2A管的是Agent到Agent。它提供了一套公共的任务交接协议让异构Agent系统之间能进行任务创建、状态上报、结果回传。几个核心概念我用大白话解释Agent CardAgent的公开简历。里面写明这个Agent能干什么、怎么调用、需要什么鉴权。企业应用里每个Agent系统启动时都会发布一份Agent Card。Task对象A2A里的任务载体有固定的生命周期created → working → completed / failed所有参与者都能看到任务状态。Artifact任务产生的交付物。可以是一段文字、一个JSON、一个文件引用。A2A协议把它们挂到Task下面。Message/事件流Agent之间的消息和事件通知支持流式反馈A2A不是发个请求等同步返回的RPC风格而是更接近真实工作场景里的异步协作。5.2 企业里的三种A2A落地模式我实测下来不同企业架构适合不同的A2A落地方式第一种网关代理模式最常用。公司内部有多个Agent系统但统一由一个中央网关暴露给外部使用。中央网关读所有Agent的Agent Card收到外部任务后按能力路由到对应Agent。这个模式对调用方最友好也方便统一鉴权。第二种消息队列托管模式。如果企业内部已经有Kafka或RabbitMQ可以把A2A的Task事件映射到消息队列里。创建任务、更新状态、回传结果全走MQ做异步解耦。适合任务量大、需要削峰的场景。第三种共享任务库Webhook模式。用一个共享数据库存任务状态Agent之间通过Webhook互相通知我更新了一件任务。适合跨团队维护成本较低的中小规模场景排错也比较直观。5.3 一次真实的跨系统A2A协作流程假设我们自研的DeepAgents系统系统A需要把物流工单转给第三方ERP团队的Agent系统系统B处理。A2A的流程大概是系统A读取系统B的Agent Card确认它支持logistics_exception_handle能力。系统A创建了一个Task把订单号、异常类型、期望结果写进去发给系统B的A2A端点。系统B的Agent收到Task用自己的工具和Skill处理过程中不断把Task状态更新为working如果处理耗时较长会通过消息流推一个预计完成时间。处理完成系统B把Task标记为completed并在Artifact里附上处理结论赔付/催件/转人工。系统A订阅到Task完成事件拉取Artifact汇总进总控Agent的最终回复。关键点是A2A不要求双方共享任何内部实现。系统B内部用的是什么框架、哪个模型、哪种工具系统A完全不关心。这就是协议层的价值。6. 全流程实战从0到1把四个组件串起来跑通一条工单理论讲得再多不如把流程跑一遍。这一节我直接给出一份可以照着走的实操路径仍然以电商智能工单为例。6.1 项目目录规划与工作流设计先规划目录结构把不同组件的文件分清楚agent-workspace/ ├── mcp/ │ ├── order-server/ # 自研订单MCP Server │ └── mcp-config.json # 全局MCP Server注册表 ├── skills/ │ ├── refund-policy/ # 退款政策Skill │ │ ├── SKILL.md │ │ └── policies/ # 政策原文快照 │ ├── logistics-exception/ # 物流异常处理Skill │ │ ├── SKILL.md │ │ └── scripts/ # 催件话术生成脚本 │ └── quality-check/ # 质检Skill │ └── SKILL.md ├── agents/ │ ├── dispatcher.py # 总控Agent逻辑 │ ├── refund_agent.py # 退款子Agent │ ├── logistics_agent.py # 物流子Agent │ └── qa_agent.py # 质检子Agent └── a2a/ └── agent-card.json # 本系统的Agent Card声明6.2 配置MCP Server注册表沿用前面给的配置文件把订单查询、物流查询、蓝湖三个Server都注册好。这一步没什么特别但注意环境变量统一管理MCP Server的token不要写死在JSON里用${VAR}引用部署时从环境变量注入。6.3 编写第一个真实可用的退款Policy Skill这个是整个工单系统里业务价值最高的文件。退款政策往往是线上客服最容易答错的部分写进Skill就不用靠模型临时记得了# Skill: 退款政策判定与退款金额计算 ## 触发场景 用户申请退款、售后专员需要判定是否符合退款条件时使用。 ## 前置条件 1. 订单MCP可用能查到订单级信息。 2. 用户提供了订单号或可以从会话上下文推断订单号。 ## 执行步骤 1. 调用 order_query 获取订单状态、商品类目、支付时间、售后状态。 2. 判定退款资格规则按优先级 - 订单状态为已发货且签收超过7天 → 仅支持退货退款不支持仅退款。 - 商品类目为虚拟商品 → 不支持无理由退款。 - 订单存在进行中的售后单 → 报错并提示用户已有售后单。 3. 计算退款金额原支付金额 - 已使用优惠券分摊 - 已发货运费如非质量问题。 4. 输出退款结论与依据依据需引用具体政策条款编号。 ## 输出规范 - JSON结构{eligible: bool, reason: string, refund_amount: float, policy_ref: string} - 给用户的自然语言答复由质检Agent另行生成本Skill只输出判定结果。 ## 常见错误与回退 - 订单查不到先用 order_query 查用户最近订单匹配商品和时间。 - 用户拒绝提供订单号给出模糊判定结果但eligible标记为false。 - 优惠券分摊规则缺失按未使用优惠券则不分摊处理并在reason中注明。这份文件的价值在于退款判定规则如果不沉淀成Skill每次对话模型都会重新发挥一遍今天判A明天判B企业根本没法接受这种不确定性。Skill写完后同样的输入永远走同样的规则链条。6.4 定义DeepAgents编排流程这一步是在代码里初始化DeepAgents把总控Agent和三个子Agent组织起来。核心代码逻辑用伪代码说明# agents/dispatcher.py 核心逻辑 # 1. 总控Agent接收用户工单 # 2. 意图识别基于轻量模型或规则分类器 # 3. 按意图创建子Agent任务 # - 退款类 - refund_agent order_mcp refund_policy_skill # - 物流类 - logistics_agent logistics_mcp logistics_exception_skill # 4. 子Agent执行结束后将结构化结果交给qa_agent # 5. 质检通过后总控Agent生成最终答复6.5 一次完整任务跑通的实测记录按这个配置我实际跑了一次订单超时未发货帮我催一下的工单完整链路是这样的Step 1总控Agent收到用户消息识别出意图为物流异常催促并且用户关联的订单只有一笔在途订单。Step 2总控Agent创建物流追查子Agent附上订单号和重点判断是否超时的指令。Step 3物流子Agent加载物流异常Skill按步骤调用物流MCP查物流节点发现最新节点停留在两天前判定为疑似超时。Step 4物流子Agent按照Skill的回退策略再调一次订单MCP检查预计送达时间确认确实已超过承诺时效于是标记completed输出涉嫌超时建议催件结构化结论。Step 5总控Agent把结论发给质检Agent。质检Agent核查关键要素有没有查完所有节点、结论依据是否完整。核查通过。Step 6总控Agent按物流Skill中的模板生成催件话术在原文中带上订单号和预计承诺时效回复用户您的订单已确认超时我们已记录催办预计24小时内更新物流信息。整个过程从用户发消息到回复耗时约18秒。如果放在原来的单体Agent架构下这一步的判定依据和话术质量很难稳定复现。6.6 失败回退机制和审计日志的关键字段企业级系统不能只考虑成功路径。我在这套系统里给每个子Agent都定了三条失败处理规则MCP调用超时重试一次仍失败则子Agent标记failed总控Agent转人工。子Agent输出的JSON解析失败重新创建同一任务的子Agent最多两次。质检不通过将原因附在原结论后重新派发给原执行Agent修订一次。审计日志我们统一记录了这些字段任务ID、Agent名称、MCP调用名、工具入参出参摘要、加载的Skill名、耗时、结果状态。出了线上问题按任务ID直接拉全链路追踪效率非常高。7. 我踩过的一些坑和现在的规避方法最后这部分是纯经验账没有踩过的人很难体会到。7.1 上下文爆炸总控Agent把子Agent的完整结果全塞进上下文第一次搭的时候我把每个子Agent的输出原封不动拼进总控Agent的上下文想着信息越全总控判断越准。结果跑了几轮任务后总控Agent的上下文开始膨胀回复速度变慢到后面甚至出现把A工单的结论套到B工单上的串味现象。现在我的做法是子Agent只返回结构化摘要和关键引用。比如退款子Agent只返回{eligible: true, amount: 128.5, policy_ref: 2024-7}不返回完整计算过程。如果用户追问细节再临时创建子Agent拉取原始数据。这个按需加载的思路和MCP/Skills的按需挂载其实一脉相承。7.2 工具权限边界写操作暴露太早差点出事上线初期我把修改订单备注也做成了MCP工具本来是想给Agent处理用户留言用的。结果漏测场景里Agent误用了这个工具给一批订单写了错备注。虽然没有造成不可逆损失但把测试团队吓出一身冷汗。教训总结成三条默认只读、写操作二次确认、工具调用全量审计。现在所有写型工具在工具描述里都会强制加上调用前必须取得用户明确确认总控Agent的prompt里也写死这一条。7.3 会调工具和会干活真的是两回事这个项目让我彻底理解了Skills的重要性。我们早期没有写物流异常的SkillDeepAgents调度没问题、MCP调用也顺畅但物流子Agent每次判断是否异常的标准都不一样——今天觉得两天没更新就算异常明天觉得三天才算。我们以为模型出问题了其实是缺少固定的判定标准。把判定规则写进Skill之后输出立刻稳定了。所以如果你正在搭多智能体系统我强烈建议把20%的开发时间留给MCP接入把30%的时间留给写Skills。Skills是让AI输出从看起来合理变成符合你业务逻辑的那一层。7.4 别把A2A用成远程函数调用任务粒度要放大刚接触A2A的时候很容易想当然地把它当成跨Agent的工具调用。我有段时间设计了一个流程总控Agent通过A2A让外部Agent执行每一个小步骤结果网络抖动、任务状态同步问题一大堆维护成本爆表。后来想通了A2A适合传任务不适合传指令。一次A2A交互应该是我把这个任务全权交给你你做完了告诉我结果而不是你执行第一步等我确认后我再通知你执行第二步。任务粒度放大整个系统对网络波动的容忍度大幅提升。外部Agent内部爱怎么编排是它自己的事只要最终回传一个符合约定的Artifact就行。7.5 可观测性必须从第一天就做多智能体系统最大的噩梦是用户说回复有问题你打开日志发现只有一句user inquiry received中间的过程全丢了。没有每个节点的日志你在排错时只能靠猜而AI系统的猜比传统系统更不靠谱因为影响因素太多——模型版本、prompt设置、工具返回、Skill加载状态都可能出问题。我从一开始就把每个环节的可观测数据打全了——总控Agent的决策理由、子Agent的创建指令、MCP工具调用的入参出参、Skill文件版本、A2A的任务事件流。你不想在凌晨两点被叫起来面对一坨黑盒就要在搭建的第一天做好这个基础工程。最后忍不住多嘱咐一句这套技术栈的组合不是越新越好而是每一层都解决了一个真实的工程问题。如果你团队现在的单体Agent还能满足需求不用急着上多智能体但只要你开始感觉到上下文爆炸、工具接入混乱、业务规则难以沉淀或者需要跟外部Agent系统协作那这个四件套组合就是在踩坑最少的前提下能走通的方向。