普通视图

发现新文章,点击刷新页面。
昨天 — 2026年3月15日首页

Agent Skill 和 Rules 有什么区别?

作者 JacksonChen
2026年3月15日 16:39

用过 Cursor 或者 Claude 的人对 Rules 应该不陌生——在设置里写几条规则,AI 就会按你的要求来。

那它和 Agent Skill 有什么不同?我见过不少人把这两个混用,或者干脆不知道该用哪个。

Rules 是什么

Rules 就是约束条件,告诉 Agent "你必须怎样,不能怎样"。

比如:

- 回复必须用中文
- 代码注释不能用英文
- 不要使用 var,统一用 const/let
- 每次修改代码后,提醒我写单元测试

Rules 的特点是全局生效,只要在对话范围内,每一次交互都受它约束。它不是在教 Agent 怎么完成某件事,而是在限定 Agent 的行为边界。

Agent Skill 是什么

Skill 是执行方法,告诉 Agent "这件事应该怎么做"。

同样是 Code Review 场景:

## Code Review 执行指南
1. 优先检查安全漏洞,标记 [HIGH]
2. 检查边界条件和空值处理
3. 评估性能问题
4. 输出格式:问题 + 等级 + 修改建议

Skill 是按需触发的,用户发起相关任务时才加载进上下文,完成后卸载。

核心区别

Rules 管边界,Skill 管方法。

Rules Agent Skill
本质 约束 / 行为准则 执行方法 / 操作流程
生效范围 全局,始终有效 按需,任务触发时加载
解决什么 Agent 该怎么"做人" Agent 该怎么"做事"
类比 公司规章制度 岗位工作手册

同一场景,两者分工不同

还是代码助手的例子:

Rules 负责的部分:

- 所有建议必须附带代码示例
- 不要直接帮用户改代码,先说明问题让用户自己改
- 回复保持简洁,不要长篇大论

这些是行为约束,不管 Agent 在做什么任务,都要遵守。

Skill 负责的部分:

Code Review 时:先查安全 → 再查逻辑 → 再查性能 → 按模板输出报告

这是执行流程,只在做 Code Review 这件具体任务时才生效。

两者叠加的效果:Agent 做 Code Review,按 Skill 定义的流程走,同时遵守 Rules 里"必须附带代码示例"和"保持简洁"的约束。


什么时候用 Rules,什么时候用 Skill

用 Rules:

  • 希望 Agent 在所有场景下保持某种风格或约束
  • 涉及输出格式、语言、态度等通用行为
  • 内容简短,几条原则就能说清楚

用 Skill:

  • 某类任务有明确的执行步骤和质量标准
  • 不同任务之间的执行逻辑差异很大
  • 执行内容较重,不适合一直挂在上下文里

一个判断方法:如果这件事对所有任务都适用,写进 Rules;如果只在特定任务里才需要,封装成 Skill。

常见的混用错误

把执行流程塞进 Rules:

# 错误示范
Rules:
- 做 Code Review 时,先检查安全漏洞,再检查逻辑问题,
  再检查性能,最后输出报告,报告格式为……(一大段)

这段内容只在 Code Review 时有用,却全局常驻在上下文里,纯属浪费 token,应该封装成 Skill。

把约束写进 Skill:

# 错误示范
code-review Skill instruction:
- 回复必须用中文
- 保持简洁
- 不要直接帮用户改代码

这些是通用行为约束,不只 Code Review 需要,应该写进 Rules 全局生效。

总结

  • Rules:全局约束,管的是 Agent 的行为边界,始终生效
  • Skill:执行方法,管的是具体任务怎么做,按需加载
  • 两者不冲突,配合使用——Rules 定底线,Skill 定打法

设计 Agent 系统时,把该全局的放 Rules,把该按需的封 Skill,结构会清晰很多。

昨天以前首页

Agent Skill 和 MCP 到底有什么区别?很多人搞混了

