Niklaus Harness 排行榜测试 Kimi Code、Hermes、Pi、Claude Code 和 Codex，超越品牌排名

Joël Niklaus 在 28,849 次试验中比较了九种编程代理 harness，对“选定模型就决定性能”的看法提出了挑战。Niklaus harness 排行榜在控制底层模型和推理设置的同时，评估引导模型开展工作的软件。其初步结果显示，多款知名工具的准确率处于相近区间，而效率和可重复性的差异使得任何“赢家”都难以下定论。

这项比较涵盖 Kimi Code、Hermes Agent、Pi、Claude Code、Codex、OpenCode、mini-swe-agent、Qwen Code 和 OpenClaw。harness 是管理 AI 模型指令、工具和执行循环的软件。在这里，这层外围软件成为被检验的变量。

核心矛盾在于产品声誉与特定受测配置实际表现之间的差异。这些结果并不能证明 Claude Code 或 Codex 在使用其默认模型时具有普遍优势。它们考察的是不同 harness 在受控条件下运行选定开源模型时的表现——这是一个范围更窄、却会对开发者带来实际影响的问题。

Niklaus Harness 排行榜实际比较什么

该实验将周边代理软件单独隔离出来，而非把每款编程产品视为不可拆分的整体。

Niklaus 在发布说明中表示，这项比较固定模型、提供商和推理强度，仅改变 harness。每项任务进行三次尝试。初步评估涵盖 GLM-5.3-Flash、DeepSeek-V4.1-Flash 和 Flint，使用 Terminal-Bench 2.1 及 DeepSWE。

这一设计很重要，因为常规产品比较往往会同时改变多个变量。开发者切换编程助手时，可能同时改变模型、指令、可用工具、权限和执行行为。如此一来，性能差异便难以归因。

发布说明称，mini-swe-agent 在这三种模型上的平均解题率为 51.4%，而 OpenClaw 为 27.3%。Niklaus 还表示，另外四种 harness 在统计上与领先结果并列。这些数字描述的是初始发布情况，而非永久排名。

其按模型划分的发现进一步复杂化了总体平均值。据 Niklaus 介绍，mini-swe-agent 在 GLM-5.3-Flash 上领先，Hermes Agent 在 DeepSeek-V4.1-Flash 上领先，Kimi Code 则在 Flint 上领先。因此，排序取决于开发者计划运行哪种模型。

直接含义有限，但影响重大。一种在某模型上表现良好的 harness，并不会自动从另一模型中获得同等的相对性能。总体得分可以帮助筛选候选方案，却可能掩盖实际部署中更关键的模型与 harness 配对。

Terminal-Bench 评估代理在终端环境中执行任务的能力，软件会执行命令并与文件交互。DeepSWE 则提供了另一项软件工程评估。两者结合拓宽了比较范围，但汇总结果并不意味着这些任务集可以代表所有开发工作流。

该实验的结论也需要标注日期。在本文核查时，在线应用显示版本为 v0.1.2。其当前说明提到会检查等效提供商，而非仅重复初始发布中“固定提供商”的表述。

这一差异值得关注，因为基准测试可能会在首次发布后演变。新的 harness 版本、额外试验或修订后的控制条件，都可能改变截图所表达的含义。即使当前榜单呈现不同排序，发布时的数据仍然是关于发布配置的证据。

因此，对于看到原始 Reddit 讨论的读者，关键修正是理解其范围：这是对选定 harness 与模型组合的比较，而非对所列产品名称关联的每项功能、订阅体验或默认配置进行全面测试。

编程代理厂商面临解释完整配置的压力

这些结果对“将代理性能完全归因于其底层模型”的说法构成了压力。

对于 harness 开发者而言，这项比较让实现层面的选择更加可见。指令、工具接口、重试行为和停止决策都会塑造模型所执行的工作。即使模型很强，也仍可能受到负责引导它的软件所带来的阻碍。

对于模型提供商而言，同一实验带来了归因难题。某模型在特定代理中的不理想结果，并不能证明模型是唯一原因。反过来，强劲结果也不能证明所有使用这些权重的应用都能复现该表现。

对于企业买家而言，这改变了有意义的评估应当说明什么。若配置选择会影响结果，仅列出模型和助手并不足够。买家需要足够的信息来理解受测组合，并复现与其工作相关的行为。

