企业官网建设流程全解析

提到 Skill、MCP 和子 Agent，我见过不少同学把三者当成同一类能力来对比，比如“MCP 是不是要取代 Skill”“子 Agent 是不是就是更小的模型”。实际上，它们并不是同一层级的东西。Skill 是单个 Agent 的技能清单，MCP 是连接外部工具和数据的标准协议，子 Agent 是真正去执行独立任务的工作单元。搞不清这三者，很容易在配置阶段就出问题：明明挂了好几个工具，Agent 却不调用；明明写了一段“Skill”，执行起来完全没效果。这篇文章把三者定位、适用场景、组合方式和最容易被带偏的误区拆一遍，适合正在做 Agent 应用开发，或者研究 Codex、Claude Code 这类工具的人参考。

先说一个整体判断：这三者不是“谁替代谁”的关系，而是会在同一个 Agent 应用里叠加出现的三样东西。Skill 负责让单个 Agent 知道“该用什么方法做”，MCP 负责让 Agent 能“连上外部世界”，子 Agent 负责把一个复杂任务拆给多个执行单元。把这三个层级看明白，后面很多配置问题都能自己定位。

1. 先给结论：三者是不同层级，不是同类替代品

1.1 用一句话给三者定位

先看一张对比表，把这三样东西放在同一个维度上比会很别扭，因为它们本来就不在同一层：

Skill 通常挂在 Agent 的能力范围里边，更像一份操作手册；MCP 站在 Agent 和外部世界的边界，负责把外部服务翻译成 Agent 能理解的接口；子 Agent 则在任务编排层，决定谁来执行哪一段任务。

所以最准确的理解是：一个任务进来，父 Agent 负责拆解，子 Agent 负责执行，执行时加载对应的 Skill 作为行为规范，需要外部数据或工具时再通过 MCP 调取。三者是串在一条流水线上的。

1.2 为什么大家总把它们搞混

很多人第一次接触这些概念，是因为不同工具的教程侧重点完全不一样。比如有人从 Agent 框架里看到“Add Skill”，有人从工具生态里看到“Configure MCP Server”，还有人从编排平台里看到“Create Sub Agent”。这三个入口在界面上经常挨在一起，看起来像并列选项，自然会被误认为是同层概念。

再加上社区里习惯性简化：有人把 Skill 叫“插件”，有人把 MCP Server 叫“工具”，有人把子 Agent 叫“小模型”。简化本身没有错，但一旦简化过头，认知就会跑偏。

有一个快速判断方法：问自己三个问题。

• 这个配置改变的是 Agent 的行为方式，还是连接外部服务的通道，还是创建一个新的执行单元？
• 如果答案是“行为方式”，基本是 Skill 或提示词层面。
• 如果答案是“连接外部”，基本是 MCP。
• 如果答案是“新执行单元”，基本是子 Agent。

2. Skill：给单个 Agent 补“行为方式”，不是接外部的插件

2.1 Skill 到底是什么

Skill 通常不是一段模型权重，也不是一个独立运行的进程，而是一份描述、一组示例、可能还会带上脚本或资源文件。它让 Agent 在特定场景下，按照固定套路使用自己已有的能力。

举几个实际场景：

• 让编码 Agent 按团队规范生成提交信息，包括类型、范围、描述格式。
• 让文档 Agent 生成统一格式的项目周报，结构固定、字段固定。
• 让数据分析 Agent 先看字段完整性，再算统计指标，最后输出 Markdown 表格。

在社区里经常能看到各种 Skill 包，名字五花八门。它们的共同点不是“模型变强了”，而是“行为更可控了”。同一个模型，加载了好的 Skill，输出质量和稳定性能提升一大截；加载了写得不清不楚的 Skill，反而可能干扰模型本来该有的判断。

2.2 写一个可用的 Skill，关键看这几点

很多人问“Skill 怎么写”，我的建议是先别急着追求花哨，先把四段结构写清楚：触发条件、执行步骤、输出格式、失败兜底。

从概念上看，一份 Skill 的结构大致是这样，具体字段要以你实际使用的平台为准：

Skill 名称：按团队规范生成提交信息 适用场景：开发者在终端里提交代码，需要生成 commit message 触发条件：用户要求“生成提交信息”或“写 commit” 执行步骤： 1. 读取当前暂存区文件列表 2. 识别改动类型：feat、fix、docs、refactor、test 3. 按“类型: 描述”格式生成提交信息 4. 如果存在关联需求编号，追加到正文 输出格式：第一行类型加描述，正文放需求编号和备注 失败兜底：无法识别改动类型时，输出 fix: 待确认修改内容

