OpenAI Presence 宣称在英语电话客服场景中实现 75% 自动解决率，但这组数据究竟证明了什么？本文从产品分析视角拆解 Agent 的生产可行性，指出模型能力不等于业务闭环，真正可运营的数字岗位需要 SOP、权限、人工接管与评测改进六层系统支撑。

OpenAI 发布 Presence 时披露了一组很有吸引力的数据：在英语电话客服场景中，Agent 能够在没有人工介入的情况下解决 75% 的来电问题；上线十天后，转交人工的比例下降了 15 个百分点。

如果只看这两个数字，很容易得出一个结论：模型能力已经足以承担大部分客服工作。但从产品分析的角度看，这组数据只能说明生产 Agent 具备了值得继续验证的自动化潜力，还不足以证明它已经成为一套可以普遍复制的解决方案。

我把 Presence 的公开资料和客服任务链路对了一遍，值得关注的不是模型又多会做了一件事，而是 OpenAI 如何定义一个可以进入真实业务的 Agent。它包含标准作业流程、业务政策、工具权限、批准动作、模拟评测、人工接管和持续改进。模型是其中最显眼的一层，却不是完整产品。

只有当任务输入存在不确定性、结果可以验收、风险可以兜底时，企业才适合把 Agent 设计成一个可运营的数字岗位。模型决定能力上限，标准作业流程、权限、人工接管、评测和改进闭环决定生产下限。

一、75% 自动解决率究竟证明了什么

这里所说的“自动解决”，来自 OpenAI 对案例结果的描述。它指向的应该是用户问题在没有人工介入的情况下得到处理，但公开资料没有提供足以独立复现的完整统计口径。我们还不知道 75% 的分母包括哪些问题：是所有来电，还是经过筛选、具有明确标准作业流程的任务；身份验证失败、政策例外和高风险操作是否提前被排除，也没有公开说明。

“解决”的判断条件同样重要。Agent 完成一段回答、成功调用业务系统、用户确认问题解决，以及用户在七天内没有重复来电，代表四种不同程度的结果。如果系统只是减少了当次人工转接，却增加了重复来电、错误关闭或后续投诉，那么自动化比例提高并不等于业务结果改善。

任务结构也会显著改变这个数字。查询订单状态、重置密码等问题通常拥有明确规则和可验证结果；费用争议、账户异常或涉及特殊政策的请求，需要更多判断、授权和责任确认。即使使用同一个模型，两类任务的可自动化程度也不会相同。脱离问题类型和风险等级比较自动解决率，很难判断 Agent 究竟解决了什么。

这组数据仍能支持一个明确的产品判断。它至少表明，在经过限定的英语电话客服场景中，Agent 已经不只是生成一段回复，而是可以参与问题识别、规则调用、业务操作和人工交接。OpenAI 在 Presence 中同时强调标准作业流程、政策、批准动作、模拟评测和人工接管，也说明案例结果并非单独由模型产生，而是来自模型与业务系统的共同运行。

因此，75% 更适合作为“生产可行性信号”，而不是生产验收结论。产品经理还需要补齐任务范围、真实解决质量、重复请求、用户满意度、单次解决成本、错误操作和异常恢复等指标。只有这些口径能够共同成立，自动解决率才可以被视为业务价值。

二、模型回答正确，业务任务仍可能失败

一次客服任务可以从一句自然语言开始，却不会在一句自然语言结束。

假设用户说：“我已经退货了，为什么还没有收到退款？”模型需要识别用户是在查询退款进度，而不是重新申请退货；系统要完成身份验证，查询订单、物流和支付状态，找到适用政策，再判断是继续等待、补交材料、重新发起退款还是转交人工。涉及退款操作时，还要检查金额、账户状态和操作权限。任务结束前，系统需要确认操作是否生效，并向用户说明结果和下一步。

这条链路至少有七个环节：

理解用户意图与上下文；

获取适用的业务知识和政策；

查询订单、账户或工单状态；

根据规则形成处理方案；

调用工具执行允许的操作；

验证系统状态是否发生预期变化；

在无法处理或风险升高时交给人工。

大模型主要改善的是意图理解、非结构化信息处理、方案生成和自然语言沟通。知识库负责提供当前有效的政策，业务系统保存真实状态，工具执行查询或修改，规则系统限制可选动作，人工承担例外判断和最终责任。任何一个环节失败，用户都可能得到一段听起来合理、实际上没有解决问题的回答。

