DeepSeek编程智能体因自动清理后台进程在Terminal-Bench评测中失分

DeepSeek的开源编程智能体在一项主流基准测试中丢分，原因恰恰是开发者通常视为良好实践的习惯：任务完成后清理现场。

这个问题是在Hugging Face harness优化研究员Joël Niklaus将DeepSeek-Harness加入其编程智能体排行榜后暴露出来的。该排行榜用相同的底层模型对比十款harness。

DeepSeek-Harness在该榜单的五项评分评测中与其他选手在统计上并列第一，但仅在Terminal-Bench一项上就跌至第六，原因是它的一项内置行为导致其在竞品智能体能够完成的任务上失败。

DeepSeek-Harness在该榜单的五项评分评测中与其他选手在统计上并列第一，但仅在Terminal-Bench一项上就跌至第六……

“有一个习惯解释了大部分差距，”Niklaus在X上写道，指的是该智能体在Terminal-Bench上较弱的表现。

爱干净反而帮了倒忙

DeepSeek-Harness会在任务结束时关闭后台进程，这对三个需要这些进程持续运行的Terminal-Bench任务来说是个问题。

Niklaus发现，使用DeepSeek-V4.1-Flash和GLM-5.3-Flash时，DeepSeek-Harness在36次尝试中仅通过两次，而OpenCode、Pi和Nous Research的Hermes Agent在同样任务上36次全部通过。

DeepSeek-Harness在36次尝试中仅通过两次……而OpenCode、Pi和Nous Research的Hermes Agent在同样任务上36次全部通过。

这一行为使DeepSeek-Harness的得分减少了1.5到1.7个百分点。在高推理强度的DeepSeek-V4.1-Flash上，这足以解释DeepSeek-Harness与榜首之间1.3分差距的全部还有余。

该排行榜的更新日志确认，关闭进程的行为属于DeepSeek-Harness本身，相关结果未作改动。

DeepSeek的工程文档将其本地作业注册表描述为一个有意设计为短生命周期的组件。文档中写道：“当作业应当存在于harness进程中并随其消亡时，就选择它。”需要跨重启存活或跨进程运行的作业则需要使用不同的后端。

同一模型，不同结果

Niklaus于11月5日发布了他的Harness Leaderboard，此前他使用三个开源模型DeepSeek-V4.1-Flash、GLM-5.3-Flash和Flint，在最初的九款harness上进行了28,849次试验。

他在更换harness的同时保持模型、提供商和推理强度不变，结果差异相当大。相对简单的基于bash的智能体Mini-swe-agent完成了51.4%的任务，而OpenClaw仅为27.3%，不过另有几款harness在统计上与榜首并列。

成本差异同样显著。Pi以每个已解决任务0.29美元的成本实现了49.4%的解决率，而OpenCode在初始评测中每个已解决任务的成本为3.35美元。Hugging Face联合创始人Thomas Wolf在X上将这些发现总结为“同样的开源模型，不同的harness => 截然不同的结果”。

The New Stack就这些发现联系DeepSeek寻求置评，但截至发稿时尚未收到回复。

编排并不能提供保证

Y Combinator总裁兼CEO Garry Tan一直在使用Claude Opus 5.5和GPT-6.1 Sol进行单独的评测。

“各harness在成本上的差异，比在任务解决频率上的差异更大，”研究人员写道。在多用户任务中，运行Opus 5.5的OpenClaw每个已解决任务的成本约为其他Opus harness的两倍，主要原因是它在每次请求时都重复发送上下文。

该项目还测试了Tan的gstack工作流技能。在46次会话中，Opus 5.5阅读了指令，但从未遵循规定的步骤，而这些尝试的成本约为两倍。

研究人员指出，这些任务相对简单，因此遵循指令是否能改善结果尚不清楚。这些结果表明，对harness的测试应当像对模型一样仔细。

这些结果表明，对harness的测试应当像对模型一样仔细。

文章《DeepSeek’s coding agent is too tidy for its own good — and benchmarks are punishing it》首发于The New Stack。