央企OPC的玩法和困境：让Agent能跑，还要改造费？

前不久，和两个央企管理层吃晚饭，

一个集团行政管理，一个科技子公司CTO。

小海鲜很有滋味，聊得也挺有意思。

一场听下来，感慨大企业内部真复杂。

有一个小细节，我印象特别深。

那个做行政管理的哥们，突然很认真地问CTO：

“我们全集团现在到底有几个模型平台？

我看到是两个？为什么是两个？”

CTO愣了一下，也没打官腔，直接说了一句：

“跟你说实话，我也不知道。”

桌上一下子就安静了一秒。

然后大家一起大笑出来。

是有笑点，但那个笑，更多是一种——

你懂的，那种有点无奈的笑。

这就是中国大企业上AI的真实现场。

不是技术问题，是组织问题。

模型再强，也要落地组织里。

从去年到今年，新需求很明显：

如何把Agent真正，大规模用起来？

尤其，龙虾热之后，领导态度也很积极。

龙虾给全世界科普了Agent，

这是它载入科技史册的功劳。

最近，还流行“OPC试点方案”。

讲真，不少企业小范围的业务还都用上Agent了。龙虾给你吐个“日报”方案嘎嘎快。

这都是我亲眼所见的，可惜文件不能分享出来，

毕竟，这是企业内部的东西。

企业级Agent市场怎么发展，

我也想一探究竟。

市场上，Demo很多，尝鲜的玩意也不少。

企业有没有准备好Agent大规模上线？

我的答案是，没有。

有好几个方面，其中一个是接口改造。

这是啥事呢？

我们公司有几十上百个老系统，

从设计上就没考虑被程序调用。

要让Agent畅通无阻，

我得把这些老系统全部改造一遍，

加API，统一身份，做权限穿透，过合规审查。

这是个一两年，上千万，跨部门的大项目，

你说的"用Agent"听起来很轻松，

实际上，是先做个企业级数字化转型工程。

所以，不是Agent不行，

是企业的底子还没准备好。

GUI界面是给人点的，

CLI是给人敲命令的，

API是给程序调的，

还得再加一句，完全不用人。

所以，天然适合Agent。

企业系统想被Agent用，没有第二条路，

必须有API（或者在API之上再包一层MCP）。

MCP严格说还不是工业标准，

它是Anthropic主推的协议，还在抢标准的阶段。

那用模型公司各自的格式，听上去是不是更乱。

不是协议，是各家SDK里的调用约定。

早期大家都这么搞，

后来Anthropic推MCP想统一，

但OpenAI等家短期内不会放弃自己的格式。

什么CLI改造之类的，

大家反正都口头混着用这些术语，

意思是"让系统能被AI调用"，

但具体怎么调用不清晰。

企业级AI落地缺的是"API改造"，

给老系统加程序调用入口。

他们很多人说的CLI改造，

这是这件事的一种特殊形态，

主要服务Coding Agent，

但不是主战场。

核心是，我们的老系统得加程序入口让AI能调。

为什么企业需要一场大改造？

企业里那些OA，ERP，

CRM系统，原本是给人用的，

人打开界面，点按钮，填表单，提交。

系统不知道也不在乎"另一个程序怎么调它"。

要让Agent能用这些系统，

必须先把这些系统改造成，

"程序能调用的样子"。

不少阿里小哥哥管这个叫"AI亲和改造"。

企业现状是，“内部还没改造完”

它有OA，有ERP，有CRM，

有自己的身份认证，

这些都是已经跑了5年以上的系统。

让企业为了用一个新Agent平台，

把这些系统全部对接进来，

等于让企业自己给自己当系统集成商。

为什么会这样？

第一，当年设计的时候只考虑给人用，

员工登录就够了，

"程序自动调用"不在原始需求里。

第二，后续加API是补丁式的。

剩下大量功能API不暴露。

第三，API文档不存在，又可能十年没更新。

我看工作量是把原有IT系统重新梳理一遍。

所以，在企业里把Agent跑起来，

其实不是“接个模型”这么简单，

没有程序入口，

要么用UI自动化去“模拟人点界面”，

但极不稳定，要么自己补一层API，

相当于在老系统旁边再做一套可调用层。

就算原本有API，也不统一，

每个系统的格式，鉴权，数据结构都不一样，

还得一层层做转换，

让Agent能用同一种方式调用。

接下来是身份问题，Agent不是自己干活，

是替具体的人干活，

这个人在不同系统里的身份，权限都要能对得上，

这一层如果不打通，系统就用不起来。

最后是数据流向，Agent一跑起来，

数据会在多个系统之间来回流动，

哪些能进模型，哪些要脱敏，哪些必须留痕审计，

都要在代码里一条条管住。

这几件事叠在一起，

本质上不是“接个AI”这么简单。

上周，采访阿里云JVS Crew技术负责人安陈，

他说，现在大部分的公司，

可能没把Agent真正是大规模用起来，

还就在跑个Demo或者老板花钱让去尝鲜的阶段。

慢慢就会发现，Agent任务的时长，

首字回复的时间，它使用token的效率，

都是非常致命的问题。

一个问题我能用100个token给你解决掉，

企业就不希望你烧1000个token，

因为这都是它的成本。

这个时候你要做什么？

你要做上下文的压缩，

你要做智能的模型路由等等，

这些是夯实你做这个服务一个底座的关键的事情。

云厂商保证Agent服务的可用性，

而且是经济的、高效的。

云厂商Agent平台打法很清晰，

"我做的是Agent这一层的标准能力，