好 Skill 的判断标准有三个：

1. 输入条件写得清楚。什么时候该加载，什么时候不要加载，必须明确。否则 Agent 可能在无关任务里也套用规范。
2. 步骤可执行。不要写“认真分析”“仔细思考”这种空话，要写“先提取哪些字段、再计算什么、最后输出什么”。
3. 输出可消费。如果输出要交给下一个环节处理，最好固定成 Markdown 表格或 JSON，方便后续节点读取。

再强调一点：Skill 长度不要失控。过长的 Skill 会占用上下文窗口，还可能让 Agent 忽略其中一部分约束。我一般建议先写一个核心版本，跑通后再根据失败案例逐步补边界条件。

2.3 Skill 能做什么，不能做什么

能做的事：让 Agent 在特定场景下更稳定地完成任务，行为可复现，输出格式统一，知识沉淀在文件里而不是只靠人记住。

不能做的事：不能凭空增加模型本来不具备的能力。如果你让模型解析一种它完全没有见过的私有二进制格式，Skill 帮不上太多；如果你让模型调用一个根本没接通的数据库工具，Skill 也救不回来。Skill 改变的是“怎么做”，而不是“底层能力”。

另一个很容易踩的点是：加载了 Skill，但 Agent 没有被触发。常见原因是描述太模糊，或者被 System Prompt 里的其他指令覆盖。排查时先确认 Agent 是否真的读取到了这份 Skill，再检查触发条件是否和实际任务匹配。

3. MCP：把外部工具和数据接入 Agent 的标准化协议

3.1 MCP 解决的是“接入标准化”问题

MCP 是一个开放协议，全称含义是“模型上下文协议”。它的价值在于让 Agent 和外部工具之间的对接方式统一起来。没有 MCP 的时候，接入每一个外部服务都要单独写集成，接数据库写一套，接设计稿写一套，接浏览器控制又写一套。有了 MCP，客户端和服务端按同一套协议对话，Agent 能统一发现和调用外部工具。

比较常见的 MCP Server 方向包括：文件系统、数据库、浏览器操作、设计稿读取、项目管理工具、代码仓库等。比如通过 MCP 连接设计稿工具，Agent 可以读取设计稿上的标注信息；连接数据库后，Agent 可以执行查询并整理结果；连接浏览器工具后，可以做一些页面自动化验证。

注意一个关键认知：MCP Server 不是“工具程序”本身，而是负责把外部能力翻译成 Agent 能理解的接口。真正干活的是背后那个服务，MCP 只是标准和入口。

3.2 接入 MCP 时真正要盯住的环节

很多朋友接入 MCP 时，以为只要在客户端配置里填一个地址或命令就结束了。实际上一条完整链路至少有这些环节：

1. Agent 客户端读取 MCP 配置。
2. 客户端启动或连接 MCP Server。
3. MCP Server 向客户端返回可用工具列表。
4. Agent 根据任务调用某个工具。
5. MCP Server 执行请求并返回结果。
6. Agent 把结果整理进回答。

从概念上，MCP 配置大致长这样，具体字段以你使用的客户端文档为准：

{ "mcpServers": { "some-server": { "command": "...", "args": ["..."], "env": { "API_KEY": "..." } } } }

任何一个环节出问题，都会表现为“工具没生效”。常见的坑有三个：

• Server 没启动。远程地址不可达，本地命令路径不对，都会导致客户端拿不到工具列表。
• 鉴权失败。很多第三方 MCP 需要 token 或密钥，过期之后 Agent 能聊天，但一调用工具就报错。
• 返回结构和声明不一致。工具声明自己能返回某种格式，实际服务端返回了另一种，Agent 解析失败。

接入时建议用小成本工具先验证。比如先接一个“读取当前时间”或“读取一条固定记录”的 MCP，确认连接、鉴权、参数传递都没问题，再切换到真实业务工具。

3.3 工具“注册不上”先查哪里

“工具注册不上”是高频问题。比如有人用了设计稿类 MCP，在客户端里总提示工具注册不了。此时不要急着重建缓存或反复重启客户端，按顺序排查：

1. 先确认 MCP Server 是否真的在运行，本地看进程，远程看端口或 API 健康检查。
2. 再确认客户端配置里的名称、地址、命令参数是否和 Server 端一致。
3. 接着看鉴权凭证是否有效，很多“注册不上”本质是认证失败。
4. 再检查返回的工具列表，客户端不展示时，直接请求 Server 的接口看输出。
5. 最后才考虑客户端缓存或版本问题。

实际碰到的案例里，大部分问题出在前三步。真正是客户端 Bug 的比例很低。

