OPC 交付企业定制 Agent，根本难以走通

企业AI落地是否误把“定制Agent”当作捷径？文章分析这条路径难以形成规模化生意的原因，并拆解三大现实障碍及破局方向。
核心内容：
1. 将定制Agent作为主要交付形态，在商业上难以成立
2. 需求多元、数据复杂等现实因素：企业AI落地的核心问题
3. AI落地的合理思路：以场景为单位，而不是以岗位为单位

为企业定制 Agent，是一种看似合理且最容易吸引OPC 的交付形态；企业 AI 落地往往因此从这里切入。

企业同样很容易用这种方式理解 AI 落地。

“我们希望开发一个客服 Agent。”
“我们希望开发一个销售 Agent。”
“我们希望开发一个运营 Agent。”
“我们希望开发一个广告投放 Agent。”

这些需求听上去十分明确。

接入企业知识库和业务系统后，再按部门配置 Agent、按岗位设置 Workflow，似乎便算启动了企业 AI 落地。

然而，服务过几家企业后，我越发确信这条路很难真正走通。

原因不是 Agent 无法开发，也不是 OPC 能力不足，更不是企业拒绝配合。

我也并非认为所有 Agent 定制都毫无价值。

问题真正出在：一旦 OPC 将企业定制 Agent 作为主要交付形态，这门生意便很难实现长期维护、规模化和可复利。

因为在企业 AI 落地过程中，双方都无法避开几个现实问题。

尚未形成的是组织使用习惯，难以稳定的是业务流程；与此同时，企业还面对高度多元的需求和十分复杂的数据基础。

定制 Agent 最初看似是产品交付，但若前述问题尚未解决，最终往往会成为一次性工程。

企业需求并非一个岗位对应一张 SOP

许多人理解企业 Agent 时，会本能地将岗位与 Agent 直接对应。

客服岗位对应客服 Agent，销售岗位对应销售 Agent，运营岗位对应运营 Agent。

这样的映射听起来十分顺畅。

进入企业现场才会看到，SOP 一张并不能代表一个岗位。

同为客服，有些企业重点处理退款退货，有些负责合同履约，有些主要应对渠道投诉，还有些需要兼顾部分销售转化。

同为运营，有人负责内容，有人组织活动，有人开展用户分层，也有人关注数据和供应链。

因此，企业需求并非“开发一个岗位 Agent”那么简单。

应先弄清这个岗位在该公司究竟负责哪些任务，再判断哪些任务高频、低风险且能自动化，哪些仅能辅助决策，哪些必须人工审核，以及哪些任务出错后会波及客户关系、合同履约或财务责任。

若不把这些问题拆解清楚，开发出的 Agent 只会是一个泛化工具壳。

它表面覆盖整个岗位，实际上没有深入任何具体场景。

不少企业最初会说：“我们先开发一个客服 Agent 就行。”

然而，客服 Agent 具体要完成什么？

要做的是判断售后政策还是依据知识库答疑？要修改工单、发起退款还是查询订单状态？要安抚客户情绪，还是在复杂情形下识别必须转人工的时机？

这些任务对应的交付难度完全不同。

我因而越来越确信：真实场景应当先被拆解，企业 AI 落地并不是将整个岗位 Agent 化。

AI 落地以场景为单位，而岗位描述的是组织结构。

数据与系统并非连接后即可使用

数据与系统，是企业建设 Agent 时第二道无法回避的关口。

很多企业谈到 Agent 时都会表示：我们有知识库、大量文档、历史聊天记录，也拥有业务系统数据。

然而，拥有数据不代表 Agent 可以使用。

飞书文档、Excel、本地文件、系统后台和群聊记录混在各处，老员工脑中甚至保留着很多关键经验。同时，知识库可能分散，政策文档可能失效，历史记录可能矛盾，表格字段也可能无人维护。

Agent 面临的更大麻烦，在于任务并非只有“读数据”。

它还必须判断哪份数据可信、哪份已经更新，以及哪条规则拥有更高优先级。

以售后场景为例，Agent 回答退款问题时，要知道商品信息的位置、退换货政策应采用哪个版本、历史判例冲突时相信哪一方、从哪里查询订单状态、如何控制退款权限，以及客户沟通过程是否需要留痕。

这些问题无法仅凭接入一个知识库解决。

数据基础若未准备妥当，Agent 很容易成为一个只会说话却无法真正办事的工具。

它可以回答，却不能完成端到端任务；可以引用文档，却无法确认文档是否最新；可以提出建议，却不能判断该建议能否在当前系统执行。

系统接入面临的问题也是如此。

查 CRM、更新客户状态和生成跟进记录，是销售 Agent 的任务；查订单、改工单和发起退款，由客服 Agent 执行；看数据后台、拉报表及触发活动配置，则交给运营 Agent。

企业已有系统在设计时，却不一定考虑过Agent。

外采系统有的未开放 API，自建系统有的缺少完整接口文档；另有一些后台只能手动点击，还有一些权限分别掌握在不同部门手中。

