OpenAI 推出 Presence，企业智能体开始接管客服与业务流程

OpenAI 在 7 月 22 日推出了新的企业软件 OpenAI Presence，把竞争焦点从“谁的模型更聪明”推向“谁能真正接管企业流程”。这套产品面向客服、销售、保险理赔和内部 IT 服务等场景，可以把 AI 智能体连接到企业数据、管理制度、现有软件及审批流程，并提供上线前测试、运行监控、人工接管和故障诊断能力。

Presence 目前并不是一款注册后即可自行开通的标准化 SaaS 产品。OpenAI 将根据客户具体情况提供服务，企业需要与 OpenAI 工程团队或官方指定合作伙伴一起完成部署和接入，价格也尚未公开。

这意味着 Presence 当前更接近一项高客单价的企业工程，而不是另一个 ChatGPT 套餐。OpenAI 真正想卖的，也不再只是 Token 和模型调用量，而是企业业务流程中的执行权。

Presence 是什么：不是聊天机器人，而是业务执行层

OpenAI Presence 是一套用于部署、管理和评估企业 AI 智能体的软件系统。它负责把模型连接到企业知识、业务工具和权限体系，使智能体不仅能够回答问题，还能读取订单、核对账单、更新客户关系管理系统、处理理赔材料，并在符合规则的前提下执行操作。

AI 智能体是能够理解目标、规划步骤、调用工具并持续执行任务的 AI 系统。传统客服机器人通常围绕固定问答和流程树工作，而智能体面对的是开放式目标，例如“解决这名客户的重复扣费问题”，它需要自行完成身份核验、订单查询、政策判断、退款操作和结果通知。

Presence 的价值不在于让客服话术更自然，而在于把“对话入口”和“后台处理”合并起来。过去，机器人可以告诉客户退款政策，却不能真正退款；接入 Presence 后，智能体可以在授权范围内查询交易、判断是否满足条件，并将退款请求送入审批或直接执行。

OpenAI 已经在内部使用 Presence 运行面向英语用户的 AI 电话客服系统。语音能力因此不是单独的演示功能，而是 Presence 进入真实服务场景的关键入口：客户通过电话描述问题，智能体在后台调用多个系统完成处理，必要时再把通话和上下文一起交给人工坐席。

企业智能体最难的不是推理，而是获得受控的执行权

Presence 试图解决的核心问题是权限，而不是单纯提高模型回答准确率。一个能够访问客户资料、退款系统和保险记录的智能体，必须知道自己能看什么、能改什么、什么操作必须审批，以及出现何种风险时应立即交给人类。

OpenAI 表示，Presence 中的智能体只会获得完成特定工作所需的知识和系统访问权限。企业可以规定智能体允许执行的动作、需要审批的任务以及人工接管条件，这实际上对应企业安全中常见的最小权限原则。

最小权限原则是仅向用户或系统授予完成当前任务所必需的访问能力。例如，一个处理账单疑问的智能体可以读取账单和付款状态，但不能修改客户合同；一个负责保险材料初审的智能体可以提取文件信息，但不能自行批准高额赔付。

安全护栏（Guardrails）是限制智能体输入、输出和操作范围的一组规则。它既可以阻止智能体泄露敏感数据，也可以拦截超出金额上限、违反地区政策或缺少必要材料的操作。

人工在环（Human-in-the-loop）是让人类保留关键决策权的智能体治理机制。Presence 可以让低风险任务自动执行，把高风险、低置信度或涉及例外政策的任务送给员工审核，而不是在“全部自动化”和“全部人工处理”之间二选一。

这套权限设计比模型跑分更能决定 Presence 能否进入大型企业。企业可以接受智能体偶尔答得不够漂亮，却很难接受它把退款打错账户、越权查看员工信息，或者在没有审批的情况下承诺赔付。

上线前先模拟，运行中持续评分

Presence 提供了一整套智能体测试与评估工具，企业可以在正式部署前模拟真实任务。模拟测试是使用预设或生成的业务场景，让智能体在隔离环境中完成任务，从而检查它是否正确调用工具、遵守规则并在异常情况下停止操作。

传统软件测试通常验证确定性结果，而智能体评估必须面对非确定性输出。同一个客户问题可能存在多种合理处理路径，因此企业不仅要判断最终答案是否正确，还要检查调用了哪些系统、是否索取了必要信息、是否触发审批，以及整个处理成本和耗时是否可接受。

Presence 支持安全护栏、人工审核和 AI 自动评分系统。AI 自动评分可以批量检查任务结果，但不应被理解为让一个模型无条件监督另一个模型；企业仍然需要使用真实业务指标和人工抽样，校准自动评分是否可靠。

