用户变了——从操作者到委托者、监督者与否决者

上一章讨论了一个变化：当 AI 从生成内容走向调用工具、执行任务，设计对象就不再只是界面，还包括意图、上下文、权限、行为和结果。

设计对象变了，用户的位置也会随之改变。

仍以差旅报销为例。在传统软件里，用户上传哪张票据、选择什么费用类型、填写多少金额、把申请提交给谁，几乎都由自己操作。系统可能帮助识别票据、校验字段和计算总额，但主要行动者仍然是用户。每一步都经过用户的手，操作链也大致就是责任链：哪项信息填错了，用户通常知道错在哪里，也知道回到哪个页面修改。

使用报销 Agent 时，用户可能只说一句：“把这次杭州出差的票据整理好，符合政策的直接生成申请，超标项目先问我。”接下来，Agent 会读取图片、匹配行程、查找政策、判断类型、计算金额并填写申请。Anthropic 在介绍可信 Agent 时也使用过类似场景：当酒店费用超过上限，而系统又不知道更具体的政策时，Agent 应该暂停，询问用户是否允许它继续从共享空间查找规则，再根据得到的信息调整计划。¹

表面上看，用户少做了很多事。但他并没有因此退出流程，而是换了一个位置。他需要说明目标和边界，决定哪些信息可以读取，判断 Agent 何时可以继续，检查关键依据，在异常时纠正方向，并对最终提交的申请负责。

过去，用户通过一步步操作来控制软件；现在，用户越来越像任务的委托者、协作者、审批者和监督者。交互的核心也从“下一步点哪里”，转向“这件事可以交出去多少，我需要在什么时候介入，又怎样确认系统没有走偏”。

这并不意味着所有用户都会成为全职监工。恰恰相反，好的 Agent 应该减少无意义的盯守，把人的注意力留给目标、例外、风险和判断。但要做到这一点，产品必须重新设计用户与系统之间的分工。否则，所谓自动化可能只是把填写表单的劳动，换成检查黑箱、反复审批和事后补救的劳动。

本章将从五个方面讨论用户角色的变化：用户为什么从操作者变成委托者；自主性与能动性为什么是两根不同的旋钮；人在不同自主等级下会扮演哪些角色；用户应该怎样形成恰当的信任；以及当 Agent 走偏时，产品怎样帮助用户看见、打断、回退与追责。

3.1　从操作者到委托者：谁负责哪一段？

“帮我完成这件事”和“告诉我怎样完成这件事”看起来只差几个字，背后却是两种完全不同的人机关系。

当用户让搜索工具查找资料、让导航软件规划路线时，系统主要提供信息或建议，用户仍然负责把建议转化成行动。Agent 则可能直接进入行动链：打开文件、修改数据、调用接口、发送消息，甚至根据中间结果改变原计划。这时，用户交出去的已经不只是一次操作，而是一段任务过程。

3.1.1　操作减少，不等于责任消失

传统软件中的用户通常同时承担五件事：设定目标、选择步骤、执行动作、检查结果并承担操作后果。系统的任务是把按钮、表单与规则稳定地提供出来。

Agent 会接手其中一部分工作，但五件事不会凭空消失，只会在人与系统之间重新分配。

这里最容易出现一个误解：既然用户不再亲自执行，就可以不再理解过程。对于整理文件、生成临时草稿等低风险任务，这种体验可能成立；但任务一旦涉及资金、权限、外部沟通、专业判断或他人权益，用户仍然需要知道系统做了什么，以及为什么现在需要自己介入。

所以，Agent 带来的并不是“用户消失”，而是用户的注意力从连续操作转向关键判断。过去的界面负责把每一步动作交给用户；新的界面则要把值得用户判断的节点，从一条更长、更快、也更不确定的行动链里提取出来。

3.1.2　委托的不是一句指令，而是一段责任

用户输入“帮我回复客户”，系统至少要面对三层问题。

第一层是目标。用户是希望礼貌告知处理进度，还是希望正式承诺解决时间？一句话里可能没有写清，但两种目标带来的措辞和后果完全不同。

第二层是边界。Agent 可以读取哪些历史沟通，能不能引用内部讨论，是否允许代表用户作出价格、交付时间和赔偿承诺？

第三层是完成标准。生成草稿算完成，等待用户确认后发送算完成，还是必须确认对方收到并更新客户系统才算完成？

如果这些问题没有被明确，Agent 只能依靠上下文猜测。模型越能把猜测表达得自然，用户越容易忽略目标和授权之间的缺口。于是，一句看似简单的委托，可能在行动过程中被悄悄扩展成更大的权限。

因此，委托设计的核心不是让用户写出一篇更长的提示词，而是让系统在合适的时候帮助用户补齐目标、边界和完成标准。低风险信息可以由系统合理推断，并允许用户事后修改；涉及身份、资金、承诺和不可逆影响的内容，则不应依赖猜测。

3.1.3　把“谁做”继续拆成判断、执行与后果

人机分工不能只用“人工”或“自动”两个标签描述。

