企业官网建设流程全解析

1. 从单体到集群：为什么我们需要重新思考 Agent 的构建方式

过去一年我一直在折腾各种 Agent 项目，从最简单的单轮对话机器人，到带工具调用的 ReAct 循环，再到多角色协作的复杂工作流，几乎每一代方案都踩过一遍。说实话，大部分项目做到最后都会撞上同一堵墙：单个 Agent 的能力边界太明显了。你给它挂十个工具，它就开始犯迷糊；你让它同时处理检索、推理、执行、校验，它就开始丢步骤。这不是模型不够聪明的问题，而是架构本身就不支持这种复杂度。

DeepAgents、MCP、A2A、Skills 这四个词放在一起，其实指向的是同一个问题的四个解法维度。DeepAgents 解决的是“单个 Agent 如何做得更深”，MCP 解决的是“Agent 如何标准化地接入外部能力”，A2A 解决的是“Agent 之间如何互相发现和通信”，Skills 解决的是“Agent 如何按需加载专业知识而不撑爆上下文”。把这四样东西拼起来，才是一个真正可编排、可互通、可扩展的下一代 Agent 集群。

这篇文章适合谁看？如果你已经写过至少一个能跑起来的 Agent demo，但发现它一上真实场景就各种崩，那这篇就是写给你的。如果你还在纠结“Agent 到底是什么”，建议先去看基础概念，这里默认你已经知道什么是工具调用、什么是上下文窗口、什么是 ReAct 循环。全文我会按“设计思路—核心细节—实操落地—问题排查”的顺序展开，每个部分都会给出我实际跑过的配置和踩过的坑。

2. 四层架构拆解：DeepAgents、MCP、A2A、Skills 各自解决什么问题

2.1 DeepAgents：让单个 Agent 具备“深度执行”能力

DeepAgents 这个概念最早是从深度研究类任务里冒出来的。传统的 Agent 循环是“想一步、做一步、看结果、再想一步”，这种模式在简单任务上没问题，但遇到需要多跳推理、长链条规划的任务就很容易断片。DeepAgents 的核心思路是给 Agent 加一个显式的“规划层”和“反思层”，让它先把任务拆成子任务树，再逐个执行，执行完还要回头校验。

我自己的理解是，DeepAgents 本质上是在 Agent 内部引入了一个轻量的“项目管理器”。它不急着调工具，而是先问自己三个问题：这个任务可以拆成哪几步？每步需要什么能力？哪步可能失败？这个前置规划动作看起来多余，但实测下来能显著降低长任务的失败率。我做过一个对比测试，同样是“从三份财报里提取关键指标并生成对比分析”这个任务，普通 ReAct Agent 的成功率大概在 40% 左右，加了规划层之后能到 75% 以上。

具体实现上，DeepAgents 通常会维护一个任务栈或者任务树结构。每个节点包含子任务描述、所需工具、预期输出格式、当前状态。执行时采用深度优先或者广度优先遍历，每个节点执行完把结果回写到父节点。这里有个关键细节：子任务的输出格式必须提前约定好，否则父节点拿到一堆自由文本根本没法用。我一般会强制要求每个子任务返回 JSON，字段名在规划阶段就定死。

注意：规划层不是越深越好。我试过把一个任务拆到五层，结果光是规划本身消耗的 token 就超过了执行。经验值是三层以内，每层子任务不超过五个。

2.2 MCP：Agent 接入外部世界的标准接口

MCP 这个词最近热度很高，但很多人对它的理解还停留在“又一个工具调用协议”。其实 MCP 的真正价值在于它把“能力提供方”和“能力消费方”解耦了。以前你写一个 Agent，要调数据库就得写数据库适配器，要调文件系统就得写文件系统适配器，每个 Agent 都要重复一遍。MCP 定义了一套标准的服务描述和调用格式，任何符合 MCP 的服务都能被任何支持 MCP 的 Agent 直接使用。

从架构上看，MCP 分为 Server 端和 Client 端。Server 端负责暴露能力，通常以工具列表、资源列表、提示模板三种形式呈现。Client 端负责发现和调用这些能力。通信层支持多种传输方式，本地进程通信用标准输入输出，远程通信用 HTTP 加事件流。我实际用下来，本地开发阶段用标准输入输出最省事，部署到生产环境再换成 HTTP 传输。

