我用约970行Python构建了一个编码代理并诚实地对其进行了基准测试

我用约970行Python构建了一个编码代理并诚实地对其进行了基准测试

原文：https://dev.to/troyjl_/i-built-a-coding-agent-in-970-lines-of-python-and-benchmarked-it-honestly-3jjf

TL;DR：我用大约970行非空Python代码（5个文件、3个工具、2个提供商、MIT协议）构建了nano-harness编码代理。它在完整的Terminal-Bench 2.0套件上使用Claude Opus 4.8获得了59.6%（53/89）的分数。过程中，一个独立的前沿模型（GPT Sol 5.6）审查了代码并给出了4/10的评分，这最终成为项目中最有价值的事情。这就是关于分数、bug以及所有出问题环节的完整故事。

我为什么要构建一个harness？

二月份，我开始从Andrej Karpathy那里了解harness……我记得他的llm-wiki刚走红，我看到了这个仓库。于是我阅读了它，并开始深入研究harness和循环。那是在所有人都在谈论循环和harness、每个YouTube视频都在讲提示词等等之前。我想学点新东西，当时正在用Azure Machine Learning训练自己的模型（这花了我一大笔钱），然后用PyTorch在我的AI操作系统中学习模式。总之，我关注的大多数代理项目都以功能为主：插件、编排图、UI仪表盘、记忆系统（他们的Obsidian"第二大脑"）——全都千篇一律。我很难找到小巧、可读的harness，同时附带可复现的全套基准测试分数（如果你了解基准测试harness的成本，就知道这绝不便宜！）。这让我印象深刻，我不明白为什么没更多人讨论这个——对我来说，这是所有发展的方向，而harness是代理中你真正可以工程化的部分，所以也是你应该能够编码和衡量的部分。

因此，nano-harness的核心理念是每行代码的分数：最小的可读harness，仍能在真实基准测试上给出真实数字。可以把它想象成Karpathy的nanochat，但针对代理harness——小到可以一口气读完，诚实到数字有意义。

我最初的目标是大约500行代码，在真实编码基准测试上达到45%以上并持续进步。至少对我来说，这将是一个挑战。

~970行代码能带来什么

整个harness是一个循环和三个工具：

• bash - 持久化shell（cwd、env和状态在调用之间保持）
• read_file - 带行号和切片的读取
• edit_file - 精确唯一匹配字符串替换

仅此而已。没有嵌入、没有规划器、没有子代理。bash涵盖了ls、grep、build、test和install。模型负责编码；harness只有一个任务：保持运行存活并保持诚实。

"存活"意味着：重试临时API故障、在上下文窗口耗尽前截断历史、在输出在工具调用中途被截断时推动继续、在挂起时杀死并重新生成shell、将每个异常转化为结构化结果而不是崩溃。

"诚实"意味着：失败的命令必须显示为失败，"完成"必须经过验证。关键部分是验证门控。一旦运行使用了工具，第一个"完成"会受到挑战：重新读取任务、运行相关检查、证明它。只有当自那次挑战以来出现了成功的工具证据时，后续的完成才会被接受。如果推回或迭代预算耗尽而没有该证据，结果将作为未验证返回，因此不算成功。无工具任务（纯问题）允许正常完成；没有什么需要验证。

基准测试曲线：20% → 80% → 53.9% → 59.6%

我通过Harbor在Terminal-Bench 2.0上进行了基准测试——89个任务，每个都在独立的Docker容器中，每个容器都安装了确切的发布版harness。我的进展顺序如下：

最终运行：16.5小时，两个任务并行，错误试验算作失败（最重任务的10个挂钟超时加上一个容器OOM都算在我头上）。

公开的Terminal-Bench结果是代理-模型配对，因此模型质量和harness质量在每个数字中都纠缠在一起。官方2.0排行榜上领先的是Codex CLI + GPT-5.5（82.2%）和WOZCODE + Opus 4.7（80.2%）等。我找不到我确切模型在该表中的验证条目，所以我不打算把59.6%粉饰成"harness差距"的干净测量。这是我在本文披露条件下自行运行的结果——一个~970行的harness，而经过调优、大得多的harness在相同套件上使用代码和任务级记录（仓库中提供，供任何人检查）处于80%低位。

说实话，我为过去3.5个月投入的所有工作感到自豪——同时担任高级工程师、托管一个有活跃付费用户每日更新的API、运行一个没有任何营销（除了几个Reddit帖子）却有100个活跃用户的免费Web应用。每晚熬夜到凌晨2/3点，早上5点起床……这并不健康，我确实因为睡眠不足和久坐（尽管每天锻炼）而经历了一次健康恐慌。但我认为我们都可以承认，现在学习不仅更容易、更有趣，而且有了AI，如果你错过一天，你会感觉像离开了一个月。当遇到像过去几周那样模型接模型、基准测试接基准测试的时期时，可能会让人不知所措。除此之外，我只能在现有条件下工作——我没有Mac Mini或NVIDIA SPARK，我买了Beelink SER 10 MAX OpenClaw版64GB，因为这是我预算范围内唯一可用的64GB设备。天哪，我真希望有一台好的迷你PC来运行本地模型并测试我想要的东西。回到Harness。

