Agent开发四要素：Skills、Rules、Prompt与MCP的分工协作体系

在工作中，我把这句话讲给不少人听过：Agent Skills、Rules、Prompt、MCP，它们不是四个需要“二选一”的技术选型，而是一套需要同时理解的分工体系。一旦你把四者各自管什么、互相怎么配合弄清楚，后面不管是搭一个简单的自动回复机器人，还是做一个多工具调度的复杂Agent，思路都会顺很多。

这篇文章就是冲着“理清楚”去的。我先讲整体设计思路，再把Skills与MCP、Rules与Prompt两组最容易混淆的概念拆开对比，最后给出一套可以照着做的落地流程和故障排查方法。适合正在做Agent应用开发、做技术选型，或者被这几个概念绕晕的读者。

1. 整体设计思路：为什么这四件事会被同时摆上台面

1.1 一个日常场景看四类机制的差别

假设你现在有一个“助手Agent”，它收到的任务是：“帮我整理本周工作周报，并翻译成英文发给老板。”

如果你只写一段Prompt，会发现在很长一段时间里，Agent确实能完成这件事，但每次完成的格式都不太一样：有时直接输出英文，有时先给中文再给英文，有时把翻译结果放在代码块里，老板打开看到一堆反引号。

这时候你会想：能不能让“翻译成英文”变成Agent一定会做的一个固定动作？这就是Skills能解决的场景。你把“周报翻译”拆成一个技能，定义好输入（中文周报）、步骤（分段翻译、检查术语、输出英文）和最终格式，Agent在遇到同类需求时，会主动调用这个技能，而不是每次都“自由发挥”。

再往下走，如果这个Agent需要真正访问某个外部系统，比如查询内部工时数据、向某个项目管理软件提交内容，那就不是Prompt和Skills能覆盖的了。你需要通过MCP服务去连接外部系统，让Agent拥有“调外部工具”的能力。MCP解决的是“Agent怎么与外部世界对话”的问题。

而Rules负责给整个过程布置“红线”。比如“周报中不允许出现客户敏感信息”“翻译时不得改变数字精度”“所有输出必须使用Markdown格式”。Rules不负责告诉Agent怎么做事，只负责限制Agent不能越界。

就这么一个场景，四类机制全部上场了：Prompt描述目标与路径，Skills提供做事步骤，MCP打通外部工具，Rules约束行为边界。它们的配合关系大体是：Rules管边界，Prompt管表达，Skills管内化能力，MCP管外部连接。

1.2 四者的协作关系与常见误区

我接触过不少开发者，最容易犯的误区是：把所有想让Agent做的事情都塞进Prompt，等到Prompt长到几千字、模型开始“记不住前面要求”之后，才回头找结构化的办法。

Prompt并不是越长越好。模型的注意力窗口虽然是连续的，但生效强度会衰减。你让Agent记住“一共十条规定”，不如把其中三条真正重要的“不可协商条款”写进Rules，再把操作流程切分成Skills，让Agent一步步执行。这样Prompt反而可以短下来，只承担“交代本次任务的背景、目标、偏好”这一层。

另一个误区是把MCP当成Skills的替代品。Skills是Agent自身的能力沉淀，它不依赖外部服务；MCP是Agent和外部服务之间的管道。一个擅长写代码的Agent，它的“代码生成”能力来自Skills；而它如果要调用某个云平台API来部署代码，走的才是MCP。两者不是竞争关系，而是“内功”和“兵器”的关系。

所以我倾向于用一张拆解图去理解：

• Rules：不可协商的约束，永远是最高优先级。
• Skills：可复用、可组合的步骤集合，Agent自己的“肌肉记忆”。
• Prompt：当前这轮任务的目标和上下文表达，负责“说清楚这次要干什么”。
• MCP：外部工具和数据的统一接入层，由Agent按需使用。

这四者的优先级从高到低是：Rules > Skills + MCP > Prompt。当用户指令与Rules冲突时，Rules必须赢；当Prompt描述过于模糊，而某个Skills恰好吃这个场景时，Agent可以直接触发Skills，不必每次都等Prompt给全所有细节。

