Agent Evaluation 是我觉得为数不多还需要人力去做判断、将来很难被AI 彻底取代的职业方向。我给大家找了一个非常好的学习资料入门：Hugging Face 的公开 Training Agent 课程 学完了，你应该会有更强的 sense，判断 AI 时代下哪些工作更适合人来做 这个资料是公开的，视频都在 Hugging Face 的 YouTube 频道，代码全部开源，下面有这六节： 1、Agentic Evaluations Workshop：怎么评价一个 Agent。 这一章节去看：为什么 benchmark 分数和真实使用体验对不上？目前 Agent Eval 做到了哪一步，还有哪些问题没解决。先把“怎样才算一个好 Agent”，等等都有 cover 2、RL for Agents Workshop：给 Agent 做强化学习，难在哪 这一章节去关注：从 LLM 的 RL 走到 Agent 的 RL，会多出哪些难点？环境怎么搭、rollout 怎么跑、reward 怎么设计，以及训练过程中推理为什么会成为 bottleneck 3、SFT on agent traces：用 Agent 的执行轨迹做微调 这一章节去关注：拿公开的 coding-agent traces（执行轨迹）整理成训练数据，用 TRL + LoRA 做 SFT，在 Hugging Face Jobs 上跑，用 Trackio 看指标。基本带着走了一遍小型的微调流程 4、Distillation：把大模型的能力蒸馏给小 Agent 这一章节去关注：怎么把 teacher model 的能力转移给更小的 coding agent。off-policy、on-policy、self-distillation 都会讲，看看这几种蒸馏方式分别怎么做 5、Reinforcement Learning：SFT 之后，怎么继续用 RL 训练 这一章节去关注：用 GRPO 接着训练，讲 group sampling、可验证的 reward，以及 reward、KL、输出长度这些曲线怎么看。看 Agent 怎么 reward hacking 6、From reward functions to environments：让 Agent 在真实环境里学习 这一章节去动手：从 reset()/step() 接口讲起，用 OpenEnv 搭环境、上传到 Hub，再接入 TRL 的 GRPOTrainer。最后通过 Harbor 和 Hugging Face sandboxes，用 AsyncGRPOTrainer 训练真正的 coding agent：OpenCode。让 Agent 在环境里采取动作、拿到反馈，再继续训练

Garry Tan 开源「g-harness-evals」：同一个前沿模型做同一批任务，只换掉 agent harness，也就是系统提示、工具和记忆这些外围设计，谁更准，谁更省钱？ 测什么，怎么判分 任务不是编程题这种评测，是一家虚构公司 Pemberline 的多人办公场景。测试搭了一个模拟的 Slack，让 agent 担任团队机器人，处理权限、审批，以及别人在后续对话里提出的纠正。主榜用的是 v0.3 版本的 20 道公开开发集任务。 模型固定为 Opus 5.5 或 GPT-6.1 Sol，只换 harness。Opus 这边比较 Claude Code、Hermes、OpenClaw 和 QM，Sol 这边比较 Codex、Hermes 和 OpenClaw。Claude Code 和 Codex 各自绑定自家模型，所以两者之间不做同模型对比。 判分不看 agent 自己怎么说，而是检查任务结束后的系统状态和事件日志，确认答案是否正确、有没有泄密、有没有越权读取。费用按计量代理记录的标价计算，用总花费除以通过的题数，得出解出一题平均花多少钱，另外报告耗时中位数。 评测结果关键数字 准确率方面，Garry 认为各个 harness 的通过率区分不开，大约都在 71% 到 79% 之间，Hermes 配 Opus 的点估计是 78.8%。20 道题里有 14 道在所有组合下得分完全相同，8 到 14 个百分点以内的差距基本无法确认。Garry 也承认这套题已经接近饱和。 真正拉开差距的是成本和速度，这部分只是描述性数据，没有做统计检验。在 Opus 上，OpenClaw 解出一题约 0.44 美元，耗时中位数约 99 秒。其余几个 harness 约 0.19 到 0.24 美元，Claude Code 和 QM 大约 40 秒。在 Sol 上，Codex 约 0.17 美元、30 秒左右，又便宜又快。作者把 OpenClaw 偏贵归因于提示更长、缓存写入更多。 失败案例里，跨频道纠正这类任务所有 harness 都容易出错。Garry 也提醒，这是开发集而不是留出集的确认结果，OpenClaw 有部分组合没跑完，QM 的网络条件也没和其他组对齐。

