人机界面与监督回路

模型进入生产环境，总要经过一个界面。这个界面不只是用户体验；它本身就是控制面，人在这里查看证据、批准副作用、修正答案、升级个案，或者停止一次运行。如果界面把不确定性藏起来，把可逆的建议和不可逆的动作混在一起，或者把反馈当成松散的产品信号，而不是一条运维记录，下面的基础设施也会继承这种混乱。人在回路中（HITL） 因此不是放在自动化系统上方的一层伦理装饰，而是一种运行时设计：人的判断插在何处，有什么权限，看见哪些轨迹，它的决定又怎样回流到评测、策略和数据。

上一章说，可靠性从精确答案转移到采样分布上。本章补上那一层表面。分布不会直接遇见用户；它通过屏幕、工作流、队列、差异视图、权限提示或告警遇见人。下一章要追踪产品流量制造出的数据。两者之间就是人机界面：一个随机输出在这里变成被接受的工作、被拒绝的工作、训练信号或事故。

界面是一块控制面

人机交互研究很早就提醒过，不要把界面当成薄薄一层展示。Horvitz 的混合主动性界面主张让系统与人共享控制，而不是把控制夺走 (Horvitz 1999)。微软的人机交互指南把这个前提整理成十八类反复出现的设计问题：系统能做什么，什么时候会失败，人又如何纠正它 (Amershi et al. 2019)。Heer 关于 agency plus automation 的论点，把其中的基础设施含义讲得更直接：好的系统不是用黑箱替换用户的工作，而是构造一份共享的行动表示，让人可以审查、修改或丢弃机器的提议 (Heer 2019)。

所以，设计对象不是一个聊天框，而是一条受治理的回路。请求进入模型，模型提出答案或工具计划，系统应用策略和校验器，界面暴露足够多的状态让人采取行动，随后的接受、编辑、拒绝、批准或升级变成一条轨迹。这条轨迹再回到 第 87 章 和 第 92 章 的机器里。

这条回路带来一个实际要求：界面必须展示人要负责判断的状态。如果系统要求审查员批准一笔付款，审查员需要看见金额、收款方、权限、证据和回滚路径，而不是一段流畅摘要。如果系统要求医生考虑一条建议，界面就必须支持情境感知：感知相关事实，理解其含义，并推断后续可能发生什么 (Endsley 1995)。一个审查页如果省掉工具参数、检索证据、模型不确定性或策略理由，不只是不好用。它制造了虚假的责任，因为它要求人为一个决定负责，却不暴露这个决定的依据。

人在回路中，不是一种设计

HITL常被说得像是一种单独的安全机制。它不是。人可以在不同时间、以不同权限进入回路。

第一种位置在模型行动之前。用户选择一个草稿，审查一份工具计划，或批准一笔交易。这是最熟悉的批准门，也是 第 85 章 里的工具调用所需要的那一类。第二种位置在行动之中。监督者在智能体运行时看见进度、预算、不确定性和停止控制。这是 第 41 章 里暂停、恢复和批准这些运行时动词的界面侧。第三种位置在行动之后。系统抽样审计结果，把失败送去复核，并把已经到达用户的缺陷提升进回归套件。这属于 第 92 章。第四种位置在正常回路之外：当系统不该在本地决定时，升级给专家、经理、第二位复核者或事故流程。

较老的自动化文献解释了为什么这些区别重要。Parasuraman、Sheridan 与 Wickens 把自动化按阶段和等级拆开：信息获取、分析、决策选择与行动执行，都可以被自动化到不同程度 (Parasuraman et al. 2000)。Bainbridge 指出了糟糕拆分带来的反讽：自动化拿走了日常练习，却把人留下来处理那些罕见、快速、困难的干预时刻 (Bainbridge 1983)。现代智能体完全可能重演这件事。它让容易任务变得毫不费力，然后在剥掉必要上下文之后，把异常个案递给人。

规则可以说得很短，实现却很难：不要让人去为一个风险担责，而这个风险，界面根本不让他看见、也不让他改变。

校准后的依赖

目标不是最大化信任，而是 校准后的依赖（calibrated reliance）：当模型很可能有帮助时使用它，当场景要求检查或保留判断时收住，并知道两者的区别。Lee 与 See 把对自动化的信任定义为：在复杂情境下决定是否依赖它的机制，而不是一种需要不断抬高的情绪 (Lee and See 2004)。一个让人接受更多建议的系统，不一定改善了整个人机系统。它也可能制造 自动化偏差（automation bias）：人会过度接受自动化建议，只因为建议来自系统。