GPT Sol给我的代码打了4/10分

这是我真的想告诉你的部分。我只想让每个人都明白，这些前沿模型所获得的基准测试分数，它们使用的harness有数千甚至数万行代码……

在第一次完整基准测试运行后，我把五个核心文件粘贴到了GPT Sol中，因为它刚发布，而我已经进行了13小时的第一次运行。我用opus 4.8包装了我的harness，使其成为"竞争对手"——没有共享上下文——并要求进行对抗性/建设性代码审查。它给代码打了4/10分，并生成了一系列发现。最关键的发现也是最好的捕捉：

一个失败的shell命令被报告给模型为成功。

我的bash工具捕获了输出但没有捕获退出状态。false、失败的测试套件、没有匹配的grep——所有这些看起来都很干净，我感觉自己像个白痴（……肯定是那些我半夜把头埋在Keychron键盘里醒来的夜晚……对此我也不高兴）。这意味着我的验证门控——整个"保持诚实"的核心——可能被一个失败的测试运行满足。Harness存在的全部理由中间有一个漏洞。

所以我以测试为先的方式处理了这些发现——每个修复在应用之前都有一个失败的回归测试。（既然这是一篇关于诚实的文章：nano-harness是使用大量AI辅助编码构建的。我想你现在已经猜到了，但与大多数人不同，我确保每一步都学到了东西。我指导了工作、做出了决策、运行了每个基准测试和审查，但我没有手动输入全部967行——老实说，我写了大约100行。下面的审查考验使用了三次独立的审查传递，没有共享对话上下文，这有助于发现不同类别的失败。）然后我对结果进行了第二次独立审查传递。它打了6/10分，并发现我的两个修复只是半修复：

• 我将工具调用存储在两个地方，而我的上下文截断传递只缩小了其中一个——因此OpenAI序列化路径悄悄地重新膨胀了我以为已经截断的巨大工具参数。我知道我做了，但一定没有提交那个更改，让它溜了过去。
• 我的CRLF修复保留了统一文件的换行符，但同质化了混合换行符的文件。

修复了这些问题。然后第三轮，一个多智能体云端审查集群发现了两个小问题（客户端API超时的一个遗漏重试情况，以及一个显式JSON空参数绕过了默认值）。两者都已修复。

整个测试流程的总损失：约20个真实漏洞，测试套件从52个测试增长到87个。修复内容包括：

• 非零的shell状态现在会引发工具错误，因此一个简单的失败测试命令不再算作成功的验证证据
• shell的哨兵协议在set -x下仍能正常工作（之前子字符串匹配会锁定跟踪行，并错误地框定后续每个命令）
• edit_file保留文件权限（之前会在Linux基准容器中静默移除编辑脚本的可执行位，这会导致任务失败），通过符号链接编辑而非替换它们，并在混合CRLF/LF文件中保持未修改行的字节一致性
• 进程树终止已验证并回收，超时后不会积累僵尸shell
• 验证门默认关闭：无回退意味着未验证，而非虚假成功

而关键在于——基准测试给我的结果：强化前的测试工具得分为53.9%。强化后的运行（相同模型、相同测试套件）通过了另外五个任务，达到59.6%，提升了5.7个百分点，但也增加了约180行代码。这些是随机单次运行，所以我无法证明每个得分点都来自特定修复。我能说的是：中间的更改是正确性和安全性修复，而非针对任务的基准补丁，并且下一次完整运行得分更高。最大的单一修复是让失败看起来像失败给模型，结果发现当测试工具不再对模型撒谎时，模型表现更好……谁能想到呢……

成本

具体金额我无法精确给出，诚实的原因是适配器中的一个缺口：nano将token使用量记录到智能体的stdout，而不是报告回Harbor的结果模式中，因此运行的摘要JSON中token字段为空。汇总存活的每个任务智能体日志，大约有300万token（约154万输入，约143万输出），由于后续的重试轮次覆盖了其中一些日志，请将其视为估算值而非收据。按Opus 4.8在2026年7月的列表价格（输入$5/M，输出$25/M），整个89任务运行大约需要$45。一个10任务的迭代片段运行一到两小时，大约$4-$6。便宜到瓶颈是实际时间而非预算。

克隆仓库

仓库地址是github.com/TroyJLorents-GH/nano-harness，MIT许可证，约970行非空代码，分布在agent.py、tools.py、providers.py、prompts.py、cli.py中，包含87个测试套件、Terminal-Bench适配器、完整的基准测试细分、重新审查提示以及树中的修复历史。

如果你从中得到一点：测试工具的工作不是聪明——模型才是聪明的。测试工具的工作是保持运行存活，并拒绝让任何人撒谎，包括模型，也包括你。4/10的审查是这一论点变得真实的那一刻。发布整个弧线——糟糕的分数、半修复、方差——才是重点。

如果你审查代码并发现第21个漏洞，请开一个issue。这就是游戏。