企业官网建设流程全解析

1. 为什么大家总在 Skill、MCP 和插件之间纠结

1.1 一个被问烂了的问题

过去大半年，我在各种技术群里被问得最多的一句话就是：“我想给 AI Agent 加个能力，到底该写 Skill、接 MCP，还是做个插件？”问的人里有做后端的老哥，有搞前端顺手玩 Agent 的，也有产品经理跑来凑热闹。大家的问题表面上是“选哪个”，但真正卡住他们的，其实是没搞清楚这三样东西各自站在哪一层。

我先把结论摆出来：Skill、MCP 和插件不是三选一的关系，它们解决的是完全不同层面的问题。把它们放在一起比较，就像问“做饭到底该用菜谱、燃气灶还是锅”——菜谱是知识，燃气灶是基础设施，锅是具体容器，你缺哪个补哪个，而不是挑一个扔掉另外两个。

这个误解之所以流行，是因为市面上很多教程把三者混着讲。有的文章说“MCP 是下一代插件”，有的说“Skill 会取代插件”，还有的说“有了 MCP 就不用写 Skill 了”。这些说法单独看都有点道理，但拼在一起就让人彻底懵了。我这篇就按我自己的实际使用经验，把这三层拆开讲清楚，顺便把“怎么扛并发”“怎么选型”“怎么落地”这些真问题一起聊了。

1.2 先给三者各画一张像

我用一个具体的场景来锚定：假设你要做一个能帮用户处理 Excel 报表的 AI Agent。

Skill是“怎么做这件事”的知识。比如“读取 Excel 时先检查合并单元格”“日期列要统一格式再计算”“遇到公式列不要直接取值要读缓存值”。这些是经验、是流程、是判断逻辑，它不依赖任何特定工具，换成 Python 的 openpyxl 还是 pandas 都能用。Skill 的本质是可复用的领域知识与操作规范。

MCP（Model Context Protocol）是“Agent 怎么和外部世界对话”的协议。它规定了 Agent 用什么格式去请求一个工具、工具用什么格式返回结果、上下文怎么传递、错误怎么表达。你可以把它理解成 Agent 世界的 USB 接口标准——只要双方都遵守这个协议，谁插谁都能用。MCP 是通信层的基础设施。

插件是“具体某个软件里的一段扩展代码”。比如 VS Code 插件、Figma 插件、IDEA 插件，它们依附于宿主软件，用的是宿主提供的 API，生命周期也由宿主管理。插件是宿主生态内的功能扩展。

把这三张画像摆在一起，你会发现它们根本不在一个维度上。Skill 管“怎么想”，MCP 管“怎么连”，插件管“挂在哪”。一个成熟的 Agent 系统，往往是三者同时存在、各司其职。

1.3 为什么这个区分如此重要

因为选错层，你会付出完全不成比例的代价。

我见过一个团队，为了给 Agent 加一个“查询内部知识库”的能力，硬是写了一个完整的插件体系，结果发现他们真正需要的只是一个 MCP Server 加一份 Skill 文档。插件那套东西维护成本极高，每次宿主升级都要跟着改，而 MCP Server 写完基本不用动。

反过来，我也见过有人想用 MCP 去解决“Agent 回答风格不稳定”的问题。这完全是南辕北辙——回答风格是 Skill 层面的事，是提示词和流程设计的问题，跟通信协议一点关系都没有。

所以搞清楚这三层，不是为了学术上的严谨，而是为了让你在动手之前就知道该把力气花在哪一层。下面我逐层拆开讲，每一层都会给出我实际用过的做法和踩过的坑。

2. Skill 层：把领域经验变成 Agent 能用的知识

2.1 Skill 到底是什么，不是什么

先澄清一个常见误解：Skill 不是代码，至少不主要是代码。它是一个结构化的知识包，告诉 Agent 在特定场景下应该遵循什么流程、注意什么细节、按什么顺序做事。

我自己的 Skill 通常包含这几块内容：触发条件（什么情况下该用这个 Skill）、操作步骤（一步步该做什么）、判断规则（遇到分支怎么选）、常见陷阱（哪些地方容易出错）、输出规范（结果应该长什么样）。这五块凑齐，一个 Skill 才算能用。

