演讲者背景与工作坊定位

本次工作坊由 Wolfram Reimann（网名 Ravenwolf）主持，他是 Corvus 和 Weights & Biases (W&B) 的 AI 布道师，也是播客《Thursday AI》的主持人。他的个人标语是“早上评估模型，晚上构建 Agent，全天宣扬 AI”（I have evaluate models for breakfast, build agents at night, and preach AI all day long）。Wolfram 从早期量化本地 Llama 模型时就开始测试和咨询，后来加入德国 AI 初创公司 Qorvo。本次工作坊不仅介绍他开发的开源框架 WolfBench，更旨在传授如何从零构建自己的模型和 Agent 评估体系。参与者包括 Agent 构建者、评估新手、模型选择专家、平台与评估负责人 以及 追踪调试者。值得注意的是，现场几乎所有听众都自认为是“怀疑论者”，这表明当前业界对现有排行榜的信任度极低，亟需透明且可复现的评估方法。

核心原则：心态优于工具与技能

Wolfram 提出了评估工作的指导原则：“心态 (Mindset) > 技能集 (Skill Set) > 工具集 (Tool Set)”。AI 领域的工具更新极快，每周每月都有新变化，因此依赖特定工具是不稳定的。技能是指使用现有工具的能力，虽然重要但可迁移；而心态是评估中最难改变且最关键的部分。他特别指出，单一分数不足以反映模型性能，因为“表现是一个分布 (distribution)，而不是一个点”。许多排行榜仅展示平均值或聚合数据，掩盖了背后的隐藏权衡、运气成分以及模型在特定场景下的真实表现。这种简化的呈现方式导致用户实际体验与排行榜数据不符，从而产生不信任感。

WolfBench 的方法论：多维度指标与统一条件

为了解决上述问题，Wolfram 构建了 WolfBench。该框架包含图表、仪表板和排行榜，其核心方法论强调必须决定感兴趣的指标。除了平均分，还需关注最差和最佳得分、解决率百分比以及一致性。成本也是一个常被忽视的关键指标，例如某些便宜快速的模型可能因消耗大量 Token 而导致总成本高于大模型。此外，统一条件 (Uniform Conditions) 至关重要：任何变量的改变（如 Prompt、Agent 版本）都会使基准测试失效。Wolfram 指出，不同评测者即使使用相同基准，若设置不同（如一月用 Open Claw，二月用 Hermes Agent），结果便不可比。因此，必须进行多次运行 (Multiple Runs)，单次运行被视为“基准彩票”，结果仅为粗略估计；WolfBench 默认进行 5 次运行以确保统计显著性。

评估透明性与配置的可复现性

在构建Agent评估体系时，透明度是核心原则。作者强调必须公开所有结果数据，而非仅展示排名分数，以便他人或自动化脚本进行独立验证。这种开放态度对于处理海量收集的数据至关重要。基准测试的本质是对特定配置进行评估，而非单纯对模型打分。任何组件的变更——无论是底层数据集、推理引擎（Inference Engine）、端点服务，还是沙盒环境后端——都会导致实验条件的改变。例如，推理软件的更新或沙盒提供商的后台调整都可能悄无声息地影响结果。

"You're not ranking a model... you are actually benchmarking a specific configuration."

这意味着，保持实验环境的一致性至关重要。如果测试代码版本更新或沙盒设置微调，即便模型未变，结果也可能不同。因此，除非使用本地可控的推理环境，否则外部变量的不可控性要求评估者必须严格锁定所有依赖项。任何部分的变动都应被视为一次全新的实验，需要重新记录基准状态。

工具链的模块化与沙盒隔离

为了系统化地构建评估流程，作者提出了六个可互换的层级结构。这不仅包括底层的技能与思维模式，还涉及具体的工具选择。对于参与者而言，建议准备笔记本电脑、终端环境以及Python、UV和Git等基础工具。虽然现场演示提供了可下载的结果文件供离线使用，但拥有API密钥（如One B账户提供的免费推理额度）能更好地体验实时评估。

