为什么 40% 的 AI Agent 项目被砍：我们亲历的失败模式

Gartner 发布过一个数字，暗示到 2027 年大约 40% 的企业 AI agent 项目会被取消。从我们在 DACH 和欧盟构建 agent 系统的位置看，取消并不神秘。它们聚成 8 种失败模式。每种都有一个征兆，每种以不同方式杀死项目，而大多数如果在第一个月而非第六个月发现，都有便宜的修法。这篇文章就是我们希望在做第一个 agent 项目前有人写出来的事后复盘。

证据基础：Wavect 在 agent 与 AI 产品上的项目，包括 Twinsoft AI、PromptID、Quivr，以及 Hyperstate AI（已成功交付，上线后资金耗尽，不是产品或技术失败）。

失败模式 1：幻觉作为信任杀手

征兆：演示里两条自信的错答案。团队补丁式改 prompt。下次演示，再两条不同形态的错答案。

它如何杀死项目：信任不是线性衰减。在高管面前一次明显的错答，价值相当于十次静默的成功。agent 变成“那个会撒谎的 AI 玩意儿”，预算转身走。

早期发现的便宜修法：约束动作空间。一个会说“我无法从提供的来源回答此问题，下面这位是最接近的人工对接”的 agent，胜过一个开始编故事的 agent。先建拒答路径，再建顺利路径。

失败模式 2：工具调用延迟堆叠

征兆：孤立看 P50 延迟还行。多步任务上面向用户的 P95 延迟是 25 到 45 秒。

它如何杀死项目：用户抛弃 agent，回到他们本想替代的手工流程。adoption 拉平。CFO 问为什么我们要为没人用的 token 付费。

便宜修法：从第一周起按工具调用测量长尾延迟。在顺序不承重时并行工具调用。缓存幂等读。按步选 LLM 档位，而不是按 agent 选。能完成任务的最便宜模型胜出。

失败模式 3：评测债累积

征兆：团队推一次 prompt 改动。没人知道有没有改善。在一个 Slack 串里靠感觉做回归测试。

它如何杀死项目：没有评测，每次改动都是赌博。系统漂移。八个冲刺过后，没人信得过这个 agent 到敢让它见真实用户。项目悄悄不再被优先处理。

便宜修法：给 agent 做 TDD。第一冲刺就建评测脚手架。对前 20 个用户意图做 golden-set 测试。pass-rate 作为部署关卡。我们在更广义的 QA 实践中写过，对 agent 来说加倍适用。

失败模式 4：每次动作的成本冲破单位经济

征兆：LLM 提供商的第一张账单还行。第三张账单是 12 倍。

它如何杀死项目：CFO 要看单位经济。每解决一张工单的成本超过毛利。agent 技术上成功，商业上死亡。

便宜修法：从第一天起追踪每次动作的成本。按步选模型。激进缩短 prompt。缓存静态上下文。带较小 embedding 的 RAG 胜过往 prompt 里塞 20 万 token 上下文。我们见过一周内能实施完成的架构选择带来 4 到 8 倍成本下降。

失败模式 5：缺少人工交接设计

征兆：80% 的情况下 agent 能跑。另外 20% 没有逃生口。用户去找客服抱怨。客服看不到 agent 做了什么。

它如何杀死项目：客户侧团队搭一个平行绕道。agent 变成被绕过的 Tier-0。同时运维两条流程的成本把任何一条都说不过去。

便宜修法：在自治之前先设计交接。每个 agent 动作都附完整上下文记录。一键升级到人工并带上对话历史。明确策略：哪些情况 agent 必须让位。

失败模式 6：把数据质量问题伪装成 agent 问题

征兆：agent 从知识库返回错误答案。团队调 prompt。毫无改善。

它如何杀死项目：团队在修错的层。源数据陈旧、矛盾或错误。任何 prompt 都修不了。几个月被埋进腐朽地基上的 prompt 工程里。

便宜修法：在扩 agent 前先审计源语料。每份文档有负责人、刷新节奏、矛盾检测。通往可用 agent 最快的路径，往往是更干净的数据管线，而不是更聪明的模型。

失败模式 7：范围贪心（一个 agent 做 9 件事）

征兆：路线图写着“agent 将处理客服、销售线索筛选、内部知识查询、日程安排和合同评审。”

它如何杀死项目：每个能力都和其他能力争 prompt 预算、工具预算、评测预算。没有一个变好。团队为演示优化，交付一个在九件事上都平庸的 agent。

便宜修法：一个 agent、一项工作、一份评测。窄发上线。只有当前能力通过生产门槛评测，才加下一项。组合优于混淆。

失败模式 8：监管与审计轨迹缺失

征兆：agent 上线。两周后，法务问“审计日志在哪里？”和“我们怎么处理一个 GDPR 第 22 条异议？”

它如何杀死项目：agent 在缺口堵上之前被下线。团队用六周事后补合规。势头死掉。

便宜修法：把审计日志当作一等数据结构，而不是 console.log。MCP 工具调用记录输入、输出、模型版本、时间戳、操作者。人工覆盖界面记录是谁覆盖了什么、原因是什么。我们在配套文章里覆盖了 GDPR 与 AI Act 叠加合规的产物层。

"评测是衡量一个 agent 唯一诚实的尺度。其他都是带挑选过的查询的演示。"

在真实项目里这些失败模式如何聚集？

按我们的经验，失败模式不会单独出现，会聚成簇。我们在卡住的项目里最常见的组合：

已交付的 agent 和被砍掉的有何不同？

我们一致看到三项纪律动作，没一个奇异。

1. 评测脚手架在第一冲刺建好。没法测量改善就没法上线。
2. 从第一次集成起就追踪每次动作的成本。按步选模型当作工程决策来对待，不是默认。
3. 在自治之前先设计人工交接。把审计轨迹当作一等关切，不是为法务事后拧上的螺丝。

Hyperstate AI 已交付。然后公司上线后资金耗尽，这是融资失败，不是产品或技术失败。要点：即使技术执行干净，也救不了外部因素导致的项目。但马虎执行不管资本怎样都保证被取消。