以退款任务为例，Agent 可以收集订单和物流信息，由客服判断是否满足退款条件；也可以根据规则给出退款建议，但由客服确认；还可以在金额较低、政策明确时自动退款，只把规则冲突和高金额订单升级给主管。三种方案都使用了 AI，却代表完全不同的委托关系。

更准确的理解是把任务看成三层。

判断层回答“谁决定应该怎么做”。执行层回答“谁把决定变成系统动作”。后果层回答“谁确认结果，处理例外，并为外部影响负责”。

当这三层被混在一起时，产品很容易把“系统能够执行”误认为“系统有权决定”，再把“用户点了同意”误认为“用户已经理解并承担全部责任”。

真正有效的分工应该让决定权、执行权和责任相互匹配。一个人如果看不到依据、不了解规则、没有时间核对，却被安排在最后点击批准，那么他只是流程上的签名者，而不是有能力监督系统的人。

3.1.4　监督不是把责任推给最后一个按钮

很多产品会在高风险动作前加一个确认弹窗，然后认为 human-in-the-loop 已经完成。问题是，确认只是一种界面动作，不等于用户拥有有效判断。

假设报销 Agent 准备提交 38 张票据，界面只显示“已整理完成，是否提交”。用户不知道哪些字段由 OCR 识别，哪几项与政策冲突，也看不到总额相对原始票据发生了什么变化。这时即使用户点了“确认”，也很难说明他真的审查了申请。

有效审批至少要回答几件事：系统准备做什么；依据是什么；哪些内容发生过推断；影响哪些对象；结果能不能撤销；如果不批准，还有哪些选择。确认信息越接近用户真正需要作出的判断，监督才越有意义。

NIST 的 AI 风险管理框架要求组织明确人机配置中的角色、责任与监督流程，并强调负责监督的人需要理解系统知识边界以及输出将怎样被使用。³ 这说明责任不能只写进用户协议，也不能通过一个按钮临时转移给用户。产品、流程和组织需要共同保证监督者拥有信息、能力、时间与权限。

3.1.5　自动化也会产生新的用户劳动

Agent 减少了逐项操作，却可能增加另外几种劳动：等待长任务完成，理解系统状态，处理升级，检查批量结果，纠正重复错误，以及在出事后重建行动经过。

例如，客服团队原来每天手动处理 100 笔退款。引入 Agent 后，大部分订单可以自动整理，但系统每天向客服发出 80 次“是否继续”的确认。如果每次确认都要重新打开订单、政策和聊天记录，团队的工作并没有真正减少，只是从执行劳动变成了上下文重建和审批劳动。

这时设计师需要计算的不只是“Agent 自动完成了多少步骤”，还包括用户为监督付出了多少注意力：一天收到多少次升级；每次需要理解多少信息；不同升级是否能批量处理；哪些问题可以由系统规则直接阻断；人的一次判断能不能减少以后同类打扰。

好的自动化不是让系统做得最多，而是把机器擅长的重复执行与人擅长的目标、例外和价值判断合理分开。如果监督成本持续上升，说明人机分工本身需要调整，而不是简单要求用户更认真。

《Designing AI Interfaces》把共享控制与“频繁确认”明确区分开来：系统应让人调整自主范围，但只把主观权衡、歧义与不可逆动作交还给人。⁹ 这给监督劳动增加了一个更实际的判断标准：确认次数不是越多越好；一次确认只有在它改变了行动范围、风险承担或后续路径时才有价值。其余风险更适合由权限、阈值、沙盒和自动校验在系统层处理。

3.1.6　委托边界应该随任务变化

用户愿意交出去多少工作，通常取决于四个因素：出错后果有多大，动作是否可撤销，影响范围有多广，以及自己能否判断结果。

同一位用户在不同任务中也会有不同选择。一个有经验的设计师可能愿意让 Agent 自动整理图层，却不会让它未经确认发布品牌资产；财务人员可能允许系统自动归类常规费用，但保留对超标、跨币种和关联交易的判断。

因此，委托不是产品上线时一次性决定的开关，而是一种随任务、风险、经验和环境变化的关系。设计师要做的不是把所有人推向同一种自动化程度，而是让人清楚知道自己交出了什么，还保留什么。

3.2　自主性与能动性：两根可以独立调节的旋钮

讨论 Agent 时，人们经常把“能力强”“能做的事多”和“能够独立完成”混成同一个概念。它们相关，但并不相同。

为了避免混乱，本书把三个概念分开。

能力回答“做得好不好”，例如模型能否正确理解票据、识别政策冲突和规划多步任务。

能动性回答“可以在环境里做多少事”，包括能使用哪些工具、读写哪些数据、影响哪些对象，以及一次行动可能产生多大的外部后果。这里所说的能动性主要指 Agent 的行动范围，不是人的主观能动性。

自主性回答“在没有用户介入的情况下可以走多远”。2025 年的《Levels of Autonomy for AI Agents》也把自主性定义为 Agent 被设计成在多大程度上无需用户参与，并强调它可以独立于系统能力进行设计。一个很强的 Agent 可以被要求每一步都与用户协作；一个能力普通的系统，也可能在非常狭窄、低风险的任务里自动运行。²

