v2.0.2 — 逐条判定,不要把上一条的推理当依据
只改一个文件:radar_review 这个 skill 多了一条规则。
radar_review 是我们最长的串行单 agent 循环——一份 digest 几十个候选,一条
一条读下来。到第二十条时,上下文里最响的东西是前十九条的推理,而它和眼前这
篇论文最不相干:判定的门槛会漂,任何长得像先前被否掉的那些的候选,看起来就
也该否掉。
新增的规则要求每个候选重新对着项目本身判定(开放命题、magi search),而不
是对着本轮累积下来的印象。
为什么现在加
SKILL.state(arXiv 2608.26263)量到了这条曲线:随无关历史累积,准确率从 0.68
掉到 0.53。它的主张——单次执行内用显式状态取代增长的历史,补丁由运行时而非
模型校验——和我们「确定性 CLI 是拘束具」是同一条原理,我们在台账那一层已经
这么做了。它没能覆盖的是 agent 自己那段串行推理,这条规则补的就是那里。
顺带记下两条:它自己承认的 Retroactive Relevance(提交时判定不重要而丢掉的
观察找不回来)和可变状态合并没有确定性冲突语义(「当前实现只支持单 agent」),
都指向我们追加式、带温度、不丢弃的 threads 是更稳的那一种。它的 "Memory"
基线(滚动窗口 + 周期性摘要)在 τ-Bench Retail 上 29.9%,低于什么都不做的
48.2%——以后若有人提议给 magi sync 加「让模型摘要老 thread」的捷径,这是
拒绝的引用。
没有配套的测试,但有两道守卫拦了一次
这条规则本身不能写成命令、闸门或测试——它约束的是判定时看哪份材料,机器
无从检查。凡是能写成检查的规则不留在 skill 里当散文;这条不能,所以它留在
这里。
不过写它的时候被现成的守卫拦了两次:第一版把 magi search 写成了不带参数的
裸调用(一个起不来的调用),第二是 skill 有 40 行硬预算,加进去变成 44。预算
的意思就是新规则得自己挣出行数——规则压到三行,第 5 步那个断在 "one candidate
per / call;" 的换行顺手重排,腾出一行。
验证
2641 个测试(2630 通过,11 跳过——PDF 文本层那批需要 textlayer extra,CI 不装
它,一直如此)。43 条变异用例全部会咬。
三宿主冒烟于 2026-09-01 在 Windows 11 通过:三个 dry-run 分别报 haiku /
its own default / gemini-3.7-flash-low;一次真实调用 21.0 秒,复核者驳回了
一个故意过宽的命题,把命题、推导、源三个文件逐行点名;命题落到 disputed 而
不是 refuted——驳回是留给人的问题。收工闸门先拒绝通过并说出缺的那个签名,
magi decide 之后才放行。
pipx upgrade --install magi-researchBrowser button — magi-browser-extension-v1.2.1.zip below.
Unzip it, open chrome://extensions, turn on Developer Mode, and use Load unpacked on the unzipped folder. It sends the page you are reading to a local MAGI queue and nothing else; nothing enters a library until you approve the batch.