为什么 70% 的智能体项目，会在 6 个月内失败？
问题不在 AI，而在管理层
这两年，几乎所有组织都在谈 AI、谈智能体（Agent）。
但一个不太被公开讨论的事实是：
大多数智能体项目，并没有失败在发布当天，而是“悄无声息地死在 6 个月左右”。
不是被宣布失败，而是：
- 逐渐没人再提
- 使用率越来越低
- 最后变成一个“当初很热闹的尝试”
我见过不少这样的项目，也参与过复盘。
结论其实很扎心：
70% 的智能体项目失败，根本不是技术问题。
一、我们高估了 AI，低估了组织复杂度
很多管理层有一个潜意识假设：
“只要模型够聪明，问题自然会被解决。”
但现实恰恰相反。
在真实业务中，智能体面对的不是：
- 标准问题
- 干净数据
- 明确规则
而是：
- 情绪化用户
- 模糊边界
- 责任不清的灰色地带
AI 的能力在进步，但组织的复杂性没有变。
当一个项目失败时，我们往往第一反应是：
- 模型不行
- 准确率不够
- 需要再调一调
但很少有人愿意回头问一句：
这个项目，一开始就被“管理正确”了吗？
二、失败的第一原因：目标从一开始就是错的
这是最常见、也最致命的问题。
很多智能体项目的目标，听起来都很宏大：
- “提升效率”
- “打造智能客服”
- “先试试 AI，看能不能用起来”
这些话在战略会上没有问题，
但在执行层面，几乎等于没有目标。
因为没有人能回答清楚：
- 到底替代哪一类工作？
- 成功的标准是什么？
- 如果没达标，算不算失败？
我见过太多项目，做了 3 个月后，大家开始困惑：
“它好像也能用，但好像也没什么用。”
这类项目，基本已经进入倒计时。
一个残酷但真实的结论是：
目标越宏大，智能体项目失败得越快。
三、失败的第二原因：把 Agent 当成“万能员工”
这是技术团队和业务团队共同容易犯的错。
项目第一版时，Agent 的定位通常很克制：
- 回答标准问题
- 做简单分类
但很快就会进入第二阶段：
- “顺便帮我做下推荐吧”
- “能不能再处理一下投诉？”
- “它这么聪明，应该可以多做点”
于是，一个 Agent 开始同时承担：
- 客服
- 销售
- 情绪安抚
- 留存转化
结果往往是：
- 没一件事真正做好
- 出一次问题，就会被全盘否定
管理上的核心原则其实很简单：
一个 Agent，只能做一类决策。
不是因为技术不行，而是因为：
- 责任无法界定
- 风险无法评估
- KPI 无法设计
四、失败的第三原因：权限设计是灾难级的
这一点，往往直接决定项目“死得快不快”。
智能体项目常见的两种极端：
- 权限给得太小 —— 没任何业务价值
- 权限给得太大 —— 一次事故直接叫停
真正成熟的做法，从来不是“全自动”，而是：
给 Agent 执行权，但一定是有明确上限的执行权。
比如：
- 金额是否有阈值
- 是否必须支持人工随时接管
- 是否有强制升级机制
很多项目失败后会被归因为“AI 不稳定”，
但真实原因往往是：
管理层没有想清楚：
一旦出问题，谁来兜底？
五、为什么这些问题在一开始很少被讨论？
因为它们都不是技术问题，而是管理问题。
而管理问题，意味着：
- 权力重新分配
- 责任需要明确
- KPI 需要重做
这些事，往往比调模型更难。
但有一个好消息是：
这些失败，并不是随机的。
它们是高度可预测的。
六、真正成熟的智能体项目，一开始就在“防失败”
我见过少数真正跑起来的项目，它们有一个共同点：
- 目标极其具体
- 权限设计非常保守
- 人工兜底被视为“成功的一部分”
- 用业务指标，而不是技术指标评估
它们并不激进，甚至看起来有点“慢”。
但正是这种克制，让项目活过了 6 个月、12 个月，
并最终融入组织。
如果你正在考虑，或已经启动智能体项目，我只建议你先问团队三个问题：
- 这个 Agent 到底替代哪一类工作？
- 一旦出问题，谁负责兜底？
- 如果 3 个月后要停，我们是否能体面地停？
如果这三个问题现在回答不清楚，
那这个项目失败的概率，已经很高了。
下一篇，我会具体拆：
智能体项目最容易踩的 3 个管理误区，为什么“很聪明的 AI”反而更危险。
如果你关注的是管理、组织效率和智能体落地，
可以点个关注，后面会持续拆解。