作者 JacksonChen
2026年3月14日 21:38

这两个概念最近出现频率都很高,而且经常被放在一起讨论,容易让人觉得它们是同一类东西。

但其实它们解决的是两个不同层面的问题。

先说 MCP 是什么

MCP 是 Anthropic 推出的一个开放协议,解决的是"AI 模型怎么标准化地连接外部工具和数据源"这个问题。

在 MCP 出现之前,每个 AI 应用要接入外部工具,都得自己写一套对接逻辑。接 GitHub 一套写法,接 Slack 又一套,接数据库再一套,重复劳动,而且互不兼容。

MCP 做的事情是:定一个标准接口,工具提供方按这个标准暴露能力,AI 应用按这个标准来调用,双方对上就能用。

你可以把 MCP 理解成 AI 世界的 USB 接口——统一了插头标准,设备不用管是什么品牌的电脑,插上就能用。

再说 Agent Skill 是什么

Agent Skill 解决的是另一个问题:Agent 自身的执行能力怎么组织和管理。

它是一种架构设计,把 Agent 的各种执行能力拆成独立的技能包,每个技能包含三层:

  • Metadata:描述这个技能是什么、什么时候用
  • Instruction:具体告诉 Agent 怎么执行这个任务
  • Resources:执行时按需加载的外部资源

核心目的是:让 Context Window 里只出现当前任务需要的内容,避免把所有能力一股脑塞进 Prompt 导致执行飘移。

两者的本质区别

一句话区分:

MCP 管的是"能连什么",Agent Skill 管的是"怎么做事"。

展开来说:

MCP Agent Skill
解决什么问题 工具连接的标准化 执行能力的结构化管理
核心角色 协议 / 接口标准 架构设计模式
关注点 我能调用哪些外部能力 我怎么组织自己的执行逻辑
类比 USB 接口标准 工作手册 / SOP

用一个场景感受区别

假设你在开发一个 AI 代码助手,需要它能读取 GitHub 上的代码,然后做 Code Review。

MCP 负责的部分:
怎么连上 GitHub?通过 MCP,GitHub 提供了标准化的 MCP Server,你的 Agent 直接接入,就能调用"读取仓库文件"、"获取 PR 详情"等能力。这一层解决的是连接问题

Agent Skill 负责的部分:
拿到代码之后,Agent 怎么做 Review?按什么维度审查?输出什么格式?这些执行逻辑封装在 code-review 这个 Skill 的 Instruction 里,需要的时候加载进来,指导 Agent 完成任务。这一层解决的是执行问题

两者在这个场景里是配合关系:MCP 把数据取回来,Skill 告诉 Agent 拿着这些数据该怎么办。

它们可以组合使用

这是很多人没意识到的一点——Agent Skill 的 Resources 层,完全可以挂载通过 MCP 连接的外部工具。

code-review Skill
├── metadata.yaml
├── instruction.md          ← 告诉 Agent 怎么审查代码
└── resources/
    ├── security_rules.json
    └── github_mcp_tool     ← 通过 MCP 连接的 GitHub 工具

Skill 定义了"做什么、怎么做",MCP 提供了"用什么工具去做"。

总结

  • MCP 是协议层,解决 AI 和外部世界的连接标准化问题,让工具接入变得可复用、可互操作
  • Agent Skill 是架构层,解决 Agent 自身执行能力的组织问题,让复杂任务的处理更稳定、更可维护
  • 两者不是竞争关系,而是不同层次的解决方案,实际项目里经常组合使用

如果你在做 Agent 开发,MCP 帮你解决"接什么",Skill 帮你解决"怎么做",搞清楚这个分工,架构设计会清晰很多。

Agent Skill 是什么?

作者 JacksonChen
2026年3月8日 18:11

做 Agent 开发一段时间后,大部分人都会遇到同一个问题:

Prompt 越写越长,模型执行越来越飘。

