从双螺旋困境到评估驱动：AI Agent 的质量可观测性

三类评分器#

Agent 评估用三类 grader：

Code-based grader——确定性检查。测试通不通过、类型对不对、状态变没变。快、便宜、客观，但刚性强，对「正确但出人意料」的解法不友好。

Model-based grader——用 LLM 来评判。基于 rubric 打分、自然语言断言、对比评估。灵活，能处理开放性任务，但不确定性高，需要定期和人工校准。

Human grader——专家评审。金标准，但慢、贵、难规模化。

文章的建议是：能用确定性检查的尽量用，必须用模型评判的再用，人工做校准和兜底。

这个分层让我想起了上篇文章里提到的 Descript 的做法——Don’t break things → Do what I asked → Do it well。本质上是同一个思路：先用成本最低的方法排除确定性问题，再用成本更高的方法处理需要判断的问题。

两种评估节奏#

Anthropic 区分了两种 eval：

Capability eval（能力评估）：问「这个 Agent 能做到什么？」，通过率应该从低开始，给团队一座要爬的山。

Regression eval（回归评估）：问「这个 Agent 还能做到之前能做的吗？」，通过率应该接近 100%，下降就是警报。

随着 Agent 成熟，能力评估中通过率足够高的任务会「毕业」，进入回归套件。曾经用来衡量「能不能做到」的测试，变成了衡量「还能不能稳定做到」的测试。

这个动态迁移的设计很精巧。它解决了一个实际问题：评估套件如果不演化，要么太难看不到进步，要么太简单失去信号。

非确定性的处理#

Agent 的行为每次都有变化，同一个任务跑十次可能五次过五次不过。Anthropic 引入了两个指标：

pass@k——k 次尝试中至少一次成功的概率。k 越大，分数越高——多给几次机会总有一次能行。适合「只要能找到一个方案就够」的场景。

pass^k——k 次尝试全部成功的概率。k 越大，分数越低——要求每次都靠谱是更高的标准。适合面向用户的场景，因为用户不会在意你十次里有九次成功，他们只会记住那一次失败。

这两个指标在 k=1 时完全相同，但随着 k 增大，它们讲述完全相反的故事。一个趋近 100%，一个趋近 0%。选哪个，取决于你的产品对「偶尔失败」的容忍度。

从零到一的路线图#

文章给了八步：

1. 尽早开始——20-50 个从真实失败中提取的任务就够起步
2. 从手动测试转化——你已经在手动做的检查，就是第一批 eval
3. 写无歧义的任务——两个专家独立看，应该给出相同的 pass/fail 判断
4. 构建平衡的测试集——不只测「该触发的场景」，也测「不该触发的场景」
5. 搭稳定的 eval harness——每次试验从干净环境启动，不让共享状态引入噪音
6. 设计 grader 要克制——评判结果而不是路径，允许 Agent 用你没想到的方式解题
7. 读 transcript——不读执行记录，你永远不知道 grader 判对了还是判错了
8. 持续维护 eval suite——eval 是活的，需要有人持续贡献任务和淘汰过时的测试

这八步里，第六步让我停了一下。

“There is a common instinct to check that agents followed very specific steps like a sequence of tool calls in the right order. We’ve found this approach too rigid… it’s often better to grade what the agent produced, not the path it took.”

评判产出，而不是路径。 这句话看起来简单，但做起来需要克制——因为当 Agent 出了问题，人的直觉反应是「它应该先做 A 再做 B 再做 C」，然后就会把这个路径硬编码进 eval。结果是惩罚了所有走不同路径但同样正确的解法。

Anthropic 自己也踩过这个坑。Opus 4.5 在 CORE-Bench 上一开始只拿了 42%³，后来发现是 eval 本身有问题——grading 太刚性、任务有歧义、随机性任务无法精确复现。修复 eval 之后，分数跳到了 95%。0% pass@100 通常说明是 eval 坏了，不是 Agent 不行。

