企业官网建设流程全解析

在慕课上把《DeepAgents+MCP+A2A+Skills 超级多智能体》这套内容反复打磨了大半年之后，我终于敢说一句结论：多 Agent 集群不是把 Agent 数量堆上去，而是老老实实把编排、互通、扩展这三件事做到位。整个项目最终沉淀下来就五个关键词——DeepAgents、MCP、A2A、Skills、Agent——分别回答“谁来统筹”“怎么连工具”“Agent 之间怎么对话”“每个 Agent 会什么”“集群最终长什么样”。如果你也在做 AI Agent 开发，或者正在被“Agent 单打独斗、复杂任务老崩”折腾得头疼，这篇文章值得你花十分钟看完，里面有我踩过的坑、画过的架构图、以及可以直接抄走的配置。

先说背景。这半年我带着一个三人小团队，给两条业务线做了 Agent 化改造：一条是内部知识库问答与文档生成，另一条是长流程的项目需求拆解加测试用例生成。两个场景刚开始都用“单 Agent + 一堆工具”的模式，结果都不太理想。后来我们切换到 DeepAgents 做编排层，用 MCP 统一接工具，用 A2A 打通 Agent 之间的通信，再把高频任务沉淀成 Skills，整套集群才算真正“立住”。下面我把整个构建过程和关键取舍拆开讲。

1. 从单 Agent 到多 Agent：先搞清楚问题出在哪

1.1 我最初犯的错：把一个 Agent 当成“万能接线板”

第一次做 Agent 项目时，我的直觉很简单：既然要处理复杂任务，那就把一个 Agent 能调用的东西全部塞给它。于是我给同一个 Agent 挂了 8 个 MCP Server，涵盖数据库查询、文件读写、网页抓取、表格处理、邮件发送、消息通知、代码执行和知识库检索。结果上线第一天就翻车了。

翻车现象很有代表性：Agent 频繁调用错误的工具，比如用户问“上个月的销售数据在哪里”，它先去调了邮件发送接口；让它“读一下项目目录里的配置文件”，它连续两次调用了网页抓取工具去访问一个不存在的 URL。排查下来，问题根本不在模型智商，而在上下文结构：8 个工具的描述和参数定义占据了大量上下文空间，模型在做工具选择时被无关干扰项带偏，平均每次任务有 2~3 次无效调用，响应时间拉长，出错率也跟着涨。

1.2 多个 Agent 实例不等于多智能体

后来我试着把任务拆给多个 Agent：文件读取 Agent、数据查询 Agent、文档生成 Agent，每个 Agent 管一件事。但很快发现，它们各干各的，之间没有通信机制，没有公共上下文，没有任务流转。我所谓“多 Agent”，本质上只是同一个模型换了不同的 system prompt 在跑，和“多智能体协作”完全不是一回事。

真正的多智能体集群，至少需要满足三个条件：Agent 之间能互相发现能力、能发起任务并接收结果、能共享一套安全边界和可观测链路。这三个条件单靠“多开几个 Agent”是满足不了的，必须引入协议和编排层。这也是我把 DeepAgents 作为整个项目基座的原因。

DeepAgents 在我这里不是某个具体商业产品，而是一套自建的编排基础设施：它负责 Agent 注册、任务拆解、状态跟踪、路由分发和结果汇总。配合 MCP 解决 Agent 与外部工具的关系，配合 A2A 解决 Agent 与 Agent 的关系，配合 Skills 解决单个 Agent “会做什么、做到什么标准”的问题。一句话总结：DeepAgents 是项目经理，MCP 是工具箱里的统一接口，A2A 是团队成员之间的沟通协议，Skills 是每个人手上的标准作业手册。

1.3 混乱时代更需要分清“harness 和 agent 的区别”

很多开发者会问：编排层和 Agent 本身到底什么关系？我在教学里经常用“harness 和 agent 的区别”来解释。Agent 是干活的人，它具备模型推理能力、技能列表和工具访问权限；harness 是那个把 Agent 套起来的外壳，负责接收外部请求、管理生命周期、注入上下文、收集日志。没有 harness，Agent 就是一个裸模型；没有 Agent，harness 就是一个空壳调度器。

