上线看什么指标
Demo 通过不是上线依据：关键任务至少要报成功率、首次完成率、All-pass@k、质量下限和单位成功成本，并看 P85 而不只是中位数。
Demo 通过不是上线依据。关键任务至少要报告任务成功率、首次完成率、All-pass@k、质量下限和单位成功成本，而且要看 P85 而不只是中位数。五次跑通一次，和五次跑通五次，在 Demo 里长得一模一样，在生产里是两个系统。
Demo 通过不是上线依据
Anthropic 那次事故是最好的反例。三起彼此独立的变更——默认 reasoning effort 从 high 降到 medium、一个缓存清理 bug、一段 verbosity prompt——各自影响不同的流量切片、按不同的时间表生效，聚合起来像一场「广泛不一致的退化」。三月初开始调查时，很难从正常的用户反馈波动里把它区分出来；内部使用和 eval 都没能复现 anthropic-postmortem。
结论是：组件正确性之和不等于系统正确性。这也是上线指标存在的唯一理由——你得能在真实流量分布上反复追问同一件事：这次成了没有。
另一个方向的例子：HN 工程师深挖 Cursor「一周自主建成浏览器」的声明，发现大量代码近乎逐字复制 Servo/stylo（quirks_mode() 一字不差），而 ACID3 截图要求「启用 JavaScript」，意味着那个 JS VM 可能根本没跑起来。社区共识落在 Roark66 那句总结上——成功之路是人机混合 hn-cursor-browser。
判据很清楚：单次成功说明能力存在，不说明能力稳定。
六个指标要一起看
| 指标 | 定义 | 单独看会怎么骗你 |
|---|---|---|
| Task Success Rate | 成功 Trial 数 / 总 Trial 数 | 不区分重试和接管，把成本藏进成功率 |
| First-pass Completion Rate | 无重试、无人工接管即完成的比例 | 低了说明规划不稳，但常被整体成功率盖住 |
| All-pass@k | 同一任务连续 k 次全部成功的任务比例 | 缺了它，你看不出哪些任务只是碰运气 |
| Quality Floor | 任务得分的 P10 或置信下界 | 只看均值，最差的那批用户体验被平均掉 |
| Human Takeover Rate | 需要人工接管的运行比例 | 不报它，等于把人力成本从账单里划掉 |
| Cost per Successful Task | 全部运行成本 ÷ 成功任务数 | 只看单次均价，失败重试的开销就消失了 |
必须区分三种「完成」：首次完成、重试后完成、人工接管后完成。三者成本差一个数量级，混在一起报，就是把人工成本记进成功率。关键任务至少报告前四项，并同时观察质量和单位成功成本——不能单独以最低 token 为目标。另外，表里的 All-pass@k 与先定义完成，再写第一行代码 里的 Pass^k 是同一个口径的两种写法：k 次里错一次就不算通过，别把它当成两个指标分别统计。
分布、下限与诚实差
同时报告平均表现、质量下限和波动，不能只看单次成功或单一 LLM Judge 分数。
长尾才是摩擦的藏身处。某团队交付周期中位数从 19 天降到 9 天，P85 却顽固停在 52 天。只看中位数，你会以为提速一倍；看 P85 才知道组织摩擦一点没动。所以看 P85，不只中位数。
还有一条容易被跳过：诚实差。自报结果与独立验证结果必须比较并记录。Agent 声称完成，不等于环境状态改变——要严格区分 Outcome（环境最终状态，比如数据库里到底有没有那条预订记录）和 Transcript（完整执行记录）。判完成只认 Outcome。
冒烟失败要分四类
冒烟失败不分类，你会在错误的地方使劲，系统越改越乱：
- CAPABILITY_FAILURE——修 Agent、Tool、知识或规则；
- INFRA_FAILURE——修环境后重跑，不要碰 prompt；
- TEST_DEFECT——修 fixture 或 grader，不是修 agent；
- NON_DETERMINISTIC——增加 trial 次数，用分布说话。
前提是固定测试数据、环境依赖和版本信息，否则你分不出第二类和第四类。
证据化置信度
置信度必须由可验证信号组合出来：证据覆盖、schema 合法、确定性检查通过、工具执行成功、校准分数。不能用模型自评的置信度决定上线或执行副作用，也不能用表达流畅度代替正确性——流畅最容易伪造，也最容易骗过评审。
检查优先级要写死：Schema / 类型 / 静态分析 / 确定性业务校验 → 环境执行 / 测试 / 状态验证 → 独立模型 Grader → 人工审核。确定性检查能覆盖的，不要交给 Grader。按风险定义自动交付、人工审核和停止的阈值，别让「看起来挺好」成为放行条件。
换模型换的不只是成功率
上线之后最常见的一个决策是换模型：新模型发布了，公开基准更高、定价更低。真正要回答的不是「它是否更强」，而是「在我的特定任务上好多少、切换成本是什么」ai-agent-book。
只有评估体系能回答这个问题。有它，你可以在几小时内跑完自己的数据集，对比成功率、工具调用正确率、延迟和成本；没有它，你只能等线上反馈，而线上反馈只会告诉你出事了，不会告诉你本来可以怎样。结论也常常不是全量切换，而是差异化：简单任务迁到新模型以降低成本，复杂多轮编排场景成功率反而下降，就留在原模型。前提还是那一条——分差要先超出噪声带宽（见让验证速度追上生成速度），否则你是在跟着随机波动改架构。
还有一层不在任何分数里：模型默认会怎样做。同一个代码任务，有的模型先广泛探索仓库再动手，有的凭少量局部证据快速定位、先改再用测试反馈补齐认识——前者把过早修改的风险估得更高，后者把「再多读一个文件」的机会成本估得更高。换模型时成功率持平不代表行为持平：探索宽度、diff 规模、重试次数都会跟着动，而这三项正是成本和稳定性的来源 ai-agent-book。
行业现实
McKinsey 2025 年 11 月的 State of AI 调研显示：62% 的受访者在实验 Agent，但任何业务职能中规模化的不超过 10%。Gartner 预测到 2027 年底超过 40% 的 Agentic AI 项目会被取消，原因是成本攀升、业务价值不清、风险控制不足 langchain-what-is-agent。
中间隔着的是一整套基础设施：可观测、Eval 与数据集、沙箱、访问控制。团队最常犯的错是低估这一层的投入，把「能跑通」当成「能上线」。
取舍要说清楚：这些指标要跑多次 trial、要保留 trace、要固定环境，成本不低，对一次性内部脚本完全不划算。检查方法是挑一个关键任务跑十次，写出五个数——成功率、首次完成率、All-pass@3、P10 得分、单位成功成本。任一项写不出来，说明观测没建好，不是任务太难。