3.4 MCP 和 Skill 在任务里如何分工

MCP 和 Skill 经常一起出现，但分工不同。MCP 负责“有外部能力可调”，Skill 负责“知道怎么用这个能力”。

举个例子：通过 MCP 连接了设计稿工具，Agent 能读取到设计稿文件。但如果没有 Skill，它可能只是把内容读出来，不知道要按设计稿的哪些标注去生成代码。如果加载了一个“设计稿转代码 Skill”，它就会按照团队规范：先读取画板尺寸，再提取颜色和字体变量，然后按组件结构生成页面代码。

所以你在搭建方案时，不能只挂 MCP 不写 Skill，也不能只写 Skill 不接 MCP。一个是管道，一个是用法，两者配合才能让 Agent 真正完成任务。

4. 子 Agent：独立上下文的任务执行单元，不是更小的模型

4.1 子 Agent 的本质是职责拆分

很多人一听“子 Agent”，第一反应是“是不是一个更小的模型”。不是。子 Agent 可以继续使用同一个模型底座，区别在于它拥有独立的上下文、独立的角色设定、独立的任务边界和工具权限。

父 Agent 负责理解整体任务、拆解流程、分配子任务；子 Agent 负责在限定范围内执行。这样做的好处是上下文隔离。如果所有内容都堆在同一个上下文里，任务一长，父 Agent 很容易被无关信息干扰，或者上下文被撑爆。

子 Agent 并不比普通 Agent 更聪明，它只是职责更聚焦。把任务拆给了它，它照样可能失败。设计子 Agent 的关键不是“多”，而是“边界清楚”。

4.2 什么时候才应该拆子 Agent

不是所有任务都要拆。一句话任务、五步内能完成的任务，拆子 Agent 反而增加调度开销。

出现这些情况再考虑拆：

• 任务有明显阶段，比如先收集数据，再分析，再生成报告。
• 各阶段需要不同的专业指令或工具，混杂在同一个 Agent 里容易互相干扰。
• 单个 Agent 的上下文快被占满，需要把中间结果抽离。
• 多个子任务可以并行执行，拆开后能缩短总耗时。

判断标准很朴素：如果用一个 Agent、五步以内就能跑出预期结果，不要拆。如果任务里有两个完全不同专业方向的环节，各自需要一套复杂的 Skill 和工具，拆开更合适。

拆的代价也要想清楚：父 Agent 到子 Agent 之间需要重新传递任务说明，子 Agent 返回结果后父 Agent 还要理解、整合。如果返回格式不规范，整合阶段照样会乱。

4.3 子 Agent、Skill、MCP 的一次协作示例

假设要生成一份竞品分析报告，流程可以是这样：

1. 任务进入父 Agent。
2. 父 Agent 将任务拆给“数据收集子 Agent”“分析子 Agent”“汇总子 Agent”。
3. 数据收集子 Agent 通过 MCP 调用网络检索工具或数据库接口，收集竞品信息。
4. 分析子 Agent 加载“竞品分析 Skill”，按固定维度输出竞品功能、差异、优缺点。
5. 汇总子 Agent 读取多个分析结果，按固定模板生成最终报告。

这套流程里，每个子 Agent 可能都会用到 Skill 或 MCP。父 Agent 不做具体操作，只负责调度。关键不是把工具集中在根节点，而是把正确的 Skill 和 MCP 工具分配给正确的子 Agent，避免互相污染。

子 Agent 的返回结果尽量结构化。比如分析子 Agent 返回一个 JSON 或 Markdown 表格，汇总子 Agent 就能稳定读取。如果返回一段自由发挥的散文，父子之间很容易断档。

5. 组合顺序：先跑通一个 Agent，再接入 MCP，最后拆子 Agent

5.1 第一步：单 Agent 加单个 Skill 跑稳

我见过不少团队一步到位搭多 Agent 架构，最后排查时连“是哪个环节输出不对”都定位不了。更稳妥的顺序是先做最小闭环：一个 Agent，一个 Skill，一个明确任务。

验证方法：准备三个不同的输入，让 Agent 按 Skill 执行，观察输出是否稳定。

• 三个输入都能触发 Skill 吗？
• 输出格式都一致吗？
• 边界输入处理得怎么样？

如果这三个问题都过了，再考虑加新能力。不要一上来就挂十几个 Skill，否则一旦行为异常，你很难判断是哪个 Skill 写坏了。

5.2 第二步：给 Agent 接入一个最小 MCP 工具

接入 MCP 时，先选一个低频、副作用小的工具。不要一上来就接一个会写数据库、会发消息、会删除文件的工具。