DeepAgents 这类编排框架就属于 harness 的范畴，但它比普通 harness 更进一步，专门为“多 Agent”设计：它要把任务拆成子任务、把子任务分给不同 Agent、处理子任务之间的依赖关系、最后把结果拼回一个完整答复。这个“拆、分、追、拼”的过程，就是编排。搞清楚这层关系，后面看任何框架都不晕。

2. MCP、A2A、Skills 的职责边界：一张表理清架构

2.1 MCP：给 Agent 接工具的“标准化接口”

MCP 全称是 Model Context Protocol，从 2024 年底开始由一家主流 AI 实验室开源，并在后续捐给了 Linux 基金会。它的核心思路非常朴素：与其让每个 Agent 为每个工具写一套私有适配器，不如给所有工具一个统一协议层。

在 MCP 架构里有三个角色：MCP Host 是 Agent 本身，MCP Client 是宿主内置的连接器，MCP Server 是工具侧的独立进程。工具开发者只需要实现一个 MCP Server，任何支持 MCP 的 Agent 都能直接调用。这个思路很像 USB-C 接口：以前每个设备都要专属充电线，现在大家用同一个口子，插上就能用。

我目前这一侧跑过的 MCP Server 包括数据库查询、文件系统操作、网页内容抓取、Figma 和蓝湖设计稿信息读取、代码仓库检索、以及一些内部系统的数据接口。最直观的收益是：新增一个工具，不需要改 Agent 代码，只要多启动一个 MCP Server，并在编排配置里声明引用即可。

2.2 A2A：解决 Agent 与 Agent 之间的“对话协议”

如果说 MCP 是 Agent 伸向工具世界的手，那 A2A 就是 Agent 彼此之间伸出的手。A2A（Agent2Agent）协议在 2025 年由 Google 提出，后来同样进入 Linux 基金会托管，目的是让不同团队、不同框架开发的 Agent 能够互相发现能力、发起任务、流转消息。

A2A 的关键概念有三个：Agent Card 是 Agent 对外发布的“名片”，里面写了它叫什么、能干什么、有哪些能力；Task 是任务载体，一个 Agent 可以向另一个 Agent 发起 Task，并跟踪状态；Message 是任务执行中的信息流，可以是文本、结构化数据或中间结果。有了这套东西，我的需求分析 Agent 可以直接向测试用例生成 Agent 发起“请基于这份需求列表生成测试要点”的 Task，而不需要我在代码里写死两者之间的私有调用逻辑。

这里要特别澄清一个误区：A2A 不是替代 MCP。MCP 是 Agent 与工具之间的协议，A2A 是 Agent 与 Agent 之间的协议。一个 Agent 既通过 MCP 调数据库，也通过 A2A 问另一个 Agent 要数据，两者天然互补。

2.3 Skills：把“会干什么、怎么干”变成可复用资产

Skills 是三者里最容易被忽视、但长期价值最高的一个。我的定义很简单：Skills 是一段高度结构化的指令包，它告诉 Agent 在什么场景下、按照什么步骤、产出什么格式的结果。它不是代码函数，而是“标准作业程序”。

举个例子，我给需求分析 Agent 写过一个 Skill：输入是一段零散需求文本，输出是需求列表、优先级、风险点和验收标准。这个 Skill 包含触发条件、输入字段说明、执行流程、输出格式要求和两个示例。有了它，Agent 不需要每次都从零推理“怎么整理需求”，而是直接按照这套流程走，输出稳定，质量方差小。

2.4 三者协同的分工表

这张表对我项目组的价值特别大。每次开技术方案评审，有人提出要给 Agent 加能力时，我们第一件事就是问：“这是工具接入问题，走 MCP；是跨 Agent 协作问题，走 A2A；是单个 Agent 的执行质量问题，走 Skills；是多个环节的串联问题，走 DeepAgents 编排。”问题一归类，方案自然就出来了。

