AI Agent 中的 Rule 是什么？以 Codex 为例，小白也能看懂

最近在学习 AI Agent、Harness、Codex 等概念时，经常会看到一个词：

Rule。

刚开始很容易把 Rule 理解成“提示词”，但实际上两者并不是一回事。

如果只记一句话，可以先记：

Prompt 是告诉 AI“这次要干什么”，Rule 是限制 AI“哪些事情能做、哪些事情不能做”。

不过到了 Codex 里面，还要再区分一个非常容易混淆的东西：

AGENTS.md。

严格来说：

Prompt
=
当前任务


AGENTS.md
=
给 Agent 的项目 Instructions
告诉 Agent 应该怎么工作


.rules
=
Codex 的命令执行 Rules
控制某些命令允许、询问还是禁止

下面详细解释。

---

一、先从最简单的例子理解 Rule

假设我使用 Codex 开发一个后台管理系统。

今天我告诉 Codex：

帮我把登录页面改漂亮一点，只修改登录页面。

这句话属于：

Prompt（提示词）

因为它描述的是：

这一次具体要完成什么任务。

但是 Codex 修改代码的过程中，还可能需要：

读取文件
↓
修改代码
↓
运行 npm run build
↓
执行 git
↓
访问网络
↓
甚至执行其他 Shell 命令

这时候就会出现另外一个问题：

Codex 到底允许执行哪些命令？

比如：

npm run build

可以直接执行。

但是：

某些危险命令

可能应该先询问用户。

甚至：

某些命令

应该完全禁止。

这时候就需要：

Rules。

---

二、Prompt 和 Rule 有什么区别？

最简单的区别就是：

Prompt
=
干什么


Rule
=
能不能这么干

例如：

Prompt

帮我修改登录页面。

告诉 Codex：

当前任务是什么。

Rule

git push
→ 是否允许直接执行？

告诉 Codex 的执行系统：

这个命令是否可以执行。

所以两者解决的问题不同。

---

三、那“不要修改其他页面”到底是不是 Rule？

这里特别容易混淆。

例如：

只修改用户明确指定的页面。

不要擅自重构无关代码。

修改完成以后必须测试。

优先使用项目已有组件。

从我们日常说话的角度，它们当然也可以叫：

“项目规则”。

但是在 Codex 的官方机制里，这类内容更加准确的名字是：

Instructions（指令）

通常可以写在：

AGENTS.md

里面。

因此以后最好区分：

广义上的“规则”
│
├── 行为要求
│      ↓
│   AGENTS.md
│   Instructions
│
└── 命令执行规则
       ↓
    .rules
    Exec Policy

这样就不容易混乱了。

---

四、AGENTS.md 是什么？

AGENTS.md 可以理解成：

给 AI Agent 看的项目工作说明书。

假设新建一个项目：

my-project/
│
├── AGENTS.md
├── frontend/
├── backend/
└── README.md

可以在 AGENTS.md 中写：

# 项目开发说明

## 修改原则

- 只修改用户明确要求的功能。
- 不修改任务范围之外的页面。
- 优先进行最小范围修改。
- 不为了顺手优化而重构无关代码。

## UI 规范

- 新页面保持现有系统视觉风格。
- 优先复用已有组件。
- 保持按钮、表格、弹窗等样式统一。

## 开发要求

- 修改前先阅读相关代码。
- 修改完成后检查是否存在编译错误。
- 可以运行测试时，应主动运行测试。
- 未经明确要求，不随意新增大型第三方依赖。

这些内容主要是在告诉 Codex：

在这个项目里应该怎么工作。

---

五、为什么叫 AGENTS.md？

这个名字其实很好理解：

AGENTS
=
Agent / 智能体


.md
=
Markdown 文件

所以：

AGENTS.md

可以简单理解成：

写给 AI Agent 阅读的 Markdown 文件。

它里面一般可以放：

项目说明

开发规范

代码约定

测试方式

目录结构

业务约束

注意事项

它不是程序运行必须使用的代码文件。

它主要是：

给 Agent 看的。

---

六、Prompt 和 AGENTS.md 是怎么配合的？

假设 AGENTS.md 中已经写了：

只修改用户明确要求的功能。

不要主动重构无关代码。

修改完成以后必须进行验证。

然后今天我告诉 Codex：

把登录按钮改成蓝色。

那么可以简单理解成 Codex 同时获得了：

AGENTS.md

“平时应该怎么工作”

        +

Prompt

“这一次具体干什么”

        ↓

Codex

于是：

Prompt：
把登录按钮改成蓝色

        +

AGENTS.md：
只修改明确要求的功能

        ↓

Codex：

只修改登录按钮
不主动修改其他页面
修改完成后进行验证

所以：

Prompt 是当前任务。

而：

AGENTS.md 是项目级的长期 Instructions。

---