推荐这篇，Hamel Husain——世界上最懂 AI eval 的实践者之一——说了一句话："这东西很难评估"本身就是一个产品气味。 如果你不给用户提供可检查的中间产物，他们就会重做一遍你的工作来验证输出。那你的产品对他们的价值是什么？ "这东西很难评估"是一个产品气味 我在 AI eval 上做了三年。最常听到的反对是"我们的产品很难评估"。这个反对本身就是一个产品气味——对你来说难验证的东西，对用户也难。 更重要的事：设计一个易于验证的产品，应该在写 eval 之前。 例 1：AI 数据分析 agent 几乎所有公司都在建内部分析 agent。问他一个业务问题，他找数据源、跑查询、给答案。目的是降低对数据分析师的依赖。 最常见的错误：把"答案"作为唯一的输出。 界面上只有一个数字——"Product A 上季度净收入：$4.21M"。用户除了重新做一遍之外没有其他方式验证。更好的设计不是隐藏过程，而是给用户可检查的 artifact。 一个数据分析师验证指标时会做六件事：对照可信源检验中间计算过程和总量数字、确认指标精确定义、检验相关量的合理性、拆开聚合数字按维度分解、读 SQL、记录无法验证的部分。 一个好的 AI 数据分析 agent 应该做同样的事——在回答里展示来源、假设和无法验证的问题。用户可以点击打开一个 Notebook 查看完整分析：agent 做的假设、跑的查询、按地区的分解分布、显式列出"无法验证的部分"，每一项都作为可运行的 cell 保留，让用户可以继续深挖。 这对 eval 意味着什么 如果你的产品设计成便于验证，标注成本就会降低，eval 会有更好的信号可以抽取。更重要的是，你会给用户一个更好的产品。 例 2：PE 教案生成器 一个创始人做的产品：老师输入约束（年级、时长、室内/室外、器材），AI 写一份教案。 "怎么评估教案好坏？"——Hamel 把问题反过来了：老师在意什么？ 最快的方式是看到"一个和你一样的老师已经用过的教案"。一个好的设计：不是从零生成教案，而是从一个被审核过的、14 所学校在用、今年跑了 30+ 次的可信教案出发，然后只展示改了哪几处——"缩短到 45 分钟，改热身从 2 圈到 1 圈""匹配你的器材，4 站变 3 站"。老师审核的不是一个完整教案，而是一个 diff——认知负荷大幅降低。eval 也变得更可追踪：只需要验证检索出的教案是否合理，以及每个修改是否遵守约束。 例 3：工伤医学报告 一个产品从病历（MRI、理疗记录、体检报告）生成 50 页专家意见。问题是：医生要对报告负责，所以他们会重新读一遍全部病历、逐条核查——用时和从零写一份一样长。产品没价值。 Hamel 建议把产品做成研究助手而不是报告生成器。先读每份病历，提取相关事实，附上链接让医生可以核查。两份检查意见矛盾？标出来。影像资料缺失到现在状态不确定？标出来。事实审查完毕后，"生成报告"按钮才出现——报告由已经核查过的事实组装而成。 这样设计让每个单元可以独立评分：这个矛盾是真的吗？这个引用支持这个主张吗？ 这个模式可以泛化 问这四个问题：用户实际需要检查什么？他们能和什么可信的东西对比？专家用什么信号或启发式做验证？哪些更小的单元可以被接受、编辑或拒绝？ 一条贯穿所有例子的线索是来源。让输出可检查的最快方式，是展示每个部分从哪里来，带上链接查看细节。用渐进式披露让这些来源不会压垮用户。 即使一个产品看起来"容易评估"（比如你写出了能跑通的代码），最优秀的产品仍然在让工作更可检查——Cursor 和 Devin 都录制 UI 变更的短视频，让你确认工作的正确性而不需要自己复现。 这些都不是新东西 这些都是老的设计原则——观察专家的领域叫 needfinding，医疗诊断里的结构化理解叫 sensemaking。但在 AI 时代前，验证通常发生在创建产品的过程中，是附带的。在 AI 时代，验证是瓶颈。 是时候更显式地思考它了。 原文：Hamel Husain, ""It's Hard to Eval" Is a Product Smell", 2026-06-29 #AI产品# #Eval# #产品设计#

Mistral开源Timestral：高精度的多元时间序列预测 专为多元概率预测设计的基础模型，能在同一套框架下联合预测多个变量，并支持融入已知未来的外部变量。它在GIFT-Eval等多个主流公开测试集上拿下了零样本预测第一名，同时给出了21个预测分位数来量化未来走势的不确定性。模型不仅支持最长超过3万步的长期上下文，而且最小版本仅5M参数，普通CPU即可直接运行。 项目地址：