知识没有及时更新，Agent 可能准确复述过期政策；工具返回超时，它可能把“已经发起退款”误当成“退款已经到账”；权限设计过宽，一次错误判断可能直接变成错误操作；人工接管时没有携带已收集的信息，用户还要从头解释。模型在离线评测中答对问题，并不能覆盖这些生产故障。

这也是普通对话机器人与生产 Agent 的关键区别。对话机器人的主要交付物是回答，生产 Agent 的交付物是经过验证的状态变化。前者可以用回答准确率、相关性和满意度衡量，后者还要确认工具是否成功、业务结果是否成立、风险是否受控，以及失败能否恢复。

把 Agent 接入更多工具，并不会自然获得业务闭环。工具越多，系统可以完成的任务越多，但权限组合、状态冲突和异常路径也会增加。产品经理必须把“模型能说什么”继续拆到“系统允许做什么、做完如何验证、失败由谁负责”。这部分工作无法由一次模型升级自动完成。

三、什么任务应该使用 Agent，什么任务继续使用工作流

传统工作流的优势不是能力更强，而是路径明确。输入满足某个条件，系统执行固定规则，输出可以预期。它适合表单校验、状态同步、固定审批和规则清晰的批处理任务，成本稳定，也容易审计。

Agent 的价值出现在另一类任务中：用户表达方式多变，信息不完整，处理路径需要根据上下文动态选择，但业务结果仍然可以验证。例如客服中的问题诊断、跨系统信息收集、例外分类和多轮材料补充，都很难为每一种表达预先画出完整流程。

这不意味着输入越复杂，越应该交给 Agent。适用性还取决于结果能否验收，以及失败是否可以恢复。可以用四个问题判断任务应该由工作流、Agent还是人工承担。

由此可以形成三类选择。

路径明确、规则稳定、结果可验证的任务，优先使用传统工作流。如果密码重置只需要完成身份验证、生成链接和记录状态，没有必要让 Agent 自由规划每一步。模型可以负责理解用户表达，实际执行仍由确定性流程完成。

输入和处理路径存在变化，但结果可以验证、错误可以恢复的任务，适合 Agent。Agent 可以根据用户上下文选择知识、补充信息、组合工具并调整步骤，系统则用权限和结果检查限制行动空间。

结果难以验证、错误代价高且不可逆的任务，应由人主导。Agent 可以整理材料、提出候选方案或发现异常，但不能独立作出最终决定。大额赔付、账户封禁、医疗诊断和具有法律责任的操作都需要更严格的授权结构。

这里的产品判断不是“Agent 替代工作流”，而是让两者分工。工作流提供稳定下限，Agent 处理流程难以穷举的变化，人工负责高风险例外与责任确认。一个成熟系统往往同时包含三者，而不是只选择其中一种。

四、生产 Agent 是一套六层运营系统

如果把生产 Agent 理解成一个可运营的数字岗位，产品设计就不能止于模型、提示词和工具列表。岗位需要明确目标、掌握必要信息、拥有有限权限、遵守业务政策、知道什么时候交接，并在长期运行中接受质量管理。

1. 岗位目标与标准作业流程

标准作业流程，也就是 SOP，定义某类任务通常如何处理。它的意义不是要求 Agent 机械照抄步骤，而是明确目标、必经检查、允许变化的部分和结束条件。

客服 Agent 的目标不能只写成“解决用户问题”。产品需要继续定义可处理的问题类型、不能承诺的事项、必须核对的信息、允许采取的操作，以及什么状态代表任务关闭。否则，模型可能把尽快结束对话理解为成功，而业务目标是正确解决并避免重复请求。

SOP 还要区分稳定规则与可判断空间。身份核验、退款上限和合规声明属于不能跳过的步骤；提问顺序、解释方式和资料收集路径可以由 Agent 根据上下文调整。这样的结构既保留模型的适应性，也避免把业务底线交给概率生成。

2. 知识与上下文

Agent 需要知道当前用户、当前任务和当前政策。这里的知识包括文档，也包括版本有效期、适用对象、地区、产品套餐和例外规则。检索到一段相关文字，不代表它适用于眼前用户。

上下文负责保存本次任务已经确认的信息、执行过的动作和未解决的问题。它必须有范围和生命周期：哪些信息可以跨会话保存，哪些只能用于当前工单，人工接管时传递什么，任务结束后保留多久。缺少这些规则，Agent 可能重复询问，也可能在不合适的场景调用敏感信息。

3. 工具与权限

工具决定 Agent 能从回答走向行动，权限决定行动的上限。查询订单、修改地址、发起退款和关闭账户看起来都是工具调用，风险等级却完全不同。