七、新建一个 Codex 项目以后，AGENTS.md 怎么用？

假设我的项目叫：

class-insight

目录：

class-insight/
│
├── AGENTS.md
├── frontend/
├── backend/
└── README.md

第一次可以先创建：

AGENTS.md

内容例如：

# 项目 Instructions

## 基本原则

- 优先进行最小范围修改。
- 只修改用户明确指定的功能。
- 不主动修改无关页面。
- 不随意改变现有业务逻辑。

## 前端

- 保持现有 UI 风格。
- 优先使用项目已有组件。
- 修改前端后执行构建检查。

## 后端

- 不随意修改数据库结构。
- 不随意改变已有接口。
- 修改后执行相关测试。

## 安全

- 不删除重要数据。
- 不修改密码、Token、Key 等敏感配置。

以后就不需要每次 Prompt 都重复：

不要乱改其他功能。

不要乱改其他功能。

不要乱改其他功能。

这些长期要求可以放在：

AGENTS.md

里面。

---

八、Codex 会自动读取 AGENTS.md 吗？

会。

Codex 会根据当前项目和工作目录查找适用的：

AGENTS.md

而且可以存在多层。

例如：

my-project/
│
├── AGENTS.md
│
├── frontend/
│   ├── AGENTS.md
│   └── src/
│
└── backend/
    └── AGENTS.md

可以理解成：

my-project/AGENTS.md
=
整个项目的总要求


frontend/AGENTS.md
=
前端自己的要求


backend/AGENTS.md
=
后端自己的要求

如果 Agent 当前正在处理：

frontend/

那么对应目录范围内的 Instructions 就会参与当前任务。

更深层目录的 AGENTS.md 可以提供更加具体的要求。

这有点像公司制度：

公司制度
   ↓
部门制度
   ↓
项目制度
   ↓
当前任务

---

九、AGENTS.md 会作为上下文发送给模型吗？

可以简单理解成：

会。

Codex 在处理任务时，会把适用的项目 Instructions 组织到模型上下文中。

所以模型真正收到的并不只是：

把登录页面改一下。

实际上可能还有：

Codex 自己的基础 Instructions

+

当前权限 / Sandbox 信息

+

AGENTS.md

+

当前工作环境

+

可以使用的 Tools

+

历史对话

+

Tool 返回结果

+

用户当前 Prompt

这些内容共同形成：

Context（上下文）

所以：

Prompt 只是模型上下文中的一部分。

---

十、AGENTS.md 是不是写得越多越好？

不是。

假如只有：

几十行真正重要的要求

通常比较容易理解。

但是如果写成：

几千行

把：

所有需求

所有接口

所有数据库表

所有历史问题

所有会议记录

所有 UI 细节

全部塞进去，就会带来问题。

因为模型读取的上下文越大：

Token 使用更多

+

真正重要的信息可能被大量内容淹没

+

留给代码和任务本身的上下文空间减少

所以更合理的方法是：

AGENTS.md
=
核心 Instructions
+
项目地图
+
详细文档入口

例如：

# 项目 Instructions

## 基本要求

- 只修改用户明确要求的功能。
- 优先进行最小范围修改。
- 不主动重构无关代码。

## 项目目录

前端：

frontend/

后端：

backend/

数据库：

db/

## UI 规范

详细内容：

docs/ui-guidelines.md

## 权限设计

详细内容：

docs/permissions.md

## 测试

前端修改后：

npm run build

后端修改后：

go test ./...

需要修改 UI 时：

再读取 docs/ui-guidelines.md

需要修改权限时：

再读取 docs/permissions.md

而不是每一次都把全部内容塞进 Context。

---

十一、那 Codex 官方真正的 Rules 是什么？

这时候再来看 Codex 的：

.rules

就非常容易理解了。

Codex 有一套命令执行策略机制。

最常见的全局规则文件是：

~/.codex/rules/default.rules

例如里面可能出现：

prefix_rule(
    pattern=["git", "push"],
    decision="allow"
)

它不是在告诉 Codex：

你必须执行 git push。

而是在说：

如果 Codex 准备执行以 git push 开头的命令，那么这个操作允许执行。

---

十二、Codex Desktop 里面有 Rules 配置页面吗？

这里特别容易说错。

目前不要理解成 Codex Desktop 中存在这样一个固定入口：

Settings
→ Rules
→ 新建规则

当前 Codex 的 .rules 机制仍然主要是：

文件式配置。

最常见的是：

~/.codex/rules/default.rules

也就是说：

Codex 有 Rules 功能

≠

Codex Desktop 一定有一个 Rules 图形化设置页面

目前更多是在：

.rules 文件

中维护这些命令执行策略。

所以如果打开 Codex 设置页面没有找到：

Rules

并不是没有这个功能。

而是：

这个功能目前主要由底层配置文件维护。

---