沙盒环境的选择是保证隔离性的关键。作者推荐使用CoreWeave Serverless Sandboxes，为每个任务提供独立的运行空间。这种隔离机制防止了评估过程对本地系统造成干扰，同时也避免了因环境残留导致的随机性误差。工具链的核心组件包括：基准数据集、评估框架（Harness）、编排系统以及Agent本身。其中，模型与服务端点往往是用户最关注的部分，但需意识到评估对象实际上包含了从API提供商（如OpenRouter、OpenAI等）到具体路由逻辑的完整链路。

基准测试的选择策略：以Terminal Bench为例

在确定评估目标后，选择合适的Benchmark（基准）是第一步。作者选择Terminal Bench是因为其专注于Agentic任务（如修复Git仓库、破解密码、数据库维修等），而非单纯的代码生成或数学解题。这类任务更贴近Agent在真实场景中的交互需求。

"I looked at all the benchmarks that have been used by the frontier labs and I saw terminal bench was on pretty much everyone."

尽管存在MMLU（多语言）、MMMU Pro（多模态）或GUI Agent专用基准，但针对通用Agent能力，Terminal Bench具有广泛的行业认可度。目前该基准有2.0、2.1及开发中的3.0版本。作者坚持使用2.0版本的理由是保持历史数据的可比性。虽然2.1版修复了部分测试用例，但版本更迭意味着基准定义的改变。若切换至新版本，之前积累的大量测试结果将无法直接对比，必须重新进行全面测试。

评估框架（Harness）的多样性与适配

选定基准后，需要部署相应的Evaluation Harness来执行测试。对于Terminal Bench，Harbor是默认的框架选择。此外，市场上还有其他流行选项：例如由英国AI安全研究所开发的Inspector框架，支持多种基准测试；历史悠久的LM Evaluation Harness；以及OpenAI自有的评估工具。用户也可以根据需求自行构建Runner。

"Some people start with picking their runner and then they pick one of the benchmarks it supports. That is also a valid way."

评估流程的构建路径具有灵活性：既可以先确定基准再选择支持的框架，也可以先选定强大的评估工具再看其兼容的基准集。关键在于确保所选Harness能够准确执行Benchmark中定义的任务逻辑。通过模块化地组合这些组件，评估者可以根据具体需求（如是否需要多语言支持、是否关注GUI交互等）定制最适合的Agent评估流水线。

版本锁定与依赖管理策略

在开始实际评测之前，首要步骤是安装 Harbor 框架。作者强烈建议锁定特定版本进行使用，因为任何变量的变更都可能直接影响评测结果的可比性。即使存在已知 Bug，保持版本一致也能确保所有模型在相同条件下进行测试。使用 UV 工具安装可以隔离环境，避免污染系统并便于后续清理。命令为 uv tool install harbor。

"I highly recommend people stick to one version because anytime you change one of the variables... then, yeah, you are changing already a variable, and the comparison comparability is suffering."

对于严肃的评测工作，作者建议Fork 仓库并自行维护分支。这样可以在需要支持新代理或提供商时，通过 Backport（向后移植）所需功能来更新版本，从而在不破坏基准测试一致性的前提下获得最新特性。这种策略平衡了稳定性与功能更新的需求。

沙箱环境的选择与部署

Agent（智能体）必须在隔离的沙箱环境中运行，严禁直接在本地系统执行。这是因为多个 Agent 并行运行时会产生相互干扰，且可能修改宿主系统状态。Docker 虽是常见选择，但在并行化方面存在资源瓶颈。作者特别感谢 Daytona 在早期提供的支持，并指出目前 Qualif 提供了两种主要的沙箱选项：基于 Kubernetes的服务和 Qualif Serverless Sandboxes。后者仅需 Vent B 账户即可使用，配置更为简便。

安装沙箱客户端需额外运行 uv tool install harbor[qualif] 以加载提供商支持。配置过程相对简单，只需在 YAML 文件中填入 API Key 即可建立连接。作者提供了便捷的 URL 链接，用户可直接输入完整配置信息，无需手动复制复杂的参数块。这种设计降低了入门门槛，使评测者能更快进入核心测试阶段。

代理模型与提供商配置

Harbor 框架支持多种主流 Agent，包括 Cursor、Claude、Klein、Codex 以及 Open Claude Hermes agent。其中，Terminus 2 是 Terminal Bench 和 Harbor 框架的默认代理。需要注意的是，Terminus 2 并非用于实际编码的智能体，而是通过模拟 CLI 环境并向模型发送按键指令来执行操作的一种测试方式。若看到未指明代理的 Terminal Bench 分数，通常默认使用的是 Simple Agent。