3.2.1　会做，不等于可以自己做

假设一个邮件 Agent 能够读取历史邮件、理解上下文、生成回复、添加附件并调用发送接口。它的能力和能动性都很高，但产品仍然可以把自主性限制在很低的水平：Agent 只能起草，用户确认后才能发送。

反过来，一个每天凌晨自动汇总服务器状态的 Agent，可能只有读取日志和生成摘要两项能力，能动性很窄，却可以在这个范围内高度自主地运行，不必每天询问用户。

这两个例子说明，Agent 的“聪明程度”不会自动给它带来行动授权。自主性不是模型升级后的自然奖励，而是产品基于场景作出的决定。

如果团队把三者混在一起，就容易出现两种错误。第一种是模型效果提升后顺手开放更多工具，让能力增长自动变成权限扩张。第二种是为了降低风险不断增加确认，却没有收紧工具和数据边界，最终让用户承担一个本来可以由系统结构解决的安全问题。

3.2.2　四种组合会产生四种体验

把能动性与自主性画成两个维度，可以得到四种常见组合。

低能动性、低自主性的产品接近传统辅助工具。它适合学习、探索和高专业任务，因为用户始终掌握流程。

低能动性、高自主性的产品常见于边界清楚的后台自动化。系统能做的事不多，但可以稳定、重复地自己完成。

高能动性、低自主性的产品拥有丰富工具，却把决定权留给人。它能减少操作成本，但如果确认点过多，很容易产生审批疲劳。

高能动性、高自主性的产品最接近人们想象中的完整 Agent。它可以带来最大的效率提升，也有最大的影响半径。一旦目标理解、权限配置或环境信息出错，错误可能沿行动链不断放大。

这四种组合没有天然的高低之分。关键是它们是否与任务风险、用户能力和恢复条件匹配。

3.2.3　不要给整个产品只设一个自主等级

自主性更适合按任务阶段和动作类型配置，而不是给产品贴一个统一标签。

在报销流程中，票据去重可以高度自主，因为它只产生候选结果，用户也能恢复；费用分类可以在置信证据充分时自动完成，把模糊项交给用户；读取公司政策需要明确数据范围；提交申请会改变外部系统状态，适合先预览；如果涉及付款，则需要更严格的审批与权限。

这样做的好处是，用户不必在“全自动”和“每步都问”之间二选一。产品可以让低风险步骤保持流畅，把人的注意力集中到真正重要的节点。

3.2.4　自主性上限由后果决定，而不是由演示效果决定

一段顺利的 Demo 很容易让人觉得 Agent 已经可以独立完成整件事，但产品中的自主性上限应该由失败时会发生什么来决定。

出错后可以一键撤销、只影响当前用户、系统状态清楚、证据容易核验的动作，可以给予更多自主空间。结果不可逆、涉及资金和他人权益、会对外形成承诺、影响生产环境，或者用户难以验证的动作，则需要更严格的边界。

OpenAI 的 Agent 构建指南建议按照读写性质、可逆性、账户权限和财务影响评估工具风险，并在失败次数超过阈值或动作高风险、不可逆时转交给人。⁴ 这类判断的重点不是“模型有没有信心”，而是“如果判断错了，谁会受到什么影响，以及还能不能补救”。

因此，设计师可以用四个问题检查自主性是否过高：

1. 错误会影响谁，影响范围有多大？
2. 用户是否能在行动前看懂后果？
3. 行动后能否撤销、回滚或补偿？
4. 如果系统持续走偏，有没有明确的停止条件？

只要其中一项答案不清楚，就不应该仅凭模型能力扩大自主范围。

3.2.5　提高 Agent 自主性时，也要保留人的能动性

前面把“能动性”用于描述 Agent 的行动范围，但从用户体验角度看，还要关注人的能动性，也就是用户是否仍然能够理解目标、表达偏好、改变方向、拒绝建议和接管任务。

一个 Agent 即使高度自主，也不应让用户失去所有有效控制。用户至少需要知道当前任务是什么、系统被允许做什么、怎样暂停或退出，以及哪些后果已经发生。否则，“替用户行动”很容易变成“替用户决定”。

这里有一个重要平衡：如果用户必须持续盯着每一步，自主性就失去了价值；如果用户只有在结果已经不可挽回时才知道发生了什么，人的控制又只是名义上的。

更合理的体验是让 Agent 在清楚边界内独立工作，同时给用户提供少量但有效的控制：任务级目标、工具与权限设置、关键检查点、异常升级、全局暂停和结果回退。人的能动性不一定表现为更多按钮，而表现为在真正重要的时候仍然能改变事情。

3.3　人的五种新角色：操作者、协作者、顾问、审批者、观察者

当 Agent 的自主性提高，用户并不是从“使用者”直接跳到“旁观者”，中间还存在多种关系。

《Levels of Autonomy for AI Agents》从用户视角提出了五个逐渐提高的自主等级：操作者、协作者、顾问、审批者和观察者。这里的名称描述的是人的角色，而不是 Agent 的职位。Agent 越自主，用户参与日常计划与执行的程度通常越低。²

