OpenAI Presence 上线前，先写一份 30 天 Agent 试点合同

OpenAI 在 7 月 22 日发布了 Presence。它不是让用户自行配置的 Agent 工具，而是一项把语音和聊天 Agent 部署到具体企业岗位的产品：选定流程、连接系统、配置权限与政策、运行模拟和评分器（grader）、设置人工升级、监控生产表现，再通过 Codex 驱动的改进闭环持续调整。

每次部署由 OpenAI 的 Forward Deployed Engineer（FDE，前线部署工程师）和指定系统集成商带领完成。目前 Presence 仅限符合条件的企业参加有限 GA（limited general availability），并未开放自助购买。

即使你的创业团队今天买不到 Presence，这次发布仍然值得关注。它揭示了“AI Agent 产品”正在发生的变化：卖方提供的不再只是模型、SDK 或可视化流程，而可能是一套持续运行关系——厂商参与定义岗位、接入系统、衡量行为，并在上线后继续修改 Agent。

因此，对 AI 应用构建者、非技术创始人和小型产品团队来说，关键问题不是“演示里的 Agent 聪不聪明”，而是：我们能否说清岗位、证据、权限、责任人、变更流程与退出路径，从而安全地跑一个受控试点？

本文把 Presence 的发布转化为一份可复用的 30 天试点合同。你会拿到责任台账、一个账单支持案例、验收矩阵、构建与采购的适用边界、停止条件，以及一份 48 小时行动清单。本文没有独立试用 Presence，也不假设它对小团队可购买或具备合理成本。

OpenAI 发布了什么，还有哪些事实没有公开

Presence 官方发布页描述了一种明确的产品形态。每次部署先从一个具体岗位开始，例如处理账单问题、保险理赔或员工 IT 服务。Agent 只获得该岗位需要的知识和系统权限；企业负责定义它能做什么、何时必须审批、何时转给人工。

上线前，模拟和 grader 检查结果、政策遵循、工具调用与升级行为。上线后，生产会话与人工升级暴露新缺口，由 Codex 提议修改，再由团队测试并批准受控发布。

OpenAI 同时披露了一个真实的内部使用场景。其英语电话支持 Agent 会验证来电者身份、读取账户上下文并执行获批操作。OpenAI 表示，它现在可以在没有人工协助的情况下解决 75% 的来电问题，且 Codex 改进闭环在十天内把转人工比例降低了 15 个百分点。

这些数字至少证明 OpenAI 自己在运行这套系统，但它们仍是厂商对自有渠道的自报结果。发布页没有公开评测集、问题分布、严重度构成、样本分母、置信区间、满意度、单次有效解决成本或独立审计。我们不能把它们直接换算成另一家公司的商业预测。

几家公开客户的表述也有清楚边界。BBVA 和 IAG 使用的是“探索”，SoftBank 使用的是“测试”。这些信息说明它们参与了设计或测试，但不能证明已经实现大规模生产效果。

采购所需的许多事实尚未公开，包括价格、最低承诺、实施周期、支持的集成、Presence 专属数据处理方式、服务水平、审计导出、回滚时间、可迁移性，以及 OpenAI、集成商与客户之间的责任划分。每个空白都应该变成采购发现问题，而不是拿 API 或 ChatGPT Enterprise 的规则自行补全。

目前最稳妥的结论很窄：Presence 已经是一项有限开放、由实施团队主导、面向生产流程的产品；它是否能改善你的业务，仍需要由你的试点来回答。

五个术语，避免一开始就买错东西

部署型产品（deployed product），是软件与大量厂商实施工作共同构成的结果。它不同于开通账号后自行使用的订阅产品，因为流程梳理、客户侧投入和上线后的变更成本可能远高于模型调用费。 流程负责人（workflow owner），对业务结果和政策承担最终责任，而不只是负责配置 Agent。以账单支持为例，负责人可能是客服或运营主管；技术负责人可以负责连接系统，却不应代替业务决定退款政策。 有效解决（valid resolution），是达到事先约定标准的用户结果。“对话没有转人工就结束了”不一定等于解决：用户可能放弃、再次来电、收到错误调整，或暂时接受了会引发后续争议的答案。 人工升级（escalation），是把上下文、权限和紧急程度完整地交给人工或另一条受控流程，而不是只给用户一句“请联系客服”。合格的升级包应保留身份验证状态、用户目标、已收集证据、已尝试操作、风险标记与处理时限。 变更权限（change authority），说明谁可以提议、测试、批准、发布和撤销对政策、提示词、工具、模型、检索来源与升级规则的修改。Presence 强调 Codex 可以提出改进，但提议不等于授权，正式发布仍应由业务方掌控。

