3 篇博文 含有标签「autonomy」

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

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

当今大多数智能体 (agent) 产品都达成了一个简单的契约：模型决定做什么，用户点击“批准”。对于低风险的消费者聊天场景 —— 预订餐厅、摘要收件箱、起草非正式回复 —— 这确实是正确的形式。但对于法律起草、财务咨询、医疗分诊和事件响应来说，这却是灾难性的错误。在这些场景中，用户承担着模型永远无法承担的问责，而且错误 计划 的成本远高于任何单个 步骤 的成本。

反向智能体翻转了这种极性。用户将计划构思为一系列命名的、可重新排序的步骤。模型按需执行每个步骤 —— 拥有完整的上下文、工具访问权限和推理能力 —— 但绝不决定下一步该做什么。模型可以提供建议，但建议仅供参考，不具有自主性。这并不是一个更糟糕的自主智能体；它是一个完全不同的产品，虽然其成本和延迟表现绝对更差，但信任度绝对更高，专门针对那些否则会完全拒绝采用自主版本的用户。

团队一直在犯的错误是将“自主性”视为默认的努力方向。它其实是一个你在每个界面上选择的 UX 维度。如果搞错了极性，你交付的功能就会被那些承担最高风险的用户悄悄拒绝使用。

每个 Agent 功能都有一个自主性上限，一旦超过这个上限，用户就会开始检查工作、进行干预，或者彻底放弃该功能。这个上限并不是你模型的属性，而是由你的用户、领域以及出错成本决定的。它不会因为发布演示稿说它该移动就移动。大多数团队都是通过惨痛的教训才发现这个天花板的：发布的功能被设计为完全自主，但采用率却停滞在“Agent 建议，人类批准”的阶段，指标把责任推给模型，而接下来的一个季度则花在调整一个从未成为瓶颈的旋钮上。

这个上限的形状在各种产品中都足够一致，以至于它值得拥有一个名字。Anthropic 自己关于 Claude Code 的使用数据显示，新用户在约 20% 的时间内使用完全自动批准，只有在经过大约 750 次会话后，这一比例才会攀升至 40% 以上。PwC 2025 年对 300 名高管的调查发现，79% 的公司正在使用 AI Agent，但大多数生产部署都运行在“协作伙伴”或“顾问”级别——即模型提议，人类决策——而不是营销所暗示的全自主层级。这些数字背后的故事并不是用户胆小，而是信任是根据可挽回错误的成本进行校准的，而你的产品几乎肯定没有以用户需要的方式让他们看到、撤销或限制这些成本。