央企OPC改造费测评：Agent运行困局与玩法
近期一次饭局，与两位央企高管——集团行政负责人与科技子公司CTO——闲聊。小海鲜味道不错，聊得也深入。整场听下来，最深感触是：大企业内部的管理复杂度，远超外界认知。
有个场景印象极深。那位行政老兄突然追问CTO：“咱们集团现在到底有几个AI模型平台？我看到至少两个，为什么偏偏是两个？”CTO愣住片刻，没绕弯子，直接答：“说实话，我也不清楚。”饭桌瞬间安静，接着大家不约而同笑出声，笑声里透着无奈。
这大致就是中国企业AI落地的真实缩影。核心瓶颈不在技术，而在组织。模型再强，最终都要嵌入具体架构。从去年到今年，一个明确的新需求浮出水面：如何让智能体真正、大规模投入生产？尤其“龙虾”爆火后，连高层态度都明显转变。客观说，“龙虾”向全球做了一次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方案。