OpenAI推出Presence：带驻场工程师的企业级AI智能体服务

不是API，而是工程师上门：Presence的本质定位

OpenAI Presence并非在线自助购买的产品，而是一项受控的托管服务，目前仅通过有限通用可用性计划（Limited GA）提供。它不面向开发者开放API调用或席位许可，而是由OpenAI自有的前向部署工程师（Forward Deployed Engineers, FDE）牵头，并联合少数经认证的全球系统集成商共同交付。这种模式标志着OpenAI从纯技术供应商向深度实施伙伴的实质性转向。

Presence按项目销售，而非按产品订阅。每个合作始于一个明确、边界清晰的业务任务——例如解决客户账单纠纷、处理保险理赔，或响应员工IT服务请求。智能体仅被授予完成该任务所必需的知识库访问权限和系统接口权限；客户自身负责编写行为规则，明确其操作边界、需人工审批的节点，以及自动转人工的触发条件。

从模拟到上线：六阶段交付与闭环优化

OpenAI官方文档罕见地坦承了落地所需的人力投入，明确列出六阶段交付流程：业务成果界定 → 安全/隐私/法务审查 → 模拟测试与结果评估 → 用户验收测试 → 分阶段上线 → 上线后持续迭代。Presence强调，智能体绝非简单‘喂入文档’即可投产——其生产就绪状态依赖于结构化验证与组织协同。

在上线前，所有交互均经模拟环境与多维评分器检验：是否达成正确结果、是否遵循既定政策、工具调用是否准确、升级时机是否恰当。运行中，防护护栏（guardrails）实时拦截越界行为；完整会话记录与操作日志为审计提供依据；人工接管时传递的是结构化上下文，而非原始对话文本；新版本通过可控灰度发布，并支持快速回滚。

直面行业痛点：为什么需要‘工程师+智能体’

Gartner预测，到2027年底，超40%的智能体AI项目将被取消，主因并非模型能力不足，而是治理机制缺失、商业价值未明、运营纪律薄弱。Presence几乎每一项设计都直指这些症结：模拟与评估前置、权限最小化、人工介入路径结构化、迭代闭环内置于Codex系统（用于分析真实会话并提出改进建议）。

企业过去两年已普遍意识到：AI智能体落地最难的部分不在模型本身，而在系统集成、权限配置与组织变革管理。OpenAI派遣FDE驻场，正是回应客户在这些环节的真实失败，而非将责任推给‘客户没配好IT团队’。

约束与权责：咨询模式带来的新挑战

该模式的天然瓶颈在于交付能力——OpenAI明确将‘可用交付容量’列为准入门槛之一。软件可无限复制，但通过严格安全审查、获准接入银行核心系统的工程师无法规模化扩张。FDE头衔源自Palantir，指长期嵌入客户现场的专家，其经济模型与按量计费的推理服务截然不同。

当OpenAI自身FDE与指定集成商共同站在交付第一线，它实质进入了传统系统集成商的市场层。这在早期小规模阶段可行，但随需求增长将面临资源调配与角色冲突压力。更关键的是，当模型厂商同时担任实施方，若因策略误用导致生产事故，合同中必须白纸黑字厘清责任归属，而不能依赖默认假设。

实证与客户进展：仍处早期验证阶段

OpenAI称Presence‘经实战检验’，依据是其多年为企业客户部署智能体的经验沉淀，而非该品牌产品上市后的市场表现。最具说服力的内部案例是其英文电话支持热线（1-888-GPT-0090）：上线数周即达到或超越人工客服基准，现可独立解决75%呼入问题，并在10天内通过Codex闭环将人工转接率降低15个百分点。需注意，该数据由OpenAI自主采集、按自有标准评测，尚未经第三方验证。

首批三家公开客户——西班牙BBVA（探索墨西哥西语语音银行服务）、日本SoftBank（测试日语对话）、英国IAG集团（高并发场景如极端天气下的客户服务）——均处于概念验证或试点阶段，实际落地深度与广度尚待观察。

> 编者观点：Presence模式凸显AI落地正从‘技术可用性’竞争转向‘组织适配性’竞争。对中国企业而言，与其追逐大模型参数竞赛，不如加速构建跨职能的AI交付能力——包括懂业务的规则设计师、通安全的权限架构师、精运维的流程编排师，这才是智能体规模化落地的核心壁垒。