企业官网建设流程全解析

三句话就能说清MCP、Tools、Skills的关系，但我见过太多人在群里问“这仨到底啥区别”“先学哪个”“是不是有了MCP就不用写Tools了”。说实话，这三个词看起来都是给AI Agent扩展能力，实际定位完全不同，用错场景就是灾难。这篇内容我会把它们的底层逻辑、适用场景、配置方式、协作套路全部拆开揉碎讲清楚，从概念对比一路讲到完整工作流搭建，全程穿插真实踩坑记录，适合刚接触Agent开发的新手，也适合已经被MCP和Skills绕晕的进阶玩家。

先说结论：如果把AI Agent比作一个员工，Tools是他能动手干活的工具，MCP是他连接外部系统的标准接口，Skills则是他的工作手册和SOP。三者的设计目标、使用方式、协作关系各有侧重，搞清楚这一点，后面所有实操都不会迷路。

1. 三者定位通识：先分清大脑、手脚和接口

1.1 Agent、LLM、AI模型到底什么关系，DeepSeek属于哪层

很多人一上来就问“DeepSeek和AI Agent有什么区别”“MCP是不是另一个大模型”，这其实是在混淆不同层级的东西。AI模型（比如DeepSeek、GPT、Claude）是“大脑”，负责理解语言、推理和生成内容，它们本身不会主动去查数据库、调接口、操作浏览器。AI Agent是一个完整的“执行者”，它拿着大脑做规划、拆任务、调用外部能力、检查结果，最后把东西交给你。

所以DeepSeek属于模型层，它可以用作Agent的推理引擎，但Agent本身还需要工具调用、记忆管理、任务编排这些模块。MCP、Tools、Skills都是围绕Agent的“能力扩展”方案，不是模型本身，也不是模型之间的竞争关系。理解了这个分层，再看后面几个概念就不会乱。

1.2 Tools：能干活，但得一个个人肉接

Tools在Agent语境里指的是“可被模型调用的函数或API”。比如你写一个get_weather(city)函数，把它用JSON Schema描述清楚（参数、返回值、功能说明），注册给Agent，模型在推理时如果觉得需要天气信息，就会生成一个调用请求，由运行环境替你执行这个函数再拿回结果。

Tools的特点非常鲜明：单点、轻量、开发成本低。你不需要任何协议，只要定义好入参出参就能用。但缺点也在这——它是离散的，一个Tool只解决一个具体动作，如果要完成一个复杂流程（比如“打开设计稿→提取样式→生成页面→截图验证”），你就得自己编排好几个Tool的调用顺序，而且每次新场景都要重新接。Tools适合确定性强、粒度小的能力。

1.3 MCP：一套标准接口，连接一切外部系统

MCP全称Model Context Protocol，模型上下文协议。它不是某个具体工具，而是一套“怎么让AI访问外部系统”的标准化规则。类比一下，USB-C是一个硬件接口标准，任何支持它的设备插上去就能用；MCP就是AI世界的USB-C——MCP Server负责把某个系统（数据库、浏览器、设计稿平台、抓包工具）包装成标准接口，Agent作为MCP Client只需按协议通讯，就能调用这个系统里的能力。

以蓝湖MCP为例，设计团队的设计稿、标注、切图都放在蓝湖上，传统做法是前端人肉去看标注、量间距、复制颜色。接了蓝湖MCP之后，Agent可以直接查询设计稿信息，把尺寸、颜色、字体、切图链接都拿到，然后去生成前端代码。Playwright MCP则是把浏览器自动化包装成标准接口，Agent可以打开页面、点击元素、截图、读取控制台日志。Burpsuite MCP、Yakit MCP则是把流量拦截和分析能力暴露给Agent，方便做安全测试。

MCP的价值在于“一次接入，处处复用”。只要Server写好，任何支持MCP的客户端都能用，不用为每个Agent单独适配。它的代价是引入了一个协议层，概念和排障成本比Tools高。

1.4 Skills：把流程、经验和工具打包成可复用的“技能包”