举个我实际写过的例子，一个“代码审查 Skill”大概长这样：

## 触发条件 用户提交代码片段并请求审查时 ## 操作步骤 1. 先通读整体结构，判断模块划分是否合理 2. 检查命名规范，变量名是否表意清晰 3. 检查边界条件，特别是空值和越界 4. 检查错误处理，是否有吞异常的情况 5. 检查性能隐患，如循环内查询、重复计算 ## 判断规则 - 如果代码少于 20 行，跳过结构审查直接看细节 - 如果涉及数据库操作，优先检查 SQL 注入和事务边界 - 如果是并发代码，优先检查共享状态和锁粒度 ## 常见陷阱 - 不要只挑格式问题，那是最没价值的审查 - 不要假设作者知道某个库的坑，该说清楚就说清楚 ## 输出规范 按严重程度分级：阻断性问题、建议改进、可选优化

你看，这里面没有一行可执行代码，但 Agent 拿到它之后，审查质量会明显不一样。这就是 Skill 的价值——把老手的判断力固化下来。

2.2 Skill 的编码方式与组织技巧

热词里出现了“skill 编码 247”“skill 编码 193”这类说法，我理解这是某些团队内部对 Skill 的编号管理方式。我自己的做法是按领域分层编号，比如skill-code-review-001、skill-data-clean-002，前缀标领域，后缀标序号。这样在 Agent 加载时能按需检索，不用把所有 Skill 一股脑塞进上下文。

组织 Skill 有几个实操要点。第一是粒度要适中。太粗的 Skill 比如“处理所有编程问题”，等于没写；太细的 Skill 比如“给变量起名”，又碎得没法用。我的经验是，一个 Skill 对应一类任务，大概覆盖 5 到 15 个操作步骤比较合适。

第二是触发条件要写得可判断。很多人写触发条件写成“当用户需要时”，这等于没写。要写成 Agent 能实际匹配的形式，比如“当输入包含代码块且用户消息含‘审查’‘review’‘看看’等词时”。

第三是版本管理。Skill 是要迭代的，我一般用 Git 管理，每次改动写清楚改了什么、为什么改。因为 Skill 的效果很难量化，不记录变更历史的话，过两个月你自己都不知道为什么当初那么写。

2.3 Skill 的加载策略与上下文预算

这是很多人忽略的一点：Skill 不是越多越好，因为上下文是有预算的。

我早期犯过一个错，把几十个 Skill 全部塞进系统提示词，结果 Agent 反而变笨了——它要在海量规则里找该用哪条，注意力被稀释得厉害。后来我改成按需加载：先用一个轻量的路由层判断当前任务属于哪个领域，再只加载对应的那两三个 Skill。

具体做法是在系统提示里放一个 Skill 索引，每个 Skill 只写一行摘要，Agent 判断需要哪个再请求完整内容。这样上下文占用能降一个数量级，效果反而更好。

提示：Skill 的加载策略直接决定 Agent 的响应质量。宁可少加载几个精准的，也不要全量塞入。

还有一个技巧是Skill 的优先级标记。有些 Skill 是硬约束（比如安全规范），有些是软建议（比如代码风格）。我会在 Skill 里标注优先级，硬约束的必须遵守，软建议的可以灵活处理。这样 Agent 在冲突时知道该听谁的。

2.4 去 AI 味的 Skill 怎么写

热词里有个“去 AI 味的 skill”，这个我特别有感触。Agent 生成的内容之所以有“AI 味”，往往是因为 Skill 里写满了“请确保”“需要注意的是”“综上所述”这类模板化表达，Agent 照着学，输出自然就那个味。

我的做法是在 Skill 里明确写反面示例。比如：

## 输出规范 禁止使用以下表达： - “通过本文可以看出” - “综上所述” - “随着技术的发展” - “为...提供了有力支持” 要求： - 直接说结论，不要铺垫 - 用具体数字代替“很多”“大量” - 用主动语态，不要“被...所...”

把禁止项写清楚，比写一堆“要自然”“要口语化”有用得多。Agent 对具体的负面清单比对抽象的风格描述敏感得多。

3. MCP 层：Agent 与外部世界之间的那根线

3.1 MCP 到底解决了什么问题

