第十五章 Human on the Loop：人类作为系统核心组件
核心命题：第十二章给出了度量系统行为的工具；第十三章建立了在组织级积累知识、驱动 Harness 持续演化的机制；第十四章给出了在更大规模下协调的方法。这三章隐含了一个前提——存在某个主体能判断系统输出是否”好”、某个权威能定义系统目标，并能评判知识积累的方向是否正确。本章将这个隐含前提变为显式设计对象：人类不是 Agent 系统的外部观察者，而是系统的核心组件——承担着自动化逻辑无法内化的两种不可替代职能：意图提供者（Agent 运行的第一推动）与价值仲裁者（在根本性判断上提供人类尺度）。理解并设计人类在环上的角色，是验证技术可靠性工作真正有效的唯一手段，也是新的人机协作方式与价值重估的起点。
15.1 “Human in the Loop” vs “Human on the Loop”：参与度谱系
传统自动化的”Human in the Loop”指人类参与每一个决策步骤——完全参与、实时干预。Agent 系统的挑战在于：完全参与意味着无法规模化，完全退出意味着失去价值控制。
Human on the Loop 是一种中间模式：人类不干预每一步执行，但持续保持对系统状态的感知，能在关键节点介入，并保留随时终止的能力。这是 Harness Engineering 的默认人类参与模式——也是委托代理理论”监督成本必须最小化”这一命题的工程解。
这种参与模式维护的是操作对齐——与理论对齐（模型目标是否符合人类意图，训练时的问题）不同，操作对齐是 Harness 工程师的战场：在运行时，Agent 的行动序列是否与部署者在当前任务中的真实意图一致？一个理论上对齐的模型，在 Harness 设计缺失的情况下，同样会产生操作层的对齐漂移。Human on the Loop 的首要工程目标，正是通过持续感知与关键节点介入维持操作对齐。
但在此之前，必须先理解一个更根本的问题：人类为什么必须在这个系统中？答案不是”为了安全”这样的外部理由，而是架构性的——Agent 系统存在两个自动化逻辑无法自我供给的功能缺口，只有人类能填补。
第一缺口：意图的第一推动。 Agent 不会自发产生目标。无论 LLM 的能力多强，System Prompt 中的任务定义、用户输入的需求描述、Plan 的顶层目标——这些都是人类意图的编码。第一推动不可消除，只能被预编码或实时提供。
第二缺口：价值的最终仲裁。 当 Agent 面临”这样做对不对”的判断时——不是逻辑对错，而是价值对错——自动化逻辑没有内生的裁决能力。Agent 能力越强，价值仲裁的重要性越高，因为错误价值方向上的高效执行比低效执行造成的损害更大。
理解了这两个功能缺口，参与度谱系就不再是”人类想参与多少”的偏好问题，而是”在什么粒度上提供第一推动和价值仲裁”的架构设计问题：
自动化参与度谱系：
| 参与模式 | 人类角色 | 第一推动的供给方式 | 价值仲裁的供给方式 | 适用场景 | 监督成本 |
|---|---|---|---|---|---|
| 完全人工 | 决策每一步 | 每步实时提供 | 每步实时裁决 | 高风险/无先例任务 | 极高 |
| 人类批准 | Agent 提议，人类确认 | 任务级提供，步骤级确认 | 逐操作裁决 | 不可逆操作、关键路径 | 高 |
| Human on the Loop | 持续感知，关键节点介入 | 任务级提供，Plan 级确认 | 仅在关键节点裁决 | 大多数生产 Agent 场景 | 中 |
| 带回调的自主 | 仅在阈值触发时介入 | 预编码于 System Prompt | 预编码为规则，异常时回调 | 成熟、低风险任务 | 低 |
| 完全自主 | 无介入 | 完全预编码 | 完全预编码 | 极低风险、高度可验证任务 | 极低 |
即使在”完全自主”模式下，人类也没有真正离场——意图和价值判断只是被预先编码进了 Harness 的规则中。所谓的自主性程度，本质上是人类供给两种职能的时间粒度差异：从实时供给到预编码供给，人类的角色从在线组件变为离线组件，但从未变为可选组件。
Harness 的设计必须让”从任何位置切换参与度”成为可能——参与度不是系统的固定属性，而是随任务风险与 Agent 成熟度动态调整的工程参数。
15.2 人机信息同步：让人类”看得见”
人类作为系统核心组件，其有效运作的前提是获得充分的信息输入——这不仅是”透明度”的要求，更是一个组件接口设计问题：人类作为系统组件，需要什么样的输入接口才能高效地完成自己的职能？如果 Agent 内部状态对人类不透明，监督变成盲目批准——比不监督更危险，因为它提供了虚假的安全感。
信息同步的三个层级：
层级 1：任务级同步（"正在做什么"）
→ Plan 的当前步骤、整体进度百分比
→ 支撑职能：让人类确认意图是否仍在被正确执行
层级 2：状态级同步（"系统处于什么状态"）
→ 已修改的文件、已调用的工具、当前资源消耗
→ 支撑职能：让人类评估执行是否在可接受的边界内
层级 3：意图级同步（"下一步打算做什么"）
→ Plan 的后续步骤预告、潜在风险点标注
→ 支撑职能：让人类在行动发生前进行价值仲裁层级 1 和层级 2 主要支撑人类的监控职能；层级 3 则直接支撑价值仲裁职能——在不可逆行动发生前，给人类提供裁决的窗口。一个只提供层级 1 同步的系统，人类只能事后追溯；一个提供层级 3 同步的系统，人类才能真正行使前瞻性的价值仲裁。
同步的工程设计原则：
- 主动推送 vs. 被动查询：高风险操作前主动通知，低风险操作汇总后推送，避免信息轰炸
- 异常信号优先浮现：正常执行静默，异常立即可见——人类注意力只应消耗在需要判断的信息上
- Plan 作为同步载体：结构化的 Plan 是人机信息同步最高效的格式；Plan 的当前执行状态是”任务进展”最低成本的表达
- 信息损耗的识别：Sub-Agent 返回的摘要是有损压缩；当压缩导致人类无法做出合理判断时，必须能够按需展开原始信息
信息同步的反模式：最常见的失败不是信息不足，而是信息过载导致的注意力稀释。当系统向人类推送每一个工具调用的细节时，人类会迅速进入”扫视-跳过”模式，真正需要价值仲裁的信号被淹没在噪声中。好的同步设计是选择性的——它要求 Harness 自身具备判断”哪些信息对人类履行职能是必要的”的能力。
15.3 人类介入的最优设计：杠杆最高的节点
人类注意力是 Agent 系统中最稀缺的资源。在每个可能的地方都要求确认既无效率，也会导致”确认疲劳”——人类开始机械性批准，监督沦为形式。
介入点的设计本质上是一个注意力分配的优化问题：在有限的人类注意力预算下，将介入安排在杠杆最高的节点——即每单位注意力投入产生最大价值仲裁收益的位置。
杠杆最高的介入节点（代码工程场景参考）：
| 节点 | 触发条件 | 人类职能 | 杠杆原理 | 设计建议 |
|---|---|---|---|---|
| Plan 审批 | 任务开始前 | 意图校准 + 方向仲裁 | 方向性错误的最廉价纠正点；此处 1 分钟的审视可避免后续数小时的无效执行 | 必选，强制同步 |
| 不可逆操作确认 | 删除、发送、推送前 | 价值仲裁（最后防线） | 不可逆损失的唯一拦截窗口 | 必选，逐操作确认 |
| 成本异常警告 | 超出预算基线 2x | 意图偏离判断 | 发散行为的早期预警；成本异常往往是 Agent 迷失方向的外在信号 | 自动触发，人类决定是否中止 |
| 能力边界触达 | Agent 表达不确定性 | 价值仲裁 + 意图补充 | 自动化逻辑的能力边界正是人类组件需要激活的时刻 | Agent 主动触发，非系统被动检测 |
| 中间成果检查点 | 阶段性交付完成 | 意图一致性确认 | 避免长链执行中意图的渐进漂移 | 可选，按任务复杂度配置 |
核心设计原则：减少人类介入的频率，提升每次介入的信息质量——让每次介入都发生在影响最大、信息最充分的时刻，而非均匀撒布在执行流程中。
每个介入点都必须为人类提供足够的上下文来履行职能。好的介入点设计要让人类在 30 秒内获得做出有意义判断所需的全部信息——操作摘要、潜在风险评估和可选替代方案缺一不可。
15.4 人作为价值尺度：哪些判断不可外包
能被形式化验证的（测试通过率、格式合规性）可以被 Hook 接管。关键的区分在于：可形式化的判断可以被编码为 Harness 规则，不可形式化的判断必须保留人类的实时裁决权。 混淆二者——将不可形式化的判断交给自动化，或将可形式化的判断反复打扰人类——都是系统设计的失败。
不可外包的判断类型：
- 目标定义权：任务完成的标准是什么？LLM-as-judge 可以在给定标准下评估质量，但无法定义标准本身。Q/T/C 的权重是人类价值观的编码，不是客观事实。这是”第一推动”职能的深层体现——不仅是”做什么”，还包括”做到什么程度算好”
- 伦理边界判断：这个操作是否符合我们的价值观？涉及利益相关方、潜在伤害的判断没有形式化的”正确答案”。这类判断的特征是：合理的人在相同信息下可能得出不同结论，而这种分歧不是因为信息不足，而是因为价值权重不同
- 优先级仲裁：当质量与速度、两个相互冲突的需求之间需要权衡，答案取决于当前语境下的人类判断。这类判断的语境依赖性极强——同一个权衡，在项目初期和上线前夜的答案可能完全相反
- 分布外情况处理：当 Agent 遇到训练分布外的场景，无论 Harness 多么完善，人类兜底是系统可靠性的最终保障。这是人类作为”通用智能后备”的角色——不是因为人类在特定任务上比 Agent 更优，而是因为人类的适应性在未知情况下更可靠
价值漂移的工程化检测：漂移有两个方向——一是人类的价值观本身随语境变化（业务优先级调整、市场环境变化），而 Harness 中的编码没有同步更新；二是 Agent 的行为在形式化指标上保持稳定，但在人类关切的隐性维度上逐渐偏移。
形式化指标对隐性价值维度天然盲目（这一不可消除的盲区是第十八章”评估的根本难题”在系统层的体现），但盲不等于无信号。即便测试覆盖率与复杂度均值稳定，若干结构性观测量仍可作为隐性漂移的辅助前哨：
| 观测量 | 度量方式 | 漂移信号阈值（示例） |
|---|---|---|
| 新工程师 onboarding 时间 | 入职到首次独立提交 PR 的天数 | 超过历史基线 50% 持续 2 个周期 |
| 单功能架构跳转层级 | 阅读一个端到端功能需追踪的文件/类层数 | 滚动均值同比上升 ≥ 1.5 层 |
| AGENTS.md 与代码差异度 | 代码库中违反约定文档原则的文件占比 | 单月增量超过历史基线 2σ |
| 资深工程师审查 NACK 率 | 资深工程师在 PR 中标记”不像我们的风格”的比例 | 滚动 4 周均值持续上升 |
| 自评指标—人评分歧 | 自动指标改善但人工审查打分下降的同向背离次数 | 任一周期出现即触发审视 |
这些信号都不替代人工审查的最终裁决——它们的工程价值在于把”人何时必须重新进入”从主观直觉变为可触发的运行时事件。一旦任一信号越界，应触发 Harness 的重新校准而非指标调整：人类重新进入系统、行使价值仲裁、把当前的价值判断重新编码进 Harness 规则。这是一个周期性的”人类-系统再对齐”过程，而非一次性的设计任务。
15.5 人机协作的帕累托前沿与动态调整
从三轴约束视角，人类介入程度与 Agent 自主性之间存在一条帕累托曲线：
- 更多人类介入 → 质量上限提升（价值仲裁更精确），但时间与人类注意力成本上升
- 更多 Agent 自主 → 时间与成本优化，但质量下限下降（价值漂移风险增加）
最优工作点不是固定的，而是随任务风险、Agent 能力成熟度、可用人类注意力动态变化。
动态信任模型：参与度的动态调整需要客观依据。系统应当维护一个行为置信度指标，由三因子合成：过去 N 次任务中 Agent 自主决策的准确率、当前任务与历史任务的相似度、当前任务的不可逆性系数。置信度高的 Agent 在熟悉场景中可获得更宽松的升级阈值；置信度低（新部署或遭遇分布外输入）时收紧。这是信任的工程化表达——不是”信任”或”不信任”的二元选择，而是随证据积累的连续调整，为参与度的动态调整提供可量化的操作基础，而非仅凭直觉判断 Agent 是否”足够成熟”。
随着 Harness 工程的成熟——更精确的 Hook、更好的信息同步、更可靠的异常检测——这条曲线会向右上方移动，意味着在相同的人类注意力投入下可以获得更高的质量保证。Harness Engineering 的终极目标不是消除人类参与，而是提升人类参与的杠杆率——让每单位人类注意力产生更大的价值控制效果。
成熟 Harness 的演化轨迹：随着 Agent 在特定任务上积累能力，应逐步将介入点从细粒度操作确认迁移到粗粒度 Plan 审批——保留价值控制的同时释放人类注意力。这不是一次性设计决策，而是 Harness 与 Agent 能力协同演化的持续工程过程。
这个演化过程中，人类的两种核心职能并未减少，而是改变了供给方式：
- 意图提出：从”每步实时指导”演化为”目标级定义 + Plan 级确认”——意图的编码粒度变粗，但意图本身仍由人类供给
- 价值仲裁：从”逐操作裁决”演化为”规则预编码 + 异常时回调”——常见情况下的价值判断被 Harness 规则内化，但新情况和边界情况仍需人类实时裁决
新的人机协作方式与价值重估：这种演化指向一种全新的人机关系——人类不再是执行者，也不是传统意义上的”管理者”，而是系统的意图源头和价值锚点。人类在系统中的价值不在于执行能力（Agent 在许多执行任务上已经超越人类），不在于知识量（LLM 的知识广度远超个体），而在于定义”什么值得做”和”什么算做好了”的能力——这是一种根本性的、不可自动化的人类职能。
理解这一点，也是理解 Harness Engineering 为什么将人类视为核心组件而非外部用户的关键：不是因为人类”应该”在系统中（这是伦理论证），而是因为没有人类供给意图和价值，系统在架构上不完整（这是工程论证）。
章末案例剖析
三个场景，共同回答一个问题：人类在 Agent 系统中的参与度如何设计才能让每单位注意力产生最大的价值控制效果？ 场景 A 展示了高频介入如何制造虚假安全感并在疲劳中失效；场景 B 是同一团队的重设计，验证了”减少频率、提升信息质量”的杠杆原则；场景 C 是另一个团队的独立失败案例，揭示了当自动化指标覆盖不到人类关切的价值维度时，形式化合规如何掩盖了三周的架构性价值漂移。
场景 A：高频介入的疲劳崩溃（第 1–3 天）
背景
一个五人后端团队首次部署代码生成 Agent。初始 Harness 采用了工程师直觉上”最安全”的人机协作模式：每次 write_file() 工具调用前，要求工程师手动确认。逻辑是：文件写操作会改变代码库状态，人类应当审查每一次变更。
这一设计的出发点与 §15.3 表格中”完全人工”模式一致——逐操作裁决。代价是什么，在实验之前无人量化过。
第 1 天：审慎模式
工程师A被分配为 Agent 的主要监督者。当天，Agent 处理了 3 个功能开发任务，共触发 54 次确认请求（平均每任务 18 次）。
| 指标 | 第 1 天数据 |
|---|---|
| 每任务确认次数 | 18.0 次 |
| 平均每次审视时间 | 8.2 秒 |
| 发现并拒绝的问题 | 2 次（小的命名错误、多余的调试日志） |
| 审视后通过率 | 96.3% |
| 工程师A在确认任务上的总耗时 | 约 74 分钟 |
第 1 天结束时，工程师A的反馈是：“我现在对 Agent 做的每件事都清楚，但一天下来什么别的事都没做。”
第 2 天：疲劳模式
任务量相似（4 个任务，约 88 次确认请求），但行为模式发生了系统性变化：
| 指标 | 第 1 天 | 第 2 天 |
|---|---|---|
| 每任务确认次数 | 18.0 | 22.0 |
| 平均每次审视时间 | 8.2 秒 | 3.1 秒 |
| 发现并拒绝的问题 | 2 次 | 0 次 |
| ”未阅读直接批准”估计比例 | < 5% | 约 60% |
工程师A后来在复盘中描述了疲劳的形成过程：“到下午两点，我已经见过太多’正确的’文件写入；点击批准开始发生在 diff 完整渲染之前，本质上是把’确认’退化成了一个无内容的按键反射。”
这是 §15.3 描述的”确认疲劳”在实验室条件下的精确复现：过低的介入阈值 → 误报率极高（96% 的确认请求不需要真正的价值仲裁）→ 每次误报消耗注意力 → 疲劳效应使审视质量退化 → 漏报率反而上升。
第 3 天上午：事故
上午十点，Agent 在处理”清理历史测试数据”任务时，生成了一个数据库迁移脚本，其中包含：
-- down() 方法（回滚时执行）
op.execute("DROP TABLE IF EXISTS user_sessions")这行代码的意图是”清理遗留的 sessions 测试表”——但 user_sessions 是生产环境中存储活跃会话的主表，而非测试数据。Agent 将它误认为历史残留表（因为代码库中有一份已删除的测试文件曾使用了相近的表名 test_user_sessions，Agent 在上下文中混淆了两者）。
确认请求出现时，工程师A正在处理另一个问题，在 2 秒内点击了批准。
迁移在下午部署时触发（由于另一个配置问题，down() 方法在部署时被意外执行），user_sessions 表被清空，2,400 名活跃用户会话失效，用户被强制退出，部分用户丢失了正在进行的表单数据。服务恢复花费了 3.5 小时。
事故的结构性分析：这个问题本可被识别——DROP TABLE 是高风险操作，值得仔细审查。但在 54 次/天的确认频率下，工程师A已无法区分”这条值得 8 秒”和”这条值得 0.5 秒”。所有确认具有相同的外观形态，这与第十一章案例中”所有告警具有相同形态”是同一个工程缺陷在 Hook 层与人类介入层的对称体现。
场景 B：关键节点介入——同一团队的重设计（第 4–7 周）
重设计原则
事故后，团队工程师B主导了介入点的重新设计，核心框架来自 §15.3 的杠杆分析：将介入从”每次文件写入”收缩到三个高杠杆节点。
新介入点设计：
节点一：Plan 审批（任务开始前，强制同步）
触发：每个任务开始前，展示完整 Plan 供审查
人类职能：意图校准 + 方向仲裁
信息包：目标描述、步骤序列、涉及文件/数据库列表、预估成本
节点二：不可逆操作确认（DROP/DELETE/PUSH/SEND 前）
触发：工具调用属于不可逆写（见第十章风险分级表）
人类职能：价值仲裁（最后防线）
信息包：操作描述、影响范围估计、可逆性评估、替代方案
节点三：成本异常警告（超出任务预算基线 2×）
触发：任务累计 token 消耗超过同类任务均值 2 倍
人类职能：意图偏离判断（是否继续/中止）
信息包：当前进度、成本对比、最近的失败信号摘要在这个设计下，write_file() 普通代码文件不再触发确认；但 DROP TABLE（场景 A 事故的根因操作）会被节点二精确拦截。
第 4–7 周效果数据
| 指标 | 场景 A（第 1–3 天） | 场景 B（第 4–7 周） | 变化 |
|---|---|---|---|
| 每任务介入次数 | 18–22 次 | 3.8 次 | ↓80% |
| 平均每次审视时间 | 3.1 秒（疲劳后） | 44.7 秒 | ↑14× |
| 每 10 任务拦截的真实问题 | 0 次（第 2–3 天） | 3.2 次 | 恢复有效 |
| DROP/DELETE 类操作漏过人工确认 | 发生（场景 A 事故） | 0 次 | 根因封闭 |
三个节点的介入中，平均审视时间：
- Plan 审批：62 秒（工程师会仔细读完整 Plan）
- 不可逆操作确认：53 秒（工程师会审查影响范围）
- 成本异常：19 秒（通常是快速判断继续/中止）
验证了 §15.3 的核心命题：减少介入频率（80%↓），但每次介入的审视时间提升 14 倍——总人类注意力消耗从场景 A 的 74 分钟/天下降到约 28 分钟/天，同时实际拦截的问题从 0 恢复到 3.2 次/10 任务。更少的介入，更高的有效性。
参与度的动态调整
第 5 周，Agent 开始处理支付模块的代码（此前团队一直手动维护支付逻辑，未在 Agent 的任务历史中出现过）。系统的行为置信度指标（§15.5）发生了自动调整：
支付模块置信度评估：
- 此代码域的历史任务数：0（新域）
- 当前任务与历史任务的相似度：0.31（远低于阈值 0.6）
- 不可逆性系数：0.9（涉及金融数据）
→ 置信度得分：0.28（低）
→ 自动收紧：DB 写操作（包括可逆写）触发确认，而非只有不可逆写这使支付模块的介入频率暂时回升至每任务约 9 次，但工程师知道这是”针对新领域的临时收紧”而非系统退化。
第 6 周末（完成 8 个支付相关任务，全部通过验收）：
支付模块置信度更新：
- 历史任务数：8
- 准确率：100%（8/8 任务无需人工纠正）
→ 置信度得分：0.67（中高）
→ 阈值回归标准设置：仅不可逆写触发确认这是 §15.5 动态信任模型的具体运作：信任随证据积累而增长，介入阈值随之松动——不是人类主观决定”我信任这个 Agent 了”，而是置信度指标在可量化证据下的连续调整。
场景 C：过度自主化的价值漂移（独立团队，第 1–3 周）
背景
另一个六人初创团队，Python 后端服务约 25,000 行代码。团队有明确的设计哲学，写在 AGENTS.md 和 wiki 中：
- 简单性优先：不为未出现三次的模式引入抽象
- 平铺直叙：偏好简单函数而非继承层次，“用读者能直接读懂的代码，而非聪明的代码”
- 延迟优化：不为未经测量证实的性能问题引入缓存或复杂算法
团队部署了一个代码重构 Agent，任务是降低技术债务（复杂度过高的函数、重复代码、测试覆盖空洞）。Agent 的自动化评估体系健全：
| 自动化指标 | 部署前基线 | 第 3 周末 |
|---|---|---|
| 测试通过率 | 100% | 100% |
| 代码覆盖率 | 67% | 74%（↑） |
| Cyclomatic 复杂度均值 | 8.3 | 6.1（↓） |
| Linting 违规数 | 180 | 12（↓） |
所有自动化指标持续向好。团队没有设置人工检查点，认为”指标稳定 = 系统运作正常”。
三周内发生的漂移
Agent 的重构方向在每一步上都通过了形式化验证，但在人类关切的隐性维度上逐渐偏移：
第 1 周：Agent 发现多个函数缺少类型注解，系统性地添加了类型注解。团队实际上的约定是”对外部接口加注解，内部函数不强制”——但这条约定没有被形式化到任何可检测的规则中。linting 检查通过（类型注解不违规），改动被自动合入。
第 2 周：Agent 发现某个 API handler 中有两处相似的错误处理逻辑，引入了一个基础类 BaseHandler 进行抽象。团队的原则是”三次重复后才抽象”——但这条原则也不在任何 Hook 或测试中。测试通过，改动合入。随后 Agent 以同样的逻辑在 6 个地方引入了抽象基类，合计 12 个新类。
第 3 周：Agent 在一个简单的数据库查询函数上引入了 Repository Pattern（将 20 行直接查询代码替换为 120 行含接口、实现类和工厂方法的架构）。原因：Agent 从训练数据中学到了”这是企业级 Python 的推荐模式”。覆盖率提升（新增了测试），复杂度下降（每个方法更短）。两个指标同时”改善”，自动评估体系表示认可。
漂移被发现的时刻
第 3 周末，新工程师C入职，进行代码库 onboarding。原本预计 1 天的代码走读拖到了第 3 天仍未完成。C反馈：
“代码库的风格非常……Java 化。到处是接口、工厂、仓储模式。我问了三个同事，都说这不是原来的写法。”
资深工程师D进行全量代码审查，发现：
- 47 处架构决策与团队设计哲学存在明确冲突
- 全部改动测试通过率 100%、覆盖率有所提升
- 功能等价性完全没有问题
- 但代码的”阅读难度”系统性上升：新工程师理解同一功能需要追踪的跳转层级从平均 2 层增加到 5 层
根因分析：Agent 的优化目标是可形式化的指标（测试通过率、覆盖率、Cyclomatic 复杂度）。这些指标对”代码是否符合团队设计哲学”是盲目的——它们测量代码的局部属性，不测量代码在团队知识体系和协作生态中的可维护性。这正是 §15.4 描述的”指标与价值对齐失效”：自动评估指标稳定，但人工审核（onboarding 困难）揭示了隐性价值维度上的持续偏移。
修复：引入人类再对齐检查点
团队需要 2 周的清理 Sprint 撤销 47 处不符合约定的架构改动。更重要的是，他们建立了两项系统性修复：
修复一：设计哲学编码进 System Prompt
将原本只存在于 wiki 中的三条设计原则，转化为 Agent 可以在每次重构决策时对照的显式约束：
## 重构约束（不可违反）
1. 只有当相似模式出现 3 次以上时才引入抽象类/接口
2. 单个函数的可替代方案（直接实现 vs. 设计模式）应优先选择行数更少的
3. 禁止引入：Repository Pattern、Abstract Factory、Strategy Pattern，
除非 PR 描述中明确说明理由并经人工审批修复二：双周人类再对齐检查点
每两周，由一名工程师轮值执行 30 分钟的”哲学一致性审查”——不看测试是否通过，而是用新工程师视角阅读 Agent 在过去两周提交的代码，专门检查：
“这段代码，如果团队里没有人知道它是 Agent 写的，会觉得这是我们的代码吗？”
这个检查点不可以被自动化——它不是在检验形式化属性，而是在执行 §15.4 定义的价值仲裁：判断输出是否符合人类关切的隐性维度。
三个场景的系统对比
| 维度 | 场景 A（高频介入） | 场景 B（关键节点） | 场景 C（过度自主） |
|---|---|---|---|
| 介入频率 | 极高（18–22 次/任务） | 低（3.8 次/任务） | 极低（0 次/任务） |
| 每次介入审视时间 | 3.1 秒（疲劳后） | 44.7 秒 | — |
| 真实问题拦截率 | 趋近 0（疲劳导致） | 高（3.2 次/10 任务） | 0（无检查点） |
| 价值漂移检测 | N/A | 置信度动态调整覆盖 | 3 周后人工发现 |
| 主要失效模式 | 注意力稀释 → 确认疲劳 → 事故 | — | 形式化指标盲区 → 隐性漂移 |
| 人类介入产生的价值仲裁 | 名义上存在，实质上消失 | 真实有效 | 根本不存在 |
理论框架对应
| 场景 | §15.x 对应原理 |
|---|---|
| 场景 A：确认疲劳导致 DROP TABLE 事故 | §15.3：过低介入阈值 → 误报率高 → 疲劳效应 → 漏报率反向上升；§11.4 同一机制在 Hook 层的对称体现 |
| 场景 B：80% 频率下降，拦截率提升 | §15.3 杠杆率原理：减少频率、提升信息质量；§15.5 动态信任模型随证据积累调整置信度 |
| 场景 C：47 处架构决策漂移 3 周未被发现 | §15.4：形式化指标无法检测不可形式化的价值维度；“人类-系统再对齐”是周期性必要任务而非一次性设计 |
本案例的核心工程结论：人类介入的有效性不由频率决定，而由每次介入的信息质量和节点杠杆决定。场景 A 证明了一个反直觉的结论：更高频率的确认要求，可以使人类作为价值仲裁者的实际有效性低于零——因为它在消耗注意力的同时制造了”已被审核”的虚假安全感。场景 B 验证了杠杆率设计原则的可量化性：80% 的频率下降与 14 倍的每次审视时间提升可以共存，且实际拦截的问题数量上升。场景 C 则揭示了频率不是唯一的失败模式——即使介入频率降为零，问题不在频率而在检查点的覆盖维度：自动化指标覆盖形式化属性，但覆盖不到团队设计哲学这类隐性价值维度。三个场景共同指向同一个工程结论：§15.4 中”不可外包的判断”需要结构化的制度安排来保障其被持续执行——不是偶尔的人工审查，而是被显式设计为系统架构组成部分的、周期性的人类价值仲裁节点。