2. 核心机制解析：Skills与MCP，两个“执行层”的边界与配合

2.1 Skills：写给Agent自己的操作手册

你可以在脑海中把Skills想象成一份“作业指导书”。它不是给最终用户看的，也不是给程序员看的，而是给Agent模型看的结构化文档。它有名字、有描述、有触发条件、有执行步骤，有时候还带几个示例。当Agent判断当前任务和某个技能描述匹配时，它就会“翻出”这份指导书，按步骤执行。

Skills的价值有三点：

第一，解决“模型每次表现不稳定”的问题。不写Skill时，Agent每次都是临场发挥，类似让一个新人凭感觉处理问题；写完Skill后，Agent每次执行都像老员工照着SOP走，输出质量下限明显提高。

第二，解决“长指令失效”的问题。把大量步骤拆到一个Skill里，Prompt里只写“用周报技能处理”，模型在需要时再展开技能内容，注意力负担小得多。

第三，解决“能力复用”的问题。一套技能可以服务多个场景。比如“调用搜索并总结”这个Skills，既可以被“写行业分析”用，也可以被“查资料写邮件”用，被不同任务共享。

以一个“报告摘要技能”为例，描述部分可以这样组织：

{ "name": "report_summarizer", "description": "当用户提供长文档或链接时，提取核心观点并生成300字以内摘要", "instructions": [ "1. 获取输入文档内容", "2. 提取中心论点与三个支撑论据", "3. 忽略铺陈和重复信息", "4. 按'观点+论据'结构输出" ], "max_output_tokens": 350 }

这不是唯一标准，但体现了一种思路：让Agent知道“什么时候用”“用了之后怎么做”“做到什么程度停”。这个结构的价值比写上几百字复杂的自然语言描述要高得多，因为它具备条件判断和执行边界。

2.2 MCP：打开外部世界的统一管道

MCP解决的问题，一句话可以概括为：让Agent不需要为每个外部工具写一套专属调用方式，而是通过一套标准协议，去发现工具、调用工具、接收结果。

打个比方：Skills是Agent自己掌握的厨艺，MCP是厨房里那些“接上水电燃气就能用的标准接口”。只要接口是标准的，不管是煤气灶还是电磁炉，插上去就能用。开发者不需要为每个燃气品牌写一套对接逻辑。

MCP服务器一般会暴露三类能力：

• 工具（Tools）：可执行的动作，比如“查询气温API”“创建工单”“发送消息”；
• 资源（Resources）：可读取的数据，比如“某个数据库的表结构”“某个项目的配置文件”；
• 提示（Prompts）：可复用的提示模板，解决不同客户端之间提示片段复用的问题。

通过这三类能力，Agent可以通过MCP完成“查数据-做决策-执行动作”的闭环。例如在一个“故障报修助手”里，MCP服务提供“读取设备状态”资源和“创建维修工单”工具，Agent先查资源，再判断是否需要创建工单，一旦需要就去调用工具。整个过程用户只接触对话界面，底层全走MCP。

我实测下来最明显的感受是：MCP让Agent的能力范围从“模型知识截止日期之前”延伸到“当前真实世界的数据与操作”。但这同时也带来了新问题：外部工具返回的数据格式、错误码、权限限制，都需要Agent在运行时做判断。如果工具返回了“403无权限”，Agent能不能正确解读，取决于你在MCP工具描述里是否写清楚了返回值和错误语义。这部分非常考验设计者，不能指望模型“天生会处理”。

2.3 什么时候用Skills，什么时候接MCP

我在实际设计系统的时候，会先做一个判断：“这个能力是Agent自己就能完成的，还是必须要外部系统配合？”

如果Agent不依赖外部系统、只靠模型本身就能完成，比如信息整理、文本润色、格式转换、代码生成，那优先考虑做成Skills。它的优势是稳定、轻量、不依赖网络和第三方服务。

如果任务必须读取外部数据或触发外部操作，例如查询实时库存、发送邮件、调用某个内部办公系统的API，那么就需要通过MCP接入。MCP在这里的不可替代性在于：Agent不仅需要“知道”流程，还需要“执行”真实操作。

