XMM Proposal Agent · 并行传送带 · D049 / D050

它现在是什么，实测揭示了什么，以及 D051 将把它变成什么

一个 planner 决定 K 件互不冲突的工作，K 个独立进程并发执行，一个 reduce 单写者提交账本。 D049/D050 保住了并发安全；D051 的任务是把这套安全机构从“高频评审”转成“持续产出可提交 proposal”。

实测窗口 2026-07-26 08:05–10:09 UTC 47 ideas · 12 roles · 4 engines K: 3 → 10（D050 AIMD） D051 决策冻结 2026-07-26

01 — 两根轴

传送带调度的不是「阶段」，是 (idea × role) 的格子

理解整个架构只需要一件事：工作单元不是「一个 idea」也不是「一个 role」，而是一次 shift —— 某个 role 在某个 idea 上干一件有界的活，末尾留一行 3-line handoff。 没有 worker 端到端拥有一个 idea。

于是全局状态是一张矩阵：行是 47 个 idea，列是 pipeline 的 12 个 role。 每次 batch，planner 从这张矩阵里挑出 K 个互相独立的格子并发点掉。

观测到的一批调度（2026-07-26 08:47 UTC）
idea M0R1R2 R3R4R5 R6R7
I021 M101··✓✓✓wk1··
I017 M83··✓wk2····
I024 M31··wk3·····
I039 NGC 5907··wk4·····
I018 M83 ULX✓wk5✓✓····
I005 NGC 4631··✓✓✓✓··
…另 41 个········

历史 shift 已完成 该批次的 5 个并发格子 未触及

图 1 — 一个真实批次实际调度的 5 个格子。注意它们全部落在不同的行： 并行发生在 idea 之间，从不发生在同一个 idea 内部。这不是巧合，是 planner 独立性谓词第 1 条强制的。

独立性谓词 —— 为什么必须「不同 idea」

并行规划 prompt 要求同一 batch 内任意两个 shift 满足全部四条：

  1. 不同 idea —— 一个 idea 文件最多一个写者（单写者不变式）。
  2. 无 D023 冲突 —— 同一 idea 的 R4 攻击与 R5 裁决不能同批，对抗性必须跨 shift 分离。
  3. 无数据依赖 —— 不能有一个 shift 读另一个 shift 正在写的产物。
  4. 排除 in-flight —— 上一批还在跑的 idea 不能碰，这是 prefetch 流水线的前提。

第 1 条是所有设计后果的源头。它把并行度的上界钉在「当前有多少个可推进且互不相干的 idea」上， 而不是「后端能承受多少并发」上。

02 — 时序

一个 batch 的四拍，加一个错峰的第五拍

PLAN 是串行的、昂贵的、LLM 的；COMPOSE 是确定性的、毫秒级的；MAP 是唯一并行的部分； REDUCE 是全局唯一写者。PREFETCH 想把下一批的 PLAN 藏到 MAP 底下。

一个 batch 的四拍加一个错峰拍 PLAN 串行需 20 到 24 分钟且位于临界路径；COMPOSE 为确定性毫秒级步骤；MAP 是 K 个 worker 并发，并以一个全栅栏结束，快的 worker 空转等最慢的；REDUCE 是全局单写者；PREFETCH 在 MAP 期间并行规划下一批。 1 · PLAN 2 · COMPOSE 3 · MAP 4 · REDUCE planner · hermes / nim-large 读 47 个 idea 账本 + 调度约束 实测 20–24 min · 在临界路径上 compose 确定性 毫秒级 wk4 R2 I039 wk3 R2 I024 wk1 R5 I021 wk2 R3 I017 wk5 R1 I018 每个 worker = 一个独立 CLI 进程，只写自己的 idea 文件 + 自己的 frag 5 · PREFETCH 无产出 PREFETCH 在 MAP 期间规划下一批（排除 in-flight ideas） 全栅栏 · 快的空转等最慢的 reduce 全局单写者 合并所有 frag 规划占临界路径 44% 槽位利用率 52% prefetch 命中 0 / 1 提交 5 个 shift / 124 min
图 2 — 一个 batch，横向按实测时长成比例。三个关键结构事实： PLAN 在临界路径上；MAP 以全栅栏结束（灰条就是空转的槽位）； PREFETCH 的 planner 在 REDUCE 执行期间仍然活着。

