解密央企OPC玩法与困境：Agent运行还需改造费

不久前，我与两位央企高管共进晚餐，一位是集团行政负责人，另一位是科技子公司的CTO。小海鲜味道不错，交谈也很尽兴。整场饭局下来，最大的感触是：大型企业内部的组织复杂度，远远超出外界的想象。

有一个细节让我印象深刻。那位行政老兄突然很认真地追问CTO：“咱们集团现在到底有几个模型平台？我看到的好像有两个，为什么偏偏是两套？”CTO愣了一下，也没绕弯子，直接回了句：“说真的，我也不知道。”饭桌上安静了一秒，接着大家不约而同地笑出声来，笑声里多少带着点无奈。

这大概就是中国大企业拥抱AI最真实的现场写真。核心矛盾并非技术，而是组织架构。模型再强大，也必须落地到具体的组织体系里。从去年到今年，一个明显的新需求逐渐浮现：如何把Agent真正、大规模地用起来？尤其是在“龙虾”爆火之后，连管理层对Agent的态度都积极了不少。客观地说，“龙虾”为全世界做了一次Agent的普及教育，这是它载入科技史册的重要贡献。

最近，大家又开始热议“OPC试点方案”。坦白讲，不少企业已经在一些小型业务场景中测试Agent了，比如让AI助手输出一份“日报”方案，效率提升非常明显。这些都是我亲眼见证的真实案例，可惜涉及企业内部信息，无法公开分享。企业级Agent市场到底会如何演进，值得深入探讨。市场上Demo满天飞，尝鲜的小工具也不少，但要说企业已经准备好大规模上线Agent？答案是，还没有。

障碍重重，其中一个核心环节是接口改造。试想一下，一家公司有几十上百个老旧系统，当初设计时压根没考虑过让程序来调用。现在要让Agent畅通无阻，就必须把这些老系统逐一改造——加API、统一身份认证、做权限穿透、通过合规审查。这个工程少说也要一两年，投入上千万，还需要跨部门协同。所以说，“用Agent”听起来轻松，但实际上，这首先是一场企业级的数字化转型大工程。不是Agent不行，而是企业的底层基础还没准备好。

GUI界面是给人点击的，CLI是给人敲命令的，而API是给程序调用的——关键是完全不需要人介入。要让企业系统被Agent调用，没有第二条路，必须有API（或者在此基础上再封装一层MCP协议）。严格来说，MCP还不是工业标准，它只是Anthropic主推的协议，目前仍处于争夺标准地位的阶段。如果各家模型公司都用自己的一套格式，那局面岂不是更混乱？早期确实如此，后来Anthropic推出MCP试图统一江湖，但OpenAI等巨头短期内肯定不会放弃自家格式。大家平时说的“CLI改造”之类，其实都是泛泛而谈，意思是“让系统能被AI调用”，但具体怎么调，定义很模糊。企业级AI落地真正的短板，就是“API改造”——为老系统增加一个程序调用入口。很多人提到的CLI改造，只是这件事的一种特殊形态，主要服务于编程类Agent，并非主战场。核心就一句话：老系统必须加上能让AI直接调用的程序接口。

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

企业里的OA、ERP、CRM系统，原本都是设计给人用的。人打开界面、点击按钮、填写表单、提交。这些系统在设计时根本不知道，也不在乎“另一个程序该怎么调用它”。要让Agent用好这些系统，唯一的办法就是把它们改造成“程序能调用的样子”。不少阿里的人把这称为“AI亲和改造”。现实是，企业内部系统大多还没有完成改造。它有OA、有ERP、有CRM，还有自己的身份认证系统，这些都已经运行了五六年甚至更久。为了让一个新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是定义“Agent该会做什么”的规范，它从来不解决基础的接口问题，解决的是“Agent怎么聪明地使用接口”的问题。有了Skill，Agent的表现会更稳定——什么时候该查数据，什么时候该走审批，什么场景下要避开，Agent全都知道。但企业想让Skill上场，必须先完成四步准备工作。