一个容易出现的坑是：大家喜欢把“需要调用API”就直接列入Skill步骤，指望模型去猜API怎么调。结果模型给出了不存在的参数格式、错误认证方式，甚至编造接口文档。正确做法是，API调用统一放到MCP服务层，Skills只负责编排“做什么”，MCP负责“怎么连”。两者配合，各司其职。

3. 行为约束与表达方式：Rules和Prompt的双层结构

3.1 Rules：不可协商的底线

Rules解决的是“绝对不能做什么”和“必须总是做什么”这两类问题。它的特点是稳定、全局、静态，不会因为某一次任务不同而改变。

例如在面向某个垂直行业的Agent产品中，Rules可能会包含：

• 不编造数据。没有来源支撑的信息，必须明确回答“未找到可靠数据”；
• 不执行删除类操作。凡是涉及删除、清空、重置的指令，必须先与用户二次确认；
• 输出中必须保留原文中所有数字和单位，任何换算必须在括号中备注；
• 回答医疗、金融类问题时，必须附加风险提示与“请咨询专业人士”字样。

这些内容如果全部写进Prompt，每次调用都要占用大量上下文窗口，还可能出现“模型注意力漂移”导致漏遵守。把它们提取为Rules之后，系统可以更高优先级的方式注入，甚至可以配置为不可被用户指令覆盖。在工程上，一部分框架支持在系统层单独配置“不可违反的规则”，优先于任何用户Prompt。

我个人的习惯是：Rules的数量控制在五条以内。超过五条，模型遵守的概率会明显下降。如果真的有很多边界要求，可以归并同类项，或者考虑拆成多个Agent场景，而不是把一堆规则压在一个系统里。

3.2 Prompt：为当前这一轮任务做定制表达

Prompt和Rules最大的区别是：Prompt通常是临时的、具体的、场景相关的，它需要回答“这一次，用户到底想让我干什么”。

一个有效的Prompt通常包含六个部分：

• 角色：你是什么身份。例如“你是一名周报编辑助手”。
• 背景：为什么会有这个任务。例如“用户本周有三场会议和一次客户拜访”。
• 任务：明确要交付什么。例如“把会议纪要和拜访记录整理成一份中英双语周报”。
• 约束：这次任务的独特限制。例如“每段不超过五十字”。
• 示例：给出一段“标准答案”样例，帮助模型理解你想要的风格。
• 输出格式：说明交付结构。例如“开头一句话总结，然后按项目列要点”。

这六部分不一定每次全上，但背景和任务至少要清晰。模型不是读心机器，你不说清楚“这次为什么做”，它只能靠猜，猜的准确率就打了折扣。

我在写Prompt时特别注意一个地方：不要把Rules反复重申。有些开发者喜欢在Prompt里把禁止事项重复三遍，结果Rules和Prompt打架，模型反而迷糊。正确做法是：Rules放在系统级，Prompt里只写“跟本次任务相关”的新增要求。只有出现“本次特殊需要覆盖常规规则”的场景时，才在Prompt里明确说明，并设置优先级标记。

3.3 优先级冲突时，谁说了算

实际运行中会发生这种情况：用户说“帮我把所有数据都换成美元汇率来显示”，而Rules规定“展示必须保留原始币种，换算必须标注”。这时系统应该怎么表现？

正确答案是：Rules胜出，Agent应该拒绝“只显示美元”的要求，并解释：我可以换算并同时显示美元和原始币种。这里的“拒绝”不是对抗用户，而是维护产品底线。尤其是金融、医疗、法务等场景，一旦模型为了讨好用户而违反底线，后果会很难收拾。

另一种冲突是Prompt与Skills的冲突：用户让Agent“不要调用搜索技能，直接凭记忆回答”，同时某个Skills默认会在不确定时调用搜索。这种情况我会做一个可配置的策略：允许用户显式禁用某项技能。但必须在Rules层面保证“如果回答涉及时效性极强的数据，即便用户禁用搜索，也必须声明‘此回答未经实时验证’”。