谁真正在执行 —— 不是「一个个跑」

planner 永远是一次 hermes 调用（默认 nim-large），它不看 route。 worker 是 K 个真并发的独立进程，引擎由 packet 的 route 加配额门共同决定， 失败沿链回退：

worker 引擎解析与回退链 route 为 hermes 时解析出单元素链，没有回退；route 为 claude 或 codex 时按配额比排序四级链；R2 由 driver 路由而非 planner。frag 非空即视为完成；为空且用时不足 300 秒则回退下一个引擎，为空且用时超过 300 秒则整条链放弃并记为 noop。 packet .route ROUTE = HERMES hermes 单元素链 · 失败就是失败，没有第二次机会 ROUTE = CLAUDE / CODEX claude codex agy hermes-terra 配额比决定谁先 R2 — 由 DRIVER 路由，不由 PLANNER claude 若 ratio<1.0 codex 若 ratio<1.5 hermes 配额比是「相对匀速节奏的周消耗」，烧得快 → 更早自动降级到 hermes frag 非空？ proof-of-work 是 → done 清除引擎 cooldown 否 · <300s → 回退 标记 4h cooldown 否 · ≥300s → noop 放弃整条链
图 3 — 引擎解析与回退。注意 route = hermes 的 shift 得到一条单元素链： 没有任何回退。观测到的那一批里，5 个 worker 有 4 个是 hermes。

03 — 与 pipeline 的关系

role 是一条严格串行的链；batch 是横切它的一刀

这是全部张力的所在：proposal 的交付依赖单个 idea 走完整条链的延迟， 而 batch 并行的是不同 idea 的不同位置。

pipeline 的 role 链与并行的关系 上游 R0 与 M0 供给 R1 与 R2；R2 到 R3 到 R4 到 R5 对同一个 idea 是不可压缩的串行链，最多两轮 R4 到 R5 修复，只有 R5 能写 Gate ledger；R5 的出口是 kill、park、needs-data 回到 M0，或晋升到 R6 到 R7 到 R8。四类全局阶段是 serial-only，出现时整批塌成 K 等于 1。 上游 · 连续 DIVERGE R0 覆盖矩阵 M0 候选源包 R1 有源事实 R2 生成 idea CONVERGE · 每个 IDEA 严格串行 R3 冻结设计 R4 kill-shot R5 四门裁决 ≤2 轮 repair 唯一的 Gate ledger 写者 QUANTIFY → EMIT · AO 事件驱动 R6 可行性 R7 起草 R8 TAC 模拟 kill · 墓地 park needs-data 回到 M0 取数 SERIAL-ONLY —— 出现时整批塌成 K = 1 R5-Pairwise Elo 锦标赛 · portfolio 重打分 · D048 降级淘汰 D043 gate-drift 修复（一次正文假阳性就足以抢占整个并行池）
图 4 — R2→R3→R4→R5 对同一个 idea 是不可压缩的串行链， 再加最多两轮 R4→R5 修复；只有 R5 能写 Gate ledger。 并行谓词禁止同一 idea 在一批里前进两步，所以这条链的长度完全不受 K 影响。

当前 47 个 idea 分布在哪

seed38
killed5
parked2
developing1
proposal-ready0
图 5 — idea 账本的生命周期直方图，实测 2026-07-26。 proposal-ready = 0 是显式的零，不是缺数据。 与 planner 自报的 role 直方图一致：R3 = 6、R5 = 5、R4 = 1， 而 R2 / R0 / R1 / R6-lite / L 全部为 0（饥饿）。

这就是架构层面的核心问题

并行度加到 10，推进的是横向：更多 seed 拿到 R3 冻结。 但 proposal 需要的是纵向：某一个 idea 走到 R6 → R7。 而纵向的临界路径长度（R2→R3→R4→R5→repair→R6→R7，每步一个 shift） 完全不受 K 影响 —— 因为独立性谓词第 1、2 条禁止同一 idea 在一批里前进两步。

04 — 实测

124 分钟买到了什么