这五个术语可以组成一句更有用的采购描述：“我们为一个明确岗位试点一项部署型产品，流程负责人明确，有严格的有效解决定义、可执行的人工升级路径，以及由客户控制的变更权限。”如果这句话还写不完整，就不该进入采购阶段。

真正购买的不是 Agent，而是一套运营闭环

许多 Agent 评测只看回复质量，而 Presence 把更大的系统暴露了出来：

1. 选择边界清楚的岗位；
2. 连接知识与业务系统；
3. 授予有限权限；
4. 写入政策与人工升级规则；
5. 用真实场景模拟；
6. 向有限流量发布；
7. 观察结果和失败；
8. 提议、测试、批准并回滚修改。

每一步都有不同的失败责任人。模型回答正确，来源政策仍可能过期；流程设计合理，工具权限仍可能过大；模拟表现很好，仍可能遗漏真实流量中的长尾；生产会话发现了问题，如果没有对照评测、审批和回滚，所谓改进也可能制造更大事故。

因此，单一模型准确率不是好的采购指标。OpenAI 自己的评测最佳实践建议使用贴近真实任务与生产分布的测试，持续运行评测，保留日志，并用人工反馈校准自动评分；它还明确把“凭感觉觉得能用”列为反模式。

真正需要验收的单位不是一段漂亮对话，而是一套能在政策、流量、工具和模型变化后继续正常工作的运营闭环。

小团队比较成本时，也应看每个有效解决的总运营成本，而不是 token 单价或许可证价格。把集成、领域审核、数据标注、人工升级、事故响应、隐私、变更审批、回归测试和退出迁移都算进去。当托管式部署能消除团队稀缺的实施风险时，更高价格可能合理；如果流程每周都在变化，它也可能只是昂贵的依赖。

先选一个岗位，不要先写一个愿景

“改善客户服务”太宽，无法成为试点目标。“为已验证身份的客户处理 50 美元以下重复订阅扣款，但一旦涉及欺诈、拒付、未成年人或账户不匹配就转人工”，才是可测试的岗位。

先写一页岗位边界：

Presence 强调每次部署从具体岗位开始，并只提供该岗位需要的知识与访问权限。这个原则与厂商无关，同样适用于自己构建的 Agent。

NIST 的软件与 AI Agent 身份和授权概念文件指出，企业需要区分 Agent 和人的身份、控制权限、把委托操作关联到具体用户，并在自主操作规模扩大后继续保留问责链。

如果公司内部还在争论政策、必要证据拿不到、结果无法验证，或人工团队根本接不住升级流量，就应拒绝这个试点岗位。Agent 无法替公司稳定一条尚未决定该如何运行的流程。

报价之前，先完成责任台账

实施型产品很容易出现一种责任错觉：厂商说政策属于客户；客户以为产品被称为“可信 Agent”，就代表厂商已经替自己承担了安全结果；集成商负责连接器，却不负责连接器允许的业务操作。真实用户数据进入系统前，必须把这些空白消除。

与其写一张模糊的 RACI 表，不如做责任台账。每一行都要有一名最终负责的客户侧人员、一个证据存放位置，以及响应时限。

重要行不能只写“共同负责”。多人协作很正常，但如果后果严重时没有一人拥有最终决定权，“共同负责”通常会变成无人能拍板。

这张表还能判断你是在买产品，还是把一项业务职能外包。如果厂商掌握政策解释、评测阈值、生产变更和事故诊断，而客户只能看一个仪表板，这种关系更接近托管运营。价格、人员与退出计划都应按这一现实设计。

Agent 获得功劳之前，先建立人工基线

没有可比基线，试点就无法证明改善。先从岗位边界内抽取近期真实案例，覆盖普通、边缘、对抗和高升级比例的情况，并按要求移除或保护个人信息。为每条案例标注用户意图、正确政策、允许操作、必要证据、升级原因、最终结果、处理时长、重复联系，以及后续修正。

