OpenAI Presence：企业买到的是托管式 AI 智能体部署，不是自助工具

OpenAI 表示，Presence 已能在其英语电话支持专线上独立解决 75% 的来电问题；通过持续改进闭环，转交人工的比例又在 10 天内下降了 15 个百分点。但支撑这些数据的 OpenAI Presence，并不是注册后即可使用的智能体搭建工具，而是一套企业级托管部署：从智能体、策略、评测和系统集成，到后续运营工作，都由同一个项目承接。

结论：OpenAI Presence 卖的是部署，不是模型

如果面向客户的语音或聊天流程需要在严格策略约束下执行真实操作，而且采购方希望 OpenAI 分担部署责任，那么 OpenAI Presence 值得考虑。反过来，对想找自助式智能体搭建工具的小团队、需要 SDK 的开发者，或尚未选定一个边界清晰且值得负责到底的工作流的企业来说，Presence 都不是合适的起点。

发布条款透露的信息非常关键：Presence 目前仅向符合条件的企业客户有限开放。项目由 OpenAI 的前线部署工程师和入选的全球系统集成商主导，OpenAI 也明确说明它不是自助式产品。无论发布页面还是当前的 Frontier 页面，都没有公开定价。

这意味着，交付模式本身就是产品。前沿模型早已能够理解客服请求，真正困难的是：向它提供正确的账户上下文，限制权限，落实退款策略，验证执行结果，判断何时必须审批，把高风险案例转交给人工，以及在不破坏既有行为的前提下更新系统。Presence 把这些工作打包成一项托管服务。

OpenAI Presence 实际包含什么

Presence 围绕一项明确任务搭建生产级系统，并不是无所不能的“数字员工”。每次部署都从一个具体工作流开始。智能体只获得完成该任务所需的知识和系统权限，客户则负责定义业务策略、审批节点和人工接管规则。

护栏（guardrail） 常被理解为模型生成回答之后再加一道过滤。Presence 中的含义更广：它是一套约束输入、工具、操作、权限和升级路径的控制体系。Presence 将业务规则与标准作业程序、护栏、已批准操作、模拟、评测工具，以及由 Codex 驱动的改进流程组合在一起。

1. 1

   限定一项完整任务

   选择一个能闭环的结果，例如解决账单问题、协助处理保险理赔，或响应员工 IT 请求。“帮助所有客户”这类宽泛指令，既无法产出有效的评测集，也无法划出可辩护的权限边界。

2. 2

   限制上下文和访问权限

   只连接该任务必需的记录与系统。账单智能体可能需要身份、账户、发票和付款信息，但它不需要不受限制地访问全部客户数据。

3. 3

   写入策略和审批规则

   明确智能体可以回答什么、能够执行哪些操作、何时必须申请批准，以及何时由人工接管。回答内容正确但操作未经授权，依然算生产失败。

4. 4

   上线前先做模拟

   用评分器检查常见请求、边界案例和高风险场景。OpenAI 表示，检查范围包括结果质量、策略合规、工具使用和升级行为。

5. 5

   在变更控制下持续改进

   生产会话、升级案例和质量信号会暴露缺口。Codex 调查这些信号并提出更新建议；团队可以先与生产版本对照测试，再批准受控发布。

真正重要的不是演示，而是闭环。语音智能体上线当天可能听起来很自然，但产品一有变化、退款政策出现新例外，或来电者换一种原始测试集从未覆盖的说法，它仍可能失败。Presence 把生产行为视为改进建议的来源，并在建议与在线系统之间加入测试和审批。

对客服负责人来说，这正是聊天机器人与工作流操作系统之间的实际区别。聊天机器人负责回答；生产级智能体还要验证、决策、在授权范围内行动、记录过程，并在风险超出权限时转交人工。

现有证据值得关注，但覆盖面仍窄

发布材料证明 Presence 能够运行真实的客服渠道，但还不足以证明它能为一般企业带来回报。OpenAI 公布的数据来自自家的英语电话支持专线 1-888-GPT-0090，因此它既是有价值的产品证据，也是供应商自行报告的证据。

设计合作伙伴的项目还处于更早阶段。BBVA 正在墨西哥探索面向日常银行业务的语音支持；SoftBank 正在测试自然的日语客户对话；IAG 则探索在恶劣天气等需求激增事件中提供帮助。这些项目体现了多语言和受监管工作流的覆盖广度，但 OpenAI 并未把它们描述为同等水平的生产成果。

发布材料也没有提供采购团队必需的数据：公开价格、实施周期、最低业务量、支持模式、按操作拆分的错误率，以及每次正确解决问题的成本。在有限开放阶段，这种缺失可以理解，却也意味着目前没有可信的公开成本对比。没有合同和工作流基线支撑的精确 ROI 说法，都只是臆测。

Presence 在 OpenAI 智能体产品栈中处于哪一层

