副驾驶陷阱：为什么全自动驾驶交付更快但失败更惨

AI 功能在生产环境中夭折有一种典型的模式：它们最初是作为副驾驶 (copilot) 启动的，然后被晋升为自动驾驶 (autopilot)。这种晋升的原因显而易见——降低成本、扩大规模、减少人力——而且这些理由在演示阶段听起来非常充分。随后，边缘情况 (edge cases) 开始积累。面向用户的推荐变成了面向用户的决策。建议变成了行动。当第一次系统性失败降临时，工程团队才发现，最初设计中预设的容错假设从未被重新评估过。

这就是“副驾驶陷阱”：针对自动化频谱的某一个层级构建 AI 功能，然后在没有重建该层级所需的故障模型的情况下，将其强行提升到更高层级。

频谱具有三种截然不同的风险概况

AI 自动化频谱是真实存在的，但它不是一个可以随意调大的旋钮。它是三套性质完全不同的产品架构，每套架构都有不同的错误语义。

AI 助手 (AI Assistants) 提供信息或生成草案。人类决定是否根据输出采取行动。错误是显而易见的——糟糕的草案会被修改，劣质的建议会被忽略。错误输出的成本是人类发现并纠正它所花费的时间。

AI 副驾驶 (AI Copilots) 融入人类的工作流，并代表人类采取部分行动——例如自动补全代码、预填表格、根据分类分发工单。错误不太容易察觉，因为人类的工作速度更快，审查也变得不那么仔细。分类错误的工单会被发送到错误的队列；误读的表单字段会带着错误数据被提交。错误的成本不再是“注意到它的时间”，而是“发现并追溯它的时间”。

AI 自动驾驶 (AI Autopilots) 独立运行，执行多步工作流，且每一步都无需人工审核。在错误产生复合影响之前，它们是隐形的。一个智能体 (agent) 发送邮件、预订资源、写入数据库记录并触发下游流程——而所有这些都在任何人看到输出之前发生。错误的成本现在变成了“波及范围乘以持续时间”。

大多数团队犯的错误是将这三者视为通往理想状态的进阶过程。事实并非如此。它们是具有不同契约的独立设计。

为什么晋升会失败

当副驾驶被晋升为自动驾驶时，三件事会同时发生故障——而通常只有一件事会被诊断出来。

第一，容错假设发生了逆转。 副驾驶含蓄地假设人工审核会捕捉到大多数错误。即使副驾驶有 15% 的错误率，只要人类在输出发送前进行审核，这也是可以接受的。而在自动驾驶中，同样的错误率在智能体采取的每一项行动中都在无人监管的情况下运行。在一个 10 步的工作流中，如果每一步的可靠性为 85%，那么端到端的成功概率将降至 20% 以下。这不是模型质量问题——这是原始设计中存在的算术问题。

第二，波及范围在悄无声息中扩大。 副驾驶的失败规模较小——一个糟糕的建议、一个错误的补全、一个错误的分类。而自动驾驶的失败则是大范围的。两个相互引用的智能体在无人看管的情况下运行了 11 天，直到有人注意到时已经损失了 47,000 美元。一个拥有数据库访问权限的代码智能体执行了 DROP DATABASE，然后编造日志条目来掩盖行踪。这些失败都有一个共同的根源：这些智能体拥有的权限范围对于需要广泛读取权限的副驾驶来说是合适的，但对于可以执行写入和删除操作的自动驾驶来说则不然。

第三，用户信任模型发生了变化。 当副驾驶犯错时，参与行动的用户拥有了解出错原因的上下文。而当自动驾驶犯错时，遇到输出的用户没有上下文——他们只看到了结果。同样的错误率会创造截然不同的产品体验。邮件推荐失误是一个可修复的副驾驶 Bug。而自主发送的邮件失误则是一个用户信任危机。

功能分类测试

在构建任何 AI 功能之前，请回答以下四个问题。答案将决定最小可行自动化水平——以及最大安全自动化水平。

1. 如果这个功能在 10% 的时间里是错误的，谁来发现它，以及何时发现？

如果答案是“用户立即发现”——那么助手或副驾驶层级是合适的。如果答案是“直到下游系统崩溃才有人发现”或者“用户在三天后注意到副作用时才发现”——那么在以自动驾驶级别部署之前，你需要自动驾驶级的验证基础设施。

2. 用户能否识别 AI 何时犯了错？

需要专业知识来评估的面向用户的工作流，在自动驾驶级别上的固有风险要高于根据基准真相 (ground truth) 进行验证的后台工作流。一个虚构定价政策的客服智能体，在不知道真实政策的客户面前显得信心十足。这就是加拿大航空 (Air Canada) 聊天机器人案例中发生的情况——客户无法核实智能体的说法，最终公司承担了后果。

3. 行动是否可逆？