在没有 MCP 之前，每个 Agent 要接一个外部工具，都得单独写一套对接代码。接数据库写一套，接文件系统写一套，接第三方 API 再写一套。这些代码逻辑高度相似，但格式各不相同，维护起来是灾难。

MCP 的出现就是为了统一这件事。它定义了一套标准的请求-响应格式，任何工具只要实现这个协议，就能被任何支持 MCP 的 Agent 调用。一次实现，处处可用，这是它最大的价值。

我打个比方：以前每个电器都有自己的充电口，出门要带一堆线；MCP 就像 USB-C，统一之后一根线走天下。当然现实中 USB-C 也没那么统一，MCP 也一样，但方向是对的。

3.2 MCP 的核心概念拆解

MCP 里有几个关键概念，理解了它们就理解了整个协议。

Resources（资源）是 Agent 可以读取的数据，比如文件内容、数据库记录、API 返回。它是被动的，Agent 去读才有。

Tools（工具）是 Agent 可以调用的动作，比如发送邮件、执行查询、创建文件。它是主动的，Agent 调用它会产生副作用。

Prompts（提示模板）是预定义的提示词模板，让 Agent 在特定场景下用特定格式提问。这个用得相对少，但在标准化场景下很有用。

Sampling（采样）是让 Server 反过来请求 Client 的模型能力，这个比较进阶，一般场景用不到。

理解这四个概念的区别很重要，因为很多人把 Resources 和 Tools 搞混。简单说：读数据用 Resources，做事情用 Tools。分清楚这个，设计 MCP Server 的时候就不会乱。

3.3 自己写一个 MCP Server 的完整流程

我拿一个实际做过的例子来讲：给 Agent 加一个“查询本地 Markdown 笔记”的能力。

第一步，确定能力边界。这个 Server 只做三件事：列出所有笔记、按关键词搜索笔记、读取指定笔记内容。不要贪多，能力越聚焦越好维护。

第二步，选传输方式。MCP 支持 stdio 和 HTTP 两种传输。本地工具用 stdio 更简单，远程服务用 HTTP 更合适。我这个笔记查询是本地场景，选 stdio。

第三步，实现协议方法。核心是实现list_resources、read_resource和list_tools、call_tool这几个方法。用 Python 的话，官方有 SDK，几十行就能跑起来。

from mcp.server import Server from mcp.server.stdio import stdio_server from mcp.types import Resource, Tool, TextContent app = Server("notes-server") @app.list_resources() async def list_resources(): notes = scan_notes_directory() return [ Resource( uri=f"note://{n['id']}", name=n['title'], mimeType="text/markdown" ) for n in notes ] @app.read_resource() async def read_resource(uri: str): note_id = uri.replace("note://", "") content = read_note(note_id) return content @app.list_tools() async def list_tools(): return [ Tool( name="search_notes", description="按关键词搜索笔记", inputSchema={ "type": "object", "properties": { "keyword": {"type": "string"} }, "required": ["keyword"] } ) ] @app.call_tool() async def call_tool(name: str, arguments: dict): if name == "search_notes": results = search(arguments["keyword"]) return [TextContent(type="text", text=format_results(results))]

第四步，配置到 Agent 端。在 Agent 的配置文件里加上这个 Server 的启动命令，Agent 启动时会自动拉起它。

第五步，测试。先单独跑 Server，用官方的 inspector 工具测一遍，确认每个方法都能正常响应，再接到 Agent 上。

3.4 MCP 选型的几个现实考量

不是所有场景都值得上 MCP。我的判断标准是：如果这个能力会被多个 Agent 复用，或者需要独立部署和更新，那就值得做成 MCP Server；如果只是某个 Agent 的一次性需求，直接写在 Agent 代码里更省事。

另外要注意 MCP Server 的启动开销。stdio 模式下每个 Server 是一个独立进程，如果接十几个 Server，启动时间和内存占用都不小。我一般会把相关能力合并到一个 Server 里，比如“文件操作”一个 Server 管所有文件相关的事，而不是每个操作一个 Server。

还有错误处理。MCP 协议规定了错误返回格式，但很多实现偷懒直接抛异常。我建议在 Server 里把常见错误都转成结构化的错误响应，这样 Agent 能根据错误类型决定是重试还是换方案，而不是一脸懵。