3. 编排层设计：DeepAgents 怎么把 Agent 串起来

3.1 三种主流编排方式，我为什么选混合式

多 Agent 编排没有银弹，主流做法大致分三种：集中式编排、层级式编排、去中心化协商。

集中式编排有一个中央调度器，所有任务都由它拆解分派，简单、可控，但调度器容易变成瓶颈；层级式编排把调度器分成多层，顶层负责战略，中间层负责任务分解，底层负责具体执行，适合业务复杂的中大型集群；去中心化协商则是 Agent 之间直接谈判，灵活性强，但结果不可控，调试难度大。

我实际采用的是“集中式入口 + 层级式执行”的混合模式：对外只有一个统一入口，由 DeepAgents 编排器接收所有任务，内部则分成 Supervisor、Specialist、Worker 三层角色。Supervisor 负责理解任务意图，Specialist 负责把任务拆成领域子任务，Worker 负责调用具体 MCP 工具并产出最终内容。这样既有集中式的好控制，又有层级式的清晰边界。

3.2 我的三级角色模型

第一个角色是 Supervisor，也就是总指挥。它接收用户请求后，先做意图判断：这是需求分析类任务、内容生成类任务，还是执行查询类任务。第二个角色是 Specialist，负责垂直领域方案。比如需求分析专家、测试设计专家、文档撰写专家。第三个角色是 Worker，负责最细粒度的工具操作，比如“查询订单数据”“读取某份文件”“生成一段 Markdown 表格”。

角色之间通过 A2A 通信。Supervisor 向 Specialist 下发 Task，Specialist 在需要数据时向 Worker 发起子任务，Worker 通过 MCP 工具拿数据后原路返回。所有消息都带任务 ID，方便追踪。

3.3 一个能跑的编排配置长什么样

我习惯用一份 YAML 来声明集群拓扑：

orchestrator: name: deepagents-main queue_size: 100 agents: - name: supervisor model: gpt-4o skills: [intent_analysis, task_planning] mcp_servers: [] a2a_registered: true - name: requirement_analyst model: gpt-4o skills: [requirement_analysis, risk_assessment, acceptance_criteria] mcp_servers: [file_reader, db_query] a2a_registered: true - name: test_case_generator model: gpt-4o skills: [test_design, boundary_analysis, traceability_check] mcp_servers: [file_writer, project_indexer] a2a_registered: true - name: data_worker model: gpt-4o-mini skills: [data_query, report_formatting] mcp_servers: [sales_db, order_db] a2a_registered: false

这里的关键设计是：每个 Agent 只挂它真正需要的 Skills 和 MCP Server。Supervisor 不需要直接连数据库，所以它的 MCP Server 列表为空；数据 Worker 不负责生成复杂方案，所以用了更便宜的模型。“模型分级、权限最小化”是我从踩坑里总结出来的第一条工程原则。

编排器的调度核心，我简化成这么一段逻辑：

class DeepAgentsOrchestrator: def __init__(self): self.task_queue = asyncio.Queue() self.agents = {} async def submit(self, request): task_id = generate_task_id(request) await self.task_queue.put({"task_id": task_id, "payload": request}) return task_id async def worker_loop(self): while True: task = await self.task_queue.get() plan = await self.supervisor.plan(task["payload"]) for step in plan.steps: specialist = self.agents[step.target_agent] result = await specialist.execute(step, task["task_id"]) self.record_result(task["task_id"], step.step_id, result) await self.finalize(task["task_id"])

当然，生产环境比这个复杂得多，但核心思路就是三步：入口统一收单，编排层拆任务，执行层按角色流转。任务状态全部落库，这样任何一步失败了，都能定位到具体 Agent 和具体环节。

3.4 任务状态与上下文隔离

多 Agent 协作很容易出现“上下文污染”：A Agent 处理完子任务后，把不相关的中间信息传给了 B Agent，导致 B 的回答偏离主题。我的解决办法是分层上下文：全局上下文只保留用户原始诉求和最终约束；每个子任务有独立上下文，只包含执行所需的数据；Agent 之间的消息全部以结构化字段传递，而不是整段对话历史。