一套可用的客服智能体评估体系至少应覆盖以下维度：

• 问题解决率：智能体是否真正解决问题，而非只生成一段看似合理的回复；
• 首次解决率：客户是否需要重复联系或转接人工；
• 规则遵循率：智能体是否完成身份验证、审批和记录留痕；
• 工具调用成功率：订单、支付、CRM 等系统是否被正确调用；
• 人工接管率：多少任务需要转交员工，以及转交是否发生在正确时机；
• 单次解决成本：模型推理、语音、工具调用和人工审核的总成本；
• 端到端延迟：从客户提出需求到业务系统完成操作所需的时间。

Presence 的产品思路是把智能体当作一名需要培训、考试和持续考核的数字员工。模型只是这名员工的“大脑”，企业数据相当于工作资料，工具连接决定它能做什么，而护栏、审批和审计记录构成管理制度。

Codex 开始扮演智能体运维工程师

Presence 把 Codex 引入了智能体故障排查流程。智能体正式运行后，如果任务失败或表现异常，Codex 可以分析执行过程、定位可能的错误来源，并提出改进建议。

Codex 是 OpenAI 面向软件开发和长周期任务执行的智能体产品。在 Presence 中，它的角色不只是编写代码，更像一名自动化运维工程师：检查工具接口是否变化、权限是否缺失、业务规则是否冲突，或者某个提示与最新政策是否不一致。

这种设计反映了企业智能体的一个现实问题：多数故障不会单纯来自模型。订单接口超时、字段名称变化、权限过期、知识库版本落后和审批节点配置错误，都可能让智能体无法完成任务，而普通业务人员很难从冗长的执行日志中迅速找到原因。

OpenAI 公布的内部数据也说明，Codex 正从编程工具变成长周期工作执行器。截至 2026 年 5 月，在抽样个人用户中，80.6% 至少发起过一次预计相当于人类工作 30 分钟以上的 Codex 请求，70.2% 发起过预计超过 1 小时的任务，25.6% 至少发起过一次预计超过 8 小时的任务。

Codex 在 OpenAI 内部的使用强度已经明显超过传统聊天工具。OpenAI 称，目前公司普通员工生成的输出 Token 中超过 85% 来自 Codex，而在每周输出 Token 总量中，Codex 占比达到 99.8%；截至 2026 年 6 月，使用强度位于前 1% 的用户平均每天会生成超过 60 小时的并行智能体运行时间。

这些数据不能直接证明 Presence 的可靠性，但可以解释 OpenAI 为什么把 Codex 放进企业智能体运维链路。OpenAI 正在把内部形成的“多个智能体并行工作、另一个智能体负责检查”的模式包装成企业产品。

Presence 与工作空间智能体并不完全相同

Presence 与 OpenAI 已经开放研究预览的工作空间智能体存在明显重叠，但两者面向的部署深度不同。工作空间智能体更侧重让员工通过自然语言创建共享智能体，并在 Slack、Google Drive、微软应用、Salesforce 和 Notion 等办公工具中执行调研、线索跟进及报表整理。

Presence 更接近企业级智能体运行与治理平台。它强调跨系统业务自动化、上线前仿真、细粒度权限、人工审批、自动评分、语音渠道和运行故障排查，目标是接管完整服务流程，而不只是提高员工个人生产力。

| 产品或方案 | 核心定位 | 主要使用者 | 典型任务 | 治理与评估 | 当前获取方式 | 公开价格 | |---|---|---|---|---|---|---| | OpenAI Presence | 企业智能体部署、运行和治理平台 | 客服、销售、保险、IT 运营团队 | 账单处理、理赔、电话客服、内部服务请求 | 模拟测试、Guardrails、人工审核、AI 评分、Codex 排障 | 按客户情况部署，需工程团队或合作伙伴参与 | 未公开 | | OpenAI 工作空间智能体 | 面向团队的可定制办公智能体 | 销售、财务、IT、产品和运营员工 | 调研、线索评分、报表、跨应用任务流转 | 角色权限、审计日志、审批关口、管理员集中管理 | ChatGPT Business、Enterprise、Edu 及教师版研究预览 | 随对应套餐 | | Zendesk 自主型 AI 智能体 | 面向客户服务的问题解决平台 | 客服与客户体验团队 | 多轮客服、问题分流、流程编排 | 质量护栏、推理评估、场景基准测试 | 通过 Zendesk 平台及试点项目提供 | 依企业方案而定 |