4. 插件层：宿主生态里的功能扩展

4.1 插件和 MCP 的本质区别

很多人把插件和 MCP 混为一谈，其实它们的定位完全不同。

插件依附于宿主。VS Code 插件只能在 VS Code 里跑，用的是 VS Code 的 API，生命周期由 VS Code 管理。离开这个宿主，插件什么都不是。

MCP Server 是独立的。它不依赖任何特定宿主，任何支持 MCP 的 Agent 都能连它。它的生命周期由自己或调用方管理。

所以插件解决的是“在某个软件里增强功能”，MCP 解决的是“让 Agent 能访问某个能力”。一个 VS Code 插件可以同时是一个 MCP Server 的客户端，但这两件事是分开的。

4.2 什么时候该做插件

我的判断很简单：当你的能力必须深度集成某个软件的 UI 或内部状态时，做插件；否则优先考虑 MCP。

比如你想在 Figma 里加一个“一键生成设计规范文档”的功能，这必须做成 Figma 插件，因为它要读取 Figma 的图层结构、要弹出 UI 面板、要操作画布。这些是 MCP 做不到的。

但如果你只是想让 Agent 能读取 Figma 文件的内容，那做一个 MCP Server 就够了，不需要插件。

热词里提到的“codex 接入 figma mcp 怎么授权”就是典型的 MCP 场景——Agent 通过 MCP 访问 Figma 数据，而不是通过插件。授权这块通常是 OAuth 流程，Figma 的 MCP Server 会引导你完成授权，拿到 token 后就能访问你的文件。

4.3 插件开发的通用套路

虽然不同宿主的插件 API 千差万别，但开发套路是相通的。

第一，先读宿主的能力清单。每个宿主都会提供一份 API 文档，告诉你哪些能做哪些不能做。别急着写代码，先把能力边界摸清楚，不然写到一半发现做不了就尴尬了。

第二，从最小可用版本开始。我见过太多人一上来就想做完整功能，结果卡在某个 API 上出不来。正确做法是先做一个能跑通的最小版本，比如只弹一个面板显示“Hello”，确认整个链路通了，再往上加功能。

第三，注意生命周期。插件的激活、停用、卸载都有对应的钩子，资源要在停用时释放，状态要在激活时恢复。这块偷懒的话，用户用久了就会遇到内存泄漏或者状态错乱。

第四，做好错误隔离。插件崩了不能把宿主带崩，所有可能出错的地方都要 try-catch，错误要友好提示而不是直接抛栈。

4.4 插件与 Agent 的协作模式

插件和 Agent 不是竞争关系，它们可以协作。我见过几种不错的模式。

模式一：插件作为 MCP 的 UI 前端。插件负责展示和交互，实际能力通过 MCP Server 提供。这样能力可以复用，UI 可以针对宿主优化。

模式二：插件触发 Agent 任务。用户在插件里点一个按钮，插件把任务发给 Agent，Agent 处理完把结果回传给插件展示。这种适合“用户主动触发”的场景。

模式三：Agent 调用插件能力。Agent 通过某种桥接机制调用插件暴露的能力。这种比较少见，因为插件通常不对外暴露接口，但技术上可行。

选哪种模式取决于你的场景。我的经验是，能用 MCP 解决的尽量用 MCP，插件只做那些非它不可的部分。这样整体架构更清晰，维护成本也更低。

5. 三层如何协同：一个完整的落地案例

5.1 案例背景：给团队做一个代码助手 Agent

我拿去年给一个团队做的代码助手来举例，完整展示三层怎么配合。

需求是：Agent 能审查代码、能查内部规范文档、能在 IDE 里直接给建议。

5.2 Skill 层的设计

这个 Agent 的 Skill 包括：代码审查流程、命名规范判断、常见 bug 模式识别、审查意见的表达方式。每个 Skill 都是独立文件，按需加载。

特别说一下“审查意见表达方式”这个 Skill，它规定了意见要分级别、要给具体修改建议、不要只说“这样不好”。这个 Skill 直接决定了 Agent 输出的可用性。

5.3 MCP 层的设计

