1. 从单体到集群为什么需要可编排的多智能体架构过去一年我一直在折腾各种 Agent 框架从最早的 ReAct 循环手写到后来用 LangChain 的 AgentExecutor再到各种 AutoGPT 式的自主循环。说实话单体 Agent 的天花板非常明显——你给它再强的模型、再长的上下文它一旦面对需要多领域协作、需要调用十几个不同工具、需要并行处理的任务时就会开始精神分裂。要么工具描述塞爆上下文要么任务链条一长就开始丢步骤要么一个环节出错整个流程崩掉。这就是为什么我看到DeepAgents MCP A2A Skills这套组合的时候第一反应是终于有人把这事想明白了。这套架构的核心思路不是造一个更聪明的单体 Agent而是把 Agent 拆成可编排、可互通、可扩展的集群。打个比方单体 Agent 像一个什么都干的自由职业者能力再强也有边界而多智能体集群像一家公司有主脑负责拆解任务有专职子 Agent 负责执行有标准协议负责部门间沟通有技能库负责沉淀可复用的能力。DeepAgents在这里扮演的是主脑 编排层的角色。它最核心的能力是subagents子智能体机制——主 Agent 可以把一个复杂任务拆成若干子任务分派给不同的子 Agent 去执行每个子 Agent 有自己的上下文、自己的工具集、自己的专长。这解决了单体 Agent 上下文爆炸和任务串行的问题。MCPModel Context Protocol解决的是工具接入标准化的问题。以前每接一个工具就要写一套适配代码现在只要工具方提供 MCP ServerAgent 就能通过统一协议调用。你可以把它理解成 Agent 世界的 USB-C 接口——不管对面是数据库、浏览器、设计软件还是安全工具插上就能用。A2AAgent to Agent解决的是Agent 之间怎么对话的问题。当你有多个独立部署的 Agent 服务时它们之间需要一个通信协议来协商任务、传递结果、同步状态。A2A 就是干这个的。Skills解决的是能力沉淀与复用的问题。把常用的操作流程、领域知识、工具组合封装成技能包Agent 按需加载不用每次都从零推理。这四个东西组合起来才构成了一个真正能落地的多智能体系统。下面我会把这套架构从设计思路到实操细节完整拆一遍包括我踩过的坑和实测有效的配置方案。2. 核心组件深度拆解每个模块到底解决什么问题2.1 DeepAgents 的 subagents 机制与编排逻辑DeepAgents 是 LangChain 团队推出的一个 Agent 框架它的定位很明确——面向长周期、多步骤、需要子任务分解的复杂场景。和传统的 AgentExecutor 相比它最大的区别在于内置了任务规划和子智能体调度能力。我实测下来DeepAgents 最值得用的三个特性是第一内置 todo 列表与任务追踪。主 Agent 在接到任务后会先生成一个结构化的任务清单然后逐项推进。这个 todo 列表是持久化的即使中间某一步失败重试也不会丢失整体进度。这一点在长任务里非常关键——我用普通 Agent 跑一个需要 20 步的任务跑到第 15 步崩了重启后它完全不记得之前干了什么。DeepAgents 不会它会从断点继续。第二subagents 的隔离上下文。每个子 Agent 有独立的上下文窗口和工具集。主 Agent 只负责拆解和汇总不把子任务的中间过程全部塞进自己的上下文。这直接解决了上下文爆炸问题。举个例子你要做一个调研 10 个竞品并生成对比报告的任务如果单体 Agent 来做10 个竞品的调研过程全堆在一个上下文里很快就爆了。用 subagents每个竞品调研交给一个子 Agent主 Agent 只接收每个子 Agent 的最终摘要。第三文件系统抽象。DeepAgents 内置了一套虚拟文件系统Agent 可以把中间结果写到文件里需要时再读回来。这个设计非常聪明——它相当于给 Agent 提供了一个外部记忆不用把所有东西都塞在上下文里。我通常会让 Agent 把调研原始数据写到文件只在上下文里保留摘要和索引。配置一个基础的 DeepAgents 主 Agent核心代码大概长这样from deepagents import create_deep_agent from langchain.chat_models import init_chat_model model init_chat_model(gpt-4o, model_provideropenai) agent create_deep_agent( modelmodel, tools[search_tool, file_tool], subagents[ { name: researcher, description: 负责信息检索与资料整理, tools: [search_tool, fetch_tool], prompt: 你是一个专业调研员负责检索并整理指定主题的资料... }, { name: analyst, description: 负责数据分析与结论提炼, tools: [python_repl, file_tool], prompt: 你是一个数据分析师负责对给定数据进行分析... } ], system_prompt你是一个项目协调者负责拆解任务并分派给合适的子智能体... )这里有个关键点subagents 的 description 字段非常重要。主 Agent 是靠这个描述来决定把任务分给谁的。描述写得越清晰、边界越明确分派就越准确。我见过很多人 subagents 分派混乱八成是 description 写得太模糊比如写个处理数据主 Agent 根本不知道什么数据该给它。2.2 MCP 协议工具接入的标准化革命MCP 是 Anthropic 主导推出的一个开放协议全称 Model Context Protocol。它的核心价值用一句话概括让 Agent 用统一的方式调用任意外部工具和数据源。在没有 MCP 之前你接一个工具要写一套适配接数据库写一套 SQL 适配接浏览器写一套 Playwright 适配接设计软件写一套 API 适配。每套适配的接口风格、错误处理、参数格式都不一样。MCP 把这些统一了——工具方只需要实现一个 MCP Server暴露标准的 resources、tools、prompts 三类接口Agent 端就能通过统一协议调用。MCP 的三类核心接口接口类型作用典型场景Resources暴露可读取的数据文件内容、数据库记录、API 响应Tools暴露可调用的函数搜索、计算、写文件、发请求Prompts暴露预设的提示模板标准化任务模板、领域知识注入我实测下来MCP 最实用的场景是把本地工具标准化接入。比如你有一个 Playwright MCP ServerAgent 就能直接操控浏览器有一个数据库 MCP ServerAgent 就能直接查库。热搜词里提到的 playwright mcp、burpsuite mcp、blender mcp、unity mcp、nxopen mcp、yakit mcp本质上都是把各自领域的工具通过 MCP 协议暴露给 Agent。配置 MCP Server 的典型方式以配置文件为例{ mcpServers: { playwright: { command: npx, args: [-y, playwright/mcplatest] }, filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /path/to/workspace] } } }这里有个坑我要重点提醒MCP Server 的权限边界一定要卡死。比如 filesystem server你给它哪个目录的权限它就能读写哪个目录。我见过有人图省事直接给了根目录权限结果 Agent 一个误操作把系统文件改了。正确做法是只给工作目录而且最好用只读模式先跑通再放开写权限。2.3 A2A 协议Agent 之间的通信标准A2A 解决的是一个更上层的问题当你有多个独立部署的 Agent 服务时它们之间怎么协作。MCP 解决的是 Agent 调用工具的问题A2A 解决的是 Agent 调用 Agent 的问题。这两者的区别很关键工具是被动的、无状态的、执行确定操作的而 Agent 是主动的、有状态的、会自主决策的。你不能用 MCP 的方式去调一个 Agent因为 Agent 需要协商、需要多轮对话、需要传递上下文。A2A 的核心概念包括Agent Card每个 Agent 对外暴露自己的能力描述包括擅长什么、接受什么输入、返回什么输出。这相当于 Agent 的名片。TaskAgent 之间的任务单元有明确的生命周期状态提交、处理中、完成、失败。MessageAgent 之间的消息传递支持多轮交互。实际用起来A2A 最适合的场景是跨团队、跨系统的 Agent 协作。比如你的团队有一个专门做数据分析的 Agent 服务另一个团队有一个专门做报告生成的 Agent 服务通过 A2A 协议两个服务可以互相调用而不需要把代码耦合在一起。2.4 Skills能力沉淀与按需加载Skills 这个概念最近特别火热搜词里 skills、skills推荐、skills开发、常用skills、superpower skills 出现频率极高。本质上Skills 是把可复用的能力封装成标准化的技能包Agent 按需加载。一个 Skill 通常包含技能描述告诉 Agent 这个技能是干什么的、什么时候用。执行逻辑具体的操作步骤、工具调用序列、提示模板。依赖声明需要哪些工具、哪些 MCP Server、哪些环境变量。示例输入输出示例帮助 Agent 理解怎么用。Skills 最大的价值在于降低 Agent 的推理负担。没有 Skills 的时候Agent 每次遇到一个任务都要从零推理我该用什么工具、按什么顺序、注意什么。有了 Skills这些经验被固化下来Agent 直接调用即可。我自己的做法是把高频操作都封装成 Skill。比如生成周报这个操作涉及查数据库、拉数据、做图表、写总结、发邮件五个步骤封装成一个 Skill 后Agent 一句话就能触发整个流程。3. 从零搭建一套可编排的多智能体系统3.1 环境准备与依赖安装先把基础环境搭起来。我推荐用 Python 3.11因为 DeepAgents 和大部分 MCP 相关库对版本有要求。# 创建虚拟环境 python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate # 安装核心依赖 pip install deepagents langchain langgraph pip install mcp # MCP 协议 Python SDK pip install a2a-sdk # A2A 协议 SDK如使用如果你要用 Node 生态的 MCP Server比如 playwright mcp还需要装 Node.js 18node --version # 确认 18 npx --version环境变量方面至少需要配置模型 API Keyexport OPENAI_API_KEYyour-key # 或者用其他模型提供商 export ANTHROPIC_API_KEYyour-key注意API Key 千万不要硬编码在代码里也不要在公开仓库里提交。用环境变量或密钥管理服务。3.2 主 Agent 与子 Agent 的编排配置这一步是整个系统的核心。我以一个竞品调研报告生成的实际任务为例展示完整的编排配置。主 Agent 的职责是拆解任务、分派子任务、汇总结果。子 Agent 分三类调研员、分析师、写手。from deepagents import create_deep_agent from langchain.chat_models import init_chat_model from langchain_core.tools import tool model init_chat_model(gpt-4o, model_provideropenai) tool def web_search(query: str) - str: 搜索网络信息 # 实际实现略 return f搜索结果{query} tool def write_file(path: str, content: str) - str: 写入文件 with open(path, w) as f: f.write(content) return f已写入 {path} tool def read_file(path: str) - str: 读取文件 with open(path, r) as f: return f.read() # 定义子智能体 researcher { name: researcher, description: 负责检索指定竞品的信息包括产品功能、定价、用户评价。输入是竞品名称输出是结构化的调研摘要。, tools: [web_search, write_file], prompt: 你是一个专业调研员。针对给定的竞品你需要 1. 检索其核心功能、定价策略、目标用户 2. 收集至少 5 条真实用户评价 3. 把原始资料写入 raw/{竞品名}.md 4. 返回一份 300 字以内的结构化摘要 注意只做调研不做分析判断。 } analyst { name: analyst, description: 负责对调研资料进行对比分析提炼差异化优势和劣势。输入是多个竞品的调研摘要输出是对比分析报告。, tools: [read_file, write_file], prompt: 你是一个数据分析师。基于给定的竞品调研摘要你需要 1. 从功能、定价、用户体验三个维度做对比 2. 找出每个竞品的差异化优势 3. 输出一份对比分析写入 analysis.md 注意结论必须有调研数据支撑不要臆测。 } writer { name: writer, description: 负责把分析结果整理成可读性强的报告。输入是对比分析输出是最终报告。, tools: [read_file, write_file], prompt: 你是一个报告撰写者。基于对比分析你需要 1. 写一份结构清晰的竞品分析报告 2. 包含执行摘要、对比表格、结论建议 3. 语言简洁专业避免空话 4. 写入 final_report.md } # 创建主 Agent main_agent create_deep_agent( modelmodel, tools[web_search, write_file, read_file], subagents[researcher, analyst, writer], system_prompt你是一个项目协调者。接到任务后 1. 先拆解任务生成 todo 列表 2. 把调研任务分派给 researcher每个竞品一个子任务 3. 调研完成后把分析任务分派给 analyst 4. 分析完成后把撰写任务分派给 writer 5. 最后检查所有产出文件确认完整性 注意不要自己执行子任务只做拆解、分派、汇总。 )这套配置跑下来主 Agent 会自动完成拆解→分派→汇总的全流程。我实测跑 5 个竞品的调研从开始到生成最终报告大约 8-12 分钟比单体 Agent 快 3 倍以上而且中间过程不会因为上下文爆炸而崩掉。3.3 MCP Server 的接入与工具注册MCP Server 的接入方式分两种本地进程和远程服务。本地进程方式适合本地工具from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client server_params StdioServerParameters( commandnpx, args[-y, playwright/mcplatest] ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() tools await session.list_tools() # 把 tools 注册到 Agent远程服务方式适合已部署的 MCP Serverfrom mcp.client.sse import sse_client async with sse_client(https://your-mcp-server.com/sse) as (read, write): async with ClientSession(read, write) as session: await session.initialize() # 同上这里有个实操要点MCP 工具的命名冲突问题。如果你同时接入了多个 MCP Server它们可能有同名工具。我的做法是给每个 Server 的工具加前缀比如playwright_navigate、filesystem_read避免冲突。3.4 Skills 的封装与加载Skills 的封装我推荐用目录结构每个 Skill 一个文件夹skills/ ├── weekly_report/ │ ├── SKILL.md # 技能描述 │ ├── execute.py # 执行逻辑 │ └── examples/ # 示例 │ ├── input.json │ └── output.json └── competitor_analysis/ ├── SKILL.md └── execute.pySKILL.md 的格式# 竞品分析技能 ## 描述 针对指定竞品自动完成调研、分析、报告生成全流程。 ## 触发条件 当用户提到竞品分析、对比 XX 和 YY时触发。 ## 依赖 - MCP Server: playwright, filesystem - 子智能体: researcher, analyst, writer ## 执行流程 1. 解析竞品列表 2. 为每个竞品分派 researcher 子任务 3. 汇总调研结果分派 analyst 4. 分派 writer 生成报告 5. 返回报告路径 ## 示例 输入分析 Notion、Obsidian、Logseq 三个笔记工具 输出final_report.md加载 Skill 的时候Agent 只需要读 SKILL.md 的描述部分判断是否匹配当前任务匹配才加载完整执行逻辑。这样能大幅节省上下文。4. 实操中的典型问题与排查技巧4.1 子智能体分派错误怎么办这是最常见的问题。表现是主 Agent 把任务分给了不合适的子 Agent或者反复在几个子 Agent 之间来回分派。根本原因通常是 subagents 的 description 写得不够清晰。主 Agent 是靠 description 做语义匹配的如果两个子 Agent 的描述有重叠它就会犹豫。解决方法给每个子 Agent 的 description 加上明确的输入是什么、输出是什么、不负责什么。比如 researcher 的描述里明确写只做调研不做分析判断。在 system_prompt 里给出分派规则比如调研类任务一律给 researcher分析类任务一律给 analyst。如果还是分派混乱可以在 description 里加负面示例比如不要用于数据分析任务。我踩过的一个坑是一开始 researcher 和 analyst 的描述都写了处理数据结果主 Agent 经常把分析任务分给 researcher。后来把 researcher 的描述改成只负责检索和整理原始资料不做任何分析判断问题就解决了。4.2 MCP 工具调用超时或失败MCP 工具调用失败的原因很多我整理了一个排查表现象可能原因排查方法连接超时Server 未启动或网络不通手动跑一遍 Server 启动命令工具列表为空Server 初始化失败检查 Server 日志调用返回错误参数格式不对对照 Server 文档检查参数间歇性失败并发过高或资源不足降低并发加超时重试权限拒绝权限边界配置过严检查 Server 的权限配置我的经验是MCP Server 一定要先单独跑通再接入 Agent。很多人一上来就把 Server 配到 Agent 里出错了根本不知道是 Server 的问题还是 Agent 的问题。正确做法是先用 MCP Inspector 或命令行工具单独测试 Server确认工具能正常调用再接入 Agent。4.3 上下文爆炸与 token 超限即使有了 subagents如果子 Agent 返回的结果太长主 Agent 的上下文还是会爆。解决方法强制子 Agent 返回摘要。在子 Agent 的 prompt 里明确要求返回 300 字以内的摘要原始资料写入文件。用文件系统做中间存储。子 Agent 把详细结果写文件只把文件路径和摘要返回给主 Agent。定期清理上下文。DeepAgents 支持上下文压缩可以在配置里开启。我实测下来一个 5 竞品的调研任务如果不做摘要控制主 Agent 上下文会到 80K token做了摘要控制后稳定在 15K 以内。4.4 Skills 加载失败或冲突Skills 加载失败的常见原因是依赖缺失或版本不匹配。我的做法是在 SKILL.md 里明确声明依赖版本加载前先做依赖检查。Skills 冲突的情况比较少见但如果两个 Skill 的触发条件重叠Agent 会不知道用哪个。解决方法是给每个 Skill 加优先级或者在描述里写清楚适用场景的差异。5. 架构扩展与生产化考量5.1 从单机到分布式的演进路径单机跑多智能体受限于本地资源并发能力有限。当任务量上来后需要考虑分布式部署。演进路径我建议分三步第一步单机多进程。主 Agent 和子 Agent 跑在同一台机器用进程隔离。适合任务量不大的场景。第二步主从分离。主 Agent 跑在一台机器子 Agent 作为独立服务跑在其他机器通过 A2A 协议通信。这样可以根据子 Agent 的负载独立扩容。第三步全分布式。每个 Agent 都是独立服务通过服务发现和负载均衡调度。适合大规模生产环境。5.2 监控、日志与可观测性多智能体系统的可观测性比单体 Agent 重要得多因为出问题时你根本不知道是哪个环节挂了。我建议至少监控这几个指标任务成功率整体任务完成的比例子任务分派分布每个子 Agent 被调用的次数平均执行时长每个环节的耗时工具调用失败率MCP 工具的失败比例Token 消耗每个 Agent 的 token 使用量日志方面我习惯给每个任务打一个 trace_id所有相关 Agent 的日志都带上这个 id排查问题时能串起来。5.3 成本控制与性能优化多智能体系统的成本比单体 Agent 高因为子 Agent 也要消耗 token。控制成本的关键是子 Agent 用更便宜的模型。主 Agent 用强模型做规划子 Agent 用便宜模型做执行。我实测下来子 Agent 用 gpt-4o-mini 和 gpt-4o 的效果差距不大但成本差 10 倍以上。缓存重复调用。同样的调研任务结果可以缓存避免重复消耗。控制子 Agent 数量。不是越多越好3-5 个通常够用太多反而增加协调成本。性能优化方面最大的瓶颈通常是 MCP 工具调用。我的做法是把能并行的工具调用并行化比如 5 个竞品的调研可以同时跑不用串行。6. 我踩过的坑与实战心得6.1 子 Agent 的 prompt 要窄不要宽这是我踩过最大的坑。一开始我给子 Agent 的 prompt 写得很宽泛比如你是一个助手负责处理各种任务。结果子 Agent 什么都想干经常越界。后来我把每个子 Agent 的 prompt 都收窄到极致明确写你只负责 X不负责 Y遇到 Y 请返回给主 Agent。效果立竿见影分派准确率和执行质量都上来了。核心原则子 Agent 的职责边界越清晰整个系统的稳定性越高。6.2 MCP 工具要少而精我一开始接了一堆 MCP Server觉得工具越多越好。结果 Agent 面对几十个工具选择困难经常调错。后来我精简到只保留核心工具每个子 Agent 只给它需要的 2-3 个工具。工具少了Agent 的决策反而更准。核心原则工具不是越多越好而是越匹配越好。6.3 Skills 要高频优先Skills 封装不要贪多优先封装高频操作。我一开始想把所有操作都封装成 Skill结果维护成本极高很多 Skill 几个月用不上一次。后来我只封装每周至少用 3 次的操作Skills 库保持精简维护起来轻松很多。核心原则Skills 是给高频操作提速的低频操作直接让 Agent 推理就行。6.4 一定要做降级方案多智能体系统比单体复杂出问题的概率更高。一定要设计降级方案当子 Agent 不可用时主 Agent 能不能自己顶上当 MCP 工具挂了有没有备用工具我的做法是给每个关键环节都准备一个降级路径。比如调研子 Agent 挂了主 Agent 直接用搜索工具自己跑MCP 文件工具挂了用本地 Python 直接读写。核心原则分布式系统没有 100% 可用降级方案是刚需。6.5 测试要覆盖异常路径大部分人测试只测正常流程但多智能体系统的问题 90% 出在异常路径。我建议至少覆盖这几类异常子 Agent 返回空结果MCP 工具超时子 Agent 之间分派死循环上下文超限模型 API 限流每类异常都要有明确的处理策略不能靠应该不会发生。7. 这套架构适合什么场景不适合什么场景7.1 适合的场景复杂多步骤任务需要拆解成多个子任务、每个子任务需要不同能力的场景。比如竞品调研、市场分析、代码审查、内容生产流水线。多工具协作任务需要调用多个外部工具、工具之间需要协调的场景。比如自动化测试、数据管道、设计工作流。长周期任务需要跑几十分钟甚至几小时、中间可能失败需要恢复的场景。比如大规模数据采集、批量内容生成。多团队协作场景不同团队维护不同的 Agent 服务需要互相调用的场景。A2A 协议在这里价值最大。7.2 不适合的场景简单单步任务一句话能搞定的事用多智能体是杀鸡用牛刀反而增加复杂度和成本。强实时性任务多智能体的协调开销决定了它不适合毫秒级响应的场景。资源极度受限场景多智能体对算力和 token 的消耗都比单体高资源紧张时慎用。任务边界模糊的场景如果任务本身就没法清晰拆解多智能体反而会放大混乱。7.3 选型决策表场景特征推荐方案单步任务、工具少于 3 个单体 Agent多步骤、工具 3-10 个单体 Agent MCP多步骤、需要子任务隔离DeepAgents subagents多团队、跨系统协作DeepAgents MCP A2A高频重复操作上述 Skills 封装大规模生产环境全分布式 监控体系8. 后续可以怎么扩展这套架构搭起来后扩展方向其实很多。我自己在探索的几个方向方向一Agent 市场。把常用的子 Agent 和 Skills 做成可插拔的模块像装 App 一样按需加载。这样不同团队可以共享能力不用重复造轮子。方向二自适应编排。让主 Agent 根据任务特征动态决定用几个子 Agent、怎么分派而不是写死配置。这需要主 Agent 有更强的规划能力。方向三跨模态协作。现在大部分子 Agent 处理的是文本未来可以接入图像、音频、视频处理的子 Agent做真正的多模态协作。方向四自进化 Skills。让 Agent 在执行任务的过程中自动沉淀新的 Skill把成功的操作流程固化下来。这个方向很有意思但需要解决 Skill 质量把控的问题。方向五人机协作编排。在关键节点引入人工审核人可以做子 Agent 的上级也可以做协作者。这在需要高可靠性的场景里很有价值。最后分享一个我个人的体会多智能体系统的核心难点从来不是技术而是任务拆解的粒度。拆得太粗子 Agent 之间职责不清拆得太细协调开销超过收益。找到那个平衡点需要大量实践。我的经验是一个子 Agent 的任务最好控制在一个明确目标 3-5 个步骤的粒度这样既不会太粗也不会太细。这个粒度感只能靠多跑、多调、多踩坑来积累。
DeepAgents+MCP+A2A+Skills：可编排多智能体架构实战
1. 从单体到集群为什么需要可编排的多智能体架构过去一年我一直在折腾各种 Agent 框架从最早的 ReAct 循环手写到后来用 LangChain 的 AgentExecutor再到各种 AutoGPT 式的自主循环。说实话单体 Agent 的天花板非常明显——你给它再强的模型、再长的上下文它一旦面对需要多领域协作、需要调用十几个不同工具、需要并行处理的任务时就会开始精神分裂。要么工具描述塞爆上下文要么任务链条一长就开始丢步骤要么一个环节出错整个流程崩掉。这就是为什么我看到DeepAgents MCP A2A Skills这套组合的时候第一反应是终于有人把这事想明白了。这套架构的核心思路不是造一个更聪明的单体 Agent而是把 Agent 拆成可编排、可互通、可扩展的集群。打个比方单体 Agent 像一个什么都干的自由职业者能力再强也有边界而多智能体集群像一家公司有主脑负责拆解任务有专职子 Agent 负责执行有标准协议负责部门间沟通有技能库负责沉淀可复用的能力。DeepAgents在这里扮演的是主脑 编排层的角色。它最核心的能力是subagents子智能体机制——主 Agent 可以把一个复杂任务拆成若干子任务分派给不同的子 Agent 去执行每个子 Agent 有自己的上下文、自己的工具集、自己的专长。这解决了单体 Agent 上下文爆炸和任务串行的问题。MCPModel Context Protocol解决的是工具接入标准化的问题。以前每接一个工具就要写一套适配代码现在只要工具方提供 MCP ServerAgent 就能通过统一协议调用。你可以把它理解成 Agent 世界的 USB-C 接口——不管对面是数据库、浏览器、设计软件还是安全工具插上就能用。A2AAgent to Agent解决的是Agent 之间怎么对话的问题。当你有多个独立部署的 Agent 服务时它们之间需要一个通信协议来协商任务、传递结果、同步状态。A2A 就是干这个的。Skills解决的是能力沉淀与复用的问题。把常用的操作流程、领域知识、工具组合封装成技能包Agent 按需加载不用每次都从零推理。这四个东西组合起来才构成了一个真正能落地的多智能体系统。下面我会把这套架构从设计思路到实操细节完整拆一遍包括我踩过的坑和实测有效的配置方案。2. 核心组件深度拆解每个模块到底解决什么问题2.1 DeepAgents 的 subagents 机制与编排逻辑DeepAgents 是 LangChain 团队推出的一个 Agent 框架它的定位很明确——面向长周期、多步骤、需要子任务分解的复杂场景。和传统的 AgentExecutor 相比它最大的区别在于内置了任务规划和子智能体调度能力。我实测下来DeepAgents 最值得用的三个特性是第一内置 todo 列表与任务追踪。主 Agent 在接到任务后会先生成一个结构化的任务清单然后逐项推进。这个 todo 列表是持久化的即使中间某一步失败重试也不会丢失整体进度。这一点在长任务里非常关键——我用普通 Agent 跑一个需要 20 步的任务跑到第 15 步崩了重启后它完全不记得之前干了什么。DeepAgents 不会它会从断点继续。第二subagents 的隔离上下文。每个子 Agent 有独立的上下文窗口和工具集。主 Agent 只负责拆解和汇总不把子任务的中间过程全部塞进自己的上下文。这直接解决了上下文爆炸问题。举个例子你要做一个调研 10 个竞品并生成对比报告的任务如果单体 Agent 来做10 个竞品的调研过程全堆在一个上下文里很快就爆了。用 subagents每个竞品调研交给一个子 Agent主 Agent 只接收每个子 Agent 的最终摘要。第三文件系统抽象。DeepAgents 内置了一套虚拟文件系统Agent 可以把中间结果写到文件里需要时再读回来。这个设计非常聪明——它相当于给 Agent 提供了一个外部记忆不用把所有东西都塞在上下文里。我通常会让 Agent 把调研原始数据写到文件只在上下文里保留摘要和索引。配置一个基础的 DeepAgents 主 Agent核心代码大概长这样from deepagents import create_deep_agent from langchain.chat_models import init_chat_model model init_chat_model(gpt-4o, model_provideropenai) agent create_deep_agent( modelmodel, tools[search_tool, file_tool], subagents[ { name: researcher, description: 负责信息检索与资料整理, tools: [search_tool, fetch_tool], prompt: 你是一个专业调研员负责检索并整理指定主题的资料... }, { name: analyst, description: 负责数据分析与结论提炼, tools: [python_repl, file_tool], prompt: 你是一个数据分析师负责对给定数据进行分析... } ], system_prompt你是一个项目协调者负责拆解任务并分派给合适的子智能体... )这里有个关键点subagents 的 description 字段非常重要。主 Agent 是靠这个描述来决定把任务分给谁的。描述写得越清晰、边界越明确分派就越准确。我见过很多人 subagents 分派混乱八成是 description 写得太模糊比如写个处理数据主 Agent 根本不知道什么数据该给它。2.2 MCP 协议工具接入的标准化革命MCP 是 Anthropic 主导推出的一个开放协议全称 Model Context Protocol。它的核心价值用一句话概括让 Agent 用统一的方式调用任意外部工具和数据源。在没有 MCP 之前你接一个工具要写一套适配接数据库写一套 SQL 适配接浏览器写一套 Playwright 适配接设计软件写一套 API 适配。每套适配的接口风格、错误处理、参数格式都不一样。MCP 把这些统一了——工具方只需要实现一个 MCP Server暴露标准的 resources、tools、prompts 三类接口Agent 端就能通过统一协议调用。MCP 的三类核心接口接口类型作用典型场景Resources暴露可读取的数据文件内容、数据库记录、API 响应Tools暴露可调用的函数搜索、计算、写文件、发请求Prompts暴露预设的提示模板标准化任务模板、领域知识注入我实测下来MCP 最实用的场景是把本地工具标准化接入。比如你有一个 Playwright MCP ServerAgent 就能直接操控浏览器有一个数据库 MCP ServerAgent 就能直接查库。热搜词里提到的 playwright mcp、burpsuite mcp、blender mcp、unity mcp、nxopen mcp、yakit mcp本质上都是把各自领域的工具通过 MCP 协议暴露给 Agent。配置 MCP Server 的典型方式以配置文件为例{ mcpServers: { playwright: { command: npx, args: [-y, playwright/mcplatest] }, filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /path/to/workspace] } } }这里有个坑我要重点提醒MCP Server 的权限边界一定要卡死。比如 filesystem server你给它哪个目录的权限它就能读写哪个目录。我见过有人图省事直接给了根目录权限结果 Agent 一个误操作把系统文件改了。正确做法是只给工作目录而且最好用只读模式先跑通再放开写权限。2.3 A2A 协议Agent 之间的通信标准A2A 解决的是一个更上层的问题当你有多个独立部署的 Agent 服务时它们之间怎么协作。MCP 解决的是 Agent 调用工具的问题A2A 解决的是 Agent 调用 Agent 的问题。这两者的区别很关键工具是被动的、无状态的、执行确定操作的而 Agent 是主动的、有状态的、会自主决策的。你不能用 MCP 的方式去调一个 Agent因为 Agent 需要协商、需要多轮对话、需要传递上下文。A2A 的核心概念包括Agent Card每个 Agent 对外暴露自己的能力描述包括擅长什么、接受什么输入、返回什么输出。这相当于 Agent 的名片。TaskAgent 之间的任务单元有明确的生命周期状态提交、处理中、完成、失败。MessageAgent 之间的消息传递支持多轮交互。实际用起来A2A 最适合的场景是跨团队、跨系统的 Agent 协作。比如你的团队有一个专门做数据分析的 Agent 服务另一个团队有一个专门做报告生成的 Agent 服务通过 A2A 协议两个服务可以互相调用而不需要把代码耦合在一起。2.4 Skills能力沉淀与按需加载Skills 这个概念最近特别火热搜词里 skills、skills推荐、skills开发、常用skills、superpower skills 出现频率极高。本质上Skills 是把可复用的能力封装成标准化的技能包Agent 按需加载。一个 Skill 通常包含技能描述告诉 Agent 这个技能是干什么的、什么时候用。执行逻辑具体的操作步骤、工具调用序列、提示模板。依赖声明需要哪些工具、哪些 MCP Server、哪些环境变量。示例输入输出示例帮助 Agent 理解怎么用。Skills 最大的价值在于降低 Agent 的推理负担。没有 Skills 的时候Agent 每次遇到一个任务都要从零推理我该用什么工具、按什么顺序、注意什么。有了 Skills这些经验被固化下来Agent 直接调用即可。我自己的做法是把高频操作都封装成 Skill。比如生成周报这个操作涉及查数据库、拉数据、做图表、写总结、发邮件五个步骤封装成一个 Skill 后Agent 一句话就能触发整个流程。3. 从零搭建一套可编排的多智能体系统3.1 环境准备与依赖安装先把基础环境搭起来。我推荐用 Python 3.11因为 DeepAgents 和大部分 MCP 相关库对版本有要求。# 创建虚拟环境 python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate # 安装核心依赖 pip install deepagents langchain langgraph pip install mcp # MCP 协议 Python SDK pip install a2a-sdk # A2A 协议 SDK如使用如果你要用 Node 生态的 MCP Server比如 playwright mcp还需要装 Node.js 18node --version # 确认 18 npx --version环境变量方面至少需要配置模型 API Keyexport OPENAI_API_KEYyour-key # 或者用其他模型提供商 export ANTHROPIC_API_KEYyour-key注意API Key 千万不要硬编码在代码里也不要在公开仓库里提交。用环境变量或密钥管理服务。3.2 主 Agent 与子 Agent 的编排配置这一步是整个系统的核心。我以一个竞品调研报告生成的实际任务为例展示完整的编排配置。主 Agent 的职责是拆解任务、分派子任务、汇总结果。子 Agent 分三类调研员、分析师、写手。from deepagents import create_deep_agent from langchain.chat_models import init_chat_model from langchain_core.tools import tool model init_chat_model(gpt-4o, model_provideropenai) tool def web_search(query: str) - str: 搜索网络信息 # 实际实现略 return f搜索结果{query} tool def write_file(path: str, content: str) - str: 写入文件 with open(path, w) as f: f.write(content) return f已写入 {path} tool def read_file(path: str) - str: 读取文件 with open(path, r) as f: return f.read() # 定义子智能体 researcher { name: researcher, description: 负责检索指定竞品的信息包括产品功能、定价、用户评价。输入是竞品名称输出是结构化的调研摘要。, tools: [web_search, write_file], prompt: 你是一个专业调研员。针对给定的竞品你需要 1. 检索其核心功能、定价策略、目标用户 2. 收集至少 5 条真实用户评价 3. 把原始资料写入 raw/{竞品名}.md 4. 返回一份 300 字以内的结构化摘要 注意只做调研不做分析判断。 } analyst { name: analyst, description: 负责对调研资料进行对比分析提炼差异化优势和劣势。输入是多个竞品的调研摘要输出是对比分析报告。, tools: [read_file, write_file], prompt: 你是一个数据分析师。基于给定的竞品调研摘要你需要 1. 从功能、定价、用户体验三个维度做对比 2. 找出每个竞品的差异化优势 3. 输出一份对比分析写入 analysis.md 注意结论必须有调研数据支撑不要臆测。 } writer { name: writer, description: 负责把分析结果整理成可读性强的报告。输入是对比分析输出是最终报告。, tools: [read_file, write_file], prompt: 你是一个报告撰写者。基于对比分析你需要 1. 写一份结构清晰的竞品分析报告 2. 包含执行摘要、对比表格、结论建议 3. 语言简洁专业避免空话 4. 写入 final_report.md } # 创建主 Agent main_agent create_deep_agent( modelmodel, tools[web_search, write_file, read_file], subagents[researcher, analyst, writer], system_prompt你是一个项目协调者。接到任务后 1. 先拆解任务生成 todo 列表 2. 把调研任务分派给 researcher每个竞品一个子任务 3. 调研完成后把分析任务分派给 analyst 4. 分析完成后把撰写任务分派给 writer 5. 最后检查所有产出文件确认完整性 注意不要自己执行子任务只做拆解、分派、汇总。 )这套配置跑下来主 Agent 会自动完成拆解→分派→汇总的全流程。我实测跑 5 个竞品的调研从开始到生成最终报告大约 8-12 分钟比单体 Agent 快 3 倍以上而且中间过程不会因为上下文爆炸而崩掉。3.3 MCP Server 的接入与工具注册MCP Server 的接入方式分两种本地进程和远程服务。本地进程方式适合本地工具from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client server_params StdioServerParameters( commandnpx, args[-y, playwright/mcplatest] ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() tools await session.list_tools() # 把 tools 注册到 Agent远程服务方式适合已部署的 MCP Serverfrom mcp.client.sse import sse_client async with sse_client(https://your-mcp-server.com/sse) as (read, write): async with ClientSession(read, write) as session: await session.initialize() # 同上这里有个实操要点MCP 工具的命名冲突问题。如果你同时接入了多个 MCP Server它们可能有同名工具。我的做法是给每个 Server 的工具加前缀比如playwright_navigate、filesystem_read避免冲突。3.4 Skills 的封装与加载Skills 的封装我推荐用目录结构每个 Skill 一个文件夹skills/ ├── weekly_report/ │ ├── SKILL.md # 技能描述 │ ├── execute.py # 执行逻辑 │ └── examples/ # 示例 │ ├── input.json │ └── output.json └── competitor_analysis/ ├── SKILL.md └── execute.pySKILL.md 的格式# 竞品分析技能 ## 描述 针对指定竞品自动完成调研、分析、报告生成全流程。 ## 触发条件 当用户提到竞品分析、对比 XX 和 YY时触发。 ## 依赖 - MCP Server: playwright, filesystem - 子智能体: researcher, analyst, writer ## 执行流程 1. 解析竞品列表 2. 为每个竞品分派 researcher 子任务 3. 汇总调研结果分派 analyst 4. 分派 writer 生成报告 5. 返回报告路径 ## 示例 输入分析 Notion、Obsidian、Logseq 三个笔记工具 输出final_report.md加载 Skill 的时候Agent 只需要读 SKILL.md 的描述部分判断是否匹配当前任务匹配才加载完整执行逻辑。这样能大幅节省上下文。4. 实操中的典型问题与排查技巧4.1 子智能体分派错误怎么办这是最常见的问题。表现是主 Agent 把任务分给了不合适的子 Agent或者反复在几个子 Agent 之间来回分派。根本原因通常是 subagents 的 description 写得不够清晰。主 Agent 是靠 description 做语义匹配的如果两个子 Agent 的描述有重叠它就会犹豫。解决方法给每个子 Agent 的 description 加上明确的输入是什么、输出是什么、不负责什么。比如 researcher 的描述里明确写只做调研不做分析判断。在 system_prompt 里给出分派规则比如调研类任务一律给 researcher分析类任务一律给 analyst。如果还是分派混乱可以在 description 里加负面示例比如不要用于数据分析任务。我踩过的一个坑是一开始 researcher 和 analyst 的描述都写了处理数据结果主 Agent 经常把分析任务分给 researcher。后来把 researcher 的描述改成只负责检索和整理原始资料不做任何分析判断问题就解决了。4.2 MCP 工具调用超时或失败MCP 工具调用失败的原因很多我整理了一个排查表现象可能原因排查方法连接超时Server 未启动或网络不通手动跑一遍 Server 启动命令工具列表为空Server 初始化失败检查 Server 日志调用返回错误参数格式不对对照 Server 文档检查参数间歇性失败并发过高或资源不足降低并发加超时重试权限拒绝权限边界配置过严检查 Server 的权限配置我的经验是MCP Server 一定要先单独跑通再接入 Agent。很多人一上来就把 Server 配到 Agent 里出错了根本不知道是 Server 的问题还是 Agent 的问题。正确做法是先用 MCP Inspector 或命令行工具单独测试 Server确认工具能正常调用再接入 Agent。4.3 上下文爆炸与 token 超限即使有了 subagents如果子 Agent 返回的结果太长主 Agent 的上下文还是会爆。解决方法强制子 Agent 返回摘要。在子 Agent 的 prompt 里明确要求返回 300 字以内的摘要原始资料写入文件。用文件系统做中间存储。子 Agent 把详细结果写文件只把文件路径和摘要返回给主 Agent。定期清理上下文。DeepAgents 支持上下文压缩可以在配置里开启。我实测下来一个 5 竞品的调研任务如果不做摘要控制主 Agent 上下文会到 80K token做了摘要控制后稳定在 15K 以内。4.4 Skills 加载失败或冲突Skills 加载失败的常见原因是依赖缺失或版本不匹配。我的做法是在 SKILL.md 里明确声明依赖版本加载前先做依赖检查。Skills 冲突的情况比较少见但如果两个 Skill 的触发条件重叠Agent 会不知道用哪个。解决方法是给每个 Skill 加优先级或者在描述里写清楚适用场景的差异。5. 架构扩展与生产化考量5.1 从单机到分布式的演进路径单机跑多智能体受限于本地资源并发能力有限。当任务量上来后需要考虑分布式部署。演进路径我建议分三步第一步单机多进程。主 Agent 和子 Agent 跑在同一台机器用进程隔离。适合任务量不大的场景。第二步主从分离。主 Agent 跑在一台机器子 Agent 作为独立服务跑在其他机器通过 A2A 协议通信。这样可以根据子 Agent 的负载独立扩容。第三步全分布式。每个 Agent 都是独立服务通过服务发现和负载均衡调度。适合大规模生产环境。5.2 监控、日志与可观测性多智能体系统的可观测性比单体 Agent 重要得多因为出问题时你根本不知道是哪个环节挂了。我建议至少监控这几个指标任务成功率整体任务完成的比例子任务分派分布每个子 Agent 被调用的次数平均执行时长每个环节的耗时工具调用失败率MCP 工具的失败比例Token 消耗每个 Agent 的 token 使用量日志方面我习惯给每个任务打一个 trace_id所有相关 Agent 的日志都带上这个 id排查问题时能串起来。5.3 成本控制与性能优化多智能体系统的成本比单体 Agent 高因为子 Agent 也要消耗 token。控制成本的关键是子 Agent 用更便宜的模型。主 Agent 用强模型做规划子 Agent 用便宜模型做执行。我实测下来子 Agent 用 gpt-4o-mini 和 gpt-4o 的效果差距不大但成本差 10 倍以上。缓存重复调用。同样的调研任务结果可以缓存避免重复消耗。控制子 Agent 数量。不是越多越好3-5 个通常够用太多反而增加协调成本。性能优化方面最大的瓶颈通常是 MCP 工具调用。我的做法是把能并行的工具调用并行化比如 5 个竞品的调研可以同时跑不用串行。6. 我踩过的坑与实战心得6.1 子 Agent 的 prompt 要窄不要宽这是我踩过最大的坑。一开始我给子 Agent 的 prompt 写得很宽泛比如你是一个助手负责处理各种任务。结果子 Agent 什么都想干经常越界。后来我把每个子 Agent 的 prompt 都收窄到极致明确写你只负责 X不负责 Y遇到 Y 请返回给主 Agent。效果立竿见影分派准确率和执行质量都上来了。核心原则子 Agent 的职责边界越清晰整个系统的稳定性越高。6.2 MCP 工具要少而精我一开始接了一堆 MCP Server觉得工具越多越好。结果 Agent 面对几十个工具选择困难经常调错。后来我精简到只保留核心工具每个子 Agent 只给它需要的 2-3 个工具。工具少了Agent 的决策反而更准。核心原则工具不是越多越好而是越匹配越好。6.3 Skills 要高频优先Skills 封装不要贪多优先封装高频操作。我一开始想把所有操作都封装成 Skill结果维护成本极高很多 Skill 几个月用不上一次。后来我只封装每周至少用 3 次的操作Skills 库保持精简维护起来轻松很多。核心原则Skills 是给高频操作提速的低频操作直接让 Agent 推理就行。6.4 一定要做降级方案多智能体系统比单体复杂出问题的概率更高。一定要设计降级方案当子 Agent 不可用时主 Agent 能不能自己顶上当 MCP 工具挂了有没有备用工具我的做法是给每个关键环节都准备一个降级路径。比如调研子 Agent 挂了主 Agent 直接用搜索工具自己跑MCP 文件工具挂了用本地 Python 直接读写。核心原则分布式系统没有 100% 可用降级方案是刚需。6.5 测试要覆盖异常路径大部分人测试只测正常流程但多智能体系统的问题 90% 出在异常路径。我建议至少覆盖这几类异常子 Agent 返回空结果MCP 工具超时子 Agent 之间分派死循环上下文超限模型 API 限流每类异常都要有明确的处理策略不能靠应该不会发生。7. 这套架构适合什么场景不适合什么场景7.1 适合的场景复杂多步骤任务需要拆解成多个子任务、每个子任务需要不同能力的场景。比如竞品调研、市场分析、代码审查、内容生产流水线。多工具协作任务需要调用多个外部工具、工具之间需要协调的场景。比如自动化测试、数据管道、设计工作流。长周期任务需要跑几十分钟甚至几小时、中间可能失败需要恢复的场景。比如大规模数据采集、批量内容生成。多团队协作场景不同团队维护不同的 Agent 服务需要互相调用的场景。A2A 协议在这里价值最大。7.2 不适合的场景简单单步任务一句话能搞定的事用多智能体是杀鸡用牛刀反而增加复杂度和成本。强实时性任务多智能体的协调开销决定了它不适合毫秒级响应的场景。资源极度受限场景多智能体对算力和 token 的消耗都比单体高资源紧张时慎用。任务边界模糊的场景如果任务本身就没法清晰拆解多智能体反而会放大混乱。7.3 选型决策表场景特征推荐方案单步任务、工具少于 3 个单体 Agent多步骤、工具 3-10 个单体 Agent MCP多步骤、需要子任务隔离DeepAgents subagents多团队、跨系统协作DeepAgents MCP A2A高频重复操作上述 Skills 封装大规模生产环境全分布式 监控体系8. 后续可以怎么扩展这套架构搭起来后扩展方向其实很多。我自己在探索的几个方向方向一Agent 市场。把常用的子 Agent 和 Skills 做成可插拔的模块像装 App 一样按需加载。这样不同团队可以共享能力不用重复造轮子。方向二自适应编排。让主 Agent 根据任务特征动态决定用几个子 Agent、怎么分派而不是写死配置。这需要主 Agent 有更强的规划能力。方向三跨模态协作。现在大部分子 Agent 处理的是文本未来可以接入图像、音频、视频处理的子 Agent做真正的多模态协作。方向四自进化 Skills。让 Agent 在执行任务的过程中自动沉淀新的 Skill把成功的操作流程固化下来。这个方向很有意思但需要解决 Skill 质量把控的问题。方向五人机协作编排。在关键节点引入人工审核人可以做子 Agent 的上级也可以做协作者。这在需要高可靠性的场景里很有价值。最后分享一个我个人的体会多智能体系统的核心难点从来不是技术而是任务拆解的粒度。拆得太粗子 Agent 之间职责不清拆得太细协调开销超过收益。找到那个平衡点需要大量实践。我的经验是一个子 Agent 的任务最好控制在一个明确目标 3-5 个步骤的粒度这样既不会太粗也不会太细。这个粒度感只能靠多跑、多调、多踩坑来积累。
![洛谷 P2850：[USACO06DEC] Wormholes G ← Bellman-Ford 算法](http://pic.xiahunao.cn/yaotu/洛谷 P2850：[USACO06DEC] Wormholes G ← Bellman-Ford 算法)
的使用解读)