近年关于 AI 辅助决策的研究把这个警告说得更清楚。Bansal 等人发现，解释会提高参与者接受 AI 建议的概率，不管建议是对还是错 (Bansal et al. 2021)。Buçinca、Malaya 与 Gajos 发现，认知强制机制，也就是让人在接受建议前先思考的干预，比简单解释展示更能降低过度依赖，但体验评价也更差 (Buçinca et al. 2021)。这是一项工程取舍，不是用户体验脚注。一个只优化接受率、速度或满意度的产品，可能把整个人机团队推向更差的决定。

对基础设施来说，这意味着「可解释性」这个要求太粗。界面需要的是能改变决定的线索。有时它是检索证据的引用；有时是与上一版的差异；有时是精确的工具调用、权限范围、置信区间、输入分布外警告，或类似失败的历史。类似思维链的叙述常常并不是审查者该看的东西：它未必可校验，可能泄露系统并不需要展示的内部推理，也可能把注意力从审查者能检查的证据上移开。更好的界面把三类工件分开：

• **证据：**答案所依赖的文档、度量、日志和工具输出。
• **不确定性：**分数、分歧、缺失输入、护栏结果和已知限制。
• **权限：**系统提议做什么动作，谁能批准，以及它是否可逆。

这种分离也让观测更可靠。如果用户主要在缺少证据时推翻模型，缺失证据这个线索就应该进入评测。如果用户在置信线索很高时接受了错误答案，那么置信模型没有校准好。如果用户从不阅读解释，那么无论解释占了多少屏幕空间，它都不是控制回路的一部分。

批准门与副作用

模型一旦能改变外部状态，监督就变成授权问题。第 56 章 已经把它讲成代表用户的委派和最小权限。界面则是这个策略对人变得可读的地方。

一个实用的门可以由五个成分决定：动作风险、模型置信度、上下文敏感性、可逆性和权限。低风险、可逆、高置信的动作可以自动执行并留下日志。中等风险动作需要提交前审查。高风险或低可逆性的动作需要更强手段：双人批准、分阶段提交、延迟执行，或进入另一个系统作为正式记录。这不是因为人不会出错，而是因为组织必须决定责任在何处换手。

def gate(risk, confidence, reversible, has_authority):
    if not has_authority:
        return "deny"
    if risk >= 0.8 and not reversible:
        return "two-person approval"
    if risk >= 0.5 or confidence < 0.7:
        return "human review"
    if reversible:
        return "auto-commit with audit log"
    return "review before irreversible commit"

cases = [
    ("draft reply", 0.2, 0.82, True, True),
    ("refund customer", 0.6, 0.76, True, True),
    ("delete records", 0.9, 0.91, False, True),
    ("wire transfer", 0.95, 0.84, False, False),
]
for name, risk, conf, reversible, auth in cases:
    print(name, "->", gate(risk, conf, reversible, auth))

法律也开始把同一项设计义务写进去。欧盟 AI Act 的人工监督条款要求高风险系统被构造成这样：部署者能理解能力与限制，能监控运行，能意识到 自动化偏差，能正确解释输出，能决定不使用或覆盖输出，也能通过停止程序介入或中断系统 (European Parliament and Council of the European Union 2024)。不过这项义务虽已立法确立，约束力尚未生效：2026 年 6 月通过的数字一揽子法案（Digital Omnibus）把高风险条款的适用推迟到了 2027 年 12 月（独立系统）与 2028 年 8 月（嵌入受监管产品的系统）(Council of the European Union 2026)。NIST 的 AI 风险管理框架是自愿性的，但它同样把可信性定义为贯穿设计、开发、使用和评估的东西，而不是部署后才贴上的补丁 (National Institute of Standards and Technology 2023)。

对一个已部署的智能体来说，这些要求会落成界面细节：能够实际取消工具执行的停止按钮，展示副作用精确参数的审查页，记录哪个用户批准了哪个范围的日志，当策略和用户意图冲突时的升级路径，以及系统提交可逆变更后的回滚路线。一个只写着「确认执行？」的确认框不是批准门，只是摩擦。有效的批准门会改变权限、捕获证据，并把动作绑定到一条可追责的轨迹上。

修正回路

