79% 的企业在搞 AI Agent，只有 2% 跑通了生产环境

你的公司卡在哪一级？

一、这个数字从哪来的

"79% 的企业在搞 AI Agent，只有 2% 跑通生产环境"——这篇文章标题在头条上能搜到，来源是一家研究机构对国内 500 家中小企业的调研。具体数字可能因样本和方法有偏差，但业内对这个比例的大致范围是有共识的：绝大多数 AI Agent 项目，停留在演示和 PoC 阶段，真正持续在生产环境跑起来的，是极少数。

这不是在泼冷水。搞清楚为什么绝大多数项目死掉，比盲目乐观地"赶紧上 Agent"有价值得多。

二、死亡漏斗：项目是怎么死的

绝大多数 AI Agent 项目的生命周期，可以画成一个漏斗：

第一级：老板感兴趣（100%）
看了某个 demo，或者同行分享，觉得 AI Agent 能省人力、提效率，让 IT 部门或者外部供应商做一个 PoC。

第二级：PoC 效果看起来不错（60-70%）
在演示环境里，输入几个问题，Agent 漂亮地给出了回答。老板满意，团队也觉得可行。

第三级：接入真实数据后出问题（30-40%）
一旦接入真实业务系统（ERP、CRM、数据仓库），Agent 就开始出各种幺蛾子——数据权限不对、接口格式不兼容、实时数据延迟……光是数据接入和权限配置，可能就要折腾 2-4 周。

第四级：在具体业务场景中效果不稳定（10-15%）
数据接进来了，但 Agent 在真实场景里的表现远不如演示时——幻觉多了、逻辑错误多了、边界情况让用户抓狂。

第五级：上线后没人维护，逐渐变成摆设（3-5%）
勉强上线了，但没有专人持续监控和维护。随着业务变化，Agent 的知识库过时、规则失效，用户满意度慢慢下降，最后大家不用了。

第六级：真正跑通生产环境，持续产生价值（2-3%）
剩下的这些，是真正把每个环节都做对了的公司。

三、第一死因：数据问题，不是模型问题

很多人以为 Agent 的效果取决于模型的强弱。实际上，绝大多数项目死在数据上。

3.1 数据孤岛

一家做五金配件的工厂，想用 Agent 给销售人员提供产品查询服务。产品数据分散在三个地方：ERP 系统里有参数和库存，官网的产品页面有描述，Excel 表格里有历史报价。这三个地方的数据没有打通，甚至同一种产品的名称在三处写都不一样（一个写"六角螺栓 M8×20"，一个写"螺丝 8mm*20mm"，一个写"HXLS-M820"）。

Agent 在这种数据环境下，检索出来的答案当然不靠谱。光是为了让数据规范化这一项，项目就多花了两个月。

3.2 数据权限和安全

一家医药公司想让 Agent 帮内部员工查询临床试验数据。但这部分数据有严格的权限控制——不同角色能看到不同级别的数据。现有的权限体系是为"人"设计的，不是为 Agent 设计的。Agent 以什么身份登录？它能访问哪些数据？它操作的日志怎么记录？

光是安全和权限这一个问题，就足够让项目延期三个月。

3.3 数据实时性

一家生鲜电商想让 Agent 帮客户查库存和价格。但库存和价格是实时变化的，每分钟都在变。如果 Agent 查到的数据是 30 分钟前的，就可能导致告诉客户"有货"但下单后发现已卖完。

实现数据的实时同步需要额外的工程投入，不是 Agent 框架本身能解决的。

四、第二死因：场景选择错误

不是所有场景都适合用 Agent。选了错误的场景，再怎么优化也没用。

4.1 不适合 Agent 的场景

高度创意性的工作： 广告创意、品牌策划、用户体验设计。这类工作需要的是"想出新东西"，而不是"执行已知流程"。Agent 能帮你搜集素材、分析竞品，但核心的创意判断，它还做不到。

高度个性化的服务： 高端咨询、心理疏导、复杂商务谈判。每个客户的情况都不一样，需要大量的实时判断和情感交互。Agent 处理这类问题的失败率很高。

后果严重的决策： 金融风控、医疗诊断、法律判决。出错成本太高，不能接受 Agent 的"偶尔幻觉"。

执行复杂物理操作： 设备维修、巡检记录。实体世界中的 Agent 还在早期阶段，不成熟。

4.2 最适合 Agent 的场景

高频、规则明确、数据可查的查询类服务： 客服咨询、内部知识库问答、产品信息查询。这是 Agent 的主战场。

固定流程的重复性操作： 数据录入、报表生成、邮件分发。规则明确，不容易出错。

辅助性工作（不是替代性工作）： 代码审查（初筛后人工再审）、文档生成（人工修改后使用）、翻译预处理（人工校对后交付）。