一个假设性的维护任务可以具体说明这一差异。代理可能需要检查代码仓库、识别失败的测试、修改函数，并验证改动。每个阶段都取决于 harness 如何提供信息并管理行动顺序。

如果代理在编辑后未运行相关测试便停止，一个看似合理的补丁仍未经验证。如果它持续执行无效命令，完成工作就会更慢，也更耗费资源。这些都是运行层面的差异，即使底层模型没有变化。

这并不能证明是哪一种实现导致了特定排行榜结果。要做到这一点，需要检查执行记录并测试干预措施。但它解释了为何这种受控比较提出了一个仅凭模型排名无法回答的有价值问题。

发布结果也为熟悉的 Claude Code vs Codex 讨论划定了边界。这些产品名称通常代表围绕特定模型家族构建的完整体验。用选定开源模型测试它们的 harness，提出的问题不同于比较这些完整体验。

在这项实验中排名较低，并不能证明某产品的默认服务表现不佳。排名较高，也不能证明其在代码审查、交互式协作或组织特定工作流中更具优势。这类说法需要直接衡量这些活动的评估。

Kimi Code 基准测试结果同样存在这一限制。它在 Flint 上的领先表现支持在受测条件下进一步考察这一组合，但并不能证明它在无关模型或代码仓库中也具有普遍优势。

对于厂商而言，建设性的回应是公开配置，并解释影响结果的变更。买家便可区分模型升级与 harness 改进，从而更容易评估性能主张，也更容易调查失败原因。

对于通过可互换代理软件运行开源模型的团队，这种压力尤其重要。他们的采购决策包含执行层，需要了解这一层实际带来了什么，而非完全依赖知名产品名称。

相近的准确率可能掩盖不同的运行行为

接近的准确率结果，仍可能在资源使用、延迟和一致性方面存在显著差异。

当前榜单将多项指标分开呈现，而非将准确率作为完整答案。其评估方法说明会对模型使用量进行外部测量，并区分模型处理时间与运行代理所花费的时间。这些差异有助于解释为何相似的解题率会产生不同的运行体验。

榜单还将准确率与成本作图比较，并标出帕累托前沿，即在两项展示指标上均未被任何竞争者超越的选项集合。这让读者能够检视相互竞争的优势，而无需假定最高准确率总是更可取。

当组织拥有固定工作量和有限资源时，这种框架尤为重要。对于需要尽量少人工监督的困难任务，微小的准确率优势可能很有价值。但如果这种优势要求在常规维护工作中投入大幅增加的执行时间，它的吸引力可能随之下降。

效率结果同样需要解读。较低支出不一定意味着代理推理更有效。它可能反映出尝试次数更少、更早终止、输出更短，或采用了不同的工具使用模式。执行记录有助于区分有效克制与过早失败。

同样，较长的执行时间也不能证明存在浪费。代理可能投入额外精力检查补丁，或从失败路径中恢复。关键问题在于，这些额外工作是否改善了团队真正重视的结果。

这也是为什么按每次尝试和按每次成功结果报告资源使用量，回答的是不同问题。一次廉价的失败尝试依然是失败。当人工补救本会主导工作流时，一次要求更高但成功的尝试仍可能是更好的选择。

这些属于评估考量，而非对榜单上每种 harness 已得到证实的解释。图表可以揭示值得调查的模式，却无法仅凭自身识别出导致该模式的指令或工具行为。

其机制在原则上很直接。代理接收信息、选择行动、观察结果，然后决定下一步。harness 控制这一循环的重要部分，包括哪些工具可用，以及工具响应如何传递给模型。

设想一个因环境问题而构建失败的代码仓库。反复编辑应用代码的代理可能消耗资源，却无法解决原因。另一种配置或许能识别环境问题，并重新调整调查方向。

这种差异关乎任务执行，而非模型的原始知识。要证实这一解释，需要将观察到的行为与结果对应起来。若没有这种检查，称某种 harness “更聪明”便超出了证据所能支持的范围。

因此，Niklaus harness 排行榜支持的是比单一“赢家”标签更具体的比较。开发者可以询问：哪些组合能在其工作负载可承受的资源使用方式下达到可接受的准确率。对于交互式开发和无人值守运行，答案可能不同。

它也改变了阅读 Kimi Code 基准测试标题的方式。模型特定的领先表现是进一步评估的有用信号；若不了解失败尝试、执行时长和产生得分的行为，其信息仍不完整。