Presence 与 Zendesk 的竞争关系尤其微妙。Zendesk 每年处理的解决方案量已经超过 46 亿次，并在 OpenAI 模型基础上开发自主型客服智能体，目标是帮助客户逐步达到 80% 的自动化率。

OpenAI 此前主要向 Zendesk 提供底层模型，如今却开始直接提供客服智能体的部署、语音交互和流程治理能力。Presence 未必会立刻替代 Zendesk，因为成熟客服平台还拥有工单系统、行业模板、渠道管理和多年积累的客户关系，但两者的产品边界已经开始重叠。

OpenAI 正在从模型供应商变成企业软件厂商

Presence 的战略意义大于它当前能够覆盖的客户数量。随着 Anthropic、Google、xAI、Meta、Mistral 和 DeepSeek 持续推出新模型，模型性能差距正在缩小，推理价格也在下降，企业越来越有能力在不同供应商之间切换。

基础模型正在出现一定程度的商品化趋势。企业不会仅因为某个模型在单项基准上领先几分，就迁移整套业务系统；真正能提高迁移成本的，是权限配置、流程模板、评估数据、审计记录、系统集成和员工使用习惯。

Presence 正是在构建这层迁移成本。一旦企业把客服、销售和理赔规则写入 Presence，把内部软件接入其权限体系，并积累大量模拟测试与运行评估数据，更换底层平台就不再只是替换一个模型名称。

这也是 OpenAI 与生态客户发生冲突的起点。过去，不少企业软件公司购买 OpenAI 的模型能力，再自行封装成客服、销售和流程自动化产品；现在 OpenAI 开始直接提供智能体管理、渠道接入、业务编排和运行评估，这些原本正是应用层公司的核心价值。

OpenAI 的优势是模型、Codex、语音和 ChatGPT 企业客户可以形成统一产品组合。OpenAI 的短板则是缺乏垂直行业流程经验，尤其在保险、医疗、金融和大型企业 IT 环境中，项目成败往往取决于历史系统兼容、监管要求和组织协调，而不是模型本身。

Presence 目前仍是一项重部署服务

Presence 尚未公布标准价格、服务等级协议、支持地区、模型选择范围和通用上市时间。企业必须与 OpenAI 工程团队或指定合作伙伴合作接入，说明当前产品仍然依赖较多定制实施工作。

重部署模式有利于 OpenAI 控制早期风险，却会限制扩张速度。客服和理赔流程涉及大量遗留系统与例外规则，如果每个客户都需要工程师逐一梳理权限、数据结构和审批路径，Presence 的交付能力将成为比模型算力更直接的瓶颈。

企业评估 Presence 时不应只看演示中的自动化率。真正需要追问的是：失败任务由谁负责、审计日志保留多久、语音与客户数据存储在哪里、模型升级是否会改变智能体行为、能否切换模型、如何回滚版本，以及人工接管时能否完整保留上下文。

Presence 现阶段最适合规则相对明确、数据已经数字化、操作可以撤销的高频流程。账单查询、订单状态、密码重置、员工 IT 工单和标准退款通常比高额理赔、复杂投诉及受监管决策更适合率先自动化。

判断：它可能比新模型发布更影响 OpenAI 的收入结构

Presence 是 OpenAI 从“提供智能能力”转向“承担业务结果”的一次关键尝试。模型公司按调用量收费时，只需要证明回答足够好；企业软件按业务价值收费时，则必须证明问题确实被解决，并对权限、稳定性和事故处理负责。

这款产品短期内不会让客服部门完全无人化。更现实的变化是，一线员工从逐单处理转向监督异常任务，智能体负责大量标准请求，人类处理高风险、情绪化和规则之外的情况。

Presence 真正值得关注的指标不是生成了多少对话，而是自动完成了多少业务闭环。如果它能稳定完成身份核验、系统查询、规则判断、审批和操作留痕，OpenAI 就不再只是企业软件背后的模型供应商，而会成为企业运行系统的一部分。

这一步也会让 OpenAI 面临更高风险。模型答错一道知识题通常只会带来差评，Presence 执行错误则可能造成退款损失、合规事故和客户数据泄露；从聊天框进入核心流程，意味着产品价值更高，但责任也更重。

OpenAI 已经用 Presence 表明了方向：下一阶段的企业 AI 竞争，不再是给每名员工增加一个聊天窗口，而是让智能体获得受控权限，直接接管一段可以衡量结果的工作流程。

参考来源

• IT之家：OpenAI 推出 OpenAI Presence，布局企业软件赛道——介绍 Presence 的产品定位、部署方式、权限治理、测试评估、Codex 排障及语音客服能力。