企业官网建设流程全解析

前阵子给团队做内部技术分享，我把命题定成了“DeepAgents+MCP+A2A+Skills 超级多智能体”，目标很直接：用这四套东西搭一个能真正干活、能互相协作、能不断往里面加新能力的 Agent 集群。折腾了一个多月，踩了不少坑，也把整套架构从 demo 推到了能稳定跑业务的状态。这篇就把我的设计思路、实操记录和排查经验完整捋一遍。

先说结论：单 Agent 的困境不是模型不够强，而是工程结构太散。工具接入每家一套 SDK，换个 Agent 就得重写一遍；多个 Agent 放一起各干各的，没有统一的协作语言；想给 Agent 加一个新能力，要么改代码要么靠提示词硬塞，维护成本越来越高。这套组合拳的意义在于——MCP 管工具接入，A2A 管智能体互联，Skills 管知识沉淀，DeepAgents 管全局编排，四层各司其职，组合起来才能形成真正可编排、可互通、可扩展的下一代 Agent 集群。

这篇文章不是纯概念科普，而是从零搭建的完整实操记录，适合正在做 Agent 应用的工程师、准备上多智能体平台的架构师，以及想搞清楚这几个协议到底怎么配合的学习者。

1. 为什么把四个技术栈叠在一起用

1.1 拆解“可编排、可互通、可扩展”三个硬指标

我在项目里反复被三个问题折磨：第一，Agent 的能力边界太死，每加一个工具就要改一遍 Agent 的调用逻辑；第二，多个 Agent 之间没有标准对话方式，A 调 B 基本靠硬编码接口；第三，沉淀下来的经验、流程、提示词散落在各处，换个环境就失效。

“可编排”指的是调度层能像搭积木一样把多个 Agent 串成一条流水线，A 做完一步自动交给 B；“可互通”指的是不同团队、不同技术栈实现的 Agent 能用同一种协议对话；“可扩展”指的是加一个新工具、新技能、新 Agent，不需要动老代码。

MCP 解决的是 Agent 和工具的插拔问题，A2A 解决的是 Agent 和 Agent 的对话问题，Skills 解决的是知识复用问题，DeepAgents 解决的是前面三者的组织和调度问题。四者叠加，正好覆盖了多智能体系统从底层到顶层的所有需求。

1.2 四层架构的分工与协作关系

我用一张表格把这四个技术栈的定位先讲清楚，方便后续理解：

我实际组网的时候，顺序是反着搭的：先接 MCP 让 Agent 有手，再装 Skills 让 Agent 有脑，然后通 A2A 让 Agent 能彼此说话，最后用 DeepAgents 做编排把这些串起来。

1.3 和“全栈自研调度框架”相比，这套方案赢在哪

说实话，我也自己写过 Agent 调度框架，核心就是一张函数注册表加一个消息队列，搞定过一阵子。但问题很快就暴露了：团队里每加一个 Agent 就要约好一套消息格式，每个工具都要写一遍适配器，跨项目复用基本为零。

采用 MCP、A2A 这类开放标准后，最大的收益是生态复用。比如官方市场里已经有不少现成的 MCP Server，数据库的、浏览器的、设计工具的都有，接上就能用；A2A 让不同框架实现的 Agent 可以互相发现和委托任务；Skills 目录下沉淀了大量现成的技能包，不用自己从头写提示词。

这不光是省代码的问题，而是把团队从“每做一个 Agent 都要做一遍全栈”的泥潭里拉出来，让注意力回到业务本身。

2. 先把四个组件逐个吃透：它们到底干了什么

2.1 MCP 不是又一个协议，它是 Agent 的工具插槽

MCP 全称是 Model Context Protocol，一个开放标准，定义了大模型应用如何发现和调用外部工具。我第一次听到时也觉得索然无味，直到自己接了一个 PostgreSQL 数据源后才发现，这套协议把“Agent 每次接入新工具”这件事从改代码变成了改配置。

MCP 的架构是 Host、Client、Server 三层。Host 是 Agent 本身，Client 负责和 Server 建立连接，Server 负责暴露工具。核心原语有三类：Tools 是 Agent 可以执行的函数；Resources 是只读的数据资源；Prompts 是预定义的提示词模板。

对普通开发者来说，最高频的操作是：跑一个 MCP Server，把连接信息配进 Agent 的客户端配置里，然后 Agent 就能像本地函数一样调用远程工具。我在项目里接过的有 PostgreSQL 数据库、GitHub、Figma、浏览器自动化工具，全部走的同一套机制，这就是 MCP 的魅力。类比一下，它就是工具侧的 USB-C，一个接口通吃所有外设。

