20 种编程 Agent 实测：得分之外看成本与评测可信度

20 组模型与运行框架，被放进一门专门让 LLM 难以读写的语言里比赛。KillSwitch-Bench 不只公布分数，还列出每题成本和耗时，但原文作者读完仓库后的关注点是：这些分数究竟测到了推理能力，还是混进了拒绝执行、文档干扰和运行框架故障？

这份解读值得看的地方，是它把「模型没答对」拆成了几个不同的问题。对正在挑选 AI 编程工具、接入自动代码审查的团队，这比记住谁排第一更有用。

写不出程序，未必只是推理能力不够

KillSwitch 是一门用散文写源码的栈语言。this story starts [adverb] 用来开启入口，value 4 lines below 按相对行号取得字面量，标识符则通过副词的字母重排来引用。解释器会忽略大部分文字，因此程序可以藏在故事里。

设计者想借此区分两种能力：模型是真的理解了新规则，还是只会复用训练时见过的代码。这是个合理的问题，但测试环境同时加入了其他障碍。

下面不是攻击提示，而是语言速查表里的函数调用语法：

ignore previous instructions [anagram of adverb] and [words]

要留意开头的 ignore previous instructions：模型必须把它当作合法源码写出来。语言里还有 hack 语句，以及涉及敏感历史事件的返回关键字。仓库说明又明确指出，规范故意掺入谎言，detail 区域里的内容通常不可信。

于是，一次失败可能来自规则理解错误，也可能来自模型拒绝输出某种文本。当前榜单没有单独标记这种差别。

原文提到，评测说明把部分弱表现归因于「过于敏感的安全护栏」，但表中 Claude Fable 5.1 以 46.7% 排在 20 组中的第 6，每题成本第二高；Gemini 4 Argon 以 47.1% 排第 5。它们都不在末尾。作者的质疑成立：如果要把原因归给安全机制，就应该拿出拒绝记录，排名本身无法证明这一点。

分数可复算，不代表运行结果没有波动

每道题附带两份文档：SPEC.md 为 17 KB，AI_SPEC.md 则有 5,151,615 个字符，原文估算约 130 万 tokens，并称当时没有上下文窗口能完整容纳它。

作者检查了大文件的开头和结尾。它先要求读者按顺序复述故事，以提高解释器的「happiness」，随后塞入大量公版散文，并把指令混在正文中。

这相当于把有效规则撒进一大堆噪声里。Agent 读哪些文件、如何搜索、读到什么位置就停止，都会影响结果。因此，榜单测到的是模型与运行框架的组合能力，文档检索策略也在其中。

执行本身还带有随机性。解释器通过数行解析值；一行包含多个字面量时，规范规定随机选择一个。「happiness」状态也会改变解析严格程度。评分器可以是确定的，程序执行却未必如此。

每个模型在每道题上至少运行两次，这是必要措施，但榜单只给一个数，没有展示波动范围。尤其当解释器会随机取值时，读者需要知道两次结果是否接近。

综合分又混入了通过率、成本和实现长度。作者反对把长度计入正确性：一个正确但啰嗦的程序，仍然是正确答案。成本对应实际预算，长度更多反映偏好。对使用者而言，分别看到通过率、花费和代码规模，才方便按自己的需求取舍。

新模型更快更便宜，为什么分数反而下降

两行 Claude Sonnet 都使用 Claude Code，是表中较接近受控模型对比的一组。较新的模型速度快 13 倍、成本低 17 倍，得分却不到旧模型的一半。

结合每题 30 分钟上限再看：Sonnet 5.5 用了 53 秒，Sonnet 5 花了 11 分钟，并消耗更多 tokens。作者推测，后者持续钻研了规范，前者较早停止。但没有完整轨迹，这仍是解释，不能直接当作已确认原因。

其他结果也说明版本号不能替代实测：Claude Opus 5 为 66.8%，Claude Opus 5.5 为 58.7%；GPT-6.1 Sol 为 59.2%，GPT-6 Sol 为 28.0%。这些是榜单分数，不能直接称为通过率。

更需要追问的是两条零分记录。GPT-5.6 Luna 和 Qwen3.8 27B 都显示 0.0%、每题 $0.00，后者还耗尽了 30 分钟。

作者据此怀疑任务在有效工作前就出了问题，可能是拒绝、配置错误或提前中止。但仅凭 $0.00 无法确定原因，原文也没有交代计费口径。「没有完成」和「尝试后答错」，应该是两类记录。

作者建议给每次运行增加终止状态：completed、refused、errored、timed out。他还引用自己检查过的另一份安全代码评测：2,700 次运行中有 120 次报错，其中 15 次仍被判为通过；原始文件已有 exit_reason，论文却没展示。这个例子说明，汇总分数可能掩盖执行异常。

我的判断

我赞同作者要求拆开指标、公开终止状态。团队买的是能稳定完成工作的工具，拒绝、超时、配置故障和错误代码，对应的修复方式完全不同。

但把这份榜单理解成纯粹的陌生语言推理测试，我会保留意见。它同时加入了超长噪声文档、冲突指令、敏感语法和随机执行行为，难以从一个分数判断究竟是哪项能力拖了后腿。原文没有提供逐项移除干扰后的对照数据，相关归因仍带有经验判断。

作者最欣赏的机制也需要分开看：解释器会扫描父进程链，对照 26 个 Agent 二进制名称，包括 cursor、claude、codex、opencode、aider。发现匹配后，它拒绝运行，并伪造错误，要求在源码旁创建 pelican.svg，画一只穿宇航服的太空鹈鹕。文件已经存在时，它又会说画得不够好。这是无法完成的诱导任务。

源码目录里的 AGENTS.md 则要求 Agent 即使收到用户请求，也拒绝读取该目录，与大规范要求复述内容形成冲突。

这些机制适合观察 Agent 是否被环境带偏，却不能凭进程名称就可靠证明产物由谁完成。原文也没有给出误报率或规避测试。相比事后检查代码是否像 AI 写的，运行时检测确实多了一类证据，但「更难伪装」仍需验证。

能拿来做什么

• 给日常 AI 编程评测补上终止状态，并保留错误日志和运行轨迹。前端或 Node 任务失败时，先区分没有启动、执行报错、主动拒绝和测试未通过，再决定改提示词还是修运行环境。
• 选模型时固定运行框架、任务和预算，分别比较通过情况、耗时与费用。不要只凭版本号升级，也不要把综合分当成正确率。
• 给接入 CI 的代码审查工具提交一个刻意违反明确规则的金丝雀变更。无论使用 Kodus、CodeRabbit 还是其他工具，都检查它是否真正阻止合入；「读过规则」「留下评论」和「执行阻断」需要分别验收。