OpenHands 用 500 次 SWE-bench 算出来:人 review agent 代码的成本,比模型生产还贵 2.1 倍 一份不太舒服的成本核算 2026 年 8 月 26 日,一篇标题朴素到刺眼的帖子出现在 Hacker News 首页:「I estimate reading code costs 2.1x more than writing it」。作者没有公司背书、没有品牌包装,
OpenHands 用 500 次 SWE-bench 算出来:人 review agent 代码的成本,比模型生产还贵 2.1 倍
一份不太舒服的成本核算
2026 年 8 月 26 日,一篇标题朴素到刺眼的帖子出现在 Hacker News 首页:「I estimate reading code costs 2.1x more than writing it」。作者没有公司背书、没有品牌包装,只有一组冰冷的数字:人类 review 一行代码 $0.243,agent 写出一行「benchmark 接受」的代码 $0.114,前者是后者的 2.13 倍。换句话说,过去两年整个行业在讨论「AI 写代码有多便宜」的时候,几乎没人认真算过「人类验证 AI 写的代码有多贵」。
这个数字之所以值得停下细读,是因为它不是「行业咨询报告里的估算」,而是把两条独立数据集对齐后的实测拼接:agent 端用 OpenHands v1.18.1 + GPT-5.5 在 SWE-bench Verified 上跑满 500 题(全部公开的 token 类别、最终 patch、单任务成本、评测结果),再用 2026 年 11 月前的 GPT-5.6 Sol 公开费率回算;人类端用 SmartBear/Cisco 一份研究覆盖 2,500+ code review、3.2M 行代码,得到 400 LOC/hour 的中位 review 速率,再用 BLS 公布的 May 2025 软件开发者中位时薪 $65.38、March 2026 雇主福利占比 32.7% 反推 loaded hourly cost $97.15。两边拼起来,review 一行 $0.243、agent 写一行 $0.114,差 2.1 倍。
作者还在帖子里做了诚实的 sanity check:500 题里有 1 个 patch(psf__requests-1142)单题改了 16,180 行,占整个数据集成功 LOC 的 76%。这种极端 outlier 会把均值压到 $0.027/LOC,看起来漂亮但实质是数据失真。作者选择了剔除并报告「剔除后 $0.114」,同时把「未剔除 $0.027」也写在下面——这种做法在 Hacker News 上罕见地专业,得到大量正向评论。剔除后,499 次尝试、390 题成功、78.2% 通过率、5,077 行 accepted LOC,token 总消耗 651.27M,折算 GPT-5.6 Sol 公开价 $577.48,每 accepted LOC 成本 $0.1137,每 accepted LOC 消耗 128,279 token。
数据里没说出来的工程含义
把这两组数字摊开看,有几个反直觉但对企业决策至关重要的推论。
第一,review 成本里 LLM 调用本身只占很小一部分。 OpenHands 这 500 题总共花了 $577.48 模型费,但 5,077 行 accepted LOC 意味着模型在「没写出来」的事上浪费的钱大概占总费用的 22%(按作者后文的剔除逻辑反推)。也就是说「让 agent 写得便宜」这件事,边际收益已经基本走到头——下一步不是把模型费再压 50%,而是让人类不再 review 这么多行。
第二,review 的瓶颈不是 bug 检测,是上下文重建。 紧随这篇帖子两天后,8 月底 Hacker News 上出现了另一篇 Ask HN:「What tools are you using for human code review of AI-assisted code?」。原帖直白地描述了作者正在面对的现实:agent 把代码产出速度提升了 10 倍,PR 越来越大、越来越频繁,但 GitHub 的 PR 界面是为「小型 PR、少数 reviewer」设计的,当 PR 变成上千行、跨十几个文件、人 + agent 评审结果混在一起时,reviewer 大量时间不是花在「找 bug」上,而是花在「重建代码意图、还原数据通路、判断架构是否合理」上。这是典型的「输出端革命、输入端没跟上」的瓶颈错位——agent 让生成便宜了 10 倍,但人类理解的成本几乎没变。
第三,LLM-based review 工具目前只能补 30% 的缺口。 上面那个 Ask HN 帖的评论区里,joshgachnang 给出了真实生产数据:Cursor 的 BugBot 对 medium/high 级别 finding 准确率高到他几乎从不反对,GitHub Copilot review 偶有补充但假阳性高到他几次想关掉,自建的 architecture reviewer 用 Claude 跑专攻「重复代码、边界破坏、模块耦合」问题效果明显。taurath 说自己正在搭一组 lens(MCP + GitHub CLI 拉代码 + 不同 lens 模型):metrics、错误处理、可测试性、架构、安全,每个 lens 跑一遍让 reviewer 看见「这个 PR 在哪个维度需要我介入」。这就是 OpenHands 那篇「2.1x」帖子的直接反应——工程师在用各种方式压低 reviewer 自己重建上下文的成本。
第四,review 单元要从「最终 diff」迁移到「决策轨迹」。 评论区里 BonanKou 给出了一个反主流但值得深思的建议:不要再 review 最终 diff,改 review 决策轨迹(plan、assumption、alternatives considered)——只要 reviewer 认同 agent 的决策过程,大概率也认同最终代码实现。ArnaudDebray 提到的 herve.review 就是这条思路的产品化:捕获 AI 开发会话的关键决策,把这些决策作为 reviewer 在 diff 里导航的「指北针」。这种 review 单元的迁移,比任何 review 工具优化都更彻底地解决了 2.1x 的成本错位——把 review 对象从「成品」换成「过程」,人类认知负担降一个量级,review 速度可以再提 3-5 倍。
真正改变成本结构的三件事
把 OpenHands 的数据 + Ask HN 的实战反馈合在一起看,2026 年下半年能真正压低 review 成本的不是「再换一个更准的 review 模型」,而是三件结构性变化。
第一,review 要从「事后门禁」迁移到「过程陪跑」。 传统 CI/PR review 是「agent 写完 → 提交 → reviewer 看 → 通过/打回」,review 出现在价值链最后、决策影响最大,但信息最贫瘠的时刻(只有最终 diff)。如果 agent 在写代码过程中就把 plan、关键 trade-off、模块边界决策以可导航结构记录下来,reviewer 在 review 时看到的不是「成品」而是「带注释的成品」,认知负担直接腰斩。Decispher 的 Branch Story、herve.review、Cursor 的 BugBot 注释,本质都是这条路的不同实现。
第二,review 工具要从「bug bot」迁移到「架构 reviewer」。 joshgachnang 的实测已经证明:Cursor BugBot 在中高级 bug 上准确率足够,但 GitHub Copilot 这种通用 review 模型假阳性高到令人沮丧——原因是通用模型「找错」比「找设计问题」容易。架构层的判断需要 codebase-specific 的 context,需要理解当前模块的设计意图和未来扩展计划,这正是 Decispher 这种"工程上下文平台"在解决的问题。当 reviewer 工具从「找错」升级到「指出架构偏离」,人类 reviewer 就不必再做「高难度识别 + 低难度判错」的双重工作,可以专注「架构判官」角色。
第三,review ROI 的计算公式要重写。 OpenHands 帖子里作者是按「reviewer 时薪 / review 速率」算单行 review 成本,这是 SaaS 时代留下的公式。agent 时代的新公式应该是:「review ROI = (review 拦下的未来维护成本) / (review 当前直接成本)」。一个 5000 行的 PR 跑过 review 投入 $300,但如果拦下了一个 6 个月后会变成 $50,000 重构工作的架构决策,ROI 是 167 倍。review 不再是「找 bug 收费」,而是「预防技术债收费」,这两者的 ROI 计算方法完全不同。
一个悬在行业头顶的合规问题
这两份数据还顺手揭开了一个被严重低估的合规隐患。当前大量企业部署 agent 的代码生成流程,都隐含一个假设:人类 review 覆盖了所有 AI 写的代码。 但 OpenHands 的数据告诉我们,review 成本比生产还贵 2.1 倍——这意味着要么企业接受了「review 不完整、agent 代码裸奔上线」的事实(技术债),要么企业把 review 成本摊到工程师身上(士气消耗)。无论是哪种,在金融、医疗、自动驾驶这类强合规领域,都会撞到审计和监管的红线。
合规的解法不是「让 review 更便宜」(那不是工程问题,那是经济学不可能三角),而是让 review 单元从「最终 diff」迁移到「决策轨迹 + 关键变更」,让 reviewer 在更小的样本上做更有意义的判断。这条路本质上和 OpenHands 数据揭示的趋势一致——整个行业未来 12 个月内最值得投入的产品方向,不是「更快的 review 工具」,而是「让 review 变得不那么必要」的决策可追溯系统。
对企业 IT 来说,这两份帖子合起来给出一个直接的行动建议:未来 6-12 个月里,如果要采购或自建 AI 代码 review 工具,问的第一个问题不是「能不能找 bug」,而是「能不能让 reviewer 少看 50% 的代码就做完高质量 review」。前者是 2024 年的问题,后者才是 2026 年的真问题。