编码 agent 指令文件对比：每个 agent 实际读取什么

把可移植的规则放进 AGENTS.md；几乎所有主流 agent 都会读它。团队踩坑的地方在于例外：有的 agent 在存在另一个文件时会跳过它，有的需要打开某个设置，有的会忽略嵌套的副本。本页列出了十一个 agent 的文件、优先级规则和内置 spec 功能，每一项都对照厂商自己的文档核实过。

最后核实2026 年 9 月 29 日
覆盖的 agent11 个，另加 Spec Kit、OpenSpec 和 BMAD
经验法则AGENTS.md 写规则，spec 写变更

对比表

"AGENTS.md"一列表示厂商文档写明原生支持。优先级描述的是多个文件同时适用时的处理方式；大多数 agent 是拼接而不是覆盖。

Agent自有指令文件AGENTS.md优先级Spec 或计划功能
Claude Code
Anthropic		CLAUDE.md（托管级、~/.claude/、项目级、CLAUDE.local.md），带 paths: glob 的 .claude/rules/*.md，位于 .claude/skills/*/SKILL.md 的 skills支持，自 2.1.277（2026 年 9 月 18 日）起。默认：仅在不存在 CLAUDE.md 时读取各层级全部拼接，根目录在前；Claude 读取子目录时加载该目录下的文件；@path 导入最多 4 层Plan mode（Shift+Tab 或 --permission-mode plan）
Codex
OpenAI，CLI / 应用 / 云端		~/.codex/AGENTS.md 或 AGENTS.override.md；skills 位于 .agents/skills支持，原生；这是它的主格式从 Git 根目录走到当前目录；拼接，离得越近的文件优先；上限 32 KiB（project_doc_max_bytes）Plan mode（/plan）
Cursor
Anysphere		带 alwaysApply、description、globs 的 .cursor/rules/*.mdc；User Rules 和 Team Rules支持，根目录和子目录Team，然后 Project，然后 UserPlan Mode；计划可以保存到工作区
Kiro
AWS		.kiro/steering/*.md（建议 product、tech、structure），~/.kiro/steering/；hooks 位于 .kiro/hooks/支持；自 v1.0.309（2026 年 8 月 13 日）起支持嵌套 AGENTS.md工作区 steering 优先于全局；AGENTS.md 始终包含Specs：requirements.md（EARS）、design.md、tasks.md
Gemini CLI
Google		GEMINI.md：全局、工作区及上级目录，然后按需加载；@./file.md 导入仅在配置后："context": {"fileName": ["AGENTS.md", ...]}拼接Plan Mode（/plan），只读
Jules
Google		没有自有文件支持，根目录 AGENTS.md不适用修改代码前需要你批准的计划
Copilot coding agent
GitHub，云端		.github/copilot-instructions.md、.github/instructions/*.instructions.md；也读根目录的 CLAUDE.md / GEMINI.md支持，任意位置；最近的优先个人，然后仓库，然后组织，但全部都会发送未见文档
VS Code 中的 Copilot
GitHub / Microsoft		同样的文件，带 applyTo 的 *.instructions.md，prompt 文件 .github/prompts/*.prompt.md；CLAUDE.md 需要打开设置支持（chat.useAgentsMdFile）；嵌套文件需要 chat.useNestedAgentsMdFiles，默认关闭叠加；文档说不要依赖顺序Plan agent（/plan）
Junie
JetBrains		.junie/AGENTS.md、.junie/playbook.md、.junie/rules/*.md；旧版 .junie/guidelines.md支持，根目录或 .junie/.junie/AGENTS.md 优先；项目级优先于 ~/.junie/AGENTS.md；重复内容会去除（CLI 文档）未见文档
Devin Desktop
Cognition，原 Windsurf		.devin/rules/（旧版 .windsurf/rules/），每个文件 12,000 字符；全局规则 6,000 字符支持；根目录始终生效，子目录按 glob 限定范围trigger：always_on、model_decision、glob、manual未见文档
Amp
Amp		回退到 AGENT.md 或 CLAUDE.md支持，它的主文件工作区、个人、上级目录直到 $HOME、读取时加载的子树、系统未见文档
Cline
Cline		.clinerules/ 或 .cline/rules/，全局规则文件夹；也读 .cursorrules、.windsurfrules支持工作区优先于全局；paths: 条件规则未核查

"未见文档"表示我们在厂商文档中没有找到该产品形态的计划或 spec 功能，不代表它不存在。"未核查"表示我们没有去查。

可移植文件悄悄不再加载的五种情况

存在 CLAUDE.md 时的 Claude Code

默认设置只在不存在 CLAUDE.md 时读取 AGENTS.md。在 CLAUDE.md 里保留一行 @AGENTS.md 导入，或者在 /config 中把 "Project instructions" 设为两者都读。Claude Code 也会忽略 AGENTS.override.md。

开箱即用的 Gemini CLI

它读取 GEMINI.md。在 settings.json 的 context.fileName 中加上 AGENTS.md，并用 /memory show 检查。

VS Code 中的嵌套文件

根目录的 AGENTS.md 能生效；monorepo 中每个包自己的文件在打开 chat.useNestedAgentsMdFiles 之前不起任何作用。

Codex 中的大文件

Codex 默认把项目指令限制在 32 KiB（project_doc_max_bytes）。在路径上有多个较长 AGENTS.md 文件的 monorepo 里，先检查这个上限，别想当然地认为最近的那个文件已经被加载。

其实是 spec 的规则

一个不断写入某个功能验收标准的指令文件，会在每个任务、每次变更时都被加载。针对单次变更的规则应该放在这次变更的 spec 里。

我们测过缺少规则的代价

在我们录制的 agent 运行中，删掉一份 13 行的契约文档后，一次安全的 API 清理在 3 次运行中有 2 次弄坏了已发布的移动端 App。

在全部十一个 agent 中都能用的配置

文件

AGENTS.md                  # stack, commands, boundaries, readers
packages/billing/AGENTS.md # rules only true inside billing
CLAUDE.md                  # "@AGENTS.md" + Claude-only notes
GEMINI.md                  # or set context.fileName instead
.github/copilot-instructions.md   # optional, Copilot-only
specs/2026-09-coupon/spec.md      # goal, non-goals, ACs, evidence

什么放在哪里

  • AGENTS.md：对每个任务都成立的事实。仓库之外谁读取哪张表或哪个字段，哪些文件是生成的，哪些迁移已冻结。
  • 工具专属文件：只写该工具单独需要的内容，再加一个指向 AGENTS.md 的指引。绝不复制第二份规则。
  • spec：这次变更的规则。AGENTS.md 指南详细讲了如何划分。

内置 spec 功能与 spec 框架

Kiro specs

这里唯一内置 spec 工作流的 agent：requirements.md 或 bugfix.md、design.md、tasks.md。需求使用 EARS 写法（"WHEN [condition/event] THE SYSTEM SHALL [expected behavior]"，即"当[条件/事件]时，系统应[预期行为]"）。变体：Requirements-First、Design-First，以及没有审批关口的 Quick Spec。"Run all tasks"（运行全部任务）会把相互独立的任务分成并行的批次运行。

计划模式

Claude Code、Codex、Cursor、Gemini CLI 和 VS Code 中的 Copilot 都有只读的计划模式。Cursor 可以把计划保存进仓库；VS Code 把本地计划保存在会话内存中，不在项目里。计划不是 spec：它描述的是步骤，而不是步骤完成后必须成立的行为。

构建在上层的框架

GitHub Spec Kit 于 2026 年 8 月 21 日发布 v1.0（9 月 25 日为 v1.0.12）。OpenSpec 目前是 v1.13.2（9 月 23 日）。BMAD-METHOD 在把核心 skills 从 14 个精简到 8 个之后，目前是 v6.12.0（9 月 4 日）。我们的 OpenSpec vs Spec Kit vs Superpowers 对比讲了如何组合使用它们。

2026 年的模型给 spec 工作带来了什么变化

2026 年 5 月到 9 月，各厂商发布了很多东西。其中三条说法关系到你需要写下多少内容；它们都是厂商自己的原话，链接见下文。

运行时间长了很多

Anthropic 报告一位测试者的 Opus 5.5 任务在无人值守的情况下运行了 "for over 18 hours"（超过 18 小时）；Meta 描述 Muse Code 的会话有 "1,000+ tool calls (up to 24 hours)"（1,000 次以上工具调用，最长 24 小时）；阿里巴巴描述了一次用 Qwen3.8-Max 完成的、持续 10 天以上的自主构建。agent 脱离你运行的时间越长，它就有越多决策发生在无人评审的地方。

计划、分发、验证

Claude Code 的动态工作流会先做计划，然后 "run hundreds of parallel subagents"（运行数百个并行 subagent），并以 "the existing test suite as its bar"（现有测试套件为标准）；Grok Build 提供带并行 subagent 的计划模式，Muse Code 内置了 /plan 和 /goal skills。当测试就是标准时，写成测试的验收标准才是 agent 真正对照检查的东西。

有 spec 时，小模型追上来了

Anthropic 公布的 Terminal-Bench 4.0 成绩中 Sonnet 5.5 高于 Opus 5.5。在我们自己的运行中，spec 让 Haiku 4.5 在 API 任务上从 8 项检查通过 2–5 项提升到 8 项全过。参见跨模型运行。

来源

核查于 2026 年 9 月 29 日。厂商文档会变动；如果这里的某个链接失效了，可以用上面的文件名和设置名去搜索。

规则写一次，spec 每次变更写一份

规格包生成器会把一个工单变成目标、非目标、验收标准和证据，你可以把它提交到 AGENTS.md 旁边。

生成规格包 阅读 AGENTS.md 指南

编辑说明

每一行都在下方日期对照厂商文档或更新日志核实过。当某个主流 agent 改变加载指令的方式时，我们会重新核查本页；如果这里有过时的内容，请告诉我们。