1. 从“Agent 三件套”说起Skill、Rules 与 MCP 到底各管什么这几年做 AI Agent 相关项目的人应该都有同一种感受模型本身的能力上限固然重要但真正决定一个 Agent “好不好用”的其实是外围那套工程化配置。你给同一个模型配上不同的 Skill、Rules 和 MCP 服务它表现出来的智商和执行力可能是天壤之别。我最早接触这三个词是在折腾 Claude Code 和 Codex 的时候。当时网上大量讨论集中在“Skill 是什么”“Rules 怎么写”“MCP 怎么接数据库”但很少有人把这三者放在一起讲清楚。实际用下来你会发现它们根本不是三个孤立的功能点而是一个完整 Agent 系统的三层骨架Rules 管的是“边界”——告诉 Agent 什么该做、什么不该做、按什么规范来做Skill 管的是“能力”——把特定任务的操作流程、提示词模板、脚本工具打包成可复用的技能包MCP 管的是“连接”——让 Agent 能安全地读写外部数据、调用外部服务把能力延伸到沙箱之外。打个不太严谨但很好用的比方Rules 是公司的规章制度Skill 是员工培训手册MCP 是办公桌上的电话和文件柜。没有制度员工会乱来没有手册员工不知道具体活儿怎么干没有电话和文件柜员工再懂流程也拿不到外部信息。三者缺一不可而且顺序上通常先用 Rules 框定行为再用 Skill 赋予流程最后通过 MCP 打通数据。这篇文章我想把这套“Agent 三件套”从头到尾拆一遍重点放在它们分别解决什么问题、怎么配合使用以及我实际项目中踩过的坑。文章会比较长但看完你至少能搞清楚一件事当别人说“给 Agent 加上 Skill”或者“接入一个 MCP Server”的时候他到底在做什么以及你自己要怎么复现。2. 先拆最上层Rules 到底是什么怎么写才不白写2.1 Rules 的本质是“行为公约”不是提示词模板很多人第一次接触 Rules容易把它当成“更长的 system prompt”。这么理解不算全错但会低估它的作用。Rules 的核心价值不在于告诉模型“你是个专家”而在于建立一套可执行的约束体系让模型在多轮对话、多次工具调用中保持一致的行为风格和决策逻辑。我见过一份写得很好的 Rules 文件它甚至不包含任何“你是一个 xxx 专家”之类的身份描述开头直接规定三件事所有涉及文件修改的操作必须先输出 diff 摘要得到确认后再执行遇到不确定的需求先列出假设清单而不是直接开始改代码测试失败时优先贴出错误堆栈和复现步骤再给出修复方案。你看这些规则没有一个是在“教模型知识”全部是在“约束模型行为”。这也是 Rules 和 Skill 最本质的区别Rules 不负责让模型变得更聪明它负责让模型变得更可控。2.2 全局 Rules 与项目级 Rules 的边界划分在实际工程里Rules 通常分两层。个人级全局 Rules 放在用户目录下适用于所有项目项目级 Rules 放在仓库里跟着代码走团队成员共享。我个人的划分原则很简单全局 Rules 只放“价值观级”的约束比如代码风格偏好、提交信息格式、禁止在注释里写个人信息、敏感操作必须二次确认项目级 Rules 放“业务相关”的约束比如这个项目数据库命名规范、测试覆盖率要求、接口返回格式约定。千万不要把所有规则全塞进全局配置。我见过有人把某个前端项目的组件规范写进全局 Rules结果切到另一个后端项目时Agent 动不动就提一些莫名其妙的“组件化重构建议”因为规则冲突导致行为漂移。Rules 越通用越好越具体越要下沉到项目里。2.3 写 Rules 的三个实操要点结合这些年的经验我总结出三条写 Rules 的关键点每一条都是踩坑踩出来的要点一用“行为描述”代替“身份描述”。比起写“你是一名资深前端工程师”不如写“在涉及样式方案时优先考虑 CSS 变量而非硬编码颜色值”。前者模型听完就忘后者会在具体决策点发挥作用。要点二规则数量控制在 10 条以内。亲测超过 15 条之后模型在长对话中遵守率会明显下降。这不是模型不行而是规则之间会出现优先级冲突。如果规则实在多就给规则分优先级明确“当 A 与 B 冲突时以 A 为准”。要点三用负面清单锁死底线。正面规则告诉模型该怎么做负面清单告诉它绝对禁止做什么。比如“禁止直接覆盖用户未提交的更改”“禁止在未确认环境的情况下执行破坏性命令”。负面清单对安全类场景尤其重要。注意Rules 的加载顺序也会影响效果。多数实现里越靠后的规则优先级越高。所以我会把“禁止性规则”放在文件末尾让它们在冲突时占据优势。3. 再看核心层Skill 才是让 Agent “会干活”的关键3.1 Skill 不是单条提示词而是一个“能力包”如果 Rules 解决的是“怎么做人”那 Skill 解决的就是“怎么做事”。一个标准 Skill 通常包含三部分内容触发条件什么场景下激活这个 Skill比如“当用户要求生成数据库迁移脚本时”操作流程完成任务需要遵循的步骤序列可以包含子步骤和决策分支参考资源提示词模板、代码示例、脚本文件、外部文档链接等。我最早真正理解 Skill 的威力是在做数据处理自动化的时候。当时需要让 Agent 定期处理一批 CSV 文件做清洗、统计、出图。如果不用 Skill每次对话我都要重新描述一遍格式要求、字段含义、输出规范Agent 还经常理解偏。后来我把整个流程封装成一个 Skill包含处理流程图、字段映射表、输出模板之后只需要说一句“用数据处理 Skill 跑一下今天的文件”Agent 就能自动完成全流程。从热词里也能看出来现在 Skill 的应用已经蔓延到各个领域数学建模有数学建模 SkillUnity 和 Blender 有 3D 建模辅助 Skill甚至有面向办公场景的 Humanizer Skill 和面向学术写作的科研 Skill。这说明 Skill 的核心价值不在于“让模型多知道一件事”而在于“把一件复杂任务的操作经验固化成可复用的流程”。3.2 Skill 开发的完整流程从任务拆解到效果验证我自己开发一个 Skill 通常分四步走这里以“编写一个 Git 提交信息生成 Skill”为例展开说明。第一步任务拆解。把“生成 Git 提交信息”拆成几个子任务读取 git diff、分析变更类型、识别影响范围、生成符合规范的提交信息。这一步的目的是搞清楚 Skill 内部需要哪些步骤以及每一步的输入输出是什么。第二步设计流程。确定步骤的执行顺序和判断条件。比如先读 diff再判断变更类型是 feat、fix 还是 refactor然后根据类型选择对应的提交信息模板。流程设计得越明确Skill 的稳定性越高。第三步编写模板与脚本。把每一步需要用到的提示词模板写出来必要时配合脚本自动执行。比如读取 diff 可以用 shell 命令生成提交信息可以用专门的提示词模板。这一阶段的核心原则是“能自动化的不要手动能模板化的不要自由发挥”。第四步测试与迭代。用不同类型的历史提交记录反复测试 Skill 的输出效果。我一般会准备三类测试用例常规功能变更、纯重构无功能变化、涉及多文件大规模改动。测试的目的不仅是验证正确性更是观察 Agent 在边界情况下是否会“硬套模板”。Skill 开发最忌讳一步到位。第一个版本能做到“80% 场景下可用”就很好了后续根据实际使用反馈持续迭代。Skill 的价值在于积累你用得越多它越贴近你的真实工作流。3.3 Skill 与 Rules、MCP 的配合姿势热词里有一个搜索量很高的问题“Skills 如何调用 MCP 工具”这说明很多人已经意识到了三层架构之间的关系。我的理解是Skill 负责定义“做事流程”MCP 负责提供“做事工具”。一个 Skill 的流程中可能会在某个步骤需要通过 MCP 调用数据库查询、文件读写或第三方 API。Skill 不需要自己实现这些底层能力它只需要在流程中声明“此处调用 MCP 工具 xxx”剩下的事情由 MCP 层去完成。至于 Rules 在其中扮演的角色更像是一个“监督者”。比如你可以在 Rules 里规定“使用 Skill 生成的内容必须经过自查”或者“调用 MCP 写入操作前必须输出将要修改的数据预览”。这样一来Rules 负责约束行为边界Skill 负责高效完成任务MCP 负责打通外部世界三层各司其职。4. 关键连接层MCP 到底是什么为什么大家都在接4.1 MCP 的“三层结构”与设计初衷MCP 的全称是 Model Context Protocol本质上是一个开放协议用来解决大模型应用接入外部数据和工具时的“N 对 N 连接”问题。在没有 MCP 之前每个 Agent 要接数据库、接设计工具、接文件系统都得单独写适配器而且每个 Agent 的适配器还不能通用。MCP 把这个过程标准化了有点像 USB 接口——设备厂商按标准生产电脑按标准接入谁都不用管对方内部怎么实现。MCP 的架构分三层MCP Host宿主程序、MCP Client客户端、MCP Server服务器。用户直接使用的是 Host比如 Claude Desktop 或支持 MCP 的 IDEHost 内部通过 Client 与 Server 建立连接Server 负责暴露具体工具或资源。理解这三层很重要因为很多问题——比如“为什么我配置了 MCP 但 Agent 看不到工具”——最后定位下来都是三层之间某一环出了问题。从热搜词里可以看到像“Claude Code 安装 MCP 读取数据库”“MasterGo MCP”“Blender MCP”“Unity MCP”这些都是具体场景下的 MCP 实践。它们本质上做的事情一模一样通过 MCP Server 把外部软件的能力暴露给 Agent让 Agent 能直接操作设计稿、3D 模型或数据库表结构。4.2 MCP Server 的核心机制工具、资源与提示词MCP Server 能暴露三种能力理解它们的区别对实际调试非常有帮助。工具Tools是最常用的能力类型代表 Agent 可以主动调用的函数。比如一个数据库 MCP Server 会暴露“执行 SQL 查询”“获取表结构”等工具。Agent 根据用户指令自主决定何时调用调用参数由 Agent 根据上下文生成。资源Resources是 Agent 可以读取的数据比如文件内容、配置信息、项目文档。与工具不同资源通常不需要参数更像是“可读取的知识库”。在某些实现里Agent 会在任务开始时主动扫描可用资源获取与任务相关的上下文。提示词Prompts是预定义的提示词模板用户或 Agent 可以主动触发。这一能力在 RAG 类场景中比较有用比如针对“代码审查”或“数据库优化”场景预置高质量的提示词让 Agent 的输出更贴合特定任务。搞清楚这三者的区别很多问题就能迎刃而解。比如“为什么 Agent 看不到我的数据库表结构”这个经典问题多半是 MCP Server 没有把“获取表结构”暴露成工具或者暴露了但描述写得模糊导致 Agent 不知道什么时候该调用它。4.3 从零搭建一个最简单的 MCP Server文件读写案例废话不多说直接上一个最简单的 MCP Server 搭建过程。我用 Python 的官方 SDK实现一个文件读写服务这也是绝大多数人第一次接 MCP 时最常用的练习场景。先装依赖pip install mcp然后写服务端代码from mcp.server import Server from mcp.server.stdio import run_server from mcp.types import Tool, TextContent import os app Server(file-helper) app.list_tools() async def list_tools(): return [ Tool( nameread_file, description读取指定路径的文本文件内容路径必须是绝对路径, inputSchema{ type: object, properties: { path: {type: string, description: 文件的绝对路径} }, required: [path] } ), Tool( namewrite_file, description将文本内容写入指定文件会覆盖已有内容, inputSchema{ type: object, properties: { path: {type: string, description: 文件的绝对路径}, content: {type: string, description: 要写入的文本内容} }, required: [path, content] } ) ] app.call_tool() async def call_tool(name: str, arguments: dict): if name read_file: try: with open(arguments[path], r, encodingutf-8) as f: content f.read() return [TextContent(typetext, textcontent)] except Exception as e: return [TextContent(typetext, textf读取失败: {str(e)})] if name write_file: try: with open(arguments[path], w, encodingutf-8) as f: f.write(arguments[content]) return [TextContent(typetext, textf写入成功: {arguments[path]})] except Exception as e: return [TextContent(typetext, textf写入失败: {str(e)}]) return [TextContent(typetext, textf未知工具: {name})] if __name__ __main__: run_server(app)这段代码做的事情很直白定义了一个叫file-helper的 MCP Server暴露两个工具——读文件和写文件。每个工具都声明了参数格式和描述信息。把这段代码存成server.py直接运行python server.py此时程序会在标准输入输出上监听 MCP 协议消息。要让它真正被 Agent 使用还需要在 Host 端配置文件里注册这个 Server。不同 Host 的配置格式略有不同但核心都是三个字段command启动命令、args启动参数、env环境变量。这里我强烈建议初学者先跑通这个最小示例再去折腾数据库 MCP、设计稿 MCP 这类复杂场景。因为文件读写 MCP 的链路最短出了问题容易定位。等你理解了“Host 怎么发现工具—Agent 怎么决定调用—Server 怎么执行返回”这条完整链路再去看其他 MCP Server 的源码基本十分钟就能看懂。4.4 工具描述的质量直接决定 Agent 的调用准确率MCP Server 开发中有一个容易被忽视但极其重要的细节工具描述description的写法。我见过太多人把工具描述写得特别简单比如“读取文件”结果 Agent 在复杂场景下根本不知道什么时候该用它或者把参数填得乱七八糟。好的工具描述应该包含三个要素这个工具是干什么的、什么场景下使用、参数要注意什么。举例对比一下差的描述读取文件好的描述读取指定路径的文本文件内容适用于需要查看配置、日志或源码的场景。路径必须是绝对路径支持常见文本编码格式。第二种写法给 Agent 提供了足够的决策信息它会更准确地判断调用时机。这一点在接多个 MCP Server 时尤其重要——你的 Server 越多工具越多Agent 的“选择困难症”就越严重描述写得清楚就是在帮它做选择题。5. 案例实战从设计稿到代码再到 3D 场景MCP 的三种典型玩法5.1 设计协作场景蓝湖/MasterGo MCP 的价值热词里“cursor 连接蓝湖 MCP”“MasterGo MCP”“figma 插件 open figma mcp”出现频率非常高。这类 MCP 解决的是前端开发里一个老生常谈的痛点设计稿到代码的转换。以前前端工程师拿到设计稿要么对着 Figma 手动量尺寸、取色值、导出切图要么用插件生成粗略的代码。整个过程高度依赖人工而且容易走样。接上蓝湖或 MasterGo 的 MCP Server 之后Agent 可以直接读取画布上的元素信息——坐标、尺寸、颜色、字体、间距——然后生成还原度更高的前端代码。这里最值得一提的不是技术难度而是“交互范式的转变”。以前是人去找设计稿信息然后翻译成代码现在是 Agent 自己通过 MCP 工具获取设计稿信息再产出代码人只负责审查结果。这种转变让我对 MCP 的价值有了更深的理解它不只是给 Agent 加了一个 API而是重新定义了人机协作的分工边界。5.2 3D 开发场景Blender MCP 与 Unity MCP 的想象力另一个让我觉得特别惊艳的方向是 3D 工具链接入 MCP。热词里出现了“blender mcp”“unity mcp”这两个工具体量都很大以前想用自然语言控制它们几乎是不可能的事。接了 MCP 之后Agent 可以做到一些很惊人的操作在 Blender 里创建、修改、删除物体调整材质参数、灯光位置、摄像机角度在 Unity 里创建场景对象、修改 Transform 组件、查询资源目录。我在一个测试项目里试过用自然语言让 Agent 在 Blender 里搭一个简单的场景“创建一个地面平面在中央放一个球体左侧放一个立方体给球体红色材质给立方体蓝色材质然后用摄像机对准球体正面 30 度角。”Agent 通过 Blender MCP 逐个调用工具最终确实渲染出了符合描述的简单场景。这个过程最让我震撼的不是 Agent 能操作 Blender而是它面对一个复杂三维软件时能自己规划操作顺序、选择正确的 API、处理中间失败。当然这背后少不了 Rules 的克制和 Skill 的流程引导——如果让它完全自由发挥它大概率会乱来。5.3 数据处理场景Cocos Creator MCP、Matlab MCP 与数学建模热词里数学建模、Matlab MCP、Cocos Creator MCP 的出现说明 MCP 正在渗透进各个专业工具领域。以数学建模为例以前写论文里的公式推导、图表绘制、模型求解都需要人在 Matlab 或 Python 里手动完成一段段代码。有了 MCP 之后Agent 可以在对话中直接调用 Matlab 执行计算然后把结果以文本或图片形式返回。这类场景的一个共性特点是工具的专业性强普通提示词根本没法让 Agent 学会用。所以 Skill 在这里的作用更为重要——你需要提前把“如何用 Matlab 求解线性规划”“如何绘制论文插图”这类领域的操作流程固化下来配上示例代码Agent 才能真正高效地调用 MCP 工具。我个人的体会是MCP 的生态正在按“专业工具软件”为单位快速铺开。每一个 MCP Server 的诞生本质上都是把一款软件的操作能力翻译成了统一的 Agent 可调用接口。短期看是“自然语言控制软件”长期看可能就是“AI 重构软件使用方式”。6. 实操中常见的坑MCP、Skill 与 Rules 的问题排查实录6.1 工具选型与版本匹配问题先聊一个最基础但最容易踩的坑版本匹配。MCP 的协议还在快速演进中SDK 版本、Host 版本、Server 版本三者之间的兼容性问题远比想象中频繁。你们如果搜“mcp server”“mcp 服务 demo”会看到大量教程推荐不同版本的安装方式但照着做经常出问题。我的建议是在项目初期固定所有相关依赖的版本号不要盲目追新升级任何一个组件之前先查官方仓库的 changelog确认兼容性遇到莫名其妙的行为异常优先怀疑版本匹配问题而不是功能逻辑问题。6.2 Agent 找不到工具或调用失败先看三个地方“我配置了 MCP Server但 Agent 说没有可用工具”——这是我在社区里看到最多的求助帖。遇到这种情况我一般按三步排查第一步确认 Server 能独立启动。先把 MCP Server 单独跑起来看能不能正常启动、是否会报错。如果启动就失败后面的问题都无从谈起。第二步确认 Host 正确加载了 Server。在 Host 设置界面查看 MCP Server 状态是否显示“已连接”。很多配置问题表现为“进程启动了但握手失败”这种情况多半是协议版本不一致或者环境变量没配好。第三步确认工具描述对 Agent 可见。即使 Server 连接成功Agent 也需要通过工具列表来发现可用能力。如果你的工具描述写得含糊Agent 可能“看不到”或“不想用”。这一步很多人会忽略但恰恰是调整空间最大的地方。6.3 配置了 MCP 后Safety 与权限管理接入 MCP 就像给 Agent 装了一双可以触及真实世界的手——这双手既能让它帮我们高效干活也可能造成破坏。比如文件读写 MCP 如果不做路径限制Agent 在收到恶意或错误指令时有可能删掉重要文件数据库 MCP 如果不加写权限控制Agent 可能执行危险 SQL。所以我的建议是MCP Server 的权限设计一定要遵循最小化原则。Server 暴露的工具越少越好每个工具的权限范围越窄越好。以文件读写 Server 为例至少应该做到限定可访问的根目录禁止越界访问删除操作单独暴露或完全不暴露写入操作记录日志方便事后审计。这套权限隔离的思路同样适用于 Rules 层面在项目 Rules 里加上“所有通过 MCP 工具执行的写操作必须先在回复中展示将要修改的内容和影响范围等待用户确认后再执行”。Rules 加 MCP 的组合能有效避免大部分误操作。6.4 Skill 与 Rules 冲突时的优先级处理当 Skill 和 Rules 都越来越庞大的时候冲突几乎是不可避免的。比如某个 Skill 的流程要求自动执行测试并修复所有失败用例但项目 Rules 规定“测试失败时不得直接修改代码必须向用户汇报”。这时候听谁的我的解决思路是在 Rules 中建立冲突仲裁机制而不是试图消除所有冲突。具体来说在 Rules 里声明优先级规则比如“当 Skill 流程与 Rules 发生冲突时以 Rules 为准但 Skill 中明确标注为‘硬性要求’的步骤除外”。这样既保留了 Skill 的灵活性又守住了 Rules 的底线。6.5 实战排查流程一个真实示例最后分享一个我最近实际处理的排查案例。当时接了一个数据库查询 MCP Server但 Agent 总是回答“我没有权限访问数据库信息”。检查步骤如下单独启动 Server确认能正常响应工具调用检查 Host 的 MCP 配置发现环境变量DATABASE_URL没有传递给 Server 进程在配置中补上环境变量后重启Server 能正常连接数据库了但 Agent 依然不调用工具进一步检查发现工具描述写得过于简略Agent 不知道这个工具的适用场景重写工具描述明确提示“当用户询问订单量、用户数等数据库信息时使用此工具”重启后一切正常。这个案例非常有代表性整个过程没有一处是“高深的技术难题”全是沟通和配置层面的细节问题。但正是这些细节决定了 MCP 能不能真正发挥价值。7. 一些经验沉淀把三层架构跑通之后我的几点体会到这边Skill、Rules、MCP 三个概念本身的内容基本讲完了。我想在最后聊几句这些年摸爬滚打攒下来的心得体会算是我个人对这套体系的理解沉淀。第一三者必须一起设计不能各搞各的。最理想的做法是在项目启动初期先定义好 Rules 的底线约束然后基于具体任务拆解 Skill最后根据 Skill 的实际需要接入 MCP 工具。顺序反了的话很容易出现接了 MCP 但 Agent 不知道何时调用、写了 Skill 但被 Rules 卡住之类的尴尬局面。第二日志和可观测性是排查一切问题的基础。无论你用的是现成的 MCP 框架还是自己写的协议层一定要确保每一步操作都有日志可查。很多看似“Agent 智能不足”的问题翻日志之后发现其实是上下文信息缺漏或参数传递错误。没有日志你只能靠猜而猜是最浪费时间的方式。第三从热词里能看到一个趋势越来越多垂直领域的工具在接入 MCPSkill 的开发也在向专业化、体系化发展。这意味着“AI 应用开发”这件事本身也在发生范式转变——以前是写代码让 AI 干活未来可能变成了“配置 AI 的能力边界让它自己调动工具干活”。作为一个从业者我建议尽早熟悉这套玩法尤其是 Skill 的开发方法和 MCP 的协议机制。等你的工作流真正跑通了一次“Rules 定边界、Skill 给流程、MCP 通外部”的完整闭环之后你对 AI Agent 的理解会发生一次质变。最后再分享一个小技巧无论是写 Rules 还是开发 Skill保留第一版草稿每迭代一版就对比一次效果差异。我做过很多次“优化”结果发现核心逻辑没变只是把描述写得更花哨了反而增加了 Agent 的理解负担。好的 Rules 和 Skill 是克制而精准的不是越多越好、越长越好——这一点可能是整套体系里最反直觉但最重要的一条经验。