复盘智能体事故：Gartner 40%失败率背后的三种模式

Gartner在2026年5月预测，到次年，40%的企业将取消自主智能体项目。"到2027年，40%的企业将降级或停用自主AI智能体，原因是在生产事故发生后才暴露的治理缺口。"

我们需要关注的关键信息在句子的后半段：缺口只有到事故发生后才被发现。

这不是关于模型质量的预测，而是关于基础设施短板的预测——这也是企业数据团队内部状况的真实写照。

智能体的失败方式不同于确定性系统

很多次AI智能体事故后会进行复盘。数据团队聚集在一起搞清楚发生了什么，结果发现……往往搞不清楚。

团队知道出了问题，因为下游测试失败了、某个数字不对、或者收到了一张意外账单。有时问题几乎立刻显现，有时要过几天甚至几周才浮出水面。

如果是人工编写的变更，后续追问清晰明了——工程师会用堆栈追踪、git blame或查询历史过滤来回答。但对于智能体的工作，每一种追问都查无结果。

企业事故响应体系是围绕快速且明确地失败的软件成长起来的。服务崩溃会抛异常，任务失败会触发告警，部署出问题会回滚。企业拥有的几乎所有治理控制都是为捕获这类失败而设计的。

但智能体的失败方式不同。

一个缺乏上下文的智能体不会按其不确定性程度减速；它会用看似合理的推理填补空白，然后以机器速度继续推进。输出能编译、能执行、返回的东西看起来合理——这意味着失败在发生时不会产生任何信号。

智能体时代的治理缺口保持不可见，直到事故将它们暴露——这正是Gartner所描述的时间序列。

在过往事故复盘中，无法回答的问题聚集为三种模式。每一种都是早在暴露它的事故之前就存在的基础设施短板。

模式一：权限是继承的，而非设计的

复盘问的第一个问题是：智能体接触了什么？

回答它本应只是一条针对访问日志的查询、按主体过滤即可；但它变成了一项清点工程，因为智能体从未拥有自己的主体身份 。

在大多数部署中，智能体的行动范围根本没有被设计过。智能体继承了启动它的工程师的凭证，或者通过一个已被多个其他系统使用的共享密钥进行认证。

2026年Gravitee对900多位高管和技术从业者的一项调查发现，46%的团队仍然依赖共享API密钥进行智能体认证，而非为每个智能体发放可独立限定范围、轮换和撤销的专用服务身份。

Gravitee是一家专注于事件原生（Event-Native）API管理的开源平台公司，总部位于美国。其核心定位是帮助企业设计、部署、管理和保护同步与异步API的完整生命周期。

团队确实会写限制条件，但他们写在了提示词里。像"不要修改生产表"这样的指令是建议性的，随着长任务中上下文的增长，其影响力会衰减。

提示词指令不能替代IAM（身份与访问管理）策略——提示词是请求智能体遵守规矩，而策略是让违规变得不可能。

公开记录已经展示了这样做的后果。一个AI编码智能体在Replit上于代码冻结期间删除了一个生产数据库，尽管有明确指示要求不得动它；一个数据团队收到了一张来自单次AI生成查询的5000美元账单，而其资源监控器从未捕获到。

纠偏方法是一个被大多数部署忽略的区分：智能体的自主性和智能体的访问权限是两个不同的属性，需要分别治理。

智能体被允许接触什么，应在权限层执行（在那里违规是不可能的），而非在提示词层（在那里违规仅仅是被劝阻的）。

模式二：所有者——组织架构图无法产出的东西

第二个问题是：谁拥有这个智能体，谁为其行为负责？

随之而来的沉默本身就是诊断结果。

一个生产环境中的智能体位于多个团队的交汇点。平台团队配置了它的访问权限，业务团队编写了它的指令，供应商提供了运行框架，每一方都合理地认为其他某一方对其行为负责。

一个有着同样岗位描述的人类新员工，不会在没有明确上级的情况下通过入职流程。

身份层让这个问题雪上加霜。同一项Gravitee调查发现，只有22%的团队将AI智能体视为拥有自己凭证的独立身份实体。