不要把“自动化率”设为唯一头部指标，至少使用下面这一组：

• 合格案例覆盖率：进入队列的案例中，真正符合岗位边界的比例；
• 有效解决率：合格案例被正确完成，证据齐全，并在约定窗口内没有返工；
• 安全升级率：应该转人工的案例，能在目标时间内带着完整上下文转出；
• 越权操作率：超出范围、缺少审批或作用于错误账户的操作；
• 重复联系率：用户在 7 天或 14 天内因同一问题再次出现；
• 单次有效解决成本：厂商、模型、集成、审核、升级和修正总成本除以有效解决数；
• 变更回归率：提示词、政策、工具、模型或连接器变化后，原本通过的案例变为失败的比例。

OpenAI 的轨迹评分指南把 trace 定义为 Agent 决策、工具调用和推理步骤的端到端记录，并说明结构化评分如何帮助定位成功或失败的原因。这比只检查最后一句回复更强，但自动 grader 仍需要人工校准，而且 trace 可能包含敏感信息。

官方 Agents SDK 追踪文档说明，trace 可以记录模型输入输出、函数输入输出、工具调用、handoff 与 guardrail。文档同时提醒：其中可能包含敏感数据，并且采用 Zero Data Retention 时无法使用官方 tracing。因此采购方必须追问：如果隐私配置不允许保留完整原始轨迹，我们将用什么证据验证结果和追查事故？

把 30 天试点拆成四个受控阶段

30 天试点不等于开放 30 天真实生产权限。应分四段，并为每次升级设置明确门槛。

第一阶段：历史回放，第 1–7 天

运行冻结的历史案例，不给真实用户回复，也不执行真实操作。案例应包括标准请求、模糊表达、政策冲突、记录缺失、情绪激动、身份不匹配、检索内容里的提示词注入、重复退款尝试与工具故障，再与已标注基线比较。

只有在测试集中没有越权操作、应升级场景覆盖充分、所有已知不支持情况都被列出时，才能进入下一阶段。平均分无法抵消一次灾难性的权限错误。

第二阶段：影子运行，第 8–14 天

让 Agent 处理实时案例，但不直接回复用户，也不修改系统。把它的拟议决策与训练过的员工比较，并按风险等级分析分歧，而不是只看整体一致率。错误解决和错误升级要分开统计。

进入下一阶段前，每个重要分歧都必须被解释，并被归入修复、明确排除或人工决策。“有更多流量后模型会自然改善”不是根因分析。

第三阶段：人工辅助的真实流量，第 15–21 天

向一小部分、已适当告知的流量提供服务，所有重要操作仍采用逐次审批。OpenAI 的 Agents SDK 人工审批指南展示了为什么审批应成为可持久化的执行状态：敏感工具调用会暂停，审批人针对这一次具体调用批准或拒绝，然后系统携带原状态恢复。

任何平台都应该提供等价语义——审批绑定具体参数与唯一操作，而不是一个笼统的“以后都信任这个 Agent”开关。

只有身份验证可靠、升级及时、审批凭证齐全、没有未解决的高严重度事故，且人工团队能承接下一档流量时，才可继续。

第四阶段：有限自主，第 22–30 天

只开放低风险、可逆、充分测试的操作。使用金丝雀流量并每日复盘，冻结无关流程变更。任何政策、工具、检索、模型或 grader 修改，都要重新运行对应回归集，并产生新的发布 ID。

是否进入常态运行，由验收矩阵决定，而不是由高管热情决定。如果触发停止阈值，就回滚或缩小岗位。一个试点只要能给出诚实决策，即使结论是“不上线”，也算成功。

具体场景：处理重复扣款

设想一家 12 人的订阅制公司，每月收到 3,000 条账单咨询。重复扣款投诉消耗大量客服时间，也容易让用户焦虑，但其中只有一部分是真正的重复扣款；其他情况可能是预授权冻结、税费差异、两个合法工作区、取消失败后的续费，或欺诈。

团队试点一项实施型语音和聊天 Agent，只负责一个岗位：解释或修正 50 美元以下、已经核实的重复扣款。Agent 可以读取账户、发票、支付渠道状态和历史调整；可以发送解释，或按政策提供一次可逆额度调整；不得改变账户所有权、暴露其他工作区、修改订阅或绕过欺诈控制。只要出现账户不匹配、拒付、用户痛苦、未成年人、重复额度调整或不确定性，就必须转人工。