建议先接这类工具：读取当前时间、读取一条固定记录、查看某个文档目录结构。这些操作没有破坏性，适合验证链路。

验证点包括：

• MCP Server 是否能正常启动。
• Agent 是否能发现工具。
• 调用参数是否正确传递。
• 返回结果是否被正确解析。
• 失败时日志是否可读。

单次调用通过之后，再加第二个工具，再测批量调用。注意看超时和并发。有些 MCP Server 本身只能处理少量并发请求，并发一高就把进程打崩了。

5.3 第三步：按任务阶段拆子 Agent

子 Agent 拆得太早，会引入不必要的调度复杂度。我建议先跑完第二步，确认主 Agent 已经能把单个任务做完整，再进入多 Agent 编排。

拆的时候先画清楚流程：

• 任务怎么进入父 Agent？
• 父 Agent 怎么判断用哪个子 Agent？
• 每个子 Agent 的输入是什么？
• 子 Agent 返回什么格式？
• 失败时谁负责重试或纠正？

这些都在纸面上想清楚，再动手写配置和代码。子 Agent 之间不要互相绑得太死，尽量通过父 Agent 中转。否则某一个子 Agent 升级或改参数，会影响整条链路。

5.4 组合时的资源、并发和日志问题

组合起来之后，最容易被低估的是资源和日志。

子 Agent 并发执行能提升吞吐，但要注意：

• 底层模型 API 是否有并发限制。
• 每个子 Agent 的上下文会重新加载，内存和 Token 消耗会增长。
• 多个 MCP 工具同时调用时，外部服务是否扛得住。
• 失败重试会不会造成重复调用。

建议先串行跑通完整流程，再用最小并发测试，逐步增加。不要一开始就开 10 个子 Agent 并行。

日志和输出目录要提前规划。每个子 Agent 的执行记录最好独立保存，任务 ID 或输出文件命名要能追溯到是哪一步产生的。否则任务一多，出了问题就像大海捞针。

6. 高频误区与一套可复用的排查链路

6.1 高频误区速查表

这些误区几乎都能在真实项目里看到。尤其是“装了 MCP Server 就一定生效”这个认知，会让排查方向完全跑偏。明明 Server 没启动，你却在反复重装客户端，浪费一晚上。

6.2 一套可以复用的排查顺序

出现“Agent 不调用 Skill”“MCP 工具注册不上”“子 Agent 返回结果父 Agent 看不懂”这类问题时，按下面顺序排查：

1. 复现最小场景。把任务缩减到只调用一个工具或只加载一个 Skill。
2. 看输入。任务描述是否明确，Skill 触发条件是否和输入匹配。
3. 看服务端。MCP Server 是否在运行，鉴权是否有效，第三方服务是否有故障。
4. 看配置。配置入口是否正确，路径、参数、密钥是否填对。
5. 看日志。客户端日志、Server 日志、运行日志里有没有明确报错。
6. 看依赖和权限。不是文件权限不足，就是依赖版本不匹配。
7. 最后看架构边界。是不是任务根本不该拆子 Agent，或者 Skill 之间互相覆盖了。

不要一上来就怀疑模型能力。很多问题看起来像“模型变笨了”，实际上要么是 Skill 没触发，要么是 MCP Server 挂了，要么是子 Agent 返回格式没有定义好。

6.3 关于“为什么看着配置好了却不起作用”的真实经验

我说一个最常见的组合：接好了一个 MCP 工具，也写了一份 Skill，但 Agent 执行任务时完全不理睬。表面看是 Agent 不听话，实际拆开看，通常是这两个原因之一：

一是 Skill 里没有写“你先通过 MCP 调用某个工具”这个动作。Skill 写了分析规则，但没写数据从哪来，Agent 可能就直接用自己记忆里的假设去分析。正确的写法是在执行步骤里明确“先调用 XXX MCP 工具获取数据，再进行后续处理”。

二是 MCP Server 确实返回了数据，但返回格式和 Skill 里期望的不一致。Skill 要求读 JSON 字段，Server 返回的是一个大字符串，Agent 解析失败后只好强行输出。这个问题看日志最容易发现。

另一个常见点是：在多人协作项目里，不同开发者的客户端配置不一致。一个人能跑通，另一个人跑不通，最后发现是配置文件的加载目录不一样。建议统一配置规范，并且把验证命令写进项目文档。

我个人更建议把顺序反过来：先把单 Agent 加单个 Skill 跑稳，再接入最小 MCP 工具，最后才考虑拆子 Agent。多数团队遇到的不是模型能力不够，而是这三层之间的连接没有理清楚。先降低变量，再逐步扩展，Agent 项目会好落地得多。