在 OpenAI 的产品体系中，Presence 是托管工作流这条路线；同一体系还包括 ChatGPT Workspace Agents、OpenAI Agents SDK 和 Frontier。把这些名称混为一谈，会让采购从一开始就走偏，因为每条路线的责任归属完全不同。

ChatGPT Workspace Agents：可重复的内部工作

ChatGPT Workspace Agents 是更轻量的选择，适合原本就在 Business 或 Enterprise 工作区内开展的可重复任务。创建者可以选择模型和推理强度，连接应用与工具，把智能体发布给同事，在 Slack 中使用，设置定时任务，或通过 API 触发。

这里的控制措施并非摆设，但执行边界更窄。应用和连接器的写操作默认设为 Always ask。Connector Action Constraints 可以限制集成能够执行的操作，不过 OpenAI 特别指出，这些约束不会过滤连接器返回的数据。每个文件上限为 512 MB，每个智能体的文件总量上限为 10 GB。

API 的决定性限制来自运营层面：触发请求只会把一次运行加入队列，并返回不含响应正文的 202 Accepted。它不返回运行 ID，目前也无法通过该 API 取回结果。这种模式可以用于发出后无需跟进的内部任务，却不适合需要同步状态、重试逻辑和可追踪结果的客户产品。

OpenAI Agents SDK：定制产品由企业自己掌控

如果企业希望把智能体放进自己的产品或基础设施，OpenAI Agents SDK 更合适。OpenAI 的智能体构建指南把架构归纳为三个核心组件：负责推理的模型、负责读取或执行操作的工具，以及定义行为的指令。

这些组件只是系统的核心，构建方仍需负责身份、授权、工具契约、评测数据、监控、降级行为、事故响应和成本。OpenAI 建议先用能力最强的模型建立评测基线，再在准确度仍可接受的环节替换成更小的模型。它还建议，先把单智能体的能力发挥到极致，再引入多智能体架构。

当工作流能为产品形成差异化、部署约束不同寻常，或业务需要精细调节模型与工具成本时，定制路线才是正确选择。如果重视供应商可迁移性，抽象层必须设计在任何单一供应商的 SDK 之上。仅仅选择某个 SDK，并不会自动获得可迁移性。

OpenAI Frontier：企业范围的平台

OpenAI Frontier 面向需要跨部门、跨系统运行大量智能体的企业，是覆盖范围最广的平台路线。其公开架构包含业务上下文、智能体执行、评测与优化，以及企业安全与治理。

Frontier 旨在通过一个平台治理客户自建、OpenAI 提供和第三方提供的智能体。OpenAI 描述的能力包括智能体身份与访问管理、明确权限、操作审计、监控和详细日志。其 Enterprise Frontier Program 还会安排前线部署工程师与客户共同设计架构、推动治理落地，并让智能体进入生产环境。

实际的产品地图并不复杂：Workspace Agents 封装内部智能体体验，SDK 提供构建模块，Presence 交付已部署的工作流，Frontier 则提供企业控制平面。OpenAI 尚未公开说明 Presence 项目会包含哪些 Frontier 组件的合同对应关系，采购方应直接询问，而不是自行推断。

如果还想了解 OpenAI 之外的整体市场，可以在2026 年最佳 AI 智能体中比较企业平台及其运营取舍。

哪些企业适合买 Presence，哪些应该自建

当工作流边界清晰、价值高、需要执行操作，而且出错代价昂贵时，可以购买 Presence。若智能体属于战略性知识产权，运营约束非同寻常，或长期控制权比托管上线更重要，则应自行构建。

Presence 尤其适合策略要求繁重的服务流程。以恶劣天气期间处理理赔进度来电的保险公司为例，智能体必须识别来电者，调取正确的保单和理赔信息，区分查询进度与提出变更，只在授权范围内行动，并在风险升高时把案例交给人工。自然语言只是其中一环，访问控制与升级机制才决定工作流是否安全。

当智能体本身能创造竞争优势时，自建更胜一筹。垂直软件公司可能需要专有工具、行业评测集、独特用户体验、对多个模型供应商的支持，或在托管服务无法适配的环境中部署。此时，把运营闭环外包出去，也可能连产品团队本应掌握的学习能力一起外包。

从不同运营角色看，答案也会变化。中型企业 CTO 面对策略复杂的客服队列，又不想长期组建智能体运营团队，有充分理由试点 Presence。若已获融资的创始人打造的产品本身就是智能体，通常应掌握架构和评测数据。资深运营负责人要自动化内部审批，应先考虑 Workspace Agents 或确定性工作流。个人技术开发者则更适合 SDK 路线，因为 Presence 既不是自助式产品，也不是为轻量实验设计的。

不要因为 LLM 能理解输入，就贸然构建智能体。如果规则引擎可以可靠决策，语言层只负责收集结构化字段，就应继续采用确定性决策。只有在确实需要处理模糊性的地方，才引入概率推理。

签约前，必须拿到工作流评分卡

