4. 拓展能力 - Rules、Skills、MCP
前三篇文章搭出了一个能跑通的 Agent：有 Loop 能循环执行，有 Memory 能记住历史，有 Plan 能拆分复杂任务。
但它有两个明显的问题：
- 工具是硬编码的。 你想让 Agent 查 GitHub issue、调外部 API、搜网页？改代码，重新编译。
- Agent 没有约束。 它在你的项目里跑
rm -rf跟你讨论晚饭吃什么一样轻松——它不知道什么能碰、什么不能碰。
Rules、Skills、MCP 就是来解决这两个问题的。它们不是新发明——Claude Code 的 CLAUDE.md、OpenClaw 的 skills 目录、各种 MCP 服务端，都是在用同一套思路。
Rules：给 Agent 画一条线
Rules 就是一个 Markdown 文件，Agent 启动时读到它，拼进 System Prompt。
比如一个项目的 CLAUDE.md：
## 项目概述
这是一个 Next.js 全栈项目，使用 Prisma 做 ORM，NextAuth 做认证。
## 常用命令
- 安装依赖：`pnpm install`
- 开发模式：`pnpm dev`
- 跑测试：`pnpm test`
## 规则
- 禁止执行 `rm -rf` 或任何不可逆的删除命令
- 变量命名用小驼峰
- 提交前必须跑 `pnpm lint`Agent 启动时把这个文件内容拼到 System Prompt 末尾。之后整个对话里，Agent 就知道这个项目用什么技术栈、怎么跑、什么不能干。
加载逻辑很简单：
import fs from "fs";
import path from "path";
function loadRules(rulesPath = ".agent/rules.md"): string {
const file = path.resolve(rulesPath);
if (!fs.existsSync(file)) return "";
return fs.readFileSync(file, "utf-8");
}
// Agent 初始化时
const rules = loadRules();
const systemPrompt = `${basePrompt}\n\n${rules}`;Rules 的本质是项目级 System Prompt 扩展。你不必每次跟 Agent 说”这个项目用 pnpm 不用 npm”、“别碰 .env 文件”——写一次，永久生效。
没有 Rules 的时候，每次在新项目里用 Agent，你都得口述一遍项目背景。Rules 就是把这段口述写成了文件，Agent 启动时自动”预习”。
Skills：一份可复用的行动指南
Rules 解决”不该做什么”。Skills 解决”怎么做”。
Skill 也是一个 Markdown 文件，但它不描述规则，而是描述能力——当用户想做 X 时，Agent 该按什么流程操作。
比如一个 deploy.md：
# Deploy Skill
当用户要求部署项目时，按以下步骤操作：
1. 运行 `pnpm build` 确保构建通过
2. 如果构建失败，检查报错信息，修复后再试
3. 构建成功后，执行 `scp -r dist/* user@server:/var/www/app/`
4. 通过 SSH 执行远程重启命令：`ssh user@server 'pm2 reload app'`
注意：部署前确认用户已经 commit 了所有改动。Agent 读到这个文件后，遇到部署任务时就不需要你一步步指挥。它知道要 build → 检查 → scp → reload。
Skill 的加载跟 Rules 类似，只是从目录里批量读：
function loadSkills(skillsDir = ".agent/skills"): string {
const dir = path.resolve(skillsDir);
if (!fs.existsSync(dir)) return "";
return fs.readdirSync(dir)
.filter(f => f.endsWith(".md"))
.sort()
.map(f => fs.readFileSync(path.join(dir, f), "utf-8"))
.join("\n\n");
}Agent 启动时把 Rules 和 Skills 拼到一起，塞进 System Prompt。整个对话里，Agent 同时拥有”不要做什么”（Rules）和”怎么做特定事情”（Skills）两份指南。
MCP：让工具变成插件
Skills 教 Agent 怎么做事，但做的事本身还是受限于硬编码的工具——bash、read、write、edit。
如果你想让它查 GitHub issue、调 Jira API、连你的 Postgres 数据库？Skills 不够用了。你需要让 Agent 获得新工具，而不是教它怎么用旧工具模拟新能力。
MCP（Model Context Protocol）就是干这个的。它是 Anthropic 提出的一套开放标准，定义了 LLM 和外部工具之间怎么通信。
你不用关心 MCP 协议内部的 JSON-RPC 细节。对 Agent 开发者来说，MCP 的价值就是一行代码：
const allTools = [...coreTools, ...mcpTools];MCP 加载的工具跟内置工具有完全相同的 JSON Schema 格式。Agent 不知道、也不需要知道一个工具是写死在代码里的还是 MCP Server 提供的。对它来说，工具就是工具。
你想连 Google Drive？起一个 Google Drive MCP Server，Agent 就能列文件、读内容。换成一个 Postgres MCP Server，Agent 就能写 SQL。切换工具不需要改 Agent 代码——启动不同的 MCP Server 就行。
MCP 和 Skill 的区别
很容易把它们搞混——都是”拓展 Agent 的能力”。但底层逻辑完全不同。
| Skill | MCP | |
|---|---|---|
| 解决的问题 | 怎么做——给 Agent 一套标准操作流程 | 怎么连——给 Agent 一个跟外部系统通信的管道 |
| 形式 | Markdown 文件，自然语言描述 | 结构化 JSON-RPC 接口，严格的客户端-服务端实现 |
| Agent 怎么用 | 读 Markdown → 理解 → 用现有工具执行 | 收到 tool_call → 调 MCP Server → 拿结构化返回 |
| 谁写的 | 你手写，或让 LLM 生成 | MCP Server 开发者实现，你只管启动 |
一个粗糙但有效的判断方式：如果能用 bash 命令搞定，写 Skill；如果 bash 搞不定（需要调用 API、连数据库、操作 SaaS 服务），上 MCP。
Skills 是给旧工具写新说明书，MCP 是装新工具。
四篇文章的完整图景
回顾一下这四篇文章串起来的 Agent 演进路线：
- Agent Loop — Agent 的心脏。没有它，后面的都是空中楼阁。
- Memory — Agent 的记性。没有它，每次对话都是全新的。
- Plan — Agent 的规划能力。没有它，复杂任务跑着跑着就偏了。
- Rules、Skills、MCP — Agent 和外部世界的接口。Rules 划边界，Skills 教方法，MCP 给武器。
你可以把前三篇理解成 Agent 的”操作系统”——Loop 是调度器，Memory 是硬盘，Plan 是进程管理器。而 Rules、Skills、MCP 就是装在这个操作系统上的应用层——它们决定了 Agent 在具体项目里能干什么、不能干什么、怎么干。
从下一篇开始，我们会跳出单个 Agent，讨论多 Agent 之间的协作和编排。
本系列所有代码在 Any-Agent-Nano 可以找到。不到 500 行，却包含了一个完整 Agent 的全部核心机制。