企业官网建设流程全解析

先说明一下，这篇文章不是要把 MCP、A2A、Skills 逐个背一遍官方文档，而是想聊清楚一件事：当你的 Agent 项目从单个 Demo 走向真正要扛业务、扛并发、扛多角色协作的时候，这四个词为什么必须一起出现，它们分别补齐了哪块短板，以及我实际把它拼成一个集群时踩过的坑。

1. 单兵 Agent 撞墙之后：四个组件其实在补同一块短板

1.1 一个真实项目的失控现场

前段时间我帮团队把一个客服问答机器人升级成"能干活"的智能体——不光是聊天，还要查订单、改地址、算退款、写工单。第一个版本是典型的单体 Agent：一个大模型 + 一堆写死的 Python 函数 + 一段越来越长的 system prompt。

结果跑到第二周就开始失控了。工具函数接得越多，模型调用错的概率越高；prompt 里塞满了各种 API 的使用说明，超过上下文窗口后模型开始"选择性失忆"；更尴尬的是，当我想让"客服 Agent"和"售后 Agent"配合时，只能靠一个 Agent 在 prompt 里要求另一个 Agent 干活，两个大模型用自然语言互相喊话，谁先举手谁先答，错误像雪球一样滚。

那段时间我得出一个结论：单兵 Agent 的天花板不在模型智商，而在能力接入、任务协作、经验复用这三件事全是手工作坊式的。后来我把这套东西拆成四个标准件——DeepAgents 负责深度规划与编排，MCP 负责接入工具，A2A 负责 Agent 之间互相派活，Skills 负责沉淀"这活儿怎么干"的经验——才真正把集群跑稳。

1.2 三个协议不是平级关系，是三层抽屉

很多人把 MCP、A2A、Skills 放在一起说，容易误以为它们是三选一的关系。我在落地时的理解是，它们根本不在一个层次上：

而 DeepAgents 是一种架构取向——它不是一个协议，而是指 Agent 应该具备深度规划、长周期任务拆解、多工具组合调用的能力。MCP、A2A、Skills 都是为这种"深度"服务的底座。

我后来在项目里给客户画图时经常说：MCP 管的是"手"（能碰到哪些系统），A2A 管的是"人与人之间的协作规矩"（任务怎么接、怎么交），Skills 管的是"脑子里的经验"（遇到这类事先做什么后做什么）。三者都齐了，再配上 DeepAgents 的规划层，才叫可编排、可互通、可扩展的 Agent 集群。

2. MCP：给 Agent 装"万能工具插座"，拆解能力接入层

2.1 MCP 的三个角色：Host、Client、Server

MCP（Model Context Protocol）的核心思想特别朴素：与其让每个 Agent 项目都单独对接每个 API，不如定一套统一协议，让工具的提供方和消费方解耦。

协议里有三个角色。Host 就是你的 Agent 应用本身，比如 Claude Desktop、IDE 插件、你自研的 Agent 服务；Client 是 Host 内部负责协议通信的组件，它负责跟一个具体的 MCP Server 建立连接；Server 是暴露工具的一方，可以是一个本地进程，也可以是一个远程 HTTP 服务。

我刚开始学 MCP 时也犯过迷糊：Client 和 Server 到底谁是谁？后来用生活化比喻就通了——Server 是插座后面的电器，Client 是插头，Host 是墙上的电源面板。电器不需要知道你有多少个家电，它只要提供一个标准插口就行。

协议底层走的是 JSON-RPC 2.0，传输方式主要有两类：本地用 stdio（标准输入输出），远程用 HTTP/SSE。这意味着一个 MCP Server 可以同时被本地工具和线上集群使用，接口描述是一致的。

2.2 实操：一分钟接一个文件系统 MCP Server

很多入门教程喜欢拿官方 Filesystem Server 做演示，我也建议照这个跑一遍，它能帮你快速理解 MCP 的"工具发现—调用—返回结果"全过程。

在 Node 环境下执行：

npx -y @modelcontextprotocol/server-filesystem /tmp/agent-files

然后在你的 Host 配置文件里加一条：

{ "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp/agent-files"] } } }

启动 Agent 后，你可以直接让模型"列出 /tmp/agent-files 下所有文件，并统计大小"。模型会在内部通过 ListTools 发现文件系统工具，再通过 CallTool 实际执行。整个过程对用户是透明的，但你打开日志能看到两次关键请求：tools/list和tools/call。

