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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

加载中…