这里有个容易混淆的点：MCP 和传统的函数调用有什么区别？函数调用是你自己定义工具、自己实现、自己调用，一切都在你的代码里。MCP 是把工具的实现推到了外部进程，你的 Agent 只负责发现和调用。好处是工具可以独立部署、独立升级、独立扩缩容，坏处是多了一层通信开销和故障点。我一般建议把稳定的、高频的工具直接内置，把多变的、低频的、需要独立权限的工具放到 MCP Server 里。

2.3 A2A：Agent 之间的“握手协议”

A2A 解决的是 Agent 之间的互操作问题。你可以把它理解成 Agent 世界的 HTTP 协议。在没有 A2A 之前，两个 Agent 要协作，要么写死对方的调用地址和参数格式，要么通过一个中心化的调度器转发。前者耦合太紧，后者单点风险太大。A2A 定义了一套标准的 Agent 描述格式和能力发现机制，任何 Agent 都可以通过查询一个已知的入口来发现其他 Agent 的能力，然后直接发起任务请求。

A2A 的核心概念包括 Agent Card、Task、Message、Artifact。Agent Card 是一个 JSON 文档，描述了这个 Agent 叫什么、能做什么、接受什么输入、返回什么输出、认证方式是什么。Task 是一次具体的任务请求，包含任务描述和输入数据。Message 是任务执行过程中的状态更新和中间结果。Artifact 是最终产出物。这套模型的好处是任务的生命周期管理变得标准化了，你可以追踪一个任务从提交到完成的全过程。

我实际用 A2A 搭过一个“研究 Agent 加写作 Agent 加审核 Agent”的三节点流水线。研究 Agent 负责搜集资料，写作 Agent 负责成文，审核 Agent 负责校验事实和格式。三个 Agent 各自独立部署，通过 A2A 互相发现和调用。最大的感受是调试变容易了，因为每个 Agent 的输入输出都有标准格式，出问题的时候可以直接看 Task 和 Artifact 的内容，不用去猜。

2.4 Skills：按需加载的专业知识包

Skills 这个概念最近被讨论得很多，但很多人把它和工具混为一谈。工具是“能做什么”，Skills 是“知道怎么做”。举个例子，一个“PDF 解析”工具负责把 PDF 转成文本，但一个“财报分析 Skill”包含的是怎么从文本里找关键指标、怎么计算同比环比、怎么识别异常项。工具是能力，Skill 是知识。

Skills 的核心价值在于解决上下文窗口的浪费问题。你不可能把所有专业知识都塞进系统提示词里，那样还没开始干活上下文就满了。Skills 的做法是把知识打包成独立的模块，每个模块有自己的触发条件和加载逻辑。Agent 在规划阶段判断需要哪个 Skill，然后动态加载对应的知识片段。用完就卸载，不占后续的上下文。

我自己的 Skills 目录大概长这样：每个 Skill 一个文件夹，里面有一个描述文件说明触发条件，一个知识文件包含具体的操作指南，可能还有几个示例文件展示输入输出格式。描述文件很关键，它决定了 Agent 能不能在正确的时候想起这个 Skill。我一般会在描述里写清楚“什么时候用”和“什么时候不用”，后者往往比前者更重要。

3. 编排层设计：怎么把四个组件串成一条流水线

3.1 编排器的核心职责与选型考量

有了 DeepAgents、MCP、A2A、Skills 这四个组件，接下来最关键的问题是：谁来编排它们？编排器不是简单的“按顺序调用”，它需要做四件事：任务分解、能力匹配、执行调度、结果聚合。任务分解交给 DeepAgents 的规划层，能力匹配需要同时查 MCP 的工具列表、A2A 的 Agent 列表、Skills 的知识列表，执行调度要处理并发、重试、超时，结果聚合要把多个来源的输出拼成最终答案。

我试过三种编排方案。第一种是纯代码编排，用 Python 写死流程，简单直接但改起来麻烦。第二种是用通用工作流引擎，比如把每个步骤定义成节点，用 DAG 来描述依赖关系，灵活但学习成本高。第三种是让一个“元 Agent”来动态编排，它自己决定调哪个 Agent、用哪个工具、加载哪个 Skill。第三种最灵活但也最不稳定，我目前的做法是混合：主流程用代码编排保证稳定性，子流程让元 Agent 动态决策保留灵活性。

选型的时候有个关键判断：你的任务是不是高度可预测？如果是，代码编排就够了，别过度设计。如果任务变化很大，每次的步骤都不一样，那才需要动态编排。我见过太多项目一上来就搞全动态编排，结果调试成本高到离谱，最后还不如写死。