这里有个新手很容易忽略的细节：MCP Server 暴露的不仅仅是"工具"（Tool），还有"资源"（Resource）和"提示词模板"（Prompt）。工具是让 Agent 执行动作的，资源是让 Agent 读取上下文数据的，提示词模板是给 Agent 提供固定话术的。大部分教程只会强调 Tool，但实际做集群时，Resource 的价值往往更大——比如把企业内部知识库的某张表通过 Resource 暴露，Agent 需要时再按需读取，就不用把整库塞进上下文。

2.3 浏览器自动化场景选型：browser-use MCP 与 Playwright MCP 怎么选

热词列表里有朋友在纠结browser use mcp和playwright mcp有什么区别。这个问题我在项目里真遇到过，两个我都接过，说下结论。

Playwright MCP 的核心定位是确定性自动化——它把 Playwright 的导航、点击、填表、断言能力包装成了 MCP 工具，适合本来就写惯了测试脚本的人，操作稳定，每一步都可复现，定位元素靠选择器，出错容易排查。

browser-use MCP 的核心定位是AI 原生浏览——它更强调让模型自己看页面结构、自己决定下一步点哪里，适合"让 Agent 像人一样浏览网页完成任务"的场景，比如给一个 URL 让它自己去搜集信息。

我的建议是：如果任务是"每周五去后台系统把报表下载下来"，用 Playwright MCP；如果任务是"帮我调研一下这十个竞品网站分别的定价策略"，用 browser-use MCP。当然也可以两个都装，让模型按任务性质自己选，前提是集群里要做好工具名的语义区分，避免模型选错。

2.4 接内部系统时的授权与鉴权：以 Codex 接 Figma 为例

MCP 在你本机跑通很容易，一旦要接企业内网或者 SaaS，问题就集中在授权上。社区里最常见的提问是"Codex 接入 Figma MCP 怎么授权"。

Figma 的 MCP Server 走的是 OAuth 流程。你需要在 Figma 开发者后台创建一个应用，拿到 Client ID 和 Client Secret，然后让用户在浏览器里完成授权，之后把拿到的 Access Token 交给 MCP Server。关键点在于 Token 的存放位置和刷新策略——千万不要把 Token 硬编码进 MCP 配置文件然后提交到 Git。我见过不止一个团队把 Figma Token 写进claude_desktop_config.json传到公司仓库，第二天就被安全团队约谈了。

更规范的做法是通过环境变量或密钥管理服务注入，比如本地用.env文件，生产环境用 Vault 或云厂商的 Secrets Manager。另外 OAuth 的 refresh token 有过期策略，MCP Server 要能处理 401 并触发重新授权，否则集群跑到半夜突然全量失败，排查起来很痛苦。

这个思路同样适用于业务系统集成。热词里提到ruoyi-vue-pro 合并 mcp 功能，本质上就是给后台管理系统加一个 MCP Server 层，把权限、订单、项目这些能力以标准协议暴露给内部 Agent。好处很明显：以后任何 Agent——不管是 Codex 还是自研的——都能通过同一套协议访问业务数据，而不是每个 Agent 单独写一套 REST 客户端。

3. A2A：让 Agent 之间"派工单"，而不是互相念 prompt

3.1 AgentCard 与任务生命周期

接完 MCP，Agent 有了"手"，但多个 Agent 之间怎么配合还是乱的。我最初的做法是在 prompt 里互相点名，结果两个大模型对话十轮之后就开始编造对方说过的话。后来引入 A2A（Agent-to-Agent）协议，才把协作从"聊天"变成了"派工单"。

A2A 协议里有个核心概念叫 AgentCard，是一个公开的 JSON 文件（通常叫agent-discovery.json），类似 Agent 的名片。名片上写清楚这个 Agent 叫什么、擅长什么、支持哪些技能、接受哪种任务格式。另一个 Agent 想找它帮忙之前，先拉取名片，看看活能不能接。

任务的生命周期则是标准化的，核心状态包括submitted（已提交）、working（执行中）、input-required（需要更多信息）、completed（完成）、failed（失败）。这其实是借鉴了工作流引擎里的任务状态机。

为什么这个设计很重要？因为在没有 A2A 时，Agent 之间传递的是一个"自然语言请求"，发起方完全不知道任务现在卡在哪一步，只能傻等或者超时。有了任务状态，编排层可以随时查询进度，还能在input-required时反向向发起方要补充材料。

我用一句话跟团队解释 A2A："这不是让两个机器人聊天，这是让两个系统互相提交工单、查询工单、关闭工单。" 一旦用这个视角看待，很多问题就清晰了。

