企业 AI Agent 用例：内部职能先行

立项会上最常出现的一句话是：我们该从哪个用例开始。多数团队会挑最像未来的那个——面向客户、直接产生收入、演示效果最好。半年后回头看，真正每天在跑、有人在验收、产出算数的，往往落在另一个位置：公司内部，且输出能被机器判定对错。

这不是直觉，是两份第三方实测数据加上我们自己的运营账共同指向的分布。本文把已落地的用例摊开，给出一个买方可以直接用的第一个用例选择法，并说明这套顺序在什么情况下不成立。

一、实测到的用例长什么样

McKinsey 2026 年的全球 AI 调研给出的分布很集中：企业规模化 agent 最常出现的职能是 IT、知识管理和软件工程，而不是销售、客服这类对外职能。大型企业里约三成在规模化编码 agent，营收十亿美元以上的企业中有 40% 在规模化 agent，比上一年的 27% 明显上升，而中小企业的比例停在 22%。

Microsoft 2026 Work Trend Index 从另一个角度印证了同一件事。对 10 万条以上 Microsoft 365 Copilot 对话的隐私保护分析显示，49% 的对话用于认知类工作——分析信息、解决问题、评估与构思；17% 用于产出交付物，15% 用于找信息，19% 用于与人协作。也就是说，被实测到的使用量集中在思考支持与内部产出，而不是对外自主执行。

两份数据的口径不同：McKinsey 是自报调研，Microsoft 是对话分类加遥测信号。但它们指向同一个位置。这个位置不是偶然形成的，它有筛选机制。

二、筛选器是可验收性，不是场景吸引力

我们自己的做法可以提供这个机制的直接观察。每引入一类工作交给 agent 之前，我们问的第一个问题不是它能做什么，而是它的产出如何被判定为合格。内容产出要过结构校验与构建检查，代码变更要过类型检查与完整构建，研究简报要过来源与去重检查。检查能写出来，这类工作就能交给 agent；写不出来，就先不铺开。

为什么内部职能天然排在前面？因为内部工作的失败大多可以回滚。一份内部研究报告写错了，改一版重发；一段自动化流程配错了，回滚再跑。对外承诺、报价、合规声明一旦发出就无法撤回，失败成本不可逆。用例顺序由失败成本决定，与场景的想象空间无关。

这也解释了为什么编码 agent 走得最快。代码有编译器、有测试、有构建流水线，输出可以在几秒内被机器判定对错。同样一份判断如果发生在销售承诺或客户沟通里，验收标准要么不存在，要么只能由人给出，规模化就无从谈起。

把内部流程按验收成本再拆一层，选择会变得更具体。同样是内部职能，机器能独立判定的程度差别很大，可以分成三层。

三层不是按技术难度分的，是按验收成本分的。第一层的验收几乎免费，第二层需要一次性把规则写出来，第三层每跑一次都要人投入时间。如果一个用例的价值落在第三层，而团队没有为它安排人的时间，它就会停在演示阶段，无论模型多强。

这里有一个可以直接用的判断标准：能不能把验收写成一条命令，或者退一步写成一份清单。能写成命令的，这一批就可以铺开；只能写成清单的，先跑试点并记录人工复核的实际耗时；连清单都写不出来的，说明这项工作本身就是人在做判断，应该先把判断从流程里拆出来，再谈自动化。

三、预测和实测必须分开读

关于 agent 用例的公开信息里，三种口径混在一起，是买方最容易踩空的地方。

我们只把第三方实测的分布数据当基准：McKinsey 的函数分布、Microsoft 的对话构成、我们自己运营账上的产出与验收方式。这三类的共同点是别人可以独立复核。

四、我们自己的用例账

把顺序落到我们自己的运营上，结果是可以核对的：目前 109 个定时任务登记在册、85 个处于启用状态，全部落在内部职能——研究、内容生产、监控、审计、代码变更。它们产出了 296 篇中英文成对文章、82 页双语 wiki 和每日多份研究简报。

人在这条流水线上保留三件事：选题、立场、对外发布。选题决定做什么，立场决定说什么，发布决定是否对外。其余环节由 agent 完成，并且由机器先验收。这个分工不是设计出来的理想状态，是反复踩坑之后剩下的部分：凡是我们试图让 agent 直接承担判断和对外承诺的环节，最后都退回给人。

对我们来说，这份账最大的用处不是展示产出量，而是回答买方最常问的那个问题：第一个用例应该选什么。答案是选那个验收标准已经存在、失败可回滚、且有人接收产出的内部流程。

五、这套顺序的三处边界

六、给买方的第一个用例选择法

把上面几节压缩成一张三步检查表，可以用来筛掉大部分注定停在演示阶段的用例。

七、同样的预算，两种结果

把这份顺序放到两家规模相近、预算相同的公司上，半年后的差别会变得很具体。一家选面向客户的自主接待，一家选内部的报告与知识流水线。

两个团队的能力没有差别，选型也没有明显失误，分岔来自验收面。面向客户的自主接待在第三个月就同时撞上长尾和不可逆动作，而内部流水线从第一个月就有可用的验收标准。

买方可以把这道分岔压成一个数字：单次产出的验收成本，等于人工复核的分钟数乘以运行频次。内部产出的复核常常以几十秒计；对外动作的复核需要业务、合规或几个人共同确认，分钟数高出一个量级。同一个模型、同一笔预算，验收成本决定了它会变成日常，还是继续停在演示。

还有第三种花法，单价往往低于前两种：先把验收能力本身建出来。写下一条可执行的检查、跑通一次自动校验、记录一次人工复核的实际耗时，这些动作本身不产生业务产出，但它们决定了后面每一个用例能否铺开。我们自己的顺序也是这样，在引入第二类自动化之前，先把第一类的检查脚本写完，再开始接第二个流程。

对买方更实际的做法，是把这笔钱分成三份：一份用于选定内部流程并写出验收脚本，一份用于跑通并记录人工复核的耗时变化，剩下的才用于扩展覆盖面。三份的先后不要倒过来。先把大部分预算压在覆盖面扩展上，通常得到的是一批同时需要人工兜底的流程，而兜底的工作量会以另一本账的形式回到团队身上。

最后留一个可以自己回答的问题：如果把公司里所有面向客户的 agent 演示先停掉，只保留内部职能上的自动化，你们的交付表会变短吗？如果不会变短，说明价值已经长在内部了，接下来的预算应该投在验收能力上，而不是继续买演示。

参考来源：McKinsey, The State of AI: Global Survey 2026（规模化 agent 集中在 IT、知识管理与软件工程；营收 10 亿美元以上企业 40% 在规模化 agent，去年 27%，中小企业 22%；大型企业约三成规模化编码 agent）；Microsoft, 2026 Work Trend Index Annual Report（10 万条以上 Copilot 对话分类：49% 认知类、17% 产出、15% 找信息、19% 协作；活跃 agent 同比 15 倍、大企业 18 倍）；OpenAI, How V7 gives AI agents institutional memory（厂商口径案例：最难图查询准确率 89%、单份文档成本下降 78%，属厂商自报，非独立验证）；Carly AI, AI Agent Statistics 2026（第三方汇总：Gartner 关于企业应用内嵌 agent 与客服自主解决比例的预测、PwC 的高管自报生产力数据，均非实测）； 内部数据来自 OOMeta 自身的定时任务登记与内容库（109 个登记、85 个启用、296 篇文章、82 页双语 wiki，2026-09-24 核对）。