AI 助手各配一个，还是收成一套

一、这一篇只管一个决定

你公司在两三个部门已经各装了一个 AI 助手。明年预算桌上摆着两件事：再给两个部门各买一个，还是把现有这几个并成一套。

这一篇给判据，不替你做这个决定。它给三样能直接拿走用的东西：一套判据、一张台账、三句问供应商的话。

先说清一件事：这里讲的"助手"，是会自己接活、还会跑到系统里把那件事办完的程序。接到一句"把这单改个地址"，它去订单系统里改，改完回你一句改好了。

只会答话、不动系统的那种（内部问答机器人）也算在内，但它带来的麻烦小一档。下面凡涉及"动过什么"的地方，说的都是会动手的这一类。

二、"几个助手"这个数，先定怎么数

按员工看到的入口数，还是按后台跑着的程序数？两个数不一样，有的一个入口后面挂着三个程序，有的三个入口共用一个。

本文后面说的个数，一律按入口数。理由是老板能看到的就是入口：员工手机上那几个图标、企业微信里那几个应用。

台账那一节也按入口记。同源的多个程序在一行里注明，别一上来就把台账做成工程清单，那种表没人维护。

三、多数公司在跑，少数有人在统

一家做低代码平台的公司 OutSystems 那份 2026 年的企业 AI 开发现状调研，样本约一千九百名全球技术决策人。三个读数：96% 的企业已在某种程度跑着智能体，只有 12% 建了统一管起来的那一层，94% 把"助手到处蔓延"当成安全与复杂度上的风险。

这三个数的分母都是受访企业，是问卷自填，不是第三方审计。本文只读到对它官方发布的转述，按二手处理。

四、数量在往上走，统的那一层没跟着长

艾瑞咨询那份《中国企业级 AI 智能体发展洞察报告（2026）》里，两个读数要放在一起才好看。

前一个：2026 年一季度，在用 6 到 10 个、11 到 26 个、27 到 50 个、50 个以上智能体的企业占比，都比 2025 年上升，已经有一部分大中型和集团企业部署到 50 个以上。

后一个：90.7% 的企业只部署了 1 个智能体开发平台，部署 2 个及以上的占 9.3%。

一边是数量在涨，一边是管它的那一层几乎没加。转述里没给每一档的具体百分比，本文不补数。档级同样按二手。

五、"十五万个"那一句，别拿来吓自己

Gartner 在 2026 年 4 月预测：到 2028 年，全球财富 500 强企业平均会运行超过 15 万个智能体；只有 13% 的组织认为自己具备合适的治理能力。

后一个数是企业自评，不是审计结论。前一个数的分母是全球最大的那 500 家，跟一家两百人的公司没有关系。

看到"十五万"就担心自己太少、或者担心行业已经失控的，都属于误读。这一条按二手转述处理，不当承诺用。

六、名单外的助手，是跟着软件更新进来的

一家做智能体风险核查的公司 Reco，那份 2026 年智能体安全现状报告的转述里有两个数：约 1280 款第三方软件产品已经内嵌了 AI 能力，其中约 282 款接进了企业统一的登录体系（就是公司那一道"你是谁"的门）。

按这两个数算，大约每五款里才有一款走过那道门。分母是那 1280 款产品，不是你的公司装了多少款，别拿它去乘自己的采购单。

报告把来源分成三类：随软件更新继承来的、用第三方运行时配置出来的、企业自己建的，前两类占比最大、增速最快。

这一条解释了台账上最常见的一个现象：采购名单上有三个，员工实际在用七个。多出来的那四个没人买过，它们跟着某次版本更新进来的。

七、第一桩麻烦：没人能说清有几个、谁在负责

把助手统一管起来那一层卖得最凶的几家厂商，产品页上有句话写得很直白。AWS 那一页说：随着更多团队开始构建，智能体会成倍增长，快到难以追踪；没有统一视图，就没人知道存在什么、谁在负责、谁有权限。

这句是厂商原文，一手，但它是卖这一层的厂商说的，本文只当问题描述用。

老板要问的三样，正好被这句话摆齐了：有几个、谁在管、它能进哪些系统。话不假，问题也不假。

八、第二桩麻烦：钱算不到哪一个助手头上

还是那一页，另一句：算不清归属的智能体支出，就是控制不了的支出，要按团队、按项目、按每一次动作分别记账。

