逐日AI
English
第 1 周 · D1约 4 小时

为什么 Agent 不能靠「试几次感觉还行」

先说清楚 Agent 比单轮对话多出的三个评估难点，再建立全课通用的五个术语与评估分层，最后用一次跑五遍的实验把非确定性变成两个能写进报告的数字：至少成一次的概率，和五次全成的概率。

今日目标 0/3

登录后可以勾选并保存进度。

今日目标

  1. 能说出 Agent 评估区别于单轮问答评估的三个难点，并各举一个会让人误判系统质量的具体表现
  2. 能用任务、试次、评分器、轨迹、结果态五个词准确描述一次评估，并说清结果态为什么不是聊天记录里的一句话
  3. 能解释 pass 的 at k 与 pass 的 k 次方分别回答什么问题，并算出单次成功率 75 百分号的 Agent 连成三次的概率

小白版讲解

体检报告与「我感觉挺好」

一个人说自己身体挺好，这是一句主观判断。它可能是对的，但你没法拿它去和三个月前比较，也没法拿它去问医生下一步该做什么。

体检报告不一样。它是一组数字，有单位，有参考区间，能和上一次的报告并排放在一起看。体检报告的价值不在于它比人的感觉更准，而在于它可复现、可比较、可以交给别人看。

上线一个 Agent 之前，绝大多数团队做的事情是这样的：打开对话框，试七八个自己想得到的问题，觉得回答得不错，发布。这就是「我感觉挺好」。

它有两个致命问题。第一，你试的那七八个问题是你想得到的，而线上会出现的是你想不到的。第二，也是更隐蔽的那个——你试的那七八次，恰好都成功了，不代表它们的成功率是百分之百。

这门课要做的事，就是把「我感觉挺好」变成一份体检报告。

Agent 难评的三件事

如果你评的是一个单轮问答系统，事情其实没那么难：给一个问题，拿到一个回答，和标准答案比一比。Agent 把这件事变难了，难在三个地方。

第一，同样的输入不一定给出同样的结果。 大模型本身就是概率性的，Agent 在此之上又叠了一层：它自己决定调哪个工具、调几次、什么时候停。同一句话问两遍，它可能第一次查了订单再退款，第二次直接退款。这意味着「跑一次通过了」这个事实，信息量比你以为的小得多。

第二，中间步骤会改变外部世界。 单轮问答错了就是一句错话，Agent 错了可能是一笔真的退款、一封真的发出去的邮件。这带来一个直接后果：评估不能只看它最后说了什么，必须看它做了什么。

第三，一次运行要花真钱。 一个跑二十步的 Agent，一次运行可能花掉几分钱和十几秒。要跑一百条任务、每条重复五次，就是五百次运行。这个成本会直接决定你的评估能做到多勤、多大，以及哪些任务只能在发版前跑。

五个术语，先立规矩

后面六天会反复用到五个词。现在把它们钉死，避免到了第五天大家说的还不是同一件事。

词含义最容易搞混的地方
任务一个测试用例：一段输入，加上成功的判据它是纯数据，能存成 JSON，能进 git
试次对同一个任务的一次运行一个任务要跑多次，每次叫一个试次
评分器判定一次试次成不成功的逻辑一个任务可以挂多个评分器
轨迹一次试次的完整过程记录：说了什么、调了哪些工具、花了多少和 D5 的链路不是一回事，见下面的警告
结果态试次跑完之后，环境的最终状态不是聊天记录里的一句话

结果态为什么不是模型说的话

这是今天最重要的一条，值得单独拎出来。

假设你在评一个客服退款 Agent。它的回复是：

TextText
已为订单 A1001 办理退款，金额 49.90 元，预计 3 个工作日到账。

这句话读起来完美。问题是：退款到底退了没有？

模型完全可能在没有调用退款工具的情况下把这句话说出来。它读过几百万条客服对话，知道这时候该说什么。而你的评估如果是拿这句话去和标准答案做文本比对，它会判通过。

