委托与用户控制

委托不是标有“开始”的按钮。它是一项关于系统可以决定什么、可以使用哪些资源、可以暂存或提交哪些行动、工作可以持续多长时间、以及何时必须再次让人类参与的约定。

糟糕的委托会导致两种相反的错误。系统可能以隐藏的自主性行动，而用户认为自己只是在接收建议。或者系统可能要求太多确认，以至于用户不看就批准。这两种失败都消除了有意义的控制。一种隐藏了授权；另一种耗尽了注意力。

产品设计必须让委托感觉简单，但不能让它变得模糊。用户不需要理解整个智能体运行框架，但他们应该能够判断自己是在寻求建议、准备供审查的工作、授权一个有限制的行动，还是让系统继续直到发生异常。

论点

只有当人能够设定任务、理解控制范围、预览实质性影响、改变或停止进程，并且无需检查每一个低价值步骤就能恢复权限时，委托才是可用的。

产品与体验负责让用户真正理解并使用这些控制。架构负责运行时审批、中断和移交状态。安全与治理负责执行和问责。一个漂亮的控制如果系统不强制执行，就只是装饰。

目标不是最大化控制的数量。而是将正确的控制放置在用户拥有证据、权限和时间来改变结果的位置。

让委托约定可见

在工作开始之前，用户应该能够回答：

系统在追求什么目标？
什么算作成功结果？
可以使用哪些资源、账户、文件、数据、记忆和工具？
哪些行动可以推荐、暂存或提交？
可以花费多少时间、金钱、算力或外部工作？
哪些事件需要审批？
适用哪些策略、安全或资格限制？
如果系统不确定、被阻塞、延迟或超出预算，会发生什么？
用户如何暂停、取消、编辑、撤销或接管？

将这些作为产品控制暴露出来，而不是隐藏在设置中的策略文本。交互可以紧凑，但约定不能是虚构的。任务组合器、侧面板、命令面板或设置表单都可以，只要它们将相同的事实绑定到运行中。

一个有用的委托约定具有如下形式：

目标：
范围：
允许的资源：
禁止的资源：
行动权限：
审批触发条件：
预算和截止时间：
预期证据：
停止和交回规则：

对于重复或熟悉的任务，产品可以提供预设。预设只有在映射到真实的权限和时限差异时才是安全的：

模式	产品含义	示例
建议	系统推荐；用户行动。	起草回复、建议方案、比较选项。
准备	系统收集和暂存工作以供审查。	填写表单、准备拉取请求、组装报告。
执行受限步骤	系统可以在明确限制内提交低风险行动。	更新标签、在批准的窗口内安排、关闭重复工单。
带异常的自动驾驶	系统在狭窄的范围内进行，并将异常情况上报。	根据策略处理符合条件的低价值退款。

名称可以变化。重要的是映射到路径决策权、行动权限、运行时长和人类参与度。如果系统仍然可以在未经审查的情况下发送消息或更新记录，就不要称模式为“需要审查”。如果下一步需要用户每分钟点击一次，就不要称模式为“自动驾驶”。

以系统可检查的方式设定目标

智能体产品通常接受自然语言目标。这很有用，但系统仍然需要结构化的成功条件。“改进这个幻灯片”可能足以用于头脑风暴。但对于委托工作来说，它很弱，因为系统和用户都无法判断是否完成。

帮助用户将意图转化为可检查的约束：

用户意图	产品应引出
“研究这个供应商”	问题、比较标准、允许的来源类型、新鲜度要求、所需输出格式。
“修复这个缺陷”	复现信号、受影响区域、测试预期、涉及的文件或目录、审查边界。
“处理这些工单”	资格策略、排除的客户、退款或信用额度、升级条件。
“清理我的日历”	日历范围、会议类型、受保护的事件、消息审批、时区行为。

产品可以推断默认值，但默认值在重要的地方应该是可见的。隐藏的默认值在选择收件人、账户、司法管辖区、记忆、成本限制或权限时尤其危险。

让范围在工作期间可编辑

智能体任务会在开始后暴露出缺失的约束。好的控制让用户能够细化：

目标或成功标准；
包含和排除的来源、收件人、文件、账户或行动；
语气、格式、时间表、优先级或深度；
花费、时间、Token 或外部服务预算；
审批阈值；
应该或不应该应用的记忆或偏好；
部分结果是否足够；以及
系统应该继续、缩小、暂停还是停止。