各家 AI 助手的钱走两条腿。一条是席位费，按人头收的那份月费；另一条是用量，每问一次、每办一次付一次的那笔钱。

席位费在采购单上看得见。用量那一笔常混在云服务的月账单里，跟服务器、跟存储、跟别的调用挤在同一行。

四个部门四个助手，月底看到的是一张合起来的账单。这时候问"客服那一个花了多少"，没人答得出。

九、第三桩麻烦：同一份资料要在三处各改一遍

价目表改一次，三个助手各自的知识库（就是喂给它们的那批资料）就要各改一次。改了两处漏一处，第二天就有人拿着旧价格对外报价。

这一桩不用看任何报告，有两套以上入口的公司都撞过。

它贵在那件人人都记得、但没人固定去做的动作：改完之后逐处核对。核对这件事一忙就省，一省就出错，出错以后要查是哪一处没改，又是一轮人工。

十、第四桩麻烦：同一句问题，两个答案

「这个客户上个月买了多少」，一个助手按下单时间算，一个按发货时间算。两个数都算对，就是不一样。

这不是 AI 在编。是两套口径都进了系统，各自有人写进去过，各自都有人签过字。

问的人不知道背后有两套，拿着其中一个数去开会。这种事故最后被归成"AI 不靠谱"，其实问题出在数据口径那一层，跟模型没关系。

顺带说一句，身份那一层（哪一次动作是谁授权的、动了什么数据、是人还是机器）另有一篇专门讲账号的稿子在管。这一篇只管数量与钱，不重复。

十一、什么时候确实该各配一个

三条判据，占两条就别并。

第一条，数据不能互看。看薪酬的那一个和看生产排程的那一个，被放进同一个权限池，等于自己给自己找事。

第二条，节奏不一样。客服那一个要 7×24 小时待命、话术一周改三次；月结那一个一年忙两周，改一次能用一年。

第三条，部门愿意自己养。有人改话术、有人看结果、有人对出错负责。这一条最硬：愿意自己养的部门被强行并掉，第二年它会绕过你去买第二个。

十二、什么时候该并成一个

四条判据，占两条就该动手。

同一批资料：两套知识库的内容重合，改一次要改两处，这是最直白的重复。

同一群人：同一个部门用两个入口问同一类问题，第二个入口的存在理由通常只是"当时先买的那个不好用"。

两份月费买的是同一件事：一边按人头收，一边按次数收，但两笔钱解决的是同一个动作。

第四条最省：上线时有人认领，现在没人改、也没人看。那一个不用并，直接停。

十三、"收成一套"收的是四件事，不是把助手变大

登记：谁在跑、归哪个部门、谁负责。这张表就是台账，第十七节给列。

计量：每一个助手每月多少钱，席位费与用量分开看。做不到这一步，后面的成本判断都是猜。

权限：每一个助手能读哪些数据、能写哪些数据。读写要分开记，能写的那一半风险高得多。

留痕：它替谁动过哪一笔，出事时能查到那一次动作。

这四件事做一次，四个助手共用同一套；不做，就是四套各做一遍。并助手是结果，不是动作。

十四、上统一平台要付的三笔代价

迁移：现有的助手要在新平台上重做一遍，包括话术、资料接入、权限映射，还有那套判对错的题。

锁定：以后换平台，这一层又要重来一次。这一笔跟买哪个平台无关，是这一层的通病。

上线期：这一层的建设按几个月算。业务部门等不了几个月，它这个月就要用。

艾瑞那个 90.7% 说明大多数公司还停在一个平台那一档，很可能就是因为这三笔还没人愿意先付。这一句是我的读法，报告里没这么写。

十五、自己算一遍：重的那一份值多少钱

下面每一个分母都是我自己设的假设，不是任何一家的报价，也不是任何一次真实项目的记录。

第一笔算席位。假设四个部门各开了 15 个席位，每席每月 60 元，那么每月 4×15×60 = 3600 元，一年 43200 元。

再假设其中两个部门问的其实是同一批资料。那这两份就是重的那一份：2×15×60×12 = 21600 元。

第二笔算人的动作。假设一批资料一年更新 24 次，三处各改一次是 72 次动作，并到一处是 24 次。

72 与 24 之间那 48 次不是钱，是漏改的机会成本。每一次漏改，对应一个员工拿着旧价格出去报价。