墙钟124 min08:05 → 10:09 UTC
提交的 shift53 个计划批次中的 2 个
规划占临界路径44%20 + 22 + 12 min
槽位利用率52%10105s / (5 × 3863s)
prefetch 命中0 / 1背景烧掉 39 min
白烧的 worker 时间64 min研究已完成，未落盘
单次运行的实测甘特图 批次一的规划耗时 20 分钟且未产出文件；批次二规划 22 分钟后并发五个 worker，其中三个在 12 分钟内完成却要在栅栏前空转约 53 分钟等待最慢的那个；同期的 prefetch 规划耗时 39 分钟且无产出；批次三规划 12 分钟后只调度了一个 worker。 08:00 08:15 08:30 08:45 09:00 09:15 09:30 09:45 10:00 10:15 BATCH 1 PLAN — 只输出散文，未写文件 BATCH 2 PLAN 22 min wk4 R2 I039 wk3 R2 I024 wk1 R5 I021 wk2 R3 I017 wk5 R1 I018 noop · 工具预算耗尽 prefetch 无产出 · 工具预算耗尽 全栅栏 BATCH 3 PLAN 12 min → 只调度 1 个 worker（serial-only 的 gate-drift 修复）
图 6 — 实测甘特图。三段红色是同一个根因： 模型把活干完了但没落盘（散文式规划 / 工具调用预算耗尽）。 灰条是空转的槽位：三个短 worker 在 12 分钟内完成，却要等约 53 分钟。
符合预期

单写者不变式、idea 级互斥锁、frag proof-of-work、摘要 sidecar、引擎链回退 —— 全部按设计工作。 5 个 worker 并发写各自的 idea 文件没有冲突；reduce 正确合并；校准日志记全了含 noop 的 5 条。

重复出现的 idea 不是 bug：同一个 idea 再次被调度是 R2→R3→R4→R5 的角色推进。

不符合

失败模式没有被任何机制接住。「说完但没写文件」发生三次， 驱动只能看见文件的有无，于是一次记 strike、一次记 noop、一次静默丢弃 39 分钟。 已修：write-first 协议 + 把 harness 的工具调用上限从 250 提到 500。

不符合

AIMD 在测一个恒为零的信号。共享后端 30 分钟窗口 255 请求、0 个 429、0 失败， 于是自适应并行度的 decrease 分支结构性永不触发，K 只会 3→4→…→上限 12。 而真正的约束是栅栏尾延迟和独立 shift 的供给 —— 两者都不在这个信号里。

设计取舍

lint 假阳性能抢占整个并行池。gate-drift 检查把某个 idea 正文里的 「is not resolved here」匹配成状态词 RESOLVED；而该修复是 serial-only， 于是 K = 6 塌成只调度 1 个，花掉 12 min 规划 + 322s 工作去改一个否定句。

05 — D051 机构重构

把传送带从“评审最多”改成“证据、生产、对抗三部门协作”

图 1–6 的测量揭示的不是某个 model 不够强，而是调度器事实上决定了组织结构： 便宜且总是 eligible 的 review shift 在 stage-FIFO 下结构性过产，而把一个 idea 送到 R6、R7 的证据和生产工作被饿死。 D051 是 owner-endorsed 的制度修订；它保留 D049/D050 的并发安全不变式，但改变槽位预算、裁决条件与产品所有权。

R4 + R5（累计）195评审 role shifts
证据 role（累计）136M0 / R0 / R1 / R3；多为冻结而非提取
full R6 / R7 / R80 / 0 / 0生产链从未真正启动
2026-07-26 R517其中 8 个 NO_NEW_SHOT
D043 drift fix4同日 bookkeeping-of-bookkeeping
proposal-ready0明确的零，不是缺数据

D051 的诊断

我们建成了一个评审官僚体系，却在处理研究问题。问题不是 K 不够大，也不是需要一个端到端的“更聪明 agent”。问题是 stage-FIFO、anti-polish quota 和 review 的低成本/常 eligibility，共同让评审成为默认产出，而 evidence contact 与 production 没有受保护的预算。

机构而非 agent：三项不可替代条件

01

Error decorrelation

不同 route / architecture 攻击同一 claim。D023 异构性与 capability floor 继续保留：不是多 agent 投票，而是让错误不相关。

02

Verifiable anchors

