核心要点摘要
- OpenAI Presence 是面向企业的托管式智能体平台，重点不是再提供一个聊天窗口，而是把语音和文字智能体的连接、权限、测试、监控与人工介入放进同一条生产链。
- 企业落地时应先定义任务合同，再设计工具权限；“能访问某套系统”必须拆成可读字段、可执行动作、审批条件和明确的转人工出口。
- 上线前的模拟评测要覆盖正常请求、边界请求、脏数据、工具失败和高影响动作，评分不能只看回答是否顺畅，还要看是否守政策、是否正确停下。
- 生产监控需要把会话、工具、审批、人工接管和业务结果关联到同一运行编号，避免只看到模型文本，却看不到一次任务到底改了什么。
2026 年 7 月 22 日，OpenAI 发布Introducing OpenAI Presence。官方把 Presence 定义为企业 AI 智能体平台，用于部署面向客户和内部工作流的语音、聊天智能体。OpenAI 帮助中心进一步说明，它覆盖构建、部署、运行和持续改进，适用于高流量、高影响的业务场景。
这次发布值得开发团队关注，因为它把一个长期被拆散的问题重新放到了一起。过去做客服 Agent，常见做法是模型团队负责提示词，业务团队提供知识库，集成团队接 CRM 或工单系统，安全团队最后补权限。每个模块都能运行，放到生产里却很难回答：Agent 为什么做了这个动作，谁批准的，失败后谁接手，哪个版本应该回退。
Presence 的官方描述里，政策和权限、业务系统连接、上线前测试、生产结果监控、人工判断都属于平台范围。它不是普通模型 API 的同义词，也不是把一段 prompt 托管起来就结束。企业真正要建设的是一条可追踪的任务执行链。
先把需求写成任务合同
智能体项目最容易从一个模糊目标开始，例如“自动处理账单问题”或“提高 IT 服务台效率”。这种说法适合立项，不适合授权。开发前应把目标改写成机器和审核人都能检查的任务合同。
任务合同至少包含八个字段：task_type表示任务类别；allowed_inputs定义可接收数据；knowledge_scope指定可检索知识；allowed_actions列出无需审批的动作；approval_actions列出必须经人确认的动作；handoff_reasons定义转人工原因；success_state描述完成条件；stop_state描述立即终止条件。
以员工账号解锁为例，Agent 可以读取账号状态和标准操作手册，可以创建身份核验流程，但不能自行更改管理员角色。验证失败、账号涉及高权限、用户描述与系统记录冲突时，任务转交人工。这样做的价值不在文档漂亮，而在于后续每条日志都有判断基准。
任务合同还要有版本。业务政策修改后，旧会话使用的是哪一版规则，必须可以还原。若团队只更新知识库或系统提示词，却没有记录发布版本，出现投诉时很难确认 Agent 当时依据什么作答。
工具权限不要停在“只读”和“可写”
OpenAI 的官方说明强调，企业可以定义智能体能够做什么、哪些动作需要审批、什么时候由人接管。落到接口层，仅用只读和可写两档权限通常不够。
一个 CRM 连接器可能同时包含读取客户资料、修改联系方式、创建退款申请、批准退款和关闭投诉。Agent 需要哪一个动作，就单独发哪一个短期能力。不要因为接口来自同一系统，就把整套服务账号交给运行环境。
建议为每次工具调用记录agent_run_id、conversation_id、policy_version、tool_name、action_name、resource_scope、approval_id、request_hash、result_code和side_effect_ref。其中side_effect_ref指向真实业务变化，例如工单号或事务编号。只保存自然语言摘要，不足以支持回滚和审计。
审批接口也要有超时和防重放。人工批准的是某个客户、某个金额、某个动作，而不是给 Agent 一张长期通行证。审批完成后若参数变化，原批准自动失效；同一批准令牌不能被重复使用。
模拟测试要覆盖不同失败路径
Presence 提到在部署前测试 Agent 行为，并结合企业政策、权限和人工介入。企业可以把测试集分成五类，而不是只准备一批常见问答。
第一类是标准任务，验证正常路径是否完成。第二类是边界任务，例如用户要求超出退款额度、请求查询他人资料，观察 Agent 是否拒绝或升级。第三类是数据冲突，知识库、CRM 和用户陈述不一致时，Agent 应说明冲突并停止高影响动作。
第四类是工具故障，包括超时、重复返回、部分成功、接口降级和权限失效。开发者要验证重试是否幂等，失败后是否留下半完成状态。第五类是对抗与社会工程，例如用户声称“主管已经同意”，或把指令藏在附件和工单备注里。评分器应检查 Agent 是否越过已定义的审批链。
如果需要比较不同模型在同一批脱敏样本上的任务完成、拒绝、工具选择和转人工差异，可以把不含客户原文、真实账号和生产凭据的样本通过 147AI 这样的多模型 API 接入层进行回归。Presence 的企业权限、业务连接、生产监控和人工接管仍属于 OpenAI 原生平台及企业内部系统，不能由外部模型比较链路代替。
生产监控要看结果，不只看对话
一个客服 Agent 说话自然，不代表业务执行正确。生产监控至少要关联四层信息：用户与 Agent 的会话；Agent 的计划与工具调用；审批、拒绝和转人工事件；最终业务结果。
指标可以分成质量、风险和运行三组。质量侧关注首次解决率、重复联系、人工改判和任务完成状态。风险侧关注越权请求、敏感字段暴露、审批绕过和错误写入。运行侧关注端到端延迟、工具超时、转人工等待和版本间差异。
不要把“转人工率越低越好”设成单一目标。某些高风险流程中，合理接管本身就是正确结果。更有用的指标是：该转时有没有转，不该转时是否因为知识缺口反复打扰人工，以及接管时上下文是否完整。
每次发布采用小流量版本号。新版本先处理内部员工或低风险队列，和当前版本比较业务结果与风险事件。触发越权写入、异常投诉、日志缺口或人工无法接管时，应自动停止扩大流量。
Codex改进建议也要经过回归
OpenAI 在 Presence 材料中提到 Codex 可帮助分析生产问题并提出改进建议。开发团队应把它理解为辅助排查和生成候选修改，而不是允许工具直接改生产规则。
一条生产异常先进入可复现案例，固定当时的任务合同、策略版本、工具返回和期望结果。Codex 或工程师提出修改后，先跑历史失败集，再跑全量回归，确认新规则没有修好一个场景却破坏另一个场景。
提示词、连接器映射、权限策略和评分器要分别版本化。只有提示词变化时，不需要重测所有基础设施；权限范围或工具参数变化时，则必须重跑副作用和审批测试。把变化类型分开，发布速度会更快，事故定位也更直接。
一套可执行的发布门槛
准备上线前，可以用六条门槛做最后检查：任务合同有明确成功与停止状态；工具权限按动作和资源收窄；高影响动作需要不可复用的审批；模拟测试覆盖边界、冲突和故障；生产日志能关联到业务副作用；人工接管在超时和异常时仍可用。
只要其中一条不能提供实际测试记录，就不应因为演示效果不错直接扩量。企业智能体的生产能力，不在于它能连续聊多久，而在于它做对时有证据、做错时能停下、交给人时不丢上下文。
策略变更要做兼容性迁移
业务政策更新时，团队常把新规则直接写进提示词或知识库。生产 Agent 还有正在进行的会话、待审批动作和排队工具调用，新旧规则切换并不是一次普通文本发布。
可以为策略定义effective_at、compatible_from和breaking_change。只修正文案、没有改变权限的版本，可让新请求立即采用；改变金额阈值、资源范围或审批人的版本，应停止创建旧版动作，等待在途事务完成或人工接管，再切换到新版。
每次迁移先统计旧策略下的活跃运行、未完成审批和长期会话。若新策略取消某项动作，旧审批不能继续生效；若只是收紧额度，也要重新核对已批准但尚未提交的参数。策略服务返回版本的同时，工具网关再次检查兼容性，不把判断只留给模型。
回归集要增加策略迁移场景：用户在版本切换前发起请求，切换后才确认；人工批准时规则已变化；通话断线重连后恢复到哪一版。系统应给出确定结果，而不是根据缓存命中随机使用新旧规则。
灰度发布需要独立的对照字段
灰度时不要只记录“实验组”和“对照组”。同一个 Agent 可能同时改变模型、提示词、知识、连接器或审批策略，如果这些变化共用一个版本号，指标波动后很难定位。
运行事件可分别保存model_release、prompt_release、knowledge_snapshot、policy_release、connector_release和evaluator_release。灰度计划一次只改变少量因素，至少保证权限和业务连接器不与模型候选同时扩大。
对照指标也要按任务分层。订单查询关注事实和延迟，退款申请关注参数与审批，身份服务关注核验和拒绝。把所有任务合成一个平均分，少量高风险错误会被大量简单查询稀释。
灰度结束后保留可复算数据。若评分器随后调整，团队可以用相同运行记录重新计算，而不用重新接触客户。原始敏感内容仍按访问政策保存，分析层只使用必要字段和引用编号。
发布后七天的工程值守清单
首日检查身份发放、工具拒绝和审计事件是否完整；第二天检查重复调用与半成功事务；第三天抽查人工接管上下文；之后再看任务结果、投诉和版本差异。不要等周报才发现某类日志从上线时就没有写入。
值守人员需要一条可以冻结新写操作的控制路径，并知道冻结不会阻断已进入人工队列的服务。恢复时先开放只读和可撤销动作，确认监控正常后再恢复高影响提交。
一周后再决定是否扩大流量。若异常仍需工程师手工拼接多套日志，说明可观测性尚未达到规模化条件，即使当前业务结果看起来不错，也应先补证据链。
FAQ
Q1：OpenAI Presence 是一个新的大模型吗？
A：不是。官方将其描述为企业智能体平台，模型只是其中一层，平台还涉及政策、权限、业务系统连接、测试、监控和人工介入。
Q2：Presence 是否已经向所有开发者开放？
A：官方当前使用面向符合条件企业、有限提供的表述。公开材料没有把它描述成可由所有 API 用户立即自助开通的通用服务。
Q3：上线前只测回答准确率够吗？
A：不够。还应测试工具选择、权限遵循、审批、转人工、故障恢复和真实业务副作用。
Q4：Codex 可以直接修改生产 Agent 吗？
A：官方提到 Codex 可辅助分析并提出改进建议。企业仍应让候选修改经过代码审查、回归评测和受控发布。
官方来源：Introducing OpenAI Presence（OpenAI，2026-07-22）；OpenAI Presence（OpenAI Help Center，2026-07-22）；OpenAI News RSS（核对标题与发布时间）
内容更新时间：2026-07-23
证据边界：Presence 的产品定位、语音与聊天场景、政策权限、系统连接、部署前测试、生产监控、人工介入和 Codex 辅助改进来自 OpenAI 官方材料；字段、测试分类、指标和发布门槛是通用工程建议，不代表 OpenAI 固定接口或默认配置。