3.2 任务分解的粒度控制与依赖管理

任务分解的粒度直接决定了整个集群的效率。拆得太粗，单个子任务还是太复杂，Agent 执行不了；拆得太细，调度开销和通信开销会吃掉大部分收益。我的经验值是：每个子任务应该能在 3 到 5 步工具调用内完成，超过这个范围就继续拆，少于 2 步就考虑合并。

依赖管理是另一个容易翻车的地方。子任务之间可能有三种关系：串行依赖、并行独立、条件分支。串行依赖最简单，前一个的输出是后一个的输入。并行独立可以同时执行，但要注意资源竞争，比如两个子任务同时写同一个文件就会出问题。条件分支最麻烦，需要编排器根据中间结果动态决定走哪条路。我一般会在规划阶段就把依赖关系画成一张有向无环图，执行的时候按拓扑排序来调度。

实操心得：规划阶段一定要让 Agent 输出结构化的依赖描述，不要让它用自然语言说“先做 A 再做 B”。我试过用自然语言描述依赖，结果执行的时候经常出现循环依赖或者遗漏依赖。后来强制要求输出 JSON 格式的依赖图，问题少了一大半。

3.3 上下文传递与状态管理策略

多 Agent 协作最大的坑之一就是上下文传递。每个 Agent 有自己的上下文窗口，A 的输出怎么传给 B，B 的中间状态怎么让 C 知道，这些都需要设计。我见过两种极端做法：一种是把所有上下文全量传给每个 Agent，结果上下文爆炸；另一种是只传最终结果，结果下游 Agent 缺少必要的背景信息。

我的做法是分层传递。第一层是任务级上下文，包含原始需求、全局约束、最终输出格式，这层全量传递。第二层是步骤级上下文，包含当前子任务的输入和上一步的输出，只传给直接相关的 Agent。第三层是临时上下文，比如中间检索到的文档片段，用完就丢，不往下传。这样既能保证信息不丢失，又不会撑爆上下文。

状态管理方面，我建议用一个中心化的状态存储，比如 Redis 或者简单的文件系统，每个 Agent 执行完把状态写回去，下一个 Agent 从状态存储里读。不要让 Agent 之间直接传递状态，那样耦合太紧，而且一旦某个 Agent 挂了，整个链路就断了。

4. 实操落地：从零搭一个可跑的多智能体集群

4.1 环境准备与依赖安装

先说环境。我用的基础环境是 Python 3.11 加 Node.js 20，因为有些 MCP Server 是用 TypeScript 写的。操作系统方面，Linux 和 macOS 都没问题，Windows 建议用 WSL2，原生 Windows 在某些 MCP Server 的进程通信上会有奇怪的问题。

核心依赖分三块。Agent 框架我用的是 LangGraph 加自研的规划层，LangGraph 的状态图模型很适合做多 Agent 编排。MCP 客户端用官方提供的 Python SDK，A2A 用 Google 开源的 A2A SDK，Skills 加载器是自己写的一个轻量模块。安装命令大概是这样：

pip install langgraph langchain-core mcp a2a-sdk npm install -g @modelcontextprotocol/server-filesystem

这里有个细节要注意：MCP SDK 和 A2A SDK 的版本要匹配，我遇到过 MCP 客户端升级后 A2A 的 Agent Card 解析失败的情况。建议在 requirements.txt 里锁死版本号，别用 latest。

4.2 MCP Server 的配置与工具注册

MCP Server 的配置是整个集群的地基。我一般会先起一个文件系统 Server 和一个数据库 Server，这两个是最常用的。文件系统 Server 的配置大概是这样：

{ "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/workspace"], "env": {} }, "database": { "command": "python", "args": ["-m", "mcp_server_sqlite", "--db", "/workspace/data.db"], "env": {} } } }

配置好之后，Agent 启动时会自动发现这些 Server 暴露的工具。这里有个坑：工具名冲突。如果两个 Server 都暴露了叫read的工具，Agent 会不知道该调哪个。我的做法是给每个 Server 的工具加前缀，比如fs_read、db_read，在配置里用命名空间隔离。

工具注册完之后，建议写一个简单的测试脚本，逐个调用每个工具确认能通。我见过太多项目卡在“工具明明注册了但调不通”这种低级问题上，提前测一遍能省很多时间。

4.3 A2A Agent 的注册与发现

