OpenAI Presence 真正值得关注的，不是企业又多了一个语音与聊天 Agent 产品，而是它重新划出了企业 Agent 平台的责任边界。生产系统不能只是模型接上一条电话线和几个工具。策略、身份、知识、批准动作、评测、升级与变更发布必须进入同一个控制循环。
OpenAI 于 2026 年 7 月 22 日发布 Presence，将它定位为面向合资格企业客户的部署型产品。目前采用有限 GA，由 OpenAI Forward Deployed Engineers 与指定系统集成商主导交付，并非自助式产品。Presence 把语音和聊天渠道与标准操作程序、护栏、批准动作、仿真、评测工具，以及由 Codex 辅助的改进流程组合在一起。
因此，企业真正该问的已不是“它说话像不像人”，而是两个更难的问题：平台愿意对生产控制循环中的哪些部分负责？哪些决定无论采用什么托管产品，都必须留在企业自己手里？
OpenAI 实际发布了什么
Presence 从一个明确岗位开始，例如处理账单问题、辅助保险理赔或解决员工 IT 请求。OpenAI 表示，Agent 只获得完成该岗位所需的知识和系统访问；企业设定它可以做什么、何时需要批准、何时必须交给人。
上线后，生产会话、质量信号和人工升级会暴露缺口。Codex 可以分析这些信号并提出更新建议，团队再把候选版本与生产版本比较、测试、批准并受控发布。这里最重要的动词是“批准”。官方描述的是辅助式改进闭环，不是 Agent 自行改写生产策略。
OpenAI 还报告，Presence 已用于其英文电话支持渠道。按照官方页面的自报数据，该渠道可以在无需人工介入的情况下解决 75% 的来电问题，改进流程在 10 天内将人工转接率降低了 15 个百分点。这组数字来自 OpenAI 对自有渠道的描述。页面没有披露外部审计、完整样本设计、置信区间或问题分布，因此它适合证明系统已经实际运行，不适合当作所有企业都能复制的效果基准。
设计伙伴的状态也需要克制表述。原文对 BBVA 和 IAG 使用的是“探索”，对 SoftBank 使用的是“测试”。这些信息说明产品正在真实场景中共同设计，不能改写成已经完成大规模生产部署。
企业 Agent 平台应该承担的六层责任
Presence 提供了一套可迁移的责任栈。即便企业评估的是别家产品或自建平台，也可以用这六层检查控制面是否完整。
一、统一渠道行为
语音和聊天有不同的交互节奏，但业务政策不能按渠道分裂。平台应统一身份、策略、升级、评测和版本发布语义，同时允许各渠道拥有自己的延迟、轮次、无障碍和展示规则。
支持多个渠道不是关键壁垒。让同一企业在不同渠道上保持一致行为，才是平台价值。
二、按岗位划定身份与上下文
Agent 应为具体岗位获得权限，而不是拿到一个泛化的“企业身份”。平台需要把每项任务绑定到最低限度的知识、工具、权限和客户上下文。OpenAI 在更广义的 Frontier 平台中明确讨论了 Business Context 与 Agent 身份访问管理；Presence 则通过岗位所需访问表达同一原则。
但真正的授权模型必须由企业决定。平台可以表达最小权限，却不能替一家银行决定退款上限，也不能替保险公司决定哪些理赔字段对某个岗位开放。
三、把政策变成可执行控制
“修改账户前先验证来电者”写在文档里还不够。运行时必须能够强制执行验证步骤、限制可用动作、请求批准并记录结果。
Presence 把政策、标准操作程序、护栏和批准动作列为不同组件，这个区分很重要。护栏处理交互是否越界；批准动作规定什么可以提交到业务系统；升级规则则决定平台不能安全完成时，如何把控制权交还给人。
四、把上线前评测做成发布门禁
仿真与 grader 不应只是一个可选仪表盘，而应进入发布流程。OpenAI 表示，Presence 会在上线前覆盖常见请求、边缘情况与高风险场景，并检查结果是否正确、是否遵守政策、工具使用是否合理、该升级时是否升级。
采购团队不能只看一个总通过率。更值得追问的是：测试覆盖哪些风险等级？用例如何版本化？评测集归谁所有？如何防止训练或调优过程污染评测？什么失败会阻断发布？自动 grader 如何与人工判断校准？
五、把人工升级当作正式状态
升级给人不等于 Agent 失败，而是系统识别到了边界。成熟平台应把当前上下文、已尝试动作、命中的政策、证据和升级原因一起交给人工队列，并定义人工处理后 Agent 是否以及如何恢复。
这与 MCP Elicitation解决的是同一类控制流问题：暂停、追问和恢复必须成为工作流中的正式状态，而不是对话中的临场发挥。
六、控制上线后的持续改进
产品、政策和用户行为都会变化，生产轨迹也会暴露上线前没覆盖的失败模式。平台应把信号变成变更提案、回归测试、与当前版本的比较、审批、灰度发布，以及必要时的回滚。
这是 Presence 发布中最有分量的部分：Agent 运营从“改 prompt”转向版本化变更管理。平台负责提供机器，企业负责定义验收标准。
企业不能外包的五种控制权
托管平台可以运行闭环，但不能接走客户的问责。至少五类控制必须留在企业。
业务政策权。 供应商可以编码政策，但什么是政策、谁能修改政策，必须由企业决定。
业务系统权限。 工具访问最终应来自企业身份、数据分级和职责分离规则，不能让供应商集成的便利性变成授权真相源。
风险接受与升级阈值。 哪些错误可以承受，哪些动作必须批准，什么情况应立即停止，属于企业的风险决定。
证据留存与事件响应。 企业需要把 Agent 日志接入自己的安全、合规和调查流程。产品内可观测性不能替代企业自己的证据计划。
退出与连续性。 企业要能导出政策、评测用例、动作定义、轨迹和运营知识。平台不能成为组织唯一知道“客服流程如何工作”的地方。
一套面向 Presence 与同类产品的采购检查
官方发布仍留下不少商业与技术空白：页面没有公开价格、SLA、详细留存行为、完整权限模型、模型版本固定策略、回滚目标、评测数据所有权或退出机制。对有限 GA、FDE 主导的产品而言，这些内容可能通过售前设计和合同回答，而不是写在公开网页上。
采购团队可以围绕可交付证据组织尽调：
| 控制领域 | 应要求的证据 |
|---|---|
| 岗位边界 | 一项工作流中知识、工具、身份、动作、批准与升级路径的完整地图 |
| 评测 | 版本化测试集、风险覆盖、grader 校准、阻断阈值和历史回归结果 |
| 生产控制 | 动作日志、政策判定、人工接管记录、回滚程序和事件预案 |
| 变更管理 | 每次行为或政策更新的差异、批准者、发布范围与回滚触发器 |
| 数据治理 | 本次部署的留存、区域处理、导出、删除、加密与访问控制承诺 |
| 可迁移性 | 政策、测试、动作 schema、轨迹与运营文档的导出格式 |
目标不是要求供应商公开全部实现，而是确保每项高影响能力都有可观察产物和明确责任人。
不要把 Presence、Frontier 与 Workspace Agents 混成一个产品
OpenAI 当前描述了多个企业 Agent 入口。Presence 是面向具体业务流程、由团队交付的语音与聊天产品；OpenAI Frontier被定位为连接业务上下文、Agent 执行、评测、治理和可观测性的更广义平台；Workspace Agents则是供团队在 ChatGPT 与连接工具中构建和分享重复性 Agent 的研究预览产品。
它们可能共享基础设施和设计原则，但公开资料不足以证明它们是同一个 SKU，也不能据此推断某个产品文档中的每项控制会自动出现在另一个产品里。企业需要评估自己真正购买和部署的那一项。
这也与站内的 Agent Cloud 架构分析形成清晰分工。Agent Cloud 关注推理、状态和执行位置；Presence 关注业务工作流上线之后如何被治理、评测与改进。
平台拥有闭环，企业拥有授权
Presence 指向了一个合理方向。模型和渠道会持续变化，但生产系统仍需要稳定岗位定义、受限访问、可执行政策、可测量行为、人工升级和受控更新。
最好的企业 Agent 平台，不是声称自治程度最高的平台，而是能让每一次自治升级都变得清楚：改了什么，什么证据支持这次变化，谁批准了它，Agent 现在多了哪些权限，以及企业如何撤回这项决定。
这就是恰当边界。平台应该拥有生产控制循环；企业必须保留允许这个循环采取行动的授权。
FAQ
OpenAI Presence 已经全面开放了吗？
没有。OpenAI 将它描述为面向合资格企业客户的有限 GA，部署由 FDE 与指定系统集成商主导，目前不是自助式产品。
Presence 同时支持语音和聊天吗？
支持。2026 年 7 月 22 日的官方发布称，Presence 面向客户与内部工作流提供实时语音和聊天体验。
Presence 会在生产环境里自行修改自己吗？
官方描述是 Codex 根据生产信号提出更新建议，团队测试候选版本、与生产版本比较，并批准受控发布。这属于辅助式变更管理，不是无限制的自主修改。
哪些控制应该永远留在企业？
业务政策、系统权限、风险阈值、审计留存、事件响应和可迁移性都应由企业掌握，即使 Agent 平台由供应商托管。
参考资料
- OpenAI：Introducing OpenAI Presence，2026-07-22。
- OpenAI：OpenAI Frontier。
- OpenAI：Workspace agents for business。
- OpenAI：Security and privacy。