企业官网建设流程全解析

搞AI Agent开发，最近绕不开三个词：Skill、MCP和插件。我和不少团队聊过，发现大家对这三者的理解差异非常大，有人觉得它们是三个并列方案，有人把MCP当成Skill的增强版，还有人以为装了插件就等于把技能交给AI。这种理解如果不纠正，后面整个项目都会陷入“反复重构”的泥潭。我自己做过基于LangChain、LangGraph的Agent服务，也维护过一批Skill文件和本地插件，今天把这三件事的边界、定位和组合用法彻底讲清楚，同时给出一份可以直接抄作业的落地记录。

1. 先搞明白Skill、MCP和插件各自在解决什么问题

1.1 Skill：给Agent准备“操作手册”，而不是“工具箱”

很多初学者最容易陷入的陷阱，是把Skill理解成“可以被调用的一段代码”。实际上，Skill的本质是程序性知识：它告诉模型“要做什么、按什么顺序做、有哪些规范、出现异常怎么处理”。它通常以Markdown、YAML或JSON文件的形式存在，并在Agent启动或任务触发时被加载进上下文，或者被编排器按名称检索后注入提示词。

我见过一个运维Agent项目，最开始把所有排查经验写成大段System Prompt，结果模型越改越糊涂。后来把几十条经验拆成一个个Skill文件，每个文件只有名字、用途描述、步骤和几个示例。效果立刻不一样：模型在遇到对应类型的任务时，才把对应的手册调出来，上下文干净、输出稳定。这个思路和“老师傅写作业指导书”完全一样——不是给徒弟发一堆工具，而是告诉他怎么一步步干活。

换个说法：Skill解决的是Agent不会做的问题。它负责把复杂流程拆解成模型能理解、能执行的步骤。很多框架里它还有版本号、依赖工具列表等元信息，比如“skill编码193”“skill编码247”本质上就是把技能当成代码资产来管理，保证多版本并存时可追溯、可回滚。

注意，Skill不是万能的。它只能改变模型的行为和决策，没有办法帮Agent连接一个从未接入的系统。如果Agent需要查数据库，Skill里写了“先查数据库”也没用，必须有一个真实可用的工具。这个工具靠谁提供？就是下面要说的MCP或插件。

1.2 MCP：把所有工具的接入方式统一成一个“标准插座”

MCP（Model Context Protocol）本质上是一个软件协议，规定了AI客户端如何发现和调用外部工具、资源、提示词。你可以把它理解成USB-C：以前每个外部API都要单独写适配代码，现在只要服务器实现了MCP协议，任何支持MCP的客户端都能直接用。

具体到工程上，你会有一个或多个MCP Server进程。它们内部封装了真实业务逻辑，比如调用订单接口、读数据库、发消息、控制浏览器，对外则暴露统一结构的工具描述和调用入口。Agent端装一个MCP Client，启动时连上Server，把自己需要的工具列表拉下来，运行时再按需调用。整个过程对模型来说是透明的：模型感知到的就是“多了一些工具可用”。

这也是为什么很多人会把MCP和插件搞混：Figma有MCP，Unreal引擎也有MCP，这些能力通常以“插件”形式分发。但你要分清，MCP解决的是Agent与外部系统之间的连接层问题。只要连接关系够标准，底层是普通API、数据库、还是本地应用，都不重要。

“mcp是软件协议还是硬件协议”这个问题，最近总能被搜到。答案很明确：它是软件协议，定义的是消息格式、方法调用和传输约定，跟硬件没有关系。你可以把MCP看成“AI世界的USB-C标准”，既要接头统一，也要数据传输协议统一。

1.3 插件：在宿主应用里长出来的“功能模块”

插件和前两者根本不在同一个层级。插件是运行在某个宿主应用内部的代码模块，它扩展的是宿主本身。比如IDE插件给编辑器增加快捷键和面板，浏览器插件给网页增加按钮和内容注入，Figma插件让画布元素可以被读出来，Unreal 5.8通过插件把MCP server集成进编辑器，让AI能操控场景。

对Agent来说，插件最大的价值是：很多原生能力只在宿主环境里才存在。比如读写本地文件、操作系统级通知、后台定时任务、桌面交互UI，这些在纯API服务里实现很别扭，在浏览器插件、桌面插件里却是基本功。

插件不是给Agent用的，也可以给Agent用。关键看你有没有做桥接。最常见的方式有三种：一是插件的界面操作走传统用户入口；二是插件内部直接集成MCP server，把宿主能力以标准工具形式暴露给Agent；三是插件启动本地HTTP服务，再由MCP server把这个本地服务包装成工具。后两种其实就是典型的“插件+MCP”组合拳。

