2026 年 7 月 22 日，OpenAI 发布了面向企业语音与聊天 agent 的产品 OpenAI Presence。它没有停留在通用问答的对话框模式，而是直接从具体岗位切入，例如客服、外呼销售或高风险的内部工作流。企业在部署时需要明确定义 agent 可以执行哪些操作、哪些高风险动作必须提前获得批准，以及何时触发人工接管。
在一个具体客服场景中，用户提交了一张涉及罕见优惠券叠加逻辑的退款请求。Agent 读取订单与折扣规则后未能算清金额，任务卡住，工单被自动转交给人工客服。在传统的工具流程里，人工客服补发退款，这笔交易在 CRM 里标记为已完成，事情到这里就结束了。
Presence 试图收进产品里的，恰恰是失败发生后的后半段工作。工单转交人工时，系统会自动保存包含完整运行上下文的失败记录。团队随后可以在模拟环境中重现这次异常，修补针对多重折扣的规则，利用历史测试集跑回归测试完成验证，再通过 Codex 修改代码与分发逻辑，确保下次遇到同样的退款请求时，agent 能够独立跑通。
上线后通过修复与测试让 agent 越用越聪明，在这里被打包成了独立于模型能力之外的产品功能。系统改进的对象不再局限在单一 LLM 模型的参数，直接覆盖了包含规则、测试集、代码与人工判断的完整 agentic 系统。这种把现场失败转化为系统测试与规则的闭环，实际上是把传统 FDE 在客户现场最有价值的经验回流放进了产品流程里。
在传统 IT 和咨询服务中，驻场 FDE 的真正价值在于把客户现场暴露的错误、业务规约和有效做法，迁回产品与工程体系中。Presence 实际上是在标准产品界面里建立了一条 FDE 经验回流链：捕获现场失败、记录人工接管轨迹、提炼成测试用例与规则、受控更新代码与逻辑。
从企业架构来看，这正是 context infrastructure 在工作流中的商业化实践。Agent 的改进不需要靠重新训练或等待一次更强的模型升级，主要是依靠系统不断捕获、提炼、按需加载与反馈重用过去付过代价的经验。经验在运行中被捕获，由人工修正后提炼为测试与 guardrail，再作为上下文重新送回 agentic 系统中。
退款发生时，企业里实际上留下了两样东西。一种是传统的业务记录，保存在 CRM 或工单系统里。在那张退款工单里，CRM 存下了订单编号、客户身份、支付金额以及退款是否完成。它记录的是这次发生了什么，也是企业业务运行的账本。另一种则是 agent 在跑任务时攒下的改进经验：处理失败的记录、人工干预的轨迹、修改后的规则、回归测试用例以及调整后的分发逻辑。正是这段“下次怎样避免同类错误”的经验，决定了系统下一次遇到异常时能否正确跑通。
把这些失败记录与规则视为关键资产，来自对行业结构的分拆判断，并不表示它们已经被 OpenAI 托管或限制导出。公开资料显示，Presence 只是在产品流程中集成了模拟、回归测试、人工接管和 Codex 改进过程。The Register 的报道 指出，Presence 目前处于 limited GA 阶段，采用非 self-serve 模式，由专门团队逐案部署，具体费用和实施方案依据具体场景与交付需求定制。官方并没有公布 Presence 对这些规则、回归测试或失败记录的托管细则、数据驻留政策、留存期限，也没有说明是否支持跨供应商的导出与迁移。
当改进闭环被放进产品后，行业里自然出现了一种担忧：平台厂商把经验回流做成标准功能，会不会像以前一样挤压垂直软件厂商的空间？
在软件历史上，云厂商或平台巨头要替换垂直软件，通常靠的是默认的分发入口、紧贴数据与工作负载的地位，以及低成本复制的标准化交付。正如 AWS Redshift 论文 所展示的，云厂商可以把托管服务、数据邻近与成本优势整合成完整的替代方案。
拿这些条件去看 Presence，会发现它目前并不符合。Presence 还停留在 limited GA 阶段，并不是开箱即用的 self-serve 产品。The Register 的报道 显示，它的每次落地都需要 FDE 工程团队或合作伙伴重度参与。它依然要连接企业现有的 CRM 等外部系统，既没有占领默认采购入口，也没有实现数据的集中托管。
回顾基础设施与应用层的竞争，底层能力增强并不等同于垂直厂商会瞬间失去生存空间。AWS 推出 OpenSearch，没有挡住 Elastic 在 2026 财年继续实现增长；OpenAI 发布 Deep Research 后，专注于金融领域的 AlphaSense 在 2025 年 10 月依然宣布其 ARR 突破 5 亿美元、服务超过 6,500 家客户，虽然这是厂商自行公布的数据，但依然反映出深度业务工作流与专有内容的韧性。反过来，通用平台推出的延伸产品也未必每次都能顺理成章地覆盖市场，比如 OpenAI GPT Store 时承诺向开发者分账，但 WIRED 的报道 显示，大多数开发者并没有借此建立起可持续的商业模式。
只要垂直应用掌握着跨云的产品界面、专有数据积累与深度的业务工作流，通用模型的升级就不会自动等于垂直软件的消亡。既然 CRM 中的业务记录仍在企业自己手里，当 FDE 的经验回流被收进产品时，成熟的垂直 agent 厂商与企业买方真正需要守住的地方是什么？
看一看成熟的垂直 agent 厂商，会发现它们的防护重点并不是绑死在某一家模型上。比如，Sierra 在技术博客中表示，它的 agent 会根据任务需求调用超过 15 个前沿模型、开源模型和专有模型；Decagon 也公开确认 同时接入 OpenAI 与 Anthropic 的模型，并与 CRM、help desk 及 CPaaS 通讯基础设施对接；Intercom Fin 通过连接 Shopify、Stripe、Salesforce 等系统执行动作，并在 chat、email、voice、SMS、WhatsApp 等多个渠道间维持运转。另外，ServiceNow AI Control Tower 强调的是横向治理任意 agent、模型与工作流，而 Presence 的定位是落到具体岗位上运行 agent，两者在治理层级上有明显的区分。
重新审视那张退款工单，企业在实际运行中把控着三样东西：一是 CRM 里记录的订单与客户状态账本；二是覆盖电话、邮件、WhatsApp 的通讯与执行通道；三是处理过成千上万张工单后沉淀下来的失败记录、人工接管轨迹、回归测试集与规则，这正是企业最核心的 context infrastructure。
真正决定下一次 agent 行为的，正是这些生产改进材料。如果企业能够把这些错误教训与测试集带到不同的模型上重新测试、迁移，那么无论底层模型怎么换，采购的主动权都在企业手里。相反，如果这些改进经验与测试集无法导出，客户就会陷入新的供应商锁定。企业搬得走 CRM 里的业务账本，却带不走过去付过代价才换来的错误教训。
积累的测试与规则能不能导出，直接决定了客户未来能不能自由切换供应商。更重要的是，团队现在就能开始把每次人工接管变成对下一次结果的明确要求。
Presence 展示的思路不需要等到采购完整平台才开始实践。对 builder 来说，先选一项会反复发生、又确实会出错的任务，例如退款、报价或客户信息更新。每次任务转给人处理时，先问一个比“这次怎么修”更重要的问题：这类任务交给 agent 后，什么结果才算正确？退款金额对不对只是其中一项；该不该转人工、有没有碰到不该改的订单、用户是否得到清楚解释，也都应该写进答案。
这就是 Evaluation-First 的起点。人工接管留下的输入、agent 做过的动作和人工修正，不只是故障记录。团队要从中挑出会重复发生的案例，连同验收标准一起组成 evaluation set。规则、提示词、工具调用或代码改动之后，先拿这组真实案例重跑；结果不达标，就不能把改动送回生产环境。
这样做的重点不在于把 agent 的每一步都锁死。开放任务的路径无法预先写全，agent 仍需要自己查资料、选择工具、调整策略。团队真正要固定的是结果边界：退款有没有正确完成，风险动作有没有停下，用户有没有得到该有的处理。从过程确定性到结果确定性 讨论的正是这层转变。evaluation set 让抽象的“结果要对”落到一组可以反复运行、会随着真实失败不断扩充的案例上。
这套材料应该由企业自己看得见、改得动，也带得走。模型可以替换，工具可以重接，负责实施的人也会离开；但只要团队持续把人工接管转成新的 evaluation case 和验收标准，agent 就不会在同一个地方反复交学费。Presence 的价值正在于它把这条路摆到了企业产品里，而真正可迁移的能力，仍然来自团队能否不断定义、检验并积累自己要的结果。