AI Agent 在离线模拟里“全部通过”，只能证明它通过了我们已经想到的考题，不能证明真实用户体验会改善。可靠的发布必须连过三道门：上线前用 eval 防已知错误，上线中用小流量实验验证真实增量，上线后用持续监控发现新失败。只做第一道门，是质量保障；三道门能把生产失败重新变成测试与策略，才接近 AI-native 增长闭环。
过去的软件功能大多相对确定：同一段代码、同一输入，通常得到同一结果，QA 可以检查按钮、页面和固定规则。AI Agent（能读取信息、调用工具并连续行动的 AI 系统）不同：同一个问题可能有多种说法，同一问题重复运行也可能出现不同路径；改一条知识、提示词或工具规则，可能修好退款，却意外破坏转人工。
Eval-driven Delivery（评测驱动发布），大白话是：每次改 Agent 前，先用一组代表性任务检查“它该做什么、不该做什么”；通过后不直接全量，而是在真实环境中逐步放量、保留对照；上线后继续检查真实对话，把新失败变成下一轮测试。它解决的不是“模型分数不够高”，而是“我们如何知道一次改动真的更好，而且没有把别处弄坏”。
生活类比是飞行员训练。模拟器能测试发动机故障、恶劣天气和标准程序，但模拟器满分不等于可以让一架新飞机直接满载起飞。还要试飞、小范围投入、持续读取真实故障记录。Momcozy APP 的待验证例子是设备连接助手：离线题可以检查步骤是否正确、是否引用对应设备知识、危险情境是否转人工；真实小流量才回答它是否提高稳定连接、减少重复失败，同时没有增加错误操作和负面体验。
这里要特别区分两种证据：offline eval（离线评测）回答“Agent 在已知场景里能否达到标准”；online experiment（在线实验）回答“这版体验面对真实用户，相比旧版是否产生增量结果”。前者不能代替后者，后者也不能在没有安全与质量底线时贸然开始。
Intercom：上线前模拟、上线中实验、上线后监控
AI 客服的质量控制正在从一次验收，变成“Evals → Releases → Monitors”的持续发布系统。
关键事实
Intercom 在 2026 年 8 月 13 日发布 Evals 与 Releases。Evals 可用真实对话构造多轮模拟，分别定义模拟用户、Agent 可访问的数据与连接器，以及成功标准；评分混合确定性检查和 LLM judge（让大模型按规则做评审），任一关键标准失败即可判整条模拟失败，并保留完整 transcript（过程记录）、事件和最终结果。Release 把内容、Procedure 和 Guidance 的改动隔离在非生产版本中，先重跑评测，再选择全量、小流量渐进或 A/B test；异常时可暂停、修复、复测和回滚。上线后 Monitors 检查真实对话，被标记的失败又可转成新模拟。
编辑视角它证明了什么： 这证明“生产失败 → 测试案例 → 新发布 → 再监控”已经能被产品化，也让评测不再只是开发阶段的一张成绩单。但这是供应商对自身产品机制的说明，没有公开独立实验结果；模拟通过仍不能证明真实解决率、信任或留存改善。若历史对话本身覆盖偏斜，评测也会稳定漏掉少见但高风险的母婴、儿童或设备安全情境。
Sierra：Agent 改动也需要真实对照，而不是只听模型解释
当 Agent 的语气、追问顺序或挽留动作都是产品策略时，真实用户的随机对照结果比“这版看起来更好”更有资格决定放量。
关键事实
Sierra 在 Agent Studio 的 Experiments 中，把 Agent 变体放入 A/B test，观察 resolution rate（问题解决率）、churn reduction（流失减少）等业务结果；仪表盘显示统计显著性、效果何时出现及是否随时间稳定，并支持从少量流量逐步扩大。其 Ghostwriter 会分析对话模式、提出假设并生成实验，官方强调洞察只能提出原因，control 与 treatment（对照组与处理组）的比较才更接近建立因果。
编辑视角它证明了什么： 这证明 Agent 不只是一个模型版本，也可以作为可控的产品策略接受随机实验；“发现模式”和“验证因果”被明确分开。但文章没有披露具体样本、效应大小或失败率，“一个下午开实验”也不适合直接照搬到母婴设备场景。提高实验数量不是目标；如果结果定义把沉默算解决、把少转人工算成功，系统只会更快优化错目标。
先认识这两位，以及今天新增什么
Hamel Husain 与 Shreya Shankar 长期帮助产品和工程团队建立 AI eval，他们的课程已培训超过 2,000 名产品与工程从业者。我们此前已经拆过 error analysis（错误分析）、开放编码、校准 LLM 评审和真实用户 trace 覆盖；今天新增的是访谈约 1:00:51 的判断：evals are the new PRDs——评测正在成为 AI 产品里“会执行的需求文档”。
过去的 PRD 为什么不够
传统 PRD（Product Requirements Document，产品需求文档）会写“助手应准确回答、语气友好、必要时转人工”。这些句子让人知道方向，却很难自动判断某次发布是否遵守。两位产品负责人还可能对“必要时”有完全不同理解；随着知识、模型和工具变化，静态文档也不会主动报警。
Living PRD（活的需求文档）的变化，是把模糊要求变成可重复运行的任务与判定：什么情境必须先澄清，什么工具必须调用，什么结果才算完成，什么情况绝不能自行回答，哪类正确接管也算成功。每次系统变化都重跑这些任务，需求不再只被阅读，而是持续约束行为。
AI 改变了哪一步
AI 可以把经人工确认的生产失败转成候选测试，批量模拟措辞与多轮变化，用确定性规则检查工具和最终状态，再用经过人工校准的 LLM judge 判断解释是否清楚、语气是否合适。这样，产品人员定义的质量标准可以持续进入发布流程，而不是发布后等投诉才发现需求没有落地。
但两位嘉宾强调的逻辑不能被偷换成“让模型自己写题、自己判卷、自己宣布上线”。最初的错误类型仍需要人阅读真实轨迹并定义；评测集只覆盖已经被表达出来的产品意图。对 Momcozy 而言，离线评测能成为发布合同，却不能替代真实任务结果、随机实验、隐私审查和高风险人工接管。
我们最值得借什么
先给一条窄旅程建立“可执行需求”，而不是先追求大而全的 Agent 分数。比如设备连接指导只需覆盖：正确识别失败节点、引用匹配知识、不给危险建议、结果不明时不冒充成功、连续失败时正确接管。等它通过离线门，再讨论小流量真实验证。这样 eval 是发布资格，不是增长胜利。
以“评测驱动发布 Agent”为例，完整链路如下。
系统读取什么：已批准的行为标准、历史脱敏失败轨迹、离线任务与评审规则、这次内容/提示词/工具改动、版本和回滚点；上线后再读取随机分组、真实曝光、任务结果、重复失败、正确接管、负面 VOC 和监控告警。母婴、儿童、健康与设备数据只按当前目的最小化使用，不默认跨场景拼接。
形成什么判断：先判是否通过 capability eval（能力评测）与 regression eval（回归评测，即旧能力有没有被破坏）；再判风险是否允许进入影子模式、小流量或 A/B；上线后区分“质量合格但无增量、真实改善、护栏受损、数据不足或结果冲突”。
能做什么：自动重跑评测、生成失败差异、阻断未达安全线的发布、为已批准的低风险改动建议渐进流量、发现异常时暂停并回滚；把经人工确认的新失败加入回归集。它不能自行降低安全阈值、扩大敏感数据用途，也不能未经明确授权向真实用户发送 Push、EDM、站内信或修改生产策略。
如何看结果并更新策略：离线失败就修版本，不进入真实实验；离线通过但在线结果无改善，就降低该假设置信度，而不是继续润色；在线结果改善但高风险接管、重复失败或负面 VOC 变差，则判不应放量；稳定胜出后仍持续监控漂移，新失败进入下一轮 eval。
何时交给人：新高风险主题、健康或儿童语境、设备安全、隐私授权不清、评审器与人工判断分歧、结果指标定义、线上因果结论和所有全量发布，都交给人。自动跑一套测试属于 AI-assisted Operations（AI 辅助运营）；系统持续从生产学习、提出改动、逐门验证、在权限内暂停回滚并更新测试与策略，才接近 AI-native Growth System（AI 原生增长系统）。
场景一：设备连接 AI 助手。 待验证假设是，一次知识或提示词更新可能提高常见问题回答，却破坏弱网、权限拒绝或不匹配设备下的接管。可以借 Intercom 的三层链路：离线先测“该回答 / 该澄清 / 该接管 / 不该行动”；通过后只在已批准低风险范围做小流量；真实结果看稳定连接、重复失败和正确接管，而不是回答是否生成。不能用敏感对话训练营销画像，也不能让 Agent 对设备安全做未经批准的动作。
场景二：绑定帮助流程。 待验证假设是，新帮助卡在模拟路径中更清楚，但真实环境可能因 APP、系统、固件和网络差异产生选择性曝光。可以借 Sierra 的对照思路，区分 assignment（被分组）、exposure（真实看到）与稳定结果；同时保留崩溃、客服、负面 VOC 为护栏。不能因为离线任务全部通过就宣布增长，也不能因为点击增加就判断绑定改善。最先需要的是一张“三道门”证据表：每道门回答什么、不能回答什么、失败后如何停止。
可以借什么、不能照抄什么：可以借可执行需求、渐进发布、回滚和生产失败回灌；不能照抄高频客服“多做实验就多学习”的速度。Momcozy 的实体设备结果更慢、外部变量更多、错误代价更高。系统首先要提高每次发布的证据质量，而不是最大化发布次数。
- Eval-driven Delivery｜评测驱动发布：用评测决定改动是否有资格逐步上线，再用真实结果和监控继续校正。Momcozy 例子：连接助手先过安全题，再进小流量验证。
- Offline Eval｜离线评测：不用真实用户，在固定或模拟任务上检查行为。Momcozy 例子：测试连续失败时是否正确转人工；它不能证明真实绑定会提升。
- Regression Eval｜回归评测：检查一次修复有没有破坏原来已经会做的事。Momcozy 例子：修正蓝牙指导后，旧设备的权限说明仍需正确。
- Progressive Rollout｜渐进发布：先给少量合格流量，确认结果和护栏后再扩大。Momcozy 例子：低风险帮助改动从受控小流量开始，并保留即时回滚。
- Living PRD｜活的需求文档：把产品要求写成持续可运行、会报警的测试。Momcozy 例子：“高风险必须接管”不只写在文档里，而是每次发布都被验证。
给一个假想的 “设备连接 AI 指导更新” 写一张三道门发布卡，不查真实敏感数据、不改生产、不触达用户：
- 上线前门：写 5 个必须通过的离线场景，其中至少包含一个“必须不回答、转人工”的反例；
- 上线中门：写一个真实结果、一个对照方式和两个护栏，明确点击与会话量不能当最终结果；
- 上线后门：写一个会触发暂停/回滚的信号，以及怎样把新失败加入回归集；
- 每道门各补一句“它能证明什么、不能证明什么”。
产出物是一页“离线资格—在线增量—持续监控—停止条件”发布卡。完成后能更新的判断是：我们现在把 eval 当作 AI 的考试成绩，还是把它放进了一条能对真实用户结果负责的发布系统？最后只回答一个具体问题：如果新版离线评测从 82% 提升到 96%，但小流量中的稳定连接没有改善、重复求助反而上升，我们应该继续放量、继续观察，还是回滚？你会用哪条护栏做决定？