企业官网建设流程全解析

从“单 Agent 硬扛所有事”到“一群 Agent 协同干活”，这个转变我是在一个真实项目里被逼出来的。项目是给团队做一套技术资讯自动聚合分析系统，需求很简单：定时抓取几十个技术博客和新闻源，做去重清洗、热度分析、分类打标，最后生成日报并推送到内部群。听起来工作量不大，但真用单一智能体去实现的时候，问题立刻暴露：工具越来越多、指令越来越长、上下文越来越乱，改一个需求就要重构整个 Prompt。后来我把架构改成 DeepAgents 做编排、MCP 统一接工具、A2A 打通智能体之间的通信、Skills 沉淀可复用的能力包，整套系统才算真正稳定下来。这篇就把我这次多智能体集群架构的设计思路、落地过程和踩坑经验完整梳理一遍，适合已经在用 Agent 做项目、想往多智能体方向升级的开发者参考。

1. 多智能体集群架构：先想清楚再动手

1.1 为什么单智能体不够用

很多人在刚接触智能体开发时，习惯把所有能力塞进一个 Agent 里：让它既能联网搜索，又能读写数据库，还能调用浏览器自动化工具、生成图表、发消息。早期这样确实能跑通，但项目一复杂就会出现三个典型痛点。

第一个是上下文窗口瓶颈。单 Agent 的对话历史是持续累积的，工具调用结果、中间推理过程、用户指令全部挤在同一段上下文里。做一轮完整的数据采集和分析，光工具返回的原始内容就可能占用几万 token，再叠加反思、纠错、重试等循环，很快就把上下文空间吃完。到了后期，Agent 会开始“遗忘”早期指令，行为变得不可预测。

第二个是提示词相互干扰. 我在单 Agent 里同时写了“抓取网页时遵守 robots 原则”和“对正文做摘要时控制字数”这两类指令，初看互不相干。但实际运行中，Agent 会在抓取阶段把摘要指令也混进去，导致它为了控制输出长度而截断抓取结果。这类指令耦合问题在单一智能体里几乎无法避免，因为所有工具和规则都在同一个决策空间里竞争。

第三个是故障恢复困难. 单 Agent 任何一个子任务失败，比如某个网站超时、某个字段解析出错，整个任务链就可能中断。由于没有分层，你很难定位是“工具调用出错”还是“指令理解偏差”，只能不断加 try-catch 式的自然语言兜底，最终 Prompt 越来越臃肿，系统越来越脆。

我对多智能体集群的第一感受很直接：不是因为它听起来高级才用，而是单 Agent 的结构性缺陷逼着你拆分。把不同职责交给不同智能体，等于把上下文、提示词、故障域都做了物理隔离，每个 Agent 只需要关心自己的那部分逻辑。

1.2 集群的分层设计思路

多智能体集群不是说把一堆 Agent 随便跑起来就行，架构上必须有清晰的分层。我这次采用的是四层结构。

• 编排层：由主控智能体（Supervisor Agent）负责理解用户目标、拆解任务、调度子智能体、汇总结果。
• 执行层：由若干子智能体（Sub Agent）分别承担采集、清洗、分析、生成等具体任务，每个子智能体只维护自己的上下文和工具集合。
• 能力层：通过 MCP Server 统一接入浏览器控制、文件读写、数据库等工具；通过 Skills 封装可复用的专业流程，供各层智能体按需加载。
• 通信层：执行层内部的子智能体之间、执行层与编排层之间，通过 A2A 协议交换结构化消息和任务状态。

这套分层设计的好处是每一层可以独立演进。比如我想给系统增加一个“自动配图”能力，只需要新增一个配图子智能体，通过 A2A 暴露服务，再把它的 Agent Card 注册到编排层，主控 Agent 就能发现并使用它，完全不需要改动其他模块。

在设计角色时，我还定了一条原则：能用简单工具解决的事不要单独发明一个子智能体。只有当某个子任务本身需要“理解上下文、做决策、多步骤执行”时，才值得拆出一个 Agent。采集网页用 MCP 工具就够了，但“判断一篇文章是否值得收录”就需要一个带有判断标准和反思能力的子智能体。这个边界一定要控制好，否则集群会变成一场通信灾难。

