人机界面与监督回路

监督界面是一道可执行的决策边界。只有当人能检查相关证据，并改变系统可以做什么时，它才真正有用。仅仅展示模型输出的仪表盘不是控制。一套真正有效的控制机制必须串起五个彼此不同的环节：呈现、决策、强制执行、外部影响和轨迹。界面呈现拟议动作，人或策略作出决定，运行时强制落实该决定，外部系统核对实际影响，持久轨迹则记录发生了什么。

当模型能够改变状态时，这一区分尤其重要。流畅的预览不能证明批准的载荷就是最终提交的载荷。停止控件不能证明外部影响已经停止。批准记录也不能证明审查者拥有相应权限。每一项主张都需要界面下方的机制来保证。

上一章根据用户可见的结果定义可靠性。本章进一步讨论，人可以在执行之前、期间和之后的哪些位置改变这些结果。下一章则会把由此产生的事件送入生产数据引擎。连接两章的是一个可能出错、受容量约束的人类控制回路，而不是徒具形式的“人在回路中”。

从屏幕到控制机制

这一思想早于现代 AI 助手。混合主动性界面允许人和软件协商控制权，而不是迫使系统在直接操纵与完全自动化之间二选一 (Horvitz 1999)。后来的人机交互指南把完整周期说得更清楚：设定预期、暴露限制、支持修正，并从使用中学习 (Amershi et al. 2019)。Heer 提出的关键设计模式，是在引入自动化的同时保留人的能动性：让人和系统共享一种可以检查、修改或丢弃的表示 (Heer 2019)。

当一项提议可能产生实际影响时，这些原则就成了基础设施要求。在设计审查界面之前，系统需要先写出一份监督控制契约：

这份契约可以避免一种常见错误：让审查者为自己既看不见也改变不了的状态承担责任。情境感知要求人能够感知相关事实、理解其含义，并推断接下来可能发生什么 (Endsley 1995)。审查付款时，相关信息包括收款方、金额、资金来源、证据、策略和可能产生的影响，而不是一段亲切的摘要。无障碍、语言和领域知识同样属于审查者资格。分配给审查者却无法感知或理解的信息不构成有效监督。

界面只是这条路径中的一个组件。授权服务、运行框架、连接器、记录系统和可观测性流水线必须共同兑现其余保证。如果点击“批准”只改变界面状态，而执行器完全忽略这个决定，那么这个界面便形同虚设。

有意安排人的介入位置

人在回路中（HITL），是指某个明确的人或角色能够检查相关证据并改变执行路径。如果设计没有同时规定介入时机、权限、能力、独立性、时间预算和超时默认行为，这个说法就不完整。

人的介入主要有三个位置：

• 提交之前： 人在状态改变前审查草稿或拟议影响。这是工具调用最常见的批准门。
• 执行期间： 人监控进度、预算和实际影响，并通过 第 41 章 请求暂停、取消或升级。
• 结果产生之后： 人审计代表性样本、裁定失败，并通过 第 92 章 发起修复。

升级并不是第四种批准，而是这三个位置之间的状态转换。它把个案移交给能力或权限不同的角色，同时保留当前状态。

自动化还可能让接管变得更困难。Parasuraman、Sheridan 与 Wickens 按信息获取、分析、决策选择和动作执行拆分自动化 (Parasuraman et al. 2000)。Bainbridge 的“自动化反讽”揭示了一个运维陷阱：日常练习被自动化拿走，人却仍要处理那些罕见、迅速而困难的故障 (Bainbridge 1983)。因此，可信的接管设计必须衡量接管时间、保留上下文，并通过演练或轮岗维持审查者的实践能力。不能让人负责应对自己既无法察觉也无法改变的风险。

校准后的依赖取决于人机共同决策

目标不是信任或接受本身。校准后的依赖（calibrated reliance），是指接受正确的帮助，并检查、修改或拒绝错误的帮助。Lee 与 See 把信任视为复杂环境下影响依赖行为的一个因素，而不是需要最大化的产品指标 (Lee and See 2004)。自动化偏差（automation bias），是指人们过度接受自动化建议的倾向，尤其是当建议看起来很权威时。

评测对象应当是人和 AI 组成的整体：

共同结果取决于两行和两列。仅看接受率，无法区分有效依赖与橡皮图章式批准。仅看推翻率，也无法区分保持警觉的审查者与表现不佳的模型。这些比率还必须结合独立裁定的结果，用户动作本身不能证明其正确性。

