OpenAI Presence:把语音与聊天 Agent 变成可控的企业生产服务

OpenAI Presence:把语音与聊天 Agent 变成可控的企业生产服务

OpenAI Presence 将语音与聊天 Agent 的权限、政策、模拟评测、人工升级和 Codex 改进流程组合成企业部署服务;本文拆解它与 Agentforce 的治理差异及当前可用边界。

先看结论

7 月 22 日,OpenAI 发布 Presence,把语音和聊天 Agent 的企业部署做成一套有限一般可用的产品。它面向客户支持、外呼销售和高风险内部工作流,企业先为 Agent 指定一个具体工作,再配置知识、系统权限、政策、批准动作和人工接管规则;上线后,生产会话和升级事件会进入评测与改进流程,Codex 负责提出候选更新,团队测试并批准后再发布。1
所以 Presence 的核心商品不是一个更会聊天的模型,而是一套「把 Agent 放进生产以后怎么管」的交付系统。OpenAI 目前没有把它做成自助式开发平台,符合条件的企业通过有限一般可用计划接入,部署由 OpenAI 的 Forward Deployed Engineers 和选定的全球系统集成商主导。对企业来说,这换来了更强的陪跑,也带来了价格、底层模型、数据治理和迁移能力尚未公开的现实缺口。

从一个具体工作流开始

Presence 的部署逻辑从「做什么工作」开始,而不是从「选择哪一个模型」开始。官方给出的例子包括账单问题、保险理赔和员工 IT 服务请求。Agent 只拿到完成该工作的必要知识与系统访问权限,企业再规定哪些动作可以直接执行、哪些动作必须审批、何时交给人处理。1
这个顺序很重要。一个能调用 CRM、支付、工单或内部知识库的 Agent,风险不只来自回答错了,还来自它是否看到了不该看的数据,是否在错误的账户上执行了正确的动作,是否在异常情形下继续重试。Presence 把知识范围、系统权限、政策和升级规则放在同一个部署单元里,先缩小可行动范围,再谈自动化率。
OpenAI Presence 官方界面图,左侧是语音转写和客服对话,右侧展示查单状态与退款工具动作。
Presence 官方示例把一段客服对话和工具动作放在同一画面里:Agent 理解重复扣款,查询订单信息,然后执行退款。这个画面展示的不是 UI 装饰,而是企业验收时必须拆开的两个问题:它是否理解了用户意图,以及它是否只在被授权的条件下改变了外部系统状态。1

把上线前后的控制串起来

Presence 把生产流程拆成四个相互连接的阶段。
阶段OpenAI 公布的能力企业真正要验收的对象
定义工作指定具体任务、知识范围和系统访问Agent 能看到哪些数据,能调用哪些系统
上线前模拟常见请求、边界案例和高风险场景,用评测器检查结果、政策遵循、工具使用和人工升级错误动作、越权访问、误升级与漏升级
生产运行处理语音与聊天会话,执行批准动作,遇到边界时交给人成功率、转人工率、处理时延和副作用
版本改进从生产会话、升级事件和质量信号发现缺口,Codex 提议更新,团队测试后受控发布每次改动能否复测、回滚和解释
这套结构解决的是 Agent 的持续变化。产品政策、客户表达方式和内部系统都会变,昨天通过的测试不能证明下个月仍然安全。Presence 把上线后的会话当成评测材料,把人工接管当成质量信号,再把变更放回测试环境,形成了一个比「上线后看日志」更完整的运营闭环。1
OpenAI 给出的自有电话支持案例显示,该系统现在处理英语电话渠道 1-888-GPT-0090,官方称其达到或超过内部一线人工支持质量基准,并在没有人工协助的情况下解决 75% 的来电问题;使用 Codex 驱动的改进循环后,人工转接在 10 天内下降了 15 个百分点。这些是 OpenAI 自报的单一部署结果,不能直接当成 Presence 在其它企业或语言环境中的平均水平。1

和 Agentforce 的差别在哪里

Presence 面对的不是空白市场。Salesforce 对 Agentforce 的公开说明同样把 Agent 的风险放在行动层,而不是只看文本是否合规:Trust Layer 负责权限、审计和升级逻辑;Agent Script 可以规定动作的步骤和顺序;Observability 记录会话轨迹、指令遵循和毒性评分;Gateway 则为每次外部工具调用施加企业安全与策略约束。2
对比维度OpenAI PresenceSalesforce Agentforce 公开能力
控制对象政策、标准操作程序、护栏、批准动作和人工升级Trust Layer、Agent Script、权限、审计、Gateway 与升级逻辑
上线后改进生产会话和升级事件触发 Codex 建议,团队测试并批准Observability 提供会话轨迹、指令遵循和运行质量信号
交付方式有限一般可用,部署由 OpenAI FDE 和选定集成商主导以企业平台治理组件为中心,公开材料强调规则、审计和工具授权
当前边界不是自助式产品,公开发布页没有给出价格、SLA、数据保留和模型迁移细节公开页面也主要描述治理架构,具体产品合同与配置边界需单独确认
两者的共同点是把「Agent 是否被允许执行某个动作」放在护栏中心。差异更像交付哲学:Presence 把 OpenAI 的部署工程师、系统集成商和 Codex 改进流程放进产品可用方式,强调从一个高价值工作流陪跑到生产;Agentforce 的公开材料更强调平台内的规则、可观察性和每次工具调用的治理。前者可能减少企业从零搭建的工作量,后者更容易让已经使用 Salesforce 业务系统的团队把治理组件接入既有平台。第二句是基于两家官方公开材料的产品定位比较,不代表完整的功能或采购对比。

现在适合谁试用

Presence 更适合那些已经能明确写出任务边界、系统权限和人工接管条件的企业。客服账单、保险理赔初筛、员工 IT 请求这类工作有相对清楚的输入和结果,也能在错误发生时暂停或交给人。OpenAI 提到 BBVA 正探索墨西哥日常银行语音支持,SoftBank 正测试日语客户对话,IAG 正探索恶劣天气等高需求时段的保险支持,官方用词仍是探索和测试,不能视作全面上线案例。1
企业在接触 Presence 时,首轮验收不应只问「能解决多少请求」。更应该要求看到以下结果:Agent 是否只读取必需数据;被拒绝的动作是否留下原因;高风险请求是否稳定转人工;策略更新能否在上线前重放历史案例;生产版本能否回滚;会话、工具调用和审批记录能否导出。若这些问题没有明确答案,自动化率越高,后续排错的成本越大。
当前可用性也决定了采购预期。Presence 只向符合条件的企业提供有限一般可用,部署需要 OpenAI FDE 和选定系统集成商参与,尚未开放自助使用。对于希望自己控制编排、模型切换和部署节奏的开发团队,它更像一项由 OpenAI 参与交付的企业服务,而不是可以立即注册、接 API、自由迁移的通用平台。1
Presence 发布后,企业 Agent 的比较单位会从「哪个模型回答得更好」移到「哪个系统能把权限、评测、异常升级和版本变更管好」。OpenAI 已经把这套运营流程包装成产品,下一步是否能在公开价格、数据治理、模型迁移和多行业部署上给出更清晰的边界,才会决定它是长期平台,还是少数大客户的定制交付项目。

関連コンテンツ

  • ログインするとコメントできます。
More from this channel