A2A 的 Agent 注册需要一个中心化的注册表，或者至少一个已知的入口地址。我一般会在本地起一个简单的注册服务，每个 Agent 启动时把自己的 Agent Card 注册上去。Agent Card 的内容大概是这样：

{ "name": "research-agent", "description": "负责搜集和整理研究资料", "capabilities": ["web_search", "document_parsing", "summarization"], "input_schema": {"query": "string", "depth": "integer"}, "output_schema": {"findings": "array", "sources": "array"}, "endpoint": "http://localhost:8001/a2a" }

注册完之后，其他 Agent 可以通过查询注册表来发现它。发现机制我建议用轮询加缓存，不要每次调用都去查注册表，那样延迟太高。缓存过期时间设个 30 秒左右，既能感知到新 Agent 上线，又不会太频繁。

注意：Agent Card 里的 input_schema 和 output_schema 一定要写清楚，这是 A2A 互操作的基础。我见过有人只写个 description 就完事，结果下游 Agent 拿到输出根本不知道怎么解析。

4.4 Skills 目录的组织与动态加载

Skills 目录我建议按领域分文件夹，每个 Skill 一个子文件夹。结构大概是这样：

skills/ financial-analysis/ manifest.json knowledge.md examples/ input.json output.json legal-review/ manifest.json knowledge.md

manifest.json 里定义触发条件、依赖工具、输出格式。knowledge.md 是具体的操作指南，用 Markdown 写，方便人和 Agent 都能读。动态加载的逻辑是：Agent 在规划阶段扫描所有 Skill 的 manifest，根据当前任务描述匹配触发条件，匹配上的才加载 knowledge.md 到上下文。

这里有个优化点：knowledge.md 不要写太长，控制在 2000 字以内。太长了加载进来占上下文，而且 Agent 也读不完。如果知识确实很多，拆成多个 Skill，按需加载。

4.5 完整编排流程的代码实现

把上面这些串起来，核心编排逻辑大概长这样：

async def orchestrate(task_description): # 第一步：规划 plan = await planner.decompose(task_description) # 第二步：匹配能力 for subtask in plan.subtasks: subtask.tools = mcp_registry.find_tools(subtask.required_capabilities) subtask.agents = a2a_registry.find_agents(subtask.required_capabilities) subtask.skills = skill_loader.match(subtask.description) # 第三步：执行 results = {} for subtask in topological_sort(plan.subtasks): if subtask.can_parallel: results[subtask.id] = await execute_parallel(subtask) else: results[subtask.id] = await execute_serial(subtask, results) # 第四步：聚合 final_output = aggregator.merge(results, plan.output_format) return final_output

这段代码看起来简单，但每个函数里面都有很多细节。比如execute_serial要处理超时、重试、错误传播，aggregator.merge要处理格式冲突和字段缺失。我建议先把主流程跑通，再逐个完善这些细节。

5. 常见问题与排查技巧实录

5.1 Agent 执行中断与超时处理

Agent 执行中断是最常见的问题，原因大概有这么几类：工具调用超时、模型返回格式错误、上下文超长、依赖服务不可用。排查的时候我一般按这个顺序来：先看日志里最后一个成功的步骤是什么，再看中断时的错误信息，然后复现最小场景。

超时处理有个技巧：给每个子任务设置独立的超时时间，不要用全局超时。全局超时会导致一个慢任务拖垮整个流程。子任务超时后不要直接失败，先重试一次，重试还失败就降级处理，比如返回部分结果或者跳过这个子任务。

实操心得：我习惯在每个子任务执行前后都打日志，记录输入、输出、耗时、状态。出问题的时候直接看日志，比调试代码快得多。

5.2 MCP 工具调用失败的排查路径

MCP 工具调用失败通常有三个原因：Server 没启动、工具名不对、参数格式不对。排查步骤是：先用 MCP 客户端的手动调用功能测一下工具能不能通，再检查 Agent 传的参数是否符合工具的 input schema，最后看 Server 端的日志有没有报错。

有个隐蔽的坑是参数类型不匹配。比如工具要求整数，Agent 传了字符串，有些 MCP Server 会静默失败，不报错但也不返回结果。我的做法是在工具注册的时候加一层参数校验，类型不对直接拒绝并返回明确的错误信息。

5.3 A2A 通信中的常见异常

A2A 通信异常主要有三种：Agent 发现失败、任务提交失败、结果获取失败。发现失败一般是注册表的问题，检查 Agent Card 有没有正确注册、endpoint 能不能访问。任务提交失败通常是 schema 不匹配，检查输入格式是否符合 Agent Card 里的定义。结果获取失败可能是任务还在执行中，需要轮询或者用回调。

