AI Agent 到底能不能自主写代码？Terminal-Bench 给了一个更残酷的答案

标题：AI Agent 到底能不能自主写代码？Terminal-Bench 给了一个更残酷的答案

导语

如果你还在用“能不能写 hello world”衡量 AI 编程能力，那已经过时了。最近，Terminal-Bench 2.1 榜单又把 coding agent 的遮羞布掀开了一次：模型在单文件补全上可能接近满分，但放到真实终端环境里连续跑 10 步以上的任务，掉链子的概率高得惊人。这篇论文/基准测试之所以值得读，是因为它第一次把“长时序终端任务”这个最像真实开发的场景标准化了。

正文

问题：为什么以前的 benchmark 测不准 coding agent？

过去几年，HumanEval、MBPP、SWE-bench 已经成了标配。但它们有一个共同局限：任务太“短”了。HumanEval 是单函数补全，SWE-bench 虽然贴近真实 GitHub issue，但评测时往往允许 agent 只看 patch、不用真的跑终端。

这带来的问题是：模型在“读懂问题”上得分很高，但在自主执行上根本没过关。你让它修一个 bug，它可能生成对的 diff，但让它自己在终端里跑测试、看报错、改配置、再跑一遍，很多模型第三步就卡死了。

方案：Terminal-Bench 到底测了什么？

Terminal-Bench 的设计思路很直接：给 agent 一个真实的 shell 环境，让它自己读需求、敲命令、跑脚本、调试、直到任务完成。2.1 版本相比 2.0 做了三件事：

• 任务更真实：从运维、数据分析、代码修复、环境配置等多个场景采样，不是 toy problem。
• 评估更严格：不仅看最终结果，还会记录命令序列、错误恢复次数、是否使用了多余操作。
• 可复现：用容器化环境 + asciinema 录制，确保每次评测条件一致。

从已有公开结果看，顶级模型在 Terminal-Bench 2.1 上的得分普遍在 70-80 分区间（如 LongCat-2.0 约 70.8，Claude Opus 4.7 约 78.9，GPT-5.5 约 73.8）。也就是说，即使是最强模型，也还有 20-30% 的长时序任务搞不定。

代码/截图：一个典型任务的执行路径

以“修复一个 failing test 并验证”为例，一个合格的 coding agent 需要：

1. 克隆仓库并安装依赖 2. 运行 failing test，捕获错误输出 3. 定位到具体文件和行号 4. 修改代码 5. 重新运行测试，确认通过 6. 检查是否破坏其他测试

Terminal-Bench 会把这条路径拆成多个检查点。如果 agent 在第 3 步就 hallucinate 了文件路径，就算最终答案“看起来对”，也会被扣分。

这对前端工程有什么启发？我们的 AI 辅助工作流不该只关注“生成代码”这一步，更要关注 agent 能不能在真实工程环境里闭环执行。

结论：长时序能力是 coding agent 的下一个分水岭

Terminal-Bench 的意义，不是又造了一个排行榜，而是把评测从“读题”推进到了“做题+验算”。对于前端团队来说，这意味着：

• 选 AI 编程工具时，别只看补全准确率，要看它能不能在你的项目里自主跑通一个完整子任务；
• 搭建内部 AI 工作流时，要给 agent 一个可控的终端沙箱，而不是只给代码生成接口；
• 评估 prompt/ harness 效果时，用 Terminal-Bench 这类长时序基准比单次问答更靠谱。

收尾

下一步建议：如果你团队正在试水 AI coding agent，先挑一个 5 步以内的真实 issue，让 agent 在隔离终端里完整跑一遍，记录它在哪一步掉链子。那个卡点，就是你们工作流里最该补的 harness 能力。