微软的人机交互论文建议支持高效的纠正和拒绝、谨慎的适应以及全局控制（Amershi et al., 2019）。对于智能体，纠正必须改变实际的运行状态。仅编辑一条聊天消息是不够的，如果智能体已经从旧指令中暂存了行动。

展示范围编辑会影响什么。如果用户将“今天发送这个”改为“仅准备草稿”，待发送内容、审批、定时器、子任务和委托权限都应可见地更新或取消。如果用户排除了一个数据源，系统应说明哪些声明或产物基于该数据源，以及它们是否需要重新生成。

预览有重大后果的行动

在产生实质性外部影响之前，显示结构化的行动预览。预览应回答：

行动：
目标：
披露或更改的数据：
使用的权限：
理由和证据：
策略或验证检查：
可逆性或补偿：
成本或截止时间影响：
自上次审批以来发生了什么变化：
如果被拒绝会发生什么：

预览应来自结构化状态，而不仅仅是生成的推理。未经信任的检索内容不应被允许写入目标、金额、收件人或策略结果而不经过验证。生成的解释可以帮助用户理解行动，但它不是权威记录。

WCAG 2.2 输入辅助标准要求对重要提交进行错误识别、建议和预防支持（W3C, 2023）。智能体审批是类似的时刻：用户需要审查、纠正和确认将要提交或更改的内容。这包括键盘访问、可访问的名称、可感知的状态，以及不依赖颜色、动画或位置等单一因素的错误消息。

谨慎而严肃地使用审批

审批在以下情况下最有用：

行动是具体且重要的；
审查者拥有权限和足够的证据；
选择仍然可以改变结果；
系统可以将审批绑定到被审查的行动和状态版本；
自上次审批以来，行动发生了实质性变化；以及
审批数量不会训练出反射性点击。

不要要求批准模糊的意图，比如“让智能体继续”，而下一个影响是隐藏的。相反，不要打断每一次无害的读取、格式更改或低风险草稿步骤。将注意力集中在需要判断的后果、不可逆性、不确定性、新颖性、策略、安全性、隐私或成本阈值以及用户偏好上。

OpenAI 的智能体构建文章将人类干预视为适用于高风险行动和重复失败（OpenAI, 2026）。这些工程触发条件需要相应的产品流程：用户会看到什么、有哪些选择，以及当他们批准、拒绝、编辑或升级处理时会发生什么。

审批绝不应与验证混淆。用户可能批准发送一封电子邮件；产品仍然需要证据表明它已发送或未发送。主管可能批准退款；产品仍然需要与支付系统进行核对。审查者可能批准一个补丁；产品仍然需要仓库状态和测试结果。

设计注意力，而不仅仅是许可

人类注意力是一种稀缺的产品资源。如果每个小步骤看起来同等紧急，用户就会学会不阅读。一个好的委托设计通过以下方式过滤注意力：

后果和可逆性；
相对于先前审批的新颖性；
不确定性或缺失证据；
策略、安全、隐私或成本阈值；
用户角色和专业知识；
截止时间和时间敏感性；
系统是否可以在没有响应的情况下安全地继续；以及
部分结果现在是否足够。

这使得审批设计成为一个质量问题，而不只是模态对话框问题。测试时要看用户是否注意到预览中植入的错误，而不仅仅是他们是否声称自己感觉“可控”。解释可能增强信心，却未必减少过度依赖；2024 年的一项实证研究发现，AI 解释并没有一致地降低人们对错误建议的依赖（Cecil et al., 2024）。设计需要证据证明“人加系统”的整体流程确实有效。

让停止和撤销控制靠近用户

用户需要有可见的方式来：

暂停新工作；
取消运行；
拒绝提议的行动；
手动接管；
撤销工具、账户、数据源或权限；
清除、忽略或纠正记忆；
减少范围；
导出当前证据；
联系支持或升级；以及
以部分结果关闭任务。

诚实地报告取消。“正在停止…”不等于“未发生任何影响”。如果消息已经发送、写入正在进行中、或支付结果未知，请说明并显示恢复路径。隐藏进行中影响的产品会教导用户停止控制是装饰性的。

全局控制也很重要。Google People + AI Guidebook 强调反馈和控制机制，以便用户随着时间的推移纠正 AI 行为（Google PAIR）。智能体产品应使持久设置、记忆、连接的账户、自动化规则和默认委托模式可被发现，而无需强制用户通过一次对话。

支持多种控制风格

不同的用户需要不同的控制界面。

专家开发者可能想要紧凑的差异、命令日志、失败的测试和快速的拒绝路径。客户服务主管可能需要策略理由、客户影响、退款金额、审计追踪和升级控制。新手可能需要有指导的范围选择和通俗语言后果。值班操作员可能需要覆盖、时间线、效果状态和事件链接。

