企业 AI 转型,别再按个买 Agent

点击上方

“星云创联AI智库”

↑↑↑

获取更多人工智能资讯和产品

最近跟不少企业聊 AI 升级，聊到预算时，对方常常会问：

“做这几个 Agent，一共要多少钱？”

一个客服 Agent 多少钱？

一个运营 Agent 多少钱？

一个物流 Agent 多少钱？

这个问题听起来很具体，实际上，

报价口径可能一开始就错了。

下面这份“企业 AI 四笔账自评清单”，可以拿去对照你公司的现状。

很多企业一提到 AI 报价，第一反应就是按个算。

供应商也乐得这么报。

简单、清晰，好签单。

采购经理拿到一个价格带，也方便回去跟老板汇报。

老板则容易产生一种错觉：

“买几个智能体”，就等于公司开始 AI 转型了。

但真正做过企业 AI 落地的人，听到这种报价方式，往往会觉得不太负责。

企业做 AI 转型，最终要转成的是一个能够使用 AI、适应 AI、持续改进的组织，而不是从市场上采购几个 Agent 就结束。

Agent 本身，并不是一个合理的交付单位。

因为 Agent 背后连接的，从来不只是一个对话框，或者一套写好的流程。

它还会涉及：

数据在哪里；

数据是否干净；

不同系统能不能连通；

谁能看什么、改什么；

业务规则怎么判断；

出现例外时由谁接手；

上线之后如何持续优化。

很多企业 AI 推不下去，并不是因为 Agent 不够多，而是最核心的几笔账，根本没有算清。

如果把“买 AI”这件事拆开看，本质上是四笔账：

数据账，决定 Agent 能不能看懂业务。

系统账，决定 Agent 能不能真正动手。

权限与规则账，决定它能不能在正确的边界内做事。

迭代账，决定它上线之后是越来越好，还是交付当天最聪明。

只要这四笔账算清楚，AI 才算真正落了地。

我们也把这套方法整理成了一份《企业 AI 落地四笔账自评表》，可以直接对照公司现状打分。

很多企业一提到“岗位数字化”，第一反应是：

这个岗位无非就是这些 SOP、这些职能。

把 SOP 做成 Skill，安装到 Agent 上，这个职位不就被数字化了吗？

但做过业务的人都知道，一个岗位远不止一张 SOP。

Agent 背后的 Skill，往往会连接到很多业务资料和历史信息。

拿售后 Agent 举例。

客服首先要知道公司有哪些产品，每个产品可能出现什么问题，公司退换货政策是什么。

这意味着，它至少要接入商品知识库、售后政策库，还要接入历史会话数据。

问题来了：

这些数据现在放在哪里？

格式统一吗？

政策内容过期了吗？

如果查出来的历史判例互相冲突，Agent 应该相信哪一份？

光是准备好这套数据基础设施，就可能涉及数据清洗、打标、系统对接、业务规则梳理和权限管理。

这些事情没有做好，装再多个 Agent，也很难跑完端到端的业务流程。

所以，成熟企业往往会先盘数据家底，而不是先问“做几个 Agent”。

先把数据摸清楚。

数据在哪里，是什么格式，由谁维护，都要列出来。

再把口径定下来。

哪一份是权威来源，出现冲突时听谁的，要提前写清楚。

最后才是统一入库。

在建设知识库之前，先把脏数据清洗、打标，把能不能用、该怎么用说清楚。

数据账不清，装再多个 Agent 也跑不完端到端。

很多人对 Agent 的想象，是它能够按照文档和规则树回答问题。

但真正有用的 Agent，不只是给出建议，还要能连接系统去做判断、修改工单、发起退款，并且让每一步都有记录、可追溯。

还是拿售后来举例。

涉及退换货，就得接订单系统。

涉及工单处理，就得接公司的 ERP。

如果使用的是外部采购的 ERP，要确认它有没有开放 API，有没有 MCP 能够提供给 Agent 调用。

如果是企业自建系统，则要看能不能做一套 CLI，让 Agent 更方便地查询和检索。

可以先问自己几个问题：

你的 Agent 现在能修改数据吗？

还是只会在对话框里给建议？

只动嘴、不动手的 Agent，价值上限通常很低。

比较稳妥的做法，是先把接口清单列出来。

哪些系统是 Agent 必须调用的，先全部拉出来。

然后先验连通。

有没有 API 或 MCP？如果没有，先补上，不要硬上。

接着从一个小动作开始。

先把“能修改一个数据”的动作跑通，再逐步铺开。

不会动手的 Agent，只是个会说话的说明书。

作为乙方接单，通常需要把客户需求抽象化，再冻结成一个确定流程，只有这样才能交付。

但矛盾也恰恰在这里。

客户想买的是灵活方案，乙方为了顺利交付，却不得不把它做成一套刚性工作流。

结果是，系统上线之后，员工很快发现：

大量长尾情况，并没有被原来的流程覆盖。

用了几次，觉得不好用，这套工作流就被放在那里。

这也是 RPA、Workflow，以及早年大量低代码、零代码工具进入企业后，没能真正实现业务自动化的一个重要原因。