在模型选择上，评测者需根据目标模型匹配对应的提供商。例如，使用 GPT 系列对应 OpenAI，Claude/Fable/Lucky 对应 Anthropic。此外，OpenRouter 提供了几乎全量的模型支持，并具备 DDR（数据脱敏）功能以保护隐私。作者还提到了自有的 Inference Core，提供开源模型的服务端推理能力。

关键评测参数：上下文窗口与思维链

在设置中，上下文窗口大小（Context Window Size） 是至关重要的参数。不同提供商出于性能考虑可能提供小于标称值的窗口，例如 GLM 5.2 虽支持百万级上下文，但在作者使用的推理服务中仅开放 256K。这是因为超过一定 Token 量后模型质量会显著下降，且全窗口处理成本高昂。256K 被作者认为是性价比、速度与质量的最佳平衡点。

"I personally think 256K, that's why I recommended it to our inference team to use this in that situation."

思维与推理努力（Thinking and Reasoning Efforts） 也是影响结果的关键因素，不同模式下的表现可能出人意料。此外，系统提示词（System Prompt） 的设定直接决定 Agent 的行为逻辑。例如，若将指令设为“有帮助的助手”，模型可能会尝试询问用户；而改为“自主执行任务的智能体”并禁止提问后，评测得分往往会提升。这一细节揭示了提示词工程对基准测试结果的巨大潜在影响。

基准测试中的环境变量与沙盒配置陷阱

在进行 Agent 评估时，变量极其繁多且复杂，尤其是工具配置和沙盒资源设置。例如，若赋予 Agent 网页访问权限，模型可能会直接搜索到公开基准测试（如 Terminal Bench）的答案。虽然这体现了 Agent 的聪明才智，但也导致结果无法真实反映模型推理能力。此外，沙盒资源的限制（如 CPU 和内存）会直接影响运行速度甚至导致崩溃。如果资源不足，任务可能因超时或错误而失败，这并非模型本身的缺陷。因此，评估者必须明确测试目的：是考察模型的独立思考能力，还是其利用外部工具解决问题的能力。

"It's not really It's not even a bad thing if you want an agent, it should be smart. And if there is a solution for the problem, why should it try to think of it if there is published solution?"

任务超时设置与并发策略的权衡

时间成本是评估中的关键考量因素。默认的任务超时时间差异巨大，从 5-15 分钟到超过 3 小时不等。作者最初为所有任务分配固定的 2 小时，以避免因本地推理端点性能较弱而 handicap Open Weight 模型（如 DeepSeek）相比 SOTA 前沿模型（如 GPT）。然而，他发现对于无法完成任务的模型，长时间运行会导致其陷入死循环，造成高昂的计算成本且无结果。最终作者发现 1 小时是一个较好的平衡点。

为了应对大量任务（如 Terminal Bench 的 89 个任务），必须引入并发策略。若串行执行，耗时将长达数十甚至上百小时；但若并发数过高（如 89），则可能触发推理端点的速率限制或超出沙盒资源配额，导致评分失效。因此，需要在执行速度与系统稳定性之间找到最佳并发阈值。同时，重试策略也需精细区分：因沙盒崩溃导致的失败应重试以保护模型评分，而由模型自身愚蠢操作引发的崩溃则不应重试。

生成参数（Temperature/Top P）的标准化难题

温度值（Temperature）、Top P 和最大生成令牌数（Max New Tokens）等参数对结果影响显著，但缺乏统一标准。不同模型提供商推荐的温度值各异（如 0 或 1），且 Agent 框架可能有默认设置。若强行使用非推荐值（如将建议温度为 1 的模型设为 0），会违背最佳实践。尽管作者初期使用温度 0 以减少随机性，但发现即使设置种子（Seed）为流行的 42，由于浮点舍入误差和性能优化等底层因素，结果仍可能存在微小波动。因此，明确记录并公开所使用的具体参数组合至关重要。若模型推荐特定温度，应遵循该建议；否则需确定一个通用标准并确保所有测试者一致。

推理后端配置与最终评估框架的确定性