从这个表格能看出来，三者不是“谁替代谁”。Skill管头脑，MCP管网线，插件管手脚。偏信任何一个，都会让整个Agent能力体系变得畸形。

2. 别再纠结三选一，按场景缺什么补什么

2.1 先问自己：Agent是“不会做”“连不上”还是“没地方跑”

我接到过不少“需求”，最典型的一句话是：“我给它加了很多MCP工具，但它就是不按我想的来。”这种情况大概率不是工具不够，而是流程和判断条件没有写清楚。反过来，也有人做了一堆Skill，Agent倒是知道该做什么了，结果每次调外部系统都要重新适配一遍，累到不想维护。这其实都是选型判断出了问题。

判断方法很简单，遇到“AI能力不足”时先拆成三个问题：

• 它是否缺步骤规范和判断标准？缺，就是写Skill。
• 它是否缺访问外部数据或系统的通道？缺，就是上MCP。
• 它是否缺一个具备UI、本地资源、宿主权限的运行环境？缺，就是做插件。

举一个真实工作流：一份经营周报，需要查订单数据、按固定模板写总结、生成PDF发到群里。这三件事分别落在三个层面：查数据靠MCP连接订单系统；写总结靠Skill规定模板和口吻；生成PDF并发送，则靠本地插件或浏览器插件提供文件导出和群机器人能力。你没法只用其中一个把整条链路跑通。

2.2 什么时候应该优先写Skill

写Skill性价比最高的场景，通常具备这几个特征：业务步骤稳定、判断规则明确、生成结果格式固定，或者模型经常在不该胡思乱想的地方自由发挥。

我自己的经验是，内部知识类的管理工作，千万别一上来就写Skill。如果同一个提示词你改了三遍还是觉得不够好，说明它已经值得固化成独立技能了；如果任务使用频率很低，每次场景差异很大，那它更适合直接写到System Prompt里。固化成Skill后，省下的其实是每次对话的输入token，因为你不需要再把整段长流程发给模型。

还有一类场景值得写Skill：多人协作需要对齐口径。比如“数据分析结论必须包含影响因子和置信度”“对外文案禁止用感叹号”，这些规范很难靠模型自觉遵守，用Skill强制挂到流程里，比写进System Prompt有效得多。

2.3 什么时候应该优先上MCP

MCP解决的问题是“连接”和“复用”。如果你发现团队里多个Agent服务都在调用同一个内部系统，并且每次都要各自写一遍HTTP封装和鉴权逻辑，那这个系统就应该做成MCP Server。一次封装，所有Client共享。

另一个信号是“标准化的诉求很强”。比如公司内部的AI平台希望规范所有外部工具接入流程，统一控制权限、埋点、审计。把工具都收敛到MCP网关后面，调用方式统一了，安全策略和日志也自然统一。

还有一个很容易忽略的使用时机：当你想让现有工具被多个AI产品复用。比如你把公司的GitHub仓库搜索能力接成MCP Server，那么不光是你的Agent能用，同事电脑里的桌面端AI、编码类IDE插件只要支持MCP，都能直接复用。这种生态价值是单独写一套内部API完全不具备的。

2.4 哪些场景必须依赖插件

第一是UI和表单。Agent自动生成的参数用户不一定敢直接确认，总得有个面板让人检查和点击，这个UI在纯服务端很难给，在插件里却可以很顺手。第二是离线或本地资源，比如读取本地磁盘文件、调用本机加密狗、操作Office，浏览器插件和桌面插件是最省事的载体。第三是宿主级权限，比如监听IDE保存事件、捕获快捷键、往网页注入内容，这些只有插件能拿到。

我之前给一个仿真设计团队做过工具链，直接面对一个尴尬问题：他们想用Agent驱动Unreal编辑器，但编辑器本身是个重客户端，纯HTTP API不够用。后来就是在Unreal里装一个包含MCP Server的插件，把场景操作暴露成标准工具。所以千万别觉得“上了MCP就不需要插件”，很多场景里没插件连MCP Server都放不进去。

3. 组合落地实操：用一套“运营助手”把它们串起来

3.1 先说清楚整体架构怎么搭

为了直观，我用一个内部“运营助手”作为例子。技术栈是FastAPI + LangGraph + FastMCP，但这个思路换任意框架都成立。整体上我把系统拆成四层：