出于同样原因，Claude Code vs Codex 的比较应保留受测语境。这些名称可以提供定位，但配置决定了结果实际描述的内容。

可重复的成功不同于偶尔的成功

一个只能间歇性完成任务的智能体，与能够稳定完成任务的智能体，所对应的部署主张并不相同。

Niklaus 随后强调了重复尝试中的可靠性。根据他的可靠性拆解，mini-swe-agent 平均每次尝试可完成 51.4% 的任务。三次尝试中至少成功一次的比例为 68.6%，但每次尝试都成功的比例仅为 33.0%。

这些指标回答的是不同的运营问题。平均值反映跨多次尝试的表现；至少成功一次反映重复机会最终是否能产出解法；每次都成功则衡量在这些尝试中的一致性。

当人们观察智能体工作时，这一区别就变得重要。开发者可以检查一次失败的尝试、调整指令，或判断是否值得再次运行。人工监督能让间歇性成功具备实用价值，但监督所花费的时间仍是工作流的一部分。

无人值守的流程则面临不同约束。除非周边系统实际运行替代方案并能识别其质量，否则它不能假定存在一次成功的替代尝试。重复尝试需要选择方法、执行预算，以及处理未解决失败的机制。

这使得偶尔成功的得分难以替代一致性指标。它可以表明某种配置在某些条件下能够找到解法，但无法证明该配置能在需要时可靠地交付这一解法。

Niklaus 报告称，在所引用的比较中，有五个 harness 在每次尝试中都完成了 32.0% 至 33.3% 的任务。他认为这些结果过于接近，难分高下。这支持人们避免在领先组内部提出过于精确的胜者断言。

可靠性数据也需要附带其限制条件。三次尝试只能证明该实验中的可重复性，无法确立在不断变化的代码仓库、依赖项、权限和用户指令环境下的生产失败率。

同样，基准测试中的失败也不会自动转化为有害的生产操作。评测器衡量的是任务是否满足成功标准；实际运营后果取决于智能体能够访问什么，以及其工作周围设置了哪些审批或验证机制。

对工程管理者而言，这意味着要将能力与可靠交付区分开来。一种配置可能有能力偶尔生成正确补丁，却仍不适合无人值守的工作流。这一差距需要额外验证，而不是更有力的营销标签。

假设性的依赖项更新可以说明这种差异。智能体可能在一次运行中成功更新软件包并通过测试，却在另一次运行中遗漏相关配置变更。偶尔成功所能证明的无人值守准备程度，远少于标题百分比可能暗示的程度。

评估这一工作流的团队会关心结果是否可复现，以及失败处理是否清晰。他们还会关心最终变更是否便于审查者理解。这些维度仍然不同于基准验证器是否接受最终状态。

排行榜的重复尝试视角将这种区别带入公开比较。它鼓励读者追问：当智能体必须再次工作时会发生什么，而不是把一次成功轨迹视为产品的完整描述。

基准版本与公开记录限制了胜者主张

已发布的结果是可检验的证据，但它们仍受基准版本、配置及验证完整度的限制。

Terminal-Bench 本身就清楚说明了版本标签为何重要。其2.1 修订版修复了上一版本 89 个任务中的 28 个问题。维护者报告称，这些修复后，代表性智能体模型的得分发生了变化。

这段历史说明，基准版本本身就是主张的一部分。Terminal-Bench 2.0 的分数不能简单视为可与 2.1 的分数互换。即使展示的指标名称保持不变，任务和评估条件已经改变。

同样的原则也适用于 harness。结果属于经过测试的软件版本及其设置。如果一次更新改变了指令、工具执行或终止行为，那么此前的分数描述的是此前的实现。

这为快速演变的公开讨论带来挑战。排行榜变动后，图表仍可能继续传播，而评论仍将其视为当前信息。读者需要原始配置和测量日期，才能判断该图像如今仍能证明什么。

该项目的公开运行记录为核查这些细节提供了途径。记录可用是一种透明度优势，但其公开并不意味着每项结果都已经过独立复现或完整的人工审查。

独立复现需要执行指定配置，并检查相关模式是否持续存在。阅读记录可以支持审计所报告的计算结果或个别行为。这些活动提供的是不同类型的证据。

因果问题仍然尤其棘手。分数差异可以识别出受控条件下配置与结果之间的关联。要解释这一差异，则需要检查失败案例，并测试某项拟议变更是否会改变它们。