2.2 Skills 是把“怎么做”教给 Agent 的最小知识单元

Skills 是另一维度的事。MCP 管的是“Agent 能用什么工具”，Skills 管的是“Agent 会用什么方法做事”。它本质上是把一段可复用的方法论——包括提示词指令、模板、脚本——打包成一个结构化文件夹，里面通常包含一个 SKILL.md 描述文件、若干参考资源和可选脚本。

我用一个实际例子说明：写论文技能，它不只是给 Agent 一个“帮我写论文”的提示，而是一整套流程——先让你确认主题、再产出大纲、逐章撰写、统一润色、校验引用格式。每个环节的指令、模板、注意事项都写在 SKILL.md 里。Agent 加载这个技能后，就相当于经过了一次完整的岗位培训。

Skills 和 MCP 的边界值得强调：MCP 暴露的是“工具函数”，Skills 暴露的是“做事的流程”。两者经常搭配使用，比如一个 Skills 里负责流程编排，其中某一步调用 MCP 工具去查询数据库。

2.3 A2A 让不同的 Agent 说同一种语言

A2A 全称是 Agent2Agent，它填补的空白是智能体之间的互联。MCP 解决的是单体 Agent 内部零件互通的问题，A2A 解决的是多个 Agent 之间的业务协作问题。

A2A 基于 JSON-RPC 2.0，核心概念是 Agent Card——每个 Agent 发布自己的能力描述，其他 Agent 通过 Agent Card 发现它能做什么，然后发起任务委托。整个流程包括能力发现、任务创建、任务协商、状态更新、结果交付。

我自己的理解是：MCP 是 Agent 的“手”，A2A 是 Agent 之间的“商务谈判协议”。有了 A2A，一个用 Python 写的分析 Agent 可以顺畅地委托任务给一个用 TypeScript 写的前端生成 Agent，两边不需要共享任何代码。

2.4 DeepAgents 负责把前面三样编排成集群

DeepAgents 是我的编排核心。所谓编排，就是把“多个 Agent、多个工具、多个技能”组织成一条可执行、可监控、可恢复的工作流。

它的工作方式类似一个业务流程引擎：定义节点、连接依赖、设定输入输出、监控运行状态。每个节点可以是一个 Agent、一个 MCP 工具调用、一个 Skills 执行单元；节点之间有先后依赖和数据流向；运行过程中记录日志、上报状态、支持失败重试。

之前我给团队演示过一个案例：一个供应链分析任务，拆成了数据采集 Agent、库存分析 Agent、报告生成 Agent 三个节点，前一个节点的输出自动成为后一个节点的输入，全程没有任何人工干预。这就是 DeepAgents 的编排价值。

3. 实操记录：从零搭建四层 Agent 集群

3.1 先搭 MCP 接入层：5 分钟跑起来一个 PostgreSQL 数据服务

MCP 是这套架构的地基，先落地它。以 Python 环境为例，最常用的是fastmcp这个库，它帮你封装了协议细节，可以专注写工具函数。

下面是我项目里一个最小可用的 MCP Server，它的作用是查数据库：

from fastmcp import FastMCP import psycopg2 mcp = FastMCP("postgres-service") @mcp.tool() def query_stock(product_id: str, days: int = 30) -> str: """查询指定商品的近 N 天库存数据""" conn = psycopg2.connect( host="localhost", port=5432, dbname="business", user="reader", password="xxx" ) cur = conn.cursor() cur.execute( "SELECT date, stock_qty FROM stock_log WHERE product_id=%s ORDER BY date DESC LIMIT %s", (product_id, days) ) rows = cur.fetchall() conn.close() return "\n".join([f"{r[0]}:{r[1]}" for r in rows]) if __name__ == "__main__": mcp.run(transport="streamable-http")

这个服务启动后，监听一个 HTTP 端口，暴露一个query_stock工具。关键点有两个：一是@mcp.tool()装饰器自动帮你做了协议包装；二是每个工具函数必须有清晰的 docstring，这会被用于生成给 Agent 看的工具描述，直接影响 Agent 是否在正确场景下调用它。

然后配置客户端。比如在 Claude Desktop 或 Cursor 中，需要往配置文件里加 MCP Server 信息：