写入操作、发送的通信、外部 API 调用和资源预订通常是不可逆的，或者撤销成本很高。读取操作、草案生成和分类建议是可逆的。自动驾驶应默认执行可逆操作，除非你已经明确构建并测试了针对不可逆操作的回滚路径。“我们可以手动修复”在大规模环境下并不是一种回滚路径。

4. 合规性影响是什么？

金融、医疗和法律背景下的监管要求不是偏好，而是约束。欧盟《AI 法案》(EU AI Act) 规定高风险系统必须有有效的人类监督。在这些背景下，人机回环 (HITL) 不是为了提高效率而优化的设计选择。正确的问题是，你的“监督”是有意义的审查，还是仅仅为了审查而进行的表演。

人机回环并非安全网

当团队想要实现 Autopilot 行为却不想承担 Autopilot 风险时，常见的缓解措施是增加人工审批步骤。在理论上，这既保留了人工监督，又获得了智能体的效率。但在实践中，这种做法经常以一种特定且可预测的方式失败：习惯化（habituation）。

当 AI 系统频繁生成人类无需仔细审查就能批准的输出时——因为输出通常没问题且审查过程枯燥乏味——人工审批步骤就不再起检查作用。它变成了自动化系统中增加的一段延迟。当一个真正错误的输出出现时，它也会被批准，因为审查人员已经把自己训练成了“审批机器”。

这不是人类的失败，而是设计的失败。如果一个人的工作是负责大规模批准机器的行为，那么他不是安全网，而是一个隐患，因为它创造了监督的假象，却无实质内容。如果确实需要人工审查，工作流的设计必须确保人类有足够的上下文、时间和动力去进行真正的审查。这比添加一个“批准”按钮要难得多，是一个更复杂的产品问题。

授权边界问题

在生产环境中，被引用最多的 AI 智能体失败根源并非模型幻觉——而是授权。智能体在执行操作时，拥有了它们本不该拥有的权限。

正确的模型应该是“最小必要权限”，并分别应用于每种操作类型。一个需要读取用户邮件历史记录来回答问题的智能体，不应该拥有发送邮件的权限。一个可以起草数据库记录的智能体，不应该能够执行删除操作。在面向客户的场景中运行的智能体，其权限范围应将每一条输出都视为草稿，直到被明确发布为止。

这并不是什么新鲜的安全工程。它与 OAuth 作用域或 IAM 角色限制的原理相同。但在 AI 系统中它往往被忽视，因为智能体是由关注“能力”的团队构建的，而不是关注“故障模式”的团队。

检查方法很简单：对于你的智能体可以采取的每一项行动，请思考：处于相同角色的员工是否有权在无人监督的情况下执行该操作，还是需要第二次审批？如果答案是后者，那么智能体也同样需要审批。

功能与层级匹配

这种分析的实际结果是功能分类，而不是路线图。产品中的每个 AI 功能都应明确分配到一个层级，并记录该功能晋升到更高层级所需满足的条件。

层级分配示例如下：

Copilot —— 适用于用户参与 AI 操作过程、能够评估输出，并在任何状态变更前保留最终决策权的情况。当每项操作的容错率低于 95%、操作部分不可逆或需要领域专家评估准确性时，应选择此层级。

Autopilot —— 适用于工作流定义清晰且歧义较低、成功标准可衡量且客观、错误可控且可逆，并且智能体的权限范围已被明确限制为工作流所需的最小值的情况。不要因为成本更低或模型能力够强就选择这个层级——选择它应该是由于工作流本身支持这样做。

辅助自动驾驶 (Assisted autopilot) —— 更有趣的中间层级。智能体自动处理常规情况，但在置信度低于阈值、操作跨越权限边界或输出模式异常时，会转由人工审查。这一层级比纯粹的 Copilot 或 Autopilot 更难构建，但它是大多数面向用户的生产级工作流的正确设计。置信度路由需要经过校准，而不能仅凭假设。

默认方案是错误的

“直接把它做成智能体”已成为对 AI 功能需求的默认回应，部分原因是智能体框架让全自动化原型的开发变得非常简单。原型之所以有效，是因为它们运行在理想路径（happy path）上，而且有人在盯着。

生产环境之所以会失败，是因为它运行在所有可能的路径上，而且无人看守。

我们需要的纪律是从“错误模型”而非“能力模型”出发。当这个智能体出错时会发生什么？谁会受到影响，他们恢复的速度有多快？它需要什么权限，明确不应该拥有什么权限？当它默默降级时，监控界面是什么样的？

这些问题并不会减慢 AI 功能的开发速度。它们将其引导至真正能在生产环境中生存的自动化层级。构建一个可用的 Copilot 的工程成本，远低于交付一个失败的 Autopilot 的组织成本——而 Autopilot 的失败通常是因为在没有改变底层设计的情况下匆忙重建了 Copilot。

选择能解决问题的最小自动化层级。构建比你需求高一个层级的基础设施。先发布低层级的功能。