Skills是最高一层，它是“提示词+工作流+可能引用的Tools/MCP”的组合包。简单说，Skills把“怎么完成一类任务”的全部经验写成了结构化文件，遇到对应场景时Agent会按Skill里的步骤走。前端开发Skills可能包含任务拆解清单、代码规范、组件库使用说明、常用调试命令；图片生成Skills可能包含提示词模板、模型参数推荐、后处理流程；Superpower Skills这种热门包，本质就是一组精心编写的、面向各类任务的高质量Skills集合。

Skills和Tools最大的区别是：Tools是“单一动作的接口”，Skills是“完成目标的完整打法”。一个Skills内部可以调用多个Tools和一个MCP Server，还包含模型每一步该输出什么、怎么判断结果是否合格。它更像是给Agent配备的岗位培训手册，而不是一个具体的工具函数。

2. 核心技术拆解：协议、函数与流程的深度对比

2.1 MCP的通信机制与Server/Client/Host角色

想在实操里玩转MCP，得先理解它的架构。MCP有四个角色：MCP Host（宿主程序，比如Claude Desktop、Claude Code、IDE插件）、MCP Client（宿主机内置的协议客户端）、MCP Server（能力提供方，比如蓝湖MCP Server、Playwright MCP Server）、本地或远程资源（数据库、文件、API服务）。Agent运行时，Host会启动Client连接各个Server，Server暴露工具、资源、提示三类能力，两边通过JSON-RPC 2.0格式的消息通信，传输层默认走stdio（本地进程），也可以配置成SSE或HTTP走远程。

这个设计解决了一个很现实的痛点：以前给Agent接10个外部系统，要写10套不同的适配逻辑；现在大家统一按MCP规范写Server，Agent这边只要实现一次协议客户端就行，剩下的事是配置“要连哪个Server、叫什么服务名”。用官方SDK（Python或TypeScript）写一个MCP Server并不复杂，核心就三步：定义一个Server实例、用装饰器注册Tool/Resource/Prompt处理器、run在主进程里。

2.2 Tools的函数签名设计：JSON Schema是命根子

Tools运行机制比MCP简单，但做好并不容易。关键在于向模型描述“这个工具是什么、什么时候该调、参数怎么填”。业内通用做法是让开发者提供一个JSON Schema格式的工具定义，包括name（工具名）、description（工具用途及使用时机）、parameters（参数结构，类型、是否必填、枚举值、描述）。

踩过很多次坑之后我的经验是：模型调用工具出错，80%的情况是工具描述写得含糊。比如一个工具叫get_user_info，description只写“获取用户信息”，模型根本不知道你期望它什么场景下调用、从哪拿用户ID。正确写法是“当用户需要查看账户资料、订单状态或会员等级时使用。参数user_id来自当前登录会话，仅当用户明确提到某个特定用户时才传入”。参数描述也一样，要把取值范围和常见格式写清楚。好的工具定义等于提前帮模型做了信息过滤，能显著提高调用准确率。

2.3 Skills的包结构：不止是提示词，是完整SOP

Skills的形态在不同生态里略有差异，但核心思路是一样的。以Claude Code里手动安装GitHub Skills为例，一个Skill通常是一个目录，里面放着SKILL.md主文件（说明触发条件、目标、步骤）、scripts/（辅助脚本）、reference/（参考资料）、assets/（模板或样例）。安装方式不复杂：把GitHub仓库clone到本地Skills目录，然后在Agent配置里指定路径，重启会话后就能用。

我之前看到有人以为Skills就是个system prompt，这是误解。真正好用的Skill应该包含“判定逻辑”——什么时候激活这个技能、什么时候不激活；还要包含“执行策略”——先做什么后做什么，每一步输出什么格式；关键的是还要写明“使用哪些工具/MCP、参数怎么填”。一个图片生成Skills如果真的达标，它会在用户丢来一句“做一张夏日促销主视觉”后，自动分析需求、选择是否参考模板、拼接提示词、调用图片模型、校验出图结果、给出备选方案。这不是一句提示词能做到的，而是一个完整的“动作序列+决策规则”包。