解释也不会自动改善这个矩阵。一项研究发现，无论 AI 建议正确与否，解释都会提高人们接受建议的概率 (Bansal et al. 2021)。认知强制要求人在看到建议之前先形成或记录自己的判断。与简单展示解释相比，它能更有效地减少过度依赖，却也会增加使用成本 (Buçinca et al. 2021)。具体应采用哪种干预，取决于风险、频率、审查者能力和时间压力。

展示可核查的信息

审查界面应优先提供证据，而不是有说服力的叙述。根据动作类型，可以展示：

• 精确的动作差异、主体、范围、载荷和预期外部影响；
• 证据的来源证明、来源时效、工具结果和相关反面证据；
• 缺失输入、策略失败、意见分歧，以及请求是否属于分布外；
• 审查者角色、有效期、提交前置条件和可用恢复方式；
• 之前的相关动作，以及相似个案的观测结果。

只有当一个数值置信度已经针对具体任务、总体、发布版本和结果完成校准，而且审查者判断的正是这个结果时，界面才应该展示它。即便如此，模型置信度也不能授予权限。风险、置信度与许可是三个不同维度，把它们压缩成一个分数，会掩盖组织真正需要作出的决定。缺失证据、模型分歧或策略检查失败等具体线索，往往比“置信度 82%”更能指导行动。

界面不应把私有思维链当作证据展示。生成的理由可能给审查者造成锚定效应，也可能以很有说服力的方式出错。应当展示可以核查的主张、引用、计算、工具轨迹和与决策有关的限制。

将批准与提交绑定

当模型能够改变外部状态时，批准就成为一项授权协议。第 56 章 介绍了最小权限和代表用户执行的委派规则，界面必须让这些规则易于理解，却不能削弱它们。

批准记录至少应绑定以下内容：

• 提议和动作哈希；
• 行动者以及动作所代表的主体；
• 精确的范围和载荷；
• 目标资源版本或其他前置条件；
• 审查者、审查者角色、决定、理由和策略版本；
• 决定时间以及批准何时到期。

任何编辑都会改变哈希，并创建一份新提议。提交时，执行器必须重新校验权限、有效期、资源版本和策略。这可以弥合检查时与使用时之间的差距：预览在审查时可能安全，到实际执行时却已经过期。批准只是在既有法律与组织责任体系中记录一项决定，不会自行转移问责责任。

下面这个简化的批准门使用具名业务策略，而不是虚构一套放之四海而皆准的风险或置信度阈值。生产系统应使用签名和可信身份，而不是普通字典。

import hashlib
import json

POLICY = {
    "draft_reply": {"review_role": None, "scope": "message:draft"},
    "send_refund": {"review_role": "refund_approver", "scope": "refund:write"},
}

def action_hash(proposal):
    bound = {
        "action": proposal["action"],
        "subject": proposal["subject"],
        "scope": proposal["scope"],
        "payload": proposal["payload"],
        "resource_version": proposal["resource_version"],
    }
    raw = json.dumps(bound, sort_keys=True, separators=(",", ":"))
    return hashlib.sha256(raw.encode()).hexdigest()

def authorize(proposal, approval, now):
    policy = POLICY.get(proposal["action"])
    if policy is None or proposal["scope"] != policy["scope"]:
        return "deny: policy"
    if approval["decision"] != "approve" or approval["expires_at"] < now:
        return "deny: decision or expiry"
    if approval["action_hash"] != action_hash(proposal):
        return "deny: changed action"
    if policy["review_role"] and approval["reviewer_role"] != policy["review_role"]:
        return "deny: reviewer role"
    if approval["resource_version"] != proposal["resource_version"]:
        return "deny: stale resource"
    return "commit"

proposal = {
    "action": "send_refund",
    "subject": "customer-17",
    "scope": "refund:write",
    "payload": {"order": "A9", "amount_cents": 2500},
    "resource_version": "order-v4",
}
approval = {
    "decision": "approve",
    "action_hash": action_hash(proposal),
    "reviewer_role": "refund_approver",
    "resource_version": "order-v4",
    "expires_at": 200,
}

assert authorize(proposal, approval, now=100) == "commit"
proposal["payload"]["amount_cents"] = 9000
assert authorize(proposal, approval, now=100) == "deny: changed action"
print("approval binding verified")

如果一个确认框无论如何选择都允许相同动作继续执行，它造成的是警告疲劳，而不是批准门。人的决定必须能够改变运行时允许发生的状态转换。