• Agent编排层：LangGraph负责理解用户请求，维护对话状态，决定加载哪些Skill。
• Skill资源层：仓库里有业务技能文件，包括周报生成、竞品分析、活动复盘等。每个文件描述了触发条件、执行步骤、需要用到哪些工具。
• 连接层：Agent内置MCP Client，连接多个MCP Server。这些Server分别对接订单系统、库存系统、群机器人。
• 插件层：浏览器扩展和本地桌面小工具，负责导PDF、文件选择、桌面通知。插件能力再通过一个本地MCP Server暴露给Agent。

这里有个容易被忽略的点：MCP Server的数量并不等于工具质量。我习惯把每个Server的工具控制在十几个以内，并用具名前缀区分，否则模型很容易在一堆相似工具里选错。

3.2 先写一个MCP Server，把数据和通知能力暴露出去

核心代码如下，用的FastMCP库：

from fastmcp import FastMCP mcp = FastMCP("ops-assistant") @mcp.tool() def get_order_stats(date: str) -> str: """获取指定日期的订单统计数据，供周报和运营分析使用。""" # 项目里这里会调用内部订单服务API return f"{date} 订单量: 1024, 成交额: 35500 元" @mcp.tool() def send_webhook(url: str, content: str) -> str: """把文本消息通过 webhook 发送到群机器人。""" # 这里省略真实HTTP请求逻辑 return "webhook sent" if __name__ == "__main__": mcp.run(transport="sse")

启动后，MCP Client会从Server拉取工具清单：get_order_stats和send_webhook。注意工具函数的docstring很关键，它会被当成工具描述喂给模型。描述写得越具体，模型越不容易误用。

传输层我建议开发阶段用sse，比较好调试；生产环境如果要求性能，可以看框架是否支持streamable http。想远程部署时，尽量别用stdio模式，否则进程管理很麻烦。

3.3 把业务规则沉淀成Skill文件

接下来我们把“生成经营周报”做成Skill：

name: weekly_report description: 根据订单统计数据生成经营周报，适合在每周五总结时使用。 version: 1.2 agent_instructions: | 1. 先调用 get_order_stats 获取近7天数据。 2. 按“整体情况、增长点、风险点、下周建议”四段输出。 3. 所有数字必须给出同比或环比，缺失时标注“暂无对比”。 4. 内容超过300字时，可以使用 send_webhook 发送到群机器人。 tools_required: - mcp__ops-assistant__get_order_stats - mcp__ops-assistant__send_webhook

这个文件生效的关键是description字段。编排器会拿用户请求和description做匹配，描述越贴合实际使用场景，模型就越能准确命中。很多团队技能库越做越大，最后模型经常选错Skill，十次里有八次是因为description写得像论文摘要，而不是像“什么时候能用的召回词”。

把Skill看成代码来管理，能解决很多遗忘问题。我的习惯是：给每个技能维护独立文件、写版本号、做变更记录。有些团队会给技能编码，比如SKILL-193、SKILL-247，本质上和代码仓库的Issue号一样，做回溯和评审都方便。任何一段Prompt被固化之后，都必须走“评审—测试—发布”流程，别让个人偏好直接污染技能库。

3.4 把插件能力“桥接”给Agent

这个环节最考验工程能力。举个例子：运营助手需要导出PDF版周报，Agent本身没有文件系统，也不该直接操作服务器磁盘。稳妥做法是：浏览器插件或桌面小工具提供本地导出服务，监听127.0.0.1:8899的HTTP请求。

插件侧的核心逻辑大致是这样：

// 桌面插件/浏览器扩展的本地服务 export async function exportPdf(title: string, htmlContent: string) { // 调用系统的打印/导出模块 return `/tmp/${title}.pdf`; // 导出成功返回文件路径 }

然后我们在MCP Server里补一个工具去转发：

@mcp.tool() def export_pdf(title: str, html_content: str) -> str: """将HTML内容导出为PDF文件，返回文件路径。""" # 项目里这里用HTTP请求访问本地插件的导出接口 return "/tmp/weekly_report.pdf"

这样Agent感知到的只是一个普通MCP工具，底层实际调用的是插件能力。如果需要更轻的方式，也可以在插件内部直接跑一个MCP Server，不再额外写转发层。两者没有本质差别，主要看谁负责进程管理和生命周期。

3.5 全链路跑一次

用户对Agent说：“把本周情况整理成PDF发到群里。”完整链路是这样的：

