OpenAI Presence 为什么只能“驻场交付”?前沿实验室集体转向 FDE 的信号

一句话答案:OpenAI 之所以不让企业自助购买 Presence、坚持由工程师驻场交付,是因为大模型能力正快速商品化,企业 AI 真正的落差已经从"模型强不强"转移到"能不能在你的业务里跑通"——而后者无法被打包成一个 API 卖给你。据 The Register 报道,OpenAI 官方对 Presence 的定性很直接:"暂不作为自助产品提供"(not yet available as a self-serve product),而利润"可能藏在管道里"(margin in the plumbing)。这对每一家想落地 AI 的公司都是一个值得读懂的信号。

OpenAI Presence 是什么?为什么只能由 Forward Deployed Engineers 交付、暂不自助?

先给答案:Presence 是 OpenAI 面向企业推出的实时 agent 服务,横跨语音与聊天;它不开放自助,是因为交付本身被 OpenAI 定义成一件需要工程师"驻场"完成的事,而不是买个账号就能开通的 SaaS。

据 The Register 报道,OpenAI 于 2026 年 7 月 22 日发布 Presence,首批聚焦三类场景:客服、外呼销售,以及高风险的内部流程。真正的关键约束写在交付方式里——OpenAI 官方原文表述为:

"Deployments are led by OpenAI Forward Deployed Engineers and select global systems integrators. Presence is not yet available as a self-serve product." (交付由 OpenAI 的 Forward Deployed Engineers 与精选的全球系统集成商主导;Presence 暂不作为自助产品提供。)

换句话说,连 OpenAI 都不认为"把模型能力做成 agent"就等于"企业能直接用起来"。为了证明这套东西真能跑,OpenAI 拿自己做了样板:据 The Register,Presence 已经在运行 OpenAI 自家的英文电话客服——能核验来电者身份、调用账户上下文、执行获批动作(处理账单、账户变更、符合条件的退款),必要时再转接真人。这套"先在自己身上跑通,再驻场帮客户跑通"的路径,正是驻场交付的典型形态。

同一发布也见于 OpenAI 官方公告《Introducing OpenAI Presence》(2026-07-22 发布,此处为 Internet Archive 官方页面存档)的一手信息,可与上述报道交叉印证。

前沿实验室为什么集体转向"驻场交付"?模型商品化后,钱在哪?

先给答案:因为模型能力正在趋同、被商品化,差异化和利润从"模型层"下移到了"管道层"——也就是集成、落地与编排。谁能把 agent 真正嵌进客户的业务流程,谁才拿得到这部分价值。

这不是一句口号,而是 OpenAI 用组织结构投的票。据 The Register 报道,Presence 的交付主体是 OpenAI 去年成立的咨询臂——"OpenAI Deployment Company and Forward Deployed Engineers",而 OpenAI 在今年 5 月收购了咨询公司 Tomoro,以此扩编这支"技术安装劳动力"(technical installation workforce)。报道对这条商业逻辑的概括很到位:

"As AI models become commoditized, maybe there's margin in the plumbing." (当 AI 模型被商品化,利润也许就藏在管道里。)

"管道"(plumbing)一词值得咂摸:它指的不是模型本身,而是把模型接进真实系统、对齐真实流程、扛住真实风险的那一层工程与咨询工作。这恰好印证了一个我们反复讲的判断——模型是原料,价值在落地。关于 FDE 到底是什么、以及"按价值交付"如何区别于卖工时,可以读我们的定义文《什么是 AI FDE 与价值交付》;本篇是它的新闻驱动续篇——当前沿实验室开始亲自照着 FDE 剧本做,这个模式就从"一种主张"变成了"行业信号"。

FDE 驻场交付和传统 IT 外包有什么区别?

先给答案:两者最大的区别在结算逻辑和关系结构。传统外包按工时或交付物结算、甲乙方隔离、项目验收即结束;FDE 则嵌入客户团队、按业务结果对齐、上线后持续迭代,并把每一个失败案例沉淀成可复用的组织能力。它不是"外包 2.0",而是另一种交付契约。

维度	FDE 驻场交付	传统 IT 外包
结算逻辑	对齐业务结果 / 价值	按工时或交付物
与客户关系	嵌入客户团队、共担目标	甲乙方、需求—验收隔离
迭代方式	上线后持续调优、共生进化	项目交付即结束
知识沉淀	bad case → 可复用组织能力	随项目结束流失
适配对象	高不确定、需深度上下文的 AI 落地	需求明确、可规格化的工程

