为什么 Warp 的 Agent 会遗漏你编写的规则
文件名区分大小写，且只有一种大小写格式有效
项目规则（Project Rules）“存在于你的代码库中，并在该项目中工作时自动应用”，存储在“AGENTS.md 文件中（或为了向后兼容而使用 WARP.md）”。Warp 对新项目的建议是使用 AGENTS.md。
全大写的要求在文档中被标记为“注意”（Caution），这个严重级别很合适。它会静默失败，而且失败的方式恰好会让你怀疑这个功能本身，而不是文件名——你写了一条规则，没有任何变化，于是你得出结论：Agent 忽略了规则。
WARP.md 仍然有效，但在文档中被归为向后兼容。如果你继承了一个包含该文件的仓库，它会被加载；如果是从头开始，请使用 AGENTS.md。
子目录规则仅在特定条件下加载
这是最隐蔽的原因，文档中曾明确说明过一次：“Warp 会自动应用根目录和当前目录中的 AGENTS.md（或 WARP.md）。”接着又说：“如果你编辑另一个子目录中的文件，Warp 会尽最大努力尝试也包含该子目录的规则文件。”
两个位置是自动加载。其他所有位置都是“尽力而为”。
Warp 自己的示例清楚地说明了这一点。当当前目录设置为 ui/ 时，自动应用的规则是 project/AGENTS.md 和 project/ui/AGENTS.md，而 project/api/AGENTS.md 则是“尽力而为”——只有当你编辑那里的文件时才会包含。将当前目录切换到 api/，角色就会互换。
因此，一个包含每个包专属规则的 Monorepo（单体大仓库）会有一个可靠层和一个不可靠层，具体取决于你从哪里开始会话。如果某条规则对整个仓库都很重要，那么根目录文件是唯一能保证加载它的地方。
最具体的规则优先，但这并不总是你的本意
Warp 按照文档中说明的顺序解决冲突：当前子目录文件中的规则，然后是根文件中的规则，最后是全局规则（Global Rules）。其声明的意图是“最具体、与项目最相关的规则优先于更广泛的规则”。
这很合理，但也是根级标准悄然失效的原因。18 个月前为某个包编写的子目录文件，现在其优先级高于你上周添加到根目录的规范——而且仅在该目录中生效，这就是为什么它看起来时断时续。
全局规则排在最后。你放在那里的任何内容都是最先被覆盖的。
规则可能存在于从未告知 Warp 读取的文件中
Warp 在这方面异常慷慨，而且这种慷慨是选择性加入的。运行 /init 可以“将现有的规则文件链接到 AGENTS.md”，支持的列表比任何同类工具都长：“CLAUDE.md、.cursorrules、AGENT.md、GEMINI.md、.clinerules、.windsurfrules、.github/copilot-instructions.md”。
请注意，单数形式的 AGENT.md 也在该列表中，它与 AGENTS.md 不是同一个文件。如果你的仓库使用的是单数形式，它是一个可链接的外部文件，而不是 Warp 的原生文件。
这里的陷阱在于，误以为存在“自动检测”，而实际上需要“手动链接”。一个装满 CLAUDE.md 的仓库不会自动提供给 Warp；你必须链接它。从其他 Agent 迁移过来的团队经常遇到这个问题——文件转换部分在如何将你的 CLAUDE.md 迁移到 AGENTS.md中有所介绍。
而且你可能拥有一些并非你编写的规则
有一行字值得了解：“Warp 还可能根据你的使用模式推荐全局规则，以使未来的交互更智能、更一致。”推荐规则是一种便利，但如果你从未打开过全局规则面板，你就不知道里面有什么。在得出规则被忽略的结论之前，请先检查一下——它可能正被你从未读过的内容所覆盖。”
人们尝试过的方法
更强硬地重写规则。 正文全部大写，加入更多感叹号。如果文件名是小写的，或者文件位于未加载的子目录中，再怎么强调也无济于事。
将所有内容移至一个巨大的根文件中。 这确实解决了加载问题，但却用一个问题交换了另一个问题：现在每条规则都会在每次请求时加载，包括关于你根本没有触及的包的 20 行内容。
将规则粘贴到提示词中。 可靠但需要手动，这意味着它一直有效，直到你忘记了一次。
假设 Warp 忽略了 CLAUDE.md。 它并没有忽略——但它需要通过 /init 进行链接，而不仅仅是存在于那里。
将项目知识放入 Warp Drive。 Warp Drive 确实非常有用，并且可以在团队中实时同步，但文档中将其定义为“工作流、笔记本、提示词和环境变量”的工作区。它不是规则或知识库，而内置于其中的规则面板只是为了 UI 上的便利，并没有改变 Drive 所保存的内容。
将规则变成一个文档项目。 直觉是对的，但容器选错了——规则文件是用来引导行为的，而规则背后的推理在其中无处安放。
解决方案：验证加载了什么，然后将推理移至规则无法容纳的地方
Warp 给你提供了大多数工具没有的东西：检查的方法。“交互中使用的规则将显示在对话中的 References（参考）下，或标记为源自特定规则。”
在更改任何内容之前，先利用这一点。让 Agent 执行规则所管辖的操作，然后查看 References。如果规则未列出，则问题出在加载上——首先检查文件名的大小写，然后检查文件是在根目录还是当前目录中。如果规则已列出，但 Agent 仍然执行了其他操作，则问题不在于加载，重写文件也无济于事。
然后找到规则面板，这样你看到的就是真实的状态，而不是你凭记忆写的内容。文档中记录了五个入口点：Warp Drive 下的 Personal > Rules；命令面板（Command Palette），搜索 “Open AI Rules”；Settings > Agents > Knowledge > Manage Rules；菜单栏下的 AI > Open Rules；以及斜杠命令 /open-project-rules，它会直接在 Warp 的编辑器中打开项目规则。使用 /add-rule 创建全局规则，并给它一个真实的描述——Warp 的字段提示是“规则的作用以及何时应用”，而描述正是 Agent 读取以决定相关性的内容。
这解决了加载问题。但它没有解决后半部分，即对于你所知道的大部分内容来说，规则文件的形式是错误的。规则是在请求时应用的指令；它们必然很短，并且会争夺上下文。某个规范存在的原因、你已经拒绝的方法、使显而易见的答案变得错误的约束——这些都不是指令，将它们放入 AGENTS.md 只会使文件变长，而不会让 Agent 更紧密地遵循它。
这就是 MemoryLake 的用武之地：将你项目的持久知识保存在一个供工具查询的层中，这样规则就能保持简短，而推理过程依然可用。设置只需三个步骤。
步骤 1：创建 API 密钥
登录并创建 API 密钥。一个凭证即可跨你连接的所有工具使用。
步骤 2：上传你的第一批记忆
简短的条目，每条只包含一个主张。最好的来源就是你正准备加长的规则文件：
每条规则的原因。 “迁移只能是递增的，因为只读副本在负载下会滞后。”规则属于 AGENTS.md；而这个原因属于这里，正是它阻止了规则在下个季度被推翻。
在此仓库中已被拒绝的方法。 这一类内容不会出现在任何规则文件或提交信息中，却在每次新会话中被重新提出。
没有任何通知的环境事实。 仅在 CI 中失败的测试、未记录的速率限制、两个任务之间的顺序依赖关系。
子目录文件之间存在分歧的地方。 如果你每个包的规则与根目录冲突，请写下当前使用的是哪一个以及原因。这是一个事实，而不是规则。
步骤 3：连接你的 AI 和 Agent
连接你使用的工具。MemoryLake 可以通过 MCP 和 API 访问，并且 Warp 支持 MCP 服务器——有一个细节值得了解：“CLI 保留了自己的 MCP 服务器配置，与 Warp 应用程序的配置分开”，在 macOS 上存储在 ~/.warp_cli/.mcp.json。如果你两者都使用，请对两者都进行配置。Claude、Codex 和 OpenClaw 等 MCP 原生 Agent 以相同的方式连接，其他助手则通过 API 读取相同的记忆。
三个坦诚的限制。MemoryLake 不会编写你的 AGENTS.md 或全局规则——这些是你引导 Warp 的方式，而上述加载行为是 Warp 的，并不是记忆层可以改变的。它只保存你或你的 Agent 放入其中的内容，因此步骤 2 是手动的。此外，规则是上下文，而不是强制配置；任何每次都必须成立的内容都需要在 CI 中进行检查，而不是在 markdown 文件中写一行字。
这在实践中带来了什么改变
“规则是否加载？”变成了一个两秒钟的检查。 查看 References。
文件名大小写不再是一个神秘的 Bug。 AGENTS.md，全部大写，否则它就不存在。
根目录与子目录的选择变成了一个深思熟虑的决定。 根目录是有保证的；其他地方则是尽力而为。
规则文件变得更短。 推理过程被移出，剩下的就是指令。
迁移进来不再意味着重写。 可以使用 /init 链接七种外部格式。
你的 CLI 和应用程序在重要的部分保持同步。 Warp 的文档指出，它们之间“规则和技能不需要迁移”——它们读取相同的文件位置。MCP 配置是例外。
Warp 项目规则的最佳实践
每次都先检查大小写。 这是成本最低的诊断方法，也是最常见的原因。
将适用于整个仓库的规则放在根文件中。 只有根目录和当前目录会自动加载。
审计你的子目录文件，查找陈旧的覆盖。 最具体的文件优先，而旧文件依然保持具体。
阅读一次你的全局规则面板。 Warp 可能推荐了你从未见过的规则。
链接，而不是复制。 /init 链接了 CLAUDE.md、.cursorrules、.clinerules 以及其他四种格式。同一规则的两个副本会产生偏差。
给全局规则一个真实的描述。 这是 Agent 读取以决定相关性的内容。
通过 References 进行验证，而不是通过重新阅读文件。 加载了什么是事实；你写了什么是意图。
不要将推理过程写在规则文件中。 规则是在请求时应用的，并且会争夺上下文——其大体形式见AI 记忆究竟是什么。
结论
一旦你了解了 Warp 规则系统的四个边界，它就会运行得很好。文件名必须全部大写，小写的 agents.md 会静默失败。只有根文件和当前目录的文件会自动加载，其他所有内容都是“尽力而为”，取决于你碰巧触及了哪些文件。冲突会解析为最具体的文件，因此旧的子目录规则在那个目录中的优先级高于新的根标准。此外，可以使用 /init 链接七种外部规则格式——是链接，而不是自动检测。
真正优秀的部分是验证路径。触发的规则会显示在对话中的 References 下，这让“我的规则加载了吗？”从一个猜测游戏变成了一目了然的查看。该类别中的大多数工具都没有提供这样的视图，在编辑任何内容之前养成检查它的习惯是很有价值的。
规则无法做到的是承载推理过程。它们很短，会在每次相关请求时加载，一旦你开始解释某个规范存在的原因，你就会让该文件在执行其实际工作时变得更糟。检查大小写、将适用于整个仓库的规则放在根目录中、审计你的子目录覆盖、通过 References 进行验证——并将决定、原因和被拒绝的方法放在你的 Agent 可以查询的层中，而不是放在它每次都必须读取的文件中。