但能力背后那套企业系统接进来的工作，

我不管，你自己做。"

就是他们只做Agent平台标准化的能力包。

他们做的是Agent的"骨架"，

但骨架下面那些"血肉"，

具体某个企业的ERP怎么对接，CRM怎么读取，

自研OA怎么集成，

用户身份怎么和企业域控映射，

平台方不下场做，留给企业自己或者ISV做。

平台方该做的是"适配标准协议"，

而不是自己写代码，

去对接每个企业的内部身份系统。

再看Skill，Skill看上去很火，能力很强，

那企业的Skill什么时候出力呢？

其实，Skill的上场更晚，为什么这么说？

Skill是定义"Agent该会做什么"的规范。

它从来都不解决基础接口问题，

它解决的是"Agent怎么聪明地使用接口"的问题。

我们都知道，有Skill，Agent表现更稳定。

什么时候该查数据，什么时候该走审批，

什么场景下要避开，Agent全知道。

但企业Skill上场前，必须先完成四步。

举个例子，假设农夫山泉，

想让Agent用上自己的SAP系统，

四步走下来是这样的：

第一步：SAP的核心功能有API吗?

SAP是1972年的德国老厂，

农夫山泉早在2004年就上了SAP，

算是国内最早一批。

当年SAP上线的时候也是鸡飞狗跳，

别问我咋知道的。

已经跑了几十年的系统，它有API，

但关键业务的API通常没有完全暴露。

农夫山泉自己定制了大量业务流程，

这些定制部分SAP标准API根本调不到。

得农夫山泉自己做个能调的接口。

第二步：API标准是厂商（SAP）自定义的。

Agent看不懂的话，得做一个标准化中间层。

还是农夫山泉自己做。

第三步：身份穿透，

Agent替采购总监李四干活的时候，

SAP那边得认识李四是谁，有没有权限。

这套身份映射做不通，

要么Agent没权限干活，要么权限太大出大事。

第四步：合规，Agent查全国经销商库存数据，

这些数据能不能传给AI模型?

尤其是东南西北各区域的真实销量，

价格策略，经销商利润分成。

这四步全部完成之后，才轮到Skill上场。

Agent读完这份Skill，就知道SAP怎么用了。

企业不是个人电脑，权限都放出来，

难点是，Skill写得再漂亮，

前4步没做，Agent跑不通。

Skill在企业AI改造里的位置应该非常清楚了，

它是最后一步、最轻的一步，

但也是最常被高估的一步。

CTO听见"要做CLI改造"就头疼，

这是个动辄上千万，跨年，需要CFO批的项目。

但是，你不做，

这件事是Agent落地最大的拦路虎。

基本上分两种场景，

已经收敛的场景和发散场景，

前者，平台方"适配标准"就够了，

而发散场景，就需要自建FDE团队。

FDE团队是啥？

FDE=ForwardDeployedEngineer，

前线部署工程师。

这是一个新概念。

知乎的曹宇博士，

鼓励我经常看Anthropic招聘帖子，

因为你会大有收获，果然如此。

FDE是OpenAI，Anthropic都在推的岗位，

而且都在大规模招，

专门派工程师驻场到客户公司，

帮客户做深度集成。

OpenAI这边更激进，已经按行业拆分专项FDE：

半导体，生命科学，政府。

这种行业专项化，说明他们的FDE团队规模，

已经大到需要垂直分工了。

这是个重要信号，

美国头部模型公司不再只是卖API，

他们在主动下场帮客户做集成。

这件事过去是给专门公司干的，

现在美国两大头部模型公司自己抢着干。

我们一起看看细节：

"embeddirectlywithourmoststrategiccustomers"，

这句的意思是驻场到客户公司。

"delivertechnicalartifactslikeMCPservers，sub-Agents，andAgent skills"，

这句的意思是，交付MCP服务器，

子Agent，Skill。

和朋友挨踢小茶聊天，

我们都认为这个岗位像驻场架构师，

好处是能动用户数据，

目前AWS的SA没有权限动客户数据。

而且，FDE的资历要求，比想象中高，

Anthropic的FDE要求：

• 7+年软件工程经验
• 1+年GenAI/LLM生产部署经验
• 客户面对面能力
• 能50%时间出差；
  

OpenAI的FDE要求：

• 5-8年工程经验（分初级，Senior，Manager三档）

• 行业专精（半导体，生命科学，政府）

还能观察到，FDE优先深入的行业每个都是，

高利润，高客单价，高合规要求的赛道。

为什么需要这个角色？

因为有些场景是非标准化的。

这就是企业级Agent落地的真实地图，

光有平台不够，必须有AI亲和性，

无论是CLI，MCP还是Skill；

光有产品不够，必须有人服务。

写到这里，我也安心了，

企业里面各种系统要让Agent用，真不简单。

原来美国也没有用户产品一把搞定，

那就谈不上借鉴先进经验了，大家一起卷吧，

回到本文的标题，

我理解，OPC需要多个Agent组合干活，

无论多少个Agent协作的大架子，

但前提是每个单Agent都得自己跑得通。

如果一个Agent都搞不好，何谈OPC试点。

Skill大火的时候，你搞，他也搞，

一个Markdown文件，改改提示词，

换换业务术语，看起来就有了。

Skill之下全是企业自己得啃的硬骨头，

不能抄、不能蒸馏、不能借。

就凭蒸馏同事那点Skill，

是做了点皮毛的OPC方案。

文章来自于"亲爱的数据"，作者 "亲爱的数据"。