面试官可能会问：“一个研究 Agent 写出一篇看起来不错的报告，你怎么证明它真的变好了，而不是更会迎合裁判？”
Agent 评估比普通问答难，因为任务往往没有唯一标准答案，而且结果来自多步执行。最终结论正确，可能只是偶然猜中；过程看起来合理，最终引用也可能错；质量提高一点，却多调用许多次模型和工具，也未必值得上线。
只看最终答案，会漏掉错误工具、无效循环、越权尝试和不稳定恢复。只看轨迹，又可能奖励一条形式漂亮却没有完成用户目标的路径。只看成本，则会鼓励 Agent 少做必要验证、过早结束。
因此评估至少分三层：任务结果是否满足用户目标，执行轨迹是否用正确方式推进并安全恢复，资源与成本是否在预算内。三层分别设指标和硬门禁，再观察质量与成本的权衡，不能把所有问题压成一个容易刷的总分。
先给出 30 秒回答
Agent 评估我会分任务结果、执行轨迹和资源成本三层。结果层按任务类型定义完成条件，例如事实正确、引用可验证、覆盖关键点、结构符合要求；轨迹层检查规划、工具选择、参数、Observation 使用、失败恢复、停止条件和权限，不依赖隐藏思维文本；成本层记录模型 Token、调用次数、工具与执行资源、端到端时间。评测集覆盖正常、歧义、工具失败、冲突、权限和长任务，用规则、LLM Judge 与人工抽检组合评估。安全与关键事实设硬门禁，质量和成本看分层指标及 Pareto 权衡。每次版本固定配置、多次运行、按场景切片，并把 Badcase 回流到数据和系统修复。
最重要的是让评估指出具体薄弱环节；一个好看的总分如果不能定位问题，就没有多少改进价值。
结果回答做没做成，轨迹回答怎么做的，成本回答是否值得。
为什么“最终答案正确率”不够
开放任务往往有多个合理答案。研究报告没有唯一措辞，代码修复可能有不同实现，客服处理也可能有多条合规路径。
即使有标准答案，Agent 还可能偶然蒙对。它调用了错误工具，拿到无关结果，最后依靠模型记忆写对结论。这种轨迹在数据更新或问题变化后很容易失败。
相反，Agent 可能完成了高质量检索和验证，但最后格式不符合用户要求。只记一个失败，会掩盖前面能力，也无法决定修 Prompt、工具还是状态机。
因此结果层要拆维度，轨迹层要独立归因。最终综合结论可以有，但必须能回到每个分项和样本。
第一步：先把“任务完成”写成可验收条件
不同任务有不同完成定义。
事实问答要求关键结论正确且有支持证据。研究报告还要求覆盖指定范围、引用与主张对应、冲突被说明、未知部分不编造。工具任务要求真实业务状态达成，而不是 API 返回成功。代码任务要求测试或行为验证通过，而不是模型说“已经修复”。
完成条件可以分硬条件与质量维度。权限合规、关键事实、必须引用和副作用确认是硬门禁，任何一项失败都不能被语言流畅抵消。覆盖、结构、简洁和解释质量可以作为分维度评分。
每个样本保存输入、上下文、允许工具、完成条件、参考证据、禁止行为和评分 Rubric。开放任务不一定要有一篇“标准答案”，可以有必须覆盖的事实、允许的结论范围和反例。
如果无法写清成功条件，模型、评审和人工会各自理解“好”，版本比较就没有意义。
评测集怎样覆盖真实任务
评测集不应只放能顺利完成的常规问题。
按任务类型覆盖检索、分析、写作、代码、数据库和多工具组合；按难度覆盖一步、长链和需要澄清；按风险覆盖只读、敏感数据和副作用；按故障覆盖空结果、超时、格式变化、权限拒绝、冲突信息和部分成功。
加入难负例。用户问题看似需要工具但其实信息不足，正确行为是澄清；多个工具都能做但成本和权限不同；历史记忆与当前输入冲突；证据不足时正确行为是拒绝下结论。
评测集按来源、业务域、时间和版本标记，避免数据泄漏与过时。固定核心集用于版本对比，动态挑战集防止长期针对静态题刷分，线上 Badcase 经过脱敏与审核后补充。
数据分布比题数本身更重要。没有真实样本规模时，只给覆盖维度，不虚构“多少题足够”。
结果质量应该评什么
事实正确性看关键主张是否与证据一致。引用质量看链接是否可访问、引用位置是否支持对应主张，而不是只数引用数量。
覆盖度看用户要求的关键方面是否遗漏。完整不等于越长越好，要识别重复和无关扩写。对于不确定事实，是否清楚标明限制也是质量的一部分。
结构与可读性看答案能否让目标用户理解，是否按要求输出表格、步骤或代码。它不能补偿错误事实。
任务完成还要看真实外部状态。工具执行任务应通过业务验证器或后端状态确认，模型自评不能代替。
开放结果可以使用 Rubric 评分，每个维度定义不同档位的可观察证据。Rubric 越具体，人工和 Judge 越容易一致。
轨迹质量应该评什么
轨迹评估不要求裁判阅读模型的私密思维过程，而是检查结构化计划、动作、工具调用、Observation、状态变化和完成证据。
规划层看子目标是否覆盖任务、依赖是否合理、是否在信息不足时澄清。工具层看是否选对工具、参数是否正确、权限是否合规、是否重复无效调用。
Observation 层看 Agent 是否忠实使用工具结果，遇到空、冲突和部分结果有没有调整。状态层看关键约束是否保留，重试与恢复是否覆盖旧结果。
停止层看完成条件是否满足，是否过早结束或无意义循环。失败恢复看暂时故障、权限拒绝、不可重试错误和业务缺口是否走不同路径。
安全事件作为硬门禁。即使最终答案正确，只要发生越权、未确认副作用或泄露敏感数据，就不能算合格轨迹。
最终质量与执行过程互相补充，任何一层都不能单独代表系统。
成本到底包括什么
Agent 成本不只有模型账单。至少要记录输入输出 Token、模型调用次数、工具调用与第三方费用、代码或检索计算资源、存储、人工介入和端到端时间。
不同模型、工具和缓存有不同计价方式，必须保存版本与计费口径。一次任务失败后重试，成本也属于该任务，不能只统计最终成功路径。
延迟与货币成本不是同一维度。并行可能降低等待时间却增加调用，缓存可能减少模型成本却增加存储与一致性复杂度。不要把它们随意折成一个分数。
按任务难度和结果质量切片看成本。复杂任务合理使用更多资源，简单任务却反复调用就是浪费。平均值会掩盖极端长尾，至少看分布和异常样本。
没有真实运行数据时，文章只定义记录字段和比较方法，不报告单次成本、节省比例或延迟改善。
怎样把质量和成本放在一起比较
可以先设置硬预算和安全门禁，再在通过的方案中比较质量与成本。不要允许更低成本补偿关键事实错误，也不要允许更高质量无限突破资源上限。
观察 Pareto 前沿比单一加权总分更诚实。如果方案 A 质量更高但成本也更高，是否采用取决于任务价值和 SLA；如果方案 B 质量更低且成本更高，它明显被支配。
还可以按任务风险动态路由。低风险简单任务走轻量路径，复杂研究才允许更多检索和验证。但路由策略本身也要进入评测。
权重和预算来自业务需求与真实评测，不能先拍一个公式。即使需要综合分，也保留所有原始分项和硬失败原因。
规则、LLM Judge 和人工怎样组合
能确定的内容优先规则。JSON 是否可解析、工具名是否合法、测试是否通过、引用 URL 是否存在、权限是否拒绝，都不需要 Judge 猜。
开放质量由 LLM Judge 按明确 Rubric 评分，例如覆盖、引用支持和结构。Judge 输出结构化分数、证据引用和理由，便于审计。
人工用于标注基准、校准 Judge、处理高风险与争议样本，并抽检版本变化。自动评估扛量，人工保证方向。
Judge 也有位置、长度和自我偏好。A/B 比较时交换顺序，Rubric 明确不奖励灌水，使用不同模型或多人样本校准。Judge 版本变化后重新验证与人工一致性。
不能让同一个 Judge 分数既做唯一训练奖励，又做唯一发布门禁，否则系统会学习迎合它。
Goodhart 定律怎样在 Agent 里出现
奖励引用数量，Agent 可能堆无关链接；奖励少调用，Agent 可能跳过必要验证；奖励报告长度，Agent 会灌水；奖励工具成功率，系统可能只选择最容易成功而非最合适的工具。
防止刷分需要多维度、硬门禁、动态挑战集、对抗样本和人工抽检。指标定义定期复查，关注分数提升是否对应真实 Badcase 减少。
把指标按场景切片也很重要。总分提高可能只来自简单题，复杂、权限和故障样本反而退化。
评估系统与被评系统是持续博弈。不要把 Rubric 设计成固定 Prompt 后长期不变。
一条轨迹怎样分层打分
假设任务要求比较两个技术方案并给来源。轨迹先拆子问题，搜索候选，访问原文，识别冲突，生成带引用结论。
结果层检查关键对比维度、事实与引用、限制说明和结构。轨迹层检查是否访问原文而非只用搜索摘要，冲突是否追加验证，工具参数与来源是否正确，完成前是否满足证据门禁。
成本层记录模型与工具调用、Token、等待和重试。若一个版本多次重复同一查询，最终报告相同，也应暴露轨迹和成本退化。
若结果正确但引用来自无关页面，硬门禁失败。若轨迹规范但结论漏掉用户要求，结果层失败。若两层都通过但资源明显异常，进入性能优化而非否定全部能力。
怎样设计离线评估流水线
冻结评测集版本、Prompt、模型路由、工具版本、状态机和随机配置。对每个样本运行多次，以观察非确定性，不用一次结果代表稳定能力。
执行后保存结果、结构化轨迹和资源记录。规则评估先运行，Judge 只看需要语义判断的部分，关键样本进入人工抽检。
聚合报告显示总体、任务类型、难度、风险、工具、错误类型和成本分位。任何综合分都能下钻到样本和 Trace。
版本对比使用配对样本，查看新增修复、旧能力回归和失败迁移。安全门禁、权限和副作用错误单独报告，不被平均。
评估支持断点续跑和样本级缓存，但缓存键包含所有影响行为的版本。配置变化后不能误用旧结果。
在线评估与离线评估怎样配合
离线集可重复、适合发布门禁，却不能完全代表真实用户分布。线上观测能发现新表达、工具变化、长尾故障和成本异常。
线上不一定有标准答案，可以看任务后端状态、用户纠正、人工接管、引用反馈和失败类型。高风险场景先小范围影子或人工审核，不以用户为实验代价。
线上 Badcase 脱敏后进入候选池，人工确认任务定义、证据和预期行为，再加入固定或挑战集。不能直接把用户差评当作唯一标签。
离线提升上线后仍要监控分布漂移。工具、模型与业务规则变化可能让旧评测失真。
Trace 如何服务评估，但不等于评估
Trace 提供模型调用、工具、State 和工件事实，评估器在其上判断轨迹质量。没有 Trace 很难知道错误在哪，但有 Trace 不代表已经定义“什么是好”。
评测样本把完成条件与 Trace 对齐。例如要求至少一条可验证来源，评估器检查引用工件和对应主张；要求权限拒绝后停止，检查工具错误与后续动作。
Trace 字段变化要版本化，评估器也保存版本。旧轨迹缺字段时标记不可评，不要默认通过。
评估结果回写失败标签与证据引用，便于团队从样本跳到最早错误 span。第 24 篇关注如何记录和回放，本篇关注用什么标准判断任务、轨迹和成本。
固定任务、分层评分、切片报告和 Badcase 回流构成持续迭代。
怎样把评估结果变成改进动作
结果正确性低且工具证据正确，优先修最终生成与引用绑定；目标表或工具选择错，修意图、规划和路由；参数错误，修 Schema 与上下文；无效循环多，修停止条件和进展判断；成本长尾高，查看重试、上下文和并发。
失败标签按任务类型和首次错误层聚类。高频且高风险的格子优先进入修复和补数据，而不是对所有 Prompt 做泛化修改。
修复后用原 Badcase、同类样本和难负例回归，确认没有只记住一题。若需要训练，评估发现的弱点可以指导种子与轨迹数据补充，但评测集本身不能泄漏到训练。
每次改动记录假设、影响层、目标样本和回归结果。没有真实结果时只写计划，不把预期改善写成事实。
常见的六个误区
只看最终答案，不看轨迹与安全。只看工具成功，不看业务任务。只看平均总分，不看场景切片和长尾。用同一个 Judge 训练又验收。把更少调用一律当更好。评测集长期不变，系统针对静态题过拟合。
另一种常见误区是先定一个漂亮指标，再补任务定义。正确顺序相反：先明确用户目标、风险和完成证据，再选择能反映它们的指标。
结果、过程、安全和资源都通过，才有资格比较版本。
面试官会怎样连续追问
追问一：为什么只看最终结果不够
Agent 可能蒙对、用错工具或发生越权。轨迹评估能定位规划、工具、状态、恢复和停止问题，也能发现结果正确但过程不可接受。
追问二：轨迹评估是不是要看完整思维链
不需要。评估结构化计划、动作、工具参数、Observation、State 变化和完成证据即可，不依赖隐藏推理文本。
追问三：质量和成本怎样合成一个分
优先不强行合成。安全和关键质量设硬门禁，通过后看质量与成本分项和 Pareto 权衡。需要综合分也保留原始维度。
追问四：LLM Judge 可靠吗
它可扩展但有位置、长度和自我偏好，需要清楚 Rubric、顺序交换、多 Judge 或人工校准，关键门禁优先使用规则与人工。
追问五：怎样避免评测集被刷
固定核心集加动态挑战集，隐藏部分样本，加入对抗与难负例，持续补线上 Badcase，并避免把评测集泄漏进训练。
追问六：怎样证明新版本真的更好
固定配置做配对多次运行，按场景切片比较结果、轨迹、安全和成本，检查修复样本与回归样本，再用影子观测验证分布变化。
用三层评估框架回答这道题
Agent 评估我分任务结果、执行轨迹和资源成本三层。先按任务类型写清完成条件，关键事实、权限、引用和副作用是硬门禁；结果层再评正确、覆盖、引用和结构。轨迹层看结构化计划、工具选择与参数、Observation 使用、State、失败恢复和停止，不依赖隐藏思维链。成本层记录 Token、模型与工具调用、计算、人工和端到端时间，不把更少调用自动当更好。评测集覆盖正常、歧义、冲突、权限、工具失败和长任务，规则负责确定性指标，LLM Judge 按 Rubric 评开放质量，人工校准和抽检。版本固定配置、多次运行、按场景切片，安全不被平均，质量与成本看 Pareto 权衡。Badcase 按最早失败层回流修复和数据闭环。
别只报总分：核对你的评估证据
- 每种任务是否有明确完成条件、硬门禁和质量维度。
- 评测集是否覆盖常规、歧义、冲突、权限、工具失败和长任务。
- 结果层是否评正确、引用、覆盖、未知和可读性。
- 轨迹层是否评规划、工具、参数、Observation、恢复和停止。
- 是否把越权和未确认副作用作为硬失败。
- 成本是否包含模型、工具、计算、人工与端到端时间，并说明口径。
- 是否避免用成本补偿关键质量错误。
- 规则、Judge 与人工是否各做擅长部分，Judge 偏见是否校准。
- 是否固定版本、多次运行、按场景切片并保留样本级 Trace。
- 评测集是否与训练数据隔离，并有动态挑战和 Badcase 更新。
- 修复是否经过原样本、同类样本和难负例回归。
- 没有真实数据时，是否避免虚构评测分数、成本和线上规模。
一套可靠的 Agent 评估体系，不会只告诉你“总分涨了”。它会说明哪些任务真正完成、哪一步更稳定、哪些安全边界仍然失败，以及为这份质量付出了什么资源代价。