自主性开关：为何智能体模式应是用户设置而非模型设置

Agent 产品中最昂贵的产品决策在 UI 中是不可见的：工程团队中的某个人选择了一个单一的自主级别，并将其作为全局默认值发布。谨慎的用户为了完成一个任务，被迫输入三条澄清问题的消息；而高级用户则因为每一步都需要审批而直接关闭了标签页。这两者看起来都像是产品市场契合点（PMF）的问题，但实际上，它们都源于同一个设计决策。

自主性并非模型属性。它是一个 UX 维度 —— 就像通知频率、显示密度或默认排序方式一样 —— 不同的用户希望针对不同的任务进行不同的设置。将其视为硬编码的工程选择，是将光谱上的一个孤点强加给分布在整个光谱上的用户群。解决方案不是寻找一个更好的默认值，而是提供一个可调节的旋钮。

一旦你发现了这种模式，它就变得显而易见。团队发布了一个自主级别的版本。调研结果却两极分化：一半人说“别再打断我了”，另一半人说“别再背着我偷偷做事”。团队对两个级别进行 A/B 测试，最后发布了两者的平均值。结果谁都不满意，因为“平均用户”并不存在 —— 现实中存在两个群体，而产品却只有一个。三个季度后，终于有人开发了一个设置项，客户支持的工作负载一夜之间减少了三分之一。

自主性阶梯属于框架，而非功能

当团队最终决定构建切换开关时，犯的第一个错误就是让每个功能定义自己的开关。收件箱整理功能有“审阅”和“自动”按钮；日历调度有“草稿”和“发送”；代码审查功能有“仅评论”和“自动合并”。不到六个月，你就会拥有 11 个功能和 11 套词汇，而用户在一个功能中学到的“自动”含义，在另一个功能中完全对不上号。

一个有效的自主性阶梯应该在框架层统一衡量，其模式名称在所有出现的地方都具有相同的含义。通常四个等级就足够了：

• 给我看。 Agent 展示它将要做什么，但不采取任何行动。纯粹的只读建议。
• 问我。 Agent 准备好操作，并在执行每一步之前等待批准。循环中包含确认环节。
• 做了再给我看。 Agent 执行操作，然后同步显示回执，用户可以立即撤销或修改。
• 做了再回头告诉我。 Agent 静默执行，并将结果批量生成定期摘要，供用户审核。

语义保证比具体的措辞更重要。“问我”在产品的任何界面都必须意味着阻塞式确认 —— 绝不能是“有时问我”或“除非我很赶时间才不问”。当契约发生偏离时，信任的蒸发速度会远超你的重建速度。自主性阶梯是那种能值回票价的框架级抽象，当用户从一个功能切换到另一个功能，并发现旋钮的工作方式符合预期时，它的价值就体现出来了。

这也迫使工程端进行一次有益的对话：每种模式对于工具调用、副作用和外部 API 写入到底意味着什么？即使 Agent 认为发送邮件是正确答案，在“给我看”模式下也不应静默发送。如果没有强制执行的阶梯，每个团队都会从头开始重新界定这些界限。

持久化是针对任务的，而非针对用户的

下一个错误是将自主性设为单一的全局偏好。那个希望 Agent 激进地整理收件箱的用户，可能也正是那个希望每笔发票审批都需要手动确认的用户。全局的“自主性 = 高”设置将这两个需求混为一谈，并在其中一个场景中犯下严重的错误。

设置应该按任务类型持久化，而不是按用户。单位应该是“针对收件箱整理”或“针对日历邀请”或“针对代码审查评论”，而不是“针对该用户的全局设置”。当用户调高某个任务的自主性时，这种更改不应静默应用到 Agent 执行的其他所有地方。

这对数据模型有实际的影响。用户的自主性偏好应该是从任务类型到模式的映射（Map），而不是一个单一字段。该映射需要为新任务类型提供合理的默认值 —— 通常是最谨慎的选项，因为不必要的操作成本远高于不必要的提示成本。此外，该映射还需要考虑版本控制，以便在你添加新模式或重命名模式时，现有用户不会丢失之前的设置。

一个更微妙的影响是：按任务持久化创建了一个数据集。用户群中汇总的自主性偏好会变成一张地图，显示哪些功能值得信任，哪些不值得。如果一个功能中有 80% 的用户将其自主性设置为“给我看”，那么该功能实际上并没有在任何地方自主运行 —— 这是一个比任何流失率仪表板都更响亮的质量信号。

撤销机制必须随着旋钮同步缩放

缺乏简易逆转机制的高自主性是一个陷阱。这也是用户在尝试一次后就禁用自主性功能最常见的原因。Agent 做了他们没预料到的事，后果很棘手，而他们不得不提交的支持工单使得节省的时间反而成了净亏损。

可逆性不能是生产环境出现问题后才补上去的亡羊补牢。它必须随着旋钮的调节而缩放 —— 自主性越高，撤销路径就必须越廉价、越显眼。一个有用的框架如下：

