企业 AI 化改造改到哪一层：外挂、内嵌与重构的判定顺序

企业 AI 化改造最先要回答的，不是用哪个模型、接哪家平台，而是这次改造要动到哪一层。

同一个需求，可以只在现有系统外面挂一个问答入口，也可以嵌进审单、派工、报价这些流程节点，还可以连主数据与编码体系一起重建。三种做法的报价能差出十倍，风险也不在一个量级：外挂答错一句话，损失是一张截图；重构改错一个编码，受影响的是整条业务线。

Gartner 在 2025 年 6 月 25 日的新闻稿里判断，到 2027 年底，超过 40% 的智能体项目会被取消，列出的原因很朴素——成本上升、业务价值不清、风险控制不足。这三条里没有一条是「模型不够聪明」。换句话说，多数项目不是败在技术，而是败在改造范围定错了：该浅的地方做深了，该深的地方只做了个界面。

这篇文章讲三件事：三种改造深度各自改什么、五个问题决定你该停在哪一层、每一层的交付物与验收怎么定。文末列出引用的一手口径，也列出明确没有采用的数字。

一、五个卡点，几乎每个改造项目都会撞上

卡点一：把外挂当成了终点

最常见的一种。企业先做一个知识库问答，再做一个文档摘要，再做几个页面操作的辅助脚本，每个都能演示，每个都在用，但一年下来，业务指标没有变化。

原因不复杂：这些工具省的是「查」和「写初稿」的时间，不改变「谁在什么时候做什么决定」。审批还是那套审批，派工还是那个人派工，报价还是业务员自己算。效率工具的价值是真的，但它不该被当成改造的成果来汇报——汇报口径一旦错位，第二年就没人愿意批预算做更深的那一层。

卡点二：把内嵌做成了重构

另一种极端。业务方提了一个「让智能体帮忙审单」的需求，方案会上被扩成「顺手把编码体系统一、把客户主数据也理一遍、把权限模型重做」，于是项目从两个月变成两个季度，业务部门在中间几个月里既不能用新系统，也不能完全用旧系统。

这类项目往往不是技术失败，而是节奏失败。主数据确实该理，但它有自己的前置条件：谁负责、口径由谁拍板、历史数据怎么分级处理。这些没定之前就开工，改到一半会发现每个部门都有一票否决权。

卡点三：写操作没有人工边界

外挂阶段只读，问题不大；一旦进到内嵌，智能体就会开始「写」——写工单、写报价、写库存调整、写审批意见。这里的风险不是它写错，而是它写错之后没人知道该找谁。

工程上至少要三样东西：写操作前的确认点、可回放的执行记录、以及一键回到人工的开关。这三样缺任何一样，业务部门都不会真的把节点交出去，最后系统上线了，人还在旁边手工核对一遍，等于多了一道工序。

卡点四：数据没就绪，让模型背锅

Gartner 在 2025 年 1 月发布的一份数据就绪度研究里给出两个判断：63% 的组织要么不具备、要么不确定自己具备支撑 AI 的数据管理实践；到 2026 年底，缺乏 AI 就绪数据的 AI 项目中有 60% 会被放弃。

放到项目现场，这两句话对应的是很具体的东西：同一个客户在 CRM、ERP、开票系统里有三个编号；同一个物料在采购叫 A、在仓库叫 B、在图纸上叫 C；同一笔金额，财务报表和业务报表差一个税。模型读到的是一堆互相矛盾的字段，它给出的答案再流畅也没有意义。

这时候停机去「治理数据」，往往也做不成，因为业务不能停。可行的顺序是：先用只读的方式把矛盾暴露出来，做成一张差异清单，再按业务影响排优先级，一次修一类，修完一类再放开一层的写入。

障碍集中在系统与数据侧，另一份调研也指向同一方向。Anthropic 与调研机构 Material 在 2025 年末访问了 500 多位美国技术负责人，其《The 2026 State of AI Agents Report》里，受访者列出的三项主要障碍是：与现有系统的集成（46%）、数据访问与质量（42%）、实施成本（43%）。排在前面的不是模型能力，而是系统接不接得上、数据能不能用。

卡点五：治理没跟上，三个部门各说各话