{ "mcpServers": { "postgres-service": { "command": "python", "args": ["path/to/mcp_server.py"], "env": {} } } }

配置完成后重启客户端，在对话里问“查一下商品 P1001 最近 7 天的库存”，Agent 会自动匹配到query_stock工具并返回结果。这一步走通后，所有的外部服务统一接入方式就确定了。

3.2 再装 Skills：让 Agent 学会搜索和读数据库

Skills 的安装比想象中简单，本质是把一个技能文件夹放到 Agent 能扫描到的目录，然后在对话里用@技能名触发。下面是一个搜索技能的目录结构：

skills/ web-research/ SKILL.md reference/ search_tips.md

其中 SKILL.md 的关键结构是这样的：

--- name: web-research description: 使用搜索工具进行多轮网络调研并产出综述报告 --- ## 执行流程 1. 拆解用户问题，提取 3-5 个搜索关键词 2. 使用 browser-use MCP 工具执行搜索 3. 对前 10 条结果逐条阅读并记录核心信息 4. 交叉验证信息，标注来源 5. 输出带引用来源的综述 ## 注意事项 - 不要只依赖第一个搜索页结果 - 优先采信官方来源与一手数据 - 若搜索失败，必须更换关键词重试

我个人的经验是：一个好 Skills 的灵魂是流程清晰、边界明确、可验证。描述里不要写空话，比如“高效地进行搜索”，而要把每一步具体动作写出来，Agent 才能稳定复现。

安装后直接在对话中输入“使用 web-research 技能，调研 MCP 和 A2A 在工业界的落地现状”，Agent 就会自动进入预设的调研流程，而不是凭感觉自由发挥。这种稳定性的提升非常明显，尤其是面对重复性任务。

3.3 打通 A2A：让两个异构 Agent 互相派活

A2A 的配置稍微复杂，核心是企业级标准。我推荐用官方 SDK 快速搭建两个实验 Agent，验证互通后再并入业务。

第一个 Agent 定义一个 Agent Card（JSON），声明自己能做什么：

{ "name": "data-analysis-agent", "description": "负责数据清洗、统计分析和可视化", "skills": ["data_processing", "statistics"], "endpoints": [ { "path": "https://myagent.example.com/a2a", "protocol": "a2a", "version": "1.0" } ] }

第二个 Agent 运行时，通过 A2A 协议向第一个 Agent 发起任务请求。核心请求格式如下：

{ "jsonrpc": "2.0", "id": 1, "method": "tasks/send", "params": { "id": "task-001", "message": { "role": "user", "parts": [ { "text": "请分析这份 CSV 数据的趋势，并生成一张趋势图" } ] } } }

第一个 Agent 收到后，返回一个任务状态，等执行完成后通过tasks/get拉取最终结果。整个过程就是 A2A 的最小闭环。

我踩过的坑是：Agent Card 里的name和description一定要写清楚。因为另一个 Agent 会发现你的 Agent Card，并根据描述判断是否适合委托任务。描述含糊，对方 Agent 就不会把任务派给你。这就像简历写不好，面试机会就没有。

3.4 DeepAgents 编排层：把团队协作变成代码

DeepAgents 是最后一步，把 MCP、Skills、A2A 全部串起来的编排层。我用一段伪代码说明它的工作方式，展示一个多 Agent 协作流程：

pipeline = deepagents.Pipeline(name="供应链异常分析流程") pipeline.add_node( name="采集库存数据", action="mcp:postgres-service#query_stock", params={"product_id": "P1001", "days": 30} ) pipeline.add_node( name="调用数据分析Agent", action="a2a:data-analysis-agent#send_task", params={"message": "分析上方库存数据，找出异常波动点"} ) pipeline.add_node( name="生成预警报告", action="skill:report-generation", depends_on=["采集库存数据", "调用数据分析Agent"] ) pipeline.run()

三个节点的依赖关系很清晰：前两个节点完成后，第三个节点才启动。实际运行中，DeepAgents 会记录每一步的输入输出、耗时、状态，失败时可以指定重试策略和降级方案。

我给团队推荐这套编排方式的核心理由是：工作流定义和业务代码分离。调整流程只需要改管线配置，不需要改 Agent 内部逻辑，非常适合快速迭代。

4. 真实项目踩坑实录：认证、上下文、兼容性与生产落地

4.1 认证授权是第一个拦路虎：Figma、蓝湖类 MCP 的 token 问题