这五种角色不是成熟度排行榜，也不代表用户越少参与越先进。它们提供的是一组设计语言，帮助团队讨论一项任务中谁规划、谁行动、谁判断，以及用户还能怎样施加控制。

3.3.1　操作者：用户掌握整个流程

在操作者模式中，用户负责长期目标、任务拆解和主要行动，AI 只在被需要时提供支持。

例如，用户准备一份行业研究报告。他自己决定先阅读哪些资料、提出什么问题和怎样组织论证；当需要摘要一篇长文、解释一个术语或生成一段图表代码时，再调用 AI。AI 可以提出建议，却不会未经请求改变研究方向或自动提交结果。

这种模式看似不够“Agent”，却非常适合两类任务。第一类是高风险、高专业判断任务，因为用户需要保持对全过程的理解。第二类是学习和能力成长任务，因为亲自规划、练习与纠错本身就是价值。如果语言学习产品把所有翻译和表达都自动完成，效率可能提高了，用户的能力却没有得到锻炼。

操作者模式的设计重点是低摩擦调用与直接控制。用户应该能快速请求帮助、忽略建议、修改结果，并在不同工具之间保留自己的工作上下文。AI 不应为了显得主动而频繁打断，也不应把一次建议自动升级成行动。

3.3.2　协作者：人与 Agent 共同完成任务

在协作者模式中，人与 Agent 都可以计划、分工和执行。用户不再亲自完成所有步骤，但仍然持续参与过程。

仍以研究报告为例，Agent 可以先提出一份计划，用户直接增删步骤，并决定哪些资料由 Agent 搜集，哪些分析自己完成。双方可以并行工作：Agent 阅读多份公开报告，用户访谈业务专家；遇到付费资料或来源冲突时，Agent 把问题放回共享计划，用户决定跳过、补充或改变方向。

协作关系的关键不是聊天次数多，而是双方围绕同一个任务状态工作。用户需要看见 Agent 正在做什么、产生了哪些中间结果、遇到什么阻塞；Agent 也要知道用户修改了哪一项假设、接手了哪一个步骤，以及这些变化会怎样影响后续计划。

因此，协作者模式往往需要共享画布、可编辑计划、任务归属、进度状态和中间产物。聊天可以用来讨论，但不能成为唯一的事实来源。否则，所有分工都埋在对话里，人与 Agent 很容易各自沿着不同版本的目标继续工作。

3.3.3　顾问：用户提供系统缺少的判断

在顾问模式中，Agent 负责大部分规划与执行，用户主要提供专业知识、价值偏好和高层方向。

例如，Agent 可以独立完成资料搜索、初步归类和报告结构，并在几个关键问题上咨询用户：“这份报告更重视短期商业机会，还是长期技术趋势？”“这两个来源结论冲突，你更信任哪类证据？”“是否需要纳入尚未公开验证的行业观点？”

顾问与审批者的区别在于，顾问不是只回答“同意或不同意”，而是在系统无法独立决定价值取舍时贡献信息。一个好的咨询问题应该说明为什么现在需要用户、用户的答案会影响哪些后续步骤，并让用户能够表达超出预设选项的意见。

时机尤其重要。问得太早，用户没有足够上下文；问得太晚，Agent 已经沿错误方向完成大量工作；问题过多，顾问模式又退化成用户替系统做计划。因此，产品需要识别“这项信息只有用户知道”与“系统只是懒得判断”的区别，把咨询留给偏好、专业经验和真正的歧义。

3.3.4　审批者：只在阻塞与高影响动作前介入

在审批者模式中，Agent 会自己完成大部分低风险决定，只在遇到无法解决的阻塞、缺少授权或准备执行重要动作时请求用户。

例如，报销 Agent 可以自动整理全部票据，但发现酒店费用超标时请求财务人员决定；客服 Agent 可以自动起草退款方案，但在高金额退款前等待主管确认；邮件 Agent 可以整理收件箱和生成草稿，却在代表用户向外部联系人发送前暂停。

审批者模式可以显著减少日常操作，但它对确认设计要求最高。因为用户平时不参与过程，被叫回来时往往缺少上下文。界面不能只显示“是否继续”，而要给出触发原因、关键依据、行动预览、影响范围、可逆性和备选方案。

审批越多，也不一定越安全。Anthropic 在 2026 年公开的 Claude Code 使用数据中提到，用户大约批准了 93% 的权限提示；提示越多，对每一次提示的注意力越低。随后通过沙盒收紧系统能够触达的范围，权限提示减少了 84%。⁵ 这个案例说明，与其让用户批准所有动作，不如先在系统层限制危险能力，再把少量真正重要的决定交给人。

所以，审批者模式需要同时设计两件事：什么情况必须找人，以及什么情况根本不应该进入人的审批队列。已知危险动作应该由权限和规则阻断，重复低风险动作可以在受控范围内自动完成，只有需要人类责任、专业知识或价值判断的节点才值得打断用户。

3.3.5　观察者：系统独立运行，人负责监控与熔断