试点应按正确结果和受控失败来评判，而不是看对话听起来多像真人。75% 的解决率很适合做标题，但合同中的定义必须经得起财务、风控和运营团队的检验。

至少跟踪以下指标：

• 正确解决率： 符合条件的客服接触中，准确完成的占比，而不是仅统计未转人工就关闭的会话。
• 错误结案率： 回答错误、操作错误或需求尚未解决，却被标记为已完成的客服接触占比。
• 策略合规： 智能体是否遵循当时适用的规则和审批路径。
• 工具执行质量： 读写操作是否指向正确记录、使用正确参数，并产生预期的状态变化。
• 升级质量： 高风险或不确定案例是否连同继续处理所需的上下文被交给了正确人员。
• 每次正确解决的成本： 合同、模型、集成、审核和支持成本之和，除以经验证的成功结果数。
• 延迟与放弃率： 正常和高峰需求下的响应时间表现，以及来电者是否在问题解决前离开。
• 变更安全性： 策略或 prompt 更新建议能否改善目标案例，同时不让已稳定的案例退步。

分母非常重要。系统可以只接手简单请求、把所有高成本请求都转交人工，从而提高自动解决率；也可以关闭后来会再次打开的对话，虚增解决率。应按意图、操作类型、风险等级、语言和渠道拆分结果，避免汇总数字掩盖代价高昂的失败。

1. 1

   选定一个完整结果

   用业务语言定义任务，包括从哪里开始、怎样才算正确结束、允许执行哪些操作，以及哪些情况必须交给人工。

2. 2

   建立评测集

   使用真实策略文件和经过脱敏的历史模式，覆盖正常请求、模糊表达、信息缺失、对抗性措辞、策略变化和高风险边界案例。

3. 3

   制定权限矩阵

   列出所有工具操作，并按可逆性、权限、财务影响和客户伤害进行分类。在证据足以支持扩大边界之前，高风险或不可逆操作必须保留人工监督。

4. 4

   与现有流程并行运行

   在允许智能体修改在线记录之前，先把它建议的回答、操作和升级方式与当前运营结果比较。遇到分歧要查明原因，而不是用平均值掩盖问题。

5. 5

   按已验证意图逐步扩展

   把已经证实的请求类型分批、受控地投入生产。保留可立即回滚的路径；任何策略、工具或指令变更上线前，都必须通过回归测试。

采购方还应在上线前明确责任归属。必须有人批准策略变更、复盘事故、维护集成、管理评测集，并决定何时扩大智能体权限。Presence 可以提供技术与部署专长，却无法免除企业对工作流结果的责任。

战略判断

OpenAI Presence 的重要之处，在于它把企业级智能体的销售重点从模型访问转向运营责任。承诺不再只是“使用我们的智能”，而是“由我们协助运营受治理的工作流，并在上线后持续改进”。

相比又一个通用智能体搭建工具，这是一种更有分量的产品形态，但它也让客户更深地依赖 OpenAI 的部署团队、模型、改进流程和合同。当托管上线的速度与共享的运营经验，胜过掌控系统本身的价值时，这种交换是合理的；若工作流本应沉淀为自有能力，它就会变成代价高昂的依赖。

因此，最关键的采购问题不是 Presence 看起来够不够聪明，而是：谁对结果负责，谁控制每项操作，谁证明更新是安全的，以及智能体失败时谁来接住工作流。如果合同回答了这些问题，试点也验证了经济性，Presence 就能缩短企业采用智能体最艰难的一段路。否则，不如构建一个范围更窄、能够测量且真正由自己掌控的系统。

OpenAI Presence 是自助式产品吗？

不是。OpenAI 表示，Presence 仅向符合条件的企业客户有限开放。项目由前线部署工程师和入选的全球系统集成商主导，发布页面也引导采购方联系自己的 OpenAI 客户团队。

OpenAI Presence 与 ChatGPT Workspace Agents 有什么区别？

Workspace Agents 是在 ChatGPT 内构建并共享的智能体，用于可重复任务，支持应用、工具、Slack、定时运行和 API 触发。Presence 则是面向实时语音与聊天工作流的托管生产部署：它会调用企业系统、执行受治理的操作，并在需要时升级给人工。

OpenAI 是否公开了 Presence 的价格？

无论 2026 年七月 22 日的发布页面，还是当前的 Frontier 产品页面，都没有公开定价。有参考价值的报价必须对应一个明确工作流，并与业务量、集成范围、支持模式和可衡量的成功标准绑定。

企业应该购买 Presence，还是自建智能体？

如果一个策略复杂的语音或聊天工作流需要托管部署，而且企业接受 OpenAI 成为深度运营伙伴，可以购买。若智能体能形成产品差异化、架构控制具有战略价值、部署约束非同寻常，或模型可迁移性和单位经济性比托管速度更重要，则应自建。

如果正在权衡购买托管智能体还是自行掌控系统，请先画清工作流和风险边界，再开始构建。