Deloitte《State of AI in the Enterprise 2026》调研了 24 个国家、3,235 名企业负责人，其中近四分之三（74%）计划在两年内部署智能体，但只有五分之一（21%）认为自己已经具备成熟的自主智能体治理模型；同一调研给出的全球口径是，把 AI 用到显著或充分程度的受访者约占 28%。

Gartner 2026 年 3 月对 223 位数据与分析负责人的调查则显示，治理项目失败的原因里，文化阻力（60%）已经超过资金约束（40%）；据此预测，到 2027 年，未能解决数据与分析治理文化挑战的组织中，60% 也无法成功治理 AI。

翻成现场语言：采购在比价，IT 在管权限，业务在管结果，三张表各自成立，但没人对「这个智能体可以做什么、不可以做什么、出了事谁签字」负责。治理不是一份制度文档，它是三件事的合订本——权限边界、审计留痕、责任人。

二、三种改造深度的边界

把「改造」拆成三层，不是为了分类好看，而是因为三层的改动对象、失败代价和组织前提完全不同。下面这张表是判定的起点，不是选型的终点。

这张表最容易被误读的一格是「典型周期」。它不是工期承诺，而是判断依据：如果一个需求按外挂做要六周、按重构做要六个月，而业务只愿意等六周，那就该先做外挂，把重构拆成后续的独立专项，而不是把两者压在一个项目里。

多数企业停在流程层，也有分布参照。同一份 Anthropic 报告显示，57% 的受访组织已把智能体用于多阶段工作流，而推进到跨团队、跨职能端到端流程的只有 16%。跨系统打通目前是少数企业的做法；对多数企业，先把一条流程做扎实，再谈要不要重构，是更符合现状的顺序。

三、五个问题，决定这次改造停在哪一层

每问一次，得到的不是「做不做」，而是「做多深」。五个问题按顺序问，前一个的答案会缩小后一个的范围。

问题一：这件事做错了，代价可逆吗？

可逆的错——报表多算一行、摘要漏一个段落、查询慢了几秒——适合外挂。不可逆的错——发错货、开错票、改错库存、签错合同——必须有人工确认点，也就是至少内嵌。

判断的时候不要问「出错概率高不高」，概率再低，乘上不可逆的代价也可能是不能接受的。现场的经验是：涉及钱、货、合同、对外承诺的四类动作，默认按不可逆处理。

问题二：决策依据写成规则了吗？

规则有三种存在方式：写在系统里（有字段、有阈值、能执行）、写在本子上（有文档但靠人解释）、在人脑子里（老师傅知道，但说不清）。

只有第一种能直接做内嵌；第二种要先做一轮规则梳理，把文档变成可执行的判断条件，这一轮通常比写代码花时间；第三种不适合交给智能体，先做外挂，让它把人的判断过程记录下来，积累一段时间再谈规则化。

问题三：主键与口径统一了吗？

检查三个东西：客户、物料、单据号。同一个客户在几个系统里有几个编号？同一个物料在采购、仓库、图纸上的叫法是否一致？单据号在跨系统传递时会不会重新生成？

如果三个都有统一编号与统一口径，内嵌的字段映射可以做得干净；如果一物多码、一客多档，那么先做的是主数据专项，也就是重构的一部分。跳过这一步直接做智能体，最后一定会变成「智能体查出来的数和人对不上」。

问题四：系统外有没有人兜底？

内嵌的前提是「机器出结果、人来确认」。如果这个节点原本就没有复核岗，或者复核岗已经被裁到一个人管三条线，那么交给智能体之后，确认环节会形同虚设——人会直接点「通过」，因为不点就完不成当天的工作量。

这种情况下，要么补一个确认岗，要么把确认做成抽检（按比例、按金额、按异常类型），要么退回外挂，只做提示不做写入。三条路都行，唯独不能假设「人会认真看」。

问题五：这次愿意为它停几天业务？

重构必然有停机或双跑窗口。如果业务部门的回答是「一天都不能停」，那么重构就只能拆成「新老并行、按组织切换」的方式，周期会拉长，成本会上升。这个答案要在一开始就问清楚，不要等到上线前一周才发现没有窗口。

