一个 Agent 多少钱？企业 AI 转型不该这样报价

本文目录

最近，一家电商公司找到我们，希望先从客服、营销和广告三个部门开始做 AI 转型。聊到预算时，采购经理希望我们直接给出三个 Agent 的总价。他此前接触过的一些服务团队，也是按“一个 Agent 多少钱”来报价。

采购需要一个价格口径，这个要求很正常。问题在于，Agent 这个词并不界定交付范围。业务、数据和权限都没有展开，供应商就报出一个单价，卖的多半只是一个可以演示的外壳。

说到底，企业真正需要建设的并不是三个孤立的 Agent，而是一套能够进入真实业务、接受反馈并持续调整的系统能力。

同样叫客服 Agent，背后可能是两套完全不同的系统

差距有多大？看一个例子就清楚了。

最简单的客服 Agent，可以读取产品说明和售后政策，根据文档生成一段回复。它解决的是”找到资料并组织语言”。

一旦要参与售后处理，任务就完全不同了。Agent 需要先确认客户买了什么、订单处于什么状态，再结合产品问题、历史沟通和当前售后政策判断下一步。如果涉及退换货，它还要查询订单、创建或修改工单，必要时发起退款，并把使用过的依据和执行结果留在系统里。

这时，模型还没有成为主要问题，企业自己的业务基础已经先挡在面前：

• 商品知识、售后政策和历史案例分别放在哪里；
• 文件格式是否统一，旧版本是否仍在被使用；
• 两份历史处理记录发生冲突时，以哪一份为准；
• 订单、ERP 和工单系统能否通过受控接口查询和写入；
• 哪些信息可以读取，哪些动作必须由员工批准；
• 执行失败以后，怎样转交人工并保留完整记录。

少了这些条件，Agent 即使能说出一段看起来合理的话，也未必能完成一次售后任务。它可能不知道客户的真实订单，也可能引用过期政策，更不能安全地改变退款或工单状态。

所以，”客服 Agent”这个词本身不具备工作量上的可比性。有人交付的是一个文档问答窗口，有人交付的是一条连接知识、订单、权限、人工确认和系统写回的业务链。名称一样，实施范围天差地别。

真正费时间的部分，藏在 Agent 之前

原因很简单。

安装一个 Agent 框架，或者让一个 Skill 在演示环境里跑通，只占项目的一小部分。更重的工作发生在前面：

业务人员要解释什么结果才算处理完成，哪些规则存在例外；数据团队要清理资料、统一版本和补足字段；技术团队要连接系统、处理接口限制；管理者还要决定权限、审批、审计和责任边界。

这些工作不能由“做几个 Agent”推导出来。一个名称下面需要连接多少数据、多少系统，允许执行到哪一步，才决定了实际成本。

这也是为什么我们此前建议企业在范围明确以后，按一条能够验收的业务工作流采购，而不是只买平台能力。不过，工作流是合适的实施单位，不等于企业一开始就能准确说出该建设哪些工作流。需求还没有经过真实使用验证时，过早定制同样会留下问题。

一次性交付，容易把柔性工作冻成刚性流程

这个矛盾是怎么产生的？

客户希望买到的是一个能处理复杂情况的 Agent。服务商为了确认范围、控制工期和完成验收，却必须把需求抽象成一套确定流程。双方都没做错，项目制交付本身就要求边界稳定。

矛盾出现在真实业务里。客服面对的是具体的人：客户此前说过什么、购买记录如何、这次问题是否属于标准政策，每次都可能不同。营销和广告也会受到产品阶段、渠道反馈和临时活动影响。流程图可以覆盖常见路径，却很难提前列完所有长尾情况。

如果例外只占很小比例，固定工作流很有价值；它能减少重复处理，让结果更容易检查。但有些岗位的核心工作恰恰是处理例外。强行把这种工作固定下来，系统上线后常会出现另一种负担：员工先判断真实情况，再想办法把它塞进系统允许的路径。

大家用过几次，发现大量情况仍要绕开流程处理，这套系统就容易被搁置。问题不一定出在 Agent、RPA 或低代码工具本身，而是团队把一项高变化的工作，当成了可以一次冻结的规则集合。

今天正确的 SOP，几个月后也可能成为累赘

这不是理论推演，我们有亲身体会。

几年前，我们也按照”拆业务、搭工作流、让 Agent 执行”的思路做过定制项目。实际运行很快暴露出两个问题。

第一个是数据基础。演示时可以准备整齐的样本，进入真实流程后，缺字段、旧文档、冲突记录和无法调用的系统会同时出现。Agent 能完成其中几个步骤，却跑不完端到端任务。

