Why Enterprise AI Gets Stuck in Pilots: Systems, Workflows, and Organizational Absorption

As AI and agents take on execution, our own agency expands. The question is whether organizations are built to capture it.

Microsoft, 2026 Work Trend Index Annual Report: “Agents, human agency, and the opportunity for every organization”

上一篇文章从更宏观的角度写 AI 怎样进入人的日常工作。这一篇换个镜头，只看公司内部。

很多企业现在都有一种不太好解释的状态。员工已经用 AI 写邮件、查资料、做分析，开发者也会把一段明确任务交给 Coding Agent。可一聊到公司层面，结论又常常变成：账号开了不少，demo 也不少，真正能把价值算明白的项目不多。

这两件事并不冲突。一个人改了做事方法，不等于公司已经改了运行方式。

模型再强，若只是旧流程旁边多出一个聊天框，效果通常也只停在局部提速。企业想拿到稳定结果，还得把一段工作重新安排清楚：谁提供输入，谁验收，谁处理例外，出了问题找谁，经验以后留在哪里。AI 在企业里难，难在这些听起来不太像模型的问题上。

企业级 AI 的未来应该是打通全部环节的内部协作系统，从 AI 辅助现有的人类协作系统的逐点效率提升，到将人变成一个 AI Native 系统中的一部分，我们还有很长的路要走。至于政府与 ToG 的 AI 系统，则比企业的路要更加漫长。

企业内部需要看两类证据

讨论企业 AI 时，我会先把材料分成两类。

一类看组织里的感受和行为：员工有没有使用，管理者有没有示范，组织是否允许试错，绩效和培训是否跟得上。另一类看已经进生产的项目：业务团队是否持续使用，质量、成本、速度或收入有没有变化，出了问题靠什么恢复。

微软 2026 Work Trend Index 比较接近第一类。它结合 Microsoft 365 的匿名生产力信号，以及对 10 个国家 2 万名 AI 用户的调查，问的是员工开始会用之后，组织有没有跟上。报告里的 Transformation Paradox 很具体：65% 的 AI 用户担心自己跟不上变化；与此同时，45% 的人觉得，与其花时间用 AI 重做工作，不如先完成眼前目标更安全。只有 13% 的人认为，就算短期结果没达成，自己也会因为尝试用 AI 重做工作而得到认可。

这很像许多团队里的真实处境。公司嘴上鼓励尝试，日常还是奖励旧的交付节奏、旧的审批方式和旧的短期指标。员工不去碰一件短期不确定的事，并不稀奇。

斯坦福 Digital Economy Lab 的《The Enterprise AI Playbook》看的是另一端。研究者访谈了 41 家组织的 51 个项目，覆盖 7 个国家和多个行业。入选项目都满足几个条件：系统已经稳定上线，业务团队持续使用至少三个月，结果能够量化，而且还有扩展或复制的可能。

这份报告不能拿来估计企业 AI 成功率。它本来就是成功样本复盘，研究者也写明了选择偏差和自我报告的限制。它更适合回答另一个问题：那些已经跑进生产环境的项目，除了模型外还做了哪些事？

两类材料摆在一起，企业 AI 的问题就不那么神秘了。员工有能力使用，不代表组织有条件吸收；模型能完成一段任务，也不代表这段任务已经成了可复用的业务能力。

一段工作进入生产，需要新的边界

想象一个运营同事让模型把用户反馈整理成周报。他复制几段文本，看一眼结果，再贴进文档。这已经很有用。

可公司若希望它每周稳定地跑，问题会一下子多出来：反馈来自哪些系统？哪些数据不能出公司？模型能看到什么？分类错了谁改？敏感投诉谁接手？周报最后给谁做决策？人工改过的地方要不要留下？下周能不能少犯同一种错？

前者是一段会话，后者才是一段工作。

我把后者叫作“组织吸收”（absorption）。它指的是把一段原来由人完成的工作重新安排好，让它有稳定的输入、明确的分工、可检查的结果和能继续改进的反馈。局部的 AI 输出走到这一步，才可能变成可复用的组织能力。

这件事可以拆成六步：

