OPC 做企业定制 Agent，根本行不通

OPC 做企业 AI 落地，最容易被一种看起来很合理的交付形态吸引：给企业定制 Agent。

企业也很容易这样理解 AI 落地。

“我们想做一个客服 Agent。”
“我们想做一个销售 Agent。”
“我们想做一个运营 Agent。”
“我们想做一个广告投放 Agent。”

听起来很清楚。

一个部门一个 Agent，一个岗位一套 Workflow，再接上企业知识库和业务系统，好像企业 AI 落地就开始了。

但我服务过几家企业之后，越来越确定，这条路很难走通。

不是 Agent 做不出来，也不是 OPC 没能力，更不是企业不愿意配合。

我也不是说所有 Agent 定制都没有价值。

真正的问题是：如果 OPC 把企业定制 Agent 当成主要交付形态，它很难成为一门可复利、可规模化、可长期维护的生意。

因为企业 AI 落地本身，有几个双方都绕不开的现实问题。

企业需求太多元，数据基础太复杂，业务流程太不稳定，组织使用习惯也还没形成。

这些问题没处理之前，定制 Agent 看起来像产品交付，最后很容易变成一次性工程。

很多人理解企业 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 才难。

企业流程本身也不是稳定不变的。

很多企业想做 Agent，正是因为业务里有大量柔性问题。

同一个客户咨询，背后的购买记录不同，处理方式不同。同一个售后问题，不同订单状态、不同历史沟通、不同客户等级，结果也不同。

这些问题原本就不是一个固定流程能轻松覆盖的。

但定制 Agent 为了报价、开发和验收，就必须把这些柔性问题拆成确定流程。

于是矛盾就出现了。

客户想买的是灵活性。乙方为了交付，只能把它做成刚性 Workflow。

上线那一刻，它可能是对的。

因为你刚刚调研完，刚刚和客户确认完 SOP，刚刚把流程跑通。

但三个月后呢？

业务政策可能变了，团队负责人可能换了，平台规则可能调整了，模型能力可能升级了，系统接口可能改了。员工也可能发现，这套流程没有覆盖真实工作里的大部分例外情况。

这时候，原来那套定制 Workflow 就开始变成负担。

以前很多 RPA、低代码、零代码工具进入企业后，没有真正把大量业务自动化，不是因为这些技术完全不行。

而是因为大量业务本来就是柔性的。

你硬要把柔性业务冻结成刚性流程，最后就是让员工迁就系统。

企业定制 Agent 也很容易踩进同一个坑。

它上线时看起来像“智能化”。但如果底层还是一套冻结后的刚性流程，它最终还是会变成另一个需要维护的旧系统。

所以定制 Agent 的风险不是“今天跑不通”。

更常见的风险是：今天能跑，过几个月就不好用了。

企业 AI 落地还有一个经常被忽略的问题：员工未必已经准备好和 Agent 协作。

很多企业采购 Agent 时，会默认员工会用。

但实际不是这样。

员工会不会把任务交给 Agent？会不会写清楚上下文？会不会判断 Agent 的结果能不能用？会不会反馈错误？会不会把自己的临时技巧沉淀成 Skill？

这些都不是装完 Agent 就自然发生的。

我在现场看到更多的情况是：系统上线了，员工还是习惯把问题丢到群里问同事；有的人把 Agent 当搜索框用，只问一句“帮我看下这个客户怎么处理”；还有的人把一整段业务背景塞进去，拿到结果以后也不知道该怎么判断对不对。

这不是员工的问题。

他们原来就没有接受过这种训练。

如果员工还没有形成使用习惯，一上来就做企业级定制 Agent，很容易出现两种情况。

一种是员工不用，觉得麻烦、不可控、不如自己手动快。

另一种是员工乱用，把不该自动化的任务交给 Agent，把风险判断交给模型，不提供足够上下文，也不检查输出结果。

这两种情况都会让 Agent 落地失败。

所以企业真正需要的不是先买一个“很完整的 Agent”。

而是先让员工在低风险、高频、变化快的场景里学会和 Agent 协作。

比如整理资料、生成初稿、处理表格、总结会议、拆解任务、做初步分析。

等组织内部有了真实使用记录，才知道哪些需求真的高频，哪些流程真的稳定，哪些能力值得企业级沉淀。

企业 AI 落地不是从 Agent 上线开始，而是从员工开始改变工作方式开始。

前面这些问题，企业和 OPC 都绕不开。

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

这些变量叠在一起，就决定了 OPC 很难把企业定制 Agent 做成标准产品。

因为每家企业的需求、数据、系统、权限、流程和员工习惯都不一样。

你给 A 企业做完，换到 B 企业，真正困难的部分几乎都要重来。

能复用的只有方法论、脚手架和部分组件。

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

如果 OPC 自己承担冷启动成本，现金流会被拖住。

如果让客户承担，客单价就会很高。

但愿意一上来就为 AI 落地投入高预算的企业，本来就不多。

大多数企业还在试探阶段。

“先做一个看看。”
“能不能先便宜点试试。”
“我们内部还没想清楚，但你先给个方案。”

这就导致定制 Agent 很容易变成一个双方都不舒服的交付形态。

企业觉得贵，还不确定效果。OPC 觉得重，还无法复利。

FDE 的出现，也是在说明同一件事。

如果企业 AI 落地真的能靠标准 Agent 完成，就不需要 FDE。企业直接买就好了。

但 Agent 落地不是这么简单。

老板说的需求，和一线真实问题不一样。部门负责人给的 SOP，和员工真实执行方式不一样。系统文档写得很完整，但接口权限可能根本拿不到。知识库看起来很多，真正能用的内容可能很少。

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

这些判断都不是一个标准 Agent 模板能解决的。

FDE 真正做的，是进入现场，把业务、系统、数据、流程、权限和员工使用习惯串起来。

他要判断哪些需求是真需求，哪些只是老板的想象；哪些流程已经稳定，哪些现在不该固化；哪些数据值得治理，哪些数据先不要碰；哪些系统必须接，哪些系统接了也没价值。

FDE 的存在，本身就说明企业 AI 落地不是标准软件售卖，而是现场工程。

这就是我说它根本行不通的原因。

不是单个项目做不出来。

而是如果把它当成 OPC 做企业 AI 落地的主交付形态，它很难长期成立。

我不是说企业不能做 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 更接近长期生意。

这篇文章写给 OPC，也写给想做 AI 落地的企业。

企业如果一上来就采购定制 Agent，很容易买到一个短期可演示、长期难维护的系统。

OPC 如果一上来就卖定制 Agent，也很容易把自己拖进高成本、低复利、重交付的项目泥潭。

企业 AI 落地真正该问的，不是：

“做一个 Agent 多少钱？”

而是：我们有哪些员工已经在用 AI？哪些任务正在被反复交给 AI？哪些流程已经稳定到值得沉淀？哪些数据值得治理？哪些权限和审核机制必须建立？组织有没有持续反馈和迭代的能力？

Agent 不是企业 AI 落地的交付终点。

它只是组织开始学会用 AI 改造自己的入口。

真正的企业 AI 落地，不是采购几个 Agent。

而是让企业长出一种能力：

不断发现真实场景，沉淀有效流程，并让 AI 系统随着业务一起进化。