三层机制：硬门禁、软门禁、集成验证

从两个漂移地点推出机制的具体形态。代码与载体块之间的漂按机制性质拆两层，一层用脚本，一层用模型。载体块之间的漂独立成一层，用跨块行为的预演机制。三层加起来在两个地点上都有专门机制，失效边界两两互补。

三层是两个漂移地点加机制性质的具体展开。

第一地点按机制性质拆两层

代码与载体块之间的漂移可以分成两类。结构性和语义性。两类的判定方式差别很大。

结构性漂的例子。字段类型对不上契约，函数签名跟载体规定的不符，错误码不在允许集合里。这类漂移不需要理解意思，看形状就能判断。规定是 uuid，实际是 int，就是错。规定包含 error_code 字段，实际没包含，就是漏。

语义性漂的例子。签名类型对但业务逻辑错。排序规则按相关度写成了按时间。错误处理策略写反。合并通知的模板把通过和拒稿混在一起。这类漂移看形状对，理解语义才知道错。

两类漂移都在同一个地点（代码与载体块之间），但判定所需的能力不同。结构性用脚本判断最合适。语义性只有模型判断。

硬门禁：脚本类机制

硬门禁抓结构性漂移。用脚本实现。脚本的判断是确定性的。for 循环遍历一次结果稳定。载体里规定的 checklist 有 200 项，脚本能可靠地逐项检查是否都在。载体规定 schema 字段类型是 uuid，脚本能可靠地判断代码里的字段类型对不对。载体规定 API 签名，脚本能可靠地判断签名一致性。

硬门禁能落地的前提是载体本身机器可读。载体是散文写的，脚本没有可靠的规则去 parse。载体的字段、层级、引用关系都要有明确格式，这样脚本才能起作用。载体的结构化是硬门禁的基础设施，服务的对象是脚本 parse，跟文档美观无关。

硬门禁的失效边界在语义。字段类型对了、命名对了，但字段的语义用途错了，脚本判断不出来。用户 uuid 被误用为会话 uuid，字段类型都是 uuid，脚本看不出问题，但业务上这是严重的漂。要抓这类漂需要下一层。

硬门禁的另一个特点是运行成本低。脚本跑几百条检查项只需要几秒到几十秒。这个成本让硬门禁可以跑得频繁——Agent 每次提交产出都跑一遍，抓到问题让 Agent 立刻改。这个前置过滤能挡住大量结构性问题，让后面成本更高的机制专注在结构以外的地方。下一节走通完整流程时会看到这个顺序设计。

软门禁：模型类机制

软门禁抓语义性漂移。用模型实现。模型能理解语义。给它一段载体块的意图和对应代码，它能判断代码是不是忠实实现了意图。这是脚本做不到的。

模型有 attention 承载力约束。让一个模型同时读几十页 spec 和几千行代码，做整体语义判断，它会跳读，会漏。这跟规约章讲的载体分块是同一个物理约束。有效注意力是硬上限。

在验证侧的解法是并行 subagent。每个 subagent 只审一个角度、独立 context 跑。一个 subagent 审"错误处理是否对齐载体"。另一个审"性能约束是否满足"。第三个审"接口契约的字段语义是否忠实"。每个 subagent 的 attention 集中在自己的角度上。这样避免了单模型审全部的漂。

Subagent 的数量对应载体里的意图角度数。博客案例里的一个块可能有十几到几十个意图条目，每个条目对应一个 subagent 任务。整套软门禁跑一遍要启动几十到上百个 subagent。这些 subagent 并行跑，实际墙钟时间接近最长的那个。运行成本比硬门禁高——每个 subagent 是一次模型调用——但比让人 review 便宜得多。

胥克谦对并行 subagent 有一条重要原则。他的原话是"只审不改。边审边改的不能并行"。改的动作会干扰审的独立性。审的动作要跟改的动作分离。审出报告，报告再进入下一步决策，改由另一个环节做。这样并行 subagent 的独立性才能保持。

软门禁的失效边界在跨块。每个 subagent 的 attention 是块内的。它拿的是一个块的载体和对应的代码。跨块的漂它抓不到。前端块的 subagent 看不到后端块的假设。抓跨块要另一层。

集成验证：第二地点的机制

集成验证抓载体块之间的漂移。载体块之间的漂到代码侧的表现是集成失败。前端代码基于载体里的假设产出，后端代码基于载体里另一个假设产出，两边合起来跑不通。

集成验证在合并之前预演跨块行为。前后端各在自己的泳道里跑。前端泳道里后端用 Mock 替代，Mock 遵守 API 契约的规定。反过来也一样。两边独立跑通自己的测试。然后跑真实集成，前端连到后端。跨块假设的差异在这时候暴露。

抓到之后回到载体分析。可能是载体本身的两块假设不一致（第二漂移地点），也可能是一块载体清楚而另一块代码没对齐（第一地点漂但落到跨块表现）。前者补载体，后者补代码。

集成验证的失效边界在块内诊断细节。它能发现"合不上"，抓不到具体是前端问题还是后端问题还是契约本身漏了。诊断需要回到硬门禁和软门禁的结果。

集成验证的运行成本是三层里最高的。跑一个完整用户旅程要几分钟到十几分钟。这个成本让集成验证只在硬软门禁都通过之后跑。前两层能抓的问题在低成本的层里就抓完，集成验证专注在跨块这个只有它能抓的地方。三层的运行成本递增，跑的顺序也递增，让整套验证的总成本可控。

三层的互补关系

三层的失效边界两两不重叠。硬门禁的语义盲区被软门禁覆盖。软门禁的跨块盲区被集成验证覆盖。集成验证的诊断盲区被硬门禁和软门禁的结果覆盖。

三层加起来在两个漂移地点上都有专门机制。第一地点的结构性漂由硬门禁抓，语义性漂由软门禁抓。第二地点的漂由集成验证抓。覆盖成立。

为什么恰好三层

有一个自然的问题。为什么恰好是三层。少一层缺什么，多一层多什么。

少两层的话（只有硬软），跨块行为漂没有专门机制抓。软门禁的 subagent 是块内的，抓不到跨块假设差异。跨块要专门层，独立成三层。

多一层能不能拆软门禁成"业务语义"和"技术语义"两块？可以拆，但拆出来的两块用同类机制（都是模型加独立 context），失效模式同源（都是 attention 漂）。同类失效模式的机制叠加是同类冗余，不产生新的覆盖。多的这层不产生新的漂捕捉能力，只多一份运行成本。

三层对应两个漂移地点加代码与载体之间的两类机制性质。少一层缺覆盖，多一层是同类冗余。

Harness Engineering Playbook · AgentsZone Community