取消不等于回滚

停止控件发送的是取消请求。在声称工作已经停止之前，界面还应单独显示执行确认。如果连接器在发出请求后超时，系统可能面对提交状态未知：外部影响或许已经发生，只是没有收到成功响应。安全做法是先与记录系统对账，再决定是否重试或宣告成功。

恢复方式取决于影响类型：

• 回滚 在系统支持时恢复到一个已知的先前状态。
• 补偿 产生一项新的影响，例如用退款抵消已经完成的扣款。
• 遏制 在无法回滚时限制进一步伤害，例如吊销凭据或停用智能体。

幂等性可以在明确的键与保留窗口内防止重复影响，但幂等性不等于回滚。界面必须区分“已请求取消”“执行已停止”“提交状态未知”“已观测到影响”和“恢复完成”。

多人复核需要真正的独立性规则

职责分离可以减少个人失误或滥用，但“需要两人批准”仍不完整。策略必须规定审查者资格、独立性、法定人数、利益冲突、决定顺序和超时规则。同一个人控制的两个账号、依赖同一份误导性证据受训的两名审查者，或者共享同一故障的审查者与校验器，都不能提供有效的独立性。控制契约应记录这些共享故障假设。

把人工审查作为队列运行

人工审查能力是一项容量有限的依赖。令 $\lambda$ 表示合格个案的到达率，$\mu$ 表示每名在岗审查者的平均服务率，$c$ 表示在岗审查者人数，则负载率为

$$\rho = \frac{\lambda}{c\mu}.$$

换句话说，如果 $\rho \ge 1$ 持续一段时间，工作到达的速度至少与处理速度一样快，积压便会增长。保持 $\rho < 1$ 是必要条件，却不是充分条件：流量突发、优先级类别、处理时长波动和截止时间仍可能让服务目标失守。

这条队列需要像软件依赖一样运行：

• 按优先级和切片发布到达率、服务率、利用率、积压、队列中最久等待时间和审查延迟；
• 为紧急个案预留容量，不能让低价值审查占满所有审查者；
• 定义过载模式：降低自主程度、缩小可执行动作范围、延迟非紧急工作，或默认拒绝危险操作；
• 监控放弃、意见分歧、重复批准和决策时间骤降，把它们视为审查者疲劳的潜在线索；
• 人员安排要覆盖休息、培训、事件和交接，不能假设每名名义上的审查者始终可用。

没有容量计划的批准门可能比范围更窄的自动化策略更不安全：它会制造积压、鼓励橡皮图章式批准，并延误紧急个案。

交接是一项协议

每个升级个案都需要交接负责人、接收方、确认、截止时间和升级原因。它的上下文包应包括原始请求、提议、证据、工具结果、策略检查、先前决定、不确定性线索、资源状态和剩余时间预算。接收角色必须明确接手，或者说明拒绝原因，并把个案送往另一个有效目的地。有界升级图可以防止个案在队列之间无限往返。

如果截止时间前无人确认，系统就执行超时默认行为。对于不可逆动作，默认行为通常是“不提交”；对于监控告警，则可能是“呼叫事件负责人”。正确的默认行为取决于外部影响和策略，而不是界面实现是否方便。

修正事件是证据，不是真值

反馈事件不是真值标签。接受建议可能表示它正确、勉强可用，或者根本没人认真看过。编辑可能是在修正事实、调整语气，也可能只是表达个人偏好。拒绝可能指出模型故障、权限缺失或界面不可用。升级也可能正是一条正确但高风险输出所要求的行为。

系统需要保存足够的来源信息，才能在日后解释这些事件：

• 带稳定标识符的修改前工件和修改后工件；
• 事件类型、原因代码、标记的文本范围或字段，以及必要时的自由文本备注；
• 任务版本、系统发布版本、策略版本和界面变体；
• 审查者身份或角色、资格，以及决定时可见的证据；
• 可获得时的后续结果和裁定；
• 抽样规则、纳入概率，以及产品策略是否强制该个案进入审查。

这些字段让 第 92 章 能把事件送往评测、策略分析、事件复盘，或经过谨慎筛选的训练数据。它们也会暴露选择偏差。产品触发的审查集中在当前模型与策略选中的个案上，静默接受和中途放弃的任务则仍有一部分不可见。要估计总体行为，还需要一份纳入概率已知的独立代表性审计样本。产品轨迹依然是有用的诊断证据，但默认并不代表总体。这样可以避免上游采集选择演变成下游的数据级联 (Sambasivan et al. 2021)。

