AI 客服最危险的虚假增长，是把“用户没再说话”算成“问题已解决”。对话结束只是一个系统事件，问题解决才是用户结果；两者之间必须有确认、合理观察窗口、重新打开后的纠错，以及“正确转人工也算成功”的定义。对 Momcozy APP，第一步不是追求更高自动解决率，而是先把“已回答、已确认解决、暂时沉默、再次求助、正确接管”拆成不同状态。
过去的客服系统为什么喜欢看“结案量”“平均处理时长”或“机器人拦截率”？因为这些事件容易记录：工单被关掉了、对话没有进入人工队列、最后一条消息已经过去若干分钟。但容易记录不代表它们就是用户获得的价值。用户可能真的解决了，也可能忙着照顾宝宝、放弃追问、转去商店差评，或者自己反复尝试后才成功。
Outcome Window（结果观察窗口），大白话是：系统不能在回答发出的那一刻就宣布成功，而要在与任务相称的一段时间里，继续观察这个结果是否被确认、维持或推翻。生活类比是修水管。师傅离开不等于维修成功；当场不漏是第一层证据，第二天仍不漏是更强证据，重新漏水则要撤销“已解决”。
Momcozy APP 的待验证例子：AI 助手给出一段设备连接指导后，至少可能出现五种状态——用户明确说“好了”；没有回复但设备随后稳定连接；没有回复且结果未知；稍后再次问同一问题；系统识别为高风险或无法判断并正确转人工。把后四种中的前三种全部算成“解决”，自动化率会很好看，却不能说明体验变好。
这也解释了为什么 Resolution Rate（解决率） 不能只有一个布尔值。更可靠的状态应包含证据强度：confirmed（用户确认）、behaviorally verified（行为结果验证）、assumed（依据沉默暂定）、reopened（后来被推翻）、human-resolved（人工完成）。尤其在母婴、儿童、健康和设备安全语境中，“正确转人工”不是 Agent 失败，而是系统守住边界后的成功动作。
Intercom Fin：连收费口径都承认“解决”需要被撤销
结果定义必须允许证据升级和反转；否则沉默会被系统性误记成成功。
关键事实
Intercom 当前帮助文档把 Fin 的 resolution（解决）分为两类：用户明确表示答案有帮助的 confirmed resolution（确认解决），以及用户收到答案后未再请求帮助的 assumed resolution（假定解决）。每段对话最多计一次结果，价格为每个解决 0.99 美元；如果用户后来回到同一对话继续求助，即使跨计费周期，原解决也会被扣回。若 Fin 最后一条只是澄清问题、用户没有回复，则被记为 abandoned（放弃），而不是解决。文档还区分预先配置、正确执行的 procedure handoff（流程转交）与默认升级：前者可以是一种完成结果，用户因不满或主动要求人工而触发的升级则不算解决。
Intercom 2026 年 7 月的另一篇官方文章还指出，CSAT（客户满意度调查）通常覆盖不到 10% 的对话，而且回复容易偏向极满意或极不满的人。其 CX Score 用 AI 给全部人机对话打 1–5 分并解释原因，官方称覆盖量通常约为只看 CSAT 的五倍；但文章也提醒不同问题复杂度必须同类比较。
编辑视角它证明了什么： 这组一手产品规则证明“暂定解决 → 后续推翻 → 账务纠正”和“转人工也可被单独定义”为可实现机制；也证明只等少数用户填问卷会留下大量沉默盲区。但这是供应商自己的规则与效果陈述，不能证明“用户没回复”就真的解决，也不能证明 AI 全量评分天然准确。全量评分扩大的是可见性，仍需用人工抽检、真实任务结果和再次求助校准。
Sierra Horizon：复杂结果往往跨越多次互动，而不是一轮聊天
当真实任务需要几天、几周或多方协作，一段对话的“结束”几乎没有资格代表最终结果。
关键事实
Sierra 在 2026 年 7 月发布 Horizon，主张 Agent 可以围绕贷款发起、医疗流程授权、预约试驾、订阅升级等长期目标，在数天、数周甚至数月内编排多次呼入与呼出互动。官方举例称，一家美国医疗服务机构安排初级医生到专科医生的转诊预约，可能涉及患者、专科机构和转诊医生之间数十次短信与电话；因此系统需要 context engine（上下文引擎）把互动串起来，并用 long-horizon planning（长周期规划）决定下一步。Sierra 同样采用按业务结果而非 token（模型计算用量）收费的主张。
编辑视角它证明了什么： 这个产品机制把“跨对话状态 + 长周期目标”明确做成了 Agent 能力，说明单次会话不是唯一分析单位。但这是一篇产品发布，不是独立实验复盘；它没有公开长期规划的准确率、错误恢复率、不同用户分群效果或隐私代价。更不能把医疗转诊的主动跟进照抄成母婴 APP 触达。我们能借的是“长期任务必须保留状态和停止条件”，不能借的是“只要目标明确，Agent 就应主动追到完成”。
先认识这个人
Bret Taylor 曾参与创建 Google Maps，担任过 Salesforce 联席 CEO，目前是 Sierra 联合创始人兼 CEO。在 Lenny’s Podcast 的访谈中，他把 AI Agent 与传统软件的关键差异概括为：软件过去主要帮助人工作，Agent 开始代表人完成工作；如果工作结果能够被清楚归因和测量，商业模式就可能从按席位、按调用量转向 outcome-based pricing（按结果收费）。
核心机制：用量与价值甚至可能反向
访谈约 1:02:15–1:07:58，Bret 解释，传统软件常用一套很绕的价值推算：“如果每位员工效率提高 5%，那么软件值多少钱？”Agent 如果能自主完成一项工作，结果更容易观察。以客户服务为例，他把有效结果描述为：AI 解决了问题、客户认可，并且不需要人工接电话；行业里常称为 resolution（解决）。
他同时挑战 usage-based pricing（按用量收费）：用了更多 token、聊了更多轮、生成了更多内容，并不代表完成了更好的工作。对 Momcozy AI 助手也一样：五轮对话可能因为 Agent 不断绕圈，一轮后转人工却可能是最安全、最高质量的结果。
最容易误解的地方
“按结果收费”不会自动得到正确结果定义，反而会强化指标激励。如果平台把沉默算解决，它就有动力减少追问和人工接管；如果我们把自动化率定成目标，系统可能把该升级的问题留在机器人里。Bret 的论点成立需要两个前提：结果能被测量，Agent 对结果有足够可归因性。母婴设备帮助通常还受固件、网络、操作系统、实体安装与用户情境影响，不能把最终成功全部归给一段回答。
我们能借什么
新增认知不是“以后按解决付费”，而是：一旦系统开始代表我们行动，增长指标必须从活动量迁移到可撤销的用户结果。 最小版本可以不碰商业模式，只建立一套结果状态机：回答只是候选结果；确认、设备行为或人工复核提高证据；再次求助会推翻旧标签；高风险的正确接管单独记为成功。
以“可撤销解决状态 Agent”为例，完整链路不是自动生成客服结案摘要。
系统读取什么：经授权且最小化的任务类型、Agent 回答、引用知识与工具结果、用户是否明确确认、是否追问或要求人工、设备任务是否在合理窗口内稳定成功、同类问题是否再次出现、脱敏 VOC、人工接管结果，以及数据缺失和版本信息。不得为了追踪结果跨场景拼接儿童、健康或孕产育数据。
形成什么判断：先区分“已回答、等待证据、确认解决、行为验证解决、假定解决、再次打开、正确接管、无法判断”；同时给出证据来源、置信度和到期时间。沉默只能生成低置信度暂定状态，不能直接升级为高可信成功。
能做什么：自动维护状态、撤销被后续证据推翻的解决标签、抽取需要人工复核的高价值样本、聚合反复出现的失败主题，并提出知识修复、产品修复、补测量或低风险实验候选。未经明确授权，不向真实用户发送 Push、EDM、站内信，不主动追问敏感问题，也不改变生产策略。
如何看结果并更新策略：同时看确认解决、行为验证、再次求助、重复设备失败、正确转人工、负面 VOC、商店评价与合理周期内的信任结果；比较不同“解决证据”对后续真实结果的预测力。若 assumed resolution 经常在 48 小时内被推翻，就下调它的权重、延长观察窗口或停止把它用于增长判断。
何时交给人：低置信度、连续失败、设备安全、健康或儿童语境、用户表达焦虑或不满、结果信号互相冲突、隐私投诉，以及任何主动触达和上线决策都交给人。自动给会话打标签属于 AI-assisted Operations（AI 辅助运营）；持续感知跨时段结果、纠正旧判断、生成修复候选并用结果更新策略，才接近受治理的 AI-native Growth System（AI 原生增长系统）。
场景一：设备绑定与故障帮助。 待验证假设是，AI 给出步骤后“用户不再回复”可能混合成功、放弃、转去重试和结果未知。可以借 Intercom 的可撤销状态，但不能把聊天静默直接记为解决。最先需要的证据是：回答曝光、具体错误、后续稳定连接、再次失败和人工求助能否在最小必要范围内串联。若设备后来稳定工作，可以把证据从 assumed 升为 behaviorally verified；若同一错误再次出现，则撤销旧解决。
场景二：AI 助手与 BBM/VOC。 待验证假设是，低风险操作问题可以用“明确确认 + 行为结果 + 再次求助”判断；涉及母婴、儿童或健康的内容，不应把继续留在 AI 对话视为更好。可以借“正确接管也是结果”：Agent 识别风险、保留上下文并交给合适的人，可能比自动结案更有价值。不能用降低人工率作为默认增长目标，也不能把敏感会话转成营销画像。
场景三：阶段性服务与订阅。 Sierra 的长周期状态提醒我们，用户需求可能跨多次互动，但主动跟进必须建立在清楚授权、频控和停止条件上。不能因为系统推断用户处于某个孕产育阶段，就自动追踪或推荐；阶段自然结束、用户拒绝或“不动作”都应是合法终止状态。最先要验证的不是怎样多触达，而是哪类任务真的需要跨时段延续。
- Outcome Window｜结果观察窗口：回答之后继续等待结果成熟或被推翻的一段时间。Momcozy 例子：设备帮助后观察是否稳定连接、是否再次报错，而不是消息发出即结案。
- Confirmed / Assumed Resolution｜确认解决 / 假定解决：前者有用户或行为证据，后者只因没有继续求助而暂定。Momcozy 例子：“已经连上”比聊天沉默证据更强。
- Reopen Rate｜重新打开率：被判解决的问题后来又回来求助的比例。Momcozy 例子：同一连接错误 48 小时内再次出现，会推翻原解决标签。
- Long-horizon Planning｜长周期规划：为跨多次互动的任务持续保留状态并选择下一步。Momcozy 只能在已授权、低风险、有停止条件的场景探索，不能默认主动追踪敏感阶段。
- Outcome-based Pricing｜按结果收费：费用与完成的用户结果绑定，而不是与 token、席位或会话量绑定。Momcozy 当前最值得借的是结果定义纪律，不是立刻改商业模式。
画一张“设备帮助结果状态机”，不修改生产系统，也不触达真实用户：
- 从“AI 已给出连接指导”开始，画出：等待证据、用户确认、设备稳定成功、结果未知、再次失败、正确转人工六个状态；
- 给每个状态写一条进入证据、一条可推翻证据和一个观察期限；
- 圈出哪两个状态绝不能计入“自动解决”；
- 写一个人工接管也应被视为成功的高风险例子。
产出物是一页“状态—证据—期限—撤销—接管”图。完成后能更新的判断是：我们衡量的是 Agent 有没有把对话关掉，还是用户的问题是否真的、安全地得到解决？最后只回答一个具体问题：如果用户看完设备帮助后没有回复，但 24 小时内也没有可验证的稳定连接事件，我们应该把它记为解决、失败，还是结果未知？为什么？