从“Eval 全绿”到真实用户成功：Agnost AI 与 Agent 静默失败的生产闭环

目录一、Eval 全绿为什么用户仍然悄悄离开一静默失败重在是“用户目标没有闭环”1. 执行表面成立2. 用户价值没有实现3. 失败信号是间接的二人工评测的盲区来自数据生成方式三Agent 质量不是一个分数而是四层证据1. 输出层说得对不对2. 轨迹层怎么做到的3. 会话层用户是否得到进展4. 结果层工作是否经受住现实二、Agnost AI 的核心把生产对话变成质量发现面一数据底座会话、事件与工具调用必须同时存在1. 会话提供用户目标2. 事件提供执行过程3. 工具调用提供外部世界的证据二分析层Intent 与 Violation 是两种不同的问题发现方式1. Intent 回答“用户想做什么”2. Violation 回答“预期行为是否被违反”三聚类层把单条抱怨升级为可优先级排序的模式四行动层从发现到 Improvement而不是自动把一切交给模型修改三、真正的代际变化评测数据源从“预设”变成“流量驱动”一上一代闭环先定义正确再验证变化二新一代闭环先观察分布再决定评测什么三四层质量系统比单一平台更重要1. 发布前离线 eval 阻止已知回归2. 运行中trace 与在线评分发现执行异常3. 体验中会话模式发现未知失败4. 业务中真实结果验证修复价值四Agnost 更像 Agent 产品分析而不只是可观测性四、静默失败分类法从一句“它不好用”到可执行问题一目标与语义错位1. 完成字面请求错过真实任务2. 多意图切换后仍停留在旧任务二上下文与记忆失败1. 用户纠正了系统没有真正吸收2. “显然来自上下文”的信息被猜错三工具与外部状态失败1. 工具假成功2. 路径偶然成功但不可持续四交互与恢复失败1. 在错误时机提出正确问题2. 走错第一步后无法恢复五交付与可感知进展失败1. 任务“完成”但制造大量返工2. 系统做了事用户却感受不到进展六信任、需求与漂移1. 使用量没降委托价值在下降2. 新需求与版本漂移被平均值掩盖五、如何把生产流量变成可信的 Eval 飞轮一第一关建立最小但完整的遥测契约1. 稳定标识1.1 会话关联1.2 版本关联2. 结构化结果3. 业务反馈二第二关先做数据边界再开全量内容采集三第三关把“候选模式”与“确认缺陷”分开四第四关不是每个生产异常都适合变成 Eval1. 任务级 Eval2. 轨迹级 Eval3. 会话级 Eval五第五关防止污染、过拟合与评分器漂移六第六关用生产结果证明修复有效六、Agnost AI 的产品判断价值、边界与竞争位置一公开信息能够确认什么1. 机制描述具体2. 商业方案已经公开3. 产品仍处早期阶段二哪些主张仍需要验证1. 聚类准确性与误报成本2. Eval 生成的可执行程度3. 自动修复的根因质量4. 商业效果数字三与同类平台的真实差异四适合与不适合的团队1. 更适合2. 暂不适合七、90 天落地方案先证明发现价值再扩大自动化一0—14 天定义边界与成功标准1. 选一个高价值窄场景2. 建立数据清单3. 固定评价基线二15—30 天验证“发现”而不是验证“仪表盘好看”三31—60 天完成三个闭环样本四61—90 天决定扩大、并行还是停止五组织机制质量闭环不能只属于 ML 团队八、进一步推演Agent 质量系统会变成什么一Eval 将从静态题库变成有版本的知识资产二会话将成为产品需求、质量与训练的共同数据面三“用户成功”会取代“回答质量”成为顶层指标四自动发现不会消灭人工判断反而提高其杠杆五最终判断可参考文章与资料干货分享感谢您的阅读如果把 AI Agent 比作一位自信满满的“数字同事”那么传统 eval 就像岗前考试答案标准、考场安静它往往能拿到分数。可进入生产环境客户换种问法、工具接口打个喷嚏、上下文拖到十几轮这位优等生可能一本正经地绕路甚至礼貌地把用户送进死胡同。它不会举手说“我失败了”监控面板也可能一片祥和只有用户追问三次后默默关闭页面留下一串看似正常、实则充满求救信号的对话。于是团队庆祝评测通过率上涨却困惑留存率为什么不配合演出。Agnost AI 瞄准的正是这种最会“装没事”的失败。它不满足于让人先猜问题、再编测试题而是回到生产会话中寻找蛛丝马迹模型是否漂移回答是否貌似完整却没有解决任务用户是否从耐心解释变成简短敷衍反复出现的抱怨是否其实是一项未被记录的功能需求。随后它把零散信号聚类为失败模式再将模式转成可复现的 eval 与明确的修复项。换句话说评测不再只是上线前的一道门禁而开始像一名驻场的质量侦探从流量里找案发现场把“我们没想到”变成“下次一定测到”。这篇文章将拆解这套闭环为何重要、怎样落地以及团队如何避免把聪明系统做成又一个只会闪绿灯的仪表盘。一、Eval 全绿为什么用户仍然悄悄离开很多团队把 Agent 上线后的质量问题想象成一种“会报警的故障”接口返回 500、工具调用报错、模型拒答、延迟突破阈值。于是工程侧监控错误率、P95 延迟和 token 成本算法侧维护一套 golden set发布前跑回归只要系统没报错、评测分数没下降就默认产品仍在正常工作。真实世界更棘手。Agent 可能完整返回了一段流畅文本工具链也显示成功用户却没有得到想要的结果它回答了字面问题却没完成用户真正的任务它口头承诺已经发送文件实际附件并不存在它在第三次纠正后仍选错客户它提出了“正确的澄清问题”但问题出现得太晚让用户放弃操作。系统看起来运行良好伤害却已经发生。这类问题之所以危险不是因为它们完全不可见而是因为它们没有被现有质量系统定义成失败。日志把一次请求记为成功传统漏斗把一次对话记为活跃离线评测只验证预先写下的场景。用户的失望则藏在“算了我自己来”“不是这个”“你到底做了什么”等短句里甚至什么也不说直接把下一次高价值任务交给别的产品。静默失败的证据断点。上方泳道是传统监控看到的请求成功、模型回复与工具返回码下方泳道是用户真实经历的目标未完成、多次纠正与最终放弃。三条向下虚线表示不能仅凭技术成功推断任务和用户成功。一静默失败重在“用户目标没有闭环”可以把静默失败定义为系统在技术层面完成了一次可观测执行却没有可靠完成用户期望的工作而且失败没有触发明确错误或主动反馈。这个定义包含三个条件。1. 执行表面成立模型生成了输出API 返回成功工具调用可能也显示successtrue。如果只看基础设施指标这次任务没有异常。Agnost 官网给出的典型例子是Agent 声称已发送 PDF但用户并未收到或者回答非常自信却回答了错误的问题。这里的关键不在“有没有文本”而在承诺、动作和外部状态是否一致。2. 用户价值没有实现用户购买的不是一串 token而是任务进展。客服 Agent 的价值不是“给出取消政策”而是正确解释政策、验证身份、完成取消并让用户知道结果编程 Agent 的价值不是“输出代码”而是代码在目标仓库中可运行、可维护且没有破坏现有行为。只测输出正确性容易忽略任务完成度、修复成本和后续影响。3. 失败信号是间接的静默失败通常表现为纠正、重试、绕行、手工清理、缩小委托范围、对答案加上防御性约束或在澄清问题之后中断会话。Agnost 的公开文章把“同一用户后来只委托更小的任务”视为信任下降的迹象这个判断有启发性但在实务中仍需结合用户分群、业务周期和外部事件验证不能把相关性直接当作因果关系。二人工评测的盲区来自数据生成方式人工用例并不低级。相反它是稳定回归、合规验证和发布门禁的核心。问题在于人只能把已经理解的失败写成测试。当测试集主要来自需求文档、工程师经验和历史缺陷时它天然更擅长回答“昨天的问题有没有回来”不擅长发现“今天的用户正在用什么新方式把系统推到边界”。OpenAI 的评测最佳实践明确建议记录开发与生产日志、从日志中挖掘用例并让评测集持续增长Anthropic 也把自动评测、生产监控、用户反馈、会话抽检和系统性人工研究视为互补层而不是互相替代。换言之“生产数据反哺评测”并非某一家产品独有的口号而是 Agent 工程正在形成的共同方法论。传统评测的结构常是“任务—参考结果—评分器”。生产会话却带来四种额外复杂度输入分布在变化任务跨多轮推进工具和权限影响最终状态用户是否接受结果本身就是质量信号。一个单轮问答可以得到 0.9 分但如果用户连续三次纠正实体、最后手工完成任务产品层面的成功率应当接近零。三Agent 质量不是一个分数而是四层证据1. 输出层说得对不对这一层包含事实性、相关性、格式、语气和安全性最适合传统离线 eval、规则校验与 LLM-as-a-judge。它仍然重要却只覆盖最终输出的一部分。2. 轨迹层怎么做到的Agent 可能给出正确答案却经过错误工具、重复循环、越权路径或不可复现的偶然路线。OpenAI 的 trace grading 把模型调用、工具调用、guardrail 与 handoff 的端到端记录作为评分对象目的正是发现工作流级别的问题。轨迹回答“系统内部发生了什么”但仍不必然回答“用户满意了吗”。3. 会话层用户是否得到进展会话层关注纠正次数、澄清后的放弃、情绪变化、同一目标的反复表述、完成后仍追问状态等信号。这里既有模型问题也有产品设计问题权限提示不清、入口错误、状态反馈不足都会被用户体验成“Agent 不好用”。4. 结果层工作是否经受住现实真正的结果可能发生在会话之后工单是否重开、退款是否增加、生成的配置是否被回滚、销售线索是否进入下一阶段、用户是否继续委托高价值任务。结果层最接近商业价值却也最难归因。成熟系统必须把会话、轨迹与业务结果通过稳定标识连接起来而不是只看聊天窗口内的最后一句话。二、Agnost AI 的核心把生产对话变成质量发现面Agnost AI 在 Product Hunt 上的定位是“捕捉 eval 漏掉的 Agent 失败”。公开页面称其分析生产环境中的用户—Agent 对话发现静默失败、行为漂移、幻觉、用户受挫、隐藏功能诉求和流失信号将相似会话聚合成模式并关联具体会话和轨迹再转成改进建议、eval 与修复动作。这段描述很容易被概括成“又一个 LLM 可观测平台”。但更准确的理解是Agnost 试图把 Agent 质量的主入口从“工程师先定义检查项”改成“生产证据先暴露问题”。它关注的不是单条 trace 是否异常而是大量会话中反复出现、具有用户影响且尚未被团队命名的模式。从生产会话到修复验证的闭环工作流。按箭头依次为采集会话与工具轨迹、识别异常信号、聚类重复模式、人工确认损害、生成评测与修复项、上线验证并回流新证据。中间证据条强调每个模式都必须保留具体会话、Agent 版本、工具轨迹和用户结果。一数据底座会话、事件与工具调用必须同时存在1. 会话提供用户目标Agnost 文档把 conversation 定义为一段相关 Agent 交互的用户视图要求整个多轮过程复用稳定的conversation_id或session_id。如果每一轮都生成新标识系统会把一次纠错过程切成若干孤立片段如果多个用户共用同一标识又会把不同任务错误合并。这个看似基础的埋点细节实际上决定了后续聚类是否可信。会话视图用于判断用户目标是否解决、是否反复提问或纠正、是否中途放弃并结合版本、套餐、入口和用户分群解释结果。也就是说Agnost 不只读取一句输入与一句输出而是试图恢复“用户故事”。2. 事件提供执行过程事件可以代表 Agent turn、模型生成、handoff、guardrail 或其他被追踪的操作。它们让分析从“这段对话让人不满意”下钻到“哪一个内部动作造成了偏差”。如果只有对话文本系统可能发现用户受挫却无法区分是提示词、检索、路由、权限还是工具超时造成的。3. 工具调用提供外部世界的证据工具调用被单独建模便于比较调用量、成功率、延迟、错误分布、参数和结果。静默失败常发生在自然语言承诺与外部状态之间模型说“已完成”工具其实没有执行工具返回空结果模型却补写了一个看似合理的答案。因此工具结果不能只是调试附件而应成为任务成功判定的一部分。OpenTelemetry 在这里很重要。Agnost 支持 OTel 以及多种 Agent 框架接入OpenTelemetry 的 GenAI 语义约定也在标准化模型、token、工具和 Agent 相关遥测。标准化并不会自动产生洞察但能降低数据锁定和重复埋点成本让团队保留更换分析后端的余地。二分析层Intent 与 Violation 是两种不同的问题发现方式1. Intent 回答“用户想做什么”Agnost 的 Intents 页面聚合用户目标的出现量允许从产品说明和已观察流量生成建议意图并回到支持该意图的具体会话。Intent 的价值不仅是分类还在于发现需求分布变化某个尚未正式支持的工作流突然增加或者高价值用户反复请求同一能力。但意图命中不等于成功。公开文档专门提醒intent count 只是分类结果不证明用户完成了目标。实务中应把意图与 violation、结果、工具活动和用户分群联合分析。例如“取消订阅”意图上升可能是帮助文档改版后的正常迁移也可能是产品价值下降的前兆只有结合完成率、情绪和真实取消结果才能判断。2. Violation 回答“预期行为是否被违反”Agnost 把 SOP 定义为 Agent 应遵循的规则violation 表示对话未遵循该规则。适合的规则是能从收到的证据中判断的具体行为例如“展示账户信息前确认身份”“完成取消前说明政策”“用户报告安全问题时升级处理”。这一路径仍然包含人工预设因此它不是“未知失败发现”的全部。它的作用更像在线行为检查把已知规则持续应用于生产会话。更重要的是Agnost 文档明确表示 violation 只是分类发现不是强制执行关键安全与授权检查仍应放在应用代码中。任何把离线分析产品当成实时安全边界的做法都是危险的责任错位。三聚类层把单条抱怨升级为可优先级排序的模式单条失败不一定值得修。它可能是噪声、极端上下文、一次性误解或用户自身条件缺失。真正影响产品路线的是反复出现的失败族群同类意图、相似轨迹、相同版本、相同工具或同一用户阶段下出现的一组会话。聚类的价值在于压缩认知负担。团队不必每天阅读上千条对话而是审阅若干候选模式并查看支持证据。一个可靠的模式至少需要四个维度语义一致性、用户影响、出现频率和可行动性。只有“语义相似”会把许多表面措辞相近、根因不同的会话错误合并只看频率又会让高频低损问题挤压低频高风险问题。静默失败的四族十二类分类树。蓝色 1—3 是任务语义类目标错位、结果需返工、隐藏诉求紫色 4—6 是状态与工具类上下文遗失、工具假成功、状态不透明青色 7—9 是交互与恢复类重复纠正、澄清后放弃、恢复失败玫红 10—12 是信任与变化类语气摩擦、委托范围缩小、版本漂移。分类先分族再落到具体模式便于指定不同的证据、评分器和责任人。四行动层从发现到 Improvement而不是自动把一切交给模型修改Agnost 的 Improvements 文档把 improvement 定义为基于生产证据的建议变更其 Auto Improve 工作流可以调查发现、读取仓库上下文、准备变更并追踪分支或 PR 与上线后的结果。公开文档同时要求像审查其他工程贡献一样审查生成变更、运行测试、确认安全与数据边界再通过既有流程部署。这条边界很关键。生产会话能告诉你“哪里痛”却不能自动证明“为什么痛”以及“怎样改一定更好”。同一个纠正循环可能来自系统提示、记忆检索、前端状态、工具 schema 或产品规则。将模式直接翻译为 prompt 修改容易得到局部改善和全局回归。正确闭环是证据形成假设人工确认根因生成可重复 eval候选修复先过离线门禁再灰度验证生产指标。三、真正的代际变化评测数据源从“预设”变成“流量驱动”把 Agnost 的意义理解为“自动写 eval”还不够。更深的变化在于评测系统的采样权发生了转移。过去工程团队决定哪些问题值得进入测试集现在真实用户行为可以持续提出新的测试候选。质量体系从封闭题库变成开放的观察—归纳—验证循环。一上一代闭环先定义正确再验证变化传统流程通常从产品要求和历史缺陷出发定义成功标准构造输入准备参考答案或评分器在每次 prompt、模型或代码变化后运行回归。这种机制对确定性约束尤其有效例如输出 JSON、必须调用特定工具、不得泄露隐私、关键业务规则不可违反。它的上限由题库覆盖决定。如果用户开始用新语言表达旧意图、多个意图在一段对话里切换、工具返回新的边界状态旧题库可能仍然全绿。更隐蔽的是团队会逐渐围绕现有分数优化形成“测得到的越来越好没测到的无人负责”。二新一代闭环先观察分布再决定评测什么生产驱动机制首先问哪些用户目标正在增长哪些会话出现高纠正、高放弃或信任下降哪些模式集中于新模型、特定工具或某个分群然后才把稳定、可重复、存在明确期望的模式转成 eval。这不是让生产流量直接污染测试集。相反需要严格的数据治理训练、调试、验证和长期保留集必须分开相同会话及其近似变体不能同时进入训练与测试高频模式要采样低频高风险模式要保留用户数据必须脱敏并符合授权。否则“真实数据”只会带来更真实的数据泄漏和更隐蔽的过拟合。三四层质量系统比单一平台更重要Agent 质量的四层证据栈。自下而上分别回答已知任务是否退化、执行过程是否正确、真实流量里有哪些未知失败、用户目标是否真正完成。右侧治理栏说明人工校准、安全门禁和数据治理横跨四层而不是孤立的第五层。1. 发布前离线 eval 阻止已知回归它应覆盖关键任务、边界条件、安全规则和业务契约并在模型、prompt、工具或工作流变化时自动运行。2. 运行中trace 与在线评分发现执行异常这一层适合检查错误工具、循环、延迟、token 激增、路由偏差和规则违反。OpenAI、LangSmith、Langfuse、Phoenix、Braintrust 等平台都在把 traces、online eval 与 datasets 连接起来。3. 体验中会话模式发现未知失败这正是 Agnost 强调的层。它关注用户是否纠正、放弃、失去信任是否暴露未被产品团队定义的新意图。这里需要语义聚类和产品判断而不仅是工程告警。4. 业务中真实结果验证修复价值修复后不能只看新的 eval 分数。还要观察任务完成率、重开率、人工接管率、退款、转化、委托深度等结果是否改善。否则团队可能把评分器优化成了更高分却没有让用户更成功。四Agnost 更像 Agent 产品分析而不只是可观测性传统可观测性擅长回答“服务为什么慢”“哪次工具调用失败”产品分析擅长回答“用户在尝试什么”“哪一段旅程流失”。Agent 把产品界面、决策逻辑和执行过程压缩进同一段对话导致这两类系统必须合流。Agnost 自称“面向对话式 Agent 的产品分析”这个定位比“LLM 监控”更准确。它试图把会话意图、用户受挫、规则违反、轨迹证据和改进工作连接起来。真正的竞争优势不会只来自某个分类模型而取决于能否让产品、工程、算法和安全团队共享同一证据对象并把发现稳定转成可审查的工作项。四、静默失败分类法从一句“它不好用”到可执行问题没有分类法聚类结果就会变成漂亮但难行动的主题云。下面给出一套面向 Agent 产品的六大类、十二种典型模式。它既可用于人工抽检也可作为生成 intent、violation、grader 和业务指标的框架。一目标与语义错位1. 完成字面请求错过真实任务用户说“给应用加计费”Agent 只生成付款按钮却没有套餐、试用状态、webhook、权限和升级文案。输出在狭窄评分标准下可能合格但用户需要的是完整工作流。识别信号包括后续大量出现“还要”“别忘了”“这应该同时……”等补充。2. 多意图切换后仍停留在旧任务用户在一段对话中从订单查询转向产品咨询Agent 没有正确 handoff继续围绕旧实体操作。应同时检查对话主题变化和内部路由轨迹而不是只评最后一句回答。二上下文与记忆失败1. 用户纠正了系统没有真正吸收Agent 道歉并复述纠正却在下一步继续使用错误客户、表名或日期。这是一种比单次误解更严重的失败因为它破坏了“纠正应产生状态变化”的基本预期。可定义“同一实体重复纠正率”并要求修复后的 eval 覆盖多轮重定向。2. “显然来自上下文”的信息被猜错“还是上次那个”“发给 Sam”“用另一份表”都依赖共享上下文。Agent 如果不确定应暴露它看到的候选对象或请求最小澄清而不是暗中猜测。这里的质量标准不是永远不问而是在错误成本和交互成本之间做可解释选择。三工具与外部状态失败1. 工具假成功模型把调用意图当成了执行结果或者工具返回部分成功却被包装成完整成功。修复需要建立“承诺—调用—结果—外部状态”四段校验凡是声称已写入、已发送、已预订的动作都应有可验证的工具证据和幂等标识。2. 路径偶然成功但不可持续Agent 硬编码值、依赖脆弱选择器、以错误顺序调用工具当前样本恰好成功后续数据变化就失败。单看最终输出发现不了这种风险必须通过 trace grader、状态测试和延迟后的结果检查识别。四交互与恢复失败1. 在错误时机提出正确问题探索性任务中澄清能提高质量重复性操作中过度澄清会让用户像管理初级员工一样疲惫。应按任务类型测量“澄清后放弃率”而不是统一奖励所有谨慎提问。2. 走错第一步后无法恢复很多 eval 每次都从干净上下文开始真实用户却会把 Agent 从错误分支拉回来。会话越长、解决概率越低是恢复失败的典型信号。评测应加入错误注入与中途纠正让 Agent 证明它能回滚假设、重新规划并解释状态。五交付与可感知进展失败1. 任务“完成”但制造大量返工用户不一定会点差评而是默默改格式、补约束、重写语气或修复小假设。可把用户后续编辑量、复制后修改比例、同类任务的重复约束视为“清理负担”。如果平台拿不到外部编辑行为至少应从对话中的密集修订指令提取代理信号。2. 系统做了事用户却感受不到进展Agent 没有清楚说明改了什么、还剩什么、下一步是什么用户只能追问“所以完成了吗”。这不是内容准确性问题而是状态可见性问题。修复可能是输出模板、过程通知或产品 UI而不一定是换模型。六信任、需求与漂移1. 使用量没降委托价值在下降用户继续使用产品但只交给它低风险小任务并添加越来越多防御性指令。DAU 仍然稳定产品获得的信任份额却在缩水。可以跟踪同一用户的任务复杂度、工具权限范围和人工复核行为但必须避免把正常的任务组合变化误判为信任下降。2. 新需求与版本漂移被平均值掩盖新入口、新模型、新工具版本或新用户群可能只影响少数流量总体成功率几乎不动。团队需要按agent_version、model、surface、plan、language、tenant 等维度切片并监控模式分布而非只看平均分。隐藏功能诉求也应单独进入产品发现流程不能与缺陷混在一个修复队列里。五、如何把生产流量变成可信的 Eval 飞轮“自动生成 eval”听起来像一步功能工程上却至少包含六个关卡。任何一关偷懒都会把生产噪声放大成错误门禁。一第一关建立最小但完整的遥测契约1. 稳定标识1.1 会话关联至少需要 user、tenant、conversation、turn、trace 和 tool call 的稳定关联。标识应当是假名化的内部 ID不应直接发送姓名、邮箱和手机号。1.2 版本关联每条证据还要绑定 agent version、model、prompt version 与 deployment。没有版本信息团队只能看到“失败变多”却无法判断变化始于哪次发布。2. 结构化结果工具调用应记录工具名、父级会话或 turn、成功/失败、错误码、端到端延迟以及在允许的情况下记录经过脱敏的参数和结果。对高风险动作应额外记录外部状态确认与幂等键。3. 业务反馈把会话后的结果回写到同一证据链是否解决、是否转人工、是否重开、是否退款、是否回滚、是否继续下一阶段。没有结果标签系统只能推测“像是成功”。二第二关先做数据边界再开全量内容采集Agnost 的数据治理文档明确说明它会分析客户选择发送的 prompts、outputs、tool calls、错误、用户标识与 metadata并且当前不提供摄入前自动 PII 脱敏或 DLP。官方建议在应用侧先脱敏、假名化或省略敏感字段使用 metadata allowlist先在 staging 检查一条完整 trace再扩大到生产。这意味着接入评估不能只问“SDK 需要几行代码”还要问哪些字段离开本系统内容在哪个区域处理保存多久谁能查看会话删除请求如何传播是否涉及医疗、支付、政府证件、儿童、求职或其他受监管数据。对于高风险场景metadata-only、脱敏文本和抽样采集通常比一开始全量上传更稳妥。数据最小化的五段边界。主路径 1→5 依次是业务系统、客户端脱敏与字段白名单、最小会话/事件/工具遥测、受控分析环境、评测与修复输出。节点 2 上方的红色支路表示直接身份信息和非必要敏感字段应在发送前阻断下方绿色框表示只有通过白名单的字段才能进入后续分析。三第三关把“候选模式”与“确认缺陷”分开聚类系统给出的只是候选。应建立轻量人工审阅查看代表会话、边界样本和反例确认是否同一根因判断用户影响指定 owner决定它属于缺陷、需求、运营、数据问题还是风险事件。可以用一个简单的优先级函数优先级 P 影响用户数 × 严重度 × 复现置信度 × 可行动性 ÷ 预估修复成本这个公式不是为了制造精确幻觉而是强迫团队显式讨论取舍。低频安全违规的严重度极高不能被频率压低高频轻微语气问题若影响关键转化也可能优先于罕见幻觉。分数应附带证据区间和人工备注。失败模式优先级矩阵。横轴表示影响规模纵轴表示用户与业务损害气泡面积表示已确认的证据量红色虚线是默认干预阈值。左上角“低频高风险”模式由安全下限单独托底不能因为样本少而被排到高频低损问题之后。四第四关不是每个生产异常都适合变成 Eval适合转为 eval 的模式通常满足三点可重复期望行为清楚输入与评分可以脱敏并稳定执行。例如“纠正账户后仍使用旧账户”“工具失败却宣称成功”“特定安全意图未升级”都适合。不适合直接变成固定 eval 的问题包括高度依赖当时外部世界状态、主观偏好分歧巨大、只出现一次且证据不足、根因属于 UI 或运营流程。它们可以继续作为生产指标、用户研究样本或产品需求不必强行塞进回归套件。1. 任务级 Eval给 Agent 一个真实目标和受控环境验证最终状态是否正确。它比比较最终文本更接近真实工作。2. 轨迹级 Eval检查是否选对工具、是否正确 handoff、是否遵守顺序、是否避免循环与越权。评分器应关注可观察动作不要求暴露模型私有推理。3. 会话级 Eval模拟用户纠正、意图切换、情绪变化和中途恢复验证多轮状态管理与体验策略。此类 eval 必须控制模拟用户的偏差最好定期用真实会话人工校准。五第五关防止污染、过拟合与评分器漂移生产样本进入评测后要保留来源、时间、版本、分群与脱敏记录。近似去重不能只比较字符串因为同一失败可有多种说法。训练集、prompt 优化集、开发集和长期保留集必须隔离团队不得反复查看并针对保留集手工调参。LLM 评分器也会漂移。模型版本、提示词或标签定义变化都会改变分数。应维护一组人工标注锚点定期计算 grader 与人工判断的一致率对高风险判定采用规则、状态验证和人工复核组合而非单一 judge。六第六关用生产结果证明修复有效修复上线后至少比较三个窗口变更前基线、灰度窗口和稳定窗口。不要只看总体均值要检查受影响意图、用户分群、Agent 版本与工具的切片并观察是否把失败转移到其他环节。建议建立以下核心指标指标定义用途静默失败率 SFR经确认的静默失败会话 ÷ 可判定会话观察体验层真实失败面纠正循环率 CLR同一实体/目标出现两次以上纠正的会话占比监控记忆与恢复能力生产到评测转化率 C2E已确认模式中形成可运行 eval 的比例衡量知识固化效率修复后再现率 RAR已部署修复对应模式再次出现的比例判断修复是否真正闭环发现时延 MTTD-S模式开始出现到被确认的中位时间衡量未知失败发现速度委托深度变化 DSD同一用户高价值/高权限任务占比的趋势作为信任变化的代理信号从发现到生产结果的五段指标链。每张卡片给出该阶段的指标定义中间菱形是证据交接门。红色区域列出“报警多、eval 多、PR 多”造成的局部优化陷阱绿色区域把任务完成率、返工率、受挫率和留存作为闭环终点。六、Agnost AI 的产品判断价值、边界与竞争位置一公开信息能够确认什么1. 机制描述具体公开文档给出了 conversations、events、tool calls、intents、violations、alerts 和 improvements 的对象关系也说明了 OTel 与多框架接入、证据回链、阈值告警和改进追踪。它不是只有一句“用 AI 提升 AI”的概念页。2. 商业方案已经公开截至核查日官网列出 Free每月 1,000 events、7 天保留、Starter 49 美元/月10,000 events、30 天保留、Pro 499 美元/月1,000,000 events、90 天保留与定制企业版企业版页面列出自托管 VPC、审计日志、自定义 SLA/SLO 和改进流程。价格、额度和功能可能变化采购时应以合同与当日页面为准。3. 产品仍处早期阶段Product Hunt 页面显示其于 2026 年上线YC 页面将其列为 Summer 2026 公司。官网 FAQ 也直言团队处于早期阶段、创始人会参与客户改进。早期意味着反馈快和路线灵活也意味着规模、稳定性、合规证明和长期可用性仍需单独验证。二哪些主张仍需要验证1. 聚类准确性与误报成本“自动发现”是否有价值取决于候选模式的纯度、召回率和解释性。采购试点应使用团队已人工标注的一段历史流量测量已知高影响问题能否被召回一个聚类是否混入多个根因低价值主题是否淹没关键问题审阅每个模式要花多少时间。2. Eval 生成的可执行程度真正的 eval 需要环境、输入、期望状态、评分器与稳定运行方式。若产物只是自然语言建议价值更接近分析助手若能生成可进入既有框架的测试、保留证据与版本并在 CI 中稳定运行才形成工程闭环。公开材料对“从 insight 到 eval”的产品叙述明确但规模化的跨框架验证仍应由试点确认。3. 自动修复的根因质量Auto Improve 可以准备变更并关联 PR但生成代码并不等于找到根因。试点要观察建议修改落在哪一层prompt、工具 schema、路由、状态管理、UI 还是业务规则是否考虑副作用是否附带反例和回滚条件。最有价值的系统应能说清“为什么改这里”而不只是快速产出 diff。4. 商业效果数字YC 页面披露 Agnost 用某客户 780 条保留 production traces 评估专用模型相对厂商基线取得更高任务成功率、更低延迟与成本并明确这只是一个特定 workload。这个案例显示公司路线可能从分析与评测延伸到工作负载专用模型但数字来自公司自述不宜外推到一般 Agent也不应与静默失败发现能力混为一谈。三与同类平台的真实差异平台/方法强项与 Agnost 的重叠主要差异或采购关注点人工 eval 框架可控、确定、适合 CI 门禁都能沉淀回归用例人工框架依赖团队先知道问题Agnost 强调从生产会话提出候选LangSmithtracing、offline/online evaluation、datasets、LangChain 生态生产 trace 可进 dataset形成反馈循环平台更完整、生态更广Agnost 的默认叙事更聚焦用户会话、未知意图和静默失败Langfuse开源/自托管、tracing、prompt、online/offline evallive traces、datasets、实验与评分闭环Langfuse 更像通用 LLM 工程平台Agnost 更强调产品分析与自动发现体验问题Braintrust生产日志与实验统一、Topics 自动聚类意图/情绪/问题blind-spot、silent failure、需求主题与 targeted datasets 高度重叠Braintrust 已公开相似 Topics 能力说明 Agnost 的差异要靠工作流、证据质量、易用性与服务深度证明Arize Phoenix/AXtracing、evaluation、datasets、生产监控与告警在线评估、生产性能与反馈数据Phoenix 偏开放工程与模型可观测Agnost 偏会话产品信号部署和数据驻留取舍不同传统产品分析/情绪监控漏斗、留存、NPS、主题与情绪都能发现用户受挫和需求趋势通常缺少 Agent trace、工具结果和 eval/代码修复闭环结论是Agnost 抓住了真实痛点但它不是在一个无人区里。生产 trace 进入 dataset、online eval、主题聚类和会话分析已经成为主流平台的共同方向。Agnost 的护城河更可能来自三点对 Agent 静默失败的专用分类与优先级从会话到根因证据的低摩擦审阅体验从发现到修复、再到结果验证的默认闭环。四适合与不适合的团队1. 更适合已有稳定生产会话量Agent 涉及多轮、工具和外部状态团队每周能投入产品与工程人员审阅模式目前主要靠工单和人工抽查发现问题数据可以脱敏或采用受控部署并且已经有基本 eval希望补齐未知失败发现。2. 暂不适合产品仍无真实流量任务高度确定、传统测试已覆盖大部分风险团队没有 owner 处理发现对话含大量不可外发的受监管数据且尚无合适部署方案或者希望购买工具后完全自动修复、无需人工审查。没有运营机制再好的聚类也只会制造一个新的待办列表。七、90 天落地方案先证明发现价值再扩大自动化90 天落地路线与决策门。五个里程碑分别是边界设计、最小接入、基线标注、闭环试点和规模决策每个卡片同时标出交付物。第 30 天与第 90 天设置继续、调整或停止的决策门避免把接入完成误当成项目成功。一0—14 天定义边界与成功标准1. 选一个高价值窄场景不要一开始覆盖所有 Agent。选择一个会话量足够、结果可验证、修复 owner 明确的任务例如退款处理、销售资格判断、知识检索或代码修改。2. 建立数据清单列出每个字段的来源、用途、敏感级别、脱敏方式、保留期和访问角色。先用 staging 发送一条完整会话逐项检查 raw event。默认拒绝自由文本 metadata采用 allowlist。3. 固定评价基线从近期高价值用户中抽取 100—300 个完整会话由产品、工程和领域专家共同标注成功、显性失败、静默失败、不可判定同时记录失败类型、严重度和根因置信度。这组数据用于测工具不用于宣传。二15—30 天验证“发现”而不是验证“仪表盘好看”比较平台候选与人工基线测召回率、聚类纯度、误报审阅时间和高风险问题的发现时延。每个候选必须能回到具体会话、事件与工具调用没有证据回链的洞察不能进入修复队列。此阶段只开少量稳定告警。最危险的做法是把所有情绪波动都推到 Slack几天后团队便会静音整个频道。告警应包含时间窗、受影响意图/工具/规则、数量、对照基线、代表证据和明确行动人。三31—60 天完成三个闭环样本选择三个不同类型的问题一个工具/状态问题、一个多轮体验问题、一个隐藏需求或漂移问题。对每个问题完成证据确认、根因分析、eval、修复、灰度和结果复测。记录从发现到上线的总工时以及若无平台团队原本何时能发现。评测生成必须进入现有代码库和 CI而不是只停留在供应商仪表盘。测试应保留来源标签和版本敏感会话需转换为脱敏、合成或抽象后的可重复案例。四61—90 天决定扩大、并行还是停止用五个问题做 go/no-go是否发现了团队此前不知道的高价值问题是否显著缩短 MTTD-S生成 eval 是否稳定可运行修复后生产结果是否改善新增数据与审阅成本是否可接受。若只发现已知问题、误报很多或无法进入工程流程应缩小范围或停止而不是因为已经接入而继续投入。五组织机制质量闭环不能只属于 ML 团队建议设置每周 45 分钟的 Agent 质量评审由产品负责人主持工程、模型/数据、安全与客户支持参加。议程只处理四件事本周新增高影响模式上周模式的证据与根因已生成 eval 和修复状态上线后指标是否改善。把“主题浏览”变成带 owner、期限和验证标准的决策流程。RACI 可以简化为产品负责用户影响与优先级工程负责轨迹、根因与修复模型/数据负责 grader、聚类与漂移安全负责数据边界和高风险规则支持团队提供用户语境与人工升级证据。平台负责加速证据流动不替代这些责任。八、进一步推演Agent 质量系统会变成什么一Eval 将从静态题库变成有版本的知识资产未来高质量 eval 不只是一个 JSONL 文件而是一条有谱系的质量知识来自哪个生产模式、由谁确认、覆盖哪些用户、对应哪个版本、评分器如何校准、修复后是否下降、何时应退役。生产流量提供问题评测把问题固化为组织记忆。题库也需要生命周期。某些 eval 是永久业务契约某些只用于防止短期回归某些在产品重构后应下线。若所有发现都永久加入 CI套件会越来越慢、重复且互相冲突。团队需要对 eval 去重、分层、采样和归档。二会话将成为产品需求、质量与训练的共同数据面同一批生产会话可以支持三种任务发现失败与需求生成评测和回归在满足授权、去重和隔离的前提下构造训练或优化数据。YC 页面显示 Agnost 已把路线延伸到用历史生产轨迹训练特定工作负载模型。这种递归很有吸引力日志变成 eval再变成训练数据再由生产结果校正。风险也同样明显。如果发现、训练和评测共用近似样本系统会产生数据泄漏如果只学习现有流量会强化当前用户群偏见忽略未被服务的人如果错误的自动标签进入训练会把静默失败固化。数据谱系、隔离集和人工校准会成为核心基础设施。三“用户成功”会取代“回答质量”成为顶层指标生成式产品早期容易以答案分数为中心因为它最容易测。Agent 能执行工具、修改状态、跨多轮协作后顶层指标必须转向任务结果与信任工作完成了吗结果可验证吗用户需要多少监督系统能否从错误中恢复用户是否愿意把下一项更重要的任务交给它。这会改变团队分工。产品分析不再只看点击与留存平台工程不再只看延迟与错误eval 团队不再只维护离线数据集。三者需要共享一条从意图、轨迹、会话到结果的证据链。四自动发现不会消灭人工判断反而提高其杠杆自动化最适合做海量阅读、相似性压缩、趋势监测和候选生成人最适合判断业务语境、严重度、根因、价值冲突和不可逆风险。理想状态不是“无人值守自我修复”而是让少量高质量人工判断作用于更大流量。Agnost 自己的文档也把 violation 定义为分类发现而非执行把自动改进视为需要正常代码审查、测试和部署流程的工程贡献。这种克制比“Agent 自动修好自己”的叙事更可信。五最终判断Agnost AI 抓住的不是一个边缘功能而是 Agent 走向生产后必然出现的质量缺口离线 eval 主要保护已知世界真实用户不断创造未知世界。它最有价值的地方不是又多给一个“质量分数”而是让一段被忽略的生产对话有机会变成可确认的失败模式、可运行的 eval、可审查的修复和可验证的结果。但这并不意味着购买一个平台就获得自我改进系统。真正的闭环依赖稳定遥测、数据治理、人工校准、跨团队 owner、独立保留集和业务结果回写。Agnost 处于一个竞争迅速加剧的赛道LangSmith、Langfuse、Braintrust、Arize 等都在连接生产 traces、online evaluation、datasets 与改进流程。选择工具时最该验证的不是功能清单而是它能否在你的真实流量、真实数据边界和真实工程流程里持续把未知失败变成更少的用户伤害。对已经拥有生产 Agent 的团队一个务实结论是不要停止写 eval也不要再把 eval 当成全部质量系统。保留发布前的确定性门禁同时建立生产会话发现面、轨迹证据链和结果验证层。下一代评测的核心不是让题库更大而是让题库学会从现实中生长。可参考文章与资料Agnost AI 官网产品能力、价格与数据边界说明Product HuntAgnost AI 产品页面Agnost AI 文档Understand your AI agents in productionAgnost AI 文档ConversationsAgnost AI 文档IntentsAgnost AI 文档ViolationsAgnost AI 文档ImprovementsAgnost AI 文档AlertsAgnost AI 文档Data GovernanceAgnost AI 文档Security TrustAgnost AIThe 12 Production Agent Failures Your Evals Will Never CatchY CombinatorAgnost AI 公司页面与厂商案例口径OpenAIEvaluation best practicesOpenAIEvaluate agent workflowsOpenAITrace gradingAnthropicDemystifying evals for AI agentsOpenTelemetryGenAI ObservabilityLangSmithEvaluationLangfuseEvaluation OverviewBraintrustObserve your application 与 TopicsArize PhoenixUser Guide