五个问题的答案组合起来，会落到三种结论：全部偏浅，做外挂；可逆性与规则满足、兜底有人，做内嵌；主键口径与停机窗口是主要矛盾，先做主数据与口径那一层，也就是重构的一部分。注意「重构的一部分」这个说法——很少有一次做完的重构，多数是按业务域分批的。

四、外挂：只读接入，先把「看得见」做出来

外挂的价值是暴露问题，不是解决问题。它不碰源系统，用只读账号把数据取出来，做查询、摘要、异常清单、对比看板。工程上有四件事要提前定。

一是取数时点。只读也会碰到一致性问题：早上九点取一次库存、十点取一次订单，两个数放在一张表里就会打架。做法是给每次取数打一个快照时间戳，报表里明确写「数据截至某时」，不要让人以为它是实时的。

二是权限。只读账号也要按数据范围授权，不能因为「反正是只读」就开全库。尤其是薪酬、合同、客户联系方式这类字段，读出来之后落到哪里、谁能看，都要先说清楚。

三是数据出域。如果外挂的问答入口调用的是外部模型服务，那么送出去的字段要先脱敏。哪几列可以送、哪几列必须本地处理，做成一张字段清单，比写一句「注意数据安全」有用得多。

四是产出形态。外挂最好产出一张「差异清单」，而不是又一个看板。差异清单只列对不上的地方：客户名不一致、金额差一分、交期晚两天、库存为负。业务每天只需要处理清单，不需要在一堆图表里找问题。

外挂的停止信号也要写在方案里：当业务开始说「这个提示我知道，但我改不了」的时候，说明问题已经不在「看不见」，而在「改不动」，该进内嵌了。

五、内嵌：找节点，不找部门

内嵌最容易犯的错是按部门写方案——「给销售部做一个智能体」「给财务部做一个智能体」。部门是组织单位，不是改造单位。真正能嵌进去的是节点：一张单子从谁手里到谁手里，中间有哪几个判断，判断错了会怎样。

三种嵌入位置

前置：在节点开始前生成草稿或建议，人改完再提交。比如报价前先生成一版报价单，业务员核对参数与条款后发出。这种位置风险最低，收益也最直接。

并行：在节点进行中做校验或提示。比如审单时同时比对合同、订单、发票三处的金额与数量，不一致就标出来。它不替人做决定，只缩短发现问题的路径。

后置：在节点完成后做归因与复盘。比如把本周所有驳回单的原因归类，找出前三类，反馈给流程设计。这一层最容易被忽略，但它是下一轮改造的依据。

人工确认点要写清三件事

看什么：确认界面上必须让人一眼看到关键字段，而不是把整张单子摊开让人自己找。改什么：哪些字段允许改、改了之后会触发什么。点了之后发生什么：是提交、是暂存、还是发起一次新的流程。

这三件事不写清，确认点就会变成「点一下继续」。现场判断确认点是否有效的办法很简单：抽查十次确认，看有几次真的改过内容。如果十次都没改，要么模型很准，要么这个确认点是摆设——两种情况的处理方式完全不同。

写操作的四道保险

幂等：一次请求只能产生一条记录。按「单据号 + 动作 + 参数摘要」生成幂等键，重复提交返回同一结果，而不是再写一遍。

超时与重试：只对可安全重试的动作自动重试，写入类动作在重试前先查一次是否已经成功。这条听着基础，但现场大量重复单据都出在这里。

部分成功：一张单子三个动作，前两个成功、第三个失败，不能整段回滚了事，也不能当成功继续往下走。要么由服务端提供状态机与补偿，要么退回人工，把已完成的部分标出来。

回退开关：按组织、按单据类型、按比例三个维度都能关。出问题时先关掉这一类，不要让所有人一起停。

六、重构：改的是口径，不是界面

重构的触发条件通常只有一个：不改就做不下去。具体表现是，同一个数在三个系统里有三个值，跨部门开会先花半小时对数；或者一个新业务要上线，发现现有编码体系根本装不下它。

先定五张表，再动系统

物料、客户、组织、科目、计量单位。这五张表决定了所有业务数据的主键与口径。定表的时候不要追求一次到位，先把「必须统一」的字段列出来——通常是编号、名称、类别、状态——其余字段允许各部门保留自己的扩展。