从 monitoring 到 observability#

云原生领域在过去几年经历了一次重要的认知升级：从 monitoring（监控）到 observability（可观测性）。

监控是预设的。你提前定义好指标（CPU、内存、延迟）、设好阈值（>90% 告警）、等着看红灯亮不亮。它假设你已经知道可能出什么问题，然后针对性地监测。

可观测性不一样。它的理念是：系统应该自身产出足够丰富的信号——traces、logs、metrics——使得任何问题都能事后回溯，包括你事先没有预料到的问题。你不需要提前知道会出什么错，只需要确保当错误发生时，有足够的数据来还原现场。

这两者的核心区别不是技术手段，而是认知模型。监控假设问题空间是已知的、可穷举的；可观测性假设问题空间是未知的、持续变化的。

回看双螺旋困境：功能迭代在不断扩大效果的问题空间。每加一个功能，就多一类可能出现的效果问题。在这种环境下，传统的「预设指标 + 阈值告警」式的质量监控显然不够用——你不可能提前穷举所有效果可能退化的方式。

这正是 Anthropic 的 Eval 体系在做的事情：不是预设「Agent 必须通过这些测试」，而是构建一套基础设施，让质量的变化被系统性地照亮——无论这些变化是你预料到的还是意料之外的。

Eval 体系 = 质量可观测性#

把 Anthropic 的 Eval 框架和可观测性的三大支柱做个映射：

Transcript = Distributed Trace。 一次 Agent 执行的完整记录——每一步推理、每一次工具调用、每一个中间结果。和分布式系统里的 trace 一样，它让你能够还原一次请求的完整路径，而不是只看到最终输出。当 Agent 的最终结果「不太对」的时候，你不需要猜是哪一步出了问题——打开 transcript 看就行。

Grader = Metric + Alert。 自动化的质量度量。Code-based grader 像是系统指标（确定性、客观、低成本），Model-based grader 像是业务指标（需要理解语义、带主观判断），Human grader 像是人工巡检（高成本但高质量的兜底）。它们共同构成了一个多层次的质量度量体系。

Eval Harness = Observability Platform。 提供一个稳定的、可复现的运行环境，把 Agent 放进去跑，收集所有信号，聚合结果。每次试验从干净环境启动，确保观测到的是 Agent 本身的行为，不是环境噪音。

Eval Suite = SLO（Service Level Objective）。 定义「什么叫好」的操作性标准。SLO 说「99.9% 的请求延迟 < 200ms」，Eval Suite 说「这 50 个核心任务的通过率 > 95%」。两者做的是同一件事：把模糊的质量期望变成可衡量、可追踪的数字。

这个映射不是为了概念上的优雅。它指向一个实际的转变：质量保障的方式，正在从「出了问题去追查」变成「让质量的变化在系统内部持续可见」。

回扣双螺旋#

用可观测性的框架重新审视双螺旋困境，几个核心问题的出路变得更清晰了。

归因困难？ 有了 transcript，归因从「猜」变成「查」。从前要猜「是功能链路断了还是提示词的问题」，现在打开执行记录，看到底是哪一步输出了异常。分层 grader 进一步降低了归因成本——code-based grader 先排除确定性的功能问题，通过了之后再用 model-based grader 评估效果质量。这就是 Descript 三层模型的工程化实现。

功能迭代在制造效果问题？ Regression eval suite 就是自动化的早期预警。每次 Agentic 核心有变更，自动跑一遍基线测试。如果核心场景的通过率下降，在效果团队手动发现问题之前，信号就已经出来了。功能团队可以自己看到「这次改动影响了这些效果指标」，而不是等效果团队撞到 bug 再反馈。信息对称问题解决了。