例如，若怀疑存在超时问题，应在保持其他相关条件不变的前提下调整超时时间进行测试。若怀疑存在信息丢失问题，则需要检查哪些信息消失，以及保留这些信息是否能改善结果。两种解释都不会仅凭较低排名自动得出。

基准熟悉度带来了另一项值得调查的担忧，但不应预设存在不当行为。针对公开任务优化的系统，可以在该任务分布上取得提升，却未必能在其他场景获得同等提升。来自陌生任务的证据将有助于判断这种增益的迁移范围。

任务覆盖范围构成另一项限制。代码仓库维护涉及组织惯例、模糊请求和人工审查预期，而固定基准无法完全涵盖这些因素。基准依然可以有用，同时仍无法解决这些部署问题。

务实的回应是让证据与决策相称。公开结果可以证明建立候选清单或开展针对性试用是合理的；要替换团队的开发工作流，则需要来自与该团队实际职责相似工作的额外证据。

将配置、失败示例和审查决策保存在一起，能让这些比较更易于回顾。可搜索的知识库可以帮助保留这类评估历史，并与测试期间使用的技术文档一同存档。

验证缺口并不会抹去实验的价值。它界定了当前结果能够支持什么，以及还需要哪些工作来增强其说服力。相比逐字接受每个排名或完全否定这项比较，这是一种更有价值的解读方式。

下一步测试应追踪更新、复现与无人值守工作

最有力的后续证据，将把版本变更与超出初始比较范围的工作中的可复现改进联系起来。

首先应关注的是带有清晰版本历史的更新后 harness 性能。当开发者修改执行软件时，可比较的重新运行能够显示准确率、效率或一致性是否发生变化。保留此前配置，才能使这一比较具有意义。

如果改进能够跨重复测量持续出现，将增强 harness 工程实质性影响结果的论据。如果某项结果在可比较的重新运行中消失，则会削弱对所宣称增益的信心。无论哪种结果，提供的信息都多于一个更新后的胜者徽章。

这也为供应商提供了建设性的回应方式。他们可以识别一种失败模式，解释相关实现变更，并发布关于结果的证据。读者随后便能评估一项具体的工程主张，而非从产品声誉中推断质量。

第二个信号是具备匹配控制条件的独立复现。独立评估者应记录模型、提供商条件、推理设置、任务版本和 harness 版本。差异需要保持可见，而不是被纳入一个看似相同的分数中。

如果独立结果保留了大致排序或模型特定的模式，人们对该比较的信心就会提高。如果结果出现分歧，则说明某些条件需要进一步审查。提供商行为、执行设置和测量细节会成为研究问题，而非方便的解释。

复现并不要求每个数字都完全一致。关键在于结论能否经受合理的重复测量。除非有额外证据支持加以区分，否则接近的结果应当仍被视为接近。

第三个信号，是在陌生工作上依据明确的无人值守成功标准衡量表现。这意味着检查智能体是否完成了所请求的任务、验证了结果，并妥善处理失败。应记录人工干预，因为它会改变“自主完成”的含义。

如果在这类工作上持续改进，将增强排行榜发现的实际重要性。如果收益仅局限于熟悉的基准任务，其相关性就会缩小。对于部署而言，这一区别比总体平均值的又一次小幅变动更重要。

对于现在选择软件的团队而言，现有证据支持在实际配对层面进行比较。Kimi Code、Hermes Agent、Pi、Claude Code、Codex 和 mini-swe-agent 都值得在团队计划使用的配置中接受评估。仅凭名称无法决定结果。

Niklaus 的 harness 排行榜为这种评估提供了公开起点，包括发布结果、重复尝试和可访问记录。它的长期贡献将取决于这些测量是否有助于解释并改善智能体行为。

在改变编码工作流之前，应使用具有代表性的维护工作，将入围配对与自己已经信任的设置进行比较。记录精确配置、完成证据、审查者投入，以及需要干预的失败情况。纳入那些仅有看似合理的补丁、却未完成验证步骤仍不足以成功的任务。在一次有意义的 harness 更新后重新进行比较，并保留此前结果，以便理解变化。将公开排行榜视为这项决策的证据，同时让自己的工作流拥有最终决定权。值得回答的问题应当具体：在你实际能够提供的监督条件下，哪种经过测试的组合能交付你的团队可以验证、复现并接受的工作？