2. 四个核心组件各自解决什么问题

2.1 DeepAgents：编排底座与深度思考范式

DeepAgents 这套范式强调“先思考、再行动，边行动、边反思”。和传统 ReAct 模式不一样的地方在于，它支持分层规划：主智能体在接到复杂任务时，会先展开一个深度的思考过程，拆解出子目标，再决定是自己调用工具还是委派给子智能体。这种“深度思考”机制在长链条任务里特别关键。

我这次用 LangChain 生态里的 DeepAgents 相关模块作为编排底座。它的核心能力有几个：一是支持子智能体的动态生成与回收，主控 Agent 可以根据任务临时创建专用子 Agent，而不是启动时把所有 Agent 都拉起来；二是带状态管理，配合 Checkpointer 可以把每个智能体的状态持久化，任务中途断了还能续跑；三是和 LangGraph 的图结构结合，能显式定义智能体之间的依赖关系和切换条件。

以我的项目为例，主控 Agent 接收到“生成今日技术资讯日报”这个目标后，会经历一轮内部规划，生成类似这样的执行计划：

1. 获取 RSS 源列表并抓取原始文章（采集子智能体） 2. 对原始内容做去重与正文提取（清洗子智能体） 3. 按主题聚类并计算热度指标（分析子智能体） 4. 生成日报 Markdown 并推送（生成子智能体）

然后主控 Agent 按计划逐个调度，而不是把所有步骤塞进一条 Prompt 里让模型自由发挥。这种编排方式显著提升了任务完成的确定性，也让每一步的执行结果更容易被检查和审计。

2.2 MCP：工具接入从“每家一套”到“一个协议走天下”

MCP（Model Context Protocol）全称是模型上下文协议，它解决的是智能体与外部工具之间连接方式标准化的问题。我用一个类比来理解它：在 MCP 出现之前，每个工具都要为每个智能体单独写适配层，就像每个设备都要配各自的充电线；MCP 出现之后，工具提供方只要实现一个 MCP Server，任何支持 MCP 的客户端都能直接复用，相当于统一成了 USB-C 接口。

MCP 的架构很简单，包含三个角色：

• Host：宿主程序，比如我们的智能体应用或者 Claude Desktop、Cursor 这类客户端。
• Client：在 Host 内部与 Server 建立连接的组件。
• Server：暴露工具、资源、提示等能力的服务进程。

在我的集群里，MCP 的定位是“能力接入层”。我用到的几个典型 MCP Server 包括：

• Playwright MCP：给智能体提供浏览器自动化能力，用于采集动态渲染的页面。
• Chrome DevTools MCP：直接驱动 Chrome 的调试协议，适合做性能检测和页面状态分析。
• 文件系统 MCP：让智能体可以读写本地目录，用于保存采集结果和中间产物。
• 数据库 MCP：统一封装 MySQL 查询，让多个子智能体能安全地访问数据。

配置方式上，我维护了一个统一的 MCP 配置清单，类似下面的结构：

