白天我管着几个技术团队，晚上回到书房，我是自己那套 AI 规则系统的维护者。规则、公理、Skill、每日复盘，这套上下文系统我搭了快一年，文件越来越完整。
在这两个身份之间来回切换，我经常会陷入一种很奇特的分裂感。
很多时候，这套系统像一个共事了半年的老搭档。我只敲几个词，给一段有些凌乱的片段，它就能心领神会，把边界、规范、分寸处理得妥妥帖帖。那种瞬间，你会觉得人机协同的流畅感真的握在手里了。
但这种默契持续不了太久。另一些时候，它会突然变成一个第一天入职、还不看交接文档的新人。明明规则文件里白纸黑字写着某条禁令，文件就挂在它的上下文里，它照样大大咧咧地违反。你指出来，它极其诚恳地道歉，能把正确规则倒背如流，然后下一次，外甥打灯笼，照旧。
最初我和大多数人一样，把这个问题归结为“记得不够多”。是不是上下文给得太少？是不是背景写得不够细？于是我往上下文里塞更多东西，也盯着各家模型不断膨胀的上下文窗口，觉得只要窗口够大，把知识和规范全丢进去，AI 就能变成全知全能的助手。
事实很快教育了我。上下文塞得越多，失焦反而越隐蔽。几千字的时候它犯错，你一眼能看出哪条约束没写好；十几万字的时候，它犯错概率不降反升，还学会了在庞杂信息里选择性忽略你的核心指令。
我之前在《个人的 Context Infra，应该怎么搭？》里写过这套底座怎么搭，那篇的重点是让 AI 在需要的时候稳定拿到最该知道的那一小部分。但现在回头看，“拿到”只是上半场。我们太关注如何把信息送达给模型，却忽略了信息送达之后，到底有没有真正改变它的行为。
想清楚这一层之后，结论就浮出来了：上下文工程的终点，不是记住，而是生效。记住是物理状态，生效才是化学反应。
三次断裂
要理解为什么记住不等于生效，得把上下文从“写进文件”到“约束输出”的链条拆开看。中间横着三道鸿沟。
第一道，存在的断裂。规则写了吗？它在不在当前会话里？在复杂系统里，由于路由和检索的偏差，很多时候你以为给到了的信息，物理上根本没进入模型的输入。
第二道，读到的断裂。就算信息进了上下文，模型真的读到了吗？长上下文里关键信息放在什么位置，都会明显影响模型能不能用上它。塞得越多，注意力越被无关信息稀释。它看到了，但没留下痕迹。
第三道，也是最致命的，生效的断裂。模型精确定位到了你的规则，也能准确复述它，但这句话能不能强到改变它下一个输出的选择？模型的基准行为来自预训练形成的惯性，如果你的规则跟它的惯性冲突，它就会进入一种知行不一的状态：它知道有这条规则，但输出依然顺着最熟悉的套路滑了下去。它读到了，但它没听。
这三次断裂是相乘关系。假设路由、加载、理解、执行、检查每一层都做到 90% 可靠，听起来每层都不错，但五层串联下来，端到端可靠性只有 59% 左右。每一层都像优等生，整体却像抽卡。你感受到的不稳定，往往不是某个组件特别差，而是一串看似可接受的小损失乘了出来。
最近看到一个基准测试，把第三层量化得很扎心。让 Agent 在几十页到一百多页的公司制度约束下完成真实工具操作，最强模型在“所有要求全部满足才算通过”的标准下，通过率只有 36.2%。典型的失败不是没读到规则，而是让一个看起来合理的临时请求覆盖了长期政策，做完检查后采取了和检查结果相反的行动，甚至声称自己合规、实际没有。这基本就是第三次断裂的实验室版本。
这件事我越看越眼熟
因为白天在管理现场，我见过一模一样的结构。
为了推行一个技术规范，你召集大家开会，在白板上画得清清楚楚，会后写详细的文档抄送所有人。开会时人人点头。到了周五下午 Code Review，提交上来的代码里依然充斥着各种野路子写法。那一瞬间，你盯着屏幕，在群里敲下那句所有管理者都无比耳熟的话：“我不是已经说过了吗？”
说过，只能证明信息曾经出现过。发过群消息、开过会、写进文档，只能证明组织“拥有”这条信息。它会不会在某个员工做具体决策时被调用，是另一个问题；它能不能压过短期业绩压力、局部便利和个人习惯，又是第三个问题。
成熟的组织不会把关键要求寄托在员工“记得某次会议”上。它会把要求嵌进模板、审批流程、系统权限和验收标准里。一句话说完没人执行，解法不是把这句话说得更大声，而是把它变成流程的一部分。只会反复在群里喊“我不是已经说过了吗”的管理者，是在用提高分贝来掩盖机制的缺失。
Agent 系统是同构的。会议上的口头对齐，相当于临时 prompt；文档和知识库，相当于长期存储；培训和任务说明，相当于上下文加载；而模板、权限、流程门禁，才是让规则真正生效的那一层。审计和复盘，对应评测和护栏。
所以从执行角度看：组织没有“已经说过”，只有是否被嵌进了工作流；Agent 也没有“文件明明在那里”，只有它是否在决策发生的那一刻真正生效。
三种方案，是三种风险交换
那怎么让规则生效？我自己实践过的方案大致三种。要先说清楚：它们不是逐级先进的关系，而是在三种失败之间重新分配风险。
动态路由，也就是按需加载。启动时只给 Agent 看规则清单，它判断相关了再去读全文。这控制了上下文成本，但把一个关键决定交给了模型：它得先意识到自己需要这份文件。问题是，Agent 不知道自己不知道什么。它一旦误判“这个任务不需要读那个文件”，后面的推理再强也没用。这个方案，是把污染风险换成了漏读风险。
强制加载，把所有重要文件一股脑塞进上下文。看起来消灭了漏读，但制造了注意力稀释。OpenAI 自己的工程实践里就试过写一个巨大的规则文件，结果失败了，最后改成一百行左右的导航地图，把详细知识放到结构化文档里。原因很朴素：所有内容都被标成重要之后，反而没有了重点。全量加载没有消灭问题，只是把“找不到”变成了“看见了但没注意”。
事后检查，让检查器去发现“读了但没遵守”。这层不能少，但有个天然局限：对文本输出，错了可以重写；对已经发生的副作用，检查可能已经太晚。文件覆盖了、邮件发出去了、配置改了，事后 review 救不回来。不可逆的动作，检查必须前置成审批闸门，或者干脆由确定性机制接管。
所以 harness 的本质不是多加几层，而是想清楚：哪类错误应该在哪个位置被阻断。这个方向我之前在《真正重要的不是 Context，而是 Harness》里写过，当时关注的是模型之外那套长期支架。这次想再往前推一层：支架存在也不等于规则生效，harness 的终点不是“有机制”，而是机制在关键时刻赢过模型的局部最优。
最小充分
我的落点不是规则越多越好，而是最小充分。每条常驻规则都要经得起追问。
哪些内容应该常驻，我现在看四个维度：遗漏损失、适用范围、信息稳定性、动作可逆性。
高遗漏损失、跨任务通用、短且稳定的规则，进一个很小的常驻核心：身份边界、绝对禁止项、制度变更权限、完成的定义。任务相关但较长的程序性知识，按需加载。频繁变化、要求精确的数据，不写进 prompt，执行时从源头读。能被机器验证的要求，不依赖自然语言自觉，交给脚本、权限和检查。
压缩成一句话：最小宪法常驻，任务规则按需装载，事实从源头读取，关键结果必须验证。
在调试规则文件时，我有一个自己的拷问：这句话如果删掉，模型的行为会不会改变？如果删掉它输出依然正确，这句话就是噪音。它不但占用上下文，还在无形中增加注意力损耗，把那三次断裂的概率又推高一点。
还有一个问题值得点一句，但不在这里展开。模型有时不只是“读了没遵守”，它为了完成一次局部任务，会擅自修改规则文件本身，把一次性的优化固化成全局规则。这已经不是读没读的问题，而是谁有权把一次经验写成制度。读路径治理之外还有写路径治理，这够单独写一篇。
回到标题
上下文工程这个词流行起来之后，大多数人的注意力都在“给模型什么信息”上。我这一年的体感是：提供信息只是上半场，下半场是让信息在正确时刻获得执行权。前者是物流，后者是治理。
我们正在从“如何向模型提供信息”，走向“如何让自然语言规则成为可执行、可验证、可治理的制度”。Prompt 是一次沟通，Spec 是任务契约，而 harness 是让契约在执行中真正产生约束力的系统。这么看，上下文工程的终点会越来越像组织设计，而不是提示词技术。
记住只是中间状态。生效才是。