此外，某些动作不能任意自动化。

财务、合规或客户关系风险可能由错误操作引发；此外，部分数据只许查看，部分动作必须先获审批。

所以，Agent 并不是“连接系统”后便宣告完成。

还必须设计它可以查询和修改什么、何时需要人工确认、由谁审批、失败后如何回滚、各步骤怎样留痕，以及出现问题时如何划分责任。

Agent 能否真正接管流程，取决于这些问题是否已有答案。

它至多只能充当建议助手。

困难之处不在制作回答问题的 Agent，而在让Agent安全地执行动作。

刚性 Workflow 被迫由乙方交付，客户购买的却是灵活性

企业内部流程也不会始终保持稳定。

许多企业希望开发 Agent，恰恰是因为业务中存在大量柔性问题。

同样的客户咨询，会因购买记录不同而采用不同处理方式；同样的售后问题，也会因订单状态、历史沟通和客户等级不同而产生不同结果。

这类问题本来就无法被一个固定流程轻易覆盖。

然而，为了完成报价、开发和验收，定制 Agent 又必须把柔性问题拆解成确定流程。

矛盾由此产生。

灵活性是客户的购买目标；为了完成交付，乙方却只能将其固化为Workflow。

在正式上线的那一刻，它或许是正确的。

因为调研刚完成，SOP 刚与客户确认，流程也刚刚跑通。

然而，三个月后又会怎样？

业务政策、平台规则和系统接口都可能变化，团队负责人可能更换，模型能力也可能升级。员工还可能发现，该流程并未覆盖真实工作中的大多数例外情况。

原先定制的那套 Workflow，到这时反而成了负担。

过去，许多 RPA、低代码和零代码工具进入企业后，并未真正实现大量业务自动化，原因并不是这些技术完全不可用。

真正的原因是，大量业务本身就具有柔性。

若强行把柔性业务冻结为刚性流程，最终只能让员工反过来迁就系统。

企业定制 Agent 同样很容易落入这个陷阱。

上线时它看似实现了“智能化”，但如果底层仍是冻结后的刚性流程，最终也会成为另一个必须维护的旧系统。

因此，定制 Agent 的风险并不在于“今天无法运行”。

更普遍的风险在于：今天可以运行，几个月后却变得不好用。

员工尚未养成与 Agent 协作的习惯

员工是否具备同 Agent 协作的准备，常被企业 AI 落地忽略。

默认员工已经会用，是很多企业采购 Agent 时的前提。

但真实情况并非如此。

能否把任务交给 Agent，并把上下文交代清楚？面对 Agent 的结果，员工能否判断是否可用并反馈错误？个人积累的临时技巧，又能否沉淀为 Skill？

这些能力不会在安装 Agent 后自然形成。

我在现场更常看到的是：系统虽已上线，员工仍习惯在群里向同事提问；有人把 Agent 当搜索框，只说一句“帮我看下这个客户怎么处理”；也有人一次塞入整段业务背景，得到结果后却不知如何判断对错。

这并不是员工自身的问题。

因为他们此前从未接受过相应训练。

员工尚未形成使用习惯时，直接开发企业级定制 Agent，通常容易出现两类情况。

第一类是员工拒绝使用，认为它麻烦、不可控，还不如自己手动处理更快。

第二类是员工错误使用，把不应自动化的任务交给 Agent，让模型承担风险判断，既不提供充分上下文，也不核查输出结果。

无论哪一种，都会导致 Agent 落地失败。

因此，先采购一个“很完整的 Agent”并非企业真正所需。

更应先从低风险、高频且快速变化的场景入手，使员工掌握同 Agent 协作的方法。

处理表格、拆解任务、整理资料、总结会议、生成初稿以及进行初步分析，都属于这类场景。

组织内部形成真实使用记录后，才能识别哪些需求确实高频、哪些流程真正稳定，以及哪些能力值得进行企业级沉淀。

员工工作方式的改变，才标志着企业 AI 落地开始；Agent 上线并不是起点。

定制 Agent 最终容易成为一次性工程

上述问题是企业与 OPC 都无法绕开的。

员工习惯尚未形成，流程持续变化且权限敏感；同时还存在需求多元、数据复杂、系统难接的问题。

多项变量叠加后，OPC 很难把企业定制 Agent 打造成标准产品。

需求、数据和系统，以及权限、流程与员工习惯，在不同企业中均有差异。

为 A 企业完成项目后，转向 B 企业时，真正困难的工作几乎仍须从头再来。

能够复用的仅有方法论、脚手架以及部分组件。

这意味着交付成本较高、复用率偏低、周期难以控制，后期维护压力也很大。

若由 OPC 自行承担冷启动成本，其现金流将受到拖累。

若把成本交给客户承担，客单价就会明显升高。

但愿意在起步阶段便为 AI 落地投入高预算的企业本来就很少。