以农夫山泉为例，想让Agent用上自己的SAP系统，四步走下来是这样的：
第一步：SAP的核心功能有API吗？SAP是1972年的德国老厂，农夫山泉早在2004年就上了SAP，算是国内最早的一批。当年上线时也是鸡飞狗跳。跑了二十多年的系统，它肯定有API，但关键业务的API通常没有完全暴露。而且农夫山泉自己定制了大量业务流程，这些定制部分SAP标准API根本调不到，必须得农夫山泉自己做一个能调用的接口。
第二步：API的标准是SAP自定义的。Agent看不懂的话，需要做一个标准化的中间层。这事还是农夫山泉自己做。
第三步：身份穿透。Agent替采购总监李四干活时，SAP那边得认识李四是谁，有没有权限。这套身份映射做不通，要么Agent没权限干活，要么权限太大会出大事。
第四步：合规。Agent查询全国经销商库存数据，这些数据能不能传给AI模型？尤其是各地区真实的销量、价格策略、经销商利润分成，这些都是高度敏感的商业数据。

这四步全部完成之后，才轮到Skill上场。Agent读完这份Skill，就知道SAP该怎么用了。企业不是个人电脑，不能把权限全放出来。难点在于，Skill写得再漂亮，前四步没做，Agent就跑不通。Skill在企业AI改造里的位置应该很清楚了：它是最后一步、最轻的一步，但也往往是被高估得最厉害的一步。

CTO一听到“要做CLI改造”就头疼，这是个动辄上千万、跨年度、还需要CFO批准的项目。但你不做，这件事就是Agent落地最大的拦路虎。基本上可以分两种场景：已经收敛的场景和发散场景。前者，平台方“适配标准”就够了；而发散场景，就需要自建FDE团队。

FDE团队是什么？FDE = Forward Deployed Engineer，即前线部署工程师。这是一个新概念。知乎的曹宇博士经常建议去看看Anthropic的招聘帖子，因为会有大收获，事实确实如此。FDE是OpenAI和Anthropic都在推广的岗位，而且都在大规模招人。他们专门派驻工程师到客户公司，帮客户做深度集成。OpenAI这边更激进，已经按行业拆分出专项FDE：半导体、生命科学、政府。这种行业专项化，说明他们的FDE团队规模已经大到需要垂直分工了。这是一个重要信号——美国头部模型公司不再只是卖API，而是主动下场帮客户做集成。这件事过去是咨询公司或集成商的活儿，现在两大巨头亲自下场抢着干。

看看招聘细节就很清楚：“embed directly with our most strategic customers”——这意味着驻场到客户公司。“deliver technical artifacts like MCP servers, sub-Agents, and Agent skills”——意思是交付MCP服务器、子Agent、Skill。和一位朋友交流，我们都觉得这个岗位像驻场架构师，好处是能接触用户数据，而目前AWS的SA是没有权限动客户数据的。FDE的资历要求也比想象中高：Anthropic要求7年以上软件工程经验、1年以上GenAI/LLM生产部署经验、客户面对面能力、能接受50%时间出差。OpenAI则要求5-8年工程经验，并分初级、资深、经理三档，还要求行业专精（半导体、生命科学、政府）。可以看到，FDE优先深耕的行业，都是高利润、高客单价、高合规要求的赛道。

为什么需要这个角色？因为有些场景是非标准化的。这就是企业级Agent落地的真实地图：光有平台还不够，必须有AI亲和性——无论是CLI、MCP还是Skill；光有产品还不够，必须有人服务。写到这，心里反而踏实了。企业内部各种系统要让Agent用，真不简单。原来美国那边也没有一个现成的用户产品能搞定一切，那也就谈不上直接借鉴先进经验了。大家一起卷吧。

回到本文的标题。我的理解是，OPC需要多个Agent组合协作，无论多少个Agent协作的大框架，前提是每个单独的Agent自己都得跑得通。如果一个Agent都搞不好，何谈OPC试点？当Skill大火的时候，你搞他也搞，一个Markdown文件，改改提示词，换换业务术语，看起来就有了。但Skill之下，全是企业自己得啃的硬骨头——不能抄、不能蒸馏、不能借。只凭从同事那“蒸馏”来的一点Skill，能做出的，终究只是皮毛的OPC方案。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：解密央企OPC玩法与困境：Agent运行还需改造费要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题