为什么 AI 落地天然更贴近左列而不是右列?因为 AI 项目在签合同那一刻,需求往往还说不清:哪个场景最该先做、模型在你真实数据上会怎么失灵、多少环节需要人兜底,这些只有驻场跑起来才知道。这也是 OpenAI 选择让 FDE 主导 Presence 交付、而非直接开放自助的底层原因——需求要在现场被发现,而不是在需求文档里被规格化。想进一步理解 FDE 的价值交付逻辑,同样可参考《什么是 AI FDE 与价值交付》。

为什么企业 AI 落地必须靠驻场交付?(用失败率反推)

先给答案:因为"买了模型"离"落地成功"还隔着一条很宽的沟。连 OpenAI 都不敢让企业自助上 agent;而 Gartner 的预测显示,大量客服 AI 计划最终会被放弃。我们据此认为:缺了既懂业务又懂工程的人驻场对齐,落地失败的风险会明显更高。

先看数据本身:据 The Register 报道,Gartner 预测,到 2027 年,在计划把客服转向 AI 的组织里,将有一半放弃该计划。需要说明的是,这条预测只给出"计划被放弃"的比例,并未逐项归因。

至于放弃的原因——以下是我们基于落地一线经验的判断,并非 Gartner 的结论:放弃往往并不是因为"模型不够强",而更多卡在落地环节——流程没对齐、数据没打通、边界情况没人兜底、上线后无人持续调优。这些恰恰是驻场交付要解决的问题:把"能演示"变成"能长期在生产里跑"。关于落地为什么这么难,可以读《为什么企业 AI 落地这么难》。

反过来看:如果落地是纯技术采购问题,OpenAI 完全可以把 Presence 做成自助 API 收订阅费,规模化又省人力。它偏偏没有——在我们看来,这恰恰说明这道沟填不填得平,很大程度上取决于人,而不只是模型。

中小企业怎么复用大厂的 FDE 剧本?

先给答案:你不需要自建一支 OpenAI 级别的 FDE 团队,但可以照搬它的四步方法论——先诊断真实瓶颈,再让懂业务的工程师驻场对齐结果,从高价值或高风险的单点切入,并把每个失败案例沉淀成可复用能力。缺自有团队时,可以借外部 FDE。

拆成可执行的四步:

1. 先诊断,别先上工具。 在写任何 prompt 之前,先搞清楚哪个业务环节最该先被 AI 改造、失败的代价有多大。OpenAI 也是先在自家客服上跑通,才向外推。你可以先花几分钟做我们的免费 AI 诊断,测出你最该优先落地的场景,而不是被"什么热做什么"牵着走。
2. 让懂业务的人驻场对齐结果。 交付的成败标准不是"模型接通了",而是"业务指标动了"。让工程师嵌进你的团队、对齐真实结果——这正是 FDE 区别于外包的地方。
3. 从单点切入,别一次全上。 OpenAI 首批只做客服、外呼、少数高风险内部流程。中小企业更应聚焦一个高价值或高风险的单点,跑通再扩。
4. 把 bad case 沉淀成能力。 每一次失败都应变成下一次能复用的规则、知识或流程,而不是随项目结束流失。这是驻场交付相对一次性外包的复利所在。

如果你的团队更想自己长出这套 AI 落地能力,而不是长期依赖外部驻场,可以参考我们的课程体系。

迷你 FAQ

Q:OpenAI Presence 可以自助购买吗? A:暂时不行。据 The Register 报道,OpenAI 明确表示 Presence"暂不作为自助产品提供",交付由 OpenAI Forward Deployed Engineers 与精选系统集成商主导。

Q:什么是 Forward Deployed Engineer(FDE / 驻场交付)? A:一种嵌入客户团队、按业务结果对齐、上线后持续迭代并把失败案例沉淀为可复用能力的交付模式,区别于按工时或交付物结算、验收即结束的传统 IT 外包。

Q:为什么企业 AI 落地经常失败? A:据 The Register 报道,Gartner 预测到 2027 年,计划把客服转向 AI 的组织中将有一半放弃该计划。我们认为,落地难点往往不在模型强弱,而在集成与流程对齐——这也是驻场交付要解决的核心问题。

更多常见问题见我们的 FAQ。