40%企业要砍掉AI智能体，问题出在哪？

2026年5月，Gartner给出一个预测：到2027年，40%的企业会缩减或关停自主AI智能体。原因不是模型不够聪明，而是治理缺口往往要等到生产事故之后才暴露出来。

更早一年，Gartner已经预判超过40%的智能体项目会在2027年前被取消，并点出三个理由：成本攀升、业务价值不清、风险控制不足。这三个理由，恰好对应一套智能体上线前必须具备的三项属性。

先看一个基本概念：智能体是跑在“套壳”里的模型。编排循环负责规划、调用工具、检查结果，模型、指令、工具与MCP服务器、记忆与检索上下文、子智能体、带审批的护栏，全都属于这个套壳。每一部分都可能以自己的方式出错——模型给出自信但错误的答案，工具静默失败，检索返回错误的条款，智能体之间的交接丢失，审批被跳过。用户只在最后看到一句回复，而这些故障大多不会出现在那句话里。

三种典型的生产故障

设想一个回答保险覆盖问题、处理理赔的助手。第一个场景：客户问爆管是否在保障范围内，循环让模型去查条款，检索返回了高级版条款，但循环从未调用CRM工具确认这位客户属于哪个档位。模型据此写出一句流畅的回答：“可以，最高5万欧元。”而客户实际是基础档，上限5000欧元。没有任何工具报错，只是“按客户自身档位回答”这个要求从未被检查。

第二个场景：前半段做对了，循环查到正确档位，随后理赔工具超时。循环把超时当成无事发生交给模型，模型写出一份带编造参考号的确认函。客户等着永远不会到来的赔付。其实套壳里只要一条规则就能拦住：没有理赔系统返回的ID，不得确认。

第三个场景：答案正确，所有质量测试都通过。但助手逐条读取条款，一个问题跑约40轮，每轮结果都追加进上下文，于是每轮都比上一轮更贵。一次带过滤的检索本可以搞定。只有单次请求成本和调用链能暴露问题，而套壳里没有设置步数上限或预算。

这不是假设

2025年7月，Replit的一个AI编程智能体在代码冻结期间删除了生产数据库，并最初声称无法回滚。另有一个广泛流传的案例：两个智能体循环了11天，花掉约4.7万美元。后者没有公布公司名或事后复盘，但这类模式是真实存在的。

宏观数据指向同一方向。OECD的AI事故与危害监测在2022年11月——ChatGPT发布那个月——记录了105起上报事故与危害，到2026年9月增至702起。相对全部AI新闻而言，事故率其实相当稳定；生产环境里的AI变多，事故的绝对数量自然变多。

三项属性，对应三个理由

可审计：从需求到发布留下完整痕迹。需求来自产品团队、核保或理赔等业务专家、监管方和客户，写成文档并做版本管理。测试集与每条需求挂钩，每个智能体版本都跑这些测试，发布决定基于通过率并有人签字。每一步都进审计日志：谁测了哪个版本、结果如何、谁批准了发布。这份日志是发布评审、审计甚至法庭上的证据，也能回答“两周前是不是更好”——按需求对比各版本的通过率即可。

可观测：看见表层之下的过程。测试通过只检查了输出，智能体走过的路径仍然隐藏。理赔例子里，最终消息听起来毫无问题，只有调用链能显示那次超时。可观测意味着追踪每一步、每次工具调用和交接，最好采用OpenTelemetry这一开放标准；评估调用链而不只是最终答案；让智能体之间的消息可见；在行为偏离测试结果时告警，尽早发现循环和重试风暴。

可预算：知道花多少钱，并能安全地削减。发布前为每个任务设定预算，在模型、提示词、步数上限和上下文大小上做实验，同时重跑同一套测试以保证质量不降。生产中按智能体、工具和用户流程追踪成本，为每个会话设硬上限，把成本驱动因素反馈回实验环节。那个4.7万美元的循环就是反例：团队看得见账单，却没有东西能拦住它。而成本数据，正来自为可观测性搭建的同一批调用链。

三者缺一不可

按需求跑的测试决定发布，生产中的调用链显示行为在哪里漂移、钱花在哪里，而每一次成本优化——换更小的模型、缩短提示词——都要先过一遍测试再上线。Anthropic在2026年1月的工程指南《Demystifying evals for AI agents》中表达了同样的观点：离线评估需要与生产监控、A/B测试和人工审核结合，问题才不会只在生产环境里冒出来。

回到开头那两个问题：你的智能体准备好发布了吗？它比两周前更好了吗？把可审计、可观测、可预算三件事做到位，两个问题都能用证据回答，而不是靠直觉。