OPC 做企业定制 Agent，很难走得通

把“定制Agent”误当企业AI落地捷径是否可行？规模化生意难以形成，三大现实障碍与破局方向需要重新审视。
核心内容：
1. 商业层面为何难以把定制Agent作为主要交付形态
2. 需求多元、数据复杂等因素构成企业AI落地的现实核心
3. AI应按场景落地，岗位不应成为实施单位

给企业定制 Agent，看似是一种合理的交付形态，也最容易吸引尝试推动企业 AI 落地的 OPC。

企业同样很容易用这种方式理解 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，定制开发也有价值，这两点并不是我要否定的。

让我反对的是这种起手方式：OPC 直接将“定制 Agent”设为企业 AI 落地的主要交付形态。

因为这条路径很容易让自身陷入高成本、低复利和重交付的困境。

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

起步阶段应避开这些提问：“客服 Agent 多少钱？”“销售 Agent 多少钱？”“要做几个 Agent？”

应先了解哪些流程已被反复验证、哪些场景确实高频出现，以及员工是否已用 AI 改造自己的工作；还要判断哪些权限必须系统化、哪些数据值得治理，哪些任务宜交给个人 Agent，又有哪些值得沉淀为企业级能力。

从个人使用起步，才是我对企业 AI 落地路径的判断。

让员工先拥有个人 Agent，并在高频、低风险且变化快的日常任务中实际使用；在此基础上，真实使用记录才能逐步形成。

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

从个人能力沉淀为组织能力的场景是否值得，取决于权限是否需要系统化、数据是否值得统一治理、流程是否真正稳定，以及需求是否反复出现。

企业级 Agent、知识库、Workflow、数据接口、权限体系、监控与 Evaluation，等到这一阶段再建设，实施才更稳。

“一次性 Agent”便不再是此时 OPC 所交付的内容。

企业如何由个人 AI 使用逐步形成组织 AI 能力，才是这套交付所包含的过程。

某个定制 Agent 成品，并非 OPC 真正能够持续复利的对象。

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

方法论与基础设施才有真正的复利价值：从使用记录提炼共性流程，训练员工使用个人 Agent，拆解真实需求，判断企业中适合 AI 化的场景；同时处理人工接管、追溯、审核和权限，并建立反馈闭环与 Evaluation。

行业不同、企业不同，业务细节自然会变化。

可以持续优化并反复复用的，是沉淀方法、风险识别、推进节奏以及 AI 落地的判断框架。

因此，OPC 不应把希望寄托在：

“卖给很多企业之前，我先做出一个 Agent。”

真正应该投入的能力是：

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

相较销售定制 Agent，这种能力更接近一门长期生意。

企业也不应从采购定制 Agent 起步

这些内容既写给 OPC，也写给希望推动 AI 落地的企业。

短期可以演示、长期难以维护的系统，往往正是企业起步便采购定制 Agent 后容易得到的结果。

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

企业 AI 落地真正需要追问的并不是：

“建设一个 Agent 需要多少钱？”

而应把问题换成：组织是否有持续反馈和迭代的能力？必须建立哪些权限与审核机制？哪些数据值得治理，哪些流程已经稳定到值得沉淀？还要找出哪些任务正被反复交给 AI，以及哪些员工已经开始使用 AI。

企业 AI 落地并不会在交付 Agent 时结束。

组织由此进入用 AI 改造自身的学习过程，它只承担入口作用。

采购几个 Agent，不能代表企业 AI 已经真正落地。

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

让 AI 系统与业务共同进化，需要先持续识别真实场景，再把得到验证的流程沉淀下来。

登录查看剩余 70% 内容