- Authors
- Name
- Youngju Kim
- @fjvbn20031
框架怎么修，分数都不动
假设你打磨了工具表面、把失败返回结构化、把上下文改成了 playbook——成功率曲线却纹丝不动。这是构造的例子，但这种纹丝不动有一个常见原因：不是没有改进，而是现在的评估者看不见改进。在一个"只要没崩就算通过"的评分器之下，所有提升结果质量的改动都不会体现在分数上。
这种局面危险在于，结论会倒着长出来。真实状态是"改进了但测不出来"，可只看曲线，读出来的却是"修框架没用"。
测不出来的质量，就选不出来
这是本系列反复回到的原则。框架改进归根到底是一个选择循环：做出改动、评估、采纳更好的那边。这个循环能选出的质量，只有评估者能分辨的质量。在评估者分辨不了的维度上，再好的改动也只能以随机概率被采纳。所以弱评分者不是小小的遗憾，而是整个系统的上限。
Lilian Weng 的框架文章也把弱评估者列在框架工程难题清单的第一位：许多任务缺少快而准的验证器，还有研究品味、长期价值这类连验证器都难以构建的质量。"瓶颈在评估而不在别处"这个诊断，接近实际推动这个领域的人们的共同结论。
评估者的阶梯：从冒烟到面板
评估者不是有或没有的问题，而是强度的问题。本系列把它整理成五级阶梯。
- 冒烟 — 只看运行有没有结束，不看做了什么。结果质量、改动范围、回归全是盲区。
- 单元测试通过率 — 得到一个数字。这个数字只有在测试文件诚实时才有意义，测试覆盖不到的质量仍是盲区。
- 评分细则（rubric） — 先写下什么算好，再按标准打分。噪声大幅下降。
- 细则 + 封存评分数据 — 把评分标准和标准答案放在智能体既读不到也写不了的地方。
- 细则 + 牵制指标面板 — 不只看成功率，还一起盯工具调用数、修改范围、被删掉的测试数。
越往上越贵。要点不是永远用最顶层，而是知道自己现在站在哪一级、这一级的盲区是什么。在冒烟这一级精心修框架，就像用没有刻度的秤称料做菜。
评分细则：先写下什么算好
阶梯中段是实务里性价比最高的位置。Anthropic 的多智能体系统复盘写道，他们的评估给 LLM 评审一份细则，让它输出 0.0 到 1.0 的分数和通过与否。标准是：事实准确性、引用准确性、完整性、来源质量、工具效率。复盘还补了一句：自动评分漏掉的细微失败，是人工测试抓住的。
# 代码评审摘要智能体的评分细则（构造的节选）
- id: grounded
weight: 3
pass: '每条意见都附有文件路径和行级依据'
- id: scope
weight: 2
pass: '不提及请求的修改范围之外的文件'
- id: actionable
weight: 2
pass: '有评审者能立刻执行的下一步'
细则的价值先于评分自动化，在于把共识写成文档。如果团队对什么是好结果都没有共识，接上什么评分器，这种分歧都会以噪声的形式冒出来。
封存与牵制：让评分碰不得
从第四级开始，主题变成评估的完整性。如果评分标准和答案数据放在智能体能写的路径里，提高指标最便宜的办法就不再是把任务做好，而是改评分。第五级的牵制指标，则盯着成功率上涨的同时其他信号有没有变得诡异。这两级与第 6 篇奖励作弊的主题直接相连，详细内容放在那一篇。
先校准评估
这是关于顺序的结论。想自动化框架改进，先校准评估者。评估是噪声，循环就跟着噪声走，自动化只会让这种移动更快。指标上涨、实际使用质量原地踏步的系统，多半是把这个顺序弄反的结果。
校准的实务，本博客另有文章展开：测人工标注与评审判定的一致率，用分歧案例修订细则，如此循环。推荐搭配阅读评估驱动开发中，最先该校准的是评审者。
亲手练习
框架工程 RPG 的第 5 层恰好就叫本文的标题——"评估者瓶颈"。游戏里评估者被实现为给任务分数封顶的规则，你可以亲眼看到同一套框架在冒烟之下和在细则之下跑出的结果如何分岔。
- 上一篇：循环设计 — 在无限循环与过早放弃之间
- 下一篇：奖励作弊 — 指标在涨，任务在败
参考资料
- Harness engineering for self-improvement — Lilian Weng, 2026-07-04 —— 把弱评估者列为框架工程第一难题的段落在这篇文章里。
- How we built our multi-agent research system — Anthropic, 2025-06-13 —— 基于细则的 LLM 评审与 0.0-1.0 打分、人工测试抓住自动评分漏洞的复盘都在这篇文章里。
- 五级阶梯是本系列与框架 RPG 使用的整理方式，正文中的细则示例是构造的。开头的平坦曲线故事也是构造的例子。