夜雨聆风摘要：OpenAI 在 2026 年 7 月 22 日发布 OpenAI Presence，一个面向企业的 AI Agent 部署产品。它支持语音和聊天 Agent，主打客服、销售外呼和内部高风险流程。其中值得关注的，是 OpenAI 正在把 Agent 从「模型能力」做成一套可交付、可评测、可控升级的企业系统。
2026 年 7 月 22 日，OpenAI 发布了 OpenAI Presence。
官方给它的定位很清晰：一个经过企业场景验证的产品，用来把 AI Agent 放进客户和内部工作流里。它可以回答问题、处理事务、调用公司系统、执行经过批准的动作，并在需要时升级给真人。
Presence 真正释放的信号：Agent 的竞争，已经从「模型有多聪明」走向「能不能嵌入企业工作流」。
模型负责推理，Presence 负责把推理放进真实业务里。这里面包括权限、策略、评测、仿真、guardrails（边界约束）、人工接管，以及上线后的持续改进。
换句话说，OpenAI 这次卖的核心能力，是一套让 Agent 在企业里「可部署、可监督、可更新」的生产系统。
Presence 到底是什么
OpenAI Presence 目前支持语音和聊天 Agent。官方列出的典型场景包括客户支持、销售外呼，以及风险较高的内部工作流。
比如，一个客户打电话来处理账单问题。Presence 背后的 Agent 需要理解请求，验证客户身份，查找账户信息，按照公司政策判断能不能退款或调整账单，然后执行获批动作。遇到超出权限、信息不足或风险较高的情况，它要把问题交给真人。
这件事听起来像客服机器人升级版，但难点并不在「回答得像人」。真正难的是：它能不能按企业政策办事，能不能只访问该访问的数据，能不能知道什么时候停下来，能不能在业务变化后及时更新。
OpenAI 在官方博客里反复强调一个设计原则：每个部署都从一个具体 job 开始。
这个 job 可以是处理账单争议，可以是支持保险理赔，也可以是解决员工 IT 服务请求。Agent 只拿到完成这个 job 所需的知识和系统权限。公司则定义三件事：它能做什么，什么时候需要审批，什么时候必须交给人。
很多人讨论 Agent，容易从「通用智能」开始想象。但企业真正会买单的，往往是边界清楚、责任清楚、效果能衡量的工作单元。Presence 的起点很务实：先让 Agent 在一个高价值流程里稳定工作。
第一个信号：Agent 的核心瓶颈在系统，不只在模型
过去一年，企业对 Agent 的态度已经变了。
早期大家会问：模型能不能理解用户？能不能调用工具？能不能一步步完成任务？
现在问题变得更苛刻：能不能在生产环境里可靠地做高价值工作？业务政策变了以后，Agent 能不能跟着改？用户行为变了以后，团队能不能发现问题、测试修改、控制上线？
这也是 Presence 的切入点。
官方列出的组件很能说明问题：政策和标准操作流程、guardrails、已批准动作、仿真、评测工具，以及由 Codex 驱动的改进流程。
这些词放在一起，其实构成了一条企业 Agent 的生产链路：
这里最关键的变化，是把 Agent 当作一个持续运行的业务系统来管理，prompt 只是其中一部分。
一个真实企业里，产品会改，政策会改，用户也会用新的方式提问。上线只是开始。真正的工程问题，是上线后如何发现缺口、提出修改、测试新版本，再由团队批准灰度发布。
Presence 把这个循环产品化了。
官方说，生产会话、人工升级和质量信号会暴露 Agent 的问题。Codex 可以借助 Presence plugin 调查这些信号并提出更新。团队再把 proposed change 和生产版本对比测试，最后批准受控发布。
这说明 Codex 在这里已经进入 Agent 运营系统：它帮助团队维护 Agent 的行为策略、评测和改进。
第二个信号：OpenAI 在卖「交付能力」
Presence 目前还没有自助入口。
官方写得很清楚：它面向符合条件的企业客户，以 limited general availability 的方式提供；部署由 OpenAI Forward Deployed Engineers 和特定全球系统集成商主导。
Forward Deployed Engineer，简称 FDE，可以理解为深入客户现场的工程团队。他们会和客户一起拆流程、接系统、设权限、做评测、推上线。
这对 OpenAI 来说，是一个很有意思的方向。
API 的商业逻辑，是把模型能力开放给开发者。Presence 的商业逻辑更像企业软件和咨询交付的结合：先找到高价值工作流，再把知识、系统、权限、政策、评测和上线流程接起来。
为什么要这么重？
因为企业 Agent 的失败，常常不发生在演示视频里，而发生在边界上。
它可能答对了普通问题，却在退款政策变化后继续用旧规则；它可能会调用系统，却在权限范围上拿得太宽；它也可能一路尝试解决问题，却没有在该交给人的时候停下来。
所以 Presence 的重点，是让企业能规定 Agent 的行为，并在运行中不断修正它。
这也是我认为这次发布值得关注的地方：OpenAI 正在把「模型公司」的一部分能力，包装成「企业 Agent 交付公司」的能力。
第三个信号：可信 Agent 需要上线前、上线中、上线后的三段控制
OpenAI 把 Presence 的信任机制分成了三个阶段。
上线前，团队可以用常见请求、边缘案例和高风险场景测试 Agent。仿真和 grader（自动评分器）会检查它是否达成正确结果、遵守政策、正确使用工具，并在该升级时升级。
上线中，guardrails 会在交互越过公司边界时介入。这里的边界可以是内容边界，也可以是权限边界和业务规则边界。
上线后，生产会话、升级记录和质量信号会继续反馈问题。团队可以看到 Agent 哪里工作得好，哪里需要关注。Codex 提出修改建议后，团队测试并批准，最后进入受控发布。
这三段控制，比「给 Agent 加一段安全提示词」要扎实得多。
企业真正关心的，是 Agent 在持续变化的业务里能不能被管理。一个 Agent 如果不能被评测、不能被回滚、不能被审计、不能被人类接管，就很难承担高价值流程。
Presence 把信任放进部署流程里，减少企业只依赖模型承诺的风险。
官方案例：75% 自动解决率，但要看清口径
OpenAI 在博客里给了一个自己的内部案例。
Presence 支撑了 OpenAI 的英文电话支持渠道，号码是 1-888-GPT-0090。它可以处理开放式请求、验证来电者、使用账户上下文，并执行经过批准的动作。
OpenAI 称，Presence 在几周内达到或超过了其用于评估一线人工支持质量的基准。现在，它可以在无需人工协助的情况下解决 75% 的入站问题。配合发布团队后，由 Codex 驱动的改进循环还在 10 天内把人工转接减少了 15 个百分点。
第一，它来自 OpenAI 官方自述，不等于第三方审计结果。第二，电话支持是 OpenAI 自己非常熟悉的业务，它能拿到完整产品知识、账户系统和内部协作资源。第三，能在 OpenAI 场景跑通，不代表每家企业复制起来都一样快。
更稳妥的读法是：这说明 Presence 已经在真实生产场景中承担了一部分一线支持工作，并且 OpenAI 认为这个路径可以复制到更多企业。
官方也列了三家企业案例：
这里的措辞都很克制：exploring、testing、exploring。也就是说，它们更像设计伙伴和早期部署方向，距离「已经全面替代人工客服」还很远。
冷静边界：Presence 仍非随手可用的 Agent 平台
Presence 最容易被误读成「OpenAI 发布了一个企业 Agent 平台，大家马上都能用」。
官方信息并不支持这个判断。它现在只面向符合条件的企业客户，通过 limited general availability 提供。它也还没有自助入口，需要 OpenAI 的 FDE 和系统集成商参与部署。
它更像一套高触达、高交付成本、高单客户价值的企业方案。
这条路线有优势，也有压力。优势是，OpenAI 可以深入真实业务，把 Agent 从 demo 推进到生产，并从每个部署中积累通用洞察。压力是，企业流程千差万别，权限系统复杂，历史系统难接，政策口径也常常很难靠一份文档讲清楚。
Presence 接下来要证明的，是 OpenAI 能不能把这种交付方式规模化，而非只做出少数标杆案例。
这件事比发布一个新模型更慢、更重，也可能更接近企业 AI 落地的真实形态。
为什么这件事值得关注
如果把过去几年的 AI 产品放在一条线上看，会看到一个清晰变化。
第一阶段，大家追逐更强的模型。第二阶段，模型开始调用工具、连接系统，Agent 成为关键词。第三阶段，企业开始问一个更朴素的问题：这个 Agent 能不能安全、稳定、可控地替我干活？
它把很多不性感但关键的东西摆到了台前：权限、审批、评测、仿真、升级、变更管理、人工接管。对于企业来说，这些东西往往比模型打榜和炫技更重要。
Agent 真正进入生产线的标志，是企业敢让它执行一个动作，并且知道这个动作如何被约束、被追踪、被纠正。
从这个角度看，Presence 短期内未必会改变所有人的工作方式。但它让一个方向变得更清楚：未来的企业 Agent，很可能会从孤零零的聊天窗口，变成一套被流程、权限和评测包住的业务系统。
普通用户看到的是一个会说话的 AI。企业真正需要的，是一个会按规则办事、出问题能交接、变化后能更新的 AI 同事。
OpenAI Presence 的价值，就在这里。
参考资料
OpenAI：Introducing OpenAI Presence，2026-07-22