• LangGraph先按weekly_report描述把Skill加载到上下文里；
• Skill要求Agent依次处理近7天数据，于是Agent调用MCP工具get_order_stats拿到数据；
• 模型按Skill里的规则组织内容，生成一段结构化周报；
• 需要PDF时，Agent调用MCP工具export_pdf，该工具转调本地插件导出文件；
• Agent再调用send_webhook把文档信息和链接发到群机器人，任务结束。

这条路没有一步是多余的：Skill提供了步骤和规范，MCP保证了数据和消息能通，插件提供了本地文件能力。三样都在场，整条链路才完整。

4. 常见问题与排查技巧实录

4.1 Skill写了但Agent死活不用

这是我自己踩过次数最多的坑，几乎每次都出在这几个地方。第一，description和实际触发场景对不上，模型检索时压根没召回；第二，Skill文件没有真正进入上下文，很多框架为了省token会按相关性动态加载，如果你设的阈值太高，匹配不到也正常；第三，工具名和Skill里写的对不上，模型找不到依赖工具，自然放弃执行步骤。

排查方法也简单：打开一次全量日志，先看模型这次请求加载了哪些Skill、上下文里有没有对应片段，再看最终工具调用列表里有没有它读到的那些工具。每次都有人信誓旦旦说“打开了，还是不生效”，一看日志，文件压根没装进去。这类问题要先把流程打通，再去调prompt内容。

4.2 MCP连上了但频繁超时，并发上来就挂

“AI Agent怎么扛并发”这个问题，在MCP层尤其明显。如果MCP Server是同步阻塞的，比如每个工具里都直接requests.get，一旦有多个Agent同时调用，就会排队卡死。

我的做法是：Server内部尽量用异步接口，工具定义写成async def，底层用httpx.AsyncClient做连接复用；对冷数据可以加一层缓存，减少重复查询；条件允许时再加一个轻量的信号量限流，防止突发流量把下游系统打爆。简单说，要把MCP Server当成一个普通的在线服务去治理，而不是当成本地函数库。

@mcp.tool() async def get_order_stats(date: str) -> str: data = await fetch_order_stats(date) return format_stats(data)

如果你用的Client连不上，先检查协议和端口，再检查鉴权头。MCP报错信息有时比较难懂，我一般先用官方调试面板或直接用Client侧的工具列表接口测一遍，确认Server本身活着，再往前查。

4.3 插件桥接经常出现“没反应”或“跨域被拦”

插件涉及到宿主环境，坑特别多。网页扩展最容易踩的是CSP（内容安全策略）和权限声明，本地请求必须把127.0.0.1加进白名单。桌面插件最大的坑是单实例：用户开了两个窗口，服务端口被占用，Agent调用时只能连上原先那个。

消息时序也很重要。插件本地服务收到的请求不要太复杂，我习惯定义成瘦接口：只做“执行动作并返回状态”，不要让它承担业务流程。否则一旦插件端弹个权限确认框，Agent那边就会傻等，最后超时。

4.4 三套机制组合后，工具冲突和重复权限怎么办

同时用多套MCP Server之后，你会遇到同名工具。比如订单MCP里有个get_user，用户MCP里也有get_user，模型分不清。解决办法是约定命名空间：mcp__<server-name>__<tool-name>，在Skill里写依赖工具时也写全名。

权限上也要注意重复。插件本身有权限，MCP Server也可能用自己的账号调用下游。工具内部最好都把“来源标记”传出去，比如source=agent或source=plugin_bridge，这样审计和幂等控制才有依据。否则同一操作被两个通道触发，很容易出现重复下单、重复扣费等事故。

5. 我现在做Agent扩展时的默认顺序

最后说一点个人经验。我现在接到“Agent能力不足”的需求，默认顺序是这样的：先看是否能用Prompt和Skill解决，再看是否需要新的MCP工具，最后才考虑做插件。不要一开始就奔着MCP网关去，很多场景只是一段业务规则没写清楚，却为了“标准”搭了一座大山。

同样，我也没少见过把插件做成万能神的团队，结果系统里塞了一堆进程，互相抢端口。插件应该像“设备驱动”：平时不启动，等主机需要时再加载。真要让它对Agent可见，就用MCP Server包一层，而不是让Agent直连插件端口。

至于Skill和MCP到底怎么配合，我的体会是：Skill规定模型怎么做，MCP规定模型能碰到什么，插件决定模型在哪个环境里跑。这个顺序一旦定下来，扩展能力时思路就清楚了。希望这份记录能帮你少走几次弯路。