做了两个 MCP Server：一个是“规范文档查询”，暴露 Resources 让 Agent 读内部规范；一个是“代码仓库访问”，暴露 Tools 让 Agent 能查历史提交、看文件变更。

这两个 Server 都是独立部署的，其他 Agent 也能复用。规范文档更新了，Server 那边改一下，所有 Agent 都受益。

5.4 插件层的设计

做了一个 VS Code 插件，功能是：在编辑器里选中代码，右键“让 Agent 审查”，结果以侧边栏形式展示，点击意见能跳转到对应行。

插件本身不包含审查逻辑，它只是把选中的代码发给 Agent，把结果展示出来。真正的审查能力在 Skill 和 MCP 那边。

5.5 三层的协作流程

用户选中代码点审查，插件把代码和上下文发给 Agent。Agent 先加载代码审查 Skill，然后通过 MCP 查询相关规范，再结合 Skill 里的判断规则生成意见，最后按输出规范格式化，回传给插件展示。

整个流程里，Skill 提供“怎么审”，MCP 提供“查什么”，插件提供“在哪用”。三者缺一不可，但各管各的，互不干扰。

6. 常见问题与排查实录

6.1 高频问题速查表

6.2 几个我踩过的坑

坑一：Skill 写得太抽象。早期我写 Skill 喜欢用“要专业”“要准确”这种词，结果 Agent 完全不知道该怎么执行。后来改成具体动作，比如“检查每个函数是否有对应的错误处理”，效果立刻不一样。Skill 要写成可执行的动作，不是形容词。

坑二：MCP Server 返回数据太大。有一次查询返回了几百条记录，直接把上下文撑爆了。后来改成默认返回前 10 条，需要更多再分页。MCP 返回数据一定要控制大小。

坑三：插件和 Agent 的状态不同步。插件里显示的是旧数据，Agent 那边已经更新了。后来加了一个版本号机制，每次数据变更都递增版本，插件发现版本不一致就重新拉取。跨组件协作一定要有状态同步机制。

6.3 关于并发的那点事

热词里有“ai agent 怎么扛并发”，这个问题值得单独说。

Agent 的并发瓶颈通常不在模型调用，而在上下文管理和工具调用。多个请求同时进来，如果共享同一份上下文，就会互相污染。我的做法是每个会话独立上下文，工具调用做连接池，MCP Server 做无状态设计。

具体来说，MCP Server 尽量设计成无状态的，每次请求带全所需信息，不要在 Server 端存会话状态。这样多个 Agent 实例可以共享同一个 Server，水平扩展很容易。

如果确实需要状态，就放到外部存储里，Server 本身保持无状态。这是扛并发的关键。

7. 我个人的选型建议

7.1 一张决策图

遇到“该做哪层”的问题时，我按这个顺序判断：

先问“这是知识还是能力”。是知识就写 Skill，是能力就往下走。

再问“这个能力需要深度集成某个软件的 UI 吗”。需要就做插件，不需要就做 MCP Server。

最后问“这个能力会被多个 Agent 复用吗”。会就独立部署 MCP Server，不会就直接写在 Agent 里。

这个顺序能覆盖大部分场景，剩下的边角情况再具体分析。

7.2 不同阶段的投入重点

早期验证阶段，重点写 Skill。因为 Skill 成本最低，改起来最快，能快速验证 Agent 的能力边界。

能力扩展阶段，重点做 MCP。把可复用的能力抽成 MCP Server，为后续扩展打基础。

产品化阶段，重点做插件。把 Agent 能力包装成用户能直接用的形态，降低使用门槛。

这个顺序不是绝对的，但大方向是这样。我见过太多人一上来就做插件，结果核心能力还没跑通，插件做完了发现 Agent 根本不好用，白费功夫。

7.3 最后分享一个小技巧

如果你不确定某个能力该放哪层，先把它写成 Skill。Skill 是最轻的，写错了改起来快。等这个 Skill 稳定了，再考虑要不要把其中的能力抽成 MCP Server。这样迭代成本最低，也不容易一开始就架构过度。

我自己现在做新 Agent，都是先写 Skill 跑通流程，再逐步把通用能力抽成 MCP，最后才考虑要不要做插件。这套流程走下来，基本不会出现大的返工。