先选任务。 从高频、成本真实、结果能判断的工作开始，不要先从“模型还能做什么”出发。
补全上下文。 模型需要资料、系统状态和业务约束，不能只靠一段孤立的提示词猜。
划清权限。 AI 是起草、建议、自动执行，还是只在例外时把任务交还给人？
写好验收和例外。 什么算完成，什么算失败，谁能覆盖模型结果，出错后怎样恢复？
看交付后的结果。 除了省时，还要看质量、客户体验、风险、收入和积压有没有变化。
留下经验。 把被验证过的规则、人工修订、异常模式和评估结果写进下一轮工作流，不要让它们散在聊天记录里。

图 1：企业 AI 的交付物不是一次模型回答，而是一段可被执行、检查、接管和学习的工作闭环。

模型能直接覆盖的，只是其中一部分。它能理解文本、生成候选、调用工具，有时还能连续执行。剩下那些环节不会随着模型升级自动补齐。许多项目停在试点，原因就在这里：demo 与能长期运行的系统之间，仍隔着一段很长的路。

这也解释了为什么一些 Agent 在 demo 里很惊艳，进公司后却显得笨重。demo 只要证明能不能做；生产环境得说明在什么条件下做、做错后怎么办、谁负责、怎样证明它一直有用。

系统接口常常长成团队接口

前面还有一层没有展开。康威在 1968 年的文章里提出过一个朴素观察：设计系统的组织，最后往往会产出与自身沟通结构相似的设计。它不是严格的因果定律，也不能拿组织图硬推出系统图。它提醒我们，团队之间怎样沟通、谁有决策权、什么事情必须交接，都会慢慢留在系统的模块和接口里。

AI 系统会把这种关系放大。一个生产级系统同时碰业务目标、知识与数据、模型与评测、工具调用、权限、成本和安全。Google Cloud 的 MLOps 指引把持续集成、交付和训练放在同一条工程链路里，也是在处理这些交接怎样连续发生。组织里每多一个模糊的 handoff，系统里往往就多一层接口、审批或等待。

拿客服智能体举例。它若要读客户资料、订单、退款和风控状态，而这四块原本就靠人工审批串起来，智能体通常只会把串行流程搬到工具调用链里：权限反复校验，上下文在不同系统间丢失，异常又回到人工队列。此时先看的不一定是 Prompt，而是这条价值流上到底有谁在反复交接，却没有共同 owner。

用康威定律看企业 AI，常会看到几种典型形状。下表是设计推断，不是斯坦福样本里的统计结论：

团队怎样分工	系统容易长成什么样	常见麻烦
数据、算法、应用、安全各自排队协作	每层各有平台或服务，靠跨团队接口拼接	知识库更新慢，权限模型不一致，故障定位要跨好几组人
一个 AI 中台包办所有场景	巨型统一 Agent 或 RAG 平台，业务团队排期接入	平台变成瓶颈，真正的业务差异只能在平台外绕路解决
业务域小队端到端负责，旁边有共享平台	场景可以自己演进，平台提供统一模型、检索、审计和评测能力	自治与复用之间仍有张力，但边界和 owner 更容易说清

康威定律也容易被用过头。组织里有客服、订单、风控和知识部门，不代表系统就该顺手拆成客服 Agent、订单 Agent、风控 Agent 和知识 Agent。部门图不是多 Agent 架构图。先按任务、上下文和工具边界划出能力，再判断其中哪些步骤真的值得独立出来。多 Agent 更适合任务可并行、上下文容易互相污染，或确实需要不同工具和专长的情况；其余场景，简单、可组合的工作流通常更容易检查和维护。系统可以反映团队的协作关系，但不必把部门交接一比一翻译成 Agent 交接。

微软关于 AI CoE 的指引有相近的意思：AI 能力通常要建在已有的云、数据和治理团队之上，而不是另立一个只负责“做模型”的孤岛。Microsoft AI CoE 指引对开发者来说，这意味着系统里的 owner、输入输出契约、权限边界、SLO、评测和升级路径，最好能和团队真实的协作关系对上。工具调用链一旦又长又脆，可以先检查团队之间是否也有高频、模糊、没人负责的交接。治理也不该只在上线前出现一次；NIST AI RMF 的 Govern 部分把角色、职责和风险管理放在贯穿全程的位置。