你把所有规范、流程、示例一股脑塞进系统 Prompt,token 蹭蹭涨,模型的注意力却被稀释了——它在"同时看着"几十件事,结果每件事都做得不够准。

Agent Skill 就是在解决这个问题。

核心思路:按需加载

把不同能力拆成独立的"技能包",Agent 根据当前任务,只加载需要的那一个。

就像你电脑装了几十个软件,但你只打开当前要用的那个,其他的不占内存。

Context Window 就是 Agent 的"内存",留给当前任务的空间越干净,执行越稳定。

一个 Skill 的三层结构

第一层:Metadata(元信息)

技能的"身份证"——叫什么、能干什么、什么时候触发。

name: code-review
description: 审查代码,识别安全风险、逻辑问题、性能瓶颈
triggers:
  - "帮我看一下这段代码"
  - "review 一下"
input:
  - code_snippet: string
output:
  - review_report: string

Metadata 很轻,系统可以把所有技能的 Metadata 一起加载,让 Agent 先选用哪个技能,而不需要把完整内容全暴露出来。

第二层:Instruction(执行指令)

真正告诉 Agent "这件事怎么做",只在执行这个技能时才加载进上下文。

## Code Review 执行指南

按优先级审查以下维度:
1. 安全性:SQL 注入、XSS、敏感信息硬编码 → 标记 [HIGH]
2. 逻辑正确性:边界条件、空值处理、并发问题
3. 性能:循环内重复计算、不必要的数据库查询
4. 可读性:命名是否清晰,复杂逻辑是否有注释

每条问题注明 [HIGH/MEDIUM/LOW],说明位置、问题、修改建议。

第三层:Resources(外部资源)

有些技能执行时还需要额外的东西:规则库、模板、脚本、外部工具调用等。这些放在 Resources 层,Agent 按需拉取,用完即走。

/skills/code-review/
  metadata.yaml          ← 索引,常驻
  instruction.md         ← 执行时加载
  resources/
    security_rules.json  ← 按需拉取
    review_template.md

三层各司其职

层级 作用 加载时机
Metadata 技能索引,用于路由选择 始终在上下文
Instruction 执行指南,指导 Agent 行为 技能被选中时
Resources 外部数据/脚本/模板 执行过程中按需

这就是所谓的渐进式披露——信息随执行进度逐步展开,而不是一开始全部堆在上下文里。

设计 Skill 时最容易踩的坑

粒度问题。 一个技能对应一个完整的用户意图,不要太粗也不要太细。

code-review ✅ 对应"帮我 review 代码"这个完整意图
backend-development ❌ 太粗,一个技能管了太多事
check-variable-naming ❌ 太细,组合起来很麻烦

描述要精准。 Agent 靠 Metadata 的 description 来判断用不用这个技能,描述模糊就容易选错。


举例

比如我们现在需要生成一个视频,但是并不知道怎么做,这时候可以借助这个skill,skills.sh/vercel-labs…,我们把这个 skill 安装到本地

npx skills add https://github.com/vercel-labs/agent-skills --skill vercel-react-best-practices

然后直接向 ai 提问,ai 会自动寻找这个 skill,并利用这个skill生成视频

帮我生成一个前端行业报告,使用remotion-best-practices这个skill

可以看到 ai 最后直接帮我创建了一个前端项目

执行看看效果,为了较少大小,我调整为4倍速,可以看到效果还不错,这个就真的像一个视频编辑器一样, 如果不借助 skill,恐怕很难实现这个效果。

写在最后

Agent Skill 的本质是对执行能力的结构化管理

三层结构解决的问题很实际:让 Context Window 里只出现当前任务需要的内容,让模型更专注,执行更稳定,技能库更好维护。

规模小的时候感受不明显,一旦你的 Agent 需要处理十几二十种不同任务类型,这套结构的价值就很清楚了。

❌
❌