正确的判法是去查环境：退款记录表里有没有这一条，订单号对不对，金额对不对。这就是结果态。

评估分成三层

不是所有故障都在同一个层面暴露，所以评估也要分层。

层看什么抓什么故障成本
单步一次模型调用或一次工具调用参数拼错、schema 不对、解析失败最低
轨迹整个过程：调了哪些工具、什么顺序、几步绕路、死循环、调了不该调的工具中
端到端只看最终结果态任务到底有没有完成最高

很多团队只做端到端，因为它最直观。代价是每次失败你都只知道「没成」，不知道断在哪一环。后面六天会把三层都补上，今天先把端到端这层做扎实。

把非确定性变成两个数字

现在回到开头那个隐蔽的问题：试了几次都成功，能说明什么？

答案是：取决于你试了几次，以及你打算怎么用这个 Agent。

有两个指标回答两个不同的问题。

pass@k：跑 k 次，至少成功一次的概率。

pass^k：跑 k 次，每一次都成功的概率。如果单次成功率是 p，那么这个值就是 p 的 k 次方。

这两个数字的差距会大到让人不舒服。看一个具体的：

一个单次成功率 75% 的 Agent，连续三次都成功的概率是多少？

TextText
0.75 × 0.75 × 0.75 = 0.421875 ≈ 42%

一个「四次里能成三次」的 Agent，在需要连续三次都对的场景里，一半以上的时间是坏的。 而如果你只报 pass@3，你会得到 98.4% 这个非常好看的数字。

那该用哪个？看你的 Agent 后面有没有人兜底。

场景用哪个为什么
生成代码草稿，人会 reviewpass@k十个候选里有一个能用就行
生成配图候选，人来挑pass@k同上
客服自动退款pass^k没有人看，错一次就是一笔真钱
自动执行运维命令pass^k错一次就是一次事故

能力评估与回归评估，不要混在一起

还有一组概念今天要先分清，它决定了你的评估套件长什么样。

能力评估回答「这个 Agent 能做到什么」。它应该从低通过率起步——如果一套新的能力评估一上来就 95% 通过，说明题目出得太简单，它没法告诉你下一步该往哪走。

回归评估回答「它还能做到它以前做得到的事吗」。它应该长期贴近 100%——一旦掉下来，就是出问题了。

把这两类混在一个套件里，是最常见的初学者错误。混在一起之后，总分变成了一个既不能指方向、也不能报警的数字：它掉了两个点，你不知道是新能力没做上去（正常），还是老功能坏了（严重）。

查它产生了什么，不要查它走了哪几步

最后一条原则，它会在 D4 被再讨论一次，但今天要先建立。

一个很自然的想法是：我知道正确的做法是「先查订单、再查政策、最后退款」，那我就在评分器里规定这三步的顺序。

这个做法的问题是，Agent 常常会找到你没想到的有效解法。比如它发现某类订单可以直接从缓存里读到政策结论，省掉一次工具调用。结果更快更省，但你的评分器判它失败——因为它没按你规定的顺序走。

正确的做法是查结果：退款对不对、金额对不对、不该退的有没有退。过程只在它真的构成问题时才去查（花了十倍的钱、陷入死循环、碰了不该碰的工具），那是 D4 的内容。

源码导读

今天的两份材料都值得完整读一遍，它们是这门课后面六天的骨架来源。

Anthropic 工程博客的评估方法文章，是目前公开材料里把 Agent 评估讲得最系统的一篇。今天用到了它的三处：task / trial / grader / transcript / outcome 这套术语、评过程还是评结果的取舍、以及能力评估与回归评估的区分。它后面还有一段关于「评估任务本身可能是坏的」的讨论，那是 D7 的主要内容，今天可以先跳过。

τ-bench 论文引入了 pass^k。这篇论文的场景设定值得看：它做的是客服 Agent，有工具、有模拟用户、有必须遵守的业务政策。这三件事和我们今天的靶子高度相似，所以它的指标设计可以直接借鉴。论文里那张 pass@k 与 pass^k 随 k 分叉的图，是理解这两个指标最快的方式。

