又一个基准测试：解决相同任务，0.34美元对比27.60美元

# 我们刻意在弱模型上调试 AI 工作台 来源：https://archestra.ai/blog/we-debug-our-ai-harness-on-weak-models-on-purpose 强大模型极善于隐藏产品缺陷。给它一个失效的工具调用或令人困惑的错误，它仍可能完成任务。 弱小模型则不那么宽容。当工具、提示或运行时出错时，它们会迅速失败，这使得它们对调试很有用。我觉得这就像在顶配 MacBook Pro 上测试应用和在老旧 ThinkPad 上测试的区别。 我们特意在弱模型上运行 Archestra Chat（https://archestra.ai/docs/platform-chat?q=chat）（我们内置的聊天界面，用于操作智能体和 MCP 工具），记录完整轨迹，并调查它们暴露出的故障。这种方法已发现文件处理、沙箱工具（https://archestra.ai/docs/platform-code-sandbox?q=sandbox）、提供商架构（https://archestra.ai/docs/platform-adding-llm-providers?q=provider%20schema）以及我们的智能体运行时（https://archestra.ai/docs/platform-agents）中的缺陷。修复这些漏洞对所有模型都有帮助——不仅仅是弱模型。强模型不再需要花费额外的 token 和重试来绕过我们的错误。结果，即使与弱模型配合（不仅仅是能够弥补其缺陷的模型），我们的工作台也能可靠运行。 这个想法来自一位客户，他问了我一个简单的问题：Archestra Chat 能否与更便宜的模型一起工作？我无法回答。当时，我们一次只测试一个变更，调整工具和提示，然后检查最终答案是否正确。有时奏效，有时不行。我们没有可重复的衡量方法。我骨子里是个机器学习从业者，如果系统表现如此，我首先构建的是一个验证循环。 这个循环变成了一个基于 26 个真实客户工作流的端到端基准测试（https://archestra.ai/blog/we-debug-our-ai-harness-on-weak-models-on-purpose#so-which-models-held-up-open-weight-vs-frontier-results）。它启动实际产品，运行每个任务，并根据隐藏的真实答案检查回复。每晚，它在约十个模型上重复相同的任务。**重要提示：** 这不是学术基准尝试。但它是一个高级集成测试，回答两个问题：我们的产品在哪里失败？在助手停止做有用工作之前，我们可以沿着价格阶梯下探多远？ ## https://archestra.ai/blog/we-debug-our-ai-harness-on-weak-models-on-purpose#how-we-benchmark-ai-agents-on-real-work-not-party-tricks 我们如何对 AI 智能体进行真实工作（而非把戏）的基准测试 我处理这个问题的方式与你处理任何严肃评估的方式相同：测试必须是一个系统无法作弊的东西，并且必须像现实一样。这引出了两个设计支柱。 首先，助手通过专用通道提交其最终答案。该通道检查格式，而不是答案是否正确。如果任务期望一个数字，它拒绝文本。如果期望三个候选，它拒绝两个。 答案仅在提交后使用确定性代码（而非另一个 LLM）检查正确性。评分器和预期答案在运行期间对智能体隐藏。如果智能体能够读取答案键，它可能会操纵测试，那么分数就是谎言。它不能，所以分数有意义。 使分数有意义的边界： `submit_result` 从不告诉智能体它是否正确——只告诉 JSON 是否根据任务的模式解析。预期的真实答案完全存在于该行的右侧，并且从未被部署到沙箱中，因此智能体无物可读。 其次，我们不仅记录通过或失败。我们捕获助手的整个可见轨迹：每条消息、工具调用、它接触的文件以及它产生的产物。这将“它失败了”变为“它确切地在这里失败了”。这是一个让你羞愧的数字与一份你可以实际使用的报告之间的区别。稍后将详细介绍，因为这已成为我们构建的最有用的东西。 任务来自现实，而非我们的想象。每一个都是基于我们实际看到的东西：一个真实的客户工作流或一个真实事件，稍作匿名化处理。今天我们有少量任务，每当现实给我们带来新的难题时，它就会增长。一旦一个任务被加入，它就会一直存在，作为该失败模式的永久警铃。 一些具体例子： - **文档工作流。** 从混合文件格式中批准发票和筛选简历，同时拒绝隐藏的提示注入（https://archestra.ai/blog/prompt-injection-examples）和不一致的数据。 - **事件分类。** 在包含合理干扰项的无序日志压缩包中找到中断原因。 - **跨对话的记忆。** 在一个对话中创建文件，然后在新对话中检索并使用它——这测试了我们在七月发布的持久化文件（https://archestra.ai/blog/new-projects-filesystem）。 - **实时事实。** 获取仓库的当前星数、指定时间的资产价格或最新包版本。 我们已经收紧任务，使其匹配真实员工实际说话方式：“这里有一些发票。做正确的事。” 那个较难的版本才值得衡量。 我们还围绕哪些内容属于测试套件保持严格界限。任务应该困难，但使用 Archestra Chat 实际拥有的工具即可解决：文件访问、所需的网络访问、沙箱和技能（https://archestra.ai/blog/new-skills-sandboxes），以及客户连通的系统。我们不是在测量模型能否做前沿物理学，也不是在测试尚未构建的功能。有用的失败模式是：“产品本应能够做到，但没有做到。” 一个实现细节很重要：这不是模拟基准测试。它启动产品。基准测试让 Chat 以无头模式针对真实的 Archestra 后端运行。对于每个环境，它在一个新端口上启动全新后端，迁移新数据库，预置提供商、技能、MCP 服务器（https://archestra.ai/mcp-catalog）和智能体界面，通过产品驱动聊天会话，带外评分答案，然后拆除实例。 工作台是公开的：它位于我们单体仓库的 `ai-labs` 工作区（https://github.com/archestra-ai/archestra/tree/main/ai-labs），与基准测试、任务套件和环境定义一起。 它每晚在 CI 中针对当天的部署构建运行，跨越约十个模型的名单。本文后面出现的数字来自这系列夜间运行。 单次运行，端到端： 以上每个框都服务于基准测试的一项工作：运行每个任务-模型组合，产生评分结果和记录轨迹，然后拆除一切。此处没有解释运行失败的原因。这将在稍后的独立工具中出现。 ## https://archestra.ai/blog/we-debug-our-ai-harness-on-weak-models-on-purpose#anyone-can-ship-a-demo-that-runs-on-a-maxed-out-macbook 任何人都能交付一个在顶配 MacBook 上运行的演示 以下是让我惊讶的部分。 稍微思考一下软件性能。任何开发者都能编写一个在最新 MacBook Pro 上运行流畅的应用——机器太快，会隐藏你的罪恶。懒散的代码、浪费的操作、草率的逻辑：什么都不显现，因为硬件强行辗过它们。然后你试图在带有红色 TrackPoint 和旋转硬盘的老式 IBM ThinkPad 上运行同一个应用，它会立刻崩溃。你走的每一条捷径瞬间暴露。 高级 AI 模型就是顶配 MacBook。它们可以蛮力穿越糟糕的管道——格式错误的工具调用、令人困惑的错误消息、缺失的回退——让产品看起来比实际更健康。模型绕过了 bug，你的基准测试返回绿色，而你一无所获。 因此，我们在隐喻上的老旧 ThinkPad 上进行调试。我们故意针对弱小、便宜的模型运行基准测试，因为它们不自我修复。当我们的管道中即使只有一点小问题，弱模型会立即且大声地绊倒——这意味着它准确告诉我们该修复什么。弱模型是一个更好的烟雾报警器，正是因为它们更不擅长弥补我们的错误。 这不仅仅是一个巧妙的调试技巧。能够存活在老 ThinkPad 上的软件是随处运行良好的软件。一个弥补我们错误的模型仍然在重试、token、延迟和脆弱性上付出代价。针对最弱模型强化 Chat，就是停止对最强模型征税的方式。测试方法和业务目标原来是一回事。 你可以在下面结果表中看到这种税：两个性能相似的模型在价格上可能相差两个数量级。 ## https://archestra.ai/blog/we-debug-our-ai-harness-on-weak-models-on-purpose#the-real-bugs-weak-models-found-for-us 弱模型为我们发现的真正缺陷 坦诚地说，基准测试到目前为止最大的贡献并非排行榜。它是一个 bug 发现机器，而大多数 bug 是我们的，不是模型的。 我手动阅读了最初的几份记录。在看了大约十个几乎相同的失败后，我放弃了，花了一周时间在上面构建一个独立的分析器。基准测试对每次运行进行评分和记录。然后分析器读取这些记录，总结似乎出错的地方，将类似失败分组，并将工程师指向产品的相关部分。 重要的词是“似乎”。分析器产生假设，而非事实，因此仍需人工审查轨迹、追溯源代码、确认失败并决定修复内容。这一人工步骤将“基准测试失败”转变为真正的产品改进，而不是一个自动化的指责机器。 这是一个对记录轨迹进行 map-reduce 的过程。它从上一张图结束的地方开始，使用相同的轨迹文件。它仅以只读源代码方式访问实时产品，以交叉验证其发现。 两个工具之间的交接是单一产物：记录的轨迹。基准测试从不尝试识别根本原因，分析器也从不运行产品。保持它们分离，让人可以使用分析器的线索而无需盲目信任它们。 以下是一周内通过该循环发现并修复的问题代表性样本，限于你无需了解我们提示栈即可理解的缺陷： | 领域 | 出问题之处 | 变更内容 | |------|------------|----------| | 文件处理 | 二进制上传可能导致 LLM 请求崩溃，即使文件已在沙箱中可用。 | 将这些文件保留为沙箱引用，而不是尝试内联不支持的 MIME 类型。#5623（https://github.com/archestra-ai/archestra/pull/5623） | | 沙箱输出 | 输出包含 NUL 字节的二进制数据，可能使 Postgres 持久化崩溃并终止对话。 | 保存沙箱输出前去除 NUL，并警告模型不要将原始二进制流输出到 stdout。#5697（https://github.com/archestra-ai/archestra/pull/5697） | | 沙箱工具 | 事件任务常以 zip 文件到达，但沙箱镜像未包含 `zip` 或 `unzip`。 | 添加 `zip` 和 `unzip`，以便 Chat 可直接检查归档。#5707（https://github.com/archestra-ai/archestra/pull/5707） | | 智能体运行时 | 某些回滚重复同一工具调用数百次，直至无答案结束。 | 检测重复工具调用循环，并在达到固定上限后停止。#5756（https://github.com/archestra-ai/archestra/pull/5756）、#5786（https://github.com/archestra-ai/archestra/pull/5786） | | 提供商后端 | 某一提供商返回了我们的 API 架构未识别的 `finish_reason` 字符串，导致轨迹回放失败。 | 保留任意提供商结束原因，而不是拒绝该交互。#5780（https://github.com/archestra-ai/archestra/pull/5780） | | 基准测试工作台 | 共享基准测试通道和数据库连接使得真实产品失败与工作台噪声难以区分。 | 将基准测试移至专用 Postgres，按项目隔离通道，使文件冲突显式化，并阻止临时认证故障显示为致命错误。#5749（https://github.com/archestra-ai/archestra/pull/5749）、#5787（https://github.com/archestra-ai/archestra/pull/5787） | | 沙箱引擎 | 罕见的沙箱引擎崩溃可能毒化后端进程，而孤儿子进程持续重击引擎。 | 将崩溃视为可重试，重新生成会话，收割子进程，并添加保活检查。#5797（https://github.com/archestra-ai/archestra/pull/5797）、#5801（https://github.com/archestra-ai/archestra/pull/5801） | 这些修复来自于通过同一产品界面运行数百次回滚，而非工程师手动点击 Chat。单元测试和集成测试仍然必要，但它们很少在一条路径中同时测试文件、工具、沙箱、提供商怪癖和持久化，而且无法带来足够的变化以覆盖非确定性系统。 ## https://archestra.ai/blog/we-debug-our-ai-harness-on-weak-models-on-purpose#so-which-models-held-up-open-weight-vs-frontier-results 那么哪些模型扛住了？开放权重 vs. 前沿结果 与客户交流时我常被问到的问题：我们是否真的需要为每个座位预算高级模型？ 当出口管制迫使 Anthropic 在六月暂停 Claude Fable 5 的访问（https://www.anthropic.com/news/redeploying-fable-5）时，我们打赌每个曾推广 AI 的高管都有同样的想法：接下来什么会被切断，对谁？三周后访问恢复，但那个盒子不会关闭。你不必使用那个模型就能看到风险——现在没人能对此视而不见。条款变化、访问被撤销、区域被地理围栏、价格波动。开放权重模型（https://archestra.ai/blog/os-models-for-enterprise-agents）——你可以自己运行，而不是依赖某家供应商的许可凭证——是显而易见的对冲工具。 但一个不可信赖的对冲不是对冲。因此我们测试哪些更便宜、自托管的模型能处理真实员工任务。这是基准测试的第二个轴：我们在从高级 API 到小型开放权重模型的模型上运行相同任务。 结果与我们预期的一致——一个在你已能验证之处与现实相符的基准测试，在你无法验证之处也可以信赖。 以下每个模型都针对最新的日构建运行了相同的 26 个任务。不同构建之间的小变化可能会引入一些方差；我们这里不追求完全确定性。 对于我们日常名单上的模型，我们报告了在相同冻结任务集上连续七次日运行的平均通过率，以及运行之间的典型变动。前沿模型在同一天、相同任务上运行一次，并相应标注。 | 模型 | 开放权重 | 通过率 | 日间波动（百分点）¹ | 套件成本² | |------|----------|--------|-------------------|-----------| | Claude Sonnet 5 | | 100% | 单次运行 | $19.95 | | Claude Opus 4.8 | | 96% | 单次运行 | $27.60 | | GPT-5.6 (sol) | | 96% | 单次运行 | $7.50 | | GPT-5.6 (terra) | | 96% | 单次运行 | $3.93 | | Qwen3.7 Plus | ● | 94% | ± 2 | $0.57 | | Sakana Fugu-Ultra | | 92% | 单次运行 | $27.69 | | GLM-5.2 | ● | 91% | ± 7 | $1.23 | | DeepSeek V4 Flash | ● | 88% | ± 7 | $0.34 | | Claude Fable 5³ | | 88% | 单次运行 | $46.17 | | Xiaomi MiMo v2.5 | ● | 86% | ± 4 | $0.27 | | Qwen3.6 27B | ● | 85% | ± 4 | $1.19 | | GPT-5.6 (luna) | | 81% | 单次运行 | $1.62 | | Qwen3.6 35B-A3B | ● | 71% | ± 10 | $0.82 | | Claude Haiku 4.5⁴ | | 68% | ± 6 | $7.82 | | Gemma 4 31B | ● | 45% | ± 8 | $0.57 | | GPT-5.4 nano | | 12% | ± 6 | $0.37 | | GPT-5.4 mini | | 9% | ± 3 | $0.90 | **注释** ¹ 7月3日至9日连续七次日运行的标准差。在26个任务套件中，每个任务约值4个百分点。因此±7意味着典型运行与平均值相差约两个任务。“单次运行”表示一次测量，而非稳定均值。 ² 通过 OpenRouter（https://archestra.ai/blog/openrouter-with-archestra）完成一次完整26任务运行的成本。 ³ 干净的重新运行。当天早些时候因工作台错误导致引导失败，因此排除。 ⁴ 平均