状态管理用任务状态机：pending（排队中）-> planning（正在拆解）-> running（执行中）-> waiting_subagent（等待子 Agent 返回）-> completed（完成）或 failed（失败）。每次状态变化都写日志。这套机制让我后来做并发和排障时轻松了很多。

4. 互通层落地：A2A 的 Agent Card、Task 流转与安全校验

4.1 想把 Agent 暴露成 A2A Agent Card，关键在能力描述

最近很多人在搜“如何把 Agent 暴露出 A2A Agent Card”，我直接说说落地细节。A2A 的起点是每个 Agent 发布一个 Agent Card，它是一个 JSON 描述文件，核心内容是名称、描述、能力列表和接入 URL。

下面是我给“需求分析 Agent”写的 Agent Card 简化版：

{ "name": "requirement-analyst", "description": "面向产品经理和研发团队的需求分析助手，可输出需求列表、优先级、风险与验收标准。", "url": "https://agent.internal/a2a/requirement-analyst", "capabilities": { "tasks": { "streaming": true, "pushNotifications": false } }, "skills": [ "requirement_analysis", "risk_assessment", "acceptance_criteria" ] }

这里最容易犯的错是 description 写得太虚。比如写“帮助分析需求”，别人根本不知道该不该调你。要写成“输入零散需求描述，输出结构化需求清单、优先级、风险和验收标准”，让调用方在第一秒就能判断“这正是我要的 Agent”。

4.2 Task 流转模型：从发起、执行到结果回收

A2A 的 Task 生命周期可以类比成一次团队任务分配：发起方创建 Task，接收方确认后进入执行态，期间可以发送中间 Message，最后以 completed 或 failed 状态结束。整个交互通过 JSON-RPC 风格的消息完成。

我在实际实现里定了三个接口：一个是能力发现，调用/agent-card获取 Agent Card；一个是任务下发，创建 Task 并带 payload；一个是状态查询，轮询或订阅任务状态。因为我们的 Agent 集群部署在内网，所以暂时关闭了推通知，用轮询实现，简单稳定。对外暴露时，则会在网关层把两个接口包成统一的 HTTP Endpoint。

4.3 安全校验：别让 Agent 变成“没有门禁的公共电话”

Agent 之间的通信安全往往被忽略，但它特别重要。如果不做身份校验，任何人都可以向你的 Agent 发起任务，你等于把内部服务端口暴露在公网。

我的做法分三层：第一层是网络隔离，Agent 间通信默认只在内网或服务网格内进行；第二层是身份认证，服务调用方需要携带访问令牌，A2A 网关统一校验签名；第三层是敏感操作审批，凡是涉及“写操作”“删除操作”“发送外部消息”这类动作，编排器会强制插入人工确认环节。这层安全设计帮我挡住了很多次“Agent 执行失控”的险情。

4.4 真实踩坑：A2A 跨框架互通容易栽在哪

我在接外部团队的 Agent 时踩过几个很具体的坑。第一个是版本不一致，对方用的是旧版 A2A 的消息结构，字段名对不上，解析直接失败，后来统一升级到同一版本并加了 Schema 校验。第二个是循环调用，A Agent 问 B，B 回答不了又转回问 A，两边陷入死循环，我最后限制了最大跳数，默认 3 跳，超过就掐断并告警。第三个是超时设置，Agent 处理长任务时经常超过默认 HTTP 超时时间，不要用同步等待，改成任务状态轮询。

这些坑的共性是“协议通了，但工程经验没有”。A2A 解决了能不能互相通信的问题，但通信质量还需要业务层去管控。

5. 扩展层落地：把 Skills 变成可复用、可测试、可发现的资产

5.1 一个合格 Skill 应该包含什么

我先给一个我项目里实际在用的 Skill 模板，再逐个字段解释：