2.4 对比总结与选型判断

为了让大家一眼看清差异，我做了一张表：

选型逻辑很简单：如果能力是“单一明确动作”且你不会换Agent，优先写Tools；如果要连一个外部系统，且希望以后所有Agent都能访问，就上MCP；如果目标是沉淀一类完整任务的打法，让Agent“照着做就行”，必须写成Skills。现实项目里，大多数健康架构是三个并存：底层Tools做基础动作，MCP解决外部连接，Skills把前两者组织成可复制的工作流。

3. 实操篇：从配置到自研，一步步接上你的Agent

3.1 环境准备：Claude Code、Codex、OpenCode里怎么挂扩展能力

要实操就得先选一个Agent宿主。目前主流终端Agent有Claude Code、Codex CLI、OpenCode，它们都原生支持MCP和Skills。以安装复杂度排序：OpenCode最省心，它有一个插件生态和Skills推荐列表，网上很多常用Skills源网站都能找到包；Codex需要看官方配置方式，新版对MCP支持也比较成熟；Claude Code的Skills安装更依赖手动clone和目录指定，但你一旦摸清结构，管理起来最可控。

Chrome浏览器扩展设置里启用MCP连接也是一种玩法——安装扩展后相当于把一个浏览器侧的MCP Server跑起来，让Agent能够读取当前页面上下文、执行扩展内的工具。这对做网页信息抽取、表单自动填充场景很有帮助，配置方式通常是在扩展弹窗里填一下Agent的监控端口或协议地址。

3.2 手把手写一个Tools：以“查询实时天气”为例

新手第一次接Tools，最好做一个对模型判断要求不高的简单函数。我这里用一个查询天气的示例说明完整流程。

先用Python写业务函数：

import requests def get_weather(city: str, unit: str = "celsius") -> str: # 这里对接任意天气API，省略鉴权细节 resp = requests.get(f"https://api.example.com/weather?city={city}&unit={unit}") data = resp.json() return f"{city}当前温度{data['temp']}℃，{data['condition']}，风力{data['wind']}级"

然后定义Tools的JSON Schema：

