上一节推出验证责任要从人转移到机制。这一节问一个更具体的问题：机制承担什么责任才能可信。
答案的第一步是把机制要防的东西列清楚。机制防的东西是漂移。漂移是产出偏离意图的地方。要机制可信，先要知道漂移可能在哪里发生。漂移空间不清楚，机制承担的责任就模糊。责任模糊的机制没法可信。
漂移的第一个地点：代码与载体块之间
Agent 拿到一个载体块，产出代码。载体块规定了这一块的意图。代码是意图的实现。两者之间可能有偏离。
偏离的具体形态有几种。代码的函数签名跟载体规定的契约不符。数据库 Agent 的 SQL 字段类型规定是 uuid，实际写成了 int。前端 Agent 的用户交互规定了三步操作流程，代码里实现成了两步跳过中间步骤。业务逻辑规定的排序按相关度，代码里排序按发布时间。错误处理规定的策略是抛异常，代码里返回了 null。
这些都属于代码没有忠实实现载体块。这是漂移的第一个地点。所有的漂在这个地点都发生在一个块的边界内。要判定漂就看这个块的载体加对应代码，两个东西对不对齐。
第一个地点的漂本身可以再细分。有的漂能不理解意思就判断，比如字段类型不匹配。有的漂需要理解意思才判断，比如排序规则反了。两类漂的判定方式差别很大。前者用脚本判断最合适，后者只能用模型判断。下一节会讲到怎么按这个差别拆机制。这一节先把两类都归到”第一漂移地点”这个更粗的分类里。
判定第一地点漂的操作性特点是”块内自足”。给你一份载体块加一份对应代码，不需要看别的块，就能判断这两个东西对不对齐。载体块自己规定了这一块的意图，代码是实现，两者的关系是封闭的。这个封闭性让第一地点的判定可以块内进行，不涉及跨块协调。
漂移的第二个地点：载体块之间
规约章建立的自足性推出载体块之间有冗余。一条决策被自足到多个块里。冗余的地方要保持一致。共同产出流程里有一致性检查，但检查会漏。载体本身可能就漂了。
不一致的具体形态。前端块的 API 契约说 session 用 cookie 传，后端块的 API 契约说 session 用 header 传。schema 块规定 reviewer_id 是 uuid，产品交互块的 UI 状态图里 reviewer_id 类型隐含成整数。两个块的意图错位。基于错位的载体块产出的代码互相不匹配。
这是漂移的第二个地点。它跟第一个地点的性质不同。第一个地点的漂在单块内可以判断，一份载体加一份代码就够。第二个地点的漂只有跨块看才能判断，需要同时对比两个块的意图，或者观察两个块产出的代码集成起来的行为。
第二地点的漂常常隐藏得很深。每一块单独看都自洽——载体块规定了假设 X，代码块按 X 实现，两者对齐。另一块单独看也自洽——载体块规定了假设 Y，代码块按 Y 实现，两者对齐。只有把两块合起来才发现 X 和 Y 冲突。这种漂在单块内检查里永远抓不到。
第二地点的漂还有另一种表现。载体本身没有明确规定某条决策，两块的载体都留了空白。基于空白，两个 Agent 各自猜了一个方向做实现。两块产出的代码也是各自内部自洽的，但对空白的两种猜测相互不兼容。这种情况比”载体两块直接矛盾”更常见。因为载体不完备的地方往往是共同产出流程里没抛出来的决策点。抛不出来是因为大模型没意识到需要人做判定。这种未识别的决策点最后往往落在跨块契约上。
两个地点覆盖所有漂移
到了本章的时候，漂移空间的其他部分都已经处理过。意图形成阶段的漂在规约章的共同产出流程里处理。载体块生成阶段的漂也在规约章处理。这一节的起点是载体在手、多个 Agent 已经从载体产出代码。这个起点之后，漂只可能在两个地方发生。要么代码没对齐载体，要么载体块之间自己就漂了。
两个地点组成完整的漂移空间。机制要可信，必须在这两个地点都有覆盖。
可信度来自失效边界显式的机制组合
有了漂移空间的两个地点，机制的可信问题就有了具体形状。要构造一套可信的机制，需要满足两个要求。第一，每个地点都要有专门机制覆盖。第二，每个机制的失效边界要能陈述清楚。
第一个要求是覆盖问题。没有专门机制的地点是覆盖漏洞。任何漂在漏洞地点发生都逃过机制，最终落在产出上。
第二个要求是可信问题的核心。每个机制都有失效场景。脚本类机制在语义问题上失效。模型类机制在长上下文里 attention 漂。机制失效是机制类型的固有属性，跟设计的好坏无关。要判断机制组合能不能覆盖两个地点，必须知道每个机制的失效边界。
举个例子看这个逻辑。A 机制声称覆盖代码与载体之间的漂。它的失效场景是不理解语义。B 机制也声称覆盖同一个地点，失效场景是长上下文里注意力漂。A 的语义盲区落在 B 的可靠区，B 的注意力漂落在 A 的可靠区。A 加 B 的组合在这个地点上有覆盖。这就是失效互补。
想清楚 A 和 B 是不是互补的前提，是 A 和 B 各自的失效场景已经明确陈述。失效边界陈述不清的机制没法进入互补组合。它承担的责任落在模糊范围里，可信度就是零。
失效边界陈述这件事的操作性要求也要说清楚。陈述失效边界不是加个免责声明，比如”本机制在某些情况下可能失效”。这类模糊陈述没意义。有意义的陈述要具体到”本机制抓 X 类漂移，不抓 Y 类漂移”，X 和 Y 都用可辨识的描述给出。比如硬门禁的失效陈述可以是”抓字段类型、签名、格式规则等结构性问题；不抓语义误用，比如字段类型正确但业务用途错的情况”。这样的陈述让互补分析能操作。任何两个机制放在一起，能明确说出一个的 Y 落在另一个的 X 里。
下一节把这个逻辑落到具体的三层机制上，说明为什么恰好是三层、每层的失效边界在哪。
Harness Engineering Playbook · AgentsZone Community