名称：requirement_analysis 描述：当用户提供零散需求文本时，按统一格式输出需求列表、优先级、风险点、验收标准。 适用场景：产品需求文档整理、用户反馈归类、PRD 草稿生成。 输入参数： raw_text: string，必填，零散的需求描述。 执行步骤： 1. 从 raw_text 中识别完整需求条目，剔除重复和无效信息。 2. 按业务影响、紧急程度、实现成本评估优先级，输出 P0/P1/P2 三档。 3. 对每条需求补充 1~2 个潜在风险点。 4. 为每条需求写出可判定的验收标准。 输出格式： Markdown 表格，列为：需求 ID、需求描述、优先级、风险、验收标准。 示例： 输入：用户希望登录页支持手机号验证码登录，还要记录登录时间。 输出：需求 ID：REQ-001；描述：登录页支持手机号验证码登录；优先级：P0；风险：短信通道限流；验收标准：输入正确验证码后 3 秒内跳转首页，错误验证码提示明确。

这个模板的核心是“把 80% 的重复工作固定下来，只给 Agent 留推理空间”。没有 Skill 时，Agent 每次都要重新想“输出什么格式”；有了 Skill，它就只需要按表格填空。

5.2 description 写得好，Agent 才找得对

很多开发者在写 Skill 时只写步骤，不写描述和适用场景，结果就是编排器根本不知道该在什么时候调用它。我强调一个原则：每个 Skill 的 description 要让另一个 Agent 或编排器在 1 秒内判断“这个 Skill 与当前任务是否匹配”。

关键词要具体，要包含动作和对象。比如“生成测试用例”不如“基于需求列表生成覆盖正常流程、异常流程和边界值的测试用例表”。后者包含了触发条件和预期产出，编排器做技能选择时准确率会高很多。

5.3 Skills 仓库化：版本、依赖、标签、测试

当 Skills 数量增长到几十个之后，我开始用 Git 仓库管它们，目录结构像这样：

skills/ requirement_analysis/ SKILL.md examples/input_01.txt examples/output_01.md tests/test_cases.yaml test_design/ SKILL.md examples/ tests/

每个 Skill 目录里放三样东西：SKILL.md 是主体定义，examples 是输入输出样例，tests 是回归测试用例。发布流程走 Git 标签，编排器加载时按版本拉取，这样改坏了还能回滚。Skills 之间如果存在依赖，比如“验收标准生成”依赖“需求分析”的输出格式，我会在 SKILL.md 头部用 dependencies 字段写清楚依赖关系，加载器会自动按拓扑排序。

5.4 现实中值得优先沉淀的 Skills 类型

结合我这半年项目实践，下面这几类 Skills 的投入产出比最高，也正好是社区里反复被搜索的方向：

• 需求分析与 PRD 生成：输入零散需求，输出结构化文档，适合所有产品研发团队。
• 代码审查：输入代码变更，输出问题清单、风险等级、修改建议，挂到代码库 MCP 上。
• 论文与报告写作：输入素材列表，输出带引用标注的报告草稿，适合学术和调研场景。
• 数据清洗与表格格式化：输入脏数据，输出标准化 CSV 或 Markdown 表格。
• 设计稿转前端代码：接入 Figma 或蓝湖的 MCP Server，让 Agent 读取设计稿标注后生成页面骨架。

这些 Skill 的共同点是“目标明确、步骤稳定、输出可验证”，非常适合用模板固定下来。我现在做新项目时，第一件事不是写代码，而是先翻 Skills 仓库，看有哪些能直接复用。这就是“可扩展”的意义：新增业务的时候，不需要从头造一套 Agent，而是把已有能力重新组合。

6. 实战复现：搭建一个需求分析多智能体集群并跑通流程

6.1 业务目标：从一段产品想法到一份测试用例草稿

为了说清楚整条链路，我用一个教学场景完整走一遍：输入一段产品想法，集群自动完成“需求拆解 -> 风险分析 -> 测试用例设计”的输出。这个场景覆盖了 MCP 工具调用、多 Agent A2A 通信、Skills 复用三个核心环节。