观察者对应最高自主程度。Agent 自己制定计划、执行任务和处理常规阻塞，用户主要查看活动、结果与异常，必要时使用紧急停止。

这种模式常见于边界非常明确的后台任务，例如在沙盒中批量运行测试、在只读数据上生成周期性分析，或在严格限额内调度资源。用户不需要逐步参与，但应该能够知道系统是否健康、是否偏离目标，以及错误是否正在扩散。

观察并不等于有效控制。一个只提供几万行日志、没有异常提示和影响范围的监控页面，虽然技术上“可查看”，实际上很难让人及时介入。如果用户只能在事后看到结果，紧急停止也无法处理已经发生的外部影响。

因此，高自主模式必须依赖更强的环境边界、状态汇总、异常检测、停止条件和恢复机制。能动性越广，观察者就越难凭个人注意力维持监督。对于高风险、不可逆或用户无法理解的任务，单纯把人放在“观察者”位置通常并不合适。

3.3.6　同一条任务里，角色可以不断变化

真实产品不必让用户从头到尾只扮演一种角色。

在一条报销任务中，用户可以在上传材料时是操作者，主动决定哪些票据属于本次出差；Agent 整理和去重时，用户退到观察者位置；遇到两版政策冲突时，用户成为顾问，提供组织背景；提交申请前，用户成为审批者；如果系统反复分类错误，用户又可以接管部分工作，与 Agent 共同修改。

这种动态关系比统一的“自动模式”更贴近用户。设计师需要清楚标记当前谁在负责、Agent 为什么暂停、用户的操作会把控制权交给谁，以及任务何时从一种关系切换到另一种关系。

3.3.7　人在环内，还要有能力在环内

给流程安排一个人并不难，难的是保证这个人能够完成监督。

有效监督至少需要四个条件：看得懂当前信息，有足够时间判断，拥有暂停或推翻的权限，并知道自己的责任范围。如果审批人看不懂模型引用的数据，或者为了完成工作量只能机械点击，他虽然出现在流程图里，却没有真正发挥作用。

这也意味着不同角色需要不同界面。操作者需要高效调用和编辑，协作者需要共享状态，顾问需要高质量问题，审批者需要决策上下文，观察者需要异常与影响汇总。把同一个聊天框提供给五种角色，很难支撑如此不同的任务。

3.4　用户什么时候该信任，什么时候该怀疑

很多 AI 产品会把“建立用户信任”写成设计目标。这个目标并不完整。

如果系统并不可靠，用户越信任，风险反而越大；如果系统在某个范围内已经稳定，用户始终拒绝使用，也无法获得价值。真正需要设计的不是信任越多越好，而是让用户在合适的情况下依赖系统，在不合适的情况下保持怀疑。

这可以称为信任校准。它关心的不是用户对 AI 的整体态度，而是用户能否针对当前任务作出恰当的依赖决定。

3.4.1　信任的对象必须具体

用户说“我信任这个 Agent”，可能同时混合了多种意思：相信它不会泄露数据，相信它能正确理解目标，相信它引用的资料真实，相信它不会越权，相信出错后可以恢复。

这些信任并不能互相替代。一个写作 Agent 可能很擅长改写语气，却不适合核对法律事实；一个报销 Agent 可能准确识别金额，却没有权限代表用户提交；一个搜索 Agent 可能找到了真实来源，却在总结时遗漏关键限制。

因此，产品要把信任对象拆开：对内容正确性的信任，对数据与隐私边界的信任，对执行行为的信任，以及对恢复机制的信任。设计师不应该用一个模糊的“AI 生成，请注意核实”覆盖全部问题，而应告诉用户这一步具体依赖什么、可能在哪里失败。

3.4.2　先让用户形成正确预期

用户第一次使用 AI 产品时，通常会从产品名称、界面语言、演示案例和一次成功结果推断系统能力。如果宣传只展示最顺利的场景，用户就容易把局部能力理解成普遍能力。

Microsoft 的人机 AI 交互指南把“说明系统能做什么”和“说明系统做得有多好”放在最初使用阶段，并在系统出错时强调容易忽略、纠正、恢复和理解原因。⁶ 这些原则背后的逻辑是：信任校准要从能力预期开始，而不是等错误发生后再补一句免责声明。

设计师可以通过具体边界帮助用户理解系统：它支持哪些任务，不支持哪些任务；使用什么数据；哪些结果是草稿，哪些会进入外部系统；在哪些情况下必须复核；能力更新后，原有行为是否会变化。

“本产品使用先进 AI”不会形成有用的心智模型；“可以整理当前项目文件，但不会读取项目之外的内容；删除和对外发送前需要确认”才会。

3.4.3　让用户看证据，而不是看 AI 的语气

生成式 AI 可以用非常流畅、完整和肯定的语言表达一个错误结论。语气越像专家，用户越容易把表达质量误认为事实质量。

所以，帮助用户判断的重点不应是展示一大段“AI 为什么这样想”，而是提供可以核验的外部证据：引用了哪一版政策，数据来自什么时间，计算使用哪些字段，哪些地方缺少信息，哪些来源互相冲突，执行前后具体改变了什么。