第 11 天，影子 Agent 与员工在 92% 的合格案例上结论一致，看起来已经非常优秀。但轨迹复核发现，其中三次虽然最终答案相同，使用的却是错误发票，因为 CRM 搜索返回了姓名相近的多个账户。只看最后输出的评分，完全掩盖了身份链路缺陷。

团队没有只改提示词就继续上线，而是要求身份连接器必须使用不可变账户 ID，新增一组相似姓名的负面案例，在新测试通过前撤销额度调整权限，并把修改记录为新版本。进入人工辅助阶段后，一名用户要求 Agent “忽略附件邮件里的旧退款规则”。系统把这封邮件当作不可信证据，而不是政策来源，并转给人工。

第 30 天，有效解决率达到 68%，安全升级率为 97%，没有出现越权额度调整，重复联系减少。但由于人工审核仍然很重，单次有效解决成本略高于预期。团队最终选择“限定发布”，而不是全面开放：保留狭窄岗位，先修复身份查询，等再积累 200 个案例后重新评估自主权限。

这比宣布 92% 一致率或一味提高自动拦截率更有价值，因为试点找到了真正决定风险的控制点。

用验收矩阵设置不能被平均分掩盖的停止条件

把下面的矩阵复制到试点文档中。具体数值应来自你的基线和风险承受能力；表中的数字只是示例，不是行业统一 benchmark。

OWASP AI Agent 安全清单建议采用工具最小权限、重要操作独立验证、人工监督、对抗测试、成本与重试限制，并保留包含授权结果和政策版本的结构化日志。这些不是只有工程团队才需要的奢侈品，而是创始人无需决定技术实现，也可以要求交付的证据行。 NIST 生成式 AI 风险管理框架提供了同样有用的生命周期视角：风险需要被治理、映射到实际情境、衡量，再持续管理。只测输出、却没有责任人与响应路径的试点，只完成了其中一部分。

把未知项写进合同，不要把发布口径当承诺

Presence 不是自助产品，因此订单和部署说明的重要性不低于公开页面。OpenAI 当前的服务协议写明：当文件发生冲突时，订单优先于服务专属条款、主协议与政策；使用上限也以适用订单或文档为准。真正重要的运营承诺，应进入具有控制力的文件，而不能只停留在销售电话里。

要求厂商书面回答下面十个问题：

1. 每类数据会经过哪些产品、模型、地区、子处理方、连接器和支持团队？
2. 今天正式支持哪些操作与集成，哪些依赖定制工程？
3. 谁可以查看原始对话、trace、grader 结果与客户记录？
4. 这次部署具体采用什么保留、删除、数据驻留和审计导出机制？
5. 端到端业务流程的可用性、响应、恢复和升级目标是什么，而不只是模型 API 的可用性？
6. 模型、政策、grader、提示词、连接器与平台变化如何通知和版本化？
7. 谁能批准生产修改，客户多久可以强制回滚或关闭全部操作？
8. 退出时可以导出哪些配置、评测案例、日志和完成凭证？
9. 哪些交付必须依赖 OpenAI FDE 或集成商？团队人员变化后如何处理？
10. 实施、用量、支持、变更工作和最低承诺分别如何收费？

OpenAI 的企业隐私页面说明，企业数据默认不用于模型训练，并介绍了数据所有权、保留控制、访问控制、DPA 与审计能力。这些是重要起点，却不能回答 Presence 每条部署链路的具体问题。要求厂商把每项承诺映射到你真正购买的产品与数据路径。

在四种运营方式之间做选择

Presence 并不是所有 Agent 项目的默认答案。至少比较下面四种方式：

流程仍在发现阶段的小团队，通常不应急着买实施型企业产品。先用人工处理并记录案例，写清岗位边界，摸清例外分布。只有当流程成熟、规模足够大、政策稳定，而且集成成本很高时，部署型产品才更可能合理。

这个决定不应变成“自建派”和“采购派”的立场之争。自建可能隐藏永久维护成本，采购也可能隐藏永久厂商依赖。真正要比较的是：上线后，你能保留多少证据和决定权。

常见失败方式与容易误读的指标