选择正确的推理提供商和版本是确保结果可比性的基础。以使用 Open Router 为例，若未指定特定提供商（Provider），系统可能随机分配不同的后端服务。这会导致在 89 个任务中，一半由提供商 A 处理，另一半由提供商 B 处理，从而引入不可控变量。因此，必须显式配置 One API Provider 以锁定推理后端。在确定了评估基准（Terminal Bench）、沙盒环境、Agent 框架（Terminus 2）及模型版本后，所有配置细节必须清晰记录并公开。这不仅是为了复现性，更是为了让读者明确知道评估的具体条件和测量范围。作者提供了完整的配置二维码/文件，强调透明化配置是发布高质量评估结果的前提。

Harbor 框架的自动化评测流程

演示者展示了如何使用 Harbor 框架运行基准测试，整个配置下载与执行过程仅需约 5分钟。具体操作是通过命令行加载配置文件并设置 API 密钥，随后启动评测。该框架会自动拉取 Terminal Bench version 2.0 数据集，并根据并发设置创建独立的沙箱环境。在每个任务中，系统会安装代理程序、执行具体指令（如从 Git 树中恢复丢失的仓库），并在完成后收集结果及轨迹数据，最后销毁沙箱。这种自动化流程确保了评测的一致性和可重复性。

"Harbor pulls the tasks, the Terminal Bench 2.0 data set... Then, it starts the sandboxes using a provider we are using."

评分机制与数据规模

评测的核心在于对每个任务进行二元打分：成功得1分，失败得0分。为了获得更具统计意义的结果，通常会对同一模型进行 5次 独立运行并计算平均分。演示者透露，目前共进行了 430次 评测运行，测试了包括 Cloud Code、Hermes Agent、Open Cursor Codex 等多个代理程序。虽然部分测试使用了自有推理资源，但演示中仍引用了公开价格进行成本估算（显示接近 40K 美元，实际成本较低）。这些数据为评估不同代理在终端任务中的表现提供了量化基础。

WolfBench Toolkit 的数据可视化与分析

为了处理海量的评测数据，演示者介绍了开源工具 WolfBench Toolkit（Apache 2.0 许可证）。该工具旨在解决原始评测文件难以分析的问题，通过集成 Remeo Notebook 提供可视化仪表盘。用户只需克隆仓库并设置环境变量，即可扫描本地或远程 VM（如 XE Dev 或 Hetzner）中的运行数据。目前仪表盘已识别出 443个 唯一运行记录，并允许用户过滤和查看详细的轨迹信息。这种方式避免了下载数 GB 原始数据的麻烦，使得检查代理行为变得直观高效。

"The Wolf Bench Toolkit is a way to work with this data because otherwise you now have a couple of files and you have some score, but how do you analyze it?"

自动化测试执行与结果生成

在构建有效的Agent评估体系时，必须确保所有预设的测试用例均被完整执行。任何未运行的测试都会导致结果无效，因此系统需要严格校验无错误、无超时的完整运行记录。作者展示了如何从测试列表中筛选模型并生成可视化图表，这一过程涉及对参数名称的动态调整。由于Agent内部逻辑可能不同，用户需将抽象的提示词（如“thinking extra high”）映射为Agent实际支持的特定参数模式，以确保评估条件与实际操作一致。完成配置后，系统会生成包含所有结果的JSON文件供共享。作者通过上传至Weights & Biases（W&B）或直接保存本地，最终生成一个可交互的图表工件。随后，该结果被上传至WolfBench平台，若启用替换索引选项，排行榜将实时更新。在一次针对Git仓库修复的任务中，模型以1.0的平均分完成了单一任务，证明了流程的闭环能力。

WolfBench排行榜的多维数据解读

WolfBench不仅仅是一个展示分数的终端，更是一个帮助用户发现更好问题的交互式分析工具。与仅显示平均分的传统基准测试不同，WolfBench提供了丰富的可视化维度。作者指出，排行榜上的条形图包含多层信息：底部的深色区域代表一致性（Consistency），即模型在5次运行中每次都能解决整个基准测试的百分比；中间的黄色区域代表平均分（Average Score），这是通常被引用的单一指标；而上下箭头则分别标记了5次运行中的最佳与最差得分。这种设计揭示了模型性能的稳定性。如果上下箭头距离很近，说明方差小、结果可预测；若差距巨大（如从79%到60%），则表明模型存在高度随机性，不可信赖。顶部的星号标记代表“天花板”分数（Ceiling），即模型至少一次解决的任务比例，这反映了模型的极限能力。