第二个是业务变化。有的工作流刚刚稳定运行，客户的业务团队参加了一次专业培训，回来后就调整了原有 SOP。新的方法可能更合理，但已经固化的流程需要重新设计。原本用来提效的系统，反而开始拖慢业务调整。

企业内部会变，外部也会变。模型能力、平台接口和技术框架都在更新。为了弥补当前模型不足而增加的提示词、分支和限制，在模型升级后未必仍有价值；有些补偿规则还会限制新模型原本能够完成的操作。

因此，定制开发并没有失去价值。需要放弃的是”一次交付、长期不变”的预期。

Skill 让 Agent 执行，反馈闭环才让它有机会进步

但只有执行，还不够。

把岗位 SOP 写成 Skill，解决的是”今天按照什么方式做”。它不会自动回答另外几个问题：这次执行是否真的完成了业务任务，员工改了哪些内容，错误发生在知识、规则、工具还是权限，以及下一版应该改什么。

要回答这些问题，企业需要记录 Agent 的真实运行过程：任务从哪里开始，调用过哪些资料和工具，在哪一步停下，最终结果是否被采用，人工修改了什么。高频修改、严重错误和转人工案例，还要沉淀成下一轮评测样本。

这样，知识库、模型、提示词或工作流发生变化后，团队才能检查新版本修好了什么，又破坏了什么。生产运行监控和评测应该从项目早期就开始设计，它们支撑着后续的持续运营。

没有这条闭环，Agent 交付半年后很可能仍停留在交付当天的水平，甚至因为知识和业务环境变化而变差。有了记录、反馈和回归机制，它才有机会逐步适应企业的真实工作。

更合理的顺序，是先形成使用，再建设共性

基于这些教训，我们的思路发生了变化。

我们现在更倾向于把企业 AI 转型分成四个阶段。

第一阶段先让员工学会与个人 Agent 协作，不急着改造整个部门。员工从低风险、结果可核对、变化频繁的工作开始，例如检索资料、整理信息、生成初稿、比较方案和准备跟进事项。关于这一阶段需要建立的能力，可以参考企业 AI 培训的任务拆解方法。

这些需求往往很零散，也带有明显的个人工作习惯。让员工自己通过模板、Skill 或简单工作流解决，比先召开一轮漫长的需求会议更快，也更接近真实情况。企业同时要划清数据和工具边界，避免个人探索绕开必要的安全要求。

第二阶段是观察。经过一段时间使用，团队可以从记录中识别反复出现的问题：哪些资料总被检索，哪些步骤总要复制到另一个系统，哪些人工修改高度相似，哪些任务只属于个人，哪些已经成为跨团队共性。

第三阶段才是系统化。对于高频、价值明确、边界逐渐稳定的需求，企业再建设统一知识库，连接订单、CRM、ERP 或工单系统，设计权限和人工确认，并把工作流纳入正式验收。到了这里，专业咨询、系统集成和定制开发都有明确的投入对象。

第四阶段是持续运营。业务负责人、技术团队和一线员工共同复盘失败与修改，更新知识和规则，用回归评测控制发布风险，再决定扩大、维持还是收缩。系统上线后的具体管理节奏，可以继续参考前 90 天运营路线图。

这条路径并不要求所有企业都从零开始。如果一家公司的流程稳定、数据完整、系统接口成熟，业务负责人也能给出真实样例和验收标准，它完全可以直接进入工作流实施。先培训、后集成不是固定教条，重点是不要在需求尚未被验证时，提前把想象中的岗位 Agent 固化下来。

报价之前，先把五个问题说清楚

回到最实际的问题。

下一次讨论”几个 Agent 一共多少钱”时，企业可以先换一组问题：

1. 要改善的具体业务结果是什么，去哪个系统核验？
2. 完成任务需要哪些知识、数据、接口和权限？
3. 哪些步骤规则稳定，哪些情况依赖人的判断？
4. 什么结果可以接受，失败时由谁接管？
5. 上线后由谁收集反馈、维护评测和发布更新？

这些问题明确以后，供应商才能判断应该提供培训、场景诊断、通用工具、定制工作流、系统集成，还是持续运营服务。企业也才能分辨，报价里包含的是一个演示界面，还是一条能够进入真实业务的执行链。

“一个 Agent 多少钱”并不是一个永远不能问的问题，只是它通常问得太早。先弄清企业已经具备什么、业务还缺什么，再讨论建设范围和价格。企业最终需要沉淀的，不是 Agent 的数量，而是发现需求、接入系统、控制风险和持续改进的能力。