本文要点
- 从单一对话入口变为可连接企业系统并执行获批动作的语音与聊天 Agent。
- 从上线前一次验收变为生产信号、评估、测试和审批组成的持续改进闭环。
- 从开发者自助拼装变为工程师与系统集成商参与的有限企业部署。
阅读辅助
先看数字、证据和来源，再读正文。
Presence 把实时语音和聊天、企业系统访问、获批动作及人工接管整合为受治理的部署产品。
2026-07-22 · OpenAI 发布 Presence，并向符合条件的企业客户启动有限通用可用计划。
OpenAI 在 2026 年 7 月 22 日发布 Presence。它值得关注的原因，不是企业又多了一个聊天机器人入口，而是 OpenAI 开始把企业 Agent 最难交付的部分——系统权限、可执行动作、审批条件、评估、变更上线和人工接管——包装成一套持续运营产品。
已经确定的事实是：Presence 面向客户支持、销售以及高风险内部流程，支持实时语音和聊天；Agent 可以回答问题、调用公司系统，并在工作流允许时执行获批动作。产品当天进入面向符合条件企业客户的有限通用可用计划，部署由 OpenAI 前线部署工程师和选定的全球系统集成商参与，并不是任何企业都能自行开通的全面 GA。
不确定性同样明显。OpenAI 给出的 75% 独立解决率和 15 个百分点 / 10 天改进数据都来自厂商自报。公告没有同步样本量、问题难度、初始转交率、最终转交率、失败成本或第三方复核结果，因此这些数字可以说明 OpenAI 正在用自己的支持场景验证产品，却还不能证明其他企业会得到同样效果。
对企业买方而言，Presence 把采购问题从“选哪个模型”改写为“允许 Agent 看什么、做什么、何时停下、谁批准变更”。对集成商和内部平台团队而言，连接器、身份权限、评估集、审批链与人工兜底将成为主要工作量；模型本身只是其中一层。
Presence 发布的不是又一个机器人模板
OpenAI 对 Presence 的描述可以拆成五个相互约束的环节。
第一是知识边界。企业要为具体工作流决定 Agent 能使用哪些信息，而不是让一个通用助手无差别读取全部内部资料。客户支持 Agent 可能需要产品文档、订单状态和服务政策，内部流程 Agent 则可能接触更敏感的员工或财务信息。知识范围本身就是权限设计的一部分。
第二是系统访问。Presence 允许 Agent 使用公司系统，但“能访问”不等于“能任意操作”。每个工作流都需要定义可调用的系统、身份和数据范围。这个区分很关键：只读查询、生成建议、修改记录、触发退款或提交审批，风险等级完全不同。
第三是动作与审批。公告强调 Agent 执行的是获批动作，并由企业设置何时需要审批。这意味着部署目标不是追求最大自主性，而是先把动作划进不同风险区间：低风险动作可自动执行，中风险动作需要规则检查，高风险动作交给人确认。Presence 的产品价值取决于这些边界是否足够细、是否可审计，而不只是对话是否流畅。
第四是评估与上线门。OpenAI 称系统会结合生产信号持续改进，并使用 Codex 分析问题、提出改进；但建议不能直接进入生产环境，仍需测试和审批。这个设计试图避免“自动学习”被误解为模型在生产中自行改写行为。更准确的状态是：生产信号产生候选改动，候选改动经过评估，获批后才部署。
第五是人工接管。Agent 必须知道何时停止，并把上下文交给人。对于语音支持，接管不只是转接电话，还包括把用户身份、问题摘要、已执行动作和未完成事项完整交给坐席。若上下文在交接时丢失，即使转交率降低，用户体验和风险控制也未必改善。
| 环节 | Presence 公告给出的状态 | 企业部署时仍要回答的问题 |
|---|---|---|
| 知识 | 为具体工作流限定可用知识 | 数据是否按角色、地区和用途隔离 |
| 系统 | 可调用公司系统 | 使用谁的身份，权限能否按动作最小化 |
| 动作 | 只执行获批动作 | 哪些动作自动执行，哪些必须人工确认 |
| 评估 | 结合生产信号测试改进 | 评估集是否覆盖长尾失败和高风险边界 |
| 上线 | 改进通过审批后部署 | 谁能批准，能否回滚，变更是否留痕 |
| 接管 | 必要时升级给人 | 触发条件、响应时限和上下文交接是否完整 |
这套结构与 OpenAI 的 Agents SDK、Evals、Voice Agents 和 Realtime API 文档形成背景上的连续性：开发者栈提供模型、工具、语音和评估能力，Presence 则试图把它们放进企业部署与运营流程。这里必须保留证据边界：这些文档能解释相关技术组件，不能反向证明 Presence 已支持文档中的全部能力，更不能独立验证其生产指标。
三个数字怎样读才不失真
公告中最醒目的数据是 75%。OpenAI 称 Presence 目前可以在无需人工协助的情况下，解决其英文电话支持渠道 75% 的入站问题。准确口径应写成“75% 自报”：主体是 OpenAI 自己，渠道限定为英文电话支持，对象是入站问题，结果是无需人工协助解决。它不是所有语言、所有渠道或所有企业客户的统一解决率。
“解决”也不应自动等同于“用户满意”。一个问题可能在流程上关闭，却仍出现答案不完整、重复来电、补偿不足或后续纠纷。要判断 75% 是否有业务价值，至少还需要同时看到首次联系解决率、重复联系率、客户满意度、平均处理时长、误操作率以及升级后的人工作业时间。
第二个数据是人工转交率下降 15 个百分点。百分点描述两个比例之间的绝对差，例如从 40% 降到 25% 是下降 15 个百分点；相对降幅则是 37.5%。公告没有披露起点和终点，因此不能把它写成“下降 15%”，也不能计算相对变化。这一口径是本次报道最容易发生的误写。
第三个数据是上述变化发生在 10 天内。OpenAI 将它归因于 Codex 驱动的改进循环：分析生产信号、提出改动、测试并经过批准后上线。15 个百分点 / 10 天说明改进节奏可能很快，但并不能单独说明效果能长期保持。短期内首先修复高频问题，往往会产生较大的初始收益；之后进入长尾问题时，边际改进通常更难。
| 官方披露 | 可以得出的结论 | 不能得出的结论 |
|---|---|---|
| 75% | OpenAI 自报其英文电话支持多数入站问题可不经人工解决 | 不能外推到其他语言、渠道、行业或客户 |
| 下降 15 个百分点 | 人工转交比例出现绝对变化 | 不能写成相对下降 15%，也无法还原起止值 |
| 10 天 | 公告描述的改进发生在较短观察期 | 不能证明长期稳定，也不能排除流量结构变化 |
由于三项数字都来自同一份官方公告，本文把发布事实标为高置信，把效果指标分别标为中置信。OpenAI 的官方 X 帖文可以交叉确认产品定位和有限开放状态，但它与公告属于同一发布方，不构成独立效果复现。其余官方技术文档只用于解释 Agent、评估和实时语音背景，也不构成第二份指标证据。
“有限”二字比 GA 更重要
Presence 的可用状态必须准确写成有限通用可用计划。这不是全面 GA，也不是面向所有账号的自助产品。官方披露由前线部署工程师和选定的全球系统集成商参与，说明当前交付仍高度依赖方案设计、系统对接和现场治理。
这种发布方式与产品风险相匹配。一个只回答公开 FAQ 的机器人出错，通常造成的是体验损失；一个可以访问客户账户、修改订单或参与高风险内部流程的 Agent 出错，可能造成资金、合规和权限事故。供应商需要在少量场景中积累评估集、故障模式和审批模板，企业也需要先梳理自己的系统与责任链。
公告提到 BBVA、软银和 IAG，但采集材料显示它们分别处于探索或测试阶段。报道不能把这三个名字写成“已全面生产部署”的客户背书。它们能证明大型企业正在评估这类产品，却不能证明规模化收益、稳定性或合规审计已经完成。
有限开放还暴露出 Presence 的商业形态：早期成本不只来自模型调用。企业要支付流程梳理、连接器建设、身份与权限映射、测试数据制作、上线审批、监控告警和人工接管的成本。如果后续定价只按 token 或通话分钟展示，而没有把系统集成与持续运营费用算进去，买方很容易低估总拥有成本。
企业真正需要建设的是责任边界
传统软件把动作写进确定性代码，审批和权限通常由现有系统承担。Agent 引入了概率性决策：同一个用户表达可能触发不同工具路径，长对话也可能逐步改变上下文。于是企业不能只检查“模型是否会调用工具”，还要检查“在什么条件下调用、参数从哪里来、失败时是否停止、结果如何回滚”。
一个可上线的 Presence 工作流至少需要四层控制。
- 最小权限：Agent 只获得当前任务必需的数据和动作，不因方便而继承操作员的全部权限。
- 动作分级：查询、建议、写入、付款和外部通知采用不同审批门槛，敏感动作需要二次确认。
- 可重复评估：每次提示、工具或策略变化都要重跑固定评估集，并加入生产中新出现的失败样本。
- 可追溯接管：系统记录用户意图、模型判断、工具调用、审批结果与人工接管原因，方便事后审计。
这里的难点不是写出一份原则，而是把原则变成机器可执行的策略。例如“金额较大时转人工”必须定义金额阈值、币种、客户层级和累计交易；“检测到用户不满时升级”必须定义误判成本及坐席容量。没有这些细化，所谓护栏只是一句无法测试的自然语言。
持续改进同样需要变更治理。Codex 可以帮助归纳失败并提出修改，但生产行为的改变仍应像软件发布一样有版本、评估、批准、灰度和回滚。越是强调 10 天内快速降低转交率，越要追问改动是否牺牲了其他指标。减少转人工可能来自能力提升，也可能来自接管阈值被放宽；只有同时观察质量和风险指标才能区分。
Presence 的重要性不在于 OpenAI 又多卖了一层企业产品，而在于它公开承认：企业 Agent 的瓶颈已经从“能不能回答”转向“能不能被授权执行，并在出错前停下”。当 Agent 进入真实系统，模型分数只是能力上限，权限、审批、评估和接管共同决定可用下限。
这对竞争格局有两层影响。第一，模型厂商开始向部署和运营层延伸，与云厂商、企业软件和系统集成商争夺工作流控制面。第二，系统集成商不会因为模型更强而消失，反而可能在早期更重要，因为每家企业的身份体系、数据边界和责任链都不同。
但当前不能把 Presence 视为企业 Agent 已经跨过规模化门槛。75% 自报缺少独立复核，15 个百分点 / 10 天缺少起止值和长期观察，有限通用可用计划也说明交付仍需高强度人工参与。更稳妥的结论是：OpenAI 已把治理闭环做成明确产品命题，效果和经济性仍等待客户侧数据检验。
接下来最值得验证什么
第一看开放范围。若 Presence 从有限通用可用计划走向更广泛可用，OpenAI 需要说明企业资格、地区和行业限制，也要回答哪些环节能自助配置，哪些仍必须由部署工程师或集成商完成。
第二看指标定义。客户案例若只重复 75%，信息增量有限。真正有价值的是公开样本规模、问题组合、首次联系解决率、重复联系率、客户满意度、误操作率和人工节省时间，并给出升级前后的同口径对比。
第三看审计能力。企业需要知道每次工具调用使用了什么身份、读取了哪些数据、为何执行某个动作、谁批准了变更，以及事故发生后能否导出完整记录。缺少可导出的审计链，治理只能停留在供应商界面里。
第四看改进闭环是否安全。Codex 提出的更改应有明确版本和评估结果，能在小流量灰度，并在风险指标恶化时自动回滚。尤其要防止团队只优化转交率，导致 Agent 为了“少转人工”而承担超出授权范围的动作。
第五看总拥有成本。Presence 的定价尚未在采集材料中披露，模型费用只是其中一项。连接器、数据清理、权限治理、评估维护、坐席接管和集成商服务加总后，才能判断它相对传统客服自动化或企业工作流软件是否形成可持续优势。