智能体规则如何分配才能节省上下文
文章按加载时机和上下文成本区分指令载体：常驻事实放入 AGENTS.md 或 CLAUDE.md，操作流程放入技能，工具能力通过 MCP 提供。路径规则适合局部约定，强制约束则可交由钩子执行。
AI 深度解读
给编程 Agent 写规则，内容放在哪里，会影响它何时读到，以及每轮要带上多少上下文。作者给出的分工很明确：常驻事实放进 AGENTS.md / CLAUDE.md，多步流程放进 skills，工具能力交给 MCP，必须守住的限制交给自动检查。
这篇值得读的地方，是把「规则怎么整理」变成了「哪些信息值得每次加载」。不过，作者没有提供调整前后的 token 对照数据。它更适合作为整理 Agent 配置的检查框架，不能直接当成经过量化验证的优化方案。
哪些规则值得让 Agent 每次都读
作者给了一个很好用的判断题：新同事提交第一个 PR 前，是否必须记住这条信息？如果答案是肯定的，它才适合进入根目录的指令文件。
AGENTS.md / CLAUDE.md 适合承载持续有效、跨任务适用的事实和约定。发布流程里的细节则不同：一份 30 行的发布清单如果放在 AGENTS.md，连不涉及发布的聊天也要承担它的上下文成本。
常驻规则的价值，取决于它是否值得在无关任务中也占据上下文。
作者援引的 Claude Code 指南将根目录 CLAUDE.md 视为上下文成本较高的入口，skills 的正文则按需加载。Cursor 也有类似的作用范围选择，包括 alwaysApply、globs 和基于 description 的规则。
因此，只适用于 src/api/ 的要求，可以放进按路径生效的 Cursor rule，或者嵌套的 CLAUDE.md。把 Cursor 规则设成 alwaysApply: true，就应当接受它持续占用上下文的代价。
那些「大多数时候有用」的规则，也不必一律常驻。作者建议用描述明确的 skill，或带有清晰 description / globs 的 Cursor rule，让它在合适的任务中出现。
流程、工具和强制限制，为什么要分开放
这三类东西经常被写进同一个文件，但它们解决的问题不同。
流程回答「这件事应该怎么做」。例如发布时需要执行的 8 个步骤，适合放进 skill：任务开始时再加载完整内容，根文件只留必要的指引。
工具回答「Agent 能执行什么操作」。查询 Postgres、创建 PR，属于 MCP 或内置工具的能力范围。把 API 文档粘贴进 AGENTS.md，只能增加说明，不能让 Agent 获得可调用的工具。
强制限制回答「什么情况必须被拦下」。作者强调，Markdown 里的要求属于指导性约束。真正不能放过的违规，应交给 hook、linter 或 CI check 执行。
写下「绝不允许」，不等于系统已经具备阻止它的机制。
MCP 也需要控制加载成本。作者提醒，冗长的服务器指令和提前加载的 schema，可能在服务器保持连接期间持续消耗 token。不过原文没有区分不同客户端的加载策略，不能把这项描述直接套到所有 MCP 实现上。
另一种浪费来自重复：同一条「不要提交密钥」同时出现在 AGENTS.md、skill 和 MCP 说明里，不仅重复占用上下文，后续修改还容易产生冲突。
我的判断
我认同作者按「生效时机」分配规则的思路。比起不断往根文件追加要求，先问它何时需要出现，通常更容易维护，也更方便定位冲突。
但「仓库里能读到的内容就删掉」需要取舍。长篇架构介绍、整段复制的 README，确实不适合常驻；一些难以从代码直接推断、却会影响修改方向的约束，仍然值得留下简短说明。可发现，不代表每次都能低成本发现。
按需加载也有前提：skill 的描述和路径匹配必须足够清楚，否则节省了常驻上下文，却可能漏掉该遵守的流程。原文没有给出触发准确率、任务成功率或 token 节省比例，这部分仍是经验建议。
作者最后推荐了自己开发的 Clogmeter，称它是免费、仅在浏览器运行的检查器，可以查看 token 开销，标记重复项以及 always/never 冲突。它可以辅助盘点，但原文没有展示检测结果或准确性验证，不能据此认定整理后的配置一定更好。