用户输入是：“我们希望做一个团队周报自动汇总工具，支持从多个渠道收集成员周报，自动按项目归类，同时生成管理者周报摘要，还要支持导出 PDF。”就这一句话。

6.2 第一步：用一个 MCP Server 提供“周报文件读取”

我需要让 Agent 能读取本地周报文件。最直接的方式是写一个简单的 MCP Server，暴露一个read_weekly_report工具。教学版核心片段如下：

# 伪代码，结构参照官方 MCP Python SDK from mcp.server import Server app = Server("weekly_report_toolkit") @app.list_tools() async def list_tools(): return [ { "name": "read_weekly_report", "description": "读取指定目录下的周报 Markdown 文件，返回原始文本。", "inputSchema": { "type": "object", "properties": { "path": {"type": "string", "description": "周报文件路径"} }, "required": ["path"] } } ] @app.call_tool() async def call_tool(name: str, arguments: dict): if name == "read_weekly_report": path = arguments["path"] # 注意做路径校验，防止越权读取 with open(path, "r", encoding="utf-8") as f: return f.read()

这里最容易被忽略的是路径校验。我一开始没做限制，Agent 传什么路径就读什么文件，结果不小心读到系统目录，差点把私有环境变量带进上下文。后来加了白名单目录检查，只允许读./weekly_reports/下的文件。

6.3 第二步：搭建需求分析 Agent 和测试用例 Agent

需求分析 Agent 绑定两个 Skills：requirement_analysis和risk_assessment。测试用例 Agent 绑定test_design和traceability_check。两个 Agent 都通过 A2A 注册到编排器，并且都接入同一个 MCP Server，以便在需要时读取真实周报样本。

测试用例 Agent 不需要直接面向用户，它只接收需求分析 Agent 传来的结构化需求列表。这样我可以用更小的模型部署它，成本更低，速度更快。这也是“可编排”带来的一个实际操作红利：你能按角色能力选模型，而不是全链路只用一个大模型。

6.4 第四步：编排器把任务串起来跑

运行过程大致是这样的：用户请求进入编排器，Supervisor 判断这是一个“需求分析 + 测试设计”的组合任务，于是向需求分析 Agent 下发 Task；需求分析 Agent 先调用 MCP Server 读取两份真实周报做参考，然后按requirement_analysisSkill 的步骤输出需求表格，并把结构化结果作为子任务消息发给测试用例 Agent；测试用例 Agent 按test_designSkill 生成测试要点，最后回传给编排器。

我在日志里看到的关键过程如下：

task-001 status: planning task-001 status: running agent: requirement_analyst receives task agent: requirement_analyst calls mcp: read_weekly_report agent: requirement_analyst produces 5 requirements, 3 risks agent: test_case_generator receives structured requirements agent: test_case_generator produces 12 test cases task-001 status: completed

整个过程不到两分钟，输出包含需求表、风险表和测试用例表。放到之前单 Agent 模式下，这种多级任务往往会被模型“自作主张”压缩，要么只给需求不给测试，要么给了测试但没有需求结构。

6.5 失败点复盘：Task 消息里的 Markdown 格式差点毁掉下游解析

这次跑通里有两次小事故值得记录。第一次是需求分析 Agent 返回的消息里带了 Markdown 表格以外的说明文字，测试用例 Agent 在解析表格时把说明文字也当成了需求，生成了几条“伪需求”。解决办法是在 A2A 消息里规定：传给下游 Agent 的数据必须是纯表格数据，附带内容放另一个字段。第二次是 MCP 工具读取文件时返回了超大文本，把子任务上下文塞爆了。解决办法是在 MCP Server 侧做文本长度截断，只返回前 2000 字和文件总行数。

这两个坑与其说是技术问题，不如说是“协议契约”设计问题。Agent 之间通信不能只传自然语言，还要定义结构化字段，否则接收方永远要靠模型猜。

7. 从能跑到能扛：并发、安全、测试与生态观察

7.1 Agent 集群怎么扛并发

社区里“AI Agent 怎么扛并发”问得非常多，我的答案是：Agent 本身很难直接扛并发，真正扛并发的是它背后的队列和 worker 池。