判断方法： 问自己"这个任务，能不能写成一份 SOP？"能写成 SOP 的任务，就适合 Agent。不能写成 SOP 的，比如"判断这个设计方案好不好"，就不适合。

五、第三死因：组织问题，不是技术问题

这是最容易被忽视、但可能是最具杀伤力的死因。

5.1 谁负责？

很多公司把 AI Agent 项目交给 IT 部门，IT 部门觉得这是业务部门的需求，业务部门觉得 IT 应该负责落地。没有明确的 Owner，项目就慢慢滑水了。

正确的做法： 指定一个"Agent Owner"，最好是既有业务理解力又懂一点技术的人。他负责定义需求、协调资源、跟踪进度、持续优化。

5.2 谁维护？

"AI 团队越做越累，Agent 系统越跑越差"——这个真实的反馈来自哪里？维护和优化。

一个 Agent 上线后，知识库要更新、意图规则要调优、新的异常情况要处理、用户反馈要跟进。这些工作需要持续有人做，不是上线一次就完事。

很多公司没有把"Agent 维护"列入部门 KPI，结果就是——大家都很忙，没有人专门做这件事，Agent 慢慢地就变了质。

5.3 员工不买账

很多一线员工担心"Agent 会替代我"，对 Agent 项目持抵触态度。即使 Agent 上线了，员工不用，还是用老方法。

这不只是心理问题，也是系统设计问题。如果 Agent 引入了但员工不需要改变工作流程，或者 Agent 反而让员工的工作变复杂了（比如还要审核 Agent 的回答、处理 Agent 搞砸的问题），他们当然不愿意用。

好的做法： 让员工参与到 Agent 的设计和测试中来。不要"从上往下"推，要"从下往上"反馈。员工觉得"这个东西真的帮我省事了"，他们才会真的用。

六、那些跑通了的公司做对了什么

看完失败案例，也看看成功的是什么样子。这几条是共同特征：

特征 1：从一个很小的场景切入。

不是一上来就做"全能 Agent"。而是选一个具体的、高频的、好评估的场景——比如"让 Agent 处理物流查询"。跑通了，再扩展到退换货、再扩展到售前咨询。

特征 2：有一个明确的 Owner，有预算，有时间。

不是"兼职做做看"，而是有专人负责、有明确的上线时间和验收标准。

特征 3：知识库有人持续更新。

成功的项目，一定有一个流程：每天/每周有人审查 Agent 的回答日志，修正错误答案，补充新知识。这和培养一个新人客服的逻辑完全一样——你投入的辅导越多，它成长的越快。

特征 4：接受"Agent + 人工"的混合模式，不追求全自动化。

成功的项目不是"Agent 完全替代人"，而是"Agent 处理 70% 的常规请求，人处理 30% 的复杂情况"。这种混合模式在现阶段是最现实的，也是用户体验最好的。

特征 5：数据问题是提前解决的，不是拖到上线后。

在搭建 Agent 之前，先花时间把数据来源理清楚：有哪些系统中的数据、谁有权限访问、更新频率怎样、格式是否统一。前期数据准备做得越充分，后面越顺利。

七、给你一个自检清单

如果你正在考虑或者已经在做 AI Agent 项目，用这份清单检查一下你在哪个阶段卡住了：

阶段一：准备

是否分析了目标场景下，高频问题的清单？
是否有结构化（FAQ格式）的知识库内容？
数据来源是否就绪？权限是否搞定？
是否明确了 Owner？

阶段二：搭建

是否先做了 PoC 再决定全量上线？
是否是小范围先行（比如一个业务线、一个场景），而不是全公司铺开？
是否定义了关键指标（解决率、转人工率、用户满意度）？
是否设置了转人工的兜底机制？

阶段三：上线

是否至少安排了一周的人工审核期？
是否有处理异常情况的应急预案？
是否建立了知识库更新流程？
是否定期审查指标数据？

阶段四：持续运营

是否安排了专人维护？
是否定期收集用户和员工的反馈？
是否根据反馈迭代知识库和规则？
是否评估扩展新场景的可能性？

如果这份清单里，有超过 3 个空没打勾，项目大概率还在"看起来不错"的阶段，离"真正跑通"还有距离。

八、最后说一句

2% 这个数字乍一看很悲观，但反过来说：现在能把 AI Agent 跑通生产环境的公司，是真的建立了竞争壁垒。 因为这不仅需要技术能力，还需要数据基础设施、组织协作、持续运营的系统性能力。这些能力，不会因为 Agent 工具变得更好做而自动获得。

换句话说，现在入场不算晚。但入场之前，先把上面的清单过一遍。

整理于 2026 年 6 月。部分数据来自头条搜索到的公开报道，案例基于行业从业者的公开分享整理。