3.2 三种编排模式：中心编排、点对点、黑板

A2A 只是通信协议，真正决定集群长什么样的，是编排模式。我实际中整理出三种，各有适用场景：

中心编排模式（Orchestrator-Worker）：一个主控 Agent 负责拆解任务，把子任务通过 A2A 派给不同的 Worker，再汇集结果。这是最推荐起步的模式，因为主控只有一个，任务流转链路清晰，出了问题容易回溯。缺点是主控 Agent 容易成为瓶颈。

点对点模式（Peer-to-Peer）：Agent 之间直接互相调用，适合流程固定的场景，比如"客服 Agent 发现需要改地址，直接调用售后 Agent"。优点是延迟低，缺点是协作关系会随着 Agent 数量增长变成一张蜘蛛网，难以维护。

黑板模式（Blackboard）：所有 Agent 往一个共享空间里写信息、读信息，通过发布订阅机制解耦。适合多个 Agent 协作解决一个复杂问题的场景，比如大家一起分析一份文档，各自往黑板上贴发现。问题是黑板的读写冲突和上下文污染需要额外设计。

我个人建议：第一版集群优先用中心编排，哪怕牺牲一点效率，也要先保证任务可追踪。

3.3 一个订单处理场景的 A2A 协作示例

举个我在客服集群里实际落地的例子。用户说"我上周买的耳机坏了想退货"，这个请求进来后，主控 Agent（DeepAgents 规划层）拆解出三个子任务：查订单、判断退货政策、生成退货运单。

主控通过 A2A 向订单 Agent 发起任务：

{ "kind": "task", "taskId": "task-order-001", "target": "order-agent", "input": { "userId": "u_1024", "message": "查询用户最近一笔耳机订单的状态与购买时间" } }

订单 Agent 返回working状态，查询完成后回复completed，附带 Artifact（结构化结果）：订单号、购买时间、商品 ID。然后主控把这些信息打包再派给售后 Agent 判断退货资格，A2A 允许任务在 Agent 间传递时携带上下文 Artifact，这比重新拼一段 prompt 要可靠得多——因为 Artifact 是结构化数据，不会因为模型"自由发挥"而变形。

这里有个细节：A2A 的任务消息里尽量传 ID 和结构化字段，而不是让上游 Agent 把一大段总结文本扔给下游。文本会在传递中丢失信息，还会让下游 Agent 上下文被污染。所有共享数据先落库，A2A 里只传引用和必要字段。

4. Skills：把一次成功的解题过程变成"肌肉记忆"

4.1 Skills 和 MCP、Prompt、Function 到底差在哪

Skills 是热词里讨论度很高、但最容易混淆的概念。先说清楚它和几个相近概念的区别。

MCP 提供的是"可被调用的工具"，比如"查天气""读文件"；Skills 提供的是"完成某类任务的完整打法"，比如"写一篇技术博客"——它可能内部会调用 MCP 工具，但核心是一套解题步骤、规则、示例和检查清单。

Prompt 是一次性的指令文本；Skills 是可持久化、可版本化、可分发的结构化模组。Function 是代码层面的封装；Skills 更接近"文档 + 脚本 + 模板"的组合包，既告诉模型怎么做，必要时也提供脚本去执行特定步骤。

我用做菜类比：MCP 是给你一把菜刀，Function 是告诉你"切土豆要用 45 度角"，而 Skills 是一份完整的菜谱——主料配料、步骤顺序、火候控制、成品标准，照着做就能出菜。

4.2 Skill 包的目录结构：SKILL.md 是核心

目前社区里比较通行的 Skill 结构（Anthropic 提出的 Agent Skills 格式是典型代表）长这样：

write-blog/ ├── SKILL.md ├── scripts/ │ └── generate-outline.py └── resources/ └── examples.md

SKILL.md 是入口文件，带一份 YAML frontmatter：

--- name: write-blog description: 根据给定主题撰写一篇结构清晰、可发布的技术博客。适合用户给出主题但没有明确大纲时使用。 ---

description 的价值被大多数人低估了。模型从 Skills 库里挑选技能时，主要靠 description 判断"当前任务是否匹配"。写得太宽泛（比如"写博客"），模型可能会用错场景；写得太窄（比如"写 Kubernetes 排障博客"），则能被匹配的机会很少。我的经验是 description 里写清楚触发条件、输入需要什么、输出结果长什么样。

