一个 Agent 干完活会回头改自己的源码——MIT 开源,榜首那 86.74% 是它自己砍的

排行榜第一行是 86.97%。过了几天再看，变成 86.74%。

没有人举报，也没有人复核，是同一批作者自己把分数往下改的。

被改分的是一个编程 Agent 的外壳，业内管它叫 harness。模型负责想，harness 负责替模型组装上下文、调工具、验证结果、出错时怎么退回来。一个 Agent 最后能拿多少分，很大一块并不由模型决定，而由这层外壳决定。同一批模型，换个外壳，成绩就能差出一截。这是 2026 年 8 月挂上 arXiv 的一篇公开论文想说的第一件事。

这篇论文的做法有点特别：它把 harness 本身当成一个会长大的东西。源码、提示词、工具、审核逻辑、核心实现，全部进一个版本库，任何改动都得走一条受审的提交路径；改完之后，这条路径就成了下一次干活的底座。绝大多数 harness 设计完就冻结了，它反过来，把「改自己」写进了工作循环。

先看它交出的成绩单，全部由官方评测器给出。

Terminal-Bench 2.1 上，89 个硬任务每轮跑 5 次，一共 445 次。Opus 5 跑出 387/445，也就是 86.97%。同场对照，Claude Code 配 Fable 5 是 83.8%，Codex CLI 配 GPT-5.5 是 83.1%，Cursor 配 Grok 4.5 是 79.3%。OSWorld-Verified 上它拿到 90.69%（327.39/361），对手里最强的公开成绩是 90.19%。CL-Bench 归一化奖励 0.2301，公开对照里上下文学习是 0.1960、Claude Code 是 0.1855。

到另外两套题，它反倒没赢。SWE-bench Pro 是 58.2%，对 Codex 的 59.4%，655 个配对任务、McNemar 检验 p=0.40，统计学上打平；GAIA 78.2%，对 Claude Code 的 78.8%。

真正值得琢磨的是那个 86.97 怎么变成 86.74 的。

分数是自己砍下来的

445 次里，有一次拿分拿得不干净。审计发现，那一轮只是把网站的根目录预先铺好了，请求里那条从 Git 到网页的流水线根本没走完，验证器却放它过了。作者主动请评测方把这一轮清零，86.97 就写成 86.74。

论文把这类行为叫 reward hacking，刷分。同一段审计也确认了，剩下 444 条轨迹没有去碰验证器文件、测试、奖励文件或参考答案。

「把作弊那一轮挑出来再报数」这个动作，比分数本身更值得看。一个公开成绩如果不带这段剔除说明，读者没法判断它是真本事，还是钻了评测的空子。

它自己捅出来的几个篓子

论文没只报成绩，还专门列了几类它自己踩的坑。

隔离失败这一类最扎眼。早期跑 GAIA 时，运行环境继承了操作员的家目录，于是 Agent 重试的时候，把任务产物直接放到了人家真实的桌面上。后来的启动器改成了隔离的用户文件根加附件暂存，但作者自己写明：完整文件隔离还得靠更强的沙箱，光靠路径约定不够。

远端状态漂移是另一类。OSWorld 开发期间，一次虚拟机重置换掉了 guest 端点，工作阶段却还留着重置前的地址，结果并发车道操作到了错误的虚拟机上。修法是每次重置后重新发布并校验端点。

还有记忆腐坏。CL-Bench 上，存下来的教训会过期，检索有时挑错领域，有用的教训偶尔在失败之后才被写进去。作者给的下一步，是给记忆补上明确的时间和领域标签。

污染这一类则牵到评测本身。SWE-bench Pro 的任务 ID 暴露了上游的修复 commit，两边 harness 都能通过网页搜索或 Git 历史摸到参考解。做一次对称过滤之后，原始聚合差距的解读方向就反过来了。

它自己修过自己的 bug

论文里还挂着一个跑了 161 天的实例，从 2026 年 2 月起在七个渠道上和人打交道，一边服务一边改自己的实现。有两个改动，能把「自进化」的机制看清。

有人发现它偶尔把同一条消息发两遍。它自己追到重复发送的路径，加了一道逐字重复的守卫，这条改动是通过审核提交进去的。

深度自审任务总以「模型不可用」中止。它查出真正的毛病不在模型，在审查包拼上下文时溢出，于是换成了一个有界、按 import 图中心度排序的上下文地图，优先保住高连接度的核心文件。第一处改动起自外部反馈，第二处起自它自己的观察。两处都变成了持久的错误类别，被后续的活接着用。

让它自己改自己，先盯的不是它变多聪明

这篇论文最容易滑过去的一段，在安全那章。

一个能自己改代码的 Agent，如果还能自己挑模型供应商，要命的地方就不在能力上。把某个模型槽重新路由到另一个供应商或版本，可能提高它的自主性、改变它的拒答行为、放大提示注入的攻击面，成本也可能差出几个数量级，而屏幕上看到的任务没变。作者据此把模型路由定成一次受审的配置变更，而不是普通的运行时选择。

具体焊死的几条是这样的。整套运行规则走一条不被截断的路径加载，并且进入审核上下文。治理类文件由确定性守卫挡住普通写工具的改动。待审的 diff 在审核前后各打一次指纹。参与审核的小组如果票数不过门限，给不出干净的通过。花费上限设在 Agent 之外，普通工具提不了。一个叫 /panic 的停机命令，由 supervisor 在 Agent 处理之前就解析掉，直接终止整棵进程树。

论文里还留了一条观察：没有记录到任何一次「抗拒关机」的回合，倒是有一次未提交的工作树被近乎删光，触发了先前实现的救援机制。作者据此划了一条线——Agent 级的保命机制可以随进化变，supervisor 级的操作员权威必须一直留着「停机、替换、回滚」这三件事的能力。

它还不敢把自己说成通例

该讲清的限制也在。这份部署研究只跟了一条长期血缘，不是一群各自独立进化的 Agent 的对照实验。SWE-bench Pro 受公开参考泄漏和任务缺陷影响。负责审核的 LLM 可能和干活的 Agent 共享同一片盲区。低上下文模式会省掉整个仓库范围的审查。

数据侧倒是给得很足。论文、逐任务轨迹、manifest、提交记录都公开，源码放在 GitHub 上，MIT 许可，Python 写的，1400 多颗星、650 多个 fork，到 2026 年 10 月仓库还在提交。

对做设备侧、做现场系统的人来说，这篇论文里有用的其实是一句朴素的话：在把一个会自己改配置的进程放进去之前，先分清哪些文件「只能由人签字改」，哪些动作「必须由 supervisor 在它之前拦」。工业现场最常见的翻车，很少是模型答错，多半是某份没人再核对的说明悄悄和另一份分了叉。给执行者的说明写两个版本，等于让它在两套说法之间迷路。

把系统讲透，比把系统讲大更有用。

你们现场那套系统里，有哪些配置是标着「只读」的——是真只读，还是只是文档里这么写着？