多数企业仍处于试探阶段。

“先开发一个看看效果。”
“能否先降低费用试一试。”
“我们内部尚未想清楚，但你先提供一份方案。”

于是，定制 Agent 很容易成为一种让双方都不满意的交付形态。

企业认为价格高且效果不确定，OPC 则认为交付太重又无法形成复利。

FDE 的出现也反映了同一问题。

假如企业 AI 落地确实能靠标准 Agent 完成，那么 FDE 就没有存在的必要，企业直接购买即可。

但 Agent 落地远没有这么简单。

老板描述的需求不同于一线的真实问题，部门负责人提供的 SOP 也不同于员工的实际做法。系统文档可能很完整，接口权限却未必能够取得；知识库看似庞大，真正可用的内容可能很少。

可控、可审计和随时由人工接管，才是客户实际需要的；他们以为要买的则是自动化。

这些判断无法依靠一个标准 Agent 模板完成。

业务、系统、数据、流程、权限及员工使用习惯，需要由FDE 进入现场后串联起来，这才是其真正工作。

他必须判断哪些属于真实需求、哪些只是老板的想象；哪些流程已经稳定、哪些不应在此时固化；哪些数据值得治理、哪些暂时不要触碰；哪些系统必须接入、哪些即使接入也没有价值。

FDE 的存在本身便说明，企业 AI 落地属于现场工程，而非标准软件售卖。

这正是我认为它根本行不通的原因。

并不是单个项目无法完成。

而是把它作为 OPC 推动企业 AI 落地的主要交付形态后，这种模式难以长期成立。

OPC 真正应该销售的并非定制 Agent

我不是否认企业可以开发 Agent，也不是否认定制开发具有价值。

我的反对点在于：企业 AI 落地刚起步，OPC 便将主要交付形态设为“定制 Agent”。

因为这条道路极易让自己陷入高成本、低复利和重交付的困境。

更合理的推进顺序应当反过来。

起步时不该先问“客服 Agent 多少钱？”“销售 Agent 多少钱？”或“要做几个 Agent？”

首先应查明：员工是否已用 AI 改变自己的工作，真正高频出现的是哪些场景，哪些流程得到过反复验证；还要判断哪些数据值得治理、哪些权限必须系统化，以及哪些任务适合个人 Agent、哪些应沉淀为企业级能力。

企业 AI 落地的起点，在我看来应当是个人使用。

先为员工提供个人 Agent，让他们用于低风险、高频且变化快的日常任务，并先形成真实的使用记录。

之后，再从这些真实记录中寻找共性需求。

要观察反复发生的需求和真正稳定的流程，判断值得统一治理的数据与需要系统化的权限，并找出值得由个人能力沉淀为组织能力的场景。

只有进入这个阶段，企业级 Agent、知识库、Workflow、数据接口、权限体系、监控与 Evaluation 的建设才会更稳。

OPC 到这时所交付的，便已超出“一次性 Agent”。

它交付的是企业从个人 AI 使用逐渐形成组织 AI 能力的完整过程。

因此，OPC 真正应该形成复利的并非某个定制 Agent 成品。

这种成品很难在不同企业之间复用。

可持续复利来自方法论和基础设施：识别企业中适合 AI 化的场景，拆分真实需求，训练员工使用个人 Agent，从使用记录提炼共性流程，建立权限、审核、追溯及人工接管机制，再形成 Evaluation 与反馈闭环。

不同行业和不同企业的业务细节都会变化。

可以持续复用并改进的，是AI 落地所需的沉淀方法、判断框架、推进节奏与风险识别。

所以，OPC 不应把希望寄托在：

“我开发一个 Agent，再将它卖给许多企业。”

真正应当投入能力的是：

我能更迅速地判断一家企业哪些部分适合 AI 化、哪些目前不该实施，以及哪些能力值得沉淀。

与销售一个定制 Agent 相比，这种模式更接近长期生意。

企业同样不应起步就采购定制 Agent

无论OPC，还是希望推动AI 落地的企业，都是这篇文章的读者。

短期能够演示却长期难以维护，可能正是企业起步即采购定制 Agent 后得到的系统。

OPC 若起步就销售定制 Agent，也容易把自己拖入高成本、低复利和重交付的项目困境。

企业 AI 落地真正应该提出的问题不是：

“开发一个 Agent 需要多少钱？”

真正该问的是：已有哪批员工在使用 AI，哪些任务正反复交给 AI，哪些流程足够稳定且值得沉淀；同时还要明确哪些数据值得治理、哪些权限与审核机制必须建立，以及组织能否持续反馈和迭代。

企业 AI 落地并不以交付Agent为终点。

组织借此开始学习如何用AI 改变自己，它只是一个入口。

采购几个 Agent，并不等于真正实现企业 AI 落地。

而是让企业逐步形成一种能力：

让 AI 系统与业务共同进化，需要持续识别真实场景，并将有效流程沉淀下来。

登录查看剩余 70% 内容