SKILL.md 正文里我习惯固定四个小节：前置检查（哪些信息必须先确认）、执行步骤（按顺序编号）、质量检查（输出要达到什么标准）、常见错误（过去踩过的坑）。这四块写完之后，一个 Skill 基本就能从"随口提示"变成"可复现的流程"。

4.3 从一个"好用 Skill"到一套"Skills 市场"

开发 Skills 不难，难的是让它持续好用。我整理了几个评估维度：能否被稳定触发、完成质量是否明显高于裸写 prompt、是否需要频繁修改。社区里有很多"skills 推荐"、"codex 好用的 skills"的讨论，我筛选时一般先看两个点：SKILL.md 的 description 是否精准、quality check 部分是否具体。没有检查清单的 Skill 大多是包装成技能包的普通 prompt，价值有限。

Skills 的共享方式也有讲究。最轻量的是放到 Git 仓库里，团队拉下来后放进本地 skills 目录；进阶一点是搭一个内网 Skills 注册中心，通过 API 让集群里的 Agent 动态拉取；还有朋友在探索"IDE 使用 skills"的场景——比如在 JetBrains 系 IDE 里装 Plugin，让写代码的 Agent 直接复用调试、重构类的技能包。

热词里提到的codex skills、superpower skills、hermes agent obsidian本质都是这个思路的不同载体：把 Agent 在某类任务上的经验沉淀下来，反复使用。我自己的习惯是：每次项目里发现"这个任务让模型裸写会碰运气"时，就开一个 Git commit 去提炼成 Skill，积少成多之后，团队新成员接入集群时基本不用重新调 prompt，直接挂上对应技能包就能有六十分以上的表现。

比如有朋友在移动端安全分析场景整理了脱壳相关的技能包，也有人整理过用 Agent 写论文的技能包——不管哪个领域，底层方法是一样的：定义输入输出、固化步骤、写明检查项、持续迭代。

5. 编排一个集群的落地路径：从协议打通到任务跑通

5.1 分层设计：Router、Worker、Tool 各管一段

写到这里，四块积木都齐了，接下来是怎么拼。我建议的集群分层是三层：

编排层（Router/Supervisor）：一个 DeepAgents 主控实例，负责接收用户请求，拆解任务，通过 A2A 派发子任务，汇聚结果。主控不要干具体执行的事，它只做规划和跟踪，否则模型上下文很快会被塞满。

执行层（Worker）：多个专业化 Agent，每个挂载自己的 Skills 和专属 MCP Server。Worker 是无状态的，任务来了就干，干完就回到空闲状态。这样可以方便水平扩展。

工具层（MCP Servers）：把企业内部系统（订单、CRM、知识库、数据库）统一通过 MCP 暴露。Worker 在必要时通过 MCP 调用工具，不直接持有 SQL 连接或内部 API 的密钥。

这个分层的核心好处是：每一层都能独立扩缩容。客服量大就多开几个客服 Worker；新接一个业务系统只加一个 MCP Server，不用改动任何 Worker 代码。

5.2 任务路由与状态管理：别让状态烂在内存里

如果你的集群只有三五个 Agent，直接在代码里写 if-else 路由就够了。但 Agent 数量一多，任务路由就必须规则化。我在项目里的做法是引入一层轻量任务队列（Redis Streams 或 RabbitMQ），主控把任务消息写入队列，Worker 按自己的注册能力和 Skills 匹配度来消费。

任务消息的字段设计参考 A2A 的 Task 结构，但加两个关键字段：

{ "taskId": "task-order-001", "type": "order.query", "payload": { "orderId": "A1024" }, "requiredSkills": ["order-lookup"], "timeoutMs": 30000, "retryCount": 0 }

requiredSkills这个字段特别重要。Worker 在消费任务前可以先检查自己具备的技能集，如果技能不匹配就直接拒绝，避免模型硬着头皮做自己不擅长的事。配上一个简单的 Redis 来存任务状态，主控可以随时查询working、completed、failed。我在这个环节吃过亏——第一版把任务状态存在主控进程内存里，结果主控一重启，所有正在跑的任务人间蒸发。后来改成 Redis 持久化，主控才能做到无状态重启。

5.3 "AI Agent 怎么扛并发"：我的实际经验谈

这个热词戳中了很多人的焦虑。我的经验可以浓缩成三句话：