人的反馈也不是一种信号。编辑和重新生成不是一回事，拒绝和升级也不是。相比之下，点踩如果不带理由、任务状态和后续结果，几乎说明不了什么。第 92 章 中的生产数据引擎依赖这些区别，因为同一个界面事件可以交给不同的下游系统。

接受一条建议是弱的正信号。它可能意味着答案好，也可能只是人在时间压力下觉得够用。用户编辑更强，但前提是系统以可比较的方式保存编辑前后。带类别的拒绝更有价值，例如证据错误、语气错误、动作被禁止或权限缺失，因为它指向负责的那一层。升级本身也不是失败标签。它可能表示高风险、低置信、权限不足，或策略含混。

所以，修正界面必须和数据引擎一起设计。界面应该让最便宜且有用的修正变得容易：选择一个原因，标出有问题的片段，替换一个实体，附上一份缺失来源，或把个案送入队列。每一种动作都需要模式。自由文本反馈适合调查，却太昂贵、太不一致，不适合作为主要数据产品。

难处在于，产品反馈带着偏差。会投诉的人不是随机样本。沉默接受的人也不一定满意。审查者看到的个案，由当前模型和当前界面共同塑造。这是 第 92 章 里的数据级联问题在产品里的形态，即上游微小的数据问题会层层累积，放大成下游的大故障：后续模型的行为会被上游的收集选择塑造 (Sambasivan et al. 2021)。解法不是忽视产品轨迹，而是标出其来源，有意抽样，保留一条留出审计流，并避免把每个用户动作都当作真值。

升级与优雅交接

升级是优雅降级在界面上的形态。当模型无法安全回答，校验器失败，置信度低，或者所请求动作超过权限时，系统应该进入一条更窄的路径，而不是继续假装有把握。第 90 章 把这叫做少做，而不是失败。这里的少做，就是把个案交给能负责的人，并带上足够多的状态，让对方可以接着做。

好的交接保存上下文，并减少工作量。它包括原始请求、模型草稿或计划、检索证据、工具结果、策略检查、不确定性线索，以及升级原因。差的交接只写「需要复核」，迫使下一个人重放整条轨迹。这种区别直接影响审查能力，因为审查能力才是稀缺资源。每一分钟无意义复核都是运维成本；每一个被省略的事实，都会提高橡皮图章式批准的概率。

高风险系统常常还要加入第二个模式：职责分离。一个人发起，另一个人批准；一个模型提出，校验器检查；一个审查员标注，另一个审计。它看起来像官僚流程，直到模型能移动资金、修改访问权限、发送法律文本、改变医疗工作列表或删除数据。那时，工作流就是基础设施控制。它给组织一个停止的地方，一个追问原因的地方，以及事故之后能检查的记录。

度量人的回路

如果人机界面是运行时的一部分，它就需要指标。基本指标不是浏览量，也不是愉悦感，而是控制指标：

• 自动化接受率： 用户多常接受系统提议。
• 覆盖率： 用户多常修改或拒绝提议，并按任务与风险分层。
• 错误接受率： 用户批准了后来被判定为错误的输出的频率。
• 错误拒绝率： 用户拒绝了后来被判定为可接受的输出的频率。
• 审查延迟： 个案等待人工决定的时间。
• 升级精度： 升级个案中真正需要升级的比例。
• 审查负载： 每位审查员的个案数、决策时间、分歧与漂移。
• 修正产出： 多少反馈事件变成评测样本、策略变更或训练样本。

关键指标常常是一对，而不是一个标量。审查率下降是好事，前提是错误接受没有升高。批准更快是好事，前提是审查员分歧没有变大。用户满意度更高是好事，前提是它不是靠隐藏不确定性换来的。系统应该被当成人机团队来度量，把模型准确率和人的依赖一起放进回路。

把界面当作基础设施

能力、效率和信任，在人的界面上相遇得最集中。能力来自让模型不只起草文本，但每增加一种行动，都需要一个强度与影响半径相称的门。效率来自不把每个个案都送给人，但审查能力必须花在判断能改变结果的地方。信任来自校准后的依赖、可见的权限和可追踪的修正，而不是让模型听起来更自信。

这就是为什么产品表面属于一本讲基础设施的书。它是模型行为变成组织行为的地方。它定义谁可以行动，谁必须审查，谁能够停止，谁从错误中学习，以及系统继续向前之后还有哪些证据留下来。下一章的生产数据引擎从这里开始：从一个严肃界面让人看得见、管得住的接受、编辑、拒绝、升级、批准和停止事件开始。

延伸阅读