短线直接做
探索实现测试 / 修复完成
直接探索、实现、测试；没有显式 GT 澄清或计划 gate。
WORKFLOW ARENA · gpt-5.6-terra/high · macOS同一个任务，
同一个任务，
五种工作方式。
十五条 native Codex rollout 被还原成可点击的阶段、墙钟与 actor 泳道：从 Without、一次澄清的 Slim，到需求闭环、需求加 review 闭环，再到 Full。
盲评分81.67 · 83.17 · 97.67 · 99.50 · 99.00
Without / Slim / Req Loop / Review Loops / Full；均为 scoreN=2
平均墙钟8:36 · 9:10 · 11:27 · 20:44 · 40:24
五组均按每条 run 求平均
平均 TOKEN / RUN2.08M · 2.27M · 2.87M · 4.88M · 15.87M
去除 fork 继承 usage；reviewer 计入 Review Loops treatment
平均首次改产品2:02 · 2:26 · 4:39 · 5:03 · 5:28
顺序同上；需求闭环会把首次 mutation 推后
01 / METHOD SHAPE
把 Full 的两个机制增量拆成相邻阶梯
澄清 + Plan-on
探索Operator 澄清计划原生实施验证
先澄清外部行为并形成计划，再由同一 Codex session 原生实施。
多轮需求闭环
探索多轮提问设计获批计划原生实施
重复 GT 澄清，直到行为设计获批，再进入 Slim 实施。
需求 + 实现反馈
需求获批实现 / 测试独立 review修复复审通过
同样的需求闭环，再由独立 reviewer 反馈、修复并复审至通过。
完整 gate 与反馈环
设计 / GTSpec + plan多代理实施独立 review修复 / verify
设计、规格、计划、多代理实施、独立 review 与 verification。
02 / PHASE DISTRIBUTION
时间花在哪里
主口径：每条 run 先归一化，再对组三条求平均。
03 / TOKEN DISTRIBUTION
Token 被什么阶段、什么 actor 消耗
04 / FIVE-WAY TRACE
什么时候由谁做了什么
每个 TRACE 纵向展示五种方法的阶段比例轴。Requirement Loop 与 Review Loops 的 pair-02/03 保留同期随机配对；pair-01 的 loop-01 分数和轨迹来自后续独立 rerun，因此整组三对只作更新后的描述性对齐。历史 Without、Slim、Full 仅作跨批次描述性对齐。Review Loops 的 Targeted reviewer 单独显示。
Without
run-01
- 分数
- 82.0
- 墙钟
- 7:01
- Token
- 1.27M
- 首改
- +2:15
- 设计获批
- —
- 首个 Review Ready
- —
- Review 通过
- —
0:003:307:01
Parent
Child
Guardian
Operator
Targeted reviewer
0 operator 回合23 tool calls2 sessions
Slim With
slim-01
- 分数
- 84.0
- 墙钟
- 8:46
- Token
- 2.49M
- 首改
- +2:32
- 设计获批
- —
- 首个 Review Ready
- —
- Review 通过
- —
0:004:238:46
Parent
Child
Guardian
Operator
Targeted reviewer
1 operator 回合34 tool calls3 sessions
Requirement Loop
loop-02
- 分数
- 96.0
- 墙钟
- 11:49
- Token
- 2.65M
- 首改
- +5:18
- 设计获批
- 00:05:21
- 首个 Review Ready
- —
- Review 通过
- —
0:005:5511:49
Parent
Child
Guardian
Operator
Targeted reviewer
6 operator 回合35 tool calls3 sessions
Requirement + Review Loops
loop-01
- 分数
- 100.0
- 墙钟
- 23:25
- Token
- 3.75M
- 首改
- +4:31
- 设计获批
- 09:03:40
- 首个 Review Ready
- 09:20:26
- Review 通过
- 09:22:26
0:0011:4223:25
Parent
Child
Guardian
Operator
Targeted reviewer
5 operator 回合54 tool calls6 sessions
Full With
run-02
- 分数
- 100.0
- 墙钟
- 47:50
- Token
- 18.47M
- 首改
- +7:27
- 设计获批
- —
- 首个 Review Ready
- —
- Review 通过
- —
0:0023:5547:50
Parent
Child
Guardian
Operator
Targeted reviewer
11 operator 回合266 tool calls19 sessions
05 / THREE RESEARCH QUESTIONS
三个问题，三条可审计证据链
把“分数更高”“验收可靠”“token 花在哪里”拆开回答；所有图都标明是原始 usage、盲评代理还是分类器派生。
Q1
Full Superpowers 相比较原生 Codex，质量和资源如何变化？隐藏验收能稳定通过吗？
Full With 的分数跃升，但不是免费提升；高分也不能替代独立的 hidden acceptance gate。
方法Score执行 creditsdedup token / run墙钟
Without
score81.67
credits24.44 cr
tokens2.08M
wall8:36
Slim With
score83.17
credits28.65 cr
tokens2.27M
wall9:10
Requirement Loop
score97.67
credits43.49 cr
tokens2.87M
wall11:27
Requirement + Review Loops
score99.50
credits85.33 cr
tokens4.88M
wall20:44
Full With
Score 是每 run 两次 blind judge 的均值；credits 是 candidate/operator/reviewer 的 execution credits，judge credits 不计入；token 是去 fork 继承后的轨迹总量。score99.00
credits182.97 cr
tokens15.87M
wall40:24
严格验证代理Verified verdict / 完全 Verified run
Without
0/6
0/3 runsSlim With
0/6
0/3 runsRequirement Loop
0/6
0/3 runsRequirement + Review Loops
4/6
1/3 runsFull With
口径：judge.final.json 的 overallValidation === Verified；这不是协议定义的独立 hidden integration gate。完全通过要求同一 run 的两次 verdict 都 Verified 且无 critical/major gap。3/6
1/3 runs三条 Full 都进入 98–100 分，和 Without 的 80.5–82.5 分区间没有重叠
Full 的三条 run 分别是 100 / 99 / 98，Without 是 82 / 82.5 / 80.5。组均值从 81.67 提升到 99.00，增加 17.33 分。这个结果说明完整流程在本任务上显著减少了行为规格遗漏；但每组只有三条，且不是同期随机批次，所以它是强描述性证据，不是总体因果效应估计。
质量提升对应约 7.6 倍 token、4.7 倍时间和 7.5 倍执行 credits
每条 run 的平均消耗从 2.08M → 15.87M，墙钟从 8:36 → 40:24，工具调用从 32.7 → 244，execution credits 从 24.44 cr → 182.97 cr。因此 Full 的优势不是“同样预算下免费变好”，而是用更多上下文、实施、协调和审查换取更完整的产品行为。
100 分也不等于流程和隐藏验收都稳定通过
run-02 两份 verdict 都是 Verified、得分 100，但最终状态是 token cap；run-03 只有 1/2 Verified；run-06 是 0/2 Verified，仍得到 98 分。Full 合计只有 3/6 Verified verdict、1/3 双 Verified run。这说明 rubric 总分是在衡量产品质量，而 overallValidation 是另一种严格代理；两者相关，却不能互相替代。
结论：Full 99.00 对 Without 81.67（+17.33），但平均墙钟约 4.69×、dedup token 7.64×、execution credits 7.49×、tool calls 7.47×。严格 Verified 代理只有 3/6 个 Full verdict、1/3 个 run 两次均 Verified；因此本样本支持“更高质量 / 更高资源”，不支持“隐藏验收稳定必过”。Full 的 run-02 虽两次 Verified 且得分 100，却在 token cap 截止，不能把分数当作流程完整性的证明。
Q2
需求闭环和定向代码审查分别带来多少收益？Full 还能继续稳定增益吗？
这里的“审查”按实际协议是独立 reviewer 反复修复到无 critical/major，而不是人为固定一次。
Without → Slim With跨批次描述性
Score +1.50credits +4.21tokens +0.19Mwall +33s
Slim With → Requirement Loop跨批次描述性；需求闭环增量
Score +14.50credits +14.85tokens +0.60Mwall +137s
Requirement Loop → Requirement + Review Loops新组 paired；pair-01 posthoc 替换后整体仅描述性
Score +1.83credits +41.84tokens +2.00Mwall +557s
Requirement + Review Loops → Full With跨批次、复合剩余流程描述性
Score −0.50credits +97.63tokens +11.00Mwall +1180s
credits 增量token 增量（各自归一化）
最大的质量跃升发生在“把需求问完整并获批”这一步
Slim → Requirement Loop 的均分变化是 83.17 → 97.67（+14.50）。三条 Requirement run 分别问了 1、2、2 个定向问题，并经历 5、4、4 次设计审批请求；首次产品修改平均从 Slim 的 +2:26 推迟到 +4:39。代价是每条多 0.60M token、2:17 墙钟、3 次工具调用和 14.85 credits。证据更支持“补齐隐藏行为边界带来主要收益”，而不是“多写计划本身带来收益”。
审查的收益较小、成本较高，而且不是每条都正向
Requirement → Review Loops 的更新后均值是 +1.83 分，同时每条多 2.00M token、9:17 墙钟、22.7 次工具调用和 41.84 credits。三个对齐差值分别为 +4.00、−1.50、+3.00：loop-01 一轮 review 后无 major fix，loop-04 和 loop-06 各两轮并各修复一次。review 能发现并修复实现问题，但效果取决于初始实现和 finding，并非机械地每条加分。
加入 spec、TDD、多代理与更多 gate 后，没有观察到继续增分
Review Loops → Full 的均分是 99.50 → 99.00（−0.50），却再增加约 11.00M token、19:40 墙钟、183.7 次工具调用和 97.63 credits。这不能证明 Full 的剩余流程“有害”：两组来自不同批次，Full 还包含多个同时变化的机制；它只能说明在当前单任务、小样本和接近满分的天花板下，没有看到稳定的额外质量收益。
结论：历史 Slim → Requirement Loop 的描述性增量是 +14.50 分，约多 24.95% 墙钟、26.53% token、51.83% credits；Requirement Loop → Review Loops 再增加 +1.83 分，却多 81.10% 墙钟、69.68% token、96.20% credits。Review Loops → Full 分数反而 −0.50，资源再增加约 95% 墙钟、226% token、114% credits；所以在这批小样本里，没有观察到 Full 在两个机制之后仍提供稳定质量增益。Slim→Requirement 是跨批次描述性比较，Review 的 pair-01 还被 posthoc rerun 替换，不能写成完整因果效应。
Q3
Superpowers 新增 token 主要花在实现、重复读上下文，还是主 Agent 与子 Agent 的协调？
阶段、actor、usage 构成是三种互补切片，不把它们相加成一个“归因总和”。
Full 相比 Without 每条 run 多 13.80M token
“协调”不是代码实现的同义词
本分析把主 Agent 的 spawn_agent、wait_agent、followup_task、send_message、代理结果汇总、worktree / approval / guardian 安全动作归到 coordinate。它是“派发—等待—收集—决策”的过程代理；一个协调片段里可能同时带有上下文传输和实现决策，不能把它解释成单一语义动作。
按互斥阶段Full − Without
协调
+5.23M · 37.9%
实现
+3.94M · 28.6%
Review
+2.27M · 16.5%
计划
+0.79M · 5.7%
需求 / 设计
+0.52M · 3.8%
测试 / 调试
+0.75M · 5.4%
探索
+0.11M · 0.8%
Operator
+0.18M · 1.3%
完成
−0.00M · 0.0%
按 actor 泳道Full − Without
Parent
+7.36M · 53.3%
Child
+5.83M · 42.3%
Guardian
+0.43M · 3.1%
Operator
+0.18M · 1.3%
Reviewer
+0.00M · 0.0%
按 usage 构成Full − Without
Cached input
+13.14M · 95.3%
Uncached input
+0.59M · 4.2%
Reasoning
+0.02M · 0.1%
Other output
+0.05M · 0.3%
最大增量是协调，其次才是实现和 review
Full 相比 Without 每条多 13.80M token。分类器把其中 5.23M（37.9%）归到 coordinate，3.94M（28.6%）归到 implement，2.27M（16.5%）归到 review；计划、测试、需求分别占 5.7%、5.4%、3.8%。所以新增 token 并非主要只花在“多写代码”，而是大量花在派发、等待后的续接、结果吸收和决策同步。
主 Agent 仍是最大消费者，但子 Agent 已承担超过四成增量
root 增加 7.36M（53.3%），child 增加 5.83M（42.3%），两者合计 95.6%；guardian 与 operator 合计约 4.4%。这说明 Full 的成本不是某个 reviewer actor 单独造成，而是主 Agent 保留全局上下文、子 Agent 各自执行任务，再由主 Agent 回收结果的组合成本。
95.3% 的新增量表现为 cached input，但它不是“重复读文件”的直接计数
增量里 cached input 为 13.14M（95.28%），uncached input 为 0.59M（4.24%），reasoning 与其他 output 合计不足 0.5%。这说明成本主要随长上下文和会话续接累积，而不是最终输出文本；但 API usage 只告诉我们输入是否命中缓存，无法逐 token 区分“重复读取代码”“给子 Agent 传上下文”还是“汇总后继续推理”。
结论：Full−Without 的新增 13.80M token 中，阶段代理最大的是 coordinate 37.9%，其次 implement 28.6%、review 16.5%；actor 视图中 root + child 合计约 95.6%。cached input 增量约 95.3%，只能作为上下文传输 / 缓存代理，不能直接证明模型语义上重复读了哪些文件。现有 raw tool evidence 支持“有派发、等待、follow-up、结果汇总”，但不能逐 token 拆成 dispatch、wait、summary。
证据入口：公开仓库的 15 条 canonical results、metrics.json、loop-01 replacement 与每条 run 的两份 verdict。详细边界见主报告。
06 / FIFTEEN RUNS
平均值背后的十五条轨迹
Without
run-01
82.0- 墙钟
- 7:01
- Token
- 1.27M
- 首次改产品
- +2:15
- Operator
- 0
- 需求 Q
- —
- 设计轮数
- —
- Review / 修复
- 0 / 0
- Reviewer
- 0
- 设计获批
- —
- 首个 Review Ready
- —
- Review 通过
- —
- Tool calls
- 23
- scoreN
- 2
- 状态
- completed
Full With
run-02
100.0- 墙钟
- 47:50
- Token
- 18.47M
- 首次改产品
- +7:27
- Operator
- 11
- 需求 Q
- —
- 设计轮数
- —
- Review / 修复
- 0 / 0
- Reviewer
- 0
- 设计获批
- —
- 首个 Review Ready
- —
- Review 通过
- —
- Tool calls
- 266
- scoreN
- 2
- 状态
- token_cap
Full With
run-03
99.0- 墙钟
- 32:08
- Token
- 13.32M
- 首次改产品
- +5:18
- Operator
- 7
- 需求 Q
- —
- 设计轮数
- —
- Review / 修复
- 0 / 0
- Reviewer
- 0
- 设计获批
- —
- 首个 Review Ready
- —
- Review 通过
- —
- Tool calls
- 186
- scoreN
- 2
- 状态
- completed
Without
run-04
82.5- 墙钟
- 12:12
- Token
- 3.94M
- 首次改产品
- +2:03
- Operator
- 0
- 需求 Q
- —
- 设计轮数
- —
- Review / 修复
- 0 / 0
- Reviewer
- 0
- 设计获批
- —
- 首个 Review Ready
- —
- Review 通过
- —
- Tool calls
- 54
- scoreN
- 2
- 状态
- completed
Without
run-05
80.5- 墙钟
- 6:36
- Token
- 1.02M
- 首次改产品
- +1:49
- Operator
- 0
- 需求 Q
- —
- 设计轮数
- —
- Review / 修复
- 0 / 0
- Reviewer
- 0
- 设计获批
- —
- 首个 Review Ready
- —
- Review 通过
- —
- Tool calls
- 21
- scoreN
- 2
- 状态
- completed
Full With
run-06
98.0- 墙钟
- 41:14
- Token
- 15.84M
- 首次改产品
- +3:40
- Operator
- 3
- 需求 Q
- —
- 设计轮数
- —
- Review / 修复
- 0 / 0
- Reviewer
- 0
- 设计获批
- —
- 首个 Review Ready
- —
- Review 通过
- —
- Tool calls
- 280
- scoreN
- 2
- 状态
- completed
Slim With
slim-01
84.0- 墙钟
- 8:46
- Token
- 2.49M
- 首次改产品
- +2:32
- Operator
- 1
- 需求 Q
- —
- 设计轮数
- —
- Review / 修复
- 0 / 0
- Reviewer
- 0
- 设计获批
- —
- 首个 Review Ready
- —
- Review 通过
- —
- Tool calls
- 34
- scoreN
- 2
- 状态
- completed
Slim With
slim-02
79.0- 墙钟
- 9:08
- Token
- 2.03M
- 首次改产品
- +2:20
- Operator
- 1
- 需求 Q
- —
- 设计轮数
- —
- Review / 修复
- 0 / 0
- Reviewer
- 0
- 设计获批
- —
- 首个 Review Ready
- —
- Review 通过
- —
- Tool calls
- 34
- scoreN
- 2
- 状态
- completed
Slim With
slim-03
86.5- 墙钟
- 9:36
- Token
- 2.30M
- 首次改产品
- +2:26
- Operator
- 1
- 需求 Q
- —
- 设计轮数
- —
- Review / 修复
- 0 / 0
- Reviewer
- 0
- 设计获批
- —
- 首个 Review Ready
- —
- Review 通过
- —
- Tool calls
- 36
- scoreN
- 2
- 状态
- completed
Requirement + Review Loops
loop-01
100.0- 墙钟
- 23:25
- Token
- 3.75M
- 首次改产品
- +4:31
- Operator
- 5
- 需求 Q
- 2
- 设计轮数
- 3
- Review / 修复
- 1 / 0
- Reviewer
- 1
- 设计获批
- 09:03:40
- 首个 Review Ready
- 09:20:26
- Review 通过
- 09:22:26
- Tool calls
- 54
- scoreN
- 2
- 状态
- completed
Requirement Loop
loop-02
96.0- 墙钟
- 11:49
- Token
- 2.65M
- 首次改产品
- +5:18
- Operator
- 6
- 需求 Q
- 1
- 设计轮数
- 5
- Review / 修复
- 0 / 0
- Reviewer
- 0
- 设计获批
- 00:05:21
- 首个 Review Ready
- —
- Review 通过
- —
- Tool calls
- 35
- scoreN
- 2
- 状态
- completed
Requirement Loop
loop-03
100.0- 墙钟
- 10:44
- Token
- 2.92M
- 首次改产品
- +4:03
- Operator
- 6
- 需求 Q
- 2
- 设计轮数
- 4
- Review / 修复
- 0 / 0
- Reviewer
- 0
- 设计获批
- 00:31:16
- 首个 Review Ready
- —
- Review 通过
- —
- Tool calls
- 38
- scoreN
- 2
- 状态
- completed
Requirement + Review Loops
loop-04
98.5- 墙钟
- 21:12
- Token
- 6.25M
- 首次改产品
- +5:00
- Operator
- 7
- 需求 Q
- 3
- 设计轮数
- 4
- Review / 修复
- 2 / 1
- Reviewer
- 2
- 设计获批
- 00:42:30
- 首个 Review Ready
- 00:51:28
- Review 通过
- 00:59:07
- Tool calls
- 70
- scoreN
- 2
- 状态
- completed
Requirement Loop
loop-05
97.0- 墙钟
- 11:48
- Token
- 3.06M
- 首次改产品
- +4:36
- Operator
- 6
- 需求 Q
- 2
- 设计轮数
- 4
- Review / 修复
- 0 / 0
- Reviewer
- 0
- 设计获批
- 01:18:00
- 首个 Review Ready
- —
- Review 通过
- —
- Tool calls
- 40
- scoreN
- 2
- 状态
- completed
Requirement + Review Loops
loop-06
100.0- 墙钟
- 17:36
- Token
- 4.63M
- 首次改产品
- +5:40
- Operator
- 5
- 需求 Q
- 1
- 设计轮数
- 4
- Review / 修复
- 2 / 1
- Reviewer
- 2
- 设计获批
- 01:29:59
- 首个 Review Ready
- 01:37:28
- Review 通过
- 01:43:07
- Tool calls
- 57
- scoreN
- 2
- 状态
- completed
07 / WHAT THIS CAN SHOW
这是机制比较，不是第三臂因果结论
需求闭环确实增加了前置轮次
Requirement Loop 三条分别经历 5、4、4 次设计审批请求；对应的 operator 问题数为 1、2、2，首次产品修改都发生在 DESIGN_APPROVED 之后。
Review Loops 的实际轮数并不固定
当前 canonical 数据中 loop-01 经历 1 轮 reviewer、loop-04/06 各 2 轮；rerun 的首轮没有 critical/major，仅保留 1 个 minor，因此按 gate 直接通过。
成本要分均值与 pooled
页面以 per-run 平均占比为主，pooled totals 只显示绝对总体；Review Loops 的 reviewer token 计入其 treatment。
替换后的 ΔFeedback 只能描述
更新后的 pair-level 值为 +4.00、−1.50、+3.00，均值 +1.83；其中 pair-01 来自 posthoc rerun，不把它当作完整同期随机效果。
08 / EVIDENCE BOUNDARY
原始事实与派生判断分开看
原始 rollout 事实
- session parent / child 树与 actor role
- UTC timestamp 与工具动作
last_token_usage单次调用增量- operator turn、focused-test log 与最终状态
分类器派生
- UTC 时间戳、session 父子关系、actor role、tool call 和 last_token_usage 是原始 rollout 事实。
- 阶段、动作标签、阶段起止和首次产品修改是分类器派生；每段保留置信度与稳定的公开 evidence ID；完整未脱敏 JSONL 不发布。
- 阶段占比主口径是先按 run 归一化再对每组三个 run 求平均；pooled totals 只作辅助。
- 多泳道可以重叠；墙钟阶段图按全局相邻可见动作切片，不把 agent-seconds 相加。
- 新两组每条 run 有两次盲评；loop-01 的 canonical 分数来自 2026-08-01 独立 rerun，原始 93.5 保留为 superseded raw evidence，因此替换后的 pair-01 与其他 pair 不在同一执行窗口；历史 Slim / Full / Without 的评分不是同期批次，只作描述性对照。