产品需要为每个工具定义读取与写入范围、金额或次数上限、适用用户、调用前提和失败处理。默认权限应当满足完成任务所需的最小范围。只要某个操作成本较高、涉及敏感数据或难以撤销，就不应仅凭模型判断直接执行。

这也是为什么“模型不会主动做坏事”不能代替权限设计。模型输出具有概率性，知识和上下文也可能不完整。权限系统负责保证一次错误判断不会自动扩大为无法控制的业务损失。

4. 政策、运行时检查与审批

业务政策只有写进文档，还不能保证每次运行都被执行。生产系统需要把关键规则转化为调用前后的机器检查。例如，退款工具在执行前校验身份、订单状态和金额；调用后核对支付系统是否返回成功状态；达到阈值时转入人工审批。

Google Managed Agents 引入的环境 Hook 提供了一个可观察的方向。Hook 是在工具调用前后自动执行的检查逻辑，可以拒绝危险参数、限制预算、记录证据或触发人工确认。它不是完整的安全体系，但说明产品政策正在从自然语言要求转为可执行规则。

审批也不应该覆盖所有动作。过多确认会让 Agent 退化为一个不断请求用户点击的流程界面。合理的做法是按成本、敏感性和可逆性分级：低风险查询自动执行，中风险操作向用户确认，高风险或异常操作交给有责任权限的人工人员。

5. 人工接管与失败恢复

人工接管不是 Agent 失败后的临时补丁，而是生产能力的一部分。产品需要事先定义什么情况下接管、交给哪类人员、携带哪些上下文、人工处理后如何把结果写回系统。

触发条件可以来自用户明确要求、模型置信不足、工具连续失败、政策冲突、情绪或安全风险，以及超过操作预算。仅设置一个“转人工”按钮并不够。如果接管时丢失对话摘要、身份验证结果、已经调用的工具和失败原因，人工只是在重新开始任务。

失败恢复还包括撤销错误操作、重新开放工单、回滚状态、补偿用户和记录事故。系统能自动做多少事，取决于它在做错时能恢复到什么程度。没有恢复能力的高自动化，会把效率收益建立在不可控风险之上。

6. 评测与持续改进

生产 Agent 不会因为上线而进入稳定状态。用户表达会变化，业务政策会更新，工具接口会调整，模型版本也会改变。一次通过的测试不能长期代表产品质量。

上线前的评测应覆盖高频任务、困难任务、边界任务和高风险任务。上线后的真实失败需要按原因分类：意图理解错误、知识召回错误、规则判断错误、工具执行错误、结果验证失败、接管失败，或用户虽然得到处理却仍不满意。

具有代表性的失败案例应进入回归评测。每次修改提示词、知识库、工具、规则或模型后，团队重新运行这些案例，确认旧问题没有复发，新能力没有破坏原有流程。小普在 AI 产品 1-N 的文章中提出把重问、改写、放弃和人工抽检结果转成失败分类与回归样本，这种案例循环正是生产 Agent 的运营基础。

六层结构共同决定一个 Agent 能否进入生产。模型变强可以抬高任务上限，却不会自动补全过期政策、错误权限、失效接口和模糊责任。系统下限来自那些看起来不如模型演示醒目，却能在每天运行中重复执行的机制。

五、自动解决率之外，应该衡量什么

自动解决率仍然重要。它能反映多少任务在没有人工介入的情况下完成，但必须先定义“完成”，并与质量、成本和风险一起使用。否则团队可能通过减少转人工来提高数字，却把问题推迟到用户复联和投诉环节。

生产 Agent 的指标可以分成五组。

业务结果：任务是否已经关闭

经过验证的任务闭环率是比自动解决率更严格的核心指标。它要求任务达到可以由业务系统确认的结束状态，而不是模型自行宣布完成。

客服场景还可以观察首次解决率、规定时间内重复请求率、工单重新打开率和承诺兑现率。首次解决率上升但重复请求率没有下降，可能说明统计关闭与用户真实解决之间仍有差距。

效率与成本：自动化是否值得

单次任务成本不能只计算模型 Token，还要包含知识检索、工具调用、语音、人工复核、重试、异常处理和错误补偿。更有意义的口径是：

> 成功任务成本 = 模型、工具、重试、人工与失败损失的总成本 ÷ 经过验收的成功任务数。

同一个模型在简单查询上可能成本过高，在复杂争议处理中却可能减少人工调查，从而降低总成本。产品经理应按任务类型计算，而不是只看全局平均数。