处理冲突的通用原则是：安全类Rule最高，业务类Rule其次，Skills建议再次，最后才是Prompt。虽然不可能做到绝对通用，但作为默认优先级，它能让大多数场景的行为保持一致。

4. 实操过程与落地路径：从概念到可运行的四步法

4.1 落地前的“四问”决策清单

在任何一个新Agent任务上线前，我会先在文档里做一轮拆解。拆解的核心是提四个问题：

• 这个任务是否高频？如果用户每周都会用同一种方式处理同类内容，那就值得沉淀为Skills。
• 这个任务是否需要外部数据或操作？如果是，就需要MCP，而不是在Prompt里硬编API参数。
• 这个任务有哪些不可触碰的边界？比如敏感词、数据格式、隐私限制，这些写进Rules。
• 这个任务是否每次都有不同要求？如果是，那Prompt负责接收变化部分，而不是把变化写死在Skills里。

这四个问题问完之后，再动手搭建，思路会非常明确。我见过不少反例：先找了一堆Prompt模板，改了几十个版本，最后发现要解决的问题根本不在Prompt层，而是对外数据获取不稳定，这就等于一直在错误楼层装修。

4.2 一个完整的设计实例：旅行规划Agent

举个例子，假设我们要做一个“行程规划Agent”，用户输入出发地和天数，Agent给出完整行程建议。听起来很简单，但真正实现时四类机制全部用上了。

Rule层写死三条：不编造航班时间和酒店价格，凡是具体价格和时段信息必须标注“需以官网实时数据为准”；涉及夜间行程必须自动加入安全提示；每次回答必须给出至少两个备选方案。

Skill层做一个“行程生成”技能，步骤包括：提取用户偏好，按主题分类目的地，为每一天分配上午、下午、晚上三个时段，输出包含预算级别的行程表。这个技能可以被“一日游”“多日游”“亲子游”等不同任务共用。

MCP层接入两个服务：一个提供景区开放时间与门票信息，一个提供当地天气预报。Agent在生成行程前，先通过MCP获取这些实时数据，再写进行程计划。

Prompt层只负责接收本次会话的用户意图：目的地、天数、交通偏好、同行人员等。它不需要知道“怎么定行程”，那部分是Skill的职责，它只需要说清楚“这次想玩什么”。

这样一个完整系统跑起来之后，用户感受到的是一个“有常识、守规矩、能给实时建议”的助手。而从开发者角度看，每个层面都可以独立修改、独立测试。如果发现“行程生成质量不行”，我会先看Skill的步骤和示例，而不是去改MCP配置；如果发现“Agent偶尔编造酒店价格”，那说明Rule没生效，要检查规则注入是否正确。

4.3 最小可用原则：从一层开始，而不是全面铺开

很多人在刚开始做Agent时，容易被“全部上四件套”的想法带着走。我的建议是：能用一层解决，就不要上四层。

如果你只做一个“会议纪要整理”的简单工具，也许只需要一个好Prompt就够了，上Skills反而增加复杂度。当你发现同一个过程要被反复使用、输出格式始终不稳定时，再把相关步骤提练成Skills。等你需要读外部数据、操作外部系统时，才去接MCP。而Rules，我建议从第一天就建立，哪怕只有三条，因为后面再补规则总会有遗漏。

这也是所谓“演进式架构”的思路：每一层都有切入时机，不要提前设计过度。我见过有些项目在最开始就接了六个MCP服务，看着功能很强，实际上六个服务中有四个在真实业务里根本用不上，还增加了启动时间和故障点。

正确的做法是先跑通最小链路，再逐步增加能力。比如旅行规划Agent的第一版可以先用Rules + Prompt跑通流程，输出一份纯文本行程；第二版再引入Skills来固定格式；第三版接上MCP获取实时天气。每一步都小到可以快速验证，出了问题也容易定位。

5. 常见问题与排查技巧实录：真实环境里踩过的坑

5.1 高频故障速查表

下面整理了一些我在实践中反复遇到的典型问题，以及对应的排查思路。这套速查表适用于大多数基于大模型开发的Agent应用。