这两笔账的意义不在金额，在于它把"要不要并"变成一个能核对的问题：你公司那两个部门，问的到底是不是同一批资料。

十六、供应商方案里那句"多个助手协同"，先问三句

这几个助手各自能看哪些数据，是谁给的权利，写在合同的哪一条？

每个月的用量能不能按助手分开出账，出账口径由谁定，多久给一次？

资料更新在哪一处改，改完多久生效，谁来确认它已经生效？

三句话里有两句答不上来，那一层就得你自己建。报价单上"多智能体协同"那一行，不该按已交付的内容算钱。

十七、先做那张台账：六列，一次两小时

要填的列	填什么	什么算过关
名字与入口	员工在哪儿点开它	一个入口一行，不合并
用的部门	谁天天在用	能写得出一个人名
每月多少钱	席位费与用量分开记	能对上账单里那两笔
能读哪些数据	它查得到哪几套系统	系统名列出来
会动什么	有没有替人提交过单据	会写的单独标出来
谁负责	出错的时候找谁	空着的先标红

第六列是关键。写不出人名的那一行，就是明年预算该问的那一行。

会写的那一列要单独看。只读的助手答错一句，最多浪费十分钟；会提交的助手做错一次，是一张单据、一笔款或者一次发货。

十八、按台账分三档处置

档	什么时候归这一档	动作
并	同一批资料、同一群人	留一个，另一个的对话记录留档，两个月内并完
留	数据不能互看、节奏差很多、有人自己养	不动，但进台账，权限与用量按上表记全
停	三个月没人认领	先把会写的那一半关掉，只读留着，两个月内定去留

三档里最省事的是第三档。它不用选型、不用迁移、不用等预算，只要一个人承认"这个我们不需要"。

十九、三个月之后，只量三个数

新增了几个；还在被用的有几个；有几对在做同一件事。

三个数要一起看才有意义。只有第一个在涨、第二个不动，那是买了没人用，跟并与否无关。

第一和第三个都在涨，而台账"谁负责"那一列还是空的，那就不是要不要上平台的问题，是已经晚了半拍。

第二个数最难拿。它需要每个助手自己有一笔账，而这正是第八节说的那个做不到的事。所以第一次量，能拿到第一和第三个数就算过关。

二十、今天就能做的一件事：问一句话

在公司的群里问一句：你们手上有没有不是你们部门买的 AI 助手？有的把链接贴上来。

这一步不花钱、不改任何系统，只做一件事：把台账第一列拿到手。

收上来的行数一定会多于采购名单，多出来的那几条不是有人在违规，是第六节那两类来源在起作用：跟着版本更新进来的，和别的部门顺手配出来的。

拿到名单之后，按第十二节那四条判据走一遍，再谈要不要并。顺序反了，就会变成先买平台、再发现平台里该装什么还没定。

二十一、这一篇里每个数算哪一档

档级只分三种：一手（发布主体自己的原文）、二手（别人转述它的原文）、未取原文（本文没读到任何一方的原文，只是多处转述一致）。

OutSystems 那份 2026 年调研的三个比例、艾瑞咨询那份 2026 年报告的两组占比与 90.7%、Gartner 2026 年 4 月那两个预测、Reco 那份 2026 年报告的 1280 与 282，全部按二手处理：本文只读到媒体与行业号对各家官方发布的转述，没有取到报告原文和问卷样本明细。

AWS 产品页那两句是一手原文，但出自卖这一层的厂商。本文只把它当问题描述用，不当效果证明。同一页那两个客户案例（一年投产十七个、不到四周上线）没有进正文，厂商自述的案例不当依据。

96%、12%、94%、13%、90.7%、9.3% 这些比例的分母互不相同。前三个的分母是受访企业，艾瑞那两个的分母是"部署智能体开发平台的企业"，Gartner 那一个是全球财富 500 强。它们之间不能相除，也不能乘成一件事。

约每五款里有一款、四万三千二百元、两万一千六百元那一笔、七十二次与二十四次，全部是本文自设假设上的算术，每个分母都在各自那一节写明。它们不是报价、不是项目记录，也不构成对任何一家产品的判断。

至于要不要现在就管起来，一句实话：助手只有两三个、并且每个都知道谁在用的时候，不用管。这一篇讲的是一条线，过了那条线，麻烦才比省下来的力气大。