{ "name": "get_weather", "description": "查询指定城市当前天气。当用户询问天气、温度、是否适合出行、下雨概率时使用。", "input_schema": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名，如北京、上海" }, "unit": { "type": "string", "enum": ["celsius", "fahrenheit"], "default": "celsius" } }, "required": ["city"] } }

如果你用的是OpenAI函数调用格式，把schema直接挂到Tools列表里；如果用的是Claude Code，把它放在工具注册模块里。注册后实测时问Agent“北京今天适合跑步吗”，它会先调get_weather拿天气数据，再结合常识回答，而不是凭空编一个天气——这就是Tools的意义。

3.3 MCP Server实战：蓝湖MCP与Playwright MCP的接入

MCP Server接入分为“使用现成的”和“自己折腾”两个层次。先用现成的打通流程。

以蓝湖MCP为例，假设你已经把某设计稿分享到蓝湖项目里。蓝湖官方提供了MCP Server二进制或npm包，你只需把它配置到Agent的MCP列表。配置完成后，直接对Agent说“读取蓝湖上XXX项目的设计标注，提取首页的导航栏尺寸和主色调”，Agent会通过MCP协议连接Server，拿到设计信息并整理给你。对前端开发来说这意味着“看图写码”变成了“取数据写码”，信息获取路径短了一大截。

Playwright MCP更通用。它的Server包一个浏览器自动化能力入口，安装后在Agent里配置一下，就能指挥Agent“打开本地开发服务器，点击登录按钮，输入测试账号，把页面截图保存到桌面”。Agent自身不具备操作浏览器的能力，Playwright MCP就是替它长出这只手。

自己写MCP Server也不难。用官方TypeScript SDK写一个最简Server：

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; const server = new McpServer({ name: "demo-server", version: "1.0.0" }); server.tool("add", "计算两个数之和", { a: { type: "number" }, b: { type: "number" } }, async (args) => ({ content: [{ type: "text", text: String(args.a + args.b) }] }) ); const transport = new StdioServerTransport(); await server.connect(transport);

启动后这个进程就是一个通过标准输入输出通信的MCP Server。在Agent配置里声明“npx启动某个JS文件”或直接指向编译产物，连接就建立起来了。核心概念不复杂，复杂的是业务逻辑本身。

3.4 编写一个Skills包：图片生成Skills的目录与内容

Skills的好处在于，你不需要为Agent重写代码，只要提供清晰的说明文件。以图片生成Skills为例，一个合格的包长这样：

image-generation-skill/ ├── SKILL.md ├── assets/ │ ├── prompt_templates.md │ └── style_reference.json └── scripts/ └── post_process.py

SKILL.md的内核结构大体是四块。第一块写触发条件，明确“当用户要求生成视觉内容且能描述主体风格时激活”。第二块写执行步骤，比如先拆解主题、要素、情绪风格，再判断是否需要参考模板，然后构造提示词，调用图片模型，校验比例，再跑后处理脚本。第三块写依赖的工具与MCP，比如需要“图片生成API”相关Tool，或者在本地有ComfyUI的MCP Server。第四块写质量标准和返工规则，比如“画面主体不完整则重新生成”“文字模糊则调整提示词词序”。

装到Claude Code这类终端里，直接把目录放到Agent指定的Skills文件夹，重启会话即可。之后你在新会话里说“按我的项目色调做一张Banner”，模型会依据SKILL.md里的规则一步步走，而不是漫无目的地自由发挥。

4. 工作流协同设计：从0到1搭建一个完整Agent

4.1 典型场景拆解：设计稿到前端代码的自动化

我们不妨把蓝湖MCP、Playwright MCP、前端开发Skills放在同一个Agent里，设计一个“从设计稿到可运行页面”的完整工作流。这个链路能直观展现三者怎么协作。

第一步，Agent收到任务“把蓝湖上登录页设计稿实现为React页面”。此时前端开发Skills会被触发，Skills里定义了接入规范：优先使用组件库、颜色和尺寸严格参考设计稿、图片资源用切图链接。第二步，Agent通过蓝湖MCP Server读取设计稿的布局结构、色彩变量、字体规格、标注信息，甚至拿到选中图层的CSS片段。第三步，Agent基于这些信息生成组件代码并落盘。第四步，启动本地开发服务器，通过Playwright MCP打开页面截图，Agent自己判断“视觉还原度是否达标”，如果不达标就返回修改。这个过程里，Skills是行动指南，两个MCP各管一段信息来源，Tools在关键节点执行计算和文件操作。

4.2 工程化配置：一个能跑通的最小Agent架构

配置一个能承载上述工作流的终端Agent，按以下顺序做：

• 选宿主：确定用Claude Code或OpenCode作为执行载体
• 接MCP：在配置里分别添加蓝湖MCP Server和Playwright MCP Server，给它们命名，比如lark_mcp和playwright_mcp
• 放Skills：把前端开发Skills放进技能目录，在配置里指定路径
• 补Tools：写几个基础工具，如save_file、run_command、fetch_url
• 跑通测试：给Agent一个简单页面设计稿，要求它走完整链路

我在多个项目里用这个架构实测，体验下来最明显的感受是：MCP解决了“信息拿不到”的瓶颈，Skills解决了“不知道怎么做”的瓶颈，两者加上一个能干活的模型，自动化程度立刻质变。

4.3 Skills沉淀与团队复用

Skills的真正红利不在单机使用，而在团队沉淀。我和前端小组的做法是：每个项目结束后复盘整个开发过程中Agent被指导最多的环节，把决策规则、踩坑经验、代码规范写成一个新的Skill文件，评审后合并进团队的Skills仓库。新成员入职后用这些Skills跑一遍真实任务，产出质量基本能对齐老手的水平，这就是流程资产化的价值。

维护Skills也要立规矩。版本管理用Git，变更必须有diff评审；Skill激活条件必须写“什么情况下不要用”，避免模型误触发；Skill内部依赖了外部MCP或Tools，就得在文件里标明依赖清单，防止换环境后失效。个人练手建议从“写周报”“整理会议纪要”“批量重命名文件”这些小任务开始，跑通一个Skill的完整制作闭环，再去做复杂业务型Skills。

4.4 能力扩展的顶层思路：先定目标再选组件

很多人在搭建Agent时习惯先装一堆MCP，再下几个Skills，结果模型每次都要在几十个工具里纠结。我的建议是从目标反推组件：你只解决一个具体问题（比如修Bug时快速定位日志），那就先写一个读取日志的Tool；如果还需要连数据库、操作线上系统、访问第三方平台，那一律走MCP；如果这个过程是重复性高的多步任务，就把它固化成一个Skill。

每加一个能力都要评估它对上下文和决策的负担。硬件再强的模型，在工具定义列表超过三四十个时，选择准确率也会肉眼可见地下降。宁可少而精，也别贪多嚼不烂。

5. 常见问题、踩坑实录与排查速查

5.1 高频问题速查表

5.2 几个让我印象深刻的实战坑

第一个坑是搜索关键词撞车。查Skills资料时你会看到大量叫“VMware Tools”“Office Tools”“Network UPS Tools”的结果，它们和AI Agent的Tools完全是两码事。第一次搜资料时我被这些干扰了大半天，后来在搜索词里强制加上“AI Agent”“MCP”“Claude Code”等限定词才清净。这个经验也提醒我：Skills源网站的质量参差，优先看官方文档和GitHub高星仓库，别什么包都往生产环境装。

第二个坑是“Tianditu Tools保存Key失败”这类环境配置问题。表面上是保存Key失败，实际往往是目录权限、HTTP代理或系统密钥链访问受限。排查思路是：第一步看日志，第二步检查目录写入权限，第三步把Key写入环境变量而非依赖GUI保存。很多MCP类工具有类似的毛病——以为是工具的问题，其实是你本机的网络或权限问题。

第三个坑是MCP连接“进程假活”。Server起在后台，你以为连上了，实际Agent发请求时它已经僵死。最稳的判断方法是先在终端手动启动Server，直接发一个标准请求看返回；能通再接进Agent。这条经验适用于所有stdio型MCP Server。

5.3 能力进阶的靠谱路径

我觉得学习这三个东西有个合理顺序：先练Tools，写五六个实用函数，把JSON Schema写明白，理解模型怎么“看”工具；再用现成的MCP Server打通外部系统，体会一次接入多处复用的价值；然后再写第一个Skills，把前面写的Tools和MCP串成一套流程。动手练手项目也别贪大，从“用Agent定时抓取某个网页的标题和正文”“让Agent根据Excel表格生成周报”这类小任务做起，跑通一两个完整闭环后，再去挑战“从设计稿到前端页面”这种复合工作流。

学习资源方面，优先读官方文档对MCP规范的定义和示例，然后在GitHub上找一些热门MCP Server的源码，拆解它们的Tool命名和描述写法。Skills资料可以去社区整理的长列表里找inspiration，但务必在本地隔离环境实验，确认没有未知脚本再放进主环境。书籍类内容可以找一些围绕Agent开发的资料，但技术变化快，核心还是以官方文档和实战为准。

最后说一个我的真实体会：这三样东西从来不是分高下的关系，而是分层协同的关系。如果你为了跟风，给一个简单Agent塞一堆MCP和Skills，反而会拖垮推理体验。真正该做的是冷静拆解你的任务，让Tools干细活，让MCP开门路，让Skills传打法。我自己最初就是从一个小Tools开始，后来接上数据库MCP，再后来把团队的前端交付流程沉淀成了Skills，效果比追任何新名词都扎实。这篇内容里所有步骤和坑都能按图索骥再走一遍，如果在实操中碰到表格里没覆盖的情况，不妨从“配置有没有写对、描述够不够清楚、链路通不通”三个方向入手排查，大概率能解决问题。