我遇到过一个比较诡异的问题：两个 Agent 互相发现不了，但单独测试都能通。后来发现是注册表的缓存没有及时刷新，新 Agent 上线后旧缓存还在。解决办法是把缓存过期时间调短，或者在 Agent 注册时主动通知注册表刷新。

5.4 Skills 加载与触发的典型故障

Skills 加载失败最常见的原因是触发条件写得太模糊或者太严格。太模糊会导致不该加载的时候加载了，浪费上下文；太严格会导致该加载的时候没加载，Agent 缺少必要知识。我的经验是触发条件里至少包含一个领域关键词和一个动作关键词，比如“财报”加“分析”。

另一个问题是 Skill 之间的冲突。两个 Skill 都声称能处理同一个任务，Agent 不知道该用哪个。解决办法是在 manifest 里加优先级字段，或者在描述里写清楚适用场景的差异。

6. 性能优化与扩展性考量

6.1 并发执行与资源竞争的处理

多 Agent 集群的并发能力直接决定了吞吐量。我一般会把无依赖的子任务并行执行，用 asyncio 的 gather 来管理。但并行不是越多越好，要考虑模型 API 的速率限制和本地资源的竞争。我的做法是设置一个并发上限，比如同时最多跑 5 个子任务，超出的排队等待。

资源竞争主要出现在文件写入和数据库操作上。两个子任务同时写同一个文件，后写的会覆盖先写的。解决办法是给每个子任务分配独立的临时目录，最后再合并。数据库操作可以用事务或者乐观锁来保证一致性。

6.2 上下文窗口的精细化管理

上下文窗口是稀缺资源，必须精细管理。我的策略是：系统提示词控制在 500 字以内，Skill 知识控制在 2000 字以内，工具描述按需加载，历史对话只保留最近 5 轮。中间结果不要全量保留，只保留摘要和关键字段。

还有个技巧是用外部存储来卸载上下文。比如检索到的文档不要直接塞进上下文，而是存到文件系统里，上下文里只放文件路径和摘要。Agent 需要详细内容的时候再通过 MCP 工具去读。这样上下文占用能降低 60% 以上。

6.3 集群水平扩展的实践建议

水平扩展的核心是让每个 Agent 无状态化。Agent 本身不存状态，状态全部放到外部存储里。这样你可以随时增加 Agent 实例来分担负载。MCP Server 也可以水平扩展，多个实例注册到同一个注册表，客户端轮询调用。

扩展的时候要注意注册表的性能。Agent 数量多了之后，注册表的查询会成为瓶颈。我建议用 Redis 做注册表，支持高性能的读写和过期淘汰。另外 Agent Card 的内容不要太大，控制在 2KB 以内，减少网络传输开销。

7. 我踩过的坑和最后分享的几个技巧

第一个坑是过度规划。刚开始用 DeepAgents 的时候，我恨不得把每个任务都拆成十层，结果规划本身消耗的 token 比执行还多。后来学乖了，简单任务不规划，中等任务拆两层，复杂任务拆三层，再复杂就说明任务本身需要重新定义。

第二个坑是 MCP Server 的进程管理。本地开发的时候 Server 是手动启动的，部署到服务器上忘了配自动重启，结果 Server 挂了整个集群就瘫了。后来用 systemd 或者 supervisor 来管理 MCP Server 进程，挂了自动拉起。

第三个坑是 A2A 的认证。内网环境我一开始没加认证，后来发现任何进程都能往注册表里注册 Agent，存在安全风险。现在至少加一个简单的 token 认证，Agent 注册和调用都要带 token。

最后分享一个小技巧：给每个 Agent 起一个有意义的名字，并且在日志里用这个名字而不是 ID。调试的时候看日志，research-agent比agent-7f3a直观太多了。另外建议在 Agent Card 里加一个owner字段，标明这个 Agent 是谁负责的，出问题的时候知道找谁。

这套架构我目前跑了大概三个月，支撑了十几个不同的任务场景，从文档分析到数据清洗到内容生成都有。最大的感受是前期搭架构的时间花得值，后面加新 Agent、新工具、新 Skill 都是即插即用，不用改核心代码。如果你也在做类似的事情，建议先把 MCP 和 Skills 跑通，这两个是基础，A2A 和 DeepAgents 可以后面再加。