效果工作的价值不可见？ Eval 指标就是效果团队最直接的产出物。「这组场景的通过率从 72% 提升到 89%」——这比「写作风格更自然了」要可沟通得多。效果优化有了可量化、可追踪、可展示的结果，它在组织里的可见度自然就不一样了。

效果优化需要稳定环境？ Eval harness 天然提供隔离。每次试验从干净环境启动，不受其他变更的干扰。效果团队可以在 eval 环境里做深度调优，不需要等「底盘不动」的窗口——因为 eval 环境本身就是一个底盘不动的沙箱。

效果评估标准本身是模糊的#

代码 Agent 有天然优势——测试通不通过是二值判断。但对于写作 Agent、客服 Agent、研究 Agent 这类输出开放性强的系统，「做得好」的标准本身就是模糊的。

「风格自然」怎么定义成 grader？「回答全面」的边界在哪里？「语气恰当」用什么 rubric 来评分？

Anthropic 也承认 LLM-as-judge 需要频繁和人工校准。他们的建议是：给 LLM 留退路（可以回答「无法判断」），用结构化 rubric 拆分评估维度，每个维度独立打分而不是一个 LLM 评所有方面。这些做法降低了噪音，但没有消除根本问题——在「好」和「不够好」的边界上，不同人的判断也不一样。

Descript 的做法是定期用人工评分校准 LLM 评分器，随着时间推移逐步减少人工介入的频率。这可能是当前最务实的路径：不追求一开始就完美，接受评估标准会随着理解加深而演化。

Eval 的维护本身就是一笔投入#

Anthropic 在文章里说 eval suite 是 “living artifact”，需要持续维护和有人负责。对 Anthropic 这种体量的公司，这不是问题。但对大多数团队来说，维护一套不断演化的评估体系本身就是一个需要人力的工程项目。

eval task 会过时——产品变了，旧任务不再有意义。grader 会漂移——你依赖的 LLM 自己也在更新，评分标准可能在你不知道的情况下悄悄变了。eval suite 会膨胀——加任务容易删任务难，时间长了跑一遍 eval 可能要好几个小时。

这不是说不值得做，而是说做的时候要对成本有清醒的认知。Anthropic 的路线图第一步——「20-50 个从真实失败中提取的任务就够起步」——之所以重要，不只是因为降低了门槛，更因为它明确了一个信息：先跑起来比追求完备更重要。

覆盖率的幻觉#

eval 通过了不代表没问题。Opus 4.5 在 CORE-Bench 上从 42% 跳到 95% 的例子，说明的不是模型进步了，而是 eval 之前就有问题。

反过来，eval 没通过也不代表一定有问题。Agent 可能用了一种 eval 设计者没有预料到的方式解决了问题，但被过于刚性的 grader 判了失败。Anthropic 文章里提到的 τ2-bench⁴ 案例就是如此——Opus 4.5 在订机票任务中发现了政策漏洞，给了用户一个更好的解法，但因为不符合 eval 的预期路径而「失败」了。

这意味着 eval 分数不能无脑地当作质量信号。它是一个有用的指示器，但不是真理。文章里反复强调的「读 transcript」——手动检查执行记录——本质上是在弥补自动化评估的盲区。再好的 eval 体系，也替代不了人对样本的直接观察。

模型漂移让基线不稳#

这可能是最棘手的问题。你的 grader 依赖 LLM（model-based grading），但 LLM 本身也在变——大模型厂商在持续更新模型，每次更新都可能微妙地改变评分标准。上个月 LLM 评 85 分的输出，这个月可能评 80 或 90，不是因为输出变了，而是评委变了。

这和我在双螺旋那篇文章里描述的「底层变了，上层不可预测」是同一个结构。只不过这次不稳的不是 Agentic 核心，而是评估系统自身的基线。

应对方式大概是：code-based grader 尽量承担更多比例（它不漂移）、model-based grader 定期和人工校准、保留一组 golden dataset 作为评估的锚点。但坦率地说，这个问题目前没有优雅的解法。