AI 功能在生产环境中夭折有一种典型的模式：它们最初是作为副驾驶 (copilot) 启动的，然后被晋升为自动驾驶 (autopilot)。这种晋升的原因显而易见——降低成本、扩大规模、减少人力——而且这些理由在演示阶段听起来非常充分。随后，边缘情况 (edge cases) 开始积累。面向用户的推荐变成了面向用户的决策。建议变成了行动。当第一次系统性失败降临时，工程团队才发现，最初设计中预设的容错假设从未被重新评估过。
这就是“副驾驶陷阱”：针对自动化频谱的某一个层级构建 AI 功能，然后在没有重建该层级所需的故障模型的情况下，将其强行提升到更高层级。
每个 Agent 功能都有一个自主性上限，一旦超过这个上限，用户就会开始检查工作、进行干预，或者彻底放弃该功能。这个上限并不是你模型的属性，而是由你的用户、领域以及出错成本决定的。它不会因为发布演示稿说它该移动就移动。大多数团队都是通过惨痛的教训才发现这个天花板的：发布的功能被设计为完全自主，但采用率却停滞在“Agent 建议，人类批准”的阶段，指标把责任推给模型，而接下来的一个季度则花在调整一个从未成为瓶颈的旋钮上。
这个上限的形状在各种产品中都足够一致，以至于它值得拥有一个名字。Anthropic 自己关于 Claude Code 的使用数据显示，新用户在约 20% 的时间内使用完全自动批准，只有在经过大约 750 次会话后，这一比例才会攀升至 40% 以上。PwC 2025 年对 300 名高管的调查发现，79% 的公司正在使用 AI Agent，但大多数生产部署都运行在“协作伙伴”或“顾问”级别——即模型提议，人类决策——而不是营销所暗示的全自主层级。这些数字背后的故事并不是用户胆小，而是信任是根据可挽回错误的成本进行校准的，而你的产品几乎肯定没有以用户需要的方式让他们看到、撤销或限制这些成本。
你的生产系统中有一个智能体删除了 10,000 条数据库记录。这次删除符合有效的业务逻辑 —— 这些记录被正确标记了。但三个月后，监管机构提出了一个简单的问题：谁授权了这个操作，智能体是根据什么依据做出决定的？你打开日志，找到了 SQL 语句，找到了时间戳，但什么都找不到了。
这就是决策溯源问题。你可以证明你的智能体采取了行动；但你无法证明它为什么这样做，或者这个行动是否曾经得到了一个真正理解自己在批准什么的人的授权。随着自主智能体开始执行跨越数小时、数十次工具调用、且决策具有真实世界影响的工作流，"我们有日志"与"我们有问责机制"之间的鸿沟已经在运营上变得危险。
大多数代理 (Agent) 故障并非以“爆炸”这种显式方式发生。它们往往是悄无声息的。代理删除了错误的数据记录，给客户发送了过时的信息，或者重复执行了一个已经成功的支付操作 —— 而你直到两天后收到支持工单 (Support Ticket) 时才会察觉。其根本原因几乎如出一辙：代理拥有对生产系统的写入权限，但在“决定行动”与“执行行动”之间缺乏检查点。
审批门禁 (Approval Gates) 是应对这一问题的工程化方案。这里指的不是那种没人看的合规复选框（即弹窗），而是真正的架构中断点 —— 它们能够暂停代理的执行，序列化状态，等待人工决策，然后干净利落地恢复运行。如果设计得当，它们能让你部署具有真实自主权的代理，而无需在每一次推理调用中都拿生产数据去冒险。
在 AI 的大部分历史中，治理问题从根本上说是关于输出的：模型说了错误、冒犯或机密的内容。这固然糟糕，但它是受控的。影响范围仅限于读取该输出的人。
智能体 AI（Agentic AI）完全打破了这一假设。当一个智能体能够调用 API、写入数据库、发送电子邮件并生成子智能体时，问题就不再仅仅是“它说了什么？”，而是“它做了什么、针对哪些系统、代表谁做的，以及我们能否撤销它？”近 70% 的企业已经在生产环境中运行智能体，但其中大多数智能体在传统的身份与访问管理（IAM）控制之外运行，使其处于不可见、权限过高且未经审计的状态。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
