哪些规则值得写进 Harness

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

先判断归属，再动手写。Harness 里每多一条规则，都要挤占上下文、消耗模型注意力，还要有人长期维护。规则不是越多越安全：把所有规则塞进一个巨大的单体 AGENTS.md，失败来得很快 openai-harness。怎么把规则文件做成按需加载的目录而不是一次性手册，分层加载与交接包 会展开。

四层归属，写之前先判断

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

只有两类内容不会过期

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

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

先看再写，L2 才生效

L2 规则最常见的失效方式不是被违反，而是被绕过：模型不知道项目里已经有什么，每次都从零新建——组织惯例写了一百条，模型第一百零一次生成重复实现。所以在新建组件、工具函数、词条或任何可复用产物之前，必须先检索项目中已有的同类实现：命中则复用并在新代码中引用，而不是复制；未命中再新建。

检索范围至少覆盖同目录同类组件、公共函数目录（utils/、composables/、hooks/）、i18n 词条表、类型定义与枚举。更重要的是执行方式：靠模型自觉等于没写，这条流程应该通过 Skill 或 Hook 强制——比如在文件创建后自动跑一次同类检索，命中相似实现就提示复用。这条规则是 L2 得以生效的前提：只有先看见项目里已有什么，组织惯例才能被遵循而非被绕过。

动笔之前，先看一眼仓库外

检索半径不止自己仓库。在动手实现一个功能之前，先让模型去外部查一遍，看有没有现成的开源实现或别人已经跑通的技术路线。理由是同一套归属判断：公开仓库里的成熟方案就是 L0——它已经在公开语料里，模型用不着重新发明，你也不该花预算重造一个更差的。

这条的判断落点是「先查」，不是「照抄」。查得到不等于该用：接一个现成方案要付学习成本、许可证审查和依赖维护成本，它的接口还会按上游节奏变化；自己写则要付开发成本和长期维护成本。所以真正的动作是分别估算两边，再决定哪边便宜——这和选能完成需求的最低复杂度是同一个动作，只是对象从「用哪个方案」换成「要不要自己写」。

判断顺序也重要：先判断整体能不能直接用，再判断哪一部分值得参考。功能完整、上游还在推进的方案可以直接拿来做骨架，只改自己独有的那部分；只解决了一个子问题的方案，取它的思路通常比搬它的代码划算。

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

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

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

还有一条比「收紧」更常被忽略的纪律：规则不要堆在一个文件里常驻，按阶段切片。 一个团队的真实教训是，他们把开发步骤列成清单让 AI 照着走，AI 总忘步漏步，于是不断加规则，不到一个月从五百多行涨到八百多行，开头还加了五条「违反任何一条即为失败」的铁律——结果规则越多 AI 越不听话。原因是结构性的：上下文里塞的东西越多，每条规则分到的注意力越少，最要紧的那几条反而被埋掉。改法是给 17 个阶段各写一份规则片段，进哪个阶段才加载哪一份，模型每一步只看到当前阶段要守的那几条 tencent-800-rules。

现在已有研究把这条路径自动化了。Google Research 开源的 Harness² 把可改的 Harness 拆成八类组件（系统提示词、护栏、记忆、工具指导、子智能体、Skills、脚本、插件），用两层递归改进它们：任务内「提出—探测—组合」——生成多个修改方案、让它们跑同一个任务、比较行为差异再组合；任务之间维护一个持续存在的改进 Harness，保存有执行证据的经验。它的关键设计是不要求任务有标准答案，用执行差异代替 ground truth，仅一步优化就让工作台基准最高提升 11.5 分 harness2。

但这条路的代价必须一起看。每增加一轮递归，都是为同一个任务运行更多候选 agent 与模型调用——用测试时计算换成功率，不是免费的改进。更值得记住的是社区里一个反面样本：有人用 8 个月、883 次提交搭一套 Harness，不断加入代码图、RAG、确定性编排、隔离 worker、崩溃恢复、模型路由、回放、验证门禁与自我改进实验，最后维护 Harness 本身的时间超过了真正使用 agent 的时间。所以判断标准不是「能不能自动改进」，而是「改进带来的收益是否超过维护这套机制的代价」——这条和本节开头那句「被违反第二次才收紧」是同一个道理，只是作用在 Harness 自己身上。

Fence 比 Sandbox 更值得建

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

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

有一条边界比 fence 更硬：约束要设在模型改不动的地方。 提示词、hooks、配置文件都是 agent 能读、极端情况下能改写或无视的软约束，它们只能提高先天合规率；真正的强制点应落在网络、会话、系统层这类绕不过的执行点。相应地，规则文件里「禁止做 X」的条款，如果 X 有副作用且参数可枚举，就应该同时落成确定性校验——反面案例是投产通知的推送目标：目标参数为空时底层接口默认群发，一条「记得校验目标」的提示词拦不住，只有「缺省即拒发」的断言拦得住 tencent-harness-safety。

同一条判断也适用于门禁本身：策略即代码，门禁脚本要像被测代码一样写单测并纳入 CI 回归，否则换一次模型或改一次提示词，某道防护可能已经失效而没人知道。

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

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

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