{ "mcpServers": { "playwright": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-playwright"] }, "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/var/data"] }, "database": { "command": "python", "args": ["mcp_db_server.py"], "env": { "DB_CONN_STR": "postgresql://user:pass@localhost:5432/newsdb" } } } }

每个子智能体会在启动时根据角色声明自己需要的 MCP Server。比如采集子智能体只挂载 Playwright 和文件系统，分析子智能体只挂载数据库。这样做既能控制工具集复杂度，也能减少模型被无关工具干扰的概率。很多人在多智能体系统里忽略这一点，把所有 MCP 工具一股脑塞给每个 Agent，结果是模型在几十个工具中间反复纠结，性能和准确率双双下降。

2.3 A2A：智能体之间的“对话协议”

多智能体集群不能只靠调用工具来协作，子智能体之间、以及和外部第三方智能体之间都需要一套标准化的通信协议，这就是 A2A（Agent-to-Agent）协议的价值。

A2A 的核心概念有三个：

• Agent Card：每个 Agent 对外发布的“名片”，声明自己的能力、服务地址、支持的技能、认证方式等。
• Task：通信的基本单元，一个智能体向另一个智能体发起任务，任务有生命周期，包括 pending、working、completed、failed 等状态。
• Artifact：任务执行过程中或完成后产生的结构化产物，比如文章、代码、数据分析结果。

我的系统里有一个真实场景很好地体现了 A2A 的作用。分析子智能体做完主题聚类后，需要把结果传给生成子智能体去写日报。如果走内部函数调用，两个智能体的生命周期就耦合在一起；而通过 A2A，分析子智能体只需要创建一个任务，把聚类结果作为 Artifact 提交，生成子智能体通过 Task 更新事件拿到产物，自己独立完成后续工作。任何一方崩溃都不会直接拖垮对方，通信状态清晰，也方便重试。

A2A 协议的 Agent Card 注册方式类似这样：

{ "name": "news-scheduler", "displayName": "资讯调度主控智能体", "description": "负责技术资讯日报任务的拆解、调度与结果汇总", "url": "http://127.0.0.1:8200/a2a", "skills": [ "task-planning", "report-summary" ], "capabilities": { "streaming": true, "pushNotifications": false } }

业界一直在讨论 MCP 和 A2A 的关系，我的理解是两者分工完全不同：MCP 解决的是“智能体怎么用工具”，A2A 解决的是“智能体怎么找智能体、怎么跟智能体协作”。打个比方，MCP 是手和工具之间的接口，A2A 是人与人之间的沟通方式。在实际集群里，一个子智能体通过 MCP 调用工具完成任务，再通过 A2A 把结果交付给另一个子智能体，两条通道各有职责，并不冲突。

2.4 Skills：把经验沉淀成可复用的技能包

Skills 是最近热度很高的一个概念。它和普通 Prompt 模板的区别在于，Skills 是一种标准化的交付格式，通常包含一个 Markdown 格式的技能清单文件（类似 SKILL.md）和相关的脚本、参考资源，打包成一个目录整体加载。当智能体遇到匹配任务时，会从技能库中检索并加载对应的技能，相当于给模型一份“操作手册”加上配套工具。

我建议把 Skills 理解为“给智能体装上的岗位培训手册”。比如我开发了一个“技术资讯去重”技能，它长这样：

--- name: tech-news-deduplication description: 对抓取到的技术资讯条目做智能去重，支持标题归一化和正文相似度计算 --- ## 适用场景 - 多个站点转载同一内容时 - 标题相似度超过 0.85 且正文相似度超过 0.6 时 ## 操作步骤 1. 提取所有候选条目的标题和正文 2. 对标题做归一化处理：去掉标点、日期、站点名称后缀 3. 使用编辑距离和 Jaccard 相似度双指标判定 4. 保留发布时间最早的来源作为主条目 5. 输出去重后的结构化列表 ## 注意事项 - 不要对绕过版权声明的内容做去重合并 - 相似度阈值需要根据数据量动态调整

这个技能文件本身是纯文本，但配套了一个 Python 脚本用来算相似度。Agent 在加载这个 Skill 后，不需要我在每次任务里重复解释去重逻辑，它直接能按流程执行。在实践中，我甚至把一些模型容易忘记的审计规则也做成了 Skill，比如“日报生成时必须包含数据来源和时间戳”，因为这些内容如果放在系统 Prompt 里很容易被长对话稀释，但作为 Skill 按需加载时，模型会把它当作一份独立参考资料，执行效果要好很多。

Skills 非常适合在多智能体集群中做能力复用。同一个“去重”技能，既可以加载到清洗子智能体，也可以临时给分析子智能体用；我在集群里维护了一个 skills 目录作为共享技能库，效果相当于给每个 Agent 配了一个可随时查阅的操作手册库。

3. 实战：一个多智能体集群从零落地

3.1 场景定义与角色分配

我选择“技术资讯自动聚合分析系统”作为实战示例。系统需要完成的任务链路是：采集多个技术站点的 RSS 和网页内容，清洗去重，按主题聚类，统计热度，生成 Markdown 日报，最后通过 webhook 推送到企业微信群。

围绕这条链路，我定义了六个智能体角色：

这里要特别强调一个设计取舍：采集智能体和发布智能体本来也可以合并进主控智能体，但它们在权限需求上完全相反。主控智能体需要读取所有中间结果，并不意味着它要能直接操作浏览器和发送消息。隔离权限、隔离上下文、隔离故障域，是我拆分角色的首要依据。

3.2 环境搭建与基础设施准备

整个集群我跑在一台 Linux 服务器上，使用 Docker Compose 管理各个智能体服务和 MCP Server。基础环境包括 Python 3.11、Node.js 20、Redis（用于任务状态缓存和 A2A 消息交换），以及一个 PostgreSQL 数据库用来存采集结果和分析产出。

代码结构大致如下：

mult-agent-cluster/ ├── agents/ │ ├── supervisor/ # 主控智能体 │ ├── collector/ # 采集智能体 │ ├── cleaner/ # 清洗智能体 │ ├── analyzer/ # 分析智能体 │ ├── writer/ # 生成智能体 │ └── publisher/ # 发布智能体 ├── skills/ # 共享技能库 │ ├── deduplication/ │ ├── clustering/ │ ├── report-format/ │ └── ... ├── mcp-servers/ # 自定义 MCP Server │ ├── database_mcp/ │ └── wecom_mcp/ ├── a2a/ # A2A 协议实现 │ └── registry/ ├── docker-compose.yml └── .env

每个智能体目录里都是一个独立的 Python 服务，拥有自己的依赖和启动脚本。启动顺序有讲究：先启动 Redis 和数据库，再启动 MCP Server，然后启动各个子智能体服务，让它们注册 A2A Agent Card，最后启动主控智能体。如果顺序反了，主控智能体会因为找不到 Agent 注册信息而拒绝调度。

3.3 基于 DeepAgents 的主控与子智能体实现

主控智能体是集群的“大脑”，我基于 DeepAgents 的编排范式实现了它的核心逻辑，伪代码大致是这样的：

from langchain_deepagents import create_deep_agent from langchain_openai import ChatOpenAI from langgraph.checkpoint.memory import InMemorySaver model = ChatOpenAI(model="gpt-4o", temperature=0.2) checkpointer = InMemorySaver() # 注册 A2A 连接器作为主控的工具 a2a_tools = [ A2AAgentConnector( agent_card_url="http://127.0.0.1:8300/a2a", agent_name="collector" ), A2AAgentConnector( agent_card_url="http://127.0.0.1:8400/a2a", agent_name="cleaner" ), # ... ] supervisor = create_deep_agent( model=model, tools=a2a_tools, checkpointer=checkpointer, system_prompt=( "你是技术资讯聚合分析系统的调度中枢。你的职责是：\n" "1. 将用户目标拆解为可执行的子任务；\n" "2. 通过 A2A 协议将子任务分发给对应子智能体；\n" "3. 收集各子智能体的产物并做最终校验；\n" "4. 如有子任务失败，最多重试两次，仍失败则跳过并记录异常。" ), )

子智能体则是一个带 MCP 工具集和对应 Skill 的独立 Agent。比如采集智能体的核心逻辑：

from langchain_deepagents import create_deep_agent from langchain_mcp_adapters.client import MultiServerMCPClient async def main(): async with MultiServerMCPClient({ "playwright": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-playwright"], "transport": "stdio", }, "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/data/raw"], "transport": "stdio", }, }) as mcp_client: tools = mcp_client.get_tools() agent = create_deep_agent( model=model, tools=tools, system_prompt=load_skill("skills/rss-collection"), ) # 启动 A2A 服务，等待主控下发任务 await run_a2a_server(agent, port=8300)

这里面的关键点在于：子智能体不需要关心“日报要怎么排版”这类问题，它的系统提示词全部来自采集方面的 Skill 描述，目标单一，上下文干净，工具也只有采集需要的两个 MCP Server，决策效率明显提升。

3.4 用 MCP 接入第三方能力

MCP Server 在实战中不只是配置那么简单，我踩过的最大的坑是连接方式的选择。MCP 支持 stdio 和 HTTP/SSE 两种典型传输方式。

• stdio 方式适合轻量级工具，比如文件系统、命令行工具，由父进程直接拉起子进程，生命周期跟着进程走，部署最简单。
• HTTP/SSE 方式适合需要常驻服务的工具，比如数据库服务，独立部署、独立重启，子智能体断了还能重连。

我的经验是：能给一个 Agent 用的本地工具就走 stdio，多个 Agent 共享的公共服务必须走 HTTP。我在初期把所有 MCP Server 都配成了 stdio，结果每次某个子智能体重启，所有依赖它的连接进程也会被一起杀掉，非常被动。后来把数据库和企业微信两个公共 MCP Server 独立成常驻服务，集群稳定性立刻上了一个台阶。

3.5 Skills 的开发与装载流程

Skills 的开发不能太随意，否则会变成“另一个 Prompt 文件夹”，模型不知道该在什么场景用。我的开发流程分五步：

• 第一步：确定技能边界。一个 Skill 只解决一个问题，比如“去重”“聚类”“日报模板校验”，绝不混合两个不相关的目标。
• 第二步：写清触发条件。在 SKILL.md 的 frontmatter 里明确描述适用场景，方便模型检索。
• 第三步：补充执行步骤和参考示例。步骤要细化到模型能直接照着做，参考示例展示输入输出格式。
• 第四步：配置配套工具脚本。比如去重技能需要一个相似度计算脚本。
• 第五步：在技能库中注册，并通过多组测试任务验证触发准确率和执行效果。

我还发现一个小技巧：Skill 的加载路径可以通过 A2A 通信在集群里共享。子智能体在启动时从/skills目录读取自己的技能包，主控智能体则通过 A2A 的 Agent Card 上的 “skills” 字段，快速了解每个子智能体具备什么能力，从而更准确地分发任务。这个字段在初期被我当成了摆设，后来发现它对模型做规划决策有非常直接的帮助。

4. 协同调度中的关键策略

4.1 任务分发：不要让任何一个 Agent 过载

多智能体集群最怕的就是“看起来在协作，实际上在排队”。我在主控智能体的调度逻辑里加入了优先级和并发控制。采集任务是 IO 密集型的，可以一次并发给多个采集实例；分析任务是 CPU 密集型的，一次只跑一个。主控 Agent 在分发前会检查目标子 Agent 的任务队列长度，超过阈值就暂不分发或换一个同样能力的实例。

这背后我用的是一套简单的任务分发表，主控智能体维护在 Redis 里：

{ "task_id": "task_20250618_001", "type": "collect", "priority": 5, "status": "pending", "assigned_to": "collector-1", "payload": { "sources": ["rss://xxx", "https://yyy"], "max_items": 100 }, "created_at": "2025-06-18T08:00:00Z" }

主控 Agent 在每次规划时都会优先扫描这些任务分发表，而不是靠模型自己“记住”待办事项。这实际上是把 Agent 短时记忆的负担转移到外部系统，模型只需要做决策，不需要做记忆。

4.2 状态同步与结果回收

子智能体执行完任务后，把结果以 Artifact 形式返回给主控。Artifact 不只是一段文本，我还要求带上元信息，例如产出时间、数据类型、可信度评分、依赖的原始文件路径。这些元信息对后续审计和能力评估很重要。

我遇到过一种情况：清洗子智能体输出了“已去重 100 条”的结果，但分析子智能体拿到的实际数据只有 80 条，中间有 20 条因为格式不完整被静默丢弃了。后来我在 Artifact 结构里增加了一个warnings字段，任何子智能体在执行中遇到的异常都要写入，主控 Agent 汇总时会检查所有 warnings 并决定是否重新调度。这个改动带来的稳定性提升非常明显，也让整个集群的行为变得透明可观测。

4.3 上下文隔离与共享策略

多智能体集群里，上下文管理是最容易被忽视又最影响效果的部分。我的做法是：默认隔离，按需共享。每个子智能体只能看到自己任务相关的输入和输出，不直接接触其他子智能体的原始上下文。共享数据统一通过数据库或文件系统中的中间产物来流转，由主控 Agent 控制读写权限。

比如采集智能体抓到的原始 HTML 文件直接落盘，清洗智能体读取落盘文件并写入清洗后的结构化结果，分析智能体只读清洗结果。整个过程没有一个 Agent 需要看到“别的东西的完整上下文”。这种数据流转方式还带来一个额外好处：即使某个子智能体因为模型版本升级或技能加载异常，生成了不稳定的结果，我也可以从落盘数据回溯问题，而不是在一团乱麻的对话历史里找原因。

5. 排障记录与踩坑清单

5.1 MCP 连接不稳定的排查

MCP 连接问题是我遇到频率最高的故障。常见现象包括工具调用超时、工具返回空结果、stdio 进程反复重启。我总结了一套排查路径：

• 先看 MCP Server 是否还活着：通过ps检查进程，通过健康检查接口确认服务状态。
• 再看传输方式是否合理：stdio 方式下，如果宿主进程崩溃，子进程也会被回收；换 HTTP 方式可以隔离生命周期。
• 最后看工具定义是否超限：有些 MCP Server 返回的工具 schema 过大，会让模型的工具选择变慢甚至报错。可以精简服务端暴露的工具，只留下当前任务需要的。

5.2 Skills 加载不生效

Skills 加载不生效的表现是：模型完全无视 Skill 里写的操作步骤，凭“自己的理解”乱来。问题通常出在触发条件描述不够精准。模型检索技能时主要靠名称、描述字段与任务目标的语义相关性，如果描述里写的都是“处理文章”这种宽泛词，模型可能把去重技能误当成摘要技能。

解决办法是把触发条件写得更具象，比如描述里写“输入是抓取的 HTML 原文，输出是结构化 JSON，执行步骤涉及标题归一化、正文相似度计算”。模型一看就知道这个技能对应的具体输入输出格式和任务场景，触发准确率明显提升。另外，技能文件里不要放太多与步骤无关的背景介绍，模型会被带偏。

5.3 A2A 握手与任务超时

A2A 在跨主机部署时容易出问题。首先是 Agent Card 的 URL 配置，我配置的是127.0.0.1，在容器内访问没问题，换到其他容器就发现找不到服务，因为地址解析范围不对。排查了很久才意识到，需要把注册地址改成服务名或宿主机可访问的 IP。

其次是任务超时问题。A2A 的任务通常有超时限制，但我的分析任务经常超过默认超时时间。解决方法是把长任务拆小，或者启用 streaming 模式，让执行方能持续发送进度事件，避免握手被断开。我在 A2A 配置里把streaming和pushNotifications都开启了，进度事件会让通信链路保持活跃，也能让主控实时看到任务状态。

5.4 快速排障速查表

5.5 兜底机制：人工复核仍然必要

最后说一个容易被忽略的教训：多智能体集群再完善，也不代表完全不用管。我在系统里保留了一个“人工审核”步骤，每日日报生成后先不发进正式群，而是发到预发布渠道，由团队值班人员确认后再发布。这个动作看着保守，但实际省了很多麻烦。因为智能体集群的失败模式有时候是隐性的：模型按照预期流程走完了每一步，但某个中间环节因为数据质量问题产出了错误结论。这种错误在编排上完全无法自检，人工审核是最后的保险丝。

我个人在这套集群跑通之后最深的体会是：架构的意义不在于热闹，而在于把不可控的模型行为放进可控的流程容器里。DeepAgents 负责决策，MCP 负责接工具，A2A 负责通信，Skills 负责沉淀经验，每一层都是独立的，组合起来却形成了一条稳定可观测的生产链路。后续我还在往集群里接入更多 Skills，比如前端开发辅助类和数据分析类技能包，让主控 Agent 能按需为不同项目动态组建“临时团队”。这条路既然走通了，就值得继续往深处走。