一、引言Presence 的重点不是又一个聊天机器人2026 年 7 月 22 日OpenAI 正式发布 OpenAI Presence将其定位为企业级 AI Agent 运营与治理平台Enterprise AI Agent Platform。它支持语音与聊天两种通道面向客服、销售和内部 IT 服务等场景并可接入 CRM、工单系统等企业现有系统。如果只看这些功能Presence 很容易被理解为一套更完整的企业机器人方案。但真正值得关注的变化在交付方式上它不是注册账号、配置几项参数即可使用的自服务 SaaS而是面向大型企业由 OpenAI 的 Forward Deployed Engineers 参与并完成部署。Bain Company 也以合作伙伴身份提供支持。需要说明的是Bain Company 与 Bain Capital贝恩资本并非同一机构在缺少更具体披露的情况下本文不进一步推断其投资关系。这意味着 OpenAI 正在把自己的角色从 API 提供商扩展为托管式企业服务提供商。过去OpenAI 交付的是模型能力企业或集成商负责知识库、系统连接、权限、安全、评测和线上运营Presence 则试图把其中更多责任收进一个平台和一套服务体系。2026 年 5 月成立的 OpenAI Deployment Company为这种转向提供了组织层面的注脚企业落地不再只是模型销售之后的配套工作而开始成为独立能力。因此Presence 的价值不能只用“回答是否更聪明”来衡量。对生产环境而言一个 Agent 能回答问题只是起点它能否在授权范围内调用系统、遇到高风险请求时停止、把复杂案例转给人、在上线前经过足够测试并在上线后持续修正才决定它能不能真正承担业务。从这个角度看Presence 释放出的信号很明确企业 Agent 的竞争焦点正在从模型能力转向可运营、可控制、可评估的系统能力。二、核心能力先建立控制面再扩大自动化Presence 基于 GPT-5.6 系列模型但它强调的并不是单一模型指标而是“governance first”先管好 Agent再逐步放开能力。这套思路可以拆成四个相互连接的环节。1. 策略与权限治理把“能做什么”写成系统规则企业可以自定义 Agent 的操作范围、审批流程和人工接管规则。三者分别回答了生产部署中的三个基本问题Agent 可以访问哪些数据、调用哪些工具什么动作必须由人确认在什么条件下应停止自动处理并移交员工。这比提示词里的“请谨慎操作”更可靠。提示词是一种行为引导权限和审批才是控制面。例如一个客服 Agent 可以查询订单状态却不应默认拥有无上限退款权限内部 IT Agent 可以帮助重置普通账号密码但涉及管理员账号或异常登录时应进入人工审核销售 Agent 可以整理线索和生成建议却不应在未经确认的情况下自动承诺折扣。真正成熟的权限设计也不是“允许”与“禁止”的二元开关而是根据身份、金额、数据类型和风险等级分层。Presence 是否能把这些规则映射到复杂组织中的角色体系并保持策略一致性将比演示中的对话效果更重要。公开资料确认了它支持自定义治理但尚不足以判断其策略表达能力、审计粒度和跨系统权限同步的具体上限这些仍需企业在项目中验证。2. Guardrails安全不是拒答而是对越界行为及时干预Presence 的 Guardrails 会在交互超出企业预设边界时自动干预。这里的“边界”不应只理解为敏感词过滤。Agent 一旦连接 CRM、工单和其他业务系统风险可能来自错误身份识别、越权读取、未经审批的写入、承诺超出政策或者在信息不足时继续执行。因此有效的 Guardrails 至少要落到动作层什么信息可以展示什么工具可以调用调用参数是否合规执行前是否需要确认异常后是否立即中止。模型层的安全回答与系统层的权限控制需要同时存在前者减少不当输出后者限制真实影响范围。这也是“governance first”的现实含义Agent 越能行动治理越不能后置。企业不是先让 Agent 获得完整权限再根据事故补规则更合理的顺序是从只读、低风险、高可逆的任务开始用真实运行数据证明稳定性后再扩大授权。3. 模拟测试与评估从“看起来不错”转向可重复验收Presence 支持在部署前批量模拟常见请求和边缘案例并自动评分。这一能力解决的是 Agent 项目中经常被低估的问题几次人工试聊不能代表生产质量。客服请求可能包含信息缺失、情绪激烈、政策冲突、跨系统数据不一致销售场景可能遇到价格边界、地区限制和错误客户身份内部 IT 则可能涉及权限升级、设备丢失和安全事件。边缘案例出现频率不高却往往拥有更高的失败代价。批量模拟的意义是把这些情况变成可重复的回归测试。企业不应只记录“回答正确率”还应关注端到端任务成功率、错误工具调用率、人工接管率、越权拦截率、平均处理时长以及升级模型或修改策略后是否出现回归。自动评分可以提高测试规模但涉及政策解释、客户承诺和高风险动作时仍需要人工抽检避免让另一个模型的判断成为唯一标准。4. 持续改进学习线上问题不等于无条件在线自我修改Presence 能从线上交互中主动学习并自动标注不确定性案例。这使评测不再是上线前的一次性门槛而形成“运行—发现问题—标注—修正—再评测”的循环。其中最有价值的环节可能不是自动学习本身而是识别“不确定”。在企业服务里可靠地知道何时不该继续比勉强生成一个答案更重要。系统可以把低置信、规则冲突或未覆盖请求送入人工队列再将处理结果沉淀为新的测试样本。不过“持续改进”不应被理解为 Agent 可以不经审核地改变生产行为。策略调整、知识更新和新动作权限仍应经过版本管理、回归测试和审批。否则今天修复的一个案例可能成为明天新的系统性偏差。四项能力并不是独立功能而是一条闭环策略定义边界 → Guardrails 在运行时执行边界 → 模拟评估验证边界 → 线上不确定案例反哺下一轮策略与测试Presence 的产品成败很大程度上取决于这条闭环能否在真实企业系统中低摩擦地持续运转。三、场景分析同一个 Agent不同风险需要不同自动化等级语音和聊天双通道让 Presence 可以覆盖从呼叫中心到内部服务台的多种入口但“支持某个场景”不等于适合全自动处理。更合理的做法是按任务风险设计自治级别。场景适合自动化的任务应设置的边界建议人工接管条件客服查询订单、解释标准政策、创建工单、整理对话摘要身份验证、退款额度、隐私数据、补偿承诺复杂投诉、政策冲突、高金额操作、客户明确要求人工销售线索初筛、产品问答、会话记录、跟进提醒折扣权限、合同条款、客户数据访问范围非标准报价、法律条款、关键信息不完整内部 IT常见故障排查、知识检索、普通工单分流管理员权限、凭证处理、生产系统变更安全事件、权限提升、批量或不可逆操作以客服为例语音 Agent 可以先识别意图、查询订单并解释标准规则。如果客户要求的退款超过预设额度Guardrails 应阻止直接执行将上下文和已完成步骤一并交给人工坐席。这里的价值不只是“转人工”而是减少重复询问让员工从可继续处理的状态接管。销售场景的难点则不在回答产品问题而在承诺边界。Agent 可以提高响应速度却不能因为追求转化而突破折扣和合同政策。内部 IT 的风险更技术化一个能够调用工具的 Agent既可能节省大量一线支持时间也可能因错误授权扩大安全影响。因此Presence 最先产生稳定收益的区域很可能是高频、规则明确、结果可验证的流程而不是一次性追求端到端无人化。四、定价与商业模式企业租用的不是 token而是一套运营能力目前公开信息没有给出 Presence 的标准价格也没有可核验的按席位、按调用量或按任务报价。考虑到它面向大型企业、不是自服务 SaaS并由 Forward Deployed Engineers 参与部署更审慎的判断是现阶段定价未公开商业交付预计以项目制和企业合同为主具体成本应以 OpenAI 的实际方案为准。这与按 token 购买 API 有本质差异。API 模式下企业购买的是模型调用能力集成、评测、治理和运营成本分散在内部团队与外部供应商中Presence 模式下OpenAI 试图交付可运行的 Agent 及其控制体系。分析师将其概括为“enterprise agents you rent, not own”——企业租用 Agent而不是完整拥有自建技术栈。成本与责任自建 AgentPresence 式托管方案模型与编排企业自行选型、开发和维护以 GPT-5.6 系列及平台能力为基础交付系统集成内部团队或集成商负责OpenAI 部署团队深度参与治理与评测企业自行搭建规则、测试与监控平台提供治理、Guardrails、模拟评估和改进闭环上线速度取决于团队积累前期建设较重有望缩短建设周期但仍受企业系统复杂度影响控制与可替换性自主性更高维护责任也更重运营负担可能更低但供应商依赖更高定价信息人力、基础设施、模型调用等成本可拆分标准价格未公开预计以项目制和企业合同为主“租用”并不天然更便宜也不天然更贵。企业应该比较的是总拥有成本部署周期、内部工程人力、集成维护、人工接管、合规审查、失败损失和供应商切换成本而不是只比较 token 单价。这种模式的优势是把稀缺的 Agent 工程和运营经验一并引入代价则是更强的供应商依赖。企业需要在合同和技术评审中问清数据如何处理、策略与评测资产能否导出、接口如何替换、服务中断如何降级以及终止合作后知识、日志和流程配置如何迁移。所谓“不拥有”真正影响的不是法律措辞而是未来能否保留业务连续性和议价能力。五、竞争格局Presence 争夺的是企业工作流控制层Presence 将直接面对 Salesforce Agentforce、Microsoft Copilot 和 Zendesk AI。由于目前没有同口径的价格、成功率和部署周期数据不能仅凭发布信息给出谁更强的结论。更有意义的是比较各自进入企业的路径。平台主要进入路径Presence 需要证明的优势企业选型时的关键问题OpenAI PresenceGPT-5.6 系列、托管部署、治理优先能否跨现有系统交付稳定的 Agent并持续运营集成深度、治理能力、项目成本、供应商依赖Salesforce AgentforceSalesforce 及 CRM 业务流程Presence 在非单一业务系统中的整合与模型能力企业流程是否主要沉淀在 Salesforce 体系Microsoft CopilotMicrosoft 办公与企业软件生态Presence 能否在专用业务流程中提供更深交付身份、数据和协作环境是否已高度微软化Zendesk AI客服与工单场景Presence 能否从客服扩展到销售和内部 IT并保持专业深度需求是专注客服还是跨部门统一平台Salesforce、Microsoft 和 Zendesk 都拥有各自的企业入口业务数据、办公身份体系或客服工作流。OpenAI 的优势起点更接近模型和 Agent 能力Presence 则要通过 Forward Deployed Engineers 与治理平台补上最后一公里。这也解释了为何 OpenAI 需要从标准化 API 走向高接触式服务。大型企业的障碍通常不是“找不到模型”而是系统割裂、权限复杂、历史数据质量不一以及没有人能为跨部门流程负责。前沿模型可以提高能力上限却不能自动解决组织和集成问题。Forward deployed 模式本质上是用高密度工程服务换取落地速度同时把客户实践带回产品迭代。但这种模式是否能规模化仍需观察。每家大型企业的流程和治理要求不同项目越定制交付成本越高平台越标准化又越可能无法覆盖关键例外。Presence 必须找到可复用平台与客户定制之间的平衡。Bain Company 的参与也与这类项目涉及流程重构和管理决策的特征相吻合。市场空间足以支持这场竞争。按给定公开市场统计口径2026 年全球 AI 客服市场约 151 亿美元年复合增长率约 25.6%整个客服中心软件市场约 778 亿美元。不过不同报告的分类口径可能不同市场规模也不等于 Presence 可直接获得的收入。它首先要证明 Agent 能降低每次有效服务的综合成本同时不以更高的合规风险、接管负担和客户体验波动为代价。六、对中国开发者与技术管理者的影响自建还是采购问题正在改变Presence 未必会成为中国团队可以直接采购的默认选项但它体现的平台化方向具有参考价值未来企业评估 Agent不会只问用了哪个模型还会问权限如何定义、风险如何拦截、上线前如何测试、失败如何接管、线上数据如何形成改进闭环。这对开发者意味着Agent 工程的价值重心正在上移。提示词、工具调用和 RAG 仍然重要但仅完成一个可演示原型已经不够。真正稀缺的能力会包括策略引擎、身份与权限映射、评测数据集、可观测性、审计、版本管理和人工工作台。换句话说模型能力可能越来越容易采购围绕模型建立可信运行系统仍需要长期工程积累。对技术管理者自建与采购可以用四个问题判断流程是否构成核心差异化如果 Agent 直接承载独特业务逻辑且规则变化频繁自建控制层更有价值标准化服务流程则更适合采购成熟平台。数据和合规边界是否允许托管数据驻留、跨境访问、审计要求与行业监管可能先于模型能力决定方案是否可行。企业是否具备持续运营团队Agent 不是一次开发完成的软件。没有评测、运营和业务专家协同自建系统很容易停留在试点。能否承受供应商锁定需要评估模型、策略、对话记录、测试集和系统连接器的可迁移性而不是只确认 API 是否开放。一个审慎的落地路径可以分为三步。第一步从单一部门的高频、低风险任务开始建立人工基线和失败分类第二步用真实历史请求构建测试集比较端到端成功率、人工接管率、P95 响应时间和单次有效任务成本第三步再根据风险逐级开放写操作并为关键动作设置审批和回滚。中国团队在评估国际平台、国内平台或自建方案时也应坚持同一口径。不要拿某个平台的演示成功率与另一方案的真实生产数据比较不要只看模型回答分数而忽略系统可用性、中文业务规则、数据合规、技术支持和长期迁移成本。Presence 最值得借鉴的不是某个品牌选择而是把治理和评测放到项目第一天。七、总结Agent 治理才是真正的门槛OpenAI Presence 的战略意义不是 OpenAI 发布了一个更大的客服机器人而是它开始交付模型之上的企业运行体系由 GPT-5.6 系列提供能力以策略和权限设定边界用 Guardrails 进行运行时干预通过部署前模拟与自动评分建立质量门槛再从线上不确定案例形成持续改进循环。这标志着 OpenAI 从 API 提供商向托管式企业服务提供商迈出更明确的一步也让它与 Salesforce Agentforce、Microsoft Copilot、Zendesk AI 的竞争从模型层进入工作流和运营层。其 Forward Deployed Engineers 模式可能加快复杂项目落地但项目制交付的成本、规模化效率以及客户对供应商依赖的接受程度仍需要真实案例验证。对企业而言最重要的采购问题不是“Agent 能不能回答”而是“Agent 在什么条件下可以行动出错时谁能发现风险扩大前谁能阻止改动之后如何证明没有退化”。对开发者而言长期壁垒也不会只是调用某个模型而是把权限、评测、监控、接管和业务反馈组织成可持续的系统。如果说大模型决定了 Agent 能做多复杂的事那么治理决定了企业敢让它做多少事。Presence 把后一个问题放到了平台中心。它能否成为企业 Agent 的主导方案尚无定论但“先治理再放权”很可能会成为这一阶段更重要的产品原则。