读的时候注意一件事：这个领域的基准会漂移。 τ-bench 原来的榜单已经冻结在早期的模型集上，新模型评的是它的后继版本，而后继版本在一次小版本更新里改过判分规则，改之前和改之后的分数不能直接比。这不是个别现象，D7 会专门讲怎么应对。

动手实验

🧪 D1：第一个评估器

代码位置：labs/agent-evals-7days/day-01-first-eval

今天要建的是 evalkit 的地基：类型层、试次执行器、靶子 Agent，以及两个概率指标。

靶子是一个客服退款 Agent，带四个工具，故意埋了四类可复现的缺陷。接下来六天你要做的，就是用评估把这四类缺陷一个个抓出来。今天先抓最容易看见的那一类。

执行器里有一条纪律必须先说：每个试次都从干净环境起步。

runner.js
// 每个试次都重建一份全新的世界，绝不在试次之间共享
export function buildWorld(task) {
  const orders = {}
  for (const o of task.seed.orders) {
    orders[o.id] = { ...o }
  }
  return { orders, refunds: [], escalations: [] }
}
 
export async function runTask(task, target, k) {
  const passed = []
  for (let i = 0; i < k; i += 1) {
    // buildWorld 在 runTrial 内部，所以每一次都是干净的
    const { grades } = await runTrial(task, target, i)
    passed.push(grades.length > 0 && grades.every((g) => g.passed))
  }
  return {
    passed,
    passAtK: passed.some(Boolean),
    passHatK: passed.every(Boolean),
  }
}

如果把 buildWorld 挪到循环外面，会发生两件事，而且都不会报错：前一次的退款记录留在世界里，让后一次「看起来」成功了；或者前一次把订单改成已退款，导致后面几次全挂。两种都会让你去修一个根本不存在的 bug。

做完练习跑一下，你会看到这样的输出：

TextText
ev-001-fresh-order  [positive]
  5 次结果：✓ ✓ ✓ ✓ ✓
 
ev-002-expired-order  [positive]
  5 次结果：✓ ✓ ✓ ✗ ✓
  失败样例：退款条数不符：期望 0 条，实际 1 条
 
ev-003-already-refunded  [negative]
  5 次结果：✓ ✓ ✓ ✓ ✓
 
—— 汇总 ——
pass@5  （至少成一次）：100.0%
pass^5 （5 次全成）：66.7%

pass@5 是 100%，pass^5 只有 66.7%。

如果你的评估报告只有上面那个数字，你会得出「这个 Agent 完美」的结论并且上线它。而实际情况是：三条任务里有一条，在五次运行里会翻一次车——那一次它给一笔 90 天前的订单退了款。

这就是今天这两个数字存在的全部意义。

面试题

今天的四道题围绕三个点：怎么向别人汇报一个非确定性系统的质量、为什么判据要落在结果态上、以及两个概率指标的选择依据。

第一道题几乎一定会在实际面试里出现，因为它是真实场景：你跑了五次，三次对两次错，现在要汇报。答「成功率 60%」只能拿一半分——真正要说的是这个数字的置信度、它对应哪个使用场景，以及你打算怎么把它变得可比较。

检查清单与明日预告

今天结束时，你应该能做到：

  • 说出 Agent 评估比单轮问答难在哪三件事，并各举一个具体表现
  • 用任务、试次、评分器、轨迹、结果态五个词描述一次完整的评估
  • 解释为什么评分器要查环境而不是读模型的回复
  • 算出单次成功率 75% 的 Agent 连成三次的概率，并说明什么场景下该看这个数
  • 让 MOCK=1 pnpm selftest 八项全绿
  • 看到 pass@5 与 pass^5 的真实差距，并能解释这个差距意味着什么

