80% 已采用 agentic AI,为什么企业仍难从试点走向规模化?
约 80% 的财富 500 强已采用 agentic AI,却仍有许多困在孤立试点。本文用 MIT Technology Review、海信实测、量子位百万级用户数据与 OpenAI 的 AI 原生方法论,拆解“试点→全公司”之间真正的组织、治理与度量差距,并给出一条可执行的规模化路径。
TL;DR： 许多企业的 AI 卡在试点,不是因为模型不够强,而是因为组织把 agent 叠在了旧流程上、喂给它的是没被记录下来的隐性知识。据 MIT Technology Review(2026-09-03),约 80% 的财富 500 强企业已经采用 agentic AI,但"progress toward meaningful scale remains uneven, with many organizations still working through isolated pilots"——真正推到全公司规模的进展并不均衡,许多仍困在孤立试点里。规模化的钥匙只有一句话:先把 agent 绑定到业务战略、重构工作流,再谈铺开,而不是在低效的老流程上加一层 AI。
本文用 MIT Technology Review、InfoQ 报道的海信实测、量子位 的百万级用户行为数据,以及 OpenAI 的 AI 原生方法论,拆解"试点→全公司"之间真正的组织、治理与度量差距,并给出一条可执行的规模化路径。
为什么很多企业的 AI 项目卡在试点阶段,推不到全公司?
答案先行:卡点几乎从不在模型能力,而在组织、工作流和知识底座。 换句话说,试点能跑,是因为它被人为地圈在一个干净、边界清晰、有人盯着的小场景里;推到全公司会散掉,是因为真实业务里到处是没被记录的历史、互不连通的系统和缺位的治理。
MIT Technology Review 把这种失败模式称为"新型碎片化"(a new kind of fragmentation):各个团队各自为战、各建互不连通的孤立系统,试点越多、割裂越重。文章引述 NiCE 首席运营官 Arun Chandra 的一句话点破了最常见的误区——"The last thing you want to do is to apply AI on an outdated or an inefficient workflow."(你最不该做的,就是把 AI 套在一条过时或低效的工作流上。)当底层流程本身就是坏的,agent 只会把坏的部分执行得更快。
工程一线的证据更直白。据 InfoQ《传统企业 AI 转型的最短路径,藏在研发部门》报道,海信在引入编码智能体 Qoder 后跑了 10 个试点:全新系统的开发效率提升了 3–4 倍,历史系统的提升却不明显。 瓶颈不是"AI 不会写代码",而是"它不知道那些从未被记录的历史"。这篇报道里有一句很适合钉在墙上的话:"人类工程师不懂时,至少会停下来问一句;AI 有时不懂,但照样往下写。"——模型甚至会放大旧系统里的隐性依赖问题。这正解释了为什么同一个 agent,在绿地场景里是生产力工具,一进入积压了十几年隐性知识的老系统就原地失速。
顺带澄清一个坊间高热的说法:网上流传"MIT 报告称 AI 项目失败率高达 95%"。这是一个未经严谨核实的流传数字,不宜当事实复述。用 MIT Technology Review 本轮的严谨口径校正:真实图景是"约 80% 已采用、但许多困在孤立试点",问题是"规模化不均衡",而不是"绝大多数彻底失败"。把"失败"精确地定义为"卡在试点、没能规模化",才是解决问题的起点。
试点 vs. 规模化:组织、治理、度量到底差在哪?
试点和规模化不是"同一件事做大一号",而是两种截然不同的心态。下面这张表把差异一次性讲清:
| 维度 | 试点阶段(Pilot) | 规模化阶段(Scale) | 证据锚 |
|---|---|---|---|
| 目标 | 为实验而实验,证明"能用" | 绑定业务战略(增收 / 降本 / 明确的财务目标) | MIT Technology Review |
| 工作流 | 在旧流程上叠一层 AI | 先重构工作流,再落 agent | MIT Technology Review(Chandra 原话) |
| 知识 / 上下文 | 依赖现成的显性文档 | 消解从未被记录的隐性历史 | InfoQ 海信 |
| 覆盖人群 | 小范围试用(~百人) | 全域推广(海信从近百人扩到 900+ 人) | InfoQ 海信 |
| 组织结构 | 各团队各建孤岛 | 连接式战略,主动避免"新型碎片化" | MIT Technology Review |
| 治理 | 事后补 | 隐私 / 安全 / 变更管理前置,agent 与人同标准考核 | MIT Technology Review |
| 度量 | 看 demo 效果 | 看可量化产出与真实算力分布 | 量子位 / OpenAI 案例 |
MIT Technology Review 给规模化开出的第一味药,就是超越"为实验而实验":把每个 agent 明确绑定到业务战略上,别去"boil the ocean"(妄图一口气烧干整片海),而是围绕高价值用例、工作流和劳动力变化,建一套"连接式战略"(connected strategy)。海信的数字给这张表提供了最具体的注脚——从近百人试用扩到 900+ 人,靠的不是把试点复制几十份,而是把研发在编码场景里沉淀的方法论作为底座往外迁。规模化的本质,是把试点里那套"人为干净"的条件,变成组织能持续供给的能力。
agentic AI 怎么从 pilot 走到规模化生产?
答案先行:五步,顺序不能乱——① 绑定业务战略与可度量结果 ② 重构工作流 ③ 沉淀上下文 / 知识底座 ④ 前置治理 ⑤ 从高价值、可复制的场景起步。
第三步是最容易被跳过、却最致命的一步。MIT Technology Review 的判断很硬:"The efficacy of these AI agents is purely a function of the context, the knowledge, and the data they can ingest and use."(这些 AI agent 的成效,完全是它们能获取并使用的上下文、知识与数据的函数。)也就是说,没有可供 agent 消费的知识底座,再强的模型在生产环境里也只是一个更快的猜测机。
第二步的样板,来自 OpenAI 对"AI 原生公司"的观察。在 OpenAI《How AI-native companies turn workflows into operating capability》 里,AI 原生公司的做法不是在既有流程上叠 AI,而是把"工作流本身"重构成一种可运营的能力(operating capability)。这与 MITTR 的"先重构工作流"是同一个道理的两种说法。
规模化确有可度量的成效,不是画饼。OpenAI 给出的落地锚点很具体:法律科技公司 Legora 用 GPT-6 Astra,几分钟审阅了 41 份文档;律所 Gilbert + Tobin 则是先把治理搭好、再规模化地推 AI。这两个案例说明:当工作流被重构、知识底座就位、治理前置之后,agent 才能在真实业务里跑出"可以写进财报"的产出,而不是停留在 demo。
从哪个部门 / 场景开始更容易见效?
答案先行:从研发 / 编程类场景切入,通常是最短路径,再由此向业务智能体迁移。
原因有二。其一是工程逻辑:据 InfoQ 报道,海信的经验是研发智能体与业务智能体共享同一套工程底座——模型调用、上下文管理、工具编排、任务拆解、执行反馈、质量校验、权限管控。研发在 AI Coding 里沉淀下来的 Spec 驱动、闭环反馈、质量护栏、知识消解这套方法论,可以跨场景迁移到财务、供应链、生产、客服等业务智能体上。先在编码场景里把底座打磨好,等于给后续所有业务场景预付了工程债。
其二是需求数据的佐证。量子位发布的《中国办公 Agent 用户行为不完全报告》(数据源 LobsterAI,8 月用户破百万)显示:泛"编程"与调试类任务占 agent 任务的 38.5%,居所有任务类型之首;从行业看,软件 / IT 行业贡献了 38.9% 的 agent 任务。真实使用量最集中的地方,恰恰是工程场景——这与"从研发起步"的判断相互印证。
(这条"研发部门作为企业 AI 转型发动机"的线索本身值得单独展开,我们会在系列第二篇里详谈,本文不铺开。)
规模化阶段怎么治理与度量,才不让它散掉?
规模化不是"铺开就完事",真正的难点在铺开之后:怎么治理、怎么度量,才不让它重新散成一地孤岛。
治理必须前置。MIT Technology Review 提醒,当 agent 开始承担更重要的工作时,治理、隐私、安全和变更管理只会更关键;它主张把"劳动力"(workforce)重新理解为"人 + agent"的组合,并且用与人类员工同样的标准去考核 agent。这句话的分量在于:它把 agent 从"工具"重新归类为"需要被管理的执行主体"。
度量则要盯真实使用,而不是 demo。量子位的报告揭示了两个规模化阶段绕不开的现实。其一是极端的头部效应:前 20% 的用户消耗了 87.4% 的算力,前 5% 的用户独占 53.5% 的 token。 这说明价值高度集中在少数深度场景——规模化的投放要顺着高价值处走,而不是平均撒网。其二是"无人值守"正在成为常态:12.2% 的调用并非由人实时发起,定时任务里单条指令平均带动 64 次模型调用,是人工发起(10.6 次)的约 6 倍。 当越来越多的调用发生在没有人盯着的时刻,度量与护栏就必须自动化——否则你根本不知道 agent 在办公时间之外替你做了什么、花了多少、对不对。
6AM 视角:用 FDE 工程纪律把试点接到生产
把上面这条路径拆开看,你会发现每一步都不是"AI 问题",而是"工程问题":重构工作流、沉淀知识底座、前置治理、自动化度量——这些恰恰是软件工程几十年来一直在解的事。6AM 的立场很朴素:规模化 agentic AI 的差异化,不在模型选型,而在工程纪律。
具体到落地,我们把研发场景里被验证过的那套方法论——Spec 驱动、闭环反馈、质量护栏、知识消解、权限管控——作为可交付的工程底座,帮企业把"试点能跑"接到"全公司能用"。这不是又一套 AI 咨询话术,而是由前向部署工程师(FDE)带着工程标准进现场,把隐性历史消解成 agent 能消费的上下文,把治理和度量做进流水线里。
如果你正卡在从试点往外推的那一步,不确定散掉的到底是工作流、知识底座还是治理,可以先做一次 AI 落地体检,把卡点定位清楚再决定投放。
延伸阅读:
- 为什么企业 AI agent 会在生产环境失效——从技术故障视角看落地
- 企业 AI 采用路径:自建 vs. 平台 vs. FDE——选型决策框架
- 企业级 agent 平台的部署要求——规模化的技术底座清单
常见问题(FAQ)
企业 AI 落地失败率真的有 95% 吗?
不宜这么说。"95% 失败率"是网上未经严谨核实的流传说法,不应当事实复述。MIT Technology Review 的严谨口径是:约 80% 的财富 500 强已采用 agentic AI,真正的问题是规模化不均衡、许多困在孤立试点,而非绝大多数彻底失败。
agentic AI 怎么从 pilot 走到规模化生产?
五步:先把 agent 绑定业务战略与可度量结果,再重构工作流,沉淀可供 agent 消费的知识底座,前置治理,然后从高价值、可复制的场景起步。核心是别在旧流程上叠 AI,而是把工作流本身重构成运营能力(OpenAI 语)。
企业想把 AI agent 用起来,该从哪个部门 / 场景开始?
优先从研发 / 编程类场景切入。据 InfoQ 报道,研发与业务智能体共享同一工程底座,方法论可跨场景迁移;量子位数据也显示编程调试类任务占比 38.5% 最高——先在工程场景把底座打磨好,再向财务、供应链、客服等业务智能体扩展最省力。