这张表的特点是：每个现象都指向“层”的错配。排错时不要只看表层，而是先定位问题发生在哪一层，再对症下药。

5.2 两个独家排查技巧

第一个技巧我称之为“规则优先级测试法”。当你不确定某一条约束到底有没有生效时，不要直接问“你会遵守吗”，而是构造一个测试用例去触发冲突。例如，如果我想确认“不允许编造航班价格”这条Rule是否真的起作用，我会让Agent去回答一个它不可能知道价格的航班，看看它会不会给出具体数字。如果它直接编了一个价格，说明Rule没有生效；如果它拒绝并给出“请以官网实时信息为准”，那Rule生效了。这个方法比空泛地问“你的规则是什么”要可靠得多，因为模型在抽象层面往往会说“我会遵守”，但在具体执行时不一定能贯彻。

第二个技巧是“日志行为溯源法”。很多Agent框架会输出内部的详细日志，包括模型的思考片段、调用了哪些工具、触发了哪些技能。遇到奇怪输出时，我会先把日志翻出来，判断这次结果是由哪一层主导的。如果是Skills主导，但输出表现不对，那就是技能定义有问题；如果是MCP返回的内容本身有误，那问题在服务端，而不是模型。不用日志就盲目改Prompt，是排查问题时的第一大忌。

5.3 防止“技能库膨胀”与“规则倦怠”

最后分享一个长期维护层面的经验。随着Agent功能不断叠加，Skills的数量会越来越多，可能几百个。这时候模型每次做“技能检索”的难度也在增加，经常出现“明明有某个技能，但模型没找到”的情况。解决方式有两个：一是在技能描述里增加高频同义词与场景短语；二是做技能分组，把相近技能放到同一个索引目录下，减少模型需要检索的候选数。

Rules同样存在“规则倦怠”问题。当规则数量过多或相似度过高时，模型对规则的敏感度就会下降。我的做法是：每隔一段时间就复盘一次Rules，把已经不再是底线的条款删掉，把重复的合并，确保最终留存下来的，都是“违反后果极其严重”的条目。

还有一个小细节：不要紧抱着一套系统配置不放。不同模型版本对指令的遵循能力有差异，换模型后必须重新验证Rules和Skills的效果。我曾经在旧模型上表现完美的技能，换到一个新模型后反而触发率下降了不少，原因是新模型的思维方式更偏“整体理解”而不是“逐步遵循”，后来调整了技能描述结构才恢复稳定。

6. 独立判断与经验沉淀：我如何从“能用”走到“好用”

前面讲了一大堆机制、结构和流程，可能看起来很系统，但真正让我觉得“这四件事理清楚了”的标志并不是能背出概念，而是能在一开始就对“哪个问题该用哪个机制解决”形成直觉。

根据我自己的经验，形成这种直觉需要刻意练习。每次遇到Agent行为不符合预期时，不要急着改代码或改Prompt，而是先写下这个问题属于哪一类：是边界被突破？是能力没触发？是外部信息缺失？还是目标表述不清？坚持做这样的分类，大约经过十来个case之后，你就不再会被“模型太笨”这类笼统的抱怨牵着走了。

还有一点关于工具选型的体会：很多人会花很多时间在不同Agent框架和模型API之间比较，反而忽略了底层架构设计的训练。框架换起来很快，可机制没搭对，换什么都一样。Rules写得一团糟、Skills没有沉淀、MCP工具描述全靠模型猜，这些问题跟用哪个模型没有关系。

所以我会建议新手从“最小但完整”的项目做起：一个场景，三条规则，一个复合技能，一个外部数据接口。把这件事完整跑通，再去扩展。你会在做的过程中慢慢明白，为什么Rules要剥离出来，为什么步骤级能力要进入Skills，为什么外部调用要统一走协议层。这些体验不是读文档能替代的。

Skills、Rules、Prompt、MCP这四个概念，单独拎出来任何一项都有大量文档可查，但真正把它们协作起来用，才是从“调接口”走向“做产品”的关键一步。希望这篇文章能帮你把那层窗户纸捅破。