不是技术一定不好，而是很多工作本来就是柔性的，不能被当成一条刚性流水线来判断。

比如同一个售后问题：

客户情况不同；

历史聊天记录不同；

产品使用情况不同；

最终处理方式也可能不同。

如果把这些情况硬固定下来，员工就只能不断迁就新流程。

流程看起来赢了，人心却输了。

更合理的做法，是先把规则分层。

刚性规则交给系统处理，柔性部分保留人工判断。

权限也要落实到岗位。

谁能看什么，谁能改什么，谁可以发起退款，谁只能提供建议，都要提前定清楚。

同时，还要给长尾情况留下出口。

遇到系统无法判断的问题，可以一键转人工，不能把员工和客户卡死在流程里。

柔性的工作，不能被冻结成一条刚性流水线。

今天的 SOP，半年后还对吗？

把岗位 SOP 做成 Skill，Agent 只能按照既定内容机械执行，它不会因此自动进步。

今天交付时它能跑到什么程度，半年后可能还是这个水平。

甚至因为模型变化、外部环境变化，它的表现还可能出现漂移。

我们过去给客户做 Agent 定制时，就踩过类似的坑。

当时的思路，是把业务拆成 Workflow，让 Agent 按照工作流执行。

工作流搭完，刚开始运行，就发现客户的数据基础很差，端到端流程根本跑不完。

即便有一些对数据依赖不那么强的 Workflow 可以运行，几个月之后，客户团队又可能发生变化。

比如团队外出培训，专家回来之后提出新的判断：

“你原来的 SOP 不对，这里需要优化。”

新需求一来，旧 Workflow 反而变成了累赘。

所以，一个 Agent 有没有未来，不只看它今天能不能工作，还要看它能不能从工作中积累经验。

你可以先自检：

Agent 有执行日志吗？

人工修改了什么，哪一步做错了，能不能沉淀成下一轮优化的数据？

如果这些都没有，Agent 就很难持续变好。

首先，要保留执行日志。

每一步是否正确，人工改了什么，都要记录下来。

其次，要建立评估机制。

把人改过的做法沉淀成新的规则，持续修正 Agent 的表现。

最后，要小步快跑。

让 Agent 跟着业务一起调整，而不是把某一天的流程永久冻结。

不会自己迭代的 Agent，交付那天就是它最聪明的时刻。

四笔账之间，并不是彼此独立的。

它们更像一条连续的链：

数据账，接着是系统账，再接着是权限账，最后是迭代账。

真正的问题，往往不是某一个环节特别差，而是这几个环节没有真正串起来。

有数据，但接不进系统，Agent 就像睁着眼睛却看不见。

接了系统，但权限没有理清，Agent 就可能处处踩雷。

权限理清了，但流程被冻结，长尾问题还是没人处理。

流程跑通了，但没有持续迭代，半年之后也可能和业务脱节。

同样叫“客服 Agent”，能力差别可以非常大。

有的只能按照规则树答题。

有的却能连接系统、修改工单、发起退款，并且让整个过程可追溯。

差别不只是模型能力，很多时候，差的就是这四笔账。

所以，别再只问：

“做几个 Agent 多少钱？”

更应该先问：

“我公司的四笔账，算清了吗？”

企业 AI 升级，说到底不是买几个 Agent，而是建设一套能够持续沉淀能力、不断自我进化的系统。

如果只装 Agent，却不盘数据，再好的模型也跑不完业务。

如果只接系统，却不理清权限，再智能的 Agent 也可能处处踩雷。

如果只冻结流程，却不持续迭代，再顺滑的系统也可能活不过半年。

这里其实存在两种完全不同的落地思路。

一种是旧思路，也就是买标品。

先把流程变成系统，再让员工去适应一套硬性流程。

系统交付之后，项目就算结束。

另一种是新思路，也就是建设企业自己的能力。

先通过培训，让员工拥有个人 Agent，由员工自下而上使用 Skill，覆盖 80%—90% 的提效需求。

再从实际使用中沉淀共性需求，建设统一的知识库、权限和监控体系。

最后，再由 FDE 进入现场，做咨询与系统集成。

员工先拥有持续迭代的能力，企业再逐步沉淀共性流程。

两者的区别在于：

前一种是先把流程固定下来，再要求员工适应。

后一种是先让员工用起来，再从真实需求中沉淀出更好的系统。

工具只是手段，真正重要的是能不能让业务持续运转、持续修正。

不要一开始就铺十个新场景。

先挑一条最痛的流程，把它真正跑通。

先把一件事做成，比把十个新词背熟更有价值。

第一，低估数据治理成本。

很多老板以为“接个库就行”，但实际的数据清洗和打标，工作量往往会被低估数倍。

第二，迷信一次性定制。

如果只是把当前 SOP 冻结后交付，业务一变化，原来的系统就可能变成累赘。

第三，忽视员工习惯。

没有自下而上的真实使用，再好的系统也很难落地。

你的企业 AI，现在走到哪一步了？

还在“按个询价”的阶段？

已经开始算清四笔账？

还是已经在思考，如何让系统形成持续迭代的能力？

喜欢本文，别忘了点击

文末右下角“推荐”

并转发给更多人看哦~

— END —