分歧只能由可检查的外部锚点解决：独立重算、archive refetch、rerun/hash check，或 feasibility/power number；不能由“同意”解决。

03

Monotonic memory

每个正确增量必须落入 ledger，不能丢失。Gate ledger、graveyard、TRUST_TABLE、SHIFTS、frag+reduce 仍是制度记忆，不是聊天历史。

严重度条款：没有锚点的评审不能移动 gate

D051 采用 Mayo 式 severity clause：一个 R4/R5 event 只有在给出可重放的 checkable anchor 时才允许移动 gate。 无锚点的 reviewer prose 仍可保留为 note，但信息量为零，不可作为 FATAL、REFRAME、CORRECTION 或 lifecycle 变更的依据。

允许的锚点独立重算 · archive footprint refetch · rerun / SHA-256 · feasibility / power 数字
禁止 gate movement无外部 check 的措辞判断、同源 reviewer 一致、harness 失败被误当 capacity signal

实测例子：I026 的 FATAL 来自 XSA footprint 重算；I035 的 REFRAME 来自 rank arithmetic 与 HEAVY hash mismatch；I005 的 PARK 来自 power 0.060/0.073 ≪ 0.8。 与之相对，同日无锚点 prose 贡献了 8/17 个 NO_NEW_SHOT。

Production inversion：槽位按部门预算，不再由 stage-FIFO 自然分配

EVIDENCE

创造 bits

M0 / R0 / R1 / R3-data / HEAVY pilots 获得受保护的多数 slots。HEAVY 改为 owner 设定规模的 weekly pre-authorized budget，champions 优先。

PRODUCTION

唯一拥有产品的部门

full R6 + R7 living draft。每个 champion 保存一份 shared/drafts/ living draft；空 feasibility table 是诚实 TODO。R8 攻击 draft，而不是 idea prose。

ADVERSARIAL

阻止 false bits

R4 / R5 / R8 / L 只花证据来阻止错误证据。连续 2 轮无 FATAL+REFRAME 且无新 evidence 文件，即触发 yield circuit-breaker：该 idea 的 review 暂停，直到新证据到达。

Champion system：让产品在 ledger 层有主人

D049 / D050 现状

  • stage-FIFO 选“当前可做”
  • review 是最便宜且总可调度
  • 新 seed 持续进入流水线
  • 每个 idea 横向前进一步
  • R6 / R7 没有被保护的槽位

广度增长，产品链停在 seed。11 个同日 R2 seeds 却得到 17 个 R5 adjudications。

实施路线图：0a/0b 已上线，1–8 已决定但尚未实现

序改动状态目的
0awrite-first protocol；hermes agent.max_turns 250→500LIVE阻断“做完但未落盘”
0bwrite-set gate + parallel reduce frags + orphan lock guardLIVEone file / one writer 的机械执行
1R4/R5 severity clause；gate-drift negation-aware matchingDECIDED只有锚定 review 能移动 gate
2plan_constraints.py yield circuit-breakerDECIDED零产出 review 不再无限循环
3champions.py + milestone contracts + serves:DECIDED把多数预算压到产品临界路径
4deterministic schedule_next.py；LLM 仅写 taskDECIDED移除 20–24 min PLAN 与 prose-no-file failure
5parallel.sh rolling replenishmentDECIDED消除全栅栏造成的 52% slot utilization
6champion full-R6 + shared/drafts/ living draftsDECIDED启动真实 proposal production chain
7north-star / velocity / yield / utilization metricsDECIDED指标只服务调度，受 Goodhart guard 约束
8weekly HEAVY budget（N×3h/week）OWNER INPUT需 owner 决定 N；champions 优先
图 7 — D051 的顺序化实施合约。不是 backlog 愿望单：0a/0b 已被部署；1–8 是已记录的制度决策，但仍不得描述为已实现或已验证。

Goodhart guard 与唯一 north star

proposal-ready count 是唯一 north star：feasibility closed ∧ no open FATAL ∧ draft sections complete。Velocity 是每个 champion-week 的 decisive-evidence delta；review efficiency 是 (FATAL+REFRAME)/R4-shift。它们可以影响调度，不能取代科学判断，更不能成为 proposal 成功的声明。