问题背景
这次整理家庭服务器项目时，我遇到的不是某个具体服务配置失败，而是一个更基础的问题：不同对话里解决的问题，怎样才能被后续的新对话继续理解和复用。
这个项目会长期记录 Mac mini 家庭服务器的配置、排障、脚本和维护流程。如果每次新对话都要重新解释项目结构、发文要求、WordPress 发布规则和安全边界，时间久了会很容易混乱。于是我开始梳理两个文件的定位：README.md 和 AGENTS.md。
现象
一开始我以为只要有 README.md 就够了，因为它能说明项目是什么、有哪些目录、当前配置到什么状态。但继续讨论后发现，README.md 更像给人看的项目总览，并不能稳定表达 agent 每次工作前必须遵守的行为规则。
比如这些要求就不适合只放在 README.md 里：
- 新对话开始前应该先读哪些文件；
- WordPress 发文任务要先读 publishing/README.md；
- “将刚才的问题发文”应该触发固定发文流程；
- 密码、Token、WordPress 应用程序密码不能写入项目；
- 解决问题后是否需要沉淀为排障记录或文章草稿。
这些不是项目介绍，而是工作规则。它们需要一个专门给 agent 看的入口。
排查过程
我们先确认了一个关键点：Codex 不会在每个新项目里自动创建 AGENTS.md。官方机制是，如果项目里已经存在 AGENTS.md，Codex 会把它作为项目级指引读取；如果没有，它当然读不到。
所以，新项目第一次使用时，最好由用户或第一个 agent 建立这份项目指引。之后每个新对话进入同一个项目时，就可以通过 AGENTS.md 继承同一套规则。
接着我们区分了 README.md 和 AGENTS.md 的职责：
README.md 面向人，负责解释这个项目是什么、目录如何组织、当前状态是什么、常用入口在哪里。
AGENTS.md 面向 agent，负责说明开始工作前要读什么、文档如何归档、什么信息不能写入项目、什么时候要更新 README.md，以及遇到 WordPress 发文任务时应该走哪套流程。
这个分工确定后，项目就不再依赖“某个对话记得之前说过什么”，而是把长期规则沉淀到了文件里。
解决方法
最后采用的方案是：在项目根目录建立 AGENTS.md，并保留 README.md 作为项目总览。
AGENTS.md 负责规定 agent 的工作方式，包括：
- 开始处理任务前先阅读根目录 README.md；
- 涉及 WordPress 发文、文章总结、发布草稿时，必须阅读 publishing/README.md；
- 长期结果按主题目录归档，不按对话归档；
- 不为了单次对话随意新增顶层目录；
- 密码、Token、API Key、WordPress 应用程序密码不能写进项目；
- 用户说“将刚才的问题发文”时，当前对话切换为 WordPress 发文 agent 工作模式。
README.md 则继续保持简洁，记录项目用途、目录结构和当前服务器状态。比如家庭服务器项目下有哪些主题目录、DDNS 和 SFTP 当前是否配置完成、Time Machine 是否已有排查记录等。
为了让发文流程也能长期复用，我们又新增了 publishing/README.md 和 publishing/article-template.md。这样以后解决完一个问题后，只要说“将刚才的问题发文”，当前 agent 就能按固定流程生成文章草稿、生成配图、生成标签，并把摘要写入 Slim SEO 的 meta description。
注意事项
这个方案里有几个边界需要注意。
第一，AGENTS.md 不是自动凭空出现的。新项目第一次使用时，仍然需要创建它，或者在个性化指令中要求 agent 发现缺失时提醒创建。
第二，不要把所有内容都塞进 AGENTS.md。它只适合放长期有效的工作规则。项目事实、当前状态和目录说明，仍然应该放在 README.md。
第三，敏感信息不要写入任何项目文档。比如 WordPress 应用程序密码应该放在 macOS 钥匙串、环境变量或项目外私密配置里。项目里只能记录读取方式，不能记录真实值。
第四，发文 agent 也不是一个永远在线的独立机器人。它更像一个固定岗位：任何新对话只要读取了项目规则，就可以按这个岗位执行发文任务。
总结
这次整理后，我对 README.md 和 AGENTS.md 的分工更清楚了：README.md 负责让人快速理解项目，AGENTS.md 负责让 agent 按统一规则工作。
对于长期维护的家庭服务器项目，这种分工很有价值。它能减少重复解释，让不同对话之间通过项目文件交接上下文，也能把排障记录、发文流程和安全规则固定下来。
以后每当出现新的长期规则，就应该考虑是否写进 AGENTS.md；每当项目状态或目录结构发生变化，就应该同步更新 README.md。这样项目会随着实际使用逐步变得更清晰，而不是只靠对话记忆维持。