以报销 Agent 为例，“根据公司政策，这笔酒店费用超标”只是结论。更可验证的表达应该同时显示政策名称与版本、适用城市与职级、上限金额、票据金额，以及系统是否发现例外条款。用户不需要阅读模型全部内部过程，但需要看到足以支持决定的事实。

解释的目标不是说服用户相信 AI，而是降低核验成本。如果解释只是把结论换一种更长的说法，它可能增加表面透明度，却没有增加用户的判断能力。

3.4.4　不确定性必须转化成下一步动作

很多界面会用一个置信度百分比表达不确定性。但如果数字本身没有经过校准，或者用户不知道 72% 对当前任务意味着什么，它只会制造一种精确的错觉。

对用户更有帮助的是说明不确定性来自哪里，以及现在应该怎样处理。

设计师需要把“系统不确定”翻译成具体交互：追问一个缺失条件，缩小服务范围，展示多个选择，暂停高风险动作，或者明确承认当前无法完成。模糊地说“结果仅供参考”，会把所有核验成本留给用户。

3.4.5　风险、可逆性和可验证性共同决定检查强度

用户是否应该相信一次结果，不能只看模型平均准确率。还要看本次任务的后果是否严重，结果是否可撤销，以及用户是否有办法验证。

一段社交媒体文案可以快速阅读和修改，即使生成偶有瑕疵，风险也有限；一条涉及合同金额的摘要看起来同样只是文字，却可能影响重要决定；一个已经发送、付款或删除数据的动作，即使出错概率很低，也需要更强保护。

因此，检查强度可以遵循一个简单原则：风险越高、越不可逆、越难验证，人类介入越应该提前；风险越低、越可撤销、越容易看出错误，系统越可以先行动，再让用户通过结果与撤销进行控制。

这也是为什么所有动作都用同一种确认方式并不合理。低风险编辑如果每次都弹窗，会让用户疲惫；高风险操作如果只在事后提供“撤销”，可能已经来不及。

3.4.6　在关键位置保留一点“有价值的摩擦”

传统体验设计经常追求减少步骤，但 Agent 产品不能把所有摩擦都当作坏事。

当用户准备把内容发给外部、让系统访问新的数据范围、执行不可逆动作，或采纳影响他人的判断时，短暂的停顿可以帮助他重新进入任务。关键是这段摩擦必须提供新的信息，而不是让用户再点一次相同按钮。

有效的停顿可能是一份差异预览、一张证据卡片、一个影响范围列表，或一句清楚的问题：“这封邮件将发送给 126 位客户，并承诺在 7 月 15 日前退款。是否继续？”

无效的停顿则是没有上下文的“请确认操作”、每一步重复索取相同权限，或者通过醒目的主按钮诱导用户快速同意。

有价值的摩擦不是减慢所有任务，而是在人的判断最能改变后果的地方减速。

3.4.7　给用户一套可复用的怀疑方法

用户不可能理解每个模型和工具的技术细节，但产品可以帮助他形成几项稳定的检查习惯。

面对一个重要结果时，用户至少可以问四个问题：

1. 这件事是否真的在系统声明的能力与授权范围内？
2. 结论依据哪些事实，来源是否完整、当前且可核验？
3. 如果结果错了，会影响谁，能不能撤销或补救？
4. 我现在是否拥有足够信息和专业能力作出判断？

如果系统能够围绕这四个问题组织信息，用户就不必在“完全相信”和“完全不用”之间摆动，而可以形成有条件的依赖。

这种能力也会成为未来用户体验的重要组成部分。用户需要学会监督 AI，产品则有责任把监督设计成可执行的行为，而不是要求用户始终保持抽象的警惕。

3.5　如果 AI 走偏了：看见、打断、回退与追责

Agent 的错误不一定表现为一个红色报错框。它可能仍在正常运行，只是理解错了目标、引用了过期信息、选择了一条代价更高的路径，或者在多次调整后逐渐偏离用户最初的要求。

这类“走偏”比单次生成错误更难处理。因为系统可能已经连续执行多个步骤，每一步单独看都合理，合在一起却产生了用户没有预期的结果。

所以，恢复设计不能等到任务失败后才出现。用户需要在行动过程中看见方向，在必要时打断，在结果发生后回退，并在无法恢复时找到清楚的责任与补救路径。

3.5.1　先让偏离变得可见

用户要发现 Agent 走偏，至少需要看到六类信息：当前目标、计划与进度、正在使用的依据、已经产生的改变、下一步可能造成的外部影响，以及异常与重试。

原始日志通常不能满足这个要求。日志记录了系统调用什么函数、返回什么参数，却不一定告诉用户“这与我的目标有什么关系”。面向监督的界面应该把机器轨迹转化为用户能判断的任务状态。

这些信息不需要同时铺满屏幕。低风险任务可以只显示简短进度，高风险节点再展开证据与影响。关键是用户能从概览发现异常，再逐层进入细节，而不是只能在“完全不看”和“阅读全部日志”之间选择。