• 给我看模式根本不需要撤销。因为什么都没发生。
• 问我模式需要撤销，以防用户在没有阅读的情况下下意识地点击了批准。
• 做了再给我看模式需要在回执上提供一键撤销，且回执要出现在报告操作的同一位置。
• 做了再回头告诉我模式需要批量撤销，以及足够详尽的操作审核日志，以便在数百个决策中找到那一个。

框架层的承诺比看起来要难。它要求 Agent 调用的每个工具都能描述其逆操作 —— 发送邮件变成“存为草稿并撤回”，预约会议变成“取消并通知”，写入数据库变成 Agent 可以回滚的事务。无法干净逆转的工具在被赋予高自主权之前，应该要求用户明确知晓。不可退款的预订、已发布的推文、银行电汇 —— 在这些情况下，无论用户在其他任务中多么偏好，UI 都不应提供“做了再回头告诉我”的选项。诚实对待不可逆的操作是信任契约的一部分；假装一切皆可撤销，而在某些事情无法撤销时，这正是产品在一个糟糕的下午失去用户的原因。

一个富有成效的设计约束是：如果一个工具无法描述其逆操作，那么它的自主模式就不应高于“问我”。这一条规则就能防止大多数最糟糕的情况发生。

默认设置应当是学习得来的，而不是推测出来的

即使有了出色的开关设计，默认设置依然至关重要。大多数用户从不触碰设置，而默认设置则是沉默的大多数人的隐性答案。在全球范围内统一选择一个默认值，意味着至少对一半的用户群来说是选错的。

更好的方案是根据观察到的行为为每个用户选择默认值。当新用户第一次使用某项功能时，从谨慎的默认选项开始——“询问我”几乎总是冷启动时的正确选择。在进行了 10 次交互后，观察用户的回答方式：如果他们总是在不进行任何修改的情况下批准，那么可以轻轻地弹出一个一次性提示，询问他们是否想要切换到更高的自主性。如果他们经常修改或拒绝，则永远不要提供该选项。

这更接近于如果产品团队亲自了解每位用户，他们会如何设置默认值的方式。它还揭示了用户群体的分布情况——通常是三到五个集群，而不是调查所暗示的那种双峰分布——这种分布会告诉你哪些任务类型属于“默认自主”领域，而哪些永远不会。

这需要一种纪律：分析层必须跟踪用户在每种任务类型上最终落定的自主模式，而不仅仅是他们触碰过一次后就忘记的模式。在前 30 次交互后落定的模式，比用户第一次选择的模式是好得多的信号。这些数据也为下一轮的默认设置提供参考——一个健康的自主产品，其设置应该随着团队对用户群体分布的深入了解而随时间收紧，而不是为了取悦声音最大的群体而放宽。

为什么工程团队抗拒这种开关

反对暴露调节拨盘的理由通常听起来像是一个 UX 论点：“我们不应该把复杂性推给用户；我们应该做一个能够自动选择正确级别的智能产品。”这几乎总是错误的，而且是以一种值得点名的特定方式出错的。

选择正确的自主级别需要了解用户的风险承受能力、用户对这项特定任务的专业知识、用户此时此刻的时间限制，以及用户在今天与六个月前对系统的信任程度。智能体无法接触到这些信息。它可以推测，但这种推测是一种概率分布，其中包含了用户会讨厌的结果。用户可以免费获得关于这四个变量的完美信息。以简化为名隐藏开关，是要求智能体在一个用户只需点击一下即可解决的问题上进行艰难的推理。

这里还有一个诚实性的问题。一个自动选择自主级别的产品是在代表用户做产品决策，且没有告诉用户做了什么决定。如果智能体这次决定先询问，用户无法得知它询问是因为动作有风险，还是因为用户是新用户，或者是由于智能体的置信度较低。开关也是一种解释：它告诉用户他们处于什么模式，并允许他们表达异议。

通知频率是一个恰当的类比。没有哪个产品团队会认真争辩说他们应该替用户选择通知频率，因为暴露设置是“复杂性”。自主权也是同样形式的决策，且赌注更高。隐藏开关的团队正在做一个用户更有资格做的产品决策。

发布这种开关后会发生什么变化

最可衡量的变化是谨慎用户群体的留存率。那些原本会因为智能体动作太快而流失的用户，现在因为有了一个可用的低级别设置而留了下来。不太明显但更持久的影响是：通过观察分布随时间的变化，团队可以获得关于哪些功能已经准备好接受更高自主性、哪些还没有的信号。赢得信任的功能会看到用户调高拨盘。失去信任的功能——通常是因为质量退化——会在支持工单大量出现之前，先看到用户调低拨盘。

从这个意义上说，自主性开关既是一个 UX 功能，也是一个预警系统。它将每个用户已经在私下询问的问题——“我今天信任这个东西吗？”——外部化，并将答案转化为产品遥测数据。发布这一功能的团队不再会在会议上争论他们的智能体是否“准备好”进行自主操作。用户会告诉他们，一次一个开关。

在框架级别构建一次阶梯。按任务进行持久化。让撤销操作随拨盘同步扩展。学习默认设置。自主性开关不是一个高级用户功能——它是智能体产品与实际使用它的人们之间的接缝。