当智能体通过共享密钥或借用登录凭证行动时，审计追踪将其行为归属于某个人（通常与智能体的部署无关）或一个被十几个系统共享的服务账号。归因变得在结构上不可能，而不可归因的行为产生不可归属的事故。

这里的纠偏既是组织性的，也是技术性的：每个智能体需要自己的身份、限定于其任务的凭证，以及一个在智能体进入生产环境之前就被书面指定的人类负责人。

十年前企业在服务账号上经历过同样的成熟过程；智能体压缩了这一时间线——因为它们行动更频繁、更具主动性。

模式三：证据从未被捕获

第三个问题是：智能体到底逐步做了什么？

这是复盘卡壳最久的地方。

事故响应假设日志能解释意图。智能体留下的是输出：四百条执行的查询、一组合并的变更、一张仓库账单。记录显示运行了什么，但不显示智能体在行动时知道什么、检查了什么、跳过了什么，以及为什么选择了它所走的路径。

长时间运行的任务扩大了这一缺口。智能体系统随着会话增长会压缩其工作上下文，而这种压缩通常丢弃了取证复盘所需的中间推理。

证据不仅未被索引——它在任务中途就被丢弃了，在任何人知道事故会使其变得有价值之前。

这种模式解释了Gartner选择的那个特定措辞。一个无法重建智能体行为的团队无法缩小范围或修复具体缺口，因为复盘从未建立哪个缺口失效了。唯一可用的应对是全面降低智能体的自主性，或直接关停它。

"降级"正是当没有证据可供修复时，修复长什么样。

纠偏方法是将决策追踪（decision traces） 视为一等工件。对于每一个有后果的行动，系统应记录：智能体检索了什么上下文、运行了什么验证、它有多大的置信度、以及是否有人的批准。

该记录必须在行动发生时生成，因为它事后无法恢复，并且应以适合分析的形式呈现。

三个模式之下的同一个根因

这三种模式看起来各不相同，但源自同一个根。

Gartner高级总监分析师Shiva Varma在该预测发布时点明了它：

"企业将AI智能体治理视为二元的——要么完全锁死，要么完全信任——这正是失败的根本原因。"

一个被完全锁死的智能体不会产生事故，也不会产生价值，于是压力积累到翻转开关。一个被完全信任的智能体会产生价值——直到它产生一个范围无法控制、所有者无法捕获、追踪无法解释的事故。

替代方案是分级自主性（graduated autonomy） 。Gartner的框架有四个层级：

• 观察智能体（ agents that observe ）

• 建议智能体（ agents that advise ）

• 经批准后行动智能体（ agents that act with approval ）

• 在护栏内自主行动智能体（ agents that act autonomously within guardrails ）

每个层级需要逐步加重的基础设施，智能体通过在下一层级积累实绩来赢得晋升。

分级只在每一层的检查是可信的情况下才有效——这指向一条坚定原则：

确定性问题应该得到确定性答案。

一张表是否存在、一个连接是否匹配其键、一条查询是否在支出限额内——这些都是有可验证答案的问题，应该由不能产生幻觉的系统来检查。模型的判断应该属于需要判断的地方：模糊的决策，而非可验证的决策。

Gartner的40%是一个普遍现状，但你肯定不希望成为其中一员

企业正将智能体推进到更高风险的工作流中，速度快于其治理的成熟速度。是的，大约40%的企业可能会以昂贵的方式发现缺口。

其余的将已经先建好了那些不那么光鲜的部分：被强制执行的范围、被明确命名的负责人、以及能在事故中幸存的追踪记录。

这项工作改变了数据和平台工程师每天的工作内容，它标志着这个学科一个新时代的开始。

这份工作正在从执行工作转向智能体数据工程——以及治理执行工作的系统：决定智能体可以接触什么、谁为其负责、以及它们留下什么证据。

拥抱这一转变的团队将运行他们能在事故复盘中站得住脚的智能体。

跳过它的团队将成为Gartner 40%的不幸者——并将在一场每个问题都有令人不安答案的会议中，做出降级智能体的决定。