OpenAI Presence 的巧思：把 agent 的判断放进会话之外

OpenAI 在 2026 年 7 月 22 日发布 Presence，把它定义为面向企业高频、高风险流程的托管式 AI agent 平台。当前公开版本支持语音和聊天，采用限量 GA，不能由企业自行注册后开通。123

Presence 值得看的地方，不是 agent 能接电话、查账户或执行操作，而是 OpenAI 没有把控制权塞进对话框。Presence 先把 agent 定义成一项具体工作，再在会话之外规定它能读什么、能做什么、何时需要审批、何时必须交给人。AI 的「聪明程度」因此不再是唯一的产品单位，权限、升级和版本也变成了用户可以管理的对象。

Presence 的每次部署都从一个具体工作开始，例如处理账单问题、协助保险理赔，或解决员工 IT 服务请求。OpenAI 的发布说明写得很明确：agent 只接收完成这项工作所需的知识和系统访问权限，企业再规定哪些动作可以自行执行、哪些动作需要批准、什么情况下应该由人接手。1

帮助中心把这套边界拆得更细。agent 可以遵循经过批准的 SOP 和组织政策，通过权限受限的 API 或工具读取信息、更新系统、完成已批准的动作；遇到政策、风险或流程要求人工判断时，转交给人，并为接手团队保留结构化上下文。2

这是一种很具体的交互选择：控制对象不是一条很长的系统提示词，而是一个岗位的工作范围。把「客服 agent」改成「处理账单争议的 agent」，系统就能围绕同一项工作配置知识、工具、审批和升级条件。产品经理审查的也不再是「它会不会回答得像人」，而是「它有没有拿到完成这项工作之外的权限」。

这个选择牺牲了开箱即用。帮助中心说明，Presence 不是把文档上传进去就能上线的产品，每次部署都要完成流程定义、系统接入、权限和政策配置、安全与法律审查、模拟测试、验收测试和受控发布。2 VentureBeat 也指出，当前部署由 OpenAI 的 Forward Deployed Engineers 或指定集成商带着客户完成，产品不提供自助式开通。3

代价很重，但边界更容易归责。一个通用 agent 出错时，团队很难判断是模型、知识库、工具权限还是流程设计出了问题；岗位级部署至少把问题压回一个可命名、可验收的工作单元。

Presence 没有把「上线后自行学习」当作主要卖点。上线前，团队可以用常见请求、边界案例和高风险场景跑模拟，评估 agent 是否达成目标、遵守政策、正确调用工具，并在需要时升级给人。帮助中心还列出会话记录、动作历史、质量信号、受控发布和回滚流程。12

上线后，生产会话、人工升级和质量信号会暴露出新的缺口。Presence 让 Codex 通过插件调查这些信号并提出更新，团队再把候选改动和当前生产版本对照测试，批准后进行受控发布。这个顺序可以写成一条清晰的操作链：发现问题，提出改动，跑模拟，人工批准，逐步上线。1

这套设计把 agent 的「学习」改成了软件团队熟悉的发布流程。模型可以参与找问题和写改动，但不能直接把自己的新行为推到线上。对于会改账单、处理理赔或访问员工系统的 agent，这个限制比单纯增加一个「人工接管」按钮更有用，因为团队能在行为变化发生前看见它、测试它，也能知道哪一次上线改变了规则。

代价同样明确：评估和监控会成为长期运营工作，分数也不自动等于安全。VentureBeat 提醒，OpenAI 展示的监控界面没有公开说明指标如何计算，也没有说明它们如何对应服务水平承诺；OpenAI 公布的电话支持数据也属于公司自报，尚未得到独立验证。3 这说明控制面能让变化更容易审查，却不能替团队决定什么叫「合格」。

OpenAI Presence 的设计判断很集中：先把 agent 缩小成一个有明确权限的岗位，再把它的改进变成需要测试和批准的版本。前者限制一次会话能做什么，后者限制系统在数周或数月后会变成什么。

对企业 AI 产品来说，这比给聊天框加一个更强的模型更接近实际难题。真正需要设计的不是 agent 能否完成一次演示，而是它的工作范围能否被说清，越界时能否把上下文交给正确的人，行为改变时能否留下可审查的记录。Presence 把这三件事放进同一套部署流程，换来的则是更高的接入成本和持续运营负担。