性能、成本与Token消耗的综合权衡

在评估模型时，仅看平均分往往具有误导性。作者对比了表现优异的Gemini 3.5 Flash与GPT-4o（文中误读为GBD 5.5/GPT 5.5，依原文语境理解为高性能模型）时揭示了风险与成本容忍度的重要性。虽然Gemini 3.5 Flash在最终得分上几乎追平GPT-4o，但通过W&B的3D视图分析发现，两者在资源消耗上存在巨大差异。Gemini 3.5 Flash为了达到相近分数，消耗了16.5亿个Token，而GPT-4o仅使用了1.36亿个Token。在成本方面，Gemini 3.5 Flash的费用高达$620，超过了GPT-4o的$497。这表明，尽管Flash模型在准确率上接近顶级模型，但其高昂的Token消耗和成本使其在实际应用中性价比极低。作者强调，理想的评估应追求高天花板、稳定的平均分和坚实的一致性基础。当两个模型平均分相近时，应选择一致性更高（底部深色区域更大）的模型。例如，某“超高级思维”模式比“中级思维”模式高出6个百分点，这种差距在统计上是显著的。

“排行榜本身生成的不仅仅是一个答案，它帮助你找到更好的问题。你在看什么？你关心的是模型的能力还是可靠性？”

“底部的深色部分...是我所说的一致性。这意味着如果得分很高，模型非常可靠，因为你可以期望它始终完成任务。”

“Gemini 3.5 Flash使用了16.5亿个Token，而GPT-4o仅使用1.36亿...成本为$620，相比之下GPT-4o为$497。”

模型选择与基准测试的透明度

在评估Agent性能时，决策并非仅基于单一指标，而是需要在速度、成本和成功率之间寻找平衡。W&B的Wolf Bench平台提供了一个决策表面（decision surface），允许用户加载快照、添加自定义指标并导出结果，从而进行多维度的对比分析。例如，在当前的基准测试中，GPT-5.5 with Codex 是表现最好的模型。然而，这种高性能往往伴随着高昂的成本。数据显示，测试该组合花费了近 1000美元（almost a thousand bucks），相比之下，使用相同模型但不同配置的Cursor仅需 282美元 且Token消耗略少。这种巨大的成本差异迫使评估者必须在“最佳性能”与“性价比”之间做出选择，因为即使分数接近，也可能存在随机性，需要多次运行才能确认结果的稳定性。

拒绝执行与异常高成本的教训

基准测试的透明度至关重要，因为它能揭示模型失败的根本原因。以 Fable 为例，该模型在测试中出现了 13次拒绝执行（refusals）。由于这些拒绝导致任务失败，Fable成为了本次基准测试中最昂贵的项目，总花费高达 11,000美元。这一案例生动地说明了为什么人们有时会质疑基准测试的可信度：如果模型因为安全或策略原因拒绝执行任务，其分数会极低且成本极高。正如演讲者所言：

"Don't tell anyone because it cost 11,000 just to test Fable and it failed because it refused so many tests."

通过查看Trace（追踪记录），用户可以清楚地看到模型为何拒绝，从而理解分数背后的逻辑。这种透明度使得基准测试不仅仅是数字游戏，而是对模型行为模式的深入洞察。

“过度思考”导致的性能反直觉下降

在测试过程中，一个令人惊讶的发现是：增加模型的“思考”层级（thinking level）并不总是带来性能提升。对于 Opus 4.6，当将思考模式从关闭提升到最大时，得分反而下降了。通过检查Trace发现，模型陷入了过度思考（overthinking）的困境：它花费大量时间分析不存在的命令，而不是直接尝试执行并处理错误。相比之下，一个不进行复杂思考的Agent通过试错（trial and error）——即直接运行命令、接收错误信息并修复——能够更有效地完成任务。演讲者指出：

"The difference... is that you see the model it thinks too much. It's overthinking... While an agent that is not even thinking, it's just doing stuff."

此外，Fable 也表现出类似的问题：模型过于自信，认为自己的路径优于基准测试设定的标准，导致最终验证失败。这表明“太聪明反而坏事”在某些Agent场景中是真实存在的风险。

