把企业 AI 项目按「在做什么」排一次序，比按「用了什么模型」排有用得多。IoT Analytics 在 2026 年 10 月 26 日发布的一份统计提供了这个视角：在其研究库收录的 1,533 个真实企业 AI 项目中，流程优化占 52.2%，营销内容生产占 30.1%，客户咨询处理占 22.2%，软件开发占 16.5%，运营报告占 13.2%。而被行业反复讨论的智能体——单智能体 11.3% 加上多智能体 2.0%——合计只占 13.4%。
这组数字对我们有一处直接用处：它是给客户排项目顺序时，少数能对外引用的公开依据之一。过去半年里，我们遇到最多的沟通场景不是「能不能做智能体」，而是客户手上已经有三四个待排的项目，需要有人告诉他先做哪个、哪个可以先不做。本文按这份分布做三件事：先说清统计口径和分布本身，再说分布为什么长成这样，最后给出我们把项目切成三层台阶的做法、交付清单与验收口径。文中方法与项目细节来自我们的交付实践，具体周期、成本与效果以客户环境实测为准；涉及的界面与流程描述为原理示意，不含真实客户数据。
一、1,533 个项目摆在一起，前五名是谁
先只看应用类型这一张表。前五名依次是流程优化（52.2%）、营销内容生产（30.1%）、客户咨询处理（22.2%）、软件开发（16.5%）、运营报告（13.2%）；协作、问题解决、产品与研究分析、合规、质量控制构成前十名的其余部分，报告未逐项给出百分比。一份项目可以同时落在多个类型上，所以这些比例相加会超过 100%，不能按「互斥分类」去读。
这里必须把口径说清楚，否则很容易引用错：报告标题里的 1,533 是研究库的项目总量，而应用类型的比例统计基于 2025 年与 2026 年一季度的 734 个生成式与智能体项目样本。两个数字分母不同，引用时应当注明「其中用于类型分布的样本为 734 个」。我们把这一条写进正文，是因为客户方的内部汇报经常拿单个百分比当结论，分母被丢掉之后，争论就变成了数字之争而不是范围之争。
这张表里真正有信息量的是三件事
第一，排在前面的都是「有明确输入和输出」的活儿。流程优化也好、内容生产也好、运营报告也好，都能写清一句话的完成状态：这批单据的字段补齐了、这轮商品文案过了人工复核、这台设备的日报按时发出去了。有完成状态，才有验收；有验收，预算才敢批。
第二，智能体的份额在涨，但基数还小。报告给出的对比是：2022 至 2024 年，单智能体和多智能体系统各占 0.3%；到 2025 年与 2026 年一季度，分别升到 11.3% 和 2.0%，合计 13.4%。同期「非智能体的聊天机器人与助手」仍是最大块，占 60.1%，只比前值 65.0% 降了不到五个百分点。换句话说，企业里绝大多数所谓「上了 AI」的系统，形态仍然是对话框，不是会自己走完流程的东西。
第三，比份额更值得注意的是形态迁移。报告把项目按「只做输出」和「在定义范围内自主执行多步」分开统计：2025 年只做输出的占 59.5%，到 2026 年一季度降到 32.2%；能自主执行多步的从 1.1% 升到 17.8%。报告自己注明这组 2026 年的数字只基于 174 个项目，用来看方向，不构成稳定比例。方向确实清楚——项目正在从「会写」往「会做」挪，但挪的幅度远没有发布会现场给人的感觉那么大。
二、行业差别比技术差别更能解释这份分布
把同一份数据按行业切开，能看出项目集中在哪里：科技企业占了 2025 至 2026 年项目的 49.7%；金融服务属于早期采用者；零售与专业服务已经进入主流采用者的行列；制造和医疗进入得晚，报告把原因归为投资周期长与数据安全顾虑；教育和公共行政靠后。智能体口径下的差距同样明显——科技 16.8%、专业服务 16.2%、金融 13.7%，而制造只有 4.3%。
另一侧的需求曲线要参考 Gartner。其《2026 年 CIO 与技术高管调研》显示，目前只有 17% 的企业已经部署了 AI 智能体，但超过 60% 的企业计划在两年内部署，Gartner 称这是本次调研中所有新兴技术里最激进的采用曲线；同期的代理型 AI 技术成熟度曲线把这项技术放在期望膨胀期，并写明多数部署范围仍然有限，完全自主的智能体还不能满足多数企业的实际需求。
把这两份公开数据放在一起，结论不是「智能体不行」，也不是「智能体已经成了」，而是一个更工程化的判断：意愿曲线和交付曲线之间存在明显错位，错位的部分正是我们做定制项目时要补的东西。计划两年内部署的 60% 里，有多少能真的跨过「有接口、有权限、有回放」这三道门槛，公开数据没有给答案；但从我们接触的项目看，卡住的位置高度一致，都在流程本身没定稿、系统没接口、责任链没定人这三件事上。
三、为什么项目都堆在流程优化和内容生产
这不是因为客户不懂新技术，而是这三类活儿在企业内部天然便宜。理解这一点，比记住前五名的排序更有用。
第一，完成状态现成
询价单证齐不齐、素材有没有重复、日报按时发了没有，业务方自己就能判断，不需要为了验收另造一套评测体系。反过来说，「这个智能体聪不聪明」是没有现成判定标准的，一旦要把主观判断写进验收条款，合同谈判周期立刻拉长，项目也就很难按批次推进。
第二，责任链短
流程型项目的改动通常落在一张表单、一个字段、一次回写上，出错影响范围有限，负责人在组织里也找得到。而跨系统自主执行的项目，动的是别人的系统和别人的审批节点，第一个要回答的问题不是技术，是「出了事谁负责」。多数企业在一轮预算里不愿意同时处理这个问题，所以先把流程做扎实是理性选择。
第三，评估与回滚成本低
内容生成类项目可以「机器做、人复核」，复核不通过就退回，人工通道本来就在；流程型项目通常只在原系统的提交动作前加一步校验，回滚就是把新校验关掉。真正贵的是自主执行：要把授权边界、异常归因、可回放记录、失败后的人工接管一次性做完，这些都是纯工程投入，且很难在第一期就显出效果。
报告里那批被点名的项目也印证了这个逻辑：Kraft Heinz 把商品内容上线周期从八周压到八小时，NielsenIQ 的商品编码时间下降九成，Carvana 每单进线量降四成以上，Delivery Hero 的编码智能体每天合并一百七十多个提交（以上均为 IoT Analytics 报告转述口径）。它们共同点是业务动作清晰、可判定的完成状态明确、并且都保留了人工复核的位置——不是「模型替代了人」，而是把一条本来有人在做、但做法很原始的流程重排了一遍。
四、我们把项目切成三层台阶来排顺序
基于这份分布，我们在需求沟通阶段会把所有候选项目归到三层，然后按层给建议。这个动作对客户方内部立项也有用：多数争论其实源于把不同层的项目写进了同一份需求清单。
L1 生成层：先解决「产量」
输入输出都是内容，不碰别人的系统。文案、图片、详情页描述、软文初稿、素材去重都在这层。我们案例库里的「素材入库去重 + AI 生产 + 软文与媒体分发 + 人工复核」这条线就是典型 L1：模型只负责产量，复核位置必须留在流程里，而且复核结论要能回流到下一轮的生成规则里。这一层最容易被低估，因为它看起来没有技术含量；但同一套生成规则在客户自己的品类上跑不跑得住，取决于历史素材的规范程度，这部分工作量往往比模型本身大。
L2 流程层：解决「一条流程能不能自动走完」
这是分布表里 52.2% 那一档，也是我们交付量最集中的一层。特征是：有明确的起点和终点，中间需要跨系统取数、字段映射、格式校验、生成文档，最后写回原系统或由人确认提交。贸易询价类项目就是流程优化与客户咨询处理两条线的交叉——把分散在页面与文档里的报价信息归集到统一结构，识别器补全字段，记录来源 URL 与记录时间，再生成报关凭证、商业发票、装箱单和订单对账材料；写回店铺后台或提交给海关的动作由操作员确认。资产管理系统与广告机集群管理平台则说明另一件事：它们解决的是设备与数据的批量下发、状态回传和留档，本来就不需要智能体，用「规则 + 队列 + 看板」交付更省成本，也更稳定。
L3 有限自主层：只在一个可关闭的范围里放手
对应报告里那 17.8%——在定义范围内自主执行多步。这层的关键词是「定义范围」：能读哪些系统、能写哪些字段、单次任务的最大步数、超预算就自动停。范围没定，就不该立项；范围定了，还要有可回放的执行记录，否则第一次出错之后没法定位，只能整条流程退回人工。我们把「授权边界」和「执行记录可回放」当成进入 L3 的前置工程，单独排期，不和业务功能混在一个阶段交付。
判断一个项目该进哪层，只看三条
一是有没有可判定的完成状态；二是需不需要写入别人的系统、写到什么字段；三是出错了能不能靠回放定位到人或规则。三条都答不上来的需求，在我们的记录里一律先退回「流程梳理」阶段，不直接开工。
五、几个真正决定成败的工程点
范围只切一条流程，不切「一整类业务」
需求沟通里最常见的失控说法是「把销售相关的活儿都交给它」。我们的做法是把范围收到一条流程：一次询价、一份单证、一张日报。范围收窄之后，字段映射表能写完，异常分支能枚举，验收标准能落到具体动作上。范围铺开到一类业务时，这三样都写不全，项目会停在演示状态。
接口优先，读页面兜底，并且把兜底写进交付物
能走接口就不走页面。现实里客户环境大量是老系统：没有对外接口、只有内网可达、或者接口有但字段不全。这时候只能从页面侧读取数据，那就要把兜底方案当成正式交付内容来写——每个字段的页面规则、字段映射表、来源 URL、记录时间、读取失败时的定位方式，逐项进文档。这一步偷懒的代价很直接：页面结构一调整，流程就断，而现场没人知道断在哪个字段。客户内网隔离、不允许外部服务直连这类限制，也要在方案里按环境写清可达路径，而不是留给上线后处理。
写入动作留给人确认
读回来的数据可以自动入库，写出去的动作我们默认要人点一次。这既是对客户账号主体的交代，也是项目能顺利验收的现实条件：账号和店铺主体在客户侧，我们不代保管密码、不代运营。需要全自动提交的场景，我们会单独确认审批链与责任归属，再按项目方案实施。
每一步可回放
执行记录里存输入、输出、耗时、失败原因和当时的规则版本。没有回放能力，问题会被归因成「模型不稳定」，接下来就是无休止的提示词调整。有了回放，能直接分辨这是字段映射缺失、来源页面变动、还是规则本身该改——这三种情况的修法和责任方完全不同。
六、交付物与验收
我们按层交付的清单大致固定，写在这里供客户方内部立项时对照：
一、流程说明书：起点、终点、每一步的责任人、人工确认点的位置；二、字段映射表与页面规则：字段来源、获取方式、映射关系、失败时的定位口径；三、权限矩阵：可读范围、可写范围、最大步数与预算上限，以及超出后的停止条件；四、执行记录与回放说明：留存周期按客户的数据管理制度设定；五、运维手册与培训：现场人员能自己改字段映射、能自己查失败原因；六、源码与部署文档：交付可自维护的完整代码与环境说明，可按项目方案实施私有化部署。
验收口径我们不用「效果承诺」的方式写，而是按客户环境的实测口径定五项：任务能否按定义的完成状态判定通过；异常样本是否每一条都能定位到具体环节；单位流程里的人工介入次数；单次处理耗时与人工基线的对比；来源 URL 与记录时间的留存完整度。这五项的合格线应当在项目开始前和业务方一起定，而不是交付时再谈。
七、边界：哪些项目不该按智能体立项
第一，流程本身还没定稿的。流程在两个人手里做法不一样，机器只能学到其中一种，剩下那种会变成故障。这种情况先做流程梳理，或者用表单和规则把流程固定下来。
第二，只有内容需求的。需求只是把商品描述写得更规范，那就是 L1，硬包装成智能体只会增加维护成本。
第三，跨系统写入但责任链没定人的。这类项目卡住的从来不是技术，是「出错谁签字」。责任没定就开工，最后大概率停在只读模式。
第四，数据基础还不成立的。历史素材没有去重、主数据没有编码规则、单价与规格散落在不同表里，这种状态下先做数据治理，收益比直接上模型更明确。
第五，行业进入节奏本来就该慢的。报告里制造只有 4.3% 的智能体份额，不是落后，而是投资周期与数据安全约束决定的。这类环境里，先把 L2 的流程型和可视化项目做出来，比追一个能自主执行的多智能体更容易形成资产。
常见问题
问：智能体和聊天机器人在交付上的区别是什么？
答：交付物不同。聊天机器人的交付物是一组问答能力和知识库；智能体的交付物是流程说明书、权限矩阵、字段映射表和执行记录。后者多出的是接口、写入控制与回放三块工程，这也是成本差异的主要来源。
问：我们该先做哪一层？
答：先看有没有可判定的完成状态，再看要不要写入别人的系统。多数企业的合理顺序是先 L2、再 L1 补齐产量、最后在有边界的地方做 L3。这条顺序和公开分布里前五名集中在流程优化、内容生产、咨询处理是一致的。
问：没有接口能不能做？
答：能，但要按兜底方案交付：页面规则、字段映射、读取失败的定位方式都要进文档，并且明确页面结构变动后的维护责任。这部分工作量应该在报价阶段体现，而不是当成模型的额外能力。
问：怎么判断一个项目被做窄了还是做宽了？
答：看异常样本能不能枚举。做窄了的项目，异常分支是有限的几种，每种都有对应处理；做宽了的项目，现场总会出现「这个情况没定义过」，那就是范围一开始铺得太大。
问：这些公开数据能直接写进我们的立项报告吗？
答：可以引用，但要注明分母和口径。734 是类型分布的样本量，1,533 是研究库总量，174 是 2026 年一季度形态迁移的样本量；报告本身也注明后者只反映方向。跨行业引用时还要说明行业差别，不要拿科技企业的 16.8% 去套制造环境。
附：口径与来源
本文行业分布、应用类型与形态迁移数据，来自 IoT Analytics《The top 10 enterprise AI applications: What 1,533 real-world projects show》，发布时间 2026 年 10 月 26 日；其中应用类型比例基于 2025 年与 2026 年一季度的 734 个生成式与智能体项目，形态迁移的 2026 年数据基于 174 个项目样本，报告注明该组数据用于观察方向。文中企业案例数据（Kraft Heinz、NielsenIQ、Carvana、Penda Health、Delivery Hero）均为该报告转述口径，未做二次核实。
部署意愿与采用曲线数据，来自 Gartner《2026 年 CIO 与技术高管调研》及其代理型 AI 技术成熟度曲线的公开摘要：仅 17% 的企业已部署 AI 智能体、超 60% 计划两年内部署、技术位于期望膨胀期。百分比之间不可直接换算，两份数据的调研对象与时间窗口不同。
本文的三层台阶划分、工程要点、交付清单与验收口径来自我们的项目实践，不构成对任何具体效果的承诺；周期、成本与实测指标以客户环境为准。