人工协作：Agent 是否把问题交对了人

转人工率下降并不天然是好事。需要同时观察接管准确率、接管时机、人工接手时长、上下文完整率和错误拦截率。

理想接管不是越少越好，而是该自动处理的任务不打扰人工，该升级的任务能及时升级。Agent 在风险发生后才转人工，或把大量可自动解决的问题都推给人工，都代表产品结构仍需调整。

质量与用户体验：用户是否接受这个结果

用户满意度需要与具体任务结果结合。一次对话语言流畅，不代表操作正确；一次准确处理也可能因为解释不清而造成不信任。

可观察指标包括任务后满意度、用户纠正率、重复解释次数、放弃率和投诉率。对于语音客服，还可以记录打断恢复、身份验证完成和关键信息复述是否准确。

风险与学习：系统是否知道自己错在哪里

错误操作率、高风险动作拦截率、权限违规率、审计日志完整率、事故恢复时间和回归样本覆盖率，决定系统能否长期运行。

这一组指标经常被放在业务看板之外，却直接影响 Agent 可以获得多大权限。一个能记录、分类和复现失败的系统，才有可能通过迭代扩大自动处理范围；如果团队只知道用户不满意，却无法定位是哪一层失效，模型升级也很难稳定改善结果。

五组指标之间存在制约关系。自动闭环率上升时，要检查投诉与风险是否同步变化；成本下降时，要确认是否把负担转移给用户或人工；接管率降低时，要检查高风险任务是否被错误留在自动流程中。生产指标不是寻找一个最大的数字，而是确认效率提升没有破坏结果质量和责任边界。

六、AI 产品经理需要交付什么

把 Agent 当作数字岗位以后，产品经理的交付物也会发生变化。提示词、模型选型和功能列表仍然需要，但它们无法单独描述岗位怎样工作、怎样受控和怎样被验证。

一套可以进入生产准备的产品方案，至少需要以下七类交付物。

岗位边界

写清 Agent 服务谁、处理哪些任务、不处理哪些任务、可以使用什么信息和工具，以及谁对最终结果负责。岗位边界用于防止团队把所有无法分类的问题都交给同一个通用 Agent。

任务样本集

收集真实或经过脱敏的高频、困难、边界、失败和高风险任务。每个样本需要包含输入、必要上下文、允许动作、正确结果和不可接受结果。它既是需求材料，也是后续评测资产。

工具权限表

为每个工具记录读写能力、数据范围、调用条件、操作上限、是否需要确认、失败后能否撤销和审计要求。权限表把抽象的“安全可控”转化为可以评审的产品决策。

异常分类与处理规则

列出知识缺失、信息冲突、身份验证失败、工具超时、政策例外、用户异议和高风险操作等异常。每一类异常要有检测信号、处理动作、接管对象和恢复方式。

人工接管设计

定义接管触发条件、队列分配、优先级、需要传递的上下文，以及人工处理结果如何进入后续评测。接管体验既影响用户，也决定自动化是否真的减少人工成本。

指标树与上线门槛

指标树连接业务结果、效率、人工协作、用户体验和风险。上线门槛需要按任务等级设置，不能只给整个 Agent 一个平均准确率。高风险任务即使样本较少，也要拥有更严格的通过标准。

案例迭代机制

规定谁查看失败案例、如何分类、什么问题需要修改知识、提示词、工具、规则或模型，以及改动后如何回归。Agent 的持续改进不是不断增加提示词，而是把真实失败转化为可复现、可归因的产品样本。

这些交付物也重新划定了 AI 产品经理与算法、工程、安全、运营和业务团队的协作界面。产品经理不需要替代每个专业岗位，但要把用户任务、系统能力、业务规则、责任和验收标准连接起来。算法团队改善理解与规划，工程团队保证工具和状态可靠，安全团队设计权限与监控，业务团队确认政策和例外，运营团队处理人工接管与案例复盘。

OpenAI Presence 提供的不是“企业只要换一个更强模型，就能获得 75% 自动解决率”的证明。它更像一个产品信号：当 Agent 进入客服、销售支持或其他业务流程时，竞争对象已经从单次回答质量转向整套任务系统的运行质量。

对正在规划 Agent 的产品团队而言，最优先的动作不是继续扩充功能，而是选定一种任务，画出从用户输入到结果验证的完整链路。标出模型、知识、工具、规则和人工分别负责什么，再检查每个失败点是否可发现、可接管、可恢复。完成这张图以后，团队才算开始设计生产 Agent。