这一步最需要的是一个能拍板的人。技术团队可以列出冲突清单，但「以谁的为准」是业务决策，不是技术决策。没有这个人，会开了十次，清单还是清单。

双跑与冻结窗口

重构期间新旧系统并行，叫双跑。双跑不是把同一份数据录两遍，而是新系统跑主流程、旧系统只读留档，按周比对关键报表。比对的口径要提前写死：比哪几张表、比哪几个字段、差异在多少以内算通过。

冻结窗口是指切换前后一段时间内不做大的流程变更，避免「一边迁移一边改需求」。窗口长度取决于业务复杂度，通常按周计，不按天计。

历史数据分级

不是所有历史数据都值得迁。分三级处理：必须迁移的（在途单据、未结合同、有效客户）、只读留档的（近三年已结业务）、归档不迁的（更早的历史）。三级的分界线要在方案里写清，否则迁移范围会越滚越大。

七、四条技术要点

先定事实源，再谈写哪儿。每个关键字段都要能回答「以哪个系统为准」。客户主数据以 CRM 为准，库存以 WMS 为准，应收以财务为准。智能体可以读多个系统，但写的时候只能写事实源，其余系统通过同步或事件更新。这条定不下来，后面所有对账都是白做。

权限按动作拆，不按角色给全部。「这个智能体能做什么」要拆成一个个动作：查订单、改交期、发提醒、生成报价、提交审批。每个动作单独授权、单独留痕。不要给它一个「业务管理员」的角色，那等于把边界交给模型自己判断。

一切写操作可回放。回放要五样东西：输入快照、工具调用参数、返回结果、人工确认记录、时间戳。少一样，出了问题就只能靠回忆。回放不是给审计看的摆设，它是下一次调参和定位失败的依据。

灰度与开关先行。上线前就设计好三档灰度：按组织（先一个部门）、按单据类型（先一种单）、按比例（先一成流量）。每档都要有对应的回退动作与观察指标，观察期不少于两周。

八、交付物与验收

六份交付物，按改造深度取用，不必每份都做全。改造深度判定表：五个问题的答案与结论，一页纸。接口与字段清单：每个接口的用途、字段、频率、权限与失败处理。节点改造清单：节点、触发条件、输入、输出、人工确认点、回退方式，六列。口径与主数据表：五张主表的字段与责任人。灰度与回滚方案：三档灰度、观察指标、回退步骤。运行手册：常见异常、处理顺序、联系人。

五项指标里，最容易被跳过的是「确认点改写率」。它不需要额外埋点，抽一周的人工确认记录就能算出来。这个数长期为零，要么模型确实成熟，可以考虑减少确认；要么确认流程设计得让人不想改，那就该回头看界面与责任划分。

九、边界与成本

三句话划边界。第一，改造不等于替代岗位，它改变的是「谁在什么时点做什么判断」，编制要不要调是另一件事，需要单独评估。第二，不承诺准确率与上线周期，任何模型在客户数据上的表现都要靠现场测，方案里写的只能是验收方法，不是结果承诺。第三，涉及审批、合同、资金的写操作默认保留人工确认，这一条不因为「模型很准」而取消。

成本有三块。接口与数据治理是一次性投入里最大的一块，尤其是主数据梳理，通常占整个项目的一半以上工时。流程改造与培训是第二块，包括确认点设计、岗位职责调整、操作手册与陪跑。运行与治理是第三块，按年算：模型调用、监控告警、规则维护、定期复盘，这些不会因为项目验收而结束。

Anthropic 那份报告对此有一句概括：把 AI 部署当作系统工程，而不只是软件采购。它给出的战略结论是，企业 AI 价值的最大障碍不是模型能力或成本，而是组织准备度——尤其是数据可访问性，以及把内部知识汇聚成模型可用上下文的能力。这与上面的成本结构相互印证：一次性投入的大头在接口与数据治理，本质上是在补组织准备度，而不是在买模型。

有三种情况建议先不做：规则说不清且短期理不清的；一次错误不可逆、又补不出复核岗的；主数据没有任何部门愿意负责的。这三种情况下去做智能体，最后大概率会变成前面提到的 40% 里的一个数字。

十、常见问题

企业 AI 化改造是不是一定要重构系统？