第一，Agent 自身不要扛并发，让队列扛。用户的请求先进入队列，Worker 一个个消费。用户感知到的可能是排队，但至少请求不会丢。想提升吞吐，就增加 Worker 实例，而不是让单个 Agent 一边推理一边处理十个任务——大模型推理本来就不是免费资源，硬扛并发只会让单任务延迟飙升。

第二，给模型供应商做好限流和配额控制。一个 Worker 挂了也可能因为 one API 的并发上限被限流。我的做法是每个 Worker 配一个令牌桶，每秒只允许发固定数量的模型请求；再在网关层做全局配额，防止某个疯狂任务把整个集群的 token 预算烧光。

第三，保持无状态。集群里的 Worker 不保存任何会话数据。用户聊天记录放 Redis，任务中间结果放对象存储，Worker 随时可以重启。这是我能做到比较稳妥扩展的大前提。

有一个反直觉的结论：加了队列之后，单任务的平均延迟反而更稳定了。原因是模型请求不再争抢，Worker 可以匀速处理，不会出现"高峰期某个任务卡了两分钟没人管"的情况。

6. 踩坑清单与冷启动建议

6.1 协议层踩坑三连：超时、状态丢失、Skill 误触发

接 MCP 最常见的坑是Server 假死。本地 stdio 模式还好，远程 MCP Server 一旦部署在高延迟网络后，默认超时设置往往不够。我实际遇到过一个 Server 在忙碌时三秒才返回，而 Host 默认超时两秒，导致 Agent 反复失败重试。解决办法是显式配置 MCP 客户端的超时和重试参数，并且在 Server 侧实现探活接口。

A2A 的坑在于任务状态和消息可能丢失。如果使用中心编排，主控挂掉会导致所有working状态的任务变孤儿。我的建议是主控启动时扫描数据库里所有working任务，超过某个时间戳的自动标记为failed并重新入队。宁可重复执行，不要静默消失。

Skill 的坑是误触发。一个 description 写得太宽泛的 Skill 会被模型选中去处理不匹配的任务，产出一个四不像结果。排查这类问题要盯住 Agent 的决策日志——你能看到模型在调用 Skill 时给出的 reason，然后据此收紧 description。记住：Skill 是给模型看的接口，它的文案质量直接影响行为质量。

6.2 权限、安全与可观测性：集群越大越要管住"手"

Agent 集群的安全问题比传统 API 网关更棘手，因为模型的调用路径是动态的，不是提前写死的。一个 MCP Server 如果开放了"执行 SQL"的能力，模型可能在用户一句"把最近感冒订单删掉"的诱导下执行危险操作。

我现在的基线：MCP 工具按最小权限暴露，写操作一律走审计。比如数据库 MCP 默认只读，需要写操作时必须经过一个"人工授权"步骤，或者在一个单独的、挂了审批回调的 MCP Server 上提供。A2A 层面也要做 Agent 身份标识——每个 Worker 有一个唯一 ID，主控只接受来自信任 Agent 列表的任务请求，防止有人往集群里塞了一个恶意 Agent 到处派活。

安全之外，可观测性经常被忽视。Agent 的失败很难用传统 APM 排查，因为一个任务可能跨了三个 Agent、十几次工具调用。我建议从第一天就记录四类日志：模型调用的输入输出、工具调用记录、A2A 任务流转记录、Skill 触发记录。这些日志除了排障，还能用来做集群的行为分析，比如哪个 Skill 经常被误触发、哪个 Worker 的成功率偏低。没有这些数据，集群就是黑盒，优化全靠猜。

6.3 冷启动建议：从一个窄场景跑闭环

最后说点实在的。很多团队一上来就想搭一个"全知全能的多智能体平台"，我的建议正好相反：先选一个高频的窄场景，用最小闭环跑通 MCP + A2A + Skills 三个链路。

比如先做"客服订单查询 + 退换货引导"这一件事：一个主控 Agent，一个订单 Worker，一个售后 Worker，挂两个 MCP Server，沉淀两个 Skill。跑顺之后，再加工具、加 Worker、加技能包。这样做的好处是，每个新增组件带来的复杂度和风险都是可控的，而且集群的骨架（队列、状态存储、日志链路）会在第一个场景里被打牢。

从我的实际操作体验来看，这套架构真正变"好用"，是在Skills积累到十几个、MCP接了七八个系统之后——那时你会发现新接入一个业务 Agent，不需要重写任何基础代码，注册一个 Worker、挂上对应 Skill、指向对应 MCP Server，半天就能上线。这才是"可编排、可互通、可扩展"这三个词落到地面的时刻。