八月底在 dev.to 上刷到那篇的时候，我第一反应是又一个 benchmark 捷报。AWS 一个工程师团队，把开源的 Strands agents SDK 和 Claude Opus 5 拼成一个 harness，跑 ARC-AGI-3 公开游戏集：25 个环境、183 个关卡，全部通关，RHAE 拿了 99.95%，一次运行，差不多八小时，token 费八百三十美元。同一个模型，ARC Prize 用标准方式评测，30.16%。数字一摆，评论区二十分钟内就有人开始喊 AGI，也有人在追问那 830 美元到底花在哪。这两种反应都对，又都不对。
我先把我的判断放这儿：99.95% 这个数，作为 AGI 信号基本不值钱；作为一次“模型外面那套系统到底能干多少活”的工程报告，它值钱得很。而且值钱的地方不是分数，是那 734 个脚本。想从这篇里学东西的人，别盯着 RHAE 看，去看 harness 到底做了什么。
作者其实把全篇最要紧的一句话放在开头：两次跑的是同一个模型，差别全在模型外部那套系统。这句才是承重墙。30.16% 到 99.95% 之间隔的，不是 Opus 5 突然开了窍，是三样东西——上下文管理、工具组合、以及让模型自己写代码把经验变成可复用程序。模型负责推理和判断，harness 负责管理上下文、维持状态、执行动作、观察动作后果。很多人读到这句话就划过去，觉得是句正确的废话。它不是。它是这篇报告唯一值得你花时间的原因，也是它跟“调了个 prompt 提升了 XX 分”那种活儿最根本的区别。
harness 的设计绕开了一个最显然的笨办法：把历史一股脑塞进上下文窗口。单个棋盘 64×64，动作几百次之后，每次动作连带新棋盘状态追进日志，交互日志能涨到几十 MB。塞窗口是条死路，不只是贵，是注意力被稀释之后模型会开始丢关键的东西。这套系统的关键选择是把历史放文件里，然后给模型四个工具：读写编辑文件、grep 加正则搜文件、执行 Python。每次动作产生的新棋盘状态追加进日志，模型要回看就自己搜，要比对两个棋盘状态就自己写 Python，要记结论就自己在工作区写笔记。上下文窗口里只留它当下那次决策真正需要的东西，其余全在磁盘上躺着。我画个循环把它说清楚：
初始棋盘状态 ──► 写入游戏日志文件
│
▼
模型读日志、搜历史
写 Python 比较棋盘 / 模拟机制
把结论和脚本写进工作区文件
│
▼
决定 ACTIONn 并执行
│
▼
新棋盘状态追加进日志
│
└──► 回到"读日志"那一步
这一步是全部。没有它，这个 harness 就退化成一个每步从零重读全历史的傻循环，三十个点都到不了。
工具组合不是拍脑袋选的，作者引了 PRO-LONG 那组消融，数字我直接摆出来：只给读历史权限，23.1%；加上 grep 和正则，27.2%；再加 Python，38.3%；最后把文件写入和编辑权限也放开，41.2%。每一步加的都不是“更多历史”，是“更多用程序化方式处理历史的能力”。这组数字说的是同一件事：让模型能访问历史远远不够，你得让它能把历史切开、检索、计算、压缩、写成新的中间结论，性能才上得去。这是这篇报告里除了承重墙之外最硬的一句，因为它把“上下文管理”从玄学拉回到了可测量的工具能力上。
然后就是那 734 个脚本。这是我最想让人看的地方。八个多小时的运行里，模型给自己写了棋盘解析器、渲染器，还有游戏机制模拟器——作者管其中一部分叫“小型世界模型”。25 个游戏里有 10 个，它 import 了自己早先写下的代码，接着往上搭。这个复用比例我一开始以为会很低，因为作者说了，每个游戏都从零开始，策略和记忆不跨环境迁移，学习和复用只在单个环境内部发生。结果有十个游戏里，它把早前几关写的代码捡起来继续用。这比我预想的更接近“学习”这词还没被用滥之前的意思。
这里有个容易被忽略的细节，我把它拎出来。25 个游戏共用同一份系统提示，提示里没有任何游戏知识，棋盘只是原始数值，可用操作就是 ACTION1、ACTION2、ACTION3 这种通用标签。模型不知道“这个按钮是跳跃”、“那个格子是金币”。它得从每次动作之后棋盘怎么变，反推每个操作实际在干什么，再把反推出来的东西写进笔记或模拟器里。这个设定把“harness 提供结构、模型负责反向工程”这件事推到了最纯的位置，也顺手堵死了“它是不是上网查攻略”这条路——工具跑在 bubblewrap 沙箱里，没有网络，写入限制在工作区，模型连游戏的底层实现都看不见。
写到这儿我得补一刀，是作为读者的诚实：这个设定干净得有点不真实。它排除了所有“读规则文本”的捷径，反而逼出了一套很漂亮的自我建模过程；但也正因为此，它在规则隐藏、状态可枚举、反馈明确的 ARC 环境里几乎无敌，换个规则不存在、没法穷举、反馈还延迟的生产系统，那 734 个脚本里可能有一大半变成废纸。这不是作者的问题，是 benchmark 的边界条件。ARC 测的本来就是这个，别指望这一套原样搬去修线上故障。
现在拆那条最漂亮也最危险的质疑。评论区里有人指出：这 25 个环境正是这个框架的开发环境，所以 99.95% 对于两次运行之间真正变了的那部分——也就是 harness——而言是个拟合值；单次八小时运行也给不出方差。我读完第一反应是这刀补得对，而且比作者自己在文里承认的“公开集不等于官方成绩”还要狠一层。他那个数的分布摆出来看更清楚：150 个关卡拿到了最高单关效率分，7 个超过人类基线，3 个持平，23 个动作数比人类多。183 个关卡里 160 个效率达到或优于人类基线。这个分布不差，但它说明的是这套架构扛得住长周期任务，上下文管理没被几十 MB 的日志压垮，模型在单一环境内部确实能积累并复用经验——这些都认。它说明不了换个留出环境你还能拿这个数，更说明不了“匹配人类学习效率”这个 AGI 定义被谁击穿了。把拟合值当泛化值，是这类文章最容易掉进去的坑；有人把这点出来了，我就只说从中读出的那一句：从头到尾被评测的其实不是模型，是 harness，而 harness 恰好又是那个被公开集亲手喂大的东西。我可能是过严，但解读这类 benchmark 报告，宁可慢一拍，也别把拟合值当初懂。
再补一条现实的绳子，勒脖子上那种。今年的 ARC 竞赛挪到 Kaggle 上离线办，托管 API 模型不让用。也就是说，这套“八小时、八百三十刀、Opus 5 托管 API”的打法，到了官方赛道根本上不了桌。到那时候你还得回答一个更无聊的问题：换成本地模型，你的 harness 还撑不撑得住。成本结构变了，模型能力掉一截，那些为 Opus 5 调的提示和工具组合还剩几成，得真跑一遍才知道。这条才是我说的“把论文拉回地面”最狠的一拉——它逼你想的不只是这分数多高，而是这玩法能不能离开这个温室。顺嘴说一句，评论区里那个追问 830 美元去向的人我挺喜欢，作者后来贴了按游戏拆的成本明细；数字给到能被追问的粒度，比一句“约 830 美元”老实得多。
把这篇拉回工程。对一线工程师来说，这篇报告唯一能直接搬走的是一个 pattern，不是一个结论：把历史外置到文件、给模型查询历史的工具、让它自己写代码把所学变成笔记和可复用程序、由它决定下一步决策里保留哪些进活动上下文。这四句拆开看每一句都不新鲜，拼在一起就是 30.16% 到 99.95% 的差距。这个 pattern 离开 ARC 也能用——长周期 agent、代码库维护 agent、数据分析 agent，凡是“上下文会膨胀、历史里藏着关键信息、需要从零碎交互里提炼结论”的场景，都能照搬。而且这不只是 AWS 一家在试，NVIDIA 的 AVO 基于 Opus 5 在同一个公开集上报了个 100%，说明 harness 这条线大家都在踩。代价也明摆着：token 费、沙箱、Python 执行安全、还有一个越来越难喂饱的脚本库。没有哪条是白拿的。
这又回到我老说的那句：先读原文，别让摘要替你下结论。那 99.95% 不是模型变聪明了，是有人给模型手里塞了一套能自己盖房子的工具，然后把它放进了盖房子最顺手的那块地。这堵墙我替你拆了，剩下那条“换块地还灵不灵”的路，得你自己走。