十三、default.rules 到底是什么意思？

例如：

prefix_rule(
    pattern=["git", "push"],
    decision="allow"
)

我们一个一个拆开。

prefix_rule

prefix 是：

前缀。

所以：

prefix_rule

可以理解成：

如果一个命令开头符合某种格式，就应用这条规则。

---

pattern

例如：

pattern=["git", "push"]

表示匹配：

git push

这种命令前缀。

例如：

git push

或者：

git push origin main

都可能符合这个前缀。

---

decision

例如：

decision="allow"

意思是：

允许。

Codex 的命令策略中，可以看到类似：

allow
prompt
forbidden

可以简单理解成：

decision	大白话
allow	允许
prompt	执行前需要询问
forbidden	禁止

例如：

prefix_rule(
    pattern=["git", "push"],
    decision="prompt"
)

可以理解成：

Codex 如果准备执行 git push，先询问用户。

---

十四、AGENTS.md 和 default.rules 是怎么一起工作的？

假设：

AGENTS.md 中写：

修改代码完成以后必须运行项目构建。

于是 Codex 修改完成后判断：

我应该执行：

npm run build

接下来：

.rules 中恰好有：

prefix_rule(
    pattern=["npm", "run", "build"],
    decision="allow"
)

于是整个过程就变成：

AGENTS.md

“修改完成后要进行构建验证”

        ↓

模型判断

“需要执行 npm run build”

        ↓

准备调用 Shell

        ↓

Rules / Exec Policy

检查 npm run build 是否允许

        ↓

allow

        ↓

执行命令

        ↓

返回结果给模型

        ↓

模型继续判断

这就把：

Instructions

Rules

Tools

Shell

Agent Loop

串起来了。

---

十五、所以 AGENTS.md 和 .rules 完全不是一回事

这是最需要记住的地方。

可以把它们类比成公司。

AGENTS.md

相当于：

《员工工作手册》

例如：

提交代码前要测试。

不要擅自修改其他部门的代码。

优先进行最小修改。

这是告诉员工：

应该怎么工作。

---

.rules

更像：

《门禁和审批策略》

例如：

普通办公室
→ 可以直接进入

机房
→ 需要审批

保险柜
→ 禁止进入

它解决的是：

到底允不允许执行某些操作。

所以：

AGENTS.md
=
项目 Instructions
=
应该怎么干


.rules
=
执行策略
=
这个命令能不能干

---

十六、Prompt、AGENTS.md、Rules 三者关系

最后把三个最容易混淆的东西放在一起：

内容	作用	举例
Prompt	当前任务	把登录页面改成蓝色
AGENTS.md	项目 Instructions	只修改明确要求的模块
.rules	命令执行策略	git push 是否需要审批

可以记成一句话：

Prompt 是“今天干什么”，AGENTS.md 是“平时应该怎么干”，.rules 是“这个命令能不能干”。

---

十七、从 Harness 的角度怎么看 Rule？

再回到 Harness。

可以简单把 Harness 理解成：

让 AI Agent 真正能够工作的整套运行环境。

例如：

Harness
│
├── Prompt / Instructions
├── Context
├── Memory
├── Tools
├── 文件系统
├── Terminal / Shell
├── Skills
├── Agent Loop
├── Rules / Exec Policy
├── Permissions
├── Logs
└── Runtime / Sandbox

这里不同东西解决不同问题：

Prompt
↓
当前要干什么


AGENTS.md
↓
这个项目应该怎么工作


Context
↓
模型现在能够看到什么


Tools
↓
模型可以调用什么能力


Rules
↓
某些命令允许、询问还是禁止


Sandbox / Permissions
↓
从系统层面限制 Agent 的实际权限


Agent Loop
↓
让 Agent 不断：
观察 → 判断 → 操作 → 检查 → 再操作

所以 Rule 并不是一个孤立功能。

它只是 Harness 中控制 Agent 行为边界的一部分。

---

十八、总结

最后总结几个最重要的概念。

1. Prompt

告诉 AI：
这一次干什么。

例如：

修改登录页面。

---

2. AGENTS.md

告诉 Agent：
在这个项目里应该怎么工作。

例如：

优先最小范围修改，修改完成后进行测试。

它更准确属于：

Instructions。

---

3. .rules

告诉 Codex 的执行策略系统：
某些命令允许、询问还是禁止。

例如：

git push
→ prompt

它才是 Codex 中更加严格意义上的：

Rules / Exec Policy。

---

所以以后再看到 Codex 的 Rule，可以先问自己：

现在说的是“给模型看的工作 Instructions”，还是“控制 Shell 命令执行的 .rules”？

只要把这两个东西分开，Codex 里的 Rule 基本就不会再混淆了。

一句话总结：

Prompt 管“任务”，AGENTS.md 管“工作方式”，.rules 管“命令执行边界”。