核心要点摘要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。灰度计划一次只改变少量因素至少保证权限和业务连接器不与模型候选同时扩大。对照指标也要按任务分层。订单查询关注事实和延迟退款申请关注参数与审批身份服务关注核验和拒绝。把所有任务合成一个平均分少量高风险错误会被大量简单查询稀释。灰度结束后保留可复算数据。若评分器随后调整团队可以用相同运行记录重新计算而不用重新接触客户。原始敏感内容仍按访问政策保存分析层只使用必要字段和引用编号。发布后七天的工程值守清单首日检查身份发放、工具拒绝和审计事件是否完整第二天检查重复调用与半成功事务第三天抽查人工接管上下文之后再看任务结果、投诉和版本差异。不要等周报才发现某类日志从上线时就没有写入。值守人员需要一条可以冻结新写操作的控制路径并知道冻结不会阻断已进入人工队列的服务。恢复时先开放只读和可撤销动作确认监控正常后再恢复高影响提交。一周后再决定是否扩大流量。若异常仍需工程师手工拼接多套日志说明可观测性尚未达到规模化条件即使当前业务结果看起来不错也应先补证据链。FAQQ1OpenAI Presence 是一个新的大模型吗A不是。官方将其描述为企业智能体平台模型只是其中一层平台还涉及政策、权限、业务系统连接、测试、监控和人工介入。Q2Presence 是否已经向所有开发者开放A官方当前使用面向符合条件企业、有限提供的表述。公开材料没有把它描述成可由所有 API 用户立即自助开通的通用服务。Q3上线前只测回答准确率够吗A不够。还应测试工具选择、权限遵循、审批、转人工、故障恢复和真实业务副作用。Q4Codex 可以直接修改生产 Agent 吗A官方提到 Codex 可辅助分析并提出改进建议。企业仍应让候选修改经过代码审查、回归评测和受控发布。官方来源Introducing OpenAI PresenceOpenAI2026-07-22OpenAI PresenceOpenAI Help Center2026-07-22OpenAI News RSS核对标题与发布时间内容更新时间2026-07-23证据边界Presence 的产品定位、语音与聊天场景、政策权限、系统连接、部署前测试、生产监控、人工介入和 Codex 辅助改进来自 OpenAI 官方材料字段、测试分类、指标和发布门槛是通用工程建议不代表 OpenAI 固定接口或默认配置。