做过多智能体项目的人应该都有过这种体验单个 Agent 跑得挺顺一旦想把三五个 Agent 串起来协同干活立刻就会遇到一堆跟智能无关的破事——工具调用格式不统一、上下文传不过去、Agent 之间没有共同语言、复用一个能力还得重新写一版逻辑。这些坑我踩了好几个月直到我自己动手搭了一套基于 DeepAgents MCP A2A Skills 的 Agent 集群才算真正把可编排、可互通、可扩展这几个词落到了实处。这套体系解决的核心问题说白了就一句话让每个 Agent 专注干自己擅长的事然后通过标准协议把它们的工具、能力和对话串成一个整体。DeepAgents 负责顶层编排调度MCP 统一了工具接入方式A2A 打通了 Agent 之间的通信Skills 把高频能力沉淀成可复用的技能模块。这篇文章我会把这四个模块的分工、关键实现思路、实操步骤和踩坑记录完整拆开来讲。无论你是刚接触 Agent 开发的小白还是已经把 LangGraph、AutoGen 玩得挺熟的老手这套方案里都有值得参考的东西。1. 整体设计思路为什么是这四个模块组合1.1 单 Agent 的局限与集群化瓶颈先说说我为什么走到了这一步。以前我维护的一个 Agent 应用里塞了翻译、搜索、代码生成、数据库查询十几个能力提示词越来越长工具列表越来越臃肿。表面上功能齐全实际上每次调用都要把一大堆工具定义塞进上下文Token 消耗大模型还经常在多个相似工具之间选错。后来我把能力拆成了多个独立 Agent问题又出现了Agent A 处理完的结果Agent B 拿不到想让 Agent B 调用 Agent A 的能力得自己写 HTTP 接口、定义 JSON 格式、处理鉴权。每加一个 Agent 就要多写一套胶水代码。这个阶段我极度需要一套框架和一个协议来统一这些问题。DeepAgents 给了我一个解决编排问题的起点。它把复杂的任务拆解成一个主 Agent 和多个子 Agentsubagents的树形结构主 Agent 负责理解任务、规划路径子 Agent 负责垂直领域的执行。这样一来编排逻辑从硬编码的 if-else 变成模型的推理决策结构上就灵活得多。1.2 四个模块的职责边界我最终确定的架构分层是这样的编排层DeepAgents负责任务拆解、调度子 Agent、决定调用哪个技能、什么时候需要向用户提问。能力层Skills MCPSkills 是模型的提示词级技能包MCP 是外部工具的标准接入协议。技能负责教模型怎么完成任务MCP 负责让模型能真正操作外部系统。通信层A2A负责 Agent 与 Agent 之间的相互调用。A2A 协议定义了 Agent Card 发现机制、任务状态同步、消息格式让不同框架、不同语言的 Agent 都能互相发现和协作。这个划分的核心思路是把思考和工具彻底解耦。模型负责推理和规划工具通过 MCP 接入技能通过 Skills 加载Agent 之间的协作走 A2A。任何一个 Agent 实例挂了换一个同样能力的 Agent 来顶替对整个集群毫无影响。1.3 这套方案比一个大 Agent 包揽一切好在哪如果你还没体会过多 Agent 集群和单体 Agent 的差别我举个例子。假设你要做一个竞品分析报告需要抓取竞品官网内容、整理用户评论里的关键词、生成一份 Word 文档。单体 Agent 的做法写一个提示词把所有要求全塞进去指望一个大模型自己完成所有步骤。结果往往是工具调用步骤一多就漏步骤上下文被无关的抓取内容污染最后的报告质量完全不可控。集群化做法定义一个 Orchestration Agent 负责拆解任务生成三个子任务抓取任务交给 WebScraper Agent分析任务交给 TextAnalysis Agent文档生成任务交给 DocumentAgent。每个 Agent 都有自己的 Skills 和 MCP 工具集上下文只加载跟自己任务相关的信息。Orchestration Agent 只维护高层级的任务状态不直接处理原始数据。实测下来集群方式的准确率和稳定性都要明显高于单体方式而且每个模块可以独立迭代——文本分析的逻辑改了不需要动抓取逻辑。2. 核心细节解析MCP、A2A、Skills 与 DeepAgents 的关键实现要点2.1 MCP把工具接入变成插拔式标准MCPModel Context Protocol解决的是模型怎么使用工具的标准问题。在没有 MCP 之前每个 Agent 框架都有自己的工具调用格式有的用 OpenAI 的 function calling 格式有的自定义 JSON Schema接入一个新工具就要适配一次。MCP 的思路是做一个类似操作系统驱动的抽象层。工具开发商只要实现一个 MCP Server暴露统一的工具接口任何支持 MCP 的客户端都能直接调用。我当时接入了一个内部的 Wiki 检索系统用了大概半天时间写完 MCP Server然后在多个 Agent 里同时复用这个效率提升是非常直观的。这里重点说一下 MCP Server 的结构。一个最基础的 MCP Server 用 TypeScript 写的话大致是这种感觉import { Server } from modelcontextprotocol/sdk/server/index.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; const server new Server( { name: wiki-search-server, version: 1.0.0 }, { capabilities: { tools: {} } } ); server.setRequestHandler(ListToolsRequestSchema, async () ({ tools: [{ name: search_wiki, description: 搜索内部 Wiki 系统, inputSchema: { type: object, properties: { query: { type: string }, limit: { type: number, default: 5 } }, required: [query] } }] })); server.setRequestHandler(CallToolRequestSchema, async (request) { const { name, arguments: args } request.params; // 在这里调用真实的 Wiki 检索接口 const results await searchWiki(args.query, args.limit); return { content: [{ type: text, text: JSON.stringify(results) }] }; }); const transport new StdioServerTransport(); await server.connect(transport);写 MCP Server 时最容易翻车的点是工具描述的措辞。模型是根据 description 来决定什么时候调用这个工具的描述里必须包含什么时候用和怎么用两个信息。比如搜索内部 Wiki 系统当用户想要查找项目文档、技术规范、设计文档时使用query 参数建议提取用户问题的核心名词短语。这种描述比简单写一句搜索 Wiki要可靠得多。2.2 A2AAgent 之间怎么发现、怎么对话如果说 MCP 解决的是Agent 用工具的问题A2AAgent-to-Agent解决的就是Agent 用 Agent的问题。A2A 协议有几个关键概念Agent Card、Task、Message。Agent Card 是一个 JSON 文件描述了一个 Agent 的能力、端点地址和认证方式相当于 Agent 的名片。客户端拿到这张名片就知道另一个 Agent 能干什么、怎么调用它。Task 是一次具体请求的单元包含状态submitted、working、completed、failed 等和工件artifacts即处理结果。Message 分管线和用户消息两类用来传递多轮对话内容。在实际集群里我通常在 DeepAgents 的子 Agent 中包装一层 A2A 客户端。比如集群里有一个独立的翻译 Agent它内部用的是 LangGraph对外暴露了 A2A 接口。主 Agent 要翻译内容时不是直接调用本地函数而是通过 A2A 协议向这个翻译 Agent 发一个 Task然后轮询任务状态拿到翻译结果。这种跨框架互通的测试我做过一次同样是把英文 PDF 转成中文摘要我分别用了基于 DeepAgents 的 Node 进程和基于 Python 的独立服务两边只是通过 A2A 消息互调完全没有共享代码库。整个过程顺利得让我有点意外这要归功于 A2A 把交互数据格式约束得很清晰。2.3 Skills如何把经验沉淀成可复用技能Skills 跟前两者不一样它更偏向提示词层面的能力封装。一个 Skill 就是一个文件夹里面通常包含一个 SKILL.md 文件描述这个技能的使用场景、工作流程和注意事项还可以附带参考代码片段。举例来说我写过很多次前端页面交付的工作流每次都要处理相同的步骤先分析设计稿再生成组件结构接着写样式最后检查响应式布局。后来我把这套流程整理成了一个名叫做 frontend-delivery 的 Skill模型加载这个 Skill 后就会自动按这套流程走输出质量稳定得多。一个 Skill 的目录结构大致是这样frontend-delivery/ ├── SKILL.md ├── templates/ │ └── component-template.tsx └── references/ └── style-guide.mdSKILL.md 的开头最好直接说明触发条件比如当用户要求根据设计稿或线框图实现前端页面时使用本技能。正文部分写工作流程的五个步骤每个步骤里写明输入输出和检查项。我建议不要写得像操作手册而要写得像老手给新手的叮嘱——重点是提醒模型在哪个环节容易出错、哪个环节必须检查。Skills 的真正威力在于组合。我现在把 MCP 工具调用也封装成了 Skill模型加载这个 Skill 之后就知道应该先查看有哪些工具、判断参数类型、再发起调用而不是胡猜参数。数学建模类的需求我会加载一个包含线性回归、时间序列分析、蒙特卡洛模拟提示词的 Skill效果相当于给模型装了一个数模经验包。2.4 DeepAgents 编排模型主 Agent 与子 Agent 的任务树DeepAgents 的核心概念我之前提过是主 Agent 加若干 subagents 的结构。跟 LangGraph 那种显式定义状态机的思路不同DeepAgents 更倾向于让模型在运行时动态决定下一步调哪个子 Agent。在实操中我通常这样定义一个子 Agentfrom deepagents import Agent def create_web_researcher(): 创建一个专门负责网页抓取与信息汇总的子 Agent return Agent( nameweb_researcher, modeldeepseek-chat, instructions你负责抓取网页内容并提取关键信息输出的信息必须结构化包含来源链接、主要观点、时间戳。, skills[web_search, news_extractor], mcp_servers[fetch-server, search-server] )这个子 Agent 有独立的名字、模型、Skills 和 MCP 工具集。主 Agent 在决策时会把子 Agent 的能力摘要作为上下文的一部分摘要来自 DeepAgents 在注册时自动生成的功能描述也是由模型生成的。我踩过的一个坑是子 Agent 的主模型默认输出返回给主 Agent 时会带上大量的中间推理过程导致上下文迅速膨胀。后来我在定义子 Agent 时明确要求输出只包含最终结果的结构化 JSON不要解释过程上下文消耗立刻降下来的同时任务完成率反而提高了。3. 实操过程从零搭建一个三节点 Agent 集群3.1 环境准备与架构规划下面我完整展示一下我是怎么搭建一个最小但完整的多 Agent 集群的。这个集群包含三个节点一个编排主 Agent一个负责内容检索的子 Agent一个负责报告生成的子 Agent。我的技术选型是编排层用 DeepAgents 框架工具接入走 MCP子 Agent 之间的远程调用走 A2A报告生成能力用 Skills 封装。整体跑在 Node 和 Python 混合的环境里用 Docker Compose 管理各服务的生命周期。首先准备好环境依赖# Node 环境用于 MCP Server 和 A2A 网关 npm install -g modelcontextprotocol/sdk # Python 环境用于 DeepAgents 编排层 pip install deepagents langchain-openai # 本地启动一个 A2A 网关服务这里用 Python 实现 pip install a2a-sdk说实话第一次搭这种多组件环境时最烦的就是依赖版本互相打架。我建议用一个全新的 Python 虚拟环境Node 也尽量不要用系统自带的旧版本。我的做法是在项目根目录建了一个 .python-version 和 .nvmrc锁死版本避免半个月后重装时昨天还能跑今天全挂了的窘境。3.2 第一个实验编写一个可复用的检索 Skill这个集群里最先要沉淀的是内容检索能力。我写了一个名为 web-research 的 Skill目录下有两个文件SKILL.md 和一个回调脚本 research_helper.py。SKILL.md 的一部分内容我贴出来# Web Research Skill 当用户要求查找资料、验证事实、收集行业动态时使用。 ## 工作流程 1. 将用户问题拆解为 2-3 个搜索关键词组合覆盖不同常识面。 2. 使用 web_search 工具搜索优先选择权威来源官网/学术/新闻报道。 3. 对每一篇结果提取标题、时间、核心结论、数据点存入结构化列表。 4. 如果搜索结果互相矛盾保留冲突信息并标注信息冲突。 5. 最终输出 JSON 数组每个元素包含 source、title、summary、timestamp。 ## 注意事项 - 不要只取第一页的搜索结果尽量用不同的关键词组合交叉验证。 - 对数据的引用必须附上来源链接宁缺毋滥。这个 Skill 在 DeepAgents 里注册之后主 Agent 会在检索类任务上自动加载它。我遇到的一个小问题是刚开始写的 Skill 描述太宽泛导致 Agent 在写文案这种任务时也调用它。后来我在描述里加了触发条件问题就消失了。3.3 实战配置 MCP Server 并接入检索工具接下来是最关键的 MCP Server。我写了一个很轻量的 HTTP 抓取服务用 Node 实现通过 MCP SDK 暴露成一个工具// fetch-server.js import { Server } from modelcontextprotocol/sdk/server/index.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import fetch from node-fetch; import * as cheerio from cheerio; const server new Server( { name: fetch-server, version: 1.0.0 }, { capabilities: { tools: {} } } ); async function fetchPage(url) { const response await fetch(url, { headers: { User-Agent: Mozilla/5.0 (compatible; MyAgentCluster/1.0) } }); if (!response.ok) throw new Error(HTTP ${response.status}); const html await response.text(); const $ cheerio.load(html); $(script, style, noscript).remove(); return $(body).text().replace(/\s/g, ).trim().slice(0, 8000); } server.setRequestHandler(ListToolsRequestSchema, async () ({ tools: [{ name: fetch_webpage, description: 抓取指定 URL 的正文文本内容用于资料收集和信息提取。, inputSchema: { type: object, properties: { url: { type: string, description: 完整 URL必须以 http/https 开头 }, maxLength: { type: number, default: 8000 } }, required: [url] } }] })); server.setRequestHandler(CallToolRequestSchema, async (request) { if (request.params.name ! fetch_webpage) { throw new Error(未知工具: ${request.params.name}); } const { url, maxLength } request.params.arguments; const text await fetchPage(url); return { content: [{ type: text, text: text.slice(0, maxLength) }] }; }); const transport new StdioServerTransport(); await server.connect(transport);启动 MCP Server 的方式是把它作为独立进程跑然后在 DeepAgents 配置里指定它的启动命令。配置完成后主 Agent 就能通过模型自主决策调用这个线上抓取能力了。这里有一个容易被忽略的配置项MCP Server 的超时设置。我在测试时发现某些页面响应很慢默认的超时时间根本不够用。我把超时调到了 30 秒并给工具的 description 里加了一句适合内容型页面不适合大文件或登录页模型会据此判断何时使用这个工具。3.4 核心操作注册 A2A 网关串联多 Node Agent接下来是 A2A 部分。我的做法是给两个子 Agentretriever 和 reporter各挂一个 A2A 网关主编排节点通过网关向它们派发任务。下面用 Python 实现一个最小的 A2A Agent 服务端from a2a_sdk import AgentServer, InProcessAgent from a2a_sdk.types import AgentCard, AgentCapability async def retrieve_agent(task_input: str) - str: 执行检索任务这里实际调用本地检索函数 results await local_search(task_input) return json.dumps(results, ensure_asciiFalse) async def report_agent(task_input: str) - str: 执行报告生成任务加载 Skills 中的模板 prompt load_skill(report_generator) rendered await llm_call(prompt, task_input) return rendered retriever_server AgentServer( agentInProcessAgent(handlerretrieve_agent), cardAgentCard( nameRetrieverAgent, description负责全网信息检索与去重汇总, urlhttp://localhost:8001, capabilities[AgentCapability(idretrieve, description输入检索需求返回结构化信息)] ) ) reporter_server AgentServer( agentInProcessAgent(handlerreport_agent), cardAgentCard( nameReporterAgent, description负责生成各类结构化报告, urlhttp://localhost:8002, capabilities[AgentCapability(idreport, description输入数据返回 Markdown 报告)] ) )这两个服务启动之后编排层通过 A2A 协议发现它们。DeepAgents 里的主 Agent 在收到帮我写一份关于智能家居行业的调研报告这个任务时会先向 retriever 派发检索任务拿到结构化信息后再向 reporter 派发报告生成任务。实测下来A2A 的最大价值在于这两个服务可以是完全独立的进程甚至可以用不同技术栈实现——一个用 Python一个用 Node互不影响。这也是可互通的核心。3.5 完整编排流程验证最后我把整个流程串起来验证了一遍。主 Agent 收到任务后通过 DeepAgents 的规划能力生成任务树子任务一调用 retriever子任务二调用 reporter子任务三合并输出。关键的一段编排逻辑大概长这样from deepagents import Agent async def orchestrator(): main_agent Agent( nameorchestrator, instructions 你是一个任务编排 Agent。收到用户请求后拆解为检索和报告两个子任务。 先调用 RetrieverAgent 获取资料再调用 ReporterAgent 生成报告最后汇总给用户。 不要跳过检索步骤直接生成报告。 , a2a_agents[retriever, reporter] ) result await main_agent.run( 写一份2025年消费级AI硬件趋势报告要求包含市场规模、主要玩家、技术路线对比 ) print(result.output)这个流程跑通之后我就有了一条原则任何新的业务能力先试着封装成 Skill 或者 MCP Server而不是直接写死在编排逻辑里。这一个原则让我后续扩展集群时省了非常多的事。4. 常见问题与排查技巧实录4.1 主 Agent 连续调用工具导致上下文爆炸这是我最先遇到的问题。主 Agent 在编排多个子任务时会把每个子任务的完整输入输出都保留在上文里几轮之后上下文就快撑爆了Token 费用也直线上升。我的解决办法是给子 Agent 的返回结果做摘要压缩。在子 Agent 的 instructions 里明确要求返回内容只包含结论和关键数据控制在一百字以内。如果确实需要完整内容就写入临时文件返回一个文件路径引用。实测下来同样任务的上下文消耗减少了约 60%编排效果没有明显下降。4.2 工具并行调用时相互污染MCP 支持多个工具在一次回复内并行调用但如果不做隔离会出现一个工具的输入跑到另一个工具的请求里。这个问题的根源是工具名冲突或参数命名模糊。我的排查思路是给每个 MCP Server 分配独立命名空间工具名尽量用带前缀的形式例如 fetch_server_webpage 而不是 webpage。另外在 MCP Server 内部加上入参强校验参数类型不对直接报错不要静默忽略。这样一旦出错立刻能在日志里定位到是哪一步导致的。4.3 A2A 任务卡在 working 状态A2A 的 Task 状态机里有一个常见的卡死状态任务提交后一直处于 working客户端一直轮询不到 completed。我遇到的真实原因是子 Agent 处理过程中异常退出了但没有更新 Task 状态导致主 Agent 一直傻等。我在 A2A 网关里加了保底逻辑服务端超过 120 秒没有返回进度就把任务标记为 failed并附上超时原因。客户端则加了重试机制允许对同一个 Task 重新提交一次。这条保底逻辑上线之后集群长时间无人值守运行时的成功率上了很多。4.4 Skills 之间的优先级冲突多个 Skill 同时加载时会出现指令冲突比如一个 Skill 说输出 JSON另一个说输出 Markdown模型就懵了。我的经验是Skills 描述里不写具体的输出格式要求而是统一放到编排层的系统提示词里。SKILL.md 只专注于任务怎么做和注意什么不碰最终输出长什么样。这样冲突面就小了很多如果系统提示词本身有变更也只改一处。4.5 模型在编排时跳过高价值步骤模型为了省事经常在编排时跳过真正有价值的中间步骤直接生成答案。比如分析类任务它可能不先取数就直接给结论。解决方法是给步骤定义成败标准。我在子 Agent 的输出里增加了一个evidence字段要求必须包含实际检索到的数据或外部引用。主 Agent 判断用户请求涉及事实性问题时如果子 Agent 返回的内容里没有 evidence就判定该步骤未完成触发重跑。5. 集群扩展与性能调优心得5.1 从三节点扩展到十节点的关键改进我的集群从三节点扩展到十个节点之后遇到了几个新问题。第一个是 MCP Server 进程太多管理成本剧增。后来我统一用 Docker Compose 管理所有 MCP Server每个 Server 一个容器启动、重启、日志查看都规范起来。第二个是子 Agent 的功能描述互相重叠编排模型分不清该调哪个。我在注册 A2A Agent 时给每个 Agent 的 Agent Card 加上了明确的 capability 标签并在描述里写上不支持什么。比如检索 Agent 明确写不负责内容总结总结 Agent 明确写不负责原始信息采集。这种边界约束让编排准确率提高了不少。5.2 三类任务的性能对比我把集群上线后实际处理过的一组任务数据整理成了一张对比表供大家参考任务类型单体 Agent 耗时集群方式耗时集群方式错误率备注竞品信息搜集与汇总约 2.5 分钟约 1.2 分钟明显降低检索 Agent 并行处理效果显著长文档翻译与摘要约 4 分钟约 3 分钟略有降低上下文隔离减少混淆结构化周报生成约 3 分钟约 2 分钟降低一半以上Skills 复用加快格式化速度这套数据不是严谨的基准测试但趋势很明确任务越复杂、所需工具越多集群化的收益就越明显。如果是简单的一问一答单体 Agent 反而更快这也是取舍时需要衡量的。5.3 成本优化如何削减 Token 消耗多 Agent 集群最肉疼的就是 Token 成本。每个子 Agent 都要独立消耗上下文主 Agent 还要带着一堆子任务状态。我做了几项优化效果很直接。第一模型分层简单的工具调用走便宜的小模型复杂的规划与报告走能力更强的大模型。第二上下文瘦身MCP 工具返回结果最大长度从 8000 字下调到 4000 字检索类结果做完摘要再写回上下文。第三A2A 任务结果的保留策略完成任务的结果只保留最终 artifact中间状态直接丢弃。这几项加起来单次复杂任务的 Token 成本降了约四成。6. 安全边界与集群治理经验6.1 MCP 工具的权限控制多 Agent 集群里的每个子 Agent 都开放 MCP 工具权限如果不控制风险很大。我在 MCP Server 上加了一层工具白名单配置每个子 Agent 只能调用自己被授权的工具。比如公开页面抓取工具对所有 Agent 开放但内部系统查询工具只对特定的内部 Agent 开放。这个白名单机制不用写得很复杂一个 JSON 配置加中间层校验就够了。关键是要在架构设计阶段预留这个位置而不是等出问题了再加。6.2 Skills 的版本管理Skills 是文本文件天然适合做版本管理。我建议把所有 Skills 放进 Git 仓库里每次变更都走 MR 审查流程。原因很简单一个 SKILL.md 的小改动可能影响集群里所有加载它的 Agent 的行为。没有版本管理出问题之后根本无法回溯。我自己维护了一套 Skills 的目录规范stable 目录放经过验证的技能beta 目录放还在迭代的技能deprecated 目录放废弃技能。主 Agent 默认只加载 stable 目录里的技能需要试用 beta 技能时手动指定。6.3 集群可观测性日志与追踪多 Agent 集群的调试比单体难很多一个任务可能横跨多个进程和多个工具。我目前的方案是统一结构化日志每个请求携带一个 trace_id所有子 Agent、MCP Server 在日志里附带这个 trace_id。排查问题时一条命令过滤出来按时间线重新拼装整个任务流转过程。A2A 网关里我也会记录 Task 的每次状态变化。这让我能精确还原任务哪一步开始、哪一步卡住、最终返回了什么。这套可观测基础设施让集群规模从 5 个节点扩到 10 个节点时维护成本没有线性上涨。7. 未来扩展方向从集群到生态7.1 把 A2A 升级为跨组织协作当每个团队甚至每家公司都把自己的 Agent 通过 A2A 标准暴露出来Agent 就能跨组织协作。现在 A2A 协议已经支持 Agent Card 的公开发现机制理论上两个独立团队部署的 Agent 可以直接互相调用。你可以想象成你的 Agent 能直接调用另一个团队的行业报告生成 Agent只要双方遵循同一套协议。这就是标题里可互通的深层价值。7.2 从技能包到技能市场Skills 做多了之后我发现完全可以做一个本地的 Skill Registry每个 Skill 有名称、作者、版本、描述和依赖的 MCP Server 列表。主 Agent 在启动的时候会自动拉取最新技能清单。未来如果能力足够甚至可以做一个开放技能市场让开发者提交各自的 Skills 供社区使用。7.3 编排策略的持续进化DeepAgents 的编排目前还是模型自由发挥为主但它也支持给主 Agent 提供结构化的规划模板。我下一步的计划是把过去成功的编排路径沉淀成模板。比如调研报告类任务固定使用 retriever - reporter - formatter 的流程数据分析类任务固定使用 dataloader - analyzer - visualizer 的流程。有了这些模板模型做规划的稳定性会更高新场景下的初始化过程也更可控。最后再说一个我在整个实践中最有感触的点这套体系里最值得投入时间打磨的不是模型本身而是 Skills 和 MCP Server 的质量。工具定义得清楚、技能描述得准确集群的表现会有质的飞跃反过来工具定义含糊、技能互相矛盾再强的模型也带不动。我现在的习惯是每写完一个 Skill就用一组典型任务实测一遍迭代两三轮之后再放进 stable 目录。这种以工具质量为抓手的思路比在提示词上反复调参要有效得多。
打造可编排可互通的多智能体集群：DeepAgents+MCP+A2A+Skills实战
做过多智能体项目的人应该都有过这种体验单个 Agent 跑得挺顺一旦想把三五个 Agent 串起来协同干活立刻就会遇到一堆跟智能无关的破事——工具调用格式不统一、上下文传不过去、Agent 之间没有共同语言、复用一个能力还得重新写一版逻辑。这些坑我踩了好几个月直到我自己动手搭了一套基于 DeepAgents MCP A2A Skills 的 Agent 集群才算真正把可编排、可互通、可扩展这几个词落到了实处。这套体系解决的核心问题说白了就一句话让每个 Agent 专注干自己擅长的事然后通过标准协议把它们的工具、能力和对话串成一个整体。DeepAgents 负责顶层编排调度MCP 统一了工具接入方式A2A 打通了 Agent 之间的通信Skills 把高频能力沉淀成可复用的技能模块。这篇文章我会把这四个模块的分工、关键实现思路、实操步骤和踩坑记录完整拆开来讲。无论你是刚接触 Agent 开发的小白还是已经把 LangGraph、AutoGen 玩得挺熟的老手这套方案里都有值得参考的东西。1. 整体设计思路为什么是这四个模块组合1.1 单 Agent 的局限与集群化瓶颈先说说我为什么走到了这一步。以前我维护的一个 Agent 应用里塞了翻译、搜索、代码生成、数据库查询十几个能力提示词越来越长工具列表越来越臃肿。表面上功能齐全实际上每次调用都要把一大堆工具定义塞进上下文Token 消耗大模型还经常在多个相似工具之间选错。后来我把能力拆成了多个独立 Agent问题又出现了Agent A 处理完的结果Agent B 拿不到想让 Agent B 调用 Agent A 的能力得自己写 HTTP 接口、定义 JSON 格式、处理鉴权。每加一个 Agent 就要多写一套胶水代码。这个阶段我极度需要一套框架和一个协议来统一这些问题。DeepAgents 给了我一个解决编排问题的起点。它把复杂的任务拆解成一个主 Agent 和多个子 Agentsubagents的树形结构主 Agent 负责理解任务、规划路径子 Agent 负责垂直领域的执行。这样一来编排逻辑从硬编码的 if-else 变成模型的推理决策结构上就灵活得多。1.2 四个模块的职责边界我最终确定的架构分层是这样的编排层DeepAgents负责任务拆解、调度子 Agent、决定调用哪个技能、什么时候需要向用户提问。能力层Skills MCPSkills 是模型的提示词级技能包MCP 是外部工具的标准接入协议。技能负责教模型怎么完成任务MCP 负责让模型能真正操作外部系统。通信层A2A负责 Agent 与 Agent 之间的相互调用。A2A 协议定义了 Agent Card 发现机制、任务状态同步、消息格式让不同框架、不同语言的 Agent 都能互相发现和协作。这个划分的核心思路是把思考和工具彻底解耦。模型负责推理和规划工具通过 MCP 接入技能通过 Skills 加载Agent 之间的协作走 A2A。任何一个 Agent 实例挂了换一个同样能力的 Agent 来顶替对整个集群毫无影响。1.3 这套方案比一个大 Agent 包揽一切好在哪如果你还没体会过多 Agent 集群和单体 Agent 的差别我举个例子。假设你要做一个竞品分析报告需要抓取竞品官网内容、整理用户评论里的关键词、生成一份 Word 文档。单体 Agent 的做法写一个提示词把所有要求全塞进去指望一个大模型自己完成所有步骤。结果往往是工具调用步骤一多就漏步骤上下文被无关的抓取内容污染最后的报告质量完全不可控。集群化做法定义一个 Orchestration Agent 负责拆解任务生成三个子任务抓取任务交给 WebScraper Agent分析任务交给 TextAnalysis Agent文档生成任务交给 DocumentAgent。每个 Agent 都有自己的 Skills 和 MCP 工具集上下文只加载跟自己任务相关的信息。Orchestration Agent 只维护高层级的任务状态不直接处理原始数据。实测下来集群方式的准确率和稳定性都要明显高于单体方式而且每个模块可以独立迭代——文本分析的逻辑改了不需要动抓取逻辑。2. 核心细节解析MCP、A2A、Skills 与 DeepAgents 的关键实现要点2.1 MCP把工具接入变成插拔式标准MCPModel Context Protocol解决的是模型怎么使用工具的标准问题。在没有 MCP 之前每个 Agent 框架都有自己的工具调用格式有的用 OpenAI 的 function calling 格式有的自定义 JSON Schema接入一个新工具就要适配一次。MCP 的思路是做一个类似操作系统驱动的抽象层。工具开发商只要实现一个 MCP Server暴露统一的工具接口任何支持 MCP 的客户端都能直接调用。我当时接入了一个内部的 Wiki 检索系统用了大概半天时间写完 MCP Server然后在多个 Agent 里同时复用这个效率提升是非常直观的。这里重点说一下 MCP Server 的结构。一个最基础的 MCP Server 用 TypeScript 写的话大致是这种感觉import { Server } from modelcontextprotocol/sdk/server/index.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; const server new Server( { name: wiki-search-server, version: 1.0.0 }, { capabilities: { tools: {} } } ); server.setRequestHandler(ListToolsRequestSchema, async () ({ tools: [{ name: search_wiki, description: 搜索内部 Wiki 系统, inputSchema: { type: object, properties: { query: { type: string }, limit: { type: number, default: 5 } }, required: [query] } }] })); server.setRequestHandler(CallToolRequestSchema, async (request) { const { name, arguments: args } request.params; // 在这里调用真实的 Wiki 检索接口 const results await searchWiki(args.query, args.limit); return { content: [{ type: text, text: JSON.stringify(results) }] }; }); const transport new StdioServerTransport(); await server.connect(transport);写 MCP Server 时最容易翻车的点是工具描述的措辞。模型是根据 description 来决定什么时候调用这个工具的描述里必须包含什么时候用和怎么用两个信息。比如搜索内部 Wiki 系统当用户想要查找项目文档、技术规范、设计文档时使用query 参数建议提取用户问题的核心名词短语。这种描述比简单写一句搜索 Wiki要可靠得多。2.2 A2AAgent 之间怎么发现、怎么对话如果说 MCP 解决的是Agent 用工具的问题A2AAgent-to-Agent解决的就是Agent 用 Agent的问题。A2A 协议有几个关键概念Agent Card、Task、Message。Agent Card 是一个 JSON 文件描述了一个 Agent 的能力、端点地址和认证方式相当于 Agent 的名片。客户端拿到这张名片就知道另一个 Agent 能干什么、怎么调用它。Task 是一次具体请求的单元包含状态submitted、working、completed、failed 等和工件artifacts即处理结果。Message 分管线和用户消息两类用来传递多轮对话内容。在实际集群里我通常在 DeepAgents 的子 Agent 中包装一层 A2A 客户端。比如集群里有一个独立的翻译 Agent它内部用的是 LangGraph对外暴露了 A2A 接口。主 Agent 要翻译内容时不是直接调用本地函数而是通过 A2A 协议向这个翻译 Agent 发一个 Task然后轮询任务状态拿到翻译结果。这种跨框架互通的测试我做过一次同样是把英文 PDF 转成中文摘要我分别用了基于 DeepAgents 的 Node 进程和基于 Python 的独立服务两边只是通过 A2A 消息互调完全没有共享代码库。整个过程顺利得让我有点意外这要归功于 A2A 把交互数据格式约束得很清晰。2.3 Skills如何把经验沉淀成可复用技能Skills 跟前两者不一样它更偏向提示词层面的能力封装。一个 Skill 就是一个文件夹里面通常包含一个 SKILL.md 文件描述这个技能的使用场景、工作流程和注意事项还可以附带参考代码片段。举例来说我写过很多次前端页面交付的工作流每次都要处理相同的步骤先分析设计稿再生成组件结构接着写样式最后检查响应式布局。后来我把这套流程整理成了一个名叫做 frontend-delivery 的 Skill模型加载这个 Skill 后就会自动按这套流程走输出质量稳定得多。一个 Skill 的目录结构大致是这样frontend-delivery/ ├── SKILL.md ├── templates/ │ └── component-template.tsx └── references/ └── style-guide.mdSKILL.md 的开头最好直接说明触发条件比如当用户要求根据设计稿或线框图实现前端页面时使用本技能。正文部分写工作流程的五个步骤每个步骤里写明输入输出和检查项。我建议不要写得像操作手册而要写得像老手给新手的叮嘱——重点是提醒模型在哪个环节容易出错、哪个环节必须检查。Skills 的真正威力在于组合。我现在把 MCP 工具调用也封装成了 Skill模型加载这个 Skill 之后就知道应该先查看有哪些工具、判断参数类型、再发起调用而不是胡猜参数。数学建模类的需求我会加载一个包含线性回归、时间序列分析、蒙特卡洛模拟提示词的 Skill效果相当于给模型装了一个数模经验包。2.4 DeepAgents 编排模型主 Agent 与子 Agent 的任务树DeepAgents 的核心概念我之前提过是主 Agent 加若干 subagents 的结构。跟 LangGraph 那种显式定义状态机的思路不同DeepAgents 更倾向于让模型在运行时动态决定下一步调哪个子 Agent。在实操中我通常这样定义一个子 Agentfrom deepagents import Agent def create_web_researcher(): 创建一个专门负责网页抓取与信息汇总的子 Agent return Agent( nameweb_researcher, modeldeepseek-chat, instructions你负责抓取网页内容并提取关键信息输出的信息必须结构化包含来源链接、主要观点、时间戳。, skills[web_search, news_extractor], mcp_servers[fetch-server, search-server] )这个子 Agent 有独立的名字、模型、Skills 和 MCP 工具集。主 Agent 在决策时会把子 Agent 的能力摘要作为上下文的一部分摘要来自 DeepAgents 在注册时自动生成的功能描述也是由模型生成的。我踩过的一个坑是子 Agent 的主模型默认输出返回给主 Agent 时会带上大量的中间推理过程导致上下文迅速膨胀。后来我在定义子 Agent 时明确要求输出只包含最终结果的结构化 JSON不要解释过程上下文消耗立刻降下来的同时任务完成率反而提高了。3. 实操过程从零搭建一个三节点 Agent 集群3.1 环境准备与架构规划下面我完整展示一下我是怎么搭建一个最小但完整的多 Agent 集群的。这个集群包含三个节点一个编排主 Agent一个负责内容检索的子 Agent一个负责报告生成的子 Agent。我的技术选型是编排层用 DeepAgents 框架工具接入走 MCP子 Agent 之间的远程调用走 A2A报告生成能力用 Skills 封装。整体跑在 Node 和 Python 混合的环境里用 Docker Compose 管理各服务的生命周期。首先准备好环境依赖# Node 环境用于 MCP Server 和 A2A 网关 npm install -g modelcontextprotocol/sdk # Python 环境用于 DeepAgents 编排层 pip install deepagents langchain-openai # 本地启动一个 A2A 网关服务这里用 Python 实现 pip install a2a-sdk说实话第一次搭这种多组件环境时最烦的就是依赖版本互相打架。我建议用一个全新的 Python 虚拟环境Node 也尽量不要用系统自带的旧版本。我的做法是在项目根目录建了一个 .python-version 和 .nvmrc锁死版本避免半个月后重装时昨天还能跑今天全挂了的窘境。3.2 第一个实验编写一个可复用的检索 Skill这个集群里最先要沉淀的是内容检索能力。我写了一个名为 web-research 的 Skill目录下有两个文件SKILL.md 和一个回调脚本 research_helper.py。SKILL.md 的一部分内容我贴出来# Web Research Skill 当用户要求查找资料、验证事实、收集行业动态时使用。 ## 工作流程 1. 将用户问题拆解为 2-3 个搜索关键词组合覆盖不同常识面。 2. 使用 web_search 工具搜索优先选择权威来源官网/学术/新闻报道。 3. 对每一篇结果提取标题、时间、核心结论、数据点存入结构化列表。 4. 如果搜索结果互相矛盾保留冲突信息并标注信息冲突。 5. 最终输出 JSON 数组每个元素包含 source、title、summary、timestamp。 ## 注意事项 - 不要只取第一页的搜索结果尽量用不同的关键词组合交叉验证。 - 对数据的引用必须附上来源链接宁缺毋滥。这个 Skill 在 DeepAgents 里注册之后主 Agent 会在检索类任务上自动加载它。我遇到的一个小问题是刚开始写的 Skill 描述太宽泛导致 Agent 在写文案这种任务时也调用它。后来我在描述里加了触发条件问题就消失了。3.3 实战配置 MCP Server 并接入检索工具接下来是最关键的 MCP Server。我写了一个很轻量的 HTTP 抓取服务用 Node 实现通过 MCP SDK 暴露成一个工具// fetch-server.js import { Server } from modelcontextprotocol/sdk/server/index.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import fetch from node-fetch; import * as cheerio from cheerio; const server new Server( { name: fetch-server, version: 1.0.0 }, { capabilities: { tools: {} } } ); async function fetchPage(url) { const response await fetch(url, { headers: { User-Agent: Mozilla/5.0 (compatible; MyAgentCluster/1.0) } }); if (!response.ok) throw new Error(HTTP ${response.status}); const html await response.text(); const $ cheerio.load(html); $(script, style, noscript).remove(); return $(body).text().replace(/\s/g, ).trim().slice(0, 8000); } server.setRequestHandler(ListToolsRequestSchema, async () ({ tools: [{ name: fetch_webpage, description: 抓取指定 URL 的正文文本内容用于资料收集和信息提取。, inputSchema: { type: object, properties: { url: { type: string, description: 完整 URL必须以 http/https 开头 }, maxLength: { type: number, default: 8000 } }, required: [url] } }] })); server.setRequestHandler(CallToolRequestSchema, async (request) { if (request.params.name ! fetch_webpage) { throw new Error(未知工具: ${request.params.name}); } const { url, maxLength } request.params.arguments; const text await fetchPage(url); return { content: [{ type: text, text: text.slice(0, maxLength) }] }; }); const transport new StdioServerTransport(); await server.connect(transport);启动 MCP Server 的方式是把它作为独立进程跑然后在 DeepAgents 配置里指定它的启动命令。配置完成后主 Agent 就能通过模型自主决策调用这个线上抓取能力了。这里有一个容易被忽略的配置项MCP Server 的超时设置。我在测试时发现某些页面响应很慢默认的超时时间根本不够用。我把超时调到了 30 秒并给工具的 description 里加了一句适合内容型页面不适合大文件或登录页模型会据此判断何时使用这个工具。3.4 核心操作注册 A2A 网关串联多 Node Agent接下来是 A2A 部分。我的做法是给两个子 Agentretriever 和 reporter各挂一个 A2A 网关主编排节点通过网关向它们派发任务。下面用 Python 实现一个最小的 A2A Agent 服务端from a2a_sdk import AgentServer, InProcessAgent from a2a_sdk.types import AgentCard, AgentCapability async def retrieve_agent(task_input: str) - str: 执行检索任务这里实际调用本地检索函数 results await local_search(task_input) return json.dumps(results, ensure_asciiFalse) async def report_agent(task_input: str) - str: 执行报告生成任务加载 Skills 中的模板 prompt load_skill(report_generator) rendered await llm_call(prompt, task_input) return rendered retriever_server AgentServer( agentInProcessAgent(handlerretrieve_agent), cardAgentCard( nameRetrieverAgent, description负责全网信息检索与去重汇总, urlhttp://localhost:8001, capabilities[AgentCapability(idretrieve, description输入检索需求返回结构化信息)] ) ) reporter_server AgentServer( agentInProcessAgent(handlerreport_agent), cardAgentCard( nameReporterAgent, description负责生成各类结构化报告, urlhttp://localhost:8002, capabilities[AgentCapability(idreport, description输入数据返回 Markdown 报告)] ) )这两个服务启动之后编排层通过 A2A 协议发现它们。DeepAgents 里的主 Agent 在收到帮我写一份关于智能家居行业的调研报告这个任务时会先向 retriever 派发检索任务拿到结构化信息后再向 reporter 派发报告生成任务。实测下来A2A 的最大价值在于这两个服务可以是完全独立的进程甚至可以用不同技术栈实现——一个用 Python一个用 Node互不影响。这也是可互通的核心。3.5 完整编排流程验证最后我把整个流程串起来验证了一遍。主 Agent 收到任务后通过 DeepAgents 的规划能力生成任务树子任务一调用 retriever子任务二调用 reporter子任务三合并输出。关键的一段编排逻辑大概长这样from deepagents import Agent async def orchestrator(): main_agent Agent( nameorchestrator, instructions 你是一个任务编排 Agent。收到用户请求后拆解为检索和报告两个子任务。 先调用 RetrieverAgent 获取资料再调用 ReporterAgent 生成报告最后汇总给用户。 不要跳过检索步骤直接生成报告。 , a2a_agents[retriever, reporter] ) result await main_agent.run( 写一份2025年消费级AI硬件趋势报告要求包含市场规模、主要玩家、技术路线对比 ) print(result.output)这个流程跑通之后我就有了一条原则任何新的业务能力先试着封装成 Skill 或者 MCP Server而不是直接写死在编排逻辑里。这一个原则让我后续扩展集群时省了非常多的事。4. 常见问题与排查技巧实录4.1 主 Agent 连续调用工具导致上下文爆炸这是我最先遇到的问题。主 Agent 在编排多个子任务时会把每个子任务的完整输入输出都保留在上文里几轮之后上下文就快撑爆了Token 费用也直线上升。我的解决办法是给子 Agent 的返回结果做摘要压缩。在子 Agent 的 instructions 里明确要求返回内容只包含结论和关键数据控制在一百字以内。如果确实需要完整内容就写入临时文件返回一个文件路径引用。实测下来同样任务的上下文消耗减少了约 60%编排效果没有明显下降。4.2 工具并行调用时相互污染MCP 支持多个工具在一次回复内并行调用但如果不做隔离会出现一个工具的输入跑到另一个工具的请求里。这个问题的根源是工具名冲突或参数命名模糊。我的排查思路是给每个 MCP Server 分配独立命名空间工具名尽量用带前缀的形式例如 fetch_server_webpage 而不是 webpage。另外在 MCP Server 内部加上入参强校验参数类型不对直接报错不要静默忽略。这样一旦出错立刻能在日志里定位到是哪一步导致的。4.3 A2A 任务卡在 working 状态A2A 的 Task 状态机里有一个常见的卡死状态任务提交后一直处于 working客户端一直轮询不到 completed。我遇到的真实原因是子 Agent 处理过程中异常退出了但没有更新 Task 状态导致主 Agent 一直傻等。我在 A2A 网关里加了保底逻辑服务端超过 120 秒没有返回进度就把任务标记为 failed并附上超时原因。客户端则加了重试机制允许对同一个 Task 重新提交一次。这条保底逻辑上线之后集群长时间无人值守运行时的成功率上了很多。4.4 Skills 之间的优先级冲突多个 Skill 同时加载时会出现指令冲突比如一个 Skill 说输出 JSON另一个说输出 Markdown模型就懵了。我的经验是Skills 描述里不写具体的输出格式要求而是统一放到编排层的系统提示词里。SKILL.md 只专注于任务怎么做和注意什么不碰最终输出长什么样。这样冲突面就小了很多如果系统提示词本身有变更也只改一处。4.5 模型在编排时跳过高价值步骤模型为了省事经常在编排时跳过真正有价值的中间步骤直接生成答案。比如分析类任务它可能不先取数就直接给结论。解决方法是给步骤定义成败标准。我在子 Agent 的输出里增加了一个evidence字段要求必须包含实际检索到的数据或外部引用。主 Agent 判断用户请求涉及事实性问题时如果子 Agent 返回的内容里没有 evidence就判定该步骤未完成触发重跑。5. 集群扩展与性能调优心得5.1 从三节点扩展到十节点的关键改进我的集群从三节点扩展到十个节点之后遇到了几个新问题。第一个是 MCP Server 进程太多管理成本剧增。后来我统一用 Docker Compose 管理所有 MCP Server每个 Server 一个容器启动、重启、日志查看都规范起来。第二个是子 Agent 的功能描述互相重叠编排模型分不清该调哪个。我在注册 A2A Agent 时给每个 Agent 的 Agent Card 加上了明确的 capability 标签并在描述里写上不支持什么。比如检索 Agent 明确写不负责内容总结总结 Agent 明确写不负责原始信息采集。这种边界约束让编排准确率提高了不少。5.2 三类任务的性能对比我把集群上线后实际处理过的一组任务数据整理成了一张对比表供大家参考任务类型单体 Agent 耗时集群方式耗时集群方式错误率备注竞品信息搜集与汇总约 2.5 分钟约 1.2 分钟明显降低检索 Agent 并行处理效果显著长文档翻译与摘要约 4 分钟约 3 分钟略有降低上下文隔离减少混淆结构化周报生成约 3 分钟约 2 分钟降低一半以上Skills 复用加快格式化速度这套数据不是严谨的基准测试但趋势很明确任务越复杂、所需工具越多集群化的收益就越明显。如果是简单的一问一答单体 Agent 反而更快这也是取舍时需要衡量的。5.3 成本优化如何削减 Token 消耗多 Agent 集群最肉疼的就是 Token 成本。每个子 Agent 都要独立消耗上下文主 Agent 还要带着一堆子任务状态。我做了几项优化效果很直接。第一模型分层简单的工具调用走便宜的小模型复杂的规划与报告走能力更强的大模型。第二上下文瘦身MCP 工具返回结果最大长度从 8000 字下调到 4000 字检索类结果做完摘要再写回上下文。第三A2A 任务结果的保留策略完成任务的结果只保留最终 artifact中间状态直接丢弃。这几项加起来单次复杂任务的 Token 成本降了约四成。6. 安全边界与集群治理经验6.1 MCP 工具的权限控制多 Agent 集群里的每个子 Agent 都开放 MCP 工具权限如果不控制风险很大。我在 MCP Server 上加了一层工具白名单配置每个子 Agent 只能调用自己被授权的工具。比如公开页面抓取工具对所有 Agent 开放但内部系统查询工具只对特定的内部 Agent 开放。这个白名单机制不用写得很复杂一个 JSON 配置加中间层校验就够了。关键是要在架构设计阶段预留这个位置而不是等出问题了再加。6.2 Skills 的版本管理Skills 是文本文件天然适合做版本管理。我建议把所有 Skills 放进 Git 仓库里每次变更都走 MR 审查流程。原因很简单一个 SKILL.md 的小改动可能影响集群里所有加载它的 Agent 的行为。没有版本管理出问题之后根本无法回溯。我自己维护了一套 Skills 的目录规范stable 目录放经过验证的技能beta 目录放还在迭代的技能deprecated 目录放废弃技能。主 Agent 默认只加载 stable 目录里的技能需要试用 beta 技能时手动指定。6.3 集群可观测性日志与追踪多 Agent 集群的调试比单体难很多一个任务可能横跨多个进程和多个工具。我目前的方案是统一结构化日志每个请求携带一个 trace_id所有子 Agent、MCP Server 在日志里附带这个 trace_id。排查问题时一条命令过滤出来按时间线重新拼装整个任务流转过程。A2A 网关里我也会记录 Task 的每次状态变化。这让我能精确还原任务哪一步开始、哪一步卡住、最终返回了什么。这套可观测基础设施让集群规模从 5 个节点扩到 10 个节点时维护成本没有线性上涨。7. 未来扩展方向从集群到生态7.1 把 A2A 升级为跨组织协作当每个团队甚至每家公司都把自己的 Agent 通过 A2A 标准暴露出来Agent 就能跨组织协作。现在 A2A 协议已经支持 Agent Card 的公开发现机制理论上两个独立团队部署的 Agent 可以直接互相调用。你可以想象成你的 Agent 能直接调用另一个团队的行业报告生成 Agent只要双方遵循同一套协议。这就是标题里可互通的深层价值。7.2 从技能包到技能市场Skills 做多了之后我发现完全可以做一个本地的 Skill Registry每个 Skill 有名称、作者、版本、描述和依赖的 MCP Server 列表。主 Agent 在启动的时候会自动拉取最新技能清单。未来如果能力足够甚至可以做一个开放技能市场让开发者提交各自的 Skills 供社区使用。7.3 编排策略的持续进化DeepAgents 的编排目前还是模型自由发挥为主但它也支持给主 Agent 提供结构化的规划模板。我下一步的计划是把过去成功的编排路径沉淀成模板。比如调研报告类任务固定使用 retriever - reporter - formatter 的流程数据分析类任务固定使用 dataloader - analyzer - visualizer 的流程。有了这些模板模型做规划的稳定性会更高新场景下的初始化过程也更可控。最后再说一个我在整个实践中最有感触的点这套体系里最值得投入时间打磨的不是模型本身而是 Skills 和 MCP Server 的质量。工具定义得清楚、技能描述得准确集群的表现会有质的飞跃反过来工具定义含糊、技能互相矛盾再强的模型也带不动。我现在的习惯是每写完一个 Skill就用一组典型任务实测一遍迭代两三轮之后再放进 stable 目录。这种以工具质量为抓手的思路比在提示词上反复调参要有效得多。