Agent 项目的死法很朴素：不是模型不行，是审批、脏数据、KPI 没人认。

Demo 时全场鼓掌，上线三个月日活 4 人：企业 AI 到底死在哪一步

3 月立项，5 月 Demo Day。

会议室坐了 20 个人，投影仪还亮着，屏幕上 Agent 自己把一封客户投诉邮件读完、分类、生成工单、抄送了对应负责人。CTO 说了句“这就是未来”。有人拍了照发朋友圈，配文是“我们真的在做 AI 了”。

鼓掌那天没人问权限。掌声是最便宜的一次性资源。

8 月上线。

10 月，后台数据显示日活 4 人。其中 3 个是项目组成员。

这不是段子。过去两年我参与和旁观了 30 多个企业 AI 项目，活过半年的不到三分之一，而且每一次，死法都差不多。

Agent 项目的死亡不是断崖，是长达 90 天的缓慢窒息。

每一口气，都断在特别小的事上。

先别急着骂技术团队。把尸体剖开，第一个致命伤出现在写第一行代码之前。

01一、技术方案评审 2 天，权限审批 6 周

Agent 要干活，就得有权限。

读 CRM（客户管理系统）、写工单、发邮件、调 ERP（企业资源计划）。每一样都是一次跨部门谈判。

法务问：“它删了数据谁负责？”

安全问：“它能不能被诱导发错邮件？”

运维问：“出问题了怎么回滚？”

这些问题都合理。合理的问题是它们没有答案，只有流程。

一条真实的时间线：

• 技术方案评审：2 天
• 权限申请流程：6 周

6 周里，业务方的热情从 100 降到 30。

每一张单子都合理，合起来就是六周。没人能指认哪一步错了。

当初提需求的是业务部的小王，他为了这个项目写了 8 页需求文档。权限批下来那天，他已经在三个月前调去了另一个部门。新接手的人看了一眼文档说：这不是我提的。

项目还没上线，就已经失去了它唯一的拥护者。

可执行的做法：立项第一天就同步启动权限清单梳理，别等技术方案定稿。

把 Agent 拆成“只读版”和“可写版”两期。先用只读版跑出真实使用数据——谁在用、用来干什么、每天多少次。

拿数据去换写权限，比拿 PPT 去换容易十倍。

02二、数据脏得超出你的想象

权限批下来了，团队松了口气。

然后他们第一次连上了生产库。

Demo 用的是实验室蒸馏水，生产数据是河水。

同一个客户，在三个系统里有三个名字。全角括号和半角括号是两个客户，“有限公司”和“有限责任公司”也是两个客户。

“已成交”这个状态，销售表里是 1，财务表里是 Y，客服表里是空字符串。

Agent 最怕的不是没数据，是矛盾数据。

它读到两条冲突记录时，不会报错。它会礼貌地给出一个错误答案，而且语气非常自信。

这比报错危险十倍。报错至少有人会去看。

上线前做一次“脏数据体检”：随机抽 200 条真实记录，人工核对，统计字段缺失率和冲突率。

对不上的那四十条，才是这个项目真正的需求文档。

这个数字比任何 POC（概念验证）报告都更能决定项目生死。

如果 200 条里有 40 条对不上，先别训模型，先去修数据。

03三、KPI 归属，没人认领的孩子

数据勉强能看了，Agent 也跑起来了。

效率提升 30%。问题来了。

这 30% 算 IT 的功劳还是业务的功劳？

省下来的人力成本记在谁的成本中心（成本归集单位）？

如果 Agent 给客户发错了一封邮件，责任算谁的？

现实是：技术团队觉得我做完交付了，业务团队觉得这是你塞给我的东西。

没有归属，就没有人负责推广、没有人负责反馈、没有人负责迭代。

项目从“上线”那天起就进入了无人区。它会一直活着，但没人管它。

立项时白纸黑字写清三件事：

• 谁是用例 owner
• 谁的考核指标里包含这个 Agent 的使用率
• 出问题的第一责任人是谁

写不下来，就别立项。

04四、剩下两个坑，专杀侥幸活过前三关的团队

坑四：一上来就想做“全能助手”。

真实跑通的项目往往只做一件事，比如自动整理会议纪要并推送到项目群。

功能越窄，越容易被用起来。越全能，越像 Demo。

我们做过一个能查数据、能写周报、能发邮件的全能助手，上线后用户问得最多的一句话是——这个我什么时候用？

因为“全能”意味着用户不知道什么时候该用它。一个需要被想起来才能用的工具，等于不存在。

坑五：上线即完工。

没有埋点（记录用户操作），没有使用日志，没有每周复盘。

用户第一次用错了，第二次就不用了。团队三个月后才发现。

上线第 3 天有个用户连续失败了 5 次，第 6 次他再也没打开过。这条日志在三个月后的复盘会上才被看到。

上线第一周，每天看一次调用日志，把失败的前 20 条对话逐条读完。

这件事比再训一版模型有用得多。你会看到用户真正在问什么，以及 Agent 是怎么把一件简单的事搞砸的。

05五、活下来的项目，做对了什么

说这些不是为了劝退。恰恰相反，认清死法，才知道怎么活。

活下来的项目有三个共同点：

范围小到有点丢人。 第一个版本只服务一个部门、一个场景、二十个用户。

有人天天盯着用。 不是项目经理盯进度，是业务侧有一个具体的人，每天用、每天骂、每天提意见。

把“能用”排在“聪明”前面。 宁可它笨一点但结果可预期，也不要它偶尔惊艳但经常胡说。

我见过跑得最好的一个 Agent，只做一件事——每天下午 5 点把当天会议纪要整理好推到项目群。20 个用户，日活 17。它的产品经理每周五把这周所有失败的对话打印出来，一条条读。

企业 Agent 的胜负手不在模型参数，在组织摩擦力。

AI 的能力早就够了，够到溢出来。真正稀缺的是有人愿意为一件小事跑完 6 周审批，愿意抽 200 条脏数据核对，愿意在立项书上写下自己的名字——而不是像小王那样，名字还留在需求文档的首页，人已经调去了别的部门。

工具不是被推广起来的，是被一个人用顺手、用出脾气来的。

接下来可以做两件事：

准备立项的，先回去把权限清单和 KPI 归属写清楚，再开第一次会。

已经在坑里的，今晚就翻一遍调用日志，把失败的前 20 条对话读完。

Agent 不缺聪明的模型，缺的是一个愿意天天用它、天天骂它的人。

其实不只是 Agent。你公司里那些上线即巅峰、然后慢慢没人提的系统、流程、制度，死法都一样——不是不好用，是没有人真的为它负责。

—— 完 ——