企业官网建设流程全解析

1. 从单体到集群：为什么需要可编排的多智能体架构

过去一年我一直在折腾各种 Agent 框架，从最早的 ReAct 循环手写，到后来用 LangChain 的 AgentExecutor，再到各种 AutoGPT 式的自主循环。说实话，单体 Agent 的天花板非常明显——你给它再强的模型、再长的上下文，它一旦面对需要多领域协作、需要调用十几个不同工具、需要并行处理的任务时，就会开始"精神分裂"。要么工具描述塞爆上下文，要么任务链条一长就开始丢步骤，要么一个环节出错整个流程崩掉。

这就是为什么我看到DeepAgents + MCP + A2A + Skills这套组合的时候，第一反应是"终于有人把这事想明白了"。这套架构的核心思路不是造一个更聪明的单体 Agent，而是把 Agent 拆成可编排、可互通、可扩展的集群。打个比方，单体 Agent 像一个什么都干的自由职业者，能力再强也有边界；而多智能体集群像一家公司，有主脑负责拆解任务，有专职子 Agent 负责执行，有标准协议负责部门间沟通，有技能库负责沉淀可复用的能力。

DeepAgents在这里扮演的是"主脑 + 编排层"的角色。它最核心的能力是subagents（子智能体）机制——主 Agent 可以把一个复杂任务拆成若干子任务，分派给不同的子 Agent 去执行，每个子 Agent 有自己的上下文、自己的工具集、自己的专长。这解决了单体 Agent 上下文爆炸和任务串行的问题。

MCP（Model Context Protocol）解决的是"工具接入标准化"的问题。以前每接一个工具就要写一套适配代码，现在只要工具方提供 MCP Server，Agent 就能通过统一协议调用。你可以把它理解成 Agent 世界的 USB-C 接口——不管对面是数据库、浏览器、设计软件还是安全工具，插上就能用。

A2A（Agent 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_provider="openai") agent = create_deep_agent( model=model, 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 的三类核心接口：

我实测下来，MCP 最实用的场景是把本地工具标准化接入。比如你有一个 Playwright MCP Server，Agent 就能直接操控浏览器；有一个数据库 MCP Server，Agent 就能直接查库。热搜词里提到的 playwright mcp、burpsuite mcp、blender mcp、unity mcp、nxopen mcp、yakit mcp，本质上都是把各自领域的工具通过 MCP 协议暴露给 Agent。

配置 MCP Server 的典型方式（以配置文件为例）：

{ "mcpServers": { "playwright": { "command": "npx", "args": ["-y", "@playwright/mcp@latest"] }, "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 的"名片"。
• Task：Agent 之间的任务单元，有明确的生命周期状态（提交、处理中、完成、失败）。
• Message：Agent 之间的消息传递，支持多轮交互。

实际用起来，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 18+：

node --version # 确认 18+ npx --version

环境变量方面，至少需要配置模型 API Key：

export OPENAI_API_KEY="your-key" # 或者用其他模型提供商 export ANTHROPIC_API_KEY="your-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_provider="openai") @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( model=model, 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( command="npx", args=["-y", "@playwright/mcp@latest"] ) 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 Server）：

from 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.py

SKILL.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 的描述有重叠，它就会犹豫。

解决方法：

1. 给每个子 Agent 的 description 加上明确的"输入是什么、输出是什么、不负责什么"。比如 researcher 的描述里明确写"只做调研，不做分析判断"。
2. 在 system_prompt 里给出分派规则，比如"调研类任务一律给 researcher，分析类任务一律给 analyst"。
3. 如果还是分派混乱，可以在 description 里加负面示例，比如"不要用于数据分析任务"。

我踩过的一个坑是：一开始 researcher 和 analyst 的描述都写了"处理数据"，结果主 Agent 经常把分析任务分给 researcher。后来把 researcher 的描述改成"只负责检索和整理原始资料，不做任何分析判断"，问题就解决了。

4.2 MCP 工具调用超时或失败

MCP 工具调用失败的原因很多，我整理了一个排查表：

我的经验是：MCP Server 一定要先单独跑通再接入 Agent。很多人一上来就把 Server 配到 Agent 里，出错了根本不知道是 Server 的问题还是 Agent 的问题。正确做法是先用 MCP Inspector 或命令行工具单独测试 Server，确认工具能正常调用，再接入 Agent。

4.3 上下文爆炸与 token 超限

即使有了 subagents，如果子 Agent 返回的结果太长，主 Agent 的上下文还是会爆。

解决方法：

1. 强制子 Agent 返回摘要。在子 Agent 的 prompt 里明确要求"返回 300 字以内的摘要，原始资料写入文件"。
2. 用文件系统做中间存储。子 Agent 把详细结果写文件，只把文件路径和摘要返回给主 Agent。
3. 定期清理上下文。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。控制成本的关键是：

1. 子 Agent 用更便宜的模型。主 Agent 用强模型做规划，子 Agent 用便宜模型做执行。我实测下来，子 Agent 用 gpt-4o-mini 和 gpt-4o 的效果差距不大，但成本差 10 倍以上。
2. 缓存重复调用。同样的调研任务，结果可以缓存，避免重复消耗。
3. 控制子 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 选型决策表

8. 后续可以怎么扩展

这套架构搭起来后，扩展方向其实很多。我自己在探索的几个方向：

方向一，Agent 市场。把常用的子 Agent 和 Skills 做成可插拔的模块，像装 App 一样按需加载。这样不同团队可以共享能力，不用重复造轮子。

方向二，自适应编排。让主 Agent 根据任务特征动态决定用几个子 Agent、怎么分派，而不是写死配置。这需要主 Agent 有更强的规划能力。

方向三，跨模态协作。现在大部分子 Agent 处理的是文本，未来可以接入图像、音频、视频处理的子 Agent，做真正的多模态协作。

方向四，自进化 Skills。让 Agent 在执行任务的过程中自动沉淀新的 Skill，把成功的操作流程固化下来。这个方向很有意思，但需要解决 Skill 质量把控的问题。

方向五，人机协作编排。在关键节点引入人工审核，人可以做子 Agent 的"上级"，也可以做"协作者"。这在需要高可靠性的场景里很有价值。

最后分享一个我个人的体会：多智能体系统的核心难点从来不是技术，而是任务拆解的粒度。拆得太粗，子 Agent 之间职责不清；拆得太细，协调开销超过收益。找到那个平衡点，需要大量实践。我的经验是，一个子 Agent 的任务最好控制在"一个明确目标 + 3-5 个步骤"的粒度，这样既不会太粗也不会太细。这个粒度感，只能靠多跑、多调、多踩坑来积累。