衡量整个回路

监督指标描述的是一个过程，不是因果解释。接受率升高，可能因为模型变好了，也可能因为审查者疲劳，或者界面隐藏了证据。推翻率下降也可能由相同原因造成。因此，行为指标必须与独立裁定的结果和测量覆盖率结合使用。

有用的指标包括：

• 共同决策质量： 正确接受、错误接受、正确推翻和错误推翻（错误拒绝）。
• 裁定质量： 审查者分歧、裁定者版本、延迟结果率和未解决个案。
• 测量覆盖率： 合格决定、已观测结果、抽样决定、缺失标签，以及按风险和用户切片统计的覆盖率。
• 队列健康： 到达率、积压、队列中最久等待时间、审查延迟、放弃、超时和交接确认。
• 控制完整性： 过期批准、载荷已变更、提交被拒绝、取消确认、提交状态未知和对账延迟。
• 修正产出： 转化为回归测试、策略变更、恢复工作或经审查训练样本的事件。

这些指标应按任务、影响类别、语言、无障碍模式、审查者角色和其他相关切片比较。全局平均值可能掩盖一种控制只对某个总体有效，却对另一个总体失灵。

标准与法律界定适用范围，而非通用方案

NIST 的 AI 风险管理框架是一套自愿性框架。它把可信性视为贯穿设计、开发、部署、使用和评估的全生命周期问题 (Tabassi 2023)。它是一套有用的治理框架，却不表示每项动作都需要人工批准。

欧盟 AI Act 更为具体。第 14 条要求适用范围内的高风险 AI 系统支持有效的人工监督，包括理解系统能力与限制、意识到自动化偏差、正确解释输出、不采用或覆盖输出，以及介入或中断系统使其进入安全状态 (European Parliament and Council of the European Union 2024)。已通过的《欧盟条例 2026/1744》，即 AI 数字综合法案，于 2026 年 7 月 27 日生效。它把第 6(2) 条和附件 III 所分类系统的相关第三章规则推迟到 2027 年 12 月 2 日，把第 6(1) 条和附件 I 所分类系统的规则推迟到 2028 年 8 月 2 日 (European Parliament and Council of the European Union 2026)。第 14 条不是普遍适用的产品规则，本章也不构成法律建议。应根据实际系统与司法管辖区判断分类和义务。

对工程实践而言，可长期适用的结论更窄：把外部影响、权限、审查者能力、决定状态、超时、提交语义和恢复方式写成可测试的要求。

测试监督路径

只测试界面的顺利流程远远不够。场景测试还应覆盖以下边界：

• 过期的预览或载荷已变更仍到达提交检查；
• 批准已过期，或者审查者在提交前失去权限；
• 使用相同或冲突载荷的重复提交到达系统；
• 取消失败，导致请求没有执行确认；
• 连接器返回提交状态未知，对账又发生延迟；
• 审查者中断或队列过载使预期人工容量消失；
• 名义上独立的审查者实际共享身份、证据或故障模式；
• 轨迹缺失、不完整，或关联失败，导致实际影响不可见；
• 置信度提示已经过期、未经校准，或与证据不一致。

每种故障都需要事件运行手册：遏制有害影响，保存提议和决定证据，对外部状态完成对账，通知负责人，修复控制，并把个案加入回归测试套件。

发布前还应形成一份监督发布记录，其中包括：

• 控制契约和策略版本；
• 影响类别、批准绑定、超时默认行为和恢复路径；
• 审查者资格、容量假设和过载行为；
• 队列目标、共同决策质量目标及其测量覆盖率；
• 无障碍与语言检查；
• 场景测试结果和已知限制；
• 证据保留与事后监控计划；
• 控制、队列、事件响应和定期复核的负责人。

这份记录让人的依赖关系可以接受审查。“由人批准”不是发布论据。

界面是运行时的一部分

人工监督既不能证明安全，也不能取代自动化。它是一项经过专门设计的依赖，具有自己的故障模式、容量上限和明确契约。只有当有效的人类决定能够改变执行，而且系统能够核验由此产生的实际影响时，界面才配称为“控制”。

这正是产品界面属于基础设施的原因。它把带有随机性的提议与组织权限、运行时执行、外部状态和证据绑定起来。下一章的生产数据引擎从这些带版本的提议、决定、实际影响、修正和结果出发，而不是从一串没有区分的点击开始。

延伸阅读