信任天花板:产品团队忽视的自主性变量
每个 Agent 功能都有一个自主性上限,一旦超过这个上限,用户就会开始检查工作、进行干预,或者彻底放弃该功能。这个上限并不是你模型的属性,而是由你的用户、领域以及出错成本决定的。它不会因为发布演示稿说它该移动就移动。大多数团队都是通过惨痛的教训才发现这个天花板的:发布的功能被设计为完全自主,但采用率却停滞在“Agent 建议,人类批准”的阶段,指标把责任推给模型,而接下来的一个季度则花在调整一个从未成为瓶颈的旋钮上。
这个上限的形状在各种产品中都足够一致,以至于它值得拥有一个名字。Anthropic 自己关于 Claude Code 的使用数据显示,新用户在约 20% 的时间内使用完全自动批准,只有在经过大约 750 次会话后,这一比例才会攀升至 40% 以上。PwC 2025 年对 300 名高管的调查发现,79% 的公司正在使用 AI Agent,但大多数生产部署都运行在“协作伙伴”或“顾问”级别——即模型提议,人类决策——而不是营销所暗示的全自主层级。这些数字背后的故事并不是用户胆小,而是信任是根据可挽回错误的成本进行校准的,而你 的产品几乎肯定没有以用户需要的方式让他们看到、撤销或限制这些成本。
本文将探讨这个变量——自主性天花板——以及当你将其视为一等公民的产品指标而非部署后的意外时,会发生什么变化。
天花板是真实的,且是分层的
第一个失败模式是假设天花板是一个单一的数字。事实并非如此。它是分布在用户、任务和距上次出错时间上的。一个有用的思维模型是实践者文章中出现的五级阶梯:用户可以是观察者(Agent 叙述全自主运行过程)、审批者(Agent 提议,用户点击通过)、顾问(被问及时 Agent 回答)、协作伙伴(Agent 与用户共用键盘)或操作员(用户驱动,Agent 辅助)。大多数生产环境中的 AI 功能都处于协作伙伴到审批者之间(第 2 级到第 3 级),而那些作为观察者发布的功能,则是那些悄无声息失去用户的功能。
任何特定用户在特定任务上处于阶梯的哪个位置,取决于工程团队几乎从不测量的因素组合:
- 行为的可恢复性。在点击发送之前,起草一条 Slack 消息是可逆的;发送电子邮件则不然。用户会给予可逆行为更多的自主权,而对后果持久的行为则给予较少的自主权。同一个模型性能在
compose_draft上的天花板与在send_message上不同,即使模型是完全一样的。 - 领域利害关系。Stanford HAI 关于信任校准的研究发现,用户在休闲语境下会慷慨地原谅错误,但在专业或安全关键领域则会严厉惩罚。一个幻觉出函数名的编程助手只是 30 秒的烦恼;一个幻觉出退款金额的账单助手则是 30 天的审计。
- 最近一次失败的发生时间。信任不会平滑衰减。虽然在最初接触时“算法欣赏”占主导地位,但一次显著的错误就可能产生强烈的厌恶感,需要多次成功的运行才能修复。昨天说“让它跑吧”的用户,今天会说“先让我看看差异(diff)”,而你的产品并没有记忆去理解原因。
- 用户专业知识。这一点违背直觉。领域专家在第一天往往对 Agent 的信任感较低——他们能看到破绽——但由于他们能定位出问题所在,他们的信任度是逐渐下降的。新手在第一天更信任,但当错误最终发生时,他们无法诊断,无法界定波及范围,信任崩塌是断崖式的。专家的怀疑是一个低通滤波器;新手的信心则是一个带有悬崖的阶跃函数。
如果你正在构建一个单一模式的“批准/拒绝”关卡,你就是将一个连续变量量化为 1 位(bit),并将同样的关卡提供给需要四种不同方案的人群。
干预率是你缺失的 SLI
当一个功能运行健康时,模型的质量并不是要观察的指标,用户对模型的行为才是。以下是三个信号,大致按实用程度排序:
- 干预率 (Intervention rate) —— 用户原封不动接受、编辑、从头重写或彻底拒绝 Agent 输出的比例。将其视为服务水平指标(SLI),而非虚荣指标。人机协同系 统的行业指南通常将 10–15% 的升级目标作为可持续区间;比率过高表示存在天花板问题,过低则可能预示着自动化偏差(automation bias)。
- 编辑距离分布 (Edit-distance distribution) —— 用户如何干预比他们是否干预更有启发性。大量的小修小补(“改变语气,更换日期”)告诉你模型的输出在结构上已经足够接近,可以挽救。如果分布呈现双峰状,即用户要么逐字接受,要么从头重写,这告诉你模型产生的“接近未命中”的修复成本比重做还要高,你面临的问题比准确率基准测试显示的更严重。
- 会话内重新提示率 (Re-prompt rate within session) —— 用户在使用微调指令后立即重新运行 Agent 的频率。这捕捉到了用户虽然不编辑你的输出,但也不信任它,因此不断重新投骰子的失败模式。这是流失率的前导指标。
这些并不难测量。大多数团队不跟踪它们的原因是,它们需要在产品代码中定义“干预”,这意味着在获得数据之前就要决定关卡长什么样,而这正是为了逃避“自主性滑块”而陷入的先有鸡还是先有蛋的陷阱。
自主权滑块,以及为什么三级胜过一级
Andrej Karpathy 提出的“自主权滑块”框架——一种让用户明确控制智能体权限范围的 UI 控件——之所以广为流传,是因为它将一个先前隐含的变量显性化了。Cursor 将其表现为 tab → inline → chat → agent。Perplexity 将其表现为 search → research → deep research。Claude Code 将其表现为针对每个工具的审批门槛。这些模式的本质是相同的:将相同的底层能力以多个自主权等级进行销售,并让用户自行选择。
其战略价值并不在于用户喜欢滑块,而在于提供三个等级是对你自己预设天花板的一次低成本 A/B 测试。如果 70% 的使用量集中在最低等级,说明你的模型还没准备好,或者你的领域本身就有此要求;无论哪种情况,你拥有的是证据而非观点。如果随着时间的推移,同一批用户的使用习惯向上迁移,说明你的产品拥有一个信任构建闭环。如果使用习惯没有迁移,说明你遇到了瓶颈,你可以决定是投入资源提高天花板,还是围绕现有天花板进行设计——这是每个 AI 产品负责人最终都必须回答的战略问题。
与滑块相辅相成的是一种战术模式:先展示计划,再执行。智能体发出意图预览——即它打算采取的行动简表——用户在任何不可逆的调用触发之前进行批准、编辑或终止。关于这种模式,有三点事实从外部看并不明显:
- 它压缩了信任闭环。用户在承担出错代价之前就能看到智能体的推理过程,并通过低成本的预览而非高昂的事故来了解智能体的故障模式。
- 它使干预率变得可衡量。对计划的修改是可以用于训练的信号;而对成品输出的纠正往往被埋没在客服工单中。
- 它实际上并不会降低大多数工作流的速度。信任计划的用户会一键接受。不信任的用户反正也会重新生成输出。
推论是,“执行前预览”并不是针对不可靠模型的临时支架。它是一种结构,能将自主权从一个二元选项转变为一个可调变量。
围绕天花板设计,而非假装它不存在
一旦你接受了天花板的存在且它是波动的,你采取的产品行动将不同于典型的智能体路线图。
在天花板处与用户会合,而非超越它。 如果用户群体习惯于 Level 2 的自主权,而你交付的功能处于 Level 4,那么无论模型有多好,其采用率都会非常糟糕,因为典型用户不会让它运行。发布相同的功能时,提供一个显性的低等级入口,监测迁移情况,并让使用数据告诉你何时提高默认等级。
默认采用“编辑而非替换”模式。 当智能体有信心时,将其输出呈现为可编辑的工件,并高亮显示智能体贡献的差异(diff),而不是将其作为既成事实。提供可编辑界面的成本很小;而“AI 刚刚重写了我的邮件,但我不知道改了什么”的代价很大,并且会隐形地累积成用户流失。
明确撤销预算。 对于任何行动具有撤回窗口的工具——如 Gmail 的撤回发送、Slack 的编辑窗口、Stripe 的预授权退款——应将该窗口作为智能体承诺的一部分展示给用户。“我可以在 30 秒内撤回”与“我会发送这个”是截然不同的产品。用户授予的自主权与恢复窗口的大小呈线性比例。
追踪“首次错误存续率”。 对于 AI 功能的采用,最具预测性的留存指标是:用户在观察到智能体的第一次错误后,是否会在接下来的两周内继续使用该功能。该留存率高的功能拥有健康的信任修复界面——透明的推理、简便的纠正、低廉的错误成本 。留存率崩塌的功能则是那些智能体黑箱化、错误不可恢复或用户无法定位问题所在的功能。在优化预训练模型之前,先优化错误发生后的用户体验。
将模型升级与自主权升级解耦。 新模型的出现通常会诱使开发者提高默认自主权,因为评估指标(evals)有所提升。请抵制这种诱惑。用户的校准是基于前一个模型的故障模式建立的;在更换模型时提高同一界面的自主权,会将两种变化混在一起,当采用率发生变动时,你将无法区分其影响。在旧的自主权等级下发布新模型,让用户自行选择放宽权限。
你再也无法规避的战略问题
每个构建智能体的团队最终都会面临一个分叉口:是投资于提高天花板,还是投资于根据现有天花板来塑造产品。提高天花板意味着更好的模型、更强的护栏、更清晰的解释、更长周期的评估、错误恢复机制,以及将智能体失败转化为信任构建时刻(而非信任瓦解时刻)的长期组织工作。围绕天花板进行塑造则意味着接受你的典型用户在可预见的未来将在 Level 2 或 Level 3 运行,并构建一个真正擅长“建议并批准”的产品,而不是假装它是通往完全自主的临时站。
交付出色的团队会按顺序兼顾两者。他们针对当前的天花板进行设计,将干预率作为服务水平指标(SLI)进行监测,将自主权暴露为滑块以便用户自我分层,然后针对那些限制了高价值用户群天花板的故障模式进行专项投资。交付糟糕的团队则跳过监测,直接按路线图承诺的自主权等级 发布,在采用率停滞时归咎于模型,然后发布一个带有更聪明模型的新版本,却因为同样的原因再次触碰天花板。
请像对待延迟或错误率一样对待自主权天花板:它是一个真实、可衡量、有负责人、显示在仪表盘上并被刻意改进的数字。做到这一点的团队不需要 PPT 来解释为什么他们的 AI 功能有效。而做不到的团队将继续把产品问题误认为模型问题,并不断针对它发布新模型。
- https://www.swarmia.com/blog/five-levels-ai-agent-autonomy/
- https://www.uxmatters.com/mt/archives/2025/12/designing-for-autonomy-ux-principles-for-agentic-ai.php
- https://www.anthropic.com/research/measuring-agent-autonomy
- https://andrewships.substack.com/p/autonomy-sliders
- https://galileo.ai/blog/human-in-the-loop-agent-oversight
- https://cloud.google.com/transform/ai-grew-up-and-got-a-job-lessons-from-2025-on-agents-and-trust
- https://fly.io/blog/trust-calibration-for-ai-software-builders/
- https://hatchworks.com/blog/ai-agents/agent-ux-patterns/
- https://www.smashingmagazine.com/2026/02/designing-agentic-ai-practical-ux-patterns/
- https://pmc.ncbi.nlm.nih.gov/articles/PMC12561693/
- https://www.cio.com/article/4087765/agentic-ai-has-big-trust-issues
- https://onereach.ai/blog/agentic-ai-adoption-rates-roi-market-trends/