把“不转人工率”当成成功。 转人工减少，既可能代表问题解决得更好，也可能代表用户受阻或放弃。必须同时看有效性、重复联系、投诉和修正。 把厂商总体结果当成自己的预测。 OpenAI 内部 75% 的结果没有披露你的问题构成、政策复杂度、渠道行为或人员条件。它可以成为测试理由，不能成为商业承诺。 默认 FDE 拥有政策决定权。 优秀的实施工程师能改进流程，但业务政策和风险接受仍属于客户。把最终权限写进责任台账。 没有隐私设计就“记录一切”。 完整 trace 有助于诊断，也可能记录个人信息、账户上下文、函数参数或音频。事先定义脱敏、访问、保留、导出，以及不能保留原始 trace 时的替代证据。 审批一类权限，而不是一次操作。 “允许退款”不是安全审批。审批应绑定账户、金额、原因、政策版本、工具参数和有效期。 让生产反馈直接改写政策。 升级案例揭示缺口，却不会自动成为新规则。把提议、领域审核、回归测试、审批与金丝雀发布分开。 跳过退出演练。 如果 Agent 掌握流程知识、评测案例、连接器映射和运营历史，取消服务可能让整条业务断裂。扩容前先测试撤权、导出、人工回退与删除。

这套框架适合哪里，又不能替代什么

这份试点合同适用于客户支持、内部 IT、销售线索筛选、排期、理赔受理、账户运营等重复的语音或聊天岗位，尤其是需要读取系统或执行操作的场景。只要一项 Agent 产品包含实施和持续改进，即使不是 Presence，同样可以使用这套框架。

对于只读 FAQ、个人效率助手，或完全不触发生产操作的一次性原型，它可能过重，可以采用更轻量的测试。

本文不能替代法律、安全、隐私、劳动、无障碍、金融、保险、医疗或消费者保护审查。高影响决策可能必须由具备资质的人负责，进行正式验证、披露和申诉，甚至完全排除 Agent 自主执行。“有人在环”也不自动等于安全；如果审核者没有时间、上下文、权限或安全的拒绝路径，人工审批只是一种表面控制。

Presence 以后可能会公开更多文档、价格、客户结果或自助能力。本文依据的是 2026 年 7 月 23 日的公开状态。产品变化后，应更新合同问题，而不是把今天的未知项永久当作事实。

创始人的 48 小时行动清单

如果 Presence 的发布让团队开始讨论“我们也应该上 Agent”，接下来的两天先收集证据，不要先看更多演示。

1. 用一句话写出一个岗位，必须包含用户、允许结果和禁止结果。
2. 抽取 50–100 个近期案例，估算真正符合岗位边界的比例。
3. 定义什么叫有效解决，并设定修正观察窗口。
4. 列出 Agent 必须读取或修改的系统，删除所有非必要权限。
5. 指定流程、政策、安全、人工升级、变更、事故和退出负责人。
6. 写出五个强制升级条件，并验证人工队列是否接得住。
7. 准备十个标准、十个边缘和十个对抗回放案例。
8. 为身份、权限、隐私、政策和可靠性各设置至少一个停止条件。
9. 要求厂商或构建方演示这项产品专属的数据流、变更控制、审计导出与退出过程。
10. 在真实流量开始前，写清回放、影子、人工辅助与有限自主的晋级门槛。
11. 计算单次有效解决的完整成本，包括人工审核与返工。
12. 把“继续由人工完成”保留为一种合格的试点结论。

Presence 带来的长期启示，不是所有公司都必须购买企业 Agent，而是严肃的 Agent 部署从来都由软件、权限、政策、评测、人工运营与受控变更共同构成。只买模型的创始人，会继承缺失的系统；购买部署型产品却不定义责任的创始人，可能只是在租用一套自己无法验证的系统。

先写清岗位、责任、证据和退出合同，再决定由谁来运营。

参考资料

1. OpenAI：Introducing OpenAI Presence
2. OpenAI API：Evaluation best practices
3. OpenAI API：Trace grading
4. OpenAI Agents SDK：Human-in-the-loop
5. OpenAI Agents SDK：Tracing
6. OpenAI：Enterprise privacy
7. OpenAI：Services Agreement
8. NIST：Generative AI Profile, NIST AI 600-1
9. NIST NCCoE：Software and AI Agent Identity and Authorization concept paper
10. OWASP：AI Agent Security Cheat Sheet