很多 MCP Server 需要调用第三方 API，而这些 API 几乎都要求 OAuth 或 token 认证。比如前阵子接入 Figma 的 MCP，我的 Codex 客户端怎么都找不到 MCP，后来排查才发现根本不是配置问题——是认证 token 过期了。

MCP Server 的认证信息一般通过两种方式传递：配置 JSON 里的env字段注入环境变量，或写在 MCP Server 的启动脚本里。建议把所有敏感凭证放进环境变量，不要硬编码在源码里。

还有一点：Codex 等客户端的 MCP 配置更新后不一定热加载，经常要重启会话才能识别新增的 MCP Server。“找不到 MCP”的时候，优先查三件事——配置文件路径是否正确、MCP Server 进程是否真的起来了、认证信息是否有效。

4.2 上下文窗口与工具幻觉：为什么 Agent 会乱调用

MCP 工具接入多了以后，你会发现一个新的问题：Agent 面对十几个工具，分析和选择的时间明显变长，偶尔还会选错工具，也就是工具幻觉。一次它把查询库存的工具用来查订单状态，结果可想而知。

原因之一是工具的 description 写得太模糊，模型无法区分边界。我给团队的硬性要求是：每个工具函数必须有动词开头的描述、明确的输入参数说明、以及典型的调用场景提示。

原因之二是上下文窗口有限。MCP Server 返回了大量数据，但上下文装不下，Agent 就会选择性忽略或干脆编造。解决办法是在 MCP Server 里做数据聚合和采样，只返回精简结果。比如上面那个库存查询，我在 SQL 里就做了LIMIT控制，防止一次性拉回几千行数据。

4.3 选型对比：browser-use MCP 和 Playwright MCP 怎么选、Skills 去哪找

问过我最多的问题是“browser-use MCP 和 Playwright MCP 有什么区别”。两者都是浏览器自动化工具，但设计思路不同——browser-use MCP 更偏向 AI 驱动的自动化，适合让 Agent 自主探索网页，但执行效率和稳定性相对低；Playwright MCP 更像传统的自动化测试工具，精确控制浏览器行为和断言，执行更稳，但需要你明确定义每一步操作。

我现在的经验是：需要让 Agent “看懂”网页并自主决策时选 browser-use MCP；需要固定流程的网页操作时选 Playwright MCP。如果追求生产稳定性，后者更靠谱。

关于 Skills 去哪找：官方市场和 GitHub 上有不少高质量技能包，包括论文写作、网页调研、数据分析等。注意选择 star 高、更新活跃的项目，同时检查 SKILL.md 的流程设计是否清晰。有些技能包其实就是把一堆提示词塞进去，质量很低，对 Agent 的能力提升很有限。我推荐的筛选标准是：看它有没有把任务拆成明确的步骤，有没有定义输入输出格式，有没有异常处理机制。

4.4 生产落地：从 demo 到稳定运行的几个关键节点

最后聊一下把整套集群从实验环境推向生产会遇到的问题。稳定性是第一位的，MCP Server 进程可能因为内存泄漏挂掉、网络抖动导致 A2A 消息丢失、Skills 执行超时——这些问题一定要在架构上预留处理空间。我的做法是：用supervisor守护 MCP Server 进程，设置自动重启；A2A 消息增加超时重试机制；Skills 执行控制在合理时间窗口内。

监控方面，因为涉及多个节点，日志分散在各处，排查问题非常痛苦。我搭了一套集中日志采集，把编排层、每个 Agent、每个 MCP Server 的运行日志统一打到 ELK，再配置关键指标告警。实战下来，这个投入的收益远超预期。

企业系统集成这块，我们尝试把一个开源后台管理框架和 MCP 结合，做法是把 MCP Server 作为独立服务部署，然后在后台系统的配置中心加一个 MCP 配置项——只要实现了标准协议，两边不需要定制开发就能打通。这个思路已经在内部跑通了，审批流、报表、数据看板都能通过 MCP 一步接入。

最后再分享一个我在备课过程中悟出来的经验：这些技术栈本身不难，真正的难点在边界把控——什么时候用 MCP、什么时候用 Skills、什么时候用 A2A、什么时候用编排层，边界清晰了，架构才不会乱。我见过很多团队把 Skills 当成 MCP 用，或者用 A2A 做内部进程通信，到最后就是一团乱麻。判断标准其实很简单：工具调用走 MCP，方法复用走 Skills，智能体协作走 A2A，流程组织走 DeepAgents。把这句口诀刻在脑子里，你们的集群架构大概率不会跑偏。