大家日常高频使用 AI 的，应该都有这个痛点：AI 足够聪明能把任务跑完，但是！距离结果好到我能直接用，中间还有很长一段距离，有的时候 AI 的结果好得一塌糊涂，但就未必是我想要的 这个事情的解药在于Evaluations，AI 评估：我觉得每个想认真用 AI 的人都值得理解。我用 AI，越来越把重心放在 Evaluations上：什么叫做好，怎么验收，犯过的错怎么减少？ 今天结合我自己的的工作流，尝试把这件事彻底讲清楚 1/ 把“我觉得不行”，变成具体的验收标准 我之前分享过，让不加以特化的 AI 解读研报，有时每个字都认识，连起来却看不懂，还得追问好多轮。 它确实写完了。但我需要的是：读完能讲清楚公司靠什么挣钱、发生了什么变化，以及变化怎么影响盈利和估值。 所以，当前的工作流我会检查：数字有没有原始出处？季度和全年有没有混用？公司指引、券商预测、自己的判断有没有分开？市场 price in 预期的反推和我自己的建模 gap 在哪里？市场有哪些错误的逻辑？是否错杀？是否超买 Eval，就是把心里“这样才算做好”的标准，变成能反复执行的检查 能算清楚的，用程序检查；“有没有解释清楚”这种开放问题，就写成 rubric，评分标准，配上好坏案例，让 AI 辅助评判、人来校准。久而久之，你的私有化模型会越来越好 2/ 让它在真实工作的条件下接受测试，留下错误记录，持续进步 一套 eval，基本就是：Agent + 工作环境 + 任务 + 验收标准 以前 AI 输入文字、输出文字。现在 Agent 会开网页、读文件、改笔记。我会明确地写 skill 和 prompt，让 AI 去记录下来自己曾经做错了什么事情，然后再让它进行自更新（也就是 RSI），最后再让它把错误的部分重新再做一遍。 久而久之，模型的效果会越来越好。通常我会让AI做两件事情： 1. 对公司基本面短期、长期的判断 2. 实际的股票操作 回溯：哪些判断对了，就继续加强；哪些判断错了，就让模型记住错误的原因，下次不要再犯。久而久之，模型会变得出乎意料的好 3/ Evaluation 非常重要 这就是为什么目前我的每一个工作流或者工作体系，我都会写好 Evaluation 和自进化的规则。AI 顶尖聪明了，但问题就是，它有的时候认为它做的正确的方式，未必是你想要的 有了可靠的标准，AI 就可以帮忙找失败、提修改方案，再接受验证。人仍要定义什么是好，并确认评分规则衡量的确实是自己在乎的东西。 因此我建议大家如果想让 AI 把工作做好，先把“什么叫做好”写清楚

读知乎回答有感，浅谈一下后训练 benchmark Any benchmark will be saturated，而随着工业界后训练的发展，reasoning / coding 的 benchmark 越来越泛化 / 众包化。其实 LLM eval 一直是个草台班子，每家都可以有自己的 setting，而任何 setting 只要不被强行统一就存在操作的空间，最早可以调 temperature / top_p / length，后来可以调 harness / setting。 AA 给出了一个相对“规范”的 setting，让大家都听它的而不是野蛮生长，但这并不 make sense。只要评测非中心化就一定存在 noise，任何结果都可以是 cherry pick 后的，而 AA 官方的 95% 置信度结果就成了 judge 模型能力的标杆。 代价是什么呢？模型如果没有很亮眼的 AA 分数，即使精心打磨体感 / working / CUA，无人在意，这本质也是模型要 sell 就要迎合表面主流的评测中心化组织。 至少我们可以从每家基模厂、每个新模型的发榜看出来大家并不会被 AA 所局限，而 OSWorld v2、ALE、TB4 / TB-Sci 等 frontier 众包 benchmark 已经告诉我们：最 frontier 的能力一定是最通用的能力，而 agent 已经站在了单 domain 能力的肩膀上。 现在的职业任务分为三类，已经被 AI 训练好的，无法被 AI 训练的，还在被 AI 训练的。所有能归纳在 Computer Use 的都是第三类，而模型如何解决第三类职业任务仍需要数年的进化。 这些众包 benchmark 越来越变成第三类任务的闭包，决定了未来数个月内基模团队的优化方向，而越是 frontier 的 benchmark 就越有 noise。如果 benchmark 团队不为自己的错题率负责，只会诞生越来越多的错题 benchmark：GPQA-Diamond，HLE，充斥大街的弱模型 judge。 为了消灭 LLM-judge 所引发的不确定性，众包 benchmark 一定会越来越商业化，而 evaluation 一定会在短暂的时间内迎来大洗盘。