明天是 D2《基准集：把线上翻过的车变成可复现的任务》。今天的三条任务只是演示，真正的评估需要一批有代表性、能覆盖正反两面、而且本身经过验证的任务。明天会讲这批任务从哪来（答案是：从你已经翻过的车里来）、多少条才够开工，以及一个反直觉的判据——一条通过率为零的任务，多半是题目写错了，不是 Agent 不行。

面试题库

  • 同一个任务跑五次，三次对两次错。你会怎么向老板汇报这个 Agent 的质量？You run the same task five times and get three passes and two failures. How do you report this agent's quality to your manager?
    国内高频海外高频进阶#evaluation#metrics#non-determinism

    分析过程 · 先想清楚再作答

    1. 这题考的是「会不会把一个非确定性系统的表现讲清楚」，不是算术。张口就报「成功率 60%」的只能拿一半分——那个数字本身没错，但它既没有置信度，也没有说清适用场景。
    2. 第一步先把样本量的问题摆出来：五次里成三次，60% 这个点估计的波动范围很大。真实成功率是 40% 还是 80%，五次样本根本分不开。所以汇报时要说的是「目前只有五次样本，这个数字还不能用来做决策」，而不是直接把 60% 报上去。
    3. 第二步要区分两个问题：至少成一次的概率，和每次都成的概率。如果这个 Agent 后面有人 review，60% 的单次成功率意味着跑三次几乎一定能拿到一个可用结果；如果它是自动执行的，那么连成三次的概率只有 0.6 的三次方，约 21.6%，等于绝大多数时候是坏的。**同一个 60% 在两个场景下的结论完全相反。**
    4. 第三步给出下一步动作，而不是停在报数：把样本量加到足够判断的规模、把两次失败的轨迹读一遍做归因、并把这条任务固化进基准集，这样下次改动才有得比。
    5. 最后补一句可比较性：这个数字要带上模型版本、提示词版本、任务集版本和随机种子，否则下周再报一个数，没人知道是系统变了还是环境变了。
    6. 可预期的追问是「那你要跑多少次才够」。答案不是一个固定数字，而是取决于你要分辨多大的差异：想区分 60% 和 65% 需要的样本量，远大于区分 60% 和 90%。先说清楚要回答什么问题，再定样本量。

    How to reason about it · think before answering

    1. This tests whether you can characterize a non-deterministic system, not whether you can divide. Answering 'a 60% success rate' earns half credit at best: the number is arithmetically right but carries no confidence interval and no context.
    2. Start with sample size. Three out of five is a point estimate with a very wide spread; five trials cannot distinguish a true rate of 40% from one of 80%. The honest report is 'we only have five trials, this number is not yet decision-grade'.
    3. Then separate two different questions: the probability of succeeding at least once, and the probability of succeeding every time. With a human reviewing the output, a 60% per-run rate means three attempts will almost certainly yield something usable. If it runs unattended, three consecutive successes happen with probability 0.6 cubed, about 21.6% - broken most of the time. The same 60% supports opposite conclusions in the two settings.
    4. Give a next action rather than stopping at the number: raise the trial count to something decision-grade, read the transcripts of both failures and attribute them, and freeze this task into the benchmark set so the next change has a baseline.
    5. Close on comparability: the number must carry the model version, prompt version, task-set version, and random seed. Without those, next week's number cannot be compared with this one.
    6. Expected follow-up: how many trials are enough? There is no fixed answer - it depends on the difference you need to detect. Separating 60% from 65% needs far more trials than separating 60% from 90%. State the question first, then size the sample.

    答题要点

    • 先说样本量不足：五次样本无法把真实成功率定位到一个有用的区间。
    • 区分「至少成一次」与「每次都成」，并说明两者适用于不同场景。
    • 自动执行场景要算连续成功率：0.6 的三次方约 21.6%，结论与 60% 完全不同。
    • 给下一步动作：加样本、读失败轨迹做归因、把任务固化进基准集。
    • 报数必须带模型版本、提示词版本、任务集版本与随机种子，否则不可比。

    Key points

    • Lead with sample size: five trials cannot pin the true rate to a useful interval.
    • Distinguish 'at least once' from 'every time' and map each to a deployment scenario.
    • For unattended execution compute the consecutive rate: 0.6 cubed is about 21.6%, a very different conclusion.
    • Propose next actions: more trials, read both failure transcripts, freeze the task into the benchmark set.
    • Always report model, prompt, task-set version and random seed, or the number is not comparable.
  • 为什么评估 Agent 时要看环境的最终状态，而不是看它最后一条回复说了什么？Why should you evaluate an agent against the final state of the environment rather than what its last message says?
    国内高频海外高频基础#evaluation#graders#outcome

    分析过程 · 先想清楚再作答

    1. 这题看着简单，区分度在于能不能举出「回复正确但事情没做」的具体机制，而不是只说一句「模型会幻觉」。
    2. 机制是这样的：模型在训练里见过大量客服对话，它非常清楚在「用户要求退款」之后应该说什么。于是它可以在**完全没有调用退款工具**的情况下，流畅地说出「已为您办理退款，预计三个工作日到账」。这句话与真正退了款时说的那句，在文本层面可以一模一样。
    3. 所以基于文本比对的评分器在这里是失效的：它判不出这两种情况的区别。而查环境可以——退款记录表里有没有这一行，是一个二值的、确定的事实。
    4. 反过来说，这也是「能用代码判就别用模型判」这条原则的最佳例证：查一行数据库记录既快又便宜又客观，而让另一个模型去读回复判断真假，既贵又会引入新的不确定性。
    5. 还要补一个更严重的后果：文本评分器不只是判错，它是**系统性地偏向乐观**。一个学会了说漂亮话但不干活的 Agent，在文本评分下会拿高分。如果你再拿这个分数去做优化，就是在训练它更会说漂亮话。
    6. 可预期的追问是「那开放式的回答怎么办，比如一份研究报告」。答案是分层：能落到结果态的部分（引用的链接是否真实存在、要覆盖的要点是否都在）仍然用代码判，剩下真正主观的部分才交给模型裁判，那是 D3 的内容。

    How to reason about it · think before answering

    1. This looks easy; the discriminator is whether you can name the concrete mechanism by which a correct-sounding reply accompanies no action, rather than just saying 'models hallucinate'.
    2. The mechanism: the model has seen enormous amounts of customer-service dialogue and knows exactly what to say after a refund request. It can therefore produce 'your refund has been processed, expect it in three business days' without ever calling the refund tool. Textually that sentence is identical to the one it produces when the refund really happened.
    3. So a text-matching grader is blind here - it cannot separate the two cases. Checking the environment can: whether a row exists in the refunds table is a binary, settled fact.
    4. This is also the cleanest illustration of 'if code can judge it, do not ask a model'. Reading one database row is fast, cheap and objective; asking a second model to judge the reply's truthfulness is expensive and injects fresh uncertainty.
    5. Add the more serious consequence: a text grader is not merely wrong, it is systematically optimistic. An agent that learned to talk well without acting scores highly, and optimizing against that score trains it to talk even better.
    6. Expected follow-up: what about open-ended outputs such as a research report? Layer it - whatever can be reduced to state (do the cited links resolve, are the required points covered) stays with code, and only the genuinely subjective remainder goes to a model judge, which is Day 3.

    答题要点

    • 模型能在不调用工具的情况下说出与真正执行时一模一样的回复。
    • 文本比对判不出这两种情况，查环境可以——它是二值的确定事实。
    • 这是「能用代码判就别用模型判」的最佳例证：更快、更便宜、更客观。
    • 文本评分器会系统性偏向乐观，拿它做优化等于训练模型更会说漂亮话。
    • 开放式输出要分层：可落到状态的用代码判，剩余主观部分才交给模型裁判。

    Key points

    • A model can produce a reply identical to the successful case without calling any tool.
    • Text comparison cannot separate the two; checking state can, because it is a binary fact.
    • Best illustration of 'prefer code graders': faster, cheaper, and objective.
    • Text graders are systematically optimistic; optimizing against them rewards better-sounding lies.
    • For open-ended output, layer it: state-checkable parts to code, the subjective remainder to a model judge.
  • 什么场景该用 pass 的 at k，什么场景必须用 pass 的 k 次方？各举一个例子并说明代价。When should you report pass@k, and when must you report pass^k? Give an example of each and state the cost.
    国内高频海外高频进阶#evaluation#metrics#pass-at-k

    分析过程 · 先想清楚再作答

    1. 这题考的是「指标与产品形态的匹配」。只背定义拿不到分，要给出判据：**后面有没有人兜底。**
    2. 有人兜底的场景用 pass@k。典型例子是代码补全或生成图片候选：一次生成十个方案，人来挑一个，只要十个里有一个能用，这次交互就是成功的。这时候报 pass@1 会严重低估系统的实际价值。
    3. 没人兜底的场景必须用 pass 的 k 次方。典型例子是客服自动退款、自动执行运维命令：没有人逐条检查，错一次就是一笔真钱或一次事故。这时候你关心的不是「它能不能做对」，而是「它会不会有一次做错」。
    4. 代价要说清楚。pass@k 的代价是它会掩盖不稳定性：一个成功率 30% 的 Agent 在 pass@10 下能拿到 97%，看起来很好，但它意味着用户平均要试三次以上。pass 的 k 次方的代价是它非常严厉，k 稍微一大数字就塌下去，容易让团队觉得「怎么努力都没用」而放弃这个指标。
    5. 所以实践里两个一起报，并且明确标注 k 是多少。只报一个的评估报告都是不完整的，报的时候不写 k 更是没有意义——脱离 k 的 pass 的 k 次方不是一个数。
    6. 可预期的追问是「那 k 取多少」。答案是按真实使用形态取：用户平均会重试几次，就把 pass@k 的 k 设成几；业务要求连续多少次不出错，pass 的 k 次方就取几。不要随手取一个 10。

    How to reason about it · think before answering

    1. This tests whether you match metrics to product shape. Reciting definitions earns nothing; give the test: is there a human backstop?
    2. With a backstop, use pass@k. Code completion or generating image candidates: produce ten, a human picks one, and the interaction succeeds if any one of them works. Reporting pass@1 here badly understates the system's value.
    3. Without a backstop, pass^k is mandatory. Automated refunds or automated ops commands: nobody checks each one, and a single error is real money or a real incident. The question is not 'can it succeed' but 'will it ever fail'.
    4. State the costs. pass@k hides instability: a 30% agent scores 97% at pass@10, which looks great but means users retry three times on average. pass^k is harsh - it collapses as k grows, and teams may dismiss it as unachievable and stop tracking it.
    5. In practice report both, and always label k. A report with only one of them is incomplete, and pass^k without a stated k is not a number at all.
    6. Expected follow-up: how do you choose k? From real usage. Set k for pass@k to how many times users actually retry, and k for pass^k to how many consecutive runs the business requires to be clean. Do not default to 10.

    答题要点

    • 判据是后面有没有人兜底：有人 review 用 pass at k，无人值守用 pass 的 k 次方。
    • 有兜底例子：代码草稿、生成候选；无兜底例子：自动退款、自动运维。
    • pass at k 的代价是掩盖不稳定性：30% 的 Agent 在 k 等于 10 时能报到 97%。
    • pass 的 k 次方的代价是过于严厉，k 一大就塌，容易被团队放弃。
    • 两个一起报并标注 k；k 要按真实重试次数或业务连续性要求来取。

    Key points

    • The test is whether a human backstop exists: reviewed output takes pass@k, unattended execution requires pass^k.
    • Backstopped: code drafts, candidate generation. Unattended: automated refunds, automated ops.
    • pass@k hides instability - a 30% agent reports 97% at k equals 10.
    • pass^k is harsh and collapses as k grows, so teams tend to abandon it.
    • Report both with k labeled, and choose k from real retry behavior or the business continuity requirement.
  • 一个新写的评估任务，跑一百次通过率是零。你的第一反应是什么？A newly written evaluation task has a 0% pass rate over one hundred trials. What is your first reaction?
    国内高频海外高频进阶#evaluation#debugging#task-quality

    分析过程 · 先想清楚再作答

    1. 这题是个陷阱题，考的是「会不会怀疑自己的评估」。回答「说明 Agent 做不到这个任务，要去优化模型」的，方向就错了。
    2. 正确的第一反应是：**这条任务本身多半是坏的。** 一百次全零是个极端信号——即便是很难的任务，如果它确实可解，一百次里通常会蒙对至少一次。全零更像是一堵墙，而不是一个斜坡。
    3. 排查顺序应该是从评估侧往模型侧走。先看判分：是不是判据写错了，比如期望值拼错、浮点数做了严格相等比较、大小写或空格不一致。这类问题非常常见，一个字符串比对写死就能让一个完全正确的答案判失败。
    4. 再看任务描述：是不是有歧义，导致 Agent 理解成了另一件事；是不是依赖了环境里不存在的东西，比如引用了一个没有被 seed 进去的订单号。
    5. 然后看可复现性：任务里有没有随机成分，导致每次的正确答案都不一样，评分器却拿着一个固定答案在比。
    6. 最后才是「确实是 Agent 做不到」。而验证这一点的标准做法是写一个参考解——人工把这条任务正确地做一遍，喂给评分器，看它判不判通过。参考解都过不了，那 100% 是评估的问题。这个动作是 D2 的核心内容。
    7. 可预期的追问是「反过来呢，通过率一上来就是 100%」。那通常说明题目太简单或者判据太松，这条任务提供不了任何信息，同样需要修。

    How to reason about it · think before answering

    1. This is a trap question about whether you will suspect your own evaluation. Answering 'the agent cannot do it, go optimize the model' starts in the wrong place.
    2. The correct first reaction is that the task itself is probably broken. A hundred straight zeros is an extreme signal - even a hard but solvable task usually gets lucky at least once in a hundred. Zero looks like a wall, not a slope.
    3. Debug from the evaluation side toward the model side. Start with grading: a mistyped expected value, a strict equality comparison on floats, a case or whitespace mismatch. These are extremely common - one brittle string comparison can fail a perfectly correct answer.
    4. Then the task description: is it ambiguous enough that the agent solved a different problem, or does it reference something absent from the environment, such as an order id never seeded in?
    5. Then reproducibility: does the task contain randomness that changes the correct answer each run while the grader compares against one fixed answer?
    6. Only last comes 'the agent genuinely cannot do it'. The standard way to establish that is a reference solution - do the task correctly by hand, feed it to the grader, and see whether it passes. If the reference solution fails, the problem is one hundred percent in the evaluation. That practice is the core of Day 2.
    7. Expected follow-up: what about a task that passes 100% immediately? Usually the task is too easy or the criterion too loose; it carries no information and needs fixing too.

    答题要点

    • 第一反应应该是怀疑任务本身，而不是去优化模型。
    • 一百次全零是极端信号：真正可解的难任务通常会蒙对至少一次。
    • 排查顺序从评估侧到模型侧：判分写错、任务描述有歧义、依赖了环境里没有的东西、随机性不可复现。
    • 严格相等比较（尤其是浮点与字符串）是最常见的判分缺陷。
    • 用参考解验证：人工做对一遍喂给评分器，过不了就一定是评估的问题。

    Key points

    • Suspect the task first, not the model.
    • A hundred straight zeros is extreme: a solvable hard task usually succeeds at least once.
    • Debug evaluation-side first: broken grading, ambiguous description, missing environment fixtures, irreproducible randomness.
    • Strict equality comparison on floats or strings is the most common grading defect.
    • Validate with a reference solution: if a hand-crafted correct answer fails the grader, the fault is in the evaluation.

评论