项目花钱的地方，常常不在模型调用

斯坦福报告有两组数字很容易被做成标题：成功项目里，受访者认为最难的问题有 77% 属于变革管理、数据质量和流程重构这类“看不见的成本”；61% 的成功项目在当前成功之前至少经历过一次失败。模型仍然重要，企业也不必把失败当成必经阶段。这些数字提醒人，最后写在 ROI 里的模型费用，往往没把项目消耗的组织工作算进去。数据问题也不只是把所有历史记录清理干净。团队要先决定哪些数据有用、谁能访问、更新和错误怎样追，项目才不会为了追求“理想数据”一直停在原地。

企业很少能从理想数据开始。在很多场景里，LLM 本身也成了处理数据的工具。91% 的案例成功处理了非结构化数据，88% 的案例中，LLM 帮助企业打开了原本存在却用不起来的数据资产。过去数据散落在多个系统里，归属不同团队，没人能真正调起来。现在，企业至少有了把这些材料抽取、整理并接进工作流的新办法。

报告里的匿名物流案例很能说明这一点。发票处理看上去像典型的 AI 任务：读发票、抽字段、匹配订单、录入系统。可项目最开始面对的是多年积累的重复模板、电话邮件扫描件混在一起的输入，以及必须由业务专家不断校正的例外。团队先压缩混乱模板，再安排领域人员复核模型输出，把流程接进 ERP，高层持续清除协作阻力，项目才走到生产。模型当然在里面，但它只是其中一段。

如果架构图里只有 RAG、Agent、工具调用和模型路由，这些工作很容易被留在图外。可它们决定用户会不会信任系统，业务会不会停掉旧流程，数据团队愿不愿意开放接口，法务能不能允许更高价值的用例进入。项目可能有一个能用的原型，却没有一套被组织接纳的做法。

这和经济学里常说的生产率 J 曲线很像。通用技术进公司后，组织得先投入重写流程、训练人员、整理知识、补数据接口、建立治理和评估。短期内投入比收益显眼，等这些东西慢慢稳定，收益才更容易出现。企业当然不该无限期容忍项目没有结果；如果预算只覆盖模型和开发，把其他投入都当成额外摩擦，商业判断从一开始就会失真。

企业 AI 的成本不只有 token、GPU、SaaS 席位和供应商报价。系统还应尽量避免被单一模型绑死，并在合适的地方做模型路由。更大的成本，是把一段工作重新变清楚、接得进去、查得出来、出了问题有人负责。还要算上允许失败的成本：不仅是一次失败造成的硬性损失，也包括团队是否还有机会根据失败继续调整。

项目也会卡在员工不愿意用之外

项目推进慢时，管理者很容易把原因归到一线：不会用、抵触变化、没有积极性。可如果员工已经私下用通用模型写材料、查资料、做初步分析，问题通常不在使用意愿本身。

微软报告里的矛盾很真实。员工知道 AI 重要，却不相信组织会奖励他们为了 AI 去承受短期不确定性。一个人花三天重做交接流程，短期内可能少交一份旧格式周报；若绩效只看周报数量，最稳妥的选择就是别改。

斯坦福的成功案例里，阻力也常常不来自终端用户。Legal、HR、Risk、Compliance 等职能部门更常被受访者提到。这不等于这些部门保守，更不是让项目绕开法务。它们本来就替组织承担风险。若团队在最后一刻拿着一个边界模糊的 Agent 去请求批准，得到否决并不奇怪。

更实际的做法，是一开始就让这些角色参与工作设计。法务和合规定义哪些数据能进、哪些记录要留、哪些动作必须确认；风控判断哪些错误可以补救，哪些必须提前阻断；HR 和业务负责人要回答，被释放出来的时间会流向什么新工作。一线用户也不能只负责点开新工具，他们知道什么结果真的能减轻痛点。

否则就会出现 Shadow AI。员工为了把事情做完，仍走旧流程，同时在旁边用个人工具补效率。个人可能受益，公司却得不到可治理、可审计、可复用的能力。很多公司里，正式供给、治理和真实需求之间差得太远，员工的私下使用就在这个缝隙里长出来。

高层持续清除部门协同的障碍、提供试错空间，已有的平台与基础设施，以及一线员工急切想解决的痛点，都会缩短项目从部署到见效的时间。反过来，员工学习新技术、项目反复迭代、准备和清洗数据、处理合规要求，以及补齐流程文档，都会拖慢推进。项目最终能跑多快，取决于这些条件怎样叠加。

人机分工需要先看工作本身，再看它带来的变化

把工作重构放在人和 Agent 共同参与的语境里。落到团队日常，管理者还要决定任务怎样分配：AI 参与到哪一步、人在什么时候接手、最后由谁承担结果。

先把一件工作拆开，再谈交给谁。搜集资料、整理信息、生成候选、从大量记录里找异常，往往有相对清楚的输入和验收方式，AI 可以多做一些。项目定位、资源取舍、客户承诺、跨团队协调，通常牵扯更多背景信息和判断，负责人应该留在人手里。

错误会带来什么后果，也会改变分工。错了容易发现、容易修正的环节，可以让 AI 先完成；一旦错误会影响客户、资金、合规或品牌，人工复核要放在交付之前，系统也要留下升级和回滚的路。还有些工作看起来流程稳定，实际高度依赖客户历史、团队关系和业务默契。这类背景很难一次说清，不能假设模型已经理解。

产出是否需要独特判断，同样值得问。规范、完整的底稿适合交给 AI 加快；带着公司策略、审美和品牌取向的内容，AI 可以帮忙发散或起草，最后仍要由人改成自己的表达。这样分工，人的时间才会回到判断、沟通和承担后果这些更难外包的地方。

一句“AI 协助写提案”无法指导实际工作。团队需要把流程拆成步骤，分别写清输入从哪里来，AI 能做哪些动作，谁在什么位置复核，什么情况必须升级，以及谁对最终交付负责。人工对结果作出的修改也要留下来：有些是在改事实，有些是在补业务约束，有些来自经验。它们不该随着一次交付结束而消失。

写清这些内容，常规部分才能稳定地交给 AI；例外出现时，团队也知道该由谁接手。分工的难处在于把交接、复核和责任安排到每一个具体步骤里。

分工上线后，调用量和节省了多少分钟只能说明一部分。要看交付质量有没有变化：结果是否更准确、更适合实际场景，还是把返工留给了下一位同事。也要看省下来的时间去了哪里。如果团队把时间用在用户洞察、判断和关系工作上，效率才会变成业务上的余量；如果大家只是等着检查 AI 的输出，流程可能只是多了一层等待。

最后看一线的感受。人工复核是否越来越轻，还是每次都得大改？例外是否能顺利交给负责人，还是又回到模糊的群聊和临时协调？这些变化比一张漂亮的调用量图更早暴露问题。模型能力、业务条件和团队经验都会变，人机分工也应随之调整。

先进入生产的，不一定是最智能的任务

企业做 AI 时，很容易按看起来聪不聪明给任务排优先级。能写战略报告的模型，似乎应该比会分拣工单的模型更有价值。落地顺序往往相反。

成功项目更常从不那么浪漫的工作开始：高频、重复、积压严重、输入相对清楚、结果能够检查。安全告警分流、发票处理、客服初筛、采购补货、文档归档、知识检索、遗留代码迁移，都有这类特征。它们未必简单，但什么算完成通常说得清楚，错误也比较容易控制在可恢复的范围里。

斯坦福的成功样本里，全自主的智能体方案只是一部分。更多项目从常规部分开始，让 AI 处理高量、可恢复的工作，把关键输出和例外留在人工审核范围内。这个观察更适合用来理解落地顺序：输入稳定、结果可检查、错误能补救的任务，更容易先跑进生产；临床文书、对外内容、高风险决策和复杂编码，仍需要更长的协作与审核链路。