同时支持：

引导式控制，用于常见的安全路径；
可检查控制，用于专家审查、审计和特殊情况；以及
管理控制，用于组织级别的默认值、限制和撤销。

不要将所有高级控制隐藏在对话记录后面。对话式纠正很有用，但某些行动需要精确的界面控件：用于资源的复选框、用于预算的滑块或数字字段、账户列表、差异视图、审批表格和清晰的禁用状态。在精度重要时，产品控制就应该朴素直接。

确保控制可访问且持久

控制必须跨设备、会话、辅助技术和中断保持可用。一个运行数小时的委托任务不能依赖短暂的提示消息。用户应该能够返回工作空间，查看哪些权限仍然有效，并更改它们。

可访问性要求包括：

控制可以通过键盘到达；
清晰的无障碍名称和角色；
状态更新暴露给辅助技术；
错误消息与受影响的字段或行动相关联；
不依赖颜色单独表示风险或状态；
在存在超时的地方有足够的时间审查；
对严重不可逆的提交进行确认；以及
替代手势或仅拖拽操作。

这些不是独立的润色任务。如果用户无法感知或操作停止、审批或纠正控制，则该产品对该用户不提供有意义的控制。

将产品控制与执行绑定

每个面向用户的控制都应有相应的系统行为：

产品控制	所需系统行为
仅草稿	执行边界拒绝发送、提交、发布或写入效果。
排除来源	上下文组装和工具调用忽略该来源，并使基于该来源的声明失效。
花费限制	运行时预算阻止进一步有付费工作，并报告部分状态。
需要审批	有重大后果的行动被暂存，直到存在绑定的审批。
暂停	新行动停止；定时器、子任务和进行中的工作进入明确状态。
撤销账户	未来的工具调用默认拒绝（fail closed）或路由到重新授权。
忘记记忆	根据保留和删除规则，记忆被移除或范围调整。

当产品无法完全执行一个控制时，请说明限制是什么。例如，删除记忆可能不会删除已导出的产物或依法保留的审计记录。取消已发送的电子邮件并不能撤回邮件。界面不应暗示系统实际上无法提供的控制。

失败模式

隐藏的自主性

界面显示为“助手”，但系统可以更改记录、发送消息、触发子任务或持续运行数小时。用户无法选择合适的信任程度或监督方式。

审批疲劳

每一步都需要点击。人们自动批准，而一个真正需要审查的请求没有得到实际评估。

抽象同意

用户授予广泛访问权限，但没有看到具体行动、目标、数据、权限或后果。

未执行的控制

界面显示“仅草稿”之类的模式，但执行边界并未强制执行。工具或子智能体绕过了产品承诺。

无法平稳停止

用户取消，但待处理工作继续无形地进行。后续回调在用户认为工作已停止后更改了状态。

通过对话记录纠正

用户在聊天中纠正了范围，但旧的待处理行动、审批或子任务继续在已被取代的指令下运行。

仅限专家的控制

产品技术上暴露了日志和设置，但目标用户在决策时无法理解或操作它们。

本手册的判断

在工作开始前让委托约定可见。
提供映射到真实权限和时限差异的模式。
将自然语言目标转化为可检查的成功条件和约束。
让用户编辑范围，并显示编辑的影响。
使用结构化事实（而非仅生成的理由）预览有重大后果的行动。
在审批可以改变结果的地方使用审批；自动化有边界限制的低风险步骤。
将暂停、取消、接管、撤销和记忆控制放在工作附近。
确保界面控件可访问，且由执行边界强制执行。

检查清单

参考文献及其使用

Cecil et al., “The effects of AI explanations on human decision-making” - 同行评审证据，用于提示审批和解释必须按“人加系统”的整体流程来评估。
Google People + AI Research, “Feedback + Control” - Google People + AI Research 发布的设计网页章节，用于支持反馈、纠正、控制和退出机制；它不是正式标准，也不是独立控制保证。
Microsoft Research, “Guidelines for Human-AI Interaction” - 经同行评审的人机交互论文，支持调用、取消、纠正、全局控制、不确定性和谨慎适应。
OpenAI, “A practical guide to building AI agents” - OpenAI 面向产品与工程的智能体构建文章，用于高风险干预、移交和实际智能体控制模式。
W3C, Web Content Accessibility Guidelines 2.2 - W3C 推荐标准，用于可访问的输入辅助、错误预防、状态和可操作控制。