3.5.2　打断必须让系统停在安全状态

很多界面提供“停止生成”，但 Agent 的停止比停止一段文字更复杂。用户点击暂停时，系统可能正在写数据库、发送请求或等待外部服务返回。界面显示停了，不代表外部动作真的没有发生。

因此，暂停需要被设计成一个明确状态，而不是按钮动画。系统应该告诉用户：哪些步骤已经完成，哪个动作正在处理中，哪些步骤尚未开始；当前动作能否取消；如果不能取消，系统将怎样确认最终状态。

Anthropic 在 Agent 工程建议中提到，长任务可以在检查点或阻塞处暂停获取人类反馈，并通过最大迭代次数等停止条件维持控制。⁸ 对产品来说，停止条件不仅是工程参数，也应该成为体验承诺：连续失败几次会暂停，成本达到多少会询问，偏离什么边界会终止。

一个安全的暂停流程可以是：用户发出暂停请求；系统停止创建新动作；等待当前不可中断操作返回；核对外部系统真实状态；保存检查点；最后把已完成、未完成和状态不明的内容交给用户。只有这样，“暂停”才不会制造新的不确定性。

3.5.3　纠正应该发生在合适的层级

发现偏离后，用户可能需要修改一个字段，也可能需要改变整条计划。产品如果只允许重新输入一句提示词，用户就不得不依赖 Agent 猜测这次修改应该影响哪些步骤。

更合适的纠正方式应该对应不同层级。

字段级纠正用于修改金额、名称、日期等局部事实；步骤级纠正用于重做分类、跳过来源或更换工具；计划级纠正用于调整顺序、添加检查点或删除整段任务；目标级纠正则用于重新定义结果、范围与成功标准。

每次纠正都要说明影响：哪些后续结果会失效，哪些已完成动作可以保留，是否需要重新计算，以及新的方向从哪个检查点开始。

Microsoft 的人机 AI 交互指南强调让用户能够高效忽略和纠正错误，并支持编辑、细化与恢复。⁶ “高效”并不只是少点几次，而是不用为了一个局部错误推倒全部工作，也不会因为修改一个字段而悄悄留下不一致的后续结果。

3.5.4　接管需要一份完整的交接包

当 Agent 无法继续，或者用户不再愿意让它继续时，系统需要把任务交还给人。

真正的接管不是关闭 AI 后让用户从头开始。用户需要知道目标是什么，已经做了什么，哪些事实得到确认，哪些结果仍是推断，当前卡在哪里，以及接下来有哪些可选动作。

以客服 Agent 为例，如果系统因为政策冲突把退款任务交给人工客服，交接内容至少应该包括客户请求、订单事实、检索过的政策、冲突条款、已起草的回复、尚未执行的动作和升级原因。客服可以从这个状态继续判断，而不是重新翻阅全部聊天记录。

产品还要清楚标记控制权归属。Agent 是否仍在后台运行；用户修改后它会不会自动继续；接管是暂时的还是永久的；恢复自动模式前是否需要重新确认目标与权限。这些细节决定用户是否真正接过任务。

3.5.5　回退与补偿是两种不同能力

“撤销”听起来简单，但并非所有 Agent 行动都能回到原状。

文档和代码可以保存版本，数据库写入可以通过事务或反向操作恢复；已经发送的邮件、已经公开的内容和已经被第三方读取的数据，却很难真正收回。订单可以取消、款项可以退款，但取消费用、时间延迟和对方感受仍然存在。

因此，设计师需要区分回退与补偿。回退是恢复之前的系统状态；补偿是在状态无法完全恢复时，通过取消、退款、道歉、更正或人工处理降低影响。

对于不可逆动作，最有效的恢复设计往往发生在执行之前：预览、延迟发送、二次确认、限额、沙盒和最小权限。不能把所有希望都寄托在事后的“撤销”按钮上。

3.5.6　追责需要可读的行动链

当 Agent 造成错误时，团队需要回答的不只是“模型为什么这样说”，还包括是谁发起任务，系统当时被允许做什么，使用了哪些数据和工具，哪一步经过人工批准，外部系统返回什么结果，以及后续怎样处理。

一条可用的审计记录至少包括：

1. 任务发起人、目标、范围与时间；
2. 使用的 Agent、模型、规则和版本；
3. 访问的数据来源、工具与权限；
4. 关键决定、异常、重试与人工介入；
5. 每次外部动作的参数、回执与影响对象；
6. 用户的批准、修改、驳回和接管；
7. 最终结果、补救措施与责任负责人。

这不是要求产品向用户展示模型的全部内部推理，也不是把原始技术日志直接倾倒出来。审计的目标是重建与责任相关的事实，让用户、运营人员、设计师和工程师能够判断哪一层出了问题。

NIST AI RMF 把角色、责任、持续监控、事件识别和反馈纳入整个生命周期的治理，而不是把责任留到事故发生后再讨论。³ 对 Agent 产品来说，日志、版本、审批与回执因此不是后台附属功能，而是用户监督能够成立的基础。

