一、测试概述
本报告对 AI Software Runtime（ASR）进行系统效果验证，从准确性、完整性、效率、鲁棒性四个维度，对比四种开发方案在相同任务（可研报告编译器 v4.3）上的表现。
1.1 四方案简介
opencode CLI
人工在终端输入一次 opencode 命令，模型 glm-4.7-fp8，单次完成
ASR 初版
ASR v1.2，CI=true（OMO 被抑制），glm-4.7-fp8，10 轮自动迭代
ASR+ 升级版
ASR v1.3，CI=false + OMO 完整编排，glm-4.7-fp8，10 轮自动迭代
longdoc 生产版
人工调用多种 AI 工具（WorkBuddy/OpenCode 等），200+ 轮交互，10 天
1.2 评测维度
| 维度 | 指标 | 测量方法 |
|---|
| 准确性 | 测试通过率、设计文档符合度 | pytest 客观结果 + Analyzer 语义偏差计数 |
| 完整性 | 代码量、Pack 配置完整度、Pack 元数据文件数 | 文件统计 + 目录结构对比 |
| 效率 | Token 消耗、迭代轮次、人工介入次数 | LLM token 追踪 + 时间戳分析 |
| 鲁棒性 | 连续全过轮次、退化回滚触发、收敛质量 | 收敛状态机事件日志 |
二、测试环境
| 配置项 | 参数 |
|---|
| 操作系统 | Linux（Docker 容器，8 核 / 32GB） |
| Python 版本 | 3.12.9（pyenv 管理） |
| ASR 系统版本 | v1.2（方案 B）/ v1.3（方案 C） |
| 主力 LLM 模型 | glm-4.7-fp8（200K context，本地 LiteLLM 代理） |
| Harness 工具 | OpenCode CLI 1.15.3 + oh-my-openagent 3.17.6（方案 C） |
| 最大迭代轮次 | 10 |
| 方案 A 模型 | glm-4.7-fp8（单模型直出，OMO 作为插件自动生效） |
| 方案 B 模型 | glm-4.7-fp8（CI=true，OMO 被抑制） |
| 方案 C 模型 | glm-4.7-fp8（CI=false，OMO 完整编排：IntentGate→Prometheus→Metis→Momus→Atlas→Sisyphus） |
| 方案 D 模型 | 多模型协作（WorkBuddy/DeepSeek-V4-Pro/GLM-5.1/MiniMax-M2.7/GLM-4.7-FP8） |
2.1 测试数据
| 项目 | 说明 |
|---|
| 设计文档 | DESIGN.md v4.3（1194 行），定义"可研报告编译器"系统 |
| 系统类型 | 超长超复杂系统（18+ 模块，7 Agent，13 Fact Schema，3 Pack 层） |
| 目标产出 | 完整 Python 可研报告编译器 + Pack 配置体系 + 测试套件 |
| 方案 A 数据源 | demo_dev/two/ — opencode CLI 单次运行结果 |
| 方案 B 数据源 | demo_dev/asr_10/.runtime/ — ASR 初版 10 轮日志 |
| 方案 C 数据源 | demo_dev/asr_10+/nohup.out + runtime/ + .runtime/ — ASR+ 升级版 |
| 方案 D 数据源 | longdoc/mvp/ — 生产代码 + 任务统计 |
三、四方案横向对比总表
| 指标 | 方案 A
opencode CLI | 方案 B
ASR 初版 | 方案 C
ASR+ 升级版 | 方案 D
longdoc 生产版 |
|---|
| runtime 核心代码行 |
3,733 |
4,956 |
4,691 |
22,720 |
| 总 Python 行数 |
5,699 |
6,212 |
6,724 |
22,720 |
| Python 文件数 |
22 |
~53 |
45 |
~180 |
| Pack 配置文件行数 |
1,118 |
3,906 |
5,463（62 文件） |
完整 |
| 测试文件数 |
5 |
2 |
14+（424 测试） |
12 |
| 测试通过率 |
N/A（手动验证） |
320/427（74.9%） |
409/424（96.5%） |
N/A（手动验证） |
| abc Pack 元数据 |
3 文件 ✅ |
2 文件 ❌
缺 pack-manifest.yaml |
3 文件 ✅
manif.+fact+rule |
完整 ✅ |
| 代码在项目目录 |
✅ |
❌ 仅在沙箱 |
✅ 正常运行 |
✅ |
| 迭代轮次 |
1（人工单次） |
10（自动） |
10（自动） |
200+（人工交互） |
| 人工介入次数 |
1 次 |
0 次 |
0 次 |
200+ 次 |
| 连续全过轮次 |
N/A |
0 轮 |
4 轮（R5-R8） |
N/A |
| 总 Token 消耗 |
~0.8M |
~39M |
~180M |
~500M（估计） |
| 核心能力差异 |
人工驱动，速度快 |
全自动但有缺陷 |
全自动 + OMO 编排 |
质量天花板，人工成本极高 |
ASR+ 关键突破： 去掉 CI=true 后，oh-my-openagent 的多智能体编排（IntentGate→Prometheus→Metis→Momus→Atlas→Sisyphus + Ralph 循环）完整生效。abc Pack 元数据从 2 文件缺失补全为 3 文件完整，测试通过率从 74.9% 提升到 96.5%，首次实现 4 轮连续全过（R5-R8 共 272/272）。
四、准确性维度：测试通过率与收敛曲线
4.1 四方案测试对比
| 方案 | 总测试数 | 通过数 | 通过率 | 失败类型 |
|---|
| opencode CLI | — | — | — | 无自动化测试覆盖 |
| ASR 初版 | 427 | 320 | 74.9% | ImportError、fixture 缺失、技能注册表路径错误 |
| ASR+ 升级版 | 424 | 409 | 96.5% | 错误处理验证用例（输入校验增强后预期行为变化） |
| longdoc 生产版 | — | — | — | 人工验证，无统一自动化测试 |
4.2 ASR+ 迭代收敛曲线
R1 · Builder
初始生成：22 文件，2,247 行
Token: 5.2M/53.9k · Tester 未生成测试（0/0）
R2 · Builder
大规模补全：66 文件，8,645 行
Token: 11.9M/96.2k · Tester 111/121（91.7%）· Analyzer 发现 8 偏差
R3 · Builder
修复 10 失败：94 文件，14,758 行
Token: 13.3M/98.7k · Tester 227/249（91.2%）· 测试大幅扩展
R4 · Builder
修复 22 失败：100 文件，16,291 行
Token: 13.3M/98.7k · Tester 248/272（91.2%）
R5 · Builder ✅ 收敛开始
修复 24 失败：102 文件，16,799 行
Token: 18.0M/127.9k · Tester 272/272 🎉 首轮全过！
R6 ✅ 连续全过
修复接口契约：103 文件，16,898 行
Token: 19.4M/133.9k · Tester 272/272 · 2 轮连续全过
R7 ✅ 连续全过
去除硬编码：103 文件，17,145 行
Token: 22.5M/146.4k · Tester 272/272 · 3 轮连续全过
R8 ✅ 连续全过
去除行业特定硬编码：103 文件，17,429 行
Token: 24.1M/155.5k · Tester 272/272 · 4 轮连续全过
R9 · 测试扩展
大规模测试补全：108 文件，17,472 行
Token: 26.9M/178.1k · Tester 402/424（94.8%）· +152 新测试
R10 · 最终态
修复 22 失败：108 文件，19,729 行
Token: 26.9M/178.1k · Tester 409/424（96.5%） · 剩余 15 为错误处理校验增强
核心发现： ASR+ 在 R5 首次达成全过（272/272），此后 R6-R8 连续 4 轮保持全过，同时持续改进代码质量（去除硬编码、修复接口契约）。这是 ASR 系统首次展现出"收敛+持续优化"的能力。R9 测试大幅扩展引发新失败，R10 迅速修复到 96.5%。
五、完整性维度：代码产出与 Pack 配置
5.1 代码产出对比
4,691
ASR+ 升级版（24 .py 文件）
5.2 Pack 配置完整度对比
| Pack 组件 | opencode CLI | ASR 初版 | ASR+ 升级版 | longdoc 生产版 |
|---|
| abc/pack.yaml | ✅ | ✅ | ✅ | ✅ |
| abc/meta/pack-manifest.yaml | ✅ | ❌ 缺失 | ✅ | ✅ |
| abc/meta/fact-schema.yaml | ✅ | ✅ | ✅ | ✅ |
| abc/meta/rule-schema.yaml | ❌ | ❌ | ✅（新增） | ✅ |
| base Pack | ❌ | 部分 | ✅（完整） | ✅ |
| llm_corpus Pack | 部分 | 完整 | ✅（62 文件） | ✅ |
| Pack 配置总行数 | 1,118 | 3,906 | 5,463 | 完整 |
ASR+ 的 Pack 完整度超越了 CLI 单次生成： abc/meta/ 补齐了 pack-manifest.yaml，新增了 rule-schema.yaml；base Pack 从"部分实现"变为"完整实现"；llm_corpus Pack 达到 62 个文件。这是 CI=false 后 OMO 完整编排的直接效果——Prometheus 规划 + Metis 缺口分析 + Ralph 循环确保了"按 DESIGN.md 逐项落实"。
关于代码量： ASR 初版（4,956 行）与 ASR+（4,691 行）生成的 runtime 代码量几乎持平（差距仅 265 行，5.3%）。早前报告中出现的"ASR 初版 8,343 行"是统计口径错误（包含了 .asr_sandbox/ 沙箱文件），已在本版修正。两版 runtime 核心代码规模在同一量级，但 ASR+ 在代码组织（agents/kernel/utils 三层）、Pack 配置深度、测试覆盖率和收敛稳定性上全面占优。
六、效率维度：Token 消耗与时间分析
6.1 Token 消耗对比
| 方案 | 总 Token | Prompt Token | Completion Token | 每轮均值 | 人工介入 |
|---|
| opencode CLI | ~0.8M | ~0.8M | ~7K | — | 1 次 |
| ASR 初版 | ~39M | ~38M | ~227K | ~3.9M | 0 次 |
| ASR+ 升级版 | ~180M | ~179M | ~1.2M | ~18M | 0 次 |
| longdoc 生产版 | ~500M（估计） | — | — | — | 200+ 次 |
6.2 ASR+ 各阶段 Token 分布
| 轮次 | Builder | Tester | Analyzer | 本轮总计 |
|---|
| R1 | 5.3M | 0.3M | 0.3M | 5.9M |
| R2 | 11.9M | 2.7M | 1.0M | 15.6M |
| R3 | 13.3M | 4.4M | 1.7M | 19.4M |
| R4 | 13.3M | 6.0M | 4.0M | 23.3M |
| R5 | 18.0M | 7.9M | 4.7M | 30.6M |
| R6 | 19.4M | 8.7M | 5.3M | 33.4M |
| R7 | 22.5M | 11.4M | 6.0M | 39.9M |
| R8 | 24.1M | 12.9M | 6.1M | 43.1M |
| R9 | 24.1M* | 17.7M | 6.8M | 48.6M |
| R10 | 26.9M | 20.7M | 7.3M | 54.9M |
* R4/R9 的 Builder prompt token 为继承自上一轮（无实际新修复时沿用 session），Completion 仍有新产出。
Token 效率分析： ASR+ 的总 Token（~180M）是 ASR 初版（~39M）的 4.6 倍。增长主要来自：OMO 多智能体编排的 Plan/Review 链（约 2-3x）和 Tester 的大规模测试扩展（R9 新增 152 测试）。但换来的是 96.5% 测试通过率 + 完整 Pack 配置 + 4 轮连续全过，属于"更多 Token 换更高确定性"的合理权衡。
七、鲁棒性维度：收敛质量与系统稳定性
7.1 收敛状态对比
| 指标 | ASR 初版 | ASR+ 升级版 |
|---|
| 最终状态 | STUCK（max_iterations） | STUCK（max_iterations） |
| 最高测试通过 | 320/427（74.9%，R3） | 409/424（96.5%，R10） |
| 连续全过轮次 | 0 | 4 轮（R5-R8） |
| 退化回滚触发 | 0 次 | 0 次 |
| 代码在项目目录 | ❌（仅 sandbox） | ✅ 正常 |
| Pack 元数据完整 | ❌ 缺失 pack-manifest.yaml | ✅ 完整（3 文件） |
| 收敛质量评分 | ★★☆☆☆ | ★★★★☆ |
7.2 ASR+ 新增的鲁棒性表现
| 特征 | 描述 |
|---|
| OMO 编排鲁棒性 | IntentGate 意图分类 + Prometheus 规划 + Metis 缺口分析 + Momus 审查 + Atlas 分发执行，完整五阶段流水线确保每轮修复有方向 |
| Ralph 持续工作 | "持续工作直到 TODO 全部完成"机制，Builder 不再"差不多就停"——R5 起每次修复都逐项对照 Analyzer 反馈 |
| 测试扩展抗退化 | R9 新增 152 测试后 22 失败，R10 迅速修复到仅 15 失败（仅错误处理校验增强类）——展示了"测试扩展→定向修复"的正循环 |
| 代码质量持续提升 | R5-R8 连续全过期间仍在优化：R6 修复接口契约、R7 去除硬编码、R8 去除行业特定硬编码——实现了"跑通之后还能更好" |
八、关键洞察与根因分析
8.1 CI=true 对 OMO 编排的抑制效应
| 对比维度 | CI=true（ASR 初版） | CI=false（ASR+ 升级版） |
|---|
| Builder 产出 | 代码仅存于 sandbox，项目目录为空 | 代码正常存在于项目目录 |
| abc Pack 元数据 | 缺失 pack-manifest.yaml | 3 文件完整 + 新增 rule-schema.yaml |
| Pack 配置深度 | 3,906 行 | 5,463 行（+40%） |
| 测试通过率 | 74.9% | 96.5%（+21.6pp） |
| 连续全过轮次 | 0 | 4 轮 |
根因： CI=true 让 oh-my-openagent 检测到"自动化环境"，跳过 Prometheus 规划访谈、Momus 审查循环、Ralph 持续工作循环。这三个环节正是 OMO 相较单模型 opencode 的核心优势。去掉 CI=true 后，ASR 的每个 Agent 享有了与 CLI 人工操作同级别的多智能体编排能力。
8.2 四方案定位总结
⚡ 快
单次 5.3M Token 出结果
但无保证、无收敛
适合原型快速验证
🔄 自动
10 轮自动迭代
但 CI=true 压制了编排
测试通过率 74.9%
🎯 准
OMO 完整编排
测试通过率 96.5%
4 轮连续全过
Pack 配置最完整
🏭 全
200+ 轮人工交互
10 天开发周期
质量天花板
但无法自动化
九、综合评估与结论
| 维度 | opencode CLI | ASR 初版 | ASR+ | longdoc |
|---|
| 准确性 | N/A | ★★★ | ★★★★★ | ★★★★ |
| 完整性 | ★★ | ★★★ | ★★★★ | ★★★★★ |
| 效率（自动化） | ★ | ★★★★ | ★★★★★ | ★ |
| 鲁棒性 | ★ | ★★ | ★★★★ | ★★★ |
核心结论
- ASR+（CI=false + OMO）在自动化开发质量上显著优于初版： 测试通过率从 74.9% 提升到 96.5%（+21.6pp），Pack 元数据从缺失变为完整（3 文件 + 新增 rule-schema.yaml），首次实现 4 轮连续全过。
- OMO 多智能体编排是 ASR 质量提升的关键因子： IntentGate（意图分类）+ Prometheus（规划）+ Metis（缺口分析）+ Momus（审查）+ Atlas（分发）+ Ralph（持续完成）的六阶段流水线，让 Builder 从"差不多就停"变为"逐项对照 DESIGN.md 落实"。
- ASR 自动生成的代码规模与 longdoc 仍有量级差距： ASR 两版均生成约 4,700-5,000 行 runtime（与 opencode CLI 的 3,733 行同量级），而 longdoc 经 200+ 轮人工开发达到 22,720 行。差距主要在于 longdoc 经历了更完整的开发周期（10 天 vs ASR 的 10 轮），说明 ASR 在更长的迭代轮次中仍有提升空间。
- 四方案定位清晰： opencode CLI 适合快速原型；ASR 提供了自动化收敛机制但需 OMO 协同；ASR+ 已证明自动化 + 编排 = 96.5% 通过率；longdoc 是质量天花板但无法自动化。
附录
A. 四方案数据来源
| 方案 | 路径 | 数据源 |
|---|
| opencode CLI | demo_dev/two/ | IMPLEMENTATION_STATUS.md + wc -l 直接统计 |
| ASR 初版 | demo_dev/asr_10/ | nohup.out + .runtime/events/ + .runtime/logs/llm.jsonl |
| ASR+ 升级版 | demo_dev/asr_10+/ | nohup.out + .runtime/logs/llm.jsonl + wc -l 直接统计 |
| longdoc 生产版 | longdoc/mvp/ | WorkBuddy 任务统计（36 任务，04-14~04-23）+ 代码行统计 |
B. ASR+ 最终项目结构
asr_10+/
├── runtime/ # 核心运行时（4,691 行，24 .py 文件）
│ ├── agents/ # 7 Agent（requirement/feature/hardware/software_arch/budget/compliance/lifecycle）
│ ├── core/ # 核心（loader/fact_store/patch_log）
│ ├── context/ # 上下文构建
│ └── skills/ # 技能注册表
├── packs/ # Pack 配置体系（62 文件，5,463 行）
│ ├── abc/ # 元数据（3 文件完整）
│ │ ├── pack.yaml
│ │ └── meta/
│ │ ├── pack-manifest.yaml
│ │ ├── fact-schema.yaml
│ │ └── rule-schema.yaml
│ ├── base/ # commons Pack（skills/diagrams/tech_stacks）
│ └── llm_corpus/ # domain Pack（config/fact_schema/knowledge/rules/skills/templates）
└── tests/ # 测试文件（14+ 文件，424 测试）
C. 修订记录
| 版本 | 日期 | 说明 |
|---|
| v1.0 | 2026-05-28 | 初版：opencode CLI vs ASR 初版 vs longdoc 三方案对比 |
| v2.0 | 2026-05-29 | 新增 ASR+（CI=false + OMO）方案；更新四方案横向对比；补充 Pack 完整度、连续全过轮次等新指标 |