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

OPC推动企业AI落地时，最容易被一种看似合理的交付形态吸引，那就是为企业定制Agent。

企业也很容易用同样的方式理解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很容易变成只能说话却无法真正办事的工具。

它能回答问题，却完成不了端到端任务；能引用文档，却不知道文档是否最新；能生成建议，却不能判断建议能否在当前系统中执行。

系统接入同样如此。

客服Agent需要查询订单、修改工单和发起退款；销售Agent需要查询CRM、更新客户状态并生成跟进记录；运营Agent则要查看数据后台、拉取报表以及触发活动配置。

但企业已有系统不一定是为Agent而设计。

部分外采系统未开放API，部分自建系统的接口文档并不完整，有些后台只能由人工点击，还有些权限分散掌握在不同部门。

此外，一些动作不能被随意自动化。

部分数据只能查看而不可修改，部分动作必须审批；某些操作一旦出错，还会引发财务、合规或客户关系风险。

因此，Agent并不是“连接系统”后就算完成。

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

这些问题若没有答案，Agent便无法真正接管流程。

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

能够回答问题的Agent容易实现，真正困难的是能安全执行动作的Agent。

客户要购买灵活性，乙方却不得不交付刚性Workflow

企业流程本身也不会始终保持稳定。

许多企业希望建设Agent，正因为业务中存在大量柔性问题。

面对同一种客户咨询，购买记录不同，处理方法也不同；同一个售后问题，因为订单状态、历史沟通和客户等级各异，结果同样会有差别。

这些问题原本就难以被一个固定流程轻松覆盖。

然而，为了报价、开发与验收，定制Agent必须将这些柔性问题拆解为确定流程。

矛盾因此产生。

客户购买的是灵活性，乙方为了完成交付，却只能将其制作为刚性Workflow。

刚上线时，这套方案也许是正确的。

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

可是三个月以后呢？

业务政策、团队负责人、平台规则和系统接口都可能发生变化，模型能力也可能升级。员工还可能发现，这套流程没有覆盖真实工作中的大部分例外。

此时，原先定制的Workflow便开始成为负担。

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

根本原因是大量业务本来就具有柔性。

若强行将柔性业务冻结成刚性流程，最后只能让员工迁就系统。

企业定制Agent也很容易掉入同样的陷阱。

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

所以，定制Agent的风险不在于“今天无法运行”。

更普遍的风险是：今天运行正常，几个月后便不再好用。

员工尚未建立与Agent协作的习惯

企业AI落地中还有一个常被忽视的问题：员工不一定已经做好与Agent协作的准备。

企业采购Agent时，往往默认员工自然会使用。

实际情况却并非如此。

员工是否会把任务交给Agent？能否写明上下文？是否懂得判断Agent结果可不可用？会不会反馈错误？能否把临时技巧沉淀成Skill？

这些能力不会在Agent安装完成后自然出现。

我在现场看到的更多情况是：系统虽然上线，员工仍习惯在群里向同事提问；有人只把Agent当搜索框，简单问一句“帮我看下这个客户怎么处理”；也有人输入整段业务背景，却在收到结果后不知道如何判断正误。

问题并不在员工身上。

因为他们此前没有接受过这种训练。

员工若尚未形成使用习惯，企业一开始就定制Agent，很容易出现两类情况。

一类是员工拒绝使用，认为它麻烦、不可控，还不如手工处理迅速。

另一类是员工滥用：把不应自动化的任务交给Agent，把风险判断交给模型，既不提供充分上下文，也不检查输出。

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

因此，企业真正需要的并不是先采购一个“非常完整的Agent”。

更合理的是让员工先在低风险、高频且变化快的场景中学习与Agent协作。

例如整理资料、生成初稿、处理表格、总结会议、拆分任务和开展初步分析。

组织内部积累真实使用记录后，才能知道哪些需求确实高频、哪些流程真正稳定，以及哪些能力值得沉淀为企业级能力。

企业AI落地并非始于Agent上线，而是始于员工改变工作方式。

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

上述问题无论企业还是OPC都无法避开。

需求多元、数据复杂、系统难接、权限敏感、流程变化，而且员工习惯尚未形成。

这些变量相互叠加，决定了OPC难以把企业定制Agent打造为标准产品。

因为不同企业在需求、数据、系统、权限、流程和员工习惯上都不相同。

为A企业完成项目后再服务B企业，真正困难的部分几乎仍要重新开展。

真正可以复用的，只有方法论、脚手架以及部分组件。

这意味着交付成本高、复用率低、周期不可控，而且后期维护压力巨大。

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

若成本转由客户承担，客单价便会变得很高。

而愿意在AI落地初期就投入高预算的企业，本来就为数不多。

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

“先做一个试试看。”
“能不能先以较低成本试试。”
“我们内部还没有想明白，但你可以先给出方案。”

于是，定制Agent很容易成为让双方都感到不适的交付形态。

企业认为价格高且效果不确定，OPC则觉得交付过重又无法产生复利。

FDE的出现也在印证同一件事。

假如标准Agent足以完成企业AI落地，就不会需要FDE，企业直接购买即可。

然而，Agent落地并没有这么简单。

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

客户以为自己需要自动化，实际更需要的是可控、可审计以及随时能够人工接管。

这些判断无法由一个标准Agent模板解决。

FDE真正承担的工作，是深入现场，把业务、系统、数据、流程、权限以及员工使用习惯连接起来。

他需要判断哪些是真需求、哪些只是老板的设想；哪些流程足够稳定、哪些暂时不应固化；哪些数据值得治理、哪些可以先不处理；哪些系统必须连接、哪些接入后也没有价值。

FDE之所以存在，本身便说明企业AI落地不是标准软件销售，而属于现场工程。

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

问题并非单个项目无法完成。

问题是将它作为OPC开展企业AI落地的主要交付形态，很难长期成立。

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

我并不是说企业不能建设Agent，也不认为定制开发没有价值。

我反对的是OPC刚开始就将“定制Agent”作为企业AI落地的主要交付形态。

因为这条道路很容易把自己拖进高成本、低复利和重交付的困境。

更合理的实施顺序应当反过来。

一开始不要询问：“要做几个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？哪些流程稳定到值得沉淀？哪些数据值得治理？哪些权限与审核机制必须建立？组织是否具备持续反馈和迭代能力？

Agent并不是企业AI落地的最终交付物。

它只是组织学习用AI改造自身的入口。

真正的企业AI落地，并非购买几个Agent。

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

持续识别真实场景、沉淀有效流程，并推动AI系统与业务共同演进。

登录查看剩余 70% 内容