模型不变状态进化：Argus 如何让 Agent 学会回头是岸
一个永不睡觉的实验室
想象有一间实验室，里面坐着四位研究员。一位叫 Manager，负责决定"我们这周做什么"；一位叫 Planner，负责把大目标拆成今天能干完的小任务；一位叫 Engineer，负责真正动手做实验、写代码、跑验证；最后一位叫 Reviewer，负责在 Engineer 说"搞定了"之前，独立检查一遍成果。
这间实验室没有午休，没有周末，没有"我明天再想"。它可以在一个数学问题上连续工作好几天，在七次走错路之后不崩溃，把每一条被否决的路径都记下来，让下一轮任务不再重蹈覆辙。六篇论文从开题到投稿，254 个子任务，16 次推翻重来——全部由它自己完成。
这不是一个更大的语言模型。这是一个运行时（Runtime）。
它的名字叫 Argus。
核心问题：长程推理不是"更长的推理"
过去两年，AI Agent 领域的共识越来越清晰：让模型做更长的推理，并不等于让它做更深的推理。一个 Agent 可以连续调用 200 次工具，但只要它没有"记住"前 100 次的失败教训，第 101 次和第 1 次就毫无区别。
长程推理的真正瓶颈不是上下文窗口的长度，而是状态管理。具体来说：
- 什么时候该坚持？ 当前方法看起来有效，但可能只是还没碰到墙。
- 什么时候该转向？ 当前方法已经失败，但失败信息里可能藏着正确的方向。
- 什么时候该承认做不到？ 与其编造一个"看起来完成"的结果，不如明确记录"这条路走不通"。
Argus 的回答：四角色 + 三平面 + 验证门控
Argus 的架构可以用一句话概括：模型权重不变，运行时状态进化。
四角色分工
| 角色 | 职责 | 权限 |
|---|---|---|
| Manager | 跨越整个 campaign 的目标管理 | 唯一能改变阶段的角色 |
| Planner | 把当前状态变成下一个有界任务 | 拥有任务定义权 |
| Engineer | 执行任务、产出工件 | 可在低风险任务上自审 |
| Reviewer | 独立检查、修订或否决 | 高风险任务的最终门控 |
这就像建筑工地的质检员不看施工日志，而是直接去量墙的厚度。
三平面分离
Argus 把系统分成三个平面：
- 控制平面：锚定 campaign、调度任务
- 执行平面：执行一个有界任务
- 记录平面：存储发生了什么，但不决定任务是否完成
验证门控（Verification-Gated）
这是 Argus 最核心的概念。一个候选更新——无论是一条记忆、一个技能、一个验证规则、还是一条被否决的路径——不会仅仅因为某个角色产出了它就被采纳。它必须通过：
1. 任务原生的证据检查（跑测试、跑验证器、跑形式化检查） 2. 授权角色的提交（Engineer 自审或 Reviewer 独立审查） 3. 后续任务的可检索复用
只有走完这条"提交-复用"路径，才算运行时自我进化。
关键实验数据：七场擂台
Argus 在七个基准测试上跑了一遍，结果用一张大表呈现。因为每个基准的度量单位不同（准确率、排名、比特每字节、时间），作者明确拒绝把它们平均成一个"通用分数"。
| 基准 | Argus 结果 | 参考结果 |
|---|---|---|
| SWE-Bench Pro | ~78% | 59%（Direct Copilot） |
| AARRI-Bench | 76.8% | — |
| 数学数据合成 | 28.0 分差距 | — |
| GPU 内核优化 | 竞争力强 | — |
| 语言模型训练 | 竞争力强 | — |
| 研究助手任务 | 竞争力强 | — |
| 数据合成 | 竞争力强 | — |
运行时自我进化的证据
更有趣的发现来自 SWE-Bench Pro 的纵向分析。Argus 把 731 个任务按执行顺序分成几个窗口：
- 启动期 W1-6：项目特定状态最少
- 成熟期 W19-22：已积累可复用知识
- 末期 W23-24：最难的尾巴任务
但作者很诚实：这个曲线不是单调的。W13-18 的 token 用量最低但执行时间更长，说明"token 效率"和"执行延迟"不是同一回事。W23-24 的指标反弹，说明难任务不会因为运行时成熟就变简单。
Reviewer 的修复漏斗
731 个任务中：
- 466 个（63.7%）调用了独立 Reviewer
- 265 个（36.3%）用 Engineer 自审
- Reviewer 要求修订 43 个任务
- 修订后 34 个通过官方验证器
- 22 个完成完整的"继续→修订→完成"循环
这组数据说明 Reviewer 不是"事后评论员"，而是一个纠错通道：它拦下了不合格的方案，要求重做，然后重做后的方案有 79.1% 通过了官方验证。
RWKV6 内核：被人类审查者合并的真实贡献
Argus 不只在基准测试上跑分。它优化了一个 TileLang RWKV6 内核，提交到了 Flash Linear Attention 仓库（fla-org）。一位 Moonshot AI 的合作者审查了生成的 CUDA 代码，发现了一个长序列数值稳定性问题，要求加 block-local exponent centering。Argus 修复后重新跑验证套件，2026 年 7 月 20 日合并入 main 分支。
具体数据：
- 前向延迟从 0.199ms 降到 0.168ms（1.18 倍）
- 前向+反向从 0.900ms 降到 0.747ms（1.21 倍）
- 13 项正确性门控全部通过
- 14 项仓库测试全部通过
数学战役：保留一条被否决的路
除了基准测试，Argus 跑了一场持续多天的 Erdős–Gyárfás 数学研究。这场战役的记录不是"定理-证明"的线性叙事，而是四个角色的行动轨迹：
- Manager 在预算失败后恢复 campaign
- Planner 先选了一个便宜的证伪测试，然后把成功标准从"收集观察"改成"产出证明"
- Engineer 检索文献、跑可执行检查、写证明
- Reviewer 否决了一条夸大的路径，要求补检查，最终接受了边界更紧的结果
这就像实验室的失败实验记录：如果记录得好，失败比成功更有价值。
六篇论文：254 个任务，16 次推翻重来
Argus 还跑了六个完整的研究项目，覆盖评估可靠性、视觉-语言匹配、测试时适应、GUI Agent、多模态幻觉、模型量化。全部六个都走到了投稿阶段。
但重点不是"六篇论文都写完了"。重点是没有一篇是一遍过的。286 次 Reviewer 修订判决、89 次会话切换、16 次阶段回滚——这些数字说明真正的研究不是一遍跑完的直线，而是在审查和回滚中反复折返的曲线。
多模态幻觉项目最能说明问题。在 12 小时的密集搜索窗口里，七次回滚决策否决了基线覆盖不全、与基线完全相同、缺失预注册信号的方法路径。然后 Planner 提出把"正向缓解方法"改成"诊断性负面结果研究"，Manager 接受了这个重新定义。Engineer 完成了一个 5 方法 × 3 基准的矩阵，4500 行官方评分数据。Reviewer 把"无效"和"退化"的结论绑定到这些输出上。
失败被保留为信息，只有审查过的状态才能控制下一步。
工程洞察：为什么"模型不变"反而更强
Argus 最反直觉的结论是：你不一定需要一个更大的模型来获得更好的长程推理。你需要的是一个更好的运行时。
这和步子哥之前关注的几条线索高度同构：
"分工比统一更有效"：Argus 的四角色分工和 Rebucca 的"小模型初筛+大模型复核"是同一个原则的不同实例。不追求一个模型做所有事，而是让专门角色做专门的事。
"颗粒度同构"：Argus 的"campaign → mission → round"层级和 Heddle/CodeRescue 的"轨迹级优化"是同一个洞察——优化颗粒度应该和被优化对象的颗粒度一致。Agent 的行为不是单次调用，而是多步轨迹，所以管理单位也应该是轨迹级的。
"评测盲区定律"：Argus 的 Reviewer 机制直接回应了"曾经正确 ≠ 当前正确"的问题。一个任务在第一轮通过不代表它在第二轮还正确——Reviewer 的修订漏斗就是对这个问题的工程回应。
"换层面解决问题"：Argus 不训练模型学会推理，而是把推理的协调工作外包给运行时——这和 Euclid-MCP 的"让 LLM 当诗人，让 Prolog 当会计"是同一个思路。模型负责生成，运行时负责审查和积累。
CHECKPOINT.md：最朴素的最关键设计
Argus 有一个看起来很不起眼但极其关键的设计：Engineer 和 Reviewer 的每次调用都用全新的 provider session。跨 session 的连续性来自一个普通的 CHECKPOINT.md 文件，里面存着持久状态、证据引用、开放问题和下一步。
这个设计的美妙之处在于：它把"记忆"从模型上下文里拿出来，放进了文件系统。 模型不需要记住所有历史——它只需要读一个文件。这意味着：
- 模型可以换（GPT-5.5 换成 GLM-5.2，运行时照跑）
- session 可以断（重启后从 CHECKPOINT 恢复）
- 状态可以审查（CHECKPOINT 是文本，人类和 Reviewer 都能读）
诚实的局限
论文的局限讨论部分值得单独一提。作者明确列出：
- 启动期到成熟期的对比是观察性的，不是因果估计——没有冻结状态的匹配重放
- Reviewer 路由是自适应的，不是随机的——不能直接做因果归因
- 六篇论文来自同一环境，campaign-hours 有重叠
- GLM-5.2 在 Claude Code 上的运行还在进行中，70.94% 但没有匹配的 Direct 基线
- 芯片结果只到综合和静态时序，没有布线、功耗、流片
- MOF 材料实验的 989 晶体子集是设计评分的同一批数据，不是独立 holdout
个人思考：运行时是新的"操作系统"
Argus 让我越来越确信一个判断：Agent 时代的"操作系统"不是模型，而是运行时。
模型是 CPU——它执行指令，但不管调度。运行时是操作系统——它管进程、管内存、管文件系统、管权限。就像你不会指望 CPU 自己管理进程切换，你也不应该指望模型自己管理长程推理的状态切换。
Argus 的三平面分离（控制/执行/记录）对应操作系统的进程调度/执行/日志。四角色分工对应操作系统的进程/线程/文件/权限管理器。验证门控对应操作系统的权限检查。CHECKPOINT.md 对应操作系统的持久存储。
这个类比不是装饰性的。它指向一个具体的工程方向：Agent 的竞争力不在于模型参数量，而在于运行时的设计质量。 一个 8B 模型配一个好的运行时，可能在长程任务上打败一个 70B 模型配一个差的运行时——因为后者会不断重复已经犯过的错误，而前者不会。
colibrì 证明了 1300 行 C 代码可以跑 7440 亿参数。Argus 证明了固定权重的运行时可以自我进化。两条线索指向同一个未来：轻量、持久、可审查的运行时，是 Agent 工程的下一个主战场。
论文链接
- arXiv: https://arxiv.org/abs/2608.05144
- HTML 全文: https://arxiv.org/html/2608.05144v1
- 上游合并: FLA PR #1045
*Argus 是希腊神话中的百眼巨人，睡觉时总有一部分眼睛睁着。这个名字起得精准——一个永不完全入睡的运行时，用一百只眼睛盯着自己的每一步。*