最近在学习 AI Agent、Harness、Codex 等概念时，经常会看到一个词：
Rule。
刚开始很容易把 Rule 理解成“提示词”，但实际上两者并不是一回事。
如果只记一句话，可以先记：
Prompt 是告诉 AI“这次要干什么”，Rule 是限制 AI“哪些事情能做、哪些事情不能做”。
不过到了 Codex 里面，还要再区分一个非常容易混淆的东西：
AGENTS.md。
严格来说：
Prompt
=
当前任务
AGENTS.md
=
给 Agent 的项目 Instructions
告诉 Agent 应该怎么工作
.rules
=
Codex 的命令执行 Rules
控制某些命令允许、询问还是禁止
下面详细解释。
假设我使用 Codex 开发一个后台管理系统。
今天我告诉 Codex：
帮我把登录页面改漂亮一点，只修改登录页面。
这句话属于：
Prompt（提示词）
因为它描述的是：
这一次具体要完成什么任务。
但是 Codex 修改代码的过程中，还可能需要：
读取文件
↓
修改代码
↓
运行 npm run build
↓
执行 git
↓
访问网络
↓
甚至执行其他 Shell 命令
这时候就会出现另外一个问题：
Codex 到底允许执行哪些命令？
比如：
npm run build
可以直接执行。
但是：
某些危险命令
可能应该先询问用户。
甚至：
某些命令
应该完全禁止。
这时候就需要：
Rules。
最简单的区别就是：
Prompt
=
干什么
Rule
=
能不能这么干
例如：
帮我修改登录页面。
告诉 Codex：
当前任务是什么。
git push
→ 是否允许直接执行？
告诉 Codex 的执行系统：
这个命令是否可以执行。
所以两者解决的问题不同。
这里特别容易混淆。
例如：
只修改用户明确指定的页面。
不要擅自重构无关代码。
修改完成以后必须测试。
优先使用项目已有组件。
从我们日常说话的角度，它们当然也可以叫：
“项目规则”。
但是在 Codex 的官方机制里，这类内容更加准确的名字是：
Instructions（指令）
通常可以写在：
AGENTS.md
里面。
因此以后最好区分：
广义上的“规则”
│
├── 行为要求
│ ↓
│ AGENTS.md
│ Instructions
│
└── 命令执行规则
↓
.rules
Exec Policy
这样就不容易混乱了。
AGENTS.md 可以理解成：
给 AI Agent 看的项目工作说明书。
假设新建一个项目：
my-project/
│
├── AGENTS.md
├── frontend/
├── backend/
└── README.md
可以在 AGENTS.md 中写：
# 项目开发说明
## 修改原则
- 只修改用户明确要求的功能。
- 不修改任务范围之外的页面。
- 优先进行最小范围修改。
- 不为了顺手优化而重构无关代码。
## UI 规范
- 新页面保持现有系统视觉风格。
- 优先复用已有组件。
- 保持按钮、表格、弹窗等样式统一。
## 开发要求
- 修改前先阅读相关代码。
- 修改完成后检查是否存在编译错误。
- 可以运行测试时，应主动运行测试。
- 未经明确要求，不随意新增大型第三方依赖。
这些内容主要是在告诉 Codex：
在这个项目里应该怎么工作。
这个名字其实很好理解：
AGENTS
=
Agent / 智能体
.md
=
Markdown 文件
所以：
AGENTS.md
可以简单理解成：
写给 AI Agent 阅读的 Markdown 文件。
它里面一般可以放：
项目说明
开发规范
代码约定
测试方式
目录结构
业务约束
注意事项
它不是程序运行必须使用的代码文件。
它主要是：
给 Agent 看的。
假设 AGENTS.md 中已经写了：
只修改用户明确要求的功能。
不要主动重构无关代码。
修改完成以后必须进行验证。
然后今天我告诉 Codex：
把登录按钮改成蓝色。
那么可以简单理解成 Codex 同时获得了：
AGENTS.md
“平时应该怎么工作”
+
Prompt
“这一次具体干什么”
↓
Codex
于是：
Prompt：
把登录按钮改成蓝色
+
AGENTS.md：
只修改明确要求的功能
↓
Codex：
只修改登录按钮
不主动修改其他页面
修改完成后进行验证
所以：
Prompt 是当前任务。
而：
AGENTS.md 是项目级的长期 Instructions。
假设我的项目叫：
class-insight
目录：
class-insight/
│
├── AGENTS.md
├── frontend/
├── backend/
└── README.md
第一次可以先创建：
AGENTS.md
内容例如：
# 项目 Instructions
## 基本原则
- 优先进行最小范围修改。
- 只修改用户明确指定的功能。
- 不主动修改无关页面。
- 不随意改变现有业务逻辑。
## 前端
- 保持现有 UI 风格。
- 优先使用项目已有组件。
- 修改前端后执行构建检查。
## 后端
- 不随意修改数据库结构。
- 不随意改变已有接口。
- 修改后执行相关测试。
## 安全
- 不删除重要数据。
- 不修改密码、Token、Key 等敏感配置。
以后就不需要每次 Prompt 都重复：
不要乱改其他功能。
不要乱改其他功能。
不要乱改其他功能。
这些长期要求可以放在：
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 可以提供更加具体的要求。
这有点像公司制度：
公司制度
↓
部门制度
↓
项目制度
↓
当前任务
可以简单理解成：
会。
Codex 在处理任务时，会把适用的项目 Instructions 组织到模型上下文中。
所以模型真正收到的并不只是：
把登录页面改一下。
实际上可能还有：
Codex 自己的基础 Instructions
+
当前权限 / Sandbox 信息
+
AGENTS.md
+
当前工作环境
+
可以使用的 Tools
+
历史对话
+
Tool 返回结果
+
用户当前 Prompt
这些内容共同形成：
Context（上下文）
所以：
Prompt 只是模型上下文中的一部分。
不是。
假如只有：
几十行真正重要的要求
通常比较容易理解。
但是如果写成：
几千行
把：
所有需求
所有接口
所有数据库表
所有历史问题
所有会议记录
所有 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 有一套命令执行策略机制。
最常见的全局规则文件是：
~/.codex/rules/default.rules
例如里面可能出现：
prefix_rule(
pattern=["git", "push"],
decision="allow"
)
它不是在告诉 Codex：
你必须执行 git push。
而是在说：
如果 Codex 准备执行以
git push开头的命令，那么这个操作允许执行。
这里特别容易说错。
目前不要理解成 Codex Desktop 中存在这样一个固定入口：
Settings
→ Rules
→ 新建规则
当前 Codex 的 .rules 机制仍然主要是：
文件式配置。
最常见的是：
~/.codex/rules/default.rules
也就是说：
Codex 有 Rules 功能
≠
Codex Desktop 一定有一个 Rules 图形化设置页面
目前更多是在：
.rules 文件
中维护这些命令执行策略。
所以如果打开 Codex 设置页面没有找到：
Rules
并不是没有这个功能。
而是：
这个功能目前主要由底层配置文件维护。
例如：
prefix_rule(
pattern=["git", "push"],
decision="allow"
)
我们一个一个拆开。
prefix 是：
前缀。
所以：
prefix_rule
可以理解成：
如果一个命令开头符合某种格式，就应用这条规则。
例如：
pattern=["git", "push"]
表示匹配：
git push
这种命令前缀。
例如：
git push
或者：
git push origin main
都可能符合这个前缀。
例如：
decision="allow"
意思是：
允许。
Codex 的命令策略中，可以看到类似：
allow
prompt
forbidden
可以简单理解成：
| decision | 大白话 |
|---|---|
| allow | 允许 |
| prompt | 执行前需要询问 |
| forbidden | 禁止 |
例如：
prefix_rule(
pattern=["git", "push"],
decision="prompt"
)
可以理解成：
Codex 如果准备执行
git push，先询问用户。
假设：
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
=
项目 Instructions
=
应该怎么干
.rules
=
执行策略
=
这个命令能不能干
最后把三个最容易混淆的东西放在一起：
| 内容 | 作用 | 举例 |
|---|---|---|
| Prompt | 当前任务 | 把登录页面改成蓝色 |
| AGENTS.md | 项目 Instructions | 只修改明确要求的模块 |
| .rules | 命令执行策略 | git push 是否需要审批 |
可以记成一句话：
Prompt 是“今天干什么”，AGENTS.md 是“平时应该怎么干”，
.rules是“这个命令能不能干”。
再回到 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 行为边界的一部分。
最后总结几个最重要的概念。
告诉 AI：
这一次干什么。
例如：
修改登录页面。
告诉 Agent：
在这个项目里应该怎么工作。
例如：
优先最小范围修改，修改完成后进行测试。
它更准确属于：
Instructions。
告诉 Codex 的执行策略系统：
某些命令允许、询问还是禁止。
例如：
git push
→ prompt
它才是 Codex 中更加严格意义上的：
Rules / Exec Policy。
所以以后再看到 Codex 的 Rule，可以先问自己：
现在说的是“给模型看的工作 Instructions”，还是“控制 Shell 命令执行的
.rules”？
只要把这两个东西分开，Codex 里的 Rule 基本就不会再混淆了。
一句话总结：
Prompt 管“任务”，AGENTS.md 管“工作方式”，
.rules管“命令执行边界”。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。