Trace作为证据：从图表到细节的深入分析

W&B平台的核心价值在于将柱状图（Bar）作为声明，而将Trace作为证据。用户可以点击任何性能数据点，进入Weave界面查看构成该分数的所有运行记录（如89个任务）。在Trace中，可以逐层检查：初始用户指令、LLM的第一条命令、分析过程以及最终执行结果。这种细粒度的检查揭示了模型在每一步的决策逻辑。

为了应对Trace数据量巨大、阅读耗时的问题，平台内置了Agent功能。用户可以直接指令内部Agent分析Trace并生成报告。回顾整个评估过程，影响基准测试结果的变量繁多，包括： 1. 版本差异：如OneBench 2.0与2.1。 2. 基础设施：模型服务、路由甚至推理端点的更新。 3. 资源限制：Agent因沙箱资源耗尽而失败，并非模型本身能力不足。 4. 采样参数：温度（temperature）和默认思考设置。 5. 策略配置：超时政策和重试机制。这些变量共同决定了最终的评估结果，因此必须结合Trace进行综合判断。

规避推理基础设施导致的评估偏差

在构建可靠的 Agent 排行榜时，忽略底层基础设施错误会导致评分失真。如果评估过程中没有设置重试机制且遭遇基础架构故障，最终得到的分数将是不可靠的。因此，在每次运行评估后，必须全面审查所有错误和失误，重点排查是否存在推理层面的问题。具体的检查手段包括观察响应中是否出现重复字符，或者提示词模板的 Token 是否泄漏到了实际回复内容中。这些异常现象通常是分词器问题或推理服务器故障的直接信号。

"If you don't retry and there has been infrastructure error, you would get a bad score."

对于新发布的模型，这一环节尤为关键。由于推理引擎对新模型的支持往往不够完善，初期评估结果可能无法反映模型的真实性能。作者分享了一个典型案例：某新模型在初次评测中表现平平，但一周后使用相同的配置再次运行，结果却显著提升。这并非模型本身发生了改变，而是推理引擎在此期间得到了优化。因此，评估者需要意识到，性能波动可能源于工具链的成熟度而非模型能力。

构建可复现且透明的评估体系

为了建立比单纯发布分数更可靠的排行榜，应当采用"Bring Your Own Everything"（自带一切）的理念。这意味着评估者需要掌握所有的构建模块，从选择具体的 Agent 框架、测试模型到确定评估指标，都需要有清晰的思路。核心在于运行可复现的基准测试配置（reproducible benchmark configurations），并公开分享结果。这种透明度能够确保其他研究者验证数据，从而提升整个社区评估标准的一致性。

"Use the message, bring your own everything. You have the building blocks..."

作者强调，仅仅运行代码并公布一个数字是远远不够的。评估者需要具备识别潜在陷阱的思维模式（mindset），通过严谨的流程来制作排行榜和图表。这不仅涉及技术实现，更关乎方法论的严谨性。通过分享详细的配置和数据，可以避免因黑盒操作导致的误解，让评估结果更具说服力。

开放协作与社区共建的愿景

作者呼吁业界进行更广泛的合作与开源共享。如果希望使用 Wolf Bench 进行评估，可以直接联系作者；如果有模型需要测试，也欢迎合作发布结果。这种协作模式旨在减轻单一团队的负担，同时丰富评估数据的多样性。

"If you want to work with Wolf Bench, contact me... We could collaborate and publish the results so I don't have to run everything."

此外，作者鼓励使用其他框架进行衍生评估（off-spin），无论采用何种工具，只要方法科学都值得尝试。对于正在开发模型或 Agent 的创作者，作者也开放了基准测试合作通道，表示已与部分 Agent 创建者建立联系并即将公布相关结果。最后，作者提到了每周四早上的播客更新计划，旨在帮助社区跟踪快速变化的行业动态。

结论

本次评估证实，单一平均分无法真实反映Agent性能，必须结合一致性、成本及Token消耗进行多维权衡。透明且可复现的配置是建立信任的基础，任何基础设施或参数变动均需视为新实验。结果显示，“过度思考”与拒绝执行会显著降低效率并推高成本，而稳定的重试机制能修正基础设施偏差。理想模型应在保证高分一致性的前提下优化资源消耗，评估者需通过Trace深入分析失败原因而非仅看排名。