3.5.7　有效监督需要理解、推翻与停止的权力

欧盟《人工智能法案》第 14 条针对高风险 AI 系统提出了非常具体的人类监督要求：监督者应能够理解系统的能力与限制，监测异常，警惕自动化偏差，正确解释输出，决定不使用或推翻结果，并能够介入或通过停止机制让系统安全停下。⁷

这些要求虽然针对特定高风险系统，却为一般 Agent 设计提供了一组清楚的检查问题：

• 用户知道 Agent 能做什么、不能做什么吗？
• 用户能发现它正在异常运行吗？
• 用户有足够证据质疑结果吗？
• 用户可以拒绝、覆盖或反转决定吗？
• 用户能停止系统，而不是只关闭当前页面吗？
• 停止之后，系统会进入安全、可理解的状态吗？

如果答案是否定的，那么“人类监督”可能只存在于产品说明里。

3.5.8　把一次走偏变成可恢复的协作

回到开头的报销场景。假设 Agent 找到一份旧版差旅政策，按照其中的标准把三笔酒店费用标记为超标，并准备删除其中两笔不符合条件的费用。

一个缺少监督设计的产品可能只在最后显示“申请已整理，是否提交”。用户要么相信结果，要么重新检查全部票据。

一个可监督的产品则会在政策版本冲突时标记异常，显示当前引用文件的日期和更新版本，暂停删除动作，并告诉用户这项选择会影响哪三笔费用。用户可以切换到新政策，让系统只重新计算受影响项目；如果 Agent 已经修改草稿，系统可以从上一个检查点恢复；最终提交时，审计记录会保存政策版本、用户选择和申请回执。

在这个过程中，用户没有重新完成所有报销操作，却始终拥有有效判断。系统的错误也没有被隐藏，而是被转化成一次看得见、能纠正、可恢复的协作。

这正是从操作者到监督者的真正含义：用户不再控制每一个动作，但仍然能够控制方向、边界与后果。

本章小结

Agent 时代，用户角色发生了五个相互关联的变化。

第一，用户从连续操作者变成任务委托者。操作步骤减少后，目标、边界、判断、执行与后果需要在人与 Agent 之间重新分配。委托不是一句指令，而是一段责任关系。

第二，能力、能动性与自主性必须分开。能力决定 Agent 做得好不好，能动性决定它可以影响什么，自主性决定它无需用户介入可以走多远。提高模型能力不等于应该自动扩大权限与自主范围。

第三，用户会在操作者、协作者、顾问、审批者和观察者之间切换。这些角色不是产品成熟度等级，而是不同的人机分工。好的产品会根据任务阶段、风险和用户能力动态安排角色。

第四，设计目标不应是让用户尽可能信任 AI，而是帮助用户形成恰当依赖。能力边界、可核验证据、不确定性、风险、可逆性和有价值的摩擦，共同决定用户什么时候可以接受，什么时候应该检查、拒绝或接管。

第五，监督必须落实为具体能力。用户需要看见目标、计划、依据与影响，能够安全打断，在合适层级纠正，从检查点回退，对不可逆后果进行补偿，并通过可读的行动链追溯责任。

用户从操作者变成监督者，并不是从“做事的人”变成“看机器做事的人”。他的工作从逐步执行，转向设定目标、提供判断、处理例外和守住后果。产品真正要减少的，是不必要的操作；真正要保留的，是用户对任务的理解、选择和最终控制。

当用户的位置发生变化，传统设计流程也必须随之改变。设计师不能只研究用户怎样点击和完成任务，还要研究用户愿意委托什么、怎样监督、何时接管，以及系统的分工与边界怎样被原型、测试和持续治理。下一章将继续讨论：Agent 时代的设计思维应该怎样变化。

¹ Anthropic, “Trustworthy agents in practice,” 2026，https://www.anthropic.com/research/trustworthy-agents 。

² K. J. Kevin Feng, David W. McDonald, Amy X. Zhang, “Levels of Autonomy for AI Agents,” 2025，https://arxiv.org/abs/2506.12469 。

³ NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023，https://airc.nist.gov/airmf-resources/airmf/5-sec-core/ 。

⁴ OpenAI, “A practical guide to building agents,” https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/ 。

⁵ Anthropic, “How we contain Claude across products,” 2026，https://www.anthropic.com/engineering/how-we-contain-claude 。

⁶ Microsoft Research, “Guidelines for Human-AI Interaction Design,” 2019，https://www.microsoft.com/en-us/research/blog/guidelines-for-human-ai-interaction-design/ 。

⁷ European Union, Artificial Intelligence Act, Regulation (EU) 2024/1689, Article 14，https://eur-lex.europa.eu/eli/reg/2024/1689/oj 。

⁸ Anthropic, “Building effective agents,” 2024，https://www.anthropic.com/engineering/building-effective-agents 。

⁹ Louise Macfadyen, Designing AI Interfaces, O’Reilly Media, 2026，章节 “New Principles for Agentic Interface Design” 与 “Design for Shared Control”；本地转述见 素材/书摘-第1轮-Designing-AI-Interfaces.md。