哪些规则值得写进 Harness

L0 公开知识和 L1 平台能力别自建，团队只把 L2 组织特有流程和 L3 责任判断写进 Harness，并给每条规则留出退出条件。

先判断归属，再动手写。Harness 里每多一条规则，都要挤占上下文、消耗模型注意力，还要有人长期维护。规则不是越多越安全：把所有规则塞进一个巨大的单体 AGENTS.md，结果一定是它挤占任务上下文、让一切显得同等重要、迅速腐烂，还无法验证规则到底有没有被遵守 openai-harness。怎么把规则文件做成按需加载的目录而不是一次性手册，分层加载与交接包 会展开。

四层归属，写之前先判断

判断标准只有一句：这条内容在公开语料里吗？在，模型已经内化，写进去是纯浪费，还挤占本该留给任务本身的上下文 sanglard-agent-md。L1 问的是另一个问题：平台会不会自己解决？会，就等它，别重复实现。

只有两类内容不会过期

凡是在补模型能力缺口的规则，都会随模型变强而过期。「不要一次改太多文件」「先列计划再动手」这类提示，下一代模型可能天然就会；你为绕开某个模型怪癖搭的脚手架，在新模型上会成为需要维护的负担。

不会过期的只有两类：L2，因为信息不在公开语料里，模型永远造不出你的私有 API 契约、数据口径和发布流程；L3，因为责任无法转移给技术系统，验收标准和授权边界只能由人持有。团队自建 harness 的预算应该集中在这两层。

规则会自己收紧，别一开始就上机械执行

规则有一条单向的生命周期：习惯（custom）→ 建议（advisory）→ 明文（written law）→ 机械执行（mechanical enforcement）。同一条规则每次被重新违反就收紧一级，机械执行是终点形态。

不要跳过前面几级。把单次错误直接升级为全局硬规则，是规则集腐烂最快的方式——升级前要有根因分析、影响分析和回归 eval。Steve Yegge 的做法是这个机制的极端版本：他让 50–60 个 agent 自发把反复出现的约束写成可执行的「法律工件」，几个月内生出 450 个。规模听着夸张，机制很朴素——被违反第二次的规则，就该从建议变成检查 yegge-fences。

Fence 比 Sandbox 更值得建

约束有两种实现。Sandbox 收窄能力空间：把 agent 关进小黑屋，它做不了坏事，也做不了多少事。Fence 在边界处拦阻并导向正确路径：越界时拒绝，同时告诉它正确的路怎么走，边界之内保留全部自主性。

P0 约束（安全、权限、数据完整性、不可逆动作）优先做成 Fence 式的「拒绝 + 导向」。数量要少、定义要清晰、必须可自动执行，并且要有稳定的 Rule ID 与负责人——能说清是谁在什么时候因为什么加的这条规则，才谈得上删它。

约束与假设分开，指令要留退出条件

在 spec 和技术方案里把约束与假设分开写：约束（数据不能出域、接口向后兼容、延迟阈值）长期保存，并尽可能自动检查；假设接受被代码取代，不过度沉淀。

每条长期常驻指令——system prompt 规则、CLAUDE.md 条目、Skill 约束——都要声明退出条件：适用哪个模型版本范围、在什么场景触发、多久复审一次。累积的规则会互相冲突，迫使模型先花推理预算解释约束，再处理任务本身。Claude Code 为新一代模型删掉了 80% 以上的 system prompt，在 coding eval 上没有可测量的损失 agent-trend-2026。模型升级后回头审视既有脚手架的触发率、删掉不再需要的部分，是让系统从模型进步中免费获益的唯一方式。