我们的方案是把编排器拆成两部分：API 入口轻量处理，只负责把请求放进队列，立刻返回 task_id；后端 worker 池异步消费队列，每个 worker 负责一个 Agent 子任务。用 Python 的 asyncio 可以很轻松跑起一个 worker 池：

async def run_workers(num_workers): tasks = [asyncio.create_task(worker_loop()) for _ in range(num_workers)] await asyncio.gather(*tasks)

同时还要做三件事：限流，防止外部请求直接把队列打爆；超时控制，每个子任务设最长执行时间，超时就标记失败；幂等处理，同一个 task_id 重复提交不会被重复执行。我把结果存到 Redis，前端只需要轮询 task_id 状态即可，体验很好。

7.2 Agent 安全：最小权限不是口号，是约束

Agent 安全是我每次都会单独强调的模块，因为 Agent 有模型能力加成，一旦配置不当，危害比普通脚本更大。我的安全基线有三条：所有 MCP Server 都按最小权限设计，比如数据库 Server 默认只读，文件 Server 默认只读白名单目录，写操作单独开一个需要审批的工具；写类工具必须走人工确认；全链路审计日志，谁在什么时间调用了哪个工具、传了什么参数，全部落盘。

有一次我为了省事，把生产数据库 MCP Server 配了写权限，然后测试时 Agent 差点把一行测试数据更新成空值。从那以后，我再也没让任何 Agent 直接拿生产库写权限。这条安全经验可能比任何性能优化都值钱。

7.3 Skills 回归测试：让技能不随模型升级而漂移

Skills 最大的隐患是“今天能用，明天模型一升级就不能用了”。我的做法是给每个 Skill 配一套回归用例，就像单元测试一样。比如requirement_analysis的测试文件里放 10 组输入输出样例，每次更新模型或修改 Skill 后，跑一遍回归，检查输出结构是否和样例一致。

测试不能只看格式，还要看语义覆盖。我会用一串黄金关键词做匹配，比如“输出中必须包含 P0/P1/P2 优先级字段”“每条需求必须包含验收标准”。跑不过就说明 Skill 定义或模型提示方式需要调整。这个流程很土，但有效，能让集群长期保持稳定表现。

7.4 生态观察：MCP 正在变成“行业工具标配”

这半年给我的一个明显感受是，MCP 生态在快速向专业软件蔓延。设计领域有 Figma、蓝湖的 MCP 接入，开发者可以让 Agent 直接读取设计稿标注；游戏引擎方向有 Unreal 相关 MCP 插件，场景资源查询可以走协议接口；专门的调试分析软件也开始提供 MCP 扩展；国内一些 RPG 脚手架项目甚至直接把 MCP 功能合并进后台框架。Dify、Cherry Studio 这类工具也都在把 MCP 作为接入标准。

这个趋势对我们做 Agent 集群是重大利好：工具侧适配得越多，我们通过 MCP 能指挥的行业软件就越多，Agent 集群从简单的“文本问答”升级成“真正干活的生产系统”的路径就越短。

8. 最后一层体会：把集群当产品做，而不是当代码堆

课程和项目收尾后，我最大的体会是：多 Agent 集群是一件需要持续经营的产品，不是一次性写出来的脚本。技术选型只是第一步，更重要的是流程约定，包括 Skills 怎么写、Agent Card 怎么描述、任务消息怎么定义字段、安全审批怎么执行。这些约定越早沉淀成模板和文档，后期扩展就越轻松。

另外，我在这半年里反复向团队强调一个“土”原则：永远先跑通三个 Agent、两个 MCP Server、十个 Skills 的最小闭环，再加并发、加安全、加新场景。我们吃过两次“一上来就设计 20 个 Agent 架构”的亏，结果连最简单的流转都调不通。集群的能力是长出来的，不是设计出来的。把最小闭环跑稳，再逐步扩充，你会亲眼看到整套系统从“能跑”变成“能扛”，这是做 Agent 基础工程最有成就感的部分。