arXiv:2609.14992，cs.CL，2026 年 9 月 14 日 03:57:37 UTC 提交 v1，5,016 KB，23 页 7 幅图，九个作者。到今天十一天。
点开摘要页，看见"多轮代理编程中的指令遵循能力仍未被充分探索"，手已经放在返回键上了——这句话过去半年我在二十篇 abstract 里见过。让我停住的是再往下两行的设计参数：每个实例平均 7.04 轮交互，91.33 条约束。
除一下。
| 项 | 数值 |
|---|---|
| 平均轮数 / 实例 | 7.04 |
| 平均约束数 / 实例 | 91.33 |
| 约束 / 轮 | 12.97 |
每轮砸下来 13 条约束。
这个数字比摘要里任何一句话都值得看。它不是给"AI 又不行了"再添一个证据点，它是一个口径问题：这套基准到底在测什么。
先把范围划死：我手上只有摘要页和元数据，23 页正文、实验表、判分脚本一个都没看到。下面的除法、比例、共线推演，全是对作者自己给出的参数做的算术，加上对设计描述的读解，没有一条是我跑出来的。谁要拿这篇当"有人验证过这个 benchmark 有问题"的依据，那是误读，我没干那事。
13 条/轮，谁在这么发指令
话先说死：没有真实用户这么发指令。没有人在第 3 轮里同时提 13 条互相独立的约束，脑容量不允许。
那这个数从哪来。两种可能。
一种是抽的。用户建 repo 的时候往 CLAUDE.md、往 plan 文件、往 issue body 里塞规矩，轮到 agent 干活，这些东西是一起生效的。真是这样，91.33 算克制——真实项目里一个规矩文件夹塞两三百条不稀奇。
一种是生成的。为了让"约束"这个维度有足够样本量，在每一轮里硬塞进去的。
两种来源，测出来的东西完全不是一回事。前者的核心能力是在长状态里不遗忘，后者的核心能力是在长 prompt 里不跑偏。论文用 instruction-following 一个词把两者装进同一个桶，而这两个桶的衰减曲线不会长一样：前者衰减是因为状态被顶掉了，后者衰减是因为注意力被稀释了，修法也完全是两回事。
我倾向前者。猜的。作者没在摘要里交代约束怎么生成的——注意，是摘要里没交代，23 页正文里大概率有。这一条我记的是"没查到"，不是"没写"。这个区别挺大，别拿我这句话去质疑人家。
checklist 这一步，值得单拎出来
有个设计我要给点 credit，因为它跟主流不一样：作者没让一个 judge 模型对着轨迹打个 1-5 分就交差，而是给每条约束和功能需求建检查清单，配验证脚本和评判代理逐项核。
区别在哪。打分式的评测最后给你一个数，这个数没法归因：模型是没遵守第 47 条，还是遵守了但被判错，你不知道。checklist 至少得先把"这条怎么算通过"写成一个可判定的谓词，失败的时候才能告诉你失败在哪一行。这是从体感评分往可复现测量挪了一格，方向对。
然后我的问题就来了，最要命的那个：这 91.33 个谓词是谁写的，写的时候一致性是多少。
九个人写 91 条/实例的 checklist，标注量不小。要让我信这套东西，至少得有两个数：约束到 checklist 的构建一致率（换个标注者，同一条约束会不会被判成同一个谓词），以及 checklist 对边界情况的覆盖率。摘要页上都没有。这两个数不出现，整篇论文的分数就是悬空的——底下垫的那层扛不扛得住，读者看不见。
我会先测的是评判代理自己
第二个更要命，也更具体：评判代理本身是个模型。
模型判模型有没有遵守指令。这个结构里有个循环，而循环最怕的是判定器自身的不稳定，和被判定对象的衰减，幅度处在同一个量级上。
这时候该做的测试便宜到不像话：同一条轨迹，喂给同一个评判代理两次，比两次判定结果。
不用跑 agent，不用 API 额度，一份存下来的轨迹日志加一套判分脚本就够。如果评判代理的重复方差是 ±8%，而论文报的衰减是从 90 掉到 60，那衰减曲线是真的，判分噪声盖不住它。但要是论文报的是 90 掉到 82，这事就得重新讨论——那 8 个点里，多少是模型真在退化，多少是判分器自己在抖，说不清。
我不怀疑作者跑测的时候做过这个检查。我怀疑的是它有没有被当成交付物写出来。这类数字属于"你交了我信一半，你不交我只能当它不存在"。
轮次和约束是共线的，这才是最大的结构问题
现在说我最想说的。
核心结论是：现有代码代理在多轮指令遵循方面存在明显缺陷，并且随着交互轮次增加，表现快速下降。
"随轮次增加而下降"，这个因果表述的前提是轮次是被分离出来的变量。看设计：多轮渐进式软件开发指令。渐进式意味着约束累积。第 1 轮可能只有 5 条约束在生效，到第 7 轮，前面六轮攒下来的加上本轮新增的，一起压在 context 里。
| 变量 | 论文设计里的状态 |
|---|---|
| 轮次 | 自然增长（1 → 7） |
| 生效约束数 | 随轮次同步增长，未分离 |
| 上下文长度 | 随轮次同步增长，未分离 |
三个变量手拉手往上走。那"随轮次下降"这句话里，轮次到底贡献了多少。
要拆开，得有这么一组条件：约束总数锁死，只变轮次的分布方式。同样 91 条约束，一组 1 轮全给（单轮 91 条的地狱 prompt），一组分 7 轮给（也就是现在的设计），一组分 20 轮给。三组跑同一个任务，看一次性通过率。
1 轮全给那组如果也掉到差不多的水平，那杀它的是约束总量下的状态跟踪能力，不是"多轮"。标题里那个"多轮"就得往后退一格，退成修饰语，不是核心变量。
反过来，1 轮全给那组反而更好——完全有可能，单轮的时候约束全在同一段上下文里，位置信息更整齐——那"多轮"这个变量才真立住了，而且立得很硬。
这个实验不难做。渐进式设计是这篇的卖点，它同时把最关键的变量混在一起了。我不认为作者是故意绕过去的，我只认为这个对照组应该存在，而且作者手里那份 harness 是现成能跑出来的。
18 个类目怎么分，聚合分才不算裸数字
还有一条，短一点。约束覆盖 6 个一级类别、18 个二级类别。91.33 除以 18，平均 5.07 条一个。
平均数在这里没什么用。真实分布不可能平，多半是某个类目塞了三四十条——"不许改动测试文件""不许新增依赖"这类硬规矩，天然容易被写成很多条。40 条集中在同一个二级类目下，那报出来的聚合分基本就是那一个类目的分，剩下 17 个是配平用的。
分类计数不摆出来，聚合数字就是裸数字：能看，不能信，因为你不知道它是被哪一块拖下来的。这张表应该在正文里，而且应该在主结果表旁边。
置信标签
- 方向大致对，样本不够："渐进式多轮设计导致轮次与约束数共线"这一条，读它的设计描述就能确认，不需要跑测，值得作者回应。但共线造成了多少虚假的衰减，这个量我给不出，得跑那三组对照才知道。
- 证据不够，先别信：所有关于评判代理噪声、checklist 构建一致率的判断，都是我基于"这类论文通常怎么写"的经验推测，不构成对这篇论文的指控。
- 高置信：13 条/轮的约束密度这件事本身值得单独拿出来讨论，讨论它比讨论"AI 又不守规矩了"有信息量。
要是作者把 harness 和判分脚本一起放出来，我最想干的是那件事：把同一批轨迹重判一遍。数字对不上，我回来改这篇。谁手上已经有这份日志、先跑了这个复测的，结果跟我不一样的话，欢迎告诉我。