不是。多数场景停在内嵌就够了：在现有系统的节点上加一层生成、校验或归因，写操作保留人工确认。只有当主键与口径本身不统一、不改就做不下去时，才进入重构。判断依据是前面五个问题，不是「别人都重构了」。

只做外挂，会不会只是个玩具？

看它产出了什么。如果产出的是又一张看板，价值有限；如果产出的是每天要处理的差异清单、异常清单、待办摘要，它就是有用的。外挂的问题不在浅，而在于长期停在浅层不往前走——当业务已经能看见问题却改不动时，就该进内嵌了。

智能体能不能直接写业务系统？

技术上可以，管理上要分动作。查询、生成草稿、发提醒这类动作可以直接做；改交期、改价格、改库存、提交审批这类动作要保留确认点，并且按动作单独授权。判断标准不是「它准不准」，而是「写错了能不能撤回、撤回要多久」。

数据很乱，能不能先上 AI 再治理？

可以先用只读方式上，但要接受一个前提：这一阶段的产出是差异清单，不是决策结论。让智能体直接基于矛盾的数据做判断，只会把矛盾放大。治理也不必等项目立项，从差异清单里挑影响最大的那一类先修，修完一类放开一层，是更现实的做法。

改造期间要停业务吗？多久？

外挂不停；内嵌基本不停，但要安排灰度与回退；重构通常需要双跑或按组织分批切换，冻结窗口按周计。这个问题的答案应该在方案阶段就写进合同，而不是上线前一周再讨论。停不停、停多久，直接决定重构的可行性与报价。

附：口径与来源

• Gartner 新闻稿，2025 年 6 月 25 日：预测到 2027 年底超过 40% 的智能体 AI 项目将被取消，主要原因是成本上升、业务价值不清晰、风险控制不足。原文页面限制自动访问，本文按该新闻稿的标题、日期与公开引述核对。
• Gartner《How to Evaluate AI Data Readiness》，2025 年 1 月 31 日（Mark Beyer、Ehtisham Zaidi、Roxane Edjlali）：63% 的组织要么不具备、要么不确定自己具备支撑 AI 的数据管理实践；到 2026 年底，缺乏 AI 就绪数据的 AI 项目中有 60% 会被放弃。
• Gartner 数据与分析峰会相关预测，调查于 2026 年 3 月完成、样本为 223 位数据与分析负责人：文化阻力（60%）超过资金约束（40%）成为治理项目失败的首要原因；到 2027 年，未能解决数据与分析治理文化挑战的组织中，60% 将无法成功治理 AI。演讲人为 Gartner 研究总监 Anurag Raj。
• Deloitte《State of AI in the Enterprise 2026》：调研覆盖 24 个国家、3,235 名企业负责人；近四分之三（74%）计划在两年内部署自主智能体，五分之一（21%）表示已具备成熟的自主智能体治理模型；全球口径下，把 AI 用到显著或充分程度的受访者约 28%。
• NIST《人工智能风险管理框架》（AI RMF 1.0，2023 年 1 月）与《生成式人工智能风险概况》（NIST AI 600-1，2024 年 7 月）：用于治理一节的框架口径，涵盖治理、映射、度量、管理四类职能，本文未引用其中任何量化指标。
• ISO/IEC 42001:2023《信息技术 人工智能 管理体系》：用于说明治理需要落到可审计的管理体系，而不是一份制度文档。
• Anthropic《The 2026 State of AI Agents Report》：与调研机构 Material 合作，于 2025 年末访问 500 多位美国技术负责人，覆盖不同规模与行业。本文引用其三项主要障碍分布（与现有系统集成 46%、数据访问与质量 42%、实施成本 43%）、部署深度分布（57% 用于多阶段工作流，16% 推进到跨职能端到端流程）与「组织准备度」结论，数字均按报告原文核对。
• 未采用：中文媒体转引的行业平均采用率、平均投资回报、项目失败率的具体百分比，以及「某类企业 AI 改造后效率提升多少」的效果数字，均未核到英文一手原文，本文一个都没有引用。文中出现的周期、成本与指标口径，都是工程判断与验收方法，不是行业统计。
• 本文不构成法律、审计或投资意见；不承诺排名、流量、项目周期与准确率。涉及具体系统的改造范围，需按客户现场的数据与流程单独评估。