所以，自动化程度不该决定优先级。团队可以先把 AI 放进一个边界清楚、验证容易的环节，确认输入、验收、异常处理和回滚都能稳定运转，再考虑是否扩大授权。对 AI 应用开发者来说，最有价值的能力常常是把业务人员说不清的工作，整理成模型能参与、系统能执行、人工能验收的步骤。

软件开发和游戏研发没有跳出这条规律

放到软件开发里，这件事很具体。

Coding Agent 已经能读仓库、改文件、跑命令、做迁移、补测试。可一段代码被生成，不等于一个需求被交付。工程里还有需求边界、依赖系统、测试、CI、代码审查、发布窗口、监控、回滚和线上责任。开发者把写实现交出去以后，更多精力会落到定义验收、识别风险、安排反馈和承担最终变更上。与其一开始追求端到端自动交付，不如先把 Agent 放进测试、审查和回滚都较清楚的步骤。

AI Coding 特别适合模式清楚、验证链完整的改动：批量迁移、接口替换、配置更新、测试补全、已知 bug 的局部修复。它们都有相对明确的 diff、测试和回滚路径。需求还没稳定、架构取舍复杂、跨团队责任模糊的工作，模型再进步也绕不开组织上下文。

DORA 2025 从软件交付角度给了类似提醒：AI 的效果会受团队已有的反馈能力、平台能力和工作方式影响。这项研究只谈软件组织，不能推到所有企业；对做开发工具和工程 Agent 的人来说，它仍然很有用。局部加速不会自动变成整个系统更快，原有流程的缺口也可能被更快地放大。

游戏和内容生产也是这样。假设团队让 AI 生成活动配置或任务文本，生产链路不止是文案好不好看。配置要过 Schema 校验，ID 要存在，奖励要满足规则，任务前置条件不能冲突，敏感内容要能审阅，版本改动要能回滚，最后还要由策划判断节奏、玩家体验和品牌调性。模型能很快给出候选，但候选能不能进项目，要看团队有没有把验证和责任安排好。

模型越能生成和行动，验证、权限、日志、回滚与评估越不能等到上线之后再补。它们本来就是生产力的一部分。

Headcount Reduction 与结语

企业项目真有了生产率收益，管理层还要决定怎么使用这部分能力。斯坦福的成功样本里，减员是最大的单一结果，却不是多数。还有项目选择避免新增招聘、把人转到更高价值的工作，或用同样的人力加快产品路线。

这首先是一道经营选择。公司可以把省下的时间换成更快交付、更高服务水平、更细的客户覆盖，或者更低的人员成本。系统不会替管理层做决定。增长机会、预算压力、产品积压和可转岗的工作，都会影响这条路怎么走。

速度带来的也不只是成本优势。可以把它比作 MOBA 游戏里的移动速度：它不替玩家做决策，却会改变追击、撤退和支援的时机。企业里的效率也是这样。它打开了原来来不及做、做不起或排不上优先级的选择，至于把这部分余量用在什么地方，仍然要由管理层决定。

节省的时间有没有变成业务结果？人被转去做什么？客户得到的服务有没有变好？如果这些问题没有答案，所谓提效很可能只是在局部看上去漂亮。减员只是企业可能选择的一种结果，不是效率收益唯一的去向。

企业还没落地 AI，原因常常不在模型能不能做事。更多时候，公司还没把模型能做的事，接进一段可以验收、有人负责、出了问题能接住、之后还能继续学的工作。

从回答问题到替人做事，产品能力跨了一步；从替人做事到让组织稳定地获得价值，才是更慢、更难，也需要开发、业务、平台和治理团队一起完成的工作。

参考资料

Microsoft Work Trend Index，2026-05-05。
The Enterprise AI Playbook，Elisa Pereira、Alvin Wang Graylin、Erik Brynjolfsson，Stanford Digital Economy Lab，2026-04。
State of AI-assisted Software Development 2025，DORA。
How Do Committees Invent?，Melvin E. Conway，1968。
Google Cloud MLOps 指引。
Anthropic: Building Effective Agents。
NIST AI RMF: Govern。
Microsoft: Establish an AI center of excellence。