sanguo/sanguo_moziplus_v2

Fork 0

Files

T

cfdaily a18bd13e1d auto-sync: 2026-05-15 09:31:37

2026-05-15 09:31:37 +08:00

35 KiB

Raw Blame History

调研报告：挑战/评审体系 + 质量门控结构化

日期: 2026-05-15 作者: 庞统士元 (pangtong-fujunshi) 版本: v2.6-research-03 用途: moziplus v2.6 AI Native DevOps 平台设计参考

课题 3：挑战/评审体系设计

已有经验（知识库/wiki + v1.0 三层实践）

知识库已有调研

我们在 gate-mechanism-research.md（2026-05-11）中已经做过一轮质量门控调研，识别出四种模式：

模式	代表项目	强制力	信任模型
LLM 自律型	Claude Code、PAV skill	❌ 弱	信任 LLM
角色分工评审	oh-my-claudecode	⚠️ 中	不信任，靠隔离
Guardrail 中断	OpenAI Agents SDK	✅ 强	不信任，靠代码
DAG 条件流转	TradingAgents / LangGraph	✅ 强	不信任，靠结构

核心结论（上一轮调研）：

业界共识：不信任 LLM 自律
检查的是产出，不是过程
Guard 定义与执行分离（声明式规则 + 代码层执行）
失败处理有层级：block → retry → escalate
不同任务类型不同标准

v1.0 三层挑战控制回顾

moziplus v1.0 PRD 定义了三层挑战：

层级	机制	参与者	触发时机
第 1 层：Agent 自律 PAV	Plan→Act→Verify skill	执行者自己	每个节点开始时
第 2 层：节点 review	司马懿独立评审	司马懿（或挑战者池）	每个节点完成时
第 3 层：最终整合审查	庞统汇总 + 司马懿终审	庞统 + 司马懿	任务完成时

PRD 的铁律 IR-1 规定：每个任务至少 2 个 Agent（做 + 挑战）。IR-2 规定：每个节点都是 Plan → Execute → Validate。

v2.6 架构现状

v2.6 架构文档中：

任务状态流转：pending → claimed → working → review → done（review 是状态机中的一个状态）
review → pending（审核不通过打回）是合法转换
挑战者由庞统在黑板上分配（assigned_by 字段）
评审结果目前只有 comments 表（自然语言评论），缺乏结构化

业界优秀实践对比表（课题3）

1. Superpowers：三阶段审查（implementer → spec reviewer → code quality reviewer）

项目: obra/superpowers — Agentic Skills Framework for Claude Code

核心机制:

Superpowers 的 subagent-driven-development 流程采用两阶段串行审查（不是三阶段，实际是两个独立 reviewer 串行执行）：

Implementer subagent 执行任务
    ↓
Spec Reviewer subagent → 检查实现是否符合计划/需求规格
    ↓ (必须通过)
Code Quality Reviewer subagent → 检查代码质量（clean, tested, maintainable）
    ↓
下一任务

关键设计细节:

维度	Spec Reviewer	Code Quality Reviewer
关注点	实现是否匹配计划	代码是否干净/可测/可维护
检查内容	功能完整性、与计划偏离、遗漏需求	单一职责、接口清晰度、测试覆盖
模型选择	用最强模型	用最强模型
顺序	先执行（必须通过）	后执行（spec 通过后才触发）
失败处理	标记偏离，返回给 implementer	修改建议返回给 implementer

Implementer 报告四种状态：

task_completed — 完成且无需修改
task_completed_with_notes — 完成，但有注意事项
task_blocked — 被阻塞，需要人介入
task_failed — 失败

关键洞察:

审查粒度是每个任务，不是每个文件 — 每个 subagent 完成一个 engineering task 后立即审查
串行门控 — spec review 必须通过后才做 code quality review，两个是串联的
审查者也是独立 subagent — 不是同一个 agent 的不同角色，是独立的 spawned agent
并行执行但串行审查 — 多个 independent tasks 可以并行执行，但每个 task 的审查是串行的（参考 issue #469）
不靠 LLM 自律 — 审查是系统自动触发，不依赖 implementer 自觉

2. TradingAgents：多空辩论（Bull↔Bear + Judge 裁决）

项目: TauricResearch/TradingAgents — Multi-Agent LLM Financial Trading Framework

核心机制:

TradingAgents 构建了5 层结构化对抗：

[4 位分析师并行] → 各自独立分析
    ↓
[Bull Researcher ↔ Bear Researcher] → 多空辩论（交替辩论，最多 max_debate_rounds 轮）
    ↓
[Research Manager] → 裁决，综合双方论据
    ↓
[Trader（3 级风险偏好）] → 根据研究报告做交易决策
    ↓
[Aggressive ↔ Conservative ↔ Neutral] → 风控三方辩论
    ↓
[Portfolio Manager] → 最终决策（Buy/Overweight/Hold/Underweight/Sell）

关键设计细节:

维度	研究辩论	风控辩论
参与者	Bull vs Bear（2 方）	Aggressive vs Conservative vs Neutral（3 方）
轮次控制	`max_debate_rounds` 限制	条件边 `should_continue_debate`
裁决者	Research Manager	Portfolio Manager
输出	综合研究报告	最终交易决策

条件边实现（LangGraph）：

workflow.add_conditional_edges(
    "Bull Researcher",
    should_continue_debate,
    {
        "Bear Researcher": "Bear Researcher",
        "Research Manager": "Research Manager"
    }
)

关键洞察:

结构化对抗 = 特殊的 Exit Gate — 不是检查产出文件，而是校验决策质量
辩论机制天然提供多视角审查 — 不需要额外的 reviewer agent
条件边让流转逻辑图化、可验证
适用于需要多角度论证的决策场景 — 投资/交易/方案选择
2026-04 v0.2.4 新增：structured-output agents（Research Manager/Trader/Portfolio Manager），LangGraph checkpoint resume

3. oh-my-claudecode：ralplan（Planner→Architect→Critic 三方共识）

项目: Yeachan-Heo/oh-my-claudecode — Teams-first Multi-agent orchestration for Claude Code

核心机制:

ralplan（Radical Planning）编排三个专业 Agent，在迭代循环中达成共识：

Planner Agent → 输出初始计划
    ↓
Architect Agent → 从架构视角审查/修正
    ↓
Critic Agent → 从批判视角挑战
    ↓
是否达成共识？
    ├── 是 → 输出最终计划
    └── 否 → 回到 Planner，循环继续

三种模式:

模式	命令	适用场景
基础模式	`ralplan "描述"`	普通规划
共识模式	`ralplan --consensus "描述"`	重要决策
深思熟虑模式	`ralplan --deliberate "描述"`	高风险场景

Critic 角色（继承自 oh-my-claudecode 的 Critic 设计）：

阶段	描述
预判 Pre-commitment	读代码前先预测 3-5 个最可能的问题
验证 Verification	逐一检查每个文件引用和函数调用
多视角审查 Multi-perspective	安全/运维/新人三个角度
缺口分析 Gap analysis	主动找"缺失的东西"
自审 Self-audit	低置信度发现降级为 Open Questions

Critic 工具限制：disallowedTools: Write, Edit — 硬编码禁用修改工具，保证评审独立性。

Verdict 只有 4 种：REJECT / REVISE / ACCEPT-WITH-RESERVATIONS / ACCEPT

关键洞察:

三方共识比双方更健壮 — Planner(规划) + Architect(架构) + Critic(批判)，三方相互制衡
共识模式有明确退出条件 — 达成共识或超时
Critic 工具被硬编码禁用 — 不是 prompt 建议，是代码层面的限制
适合规划/设计阶段，不适合执行阶段 — ralplan 产出的是计划，不是代码
每种模式有不同的严谨程度 — 按风险级别选择

4. OpenAI Agent SDK：OutputGuardrail + 声明式 Guardrail

项目: OpenAI Agents SDK — 官方 Agent 框架

核心机制:

OpenAI Agent SDK 提供三种 Guardrail：

类型	触发时机	作用
Input Guardrail	Agent 执行前	检查输入合法性
Output Guardrail	Agent 执行后	检查产出达标
Tool Guardrail	每次工具调用前后	检查工具调用合法性

Tripwire 机制：

@output_guardrail
async def guardrail_fn(ctx, agent, output):
    result = await Runner.run(guardrail_agent, output)
    return GuardrailFunctionOutput(
        tripwire_triggered=result.final_output.is_invalid  # True = 立即中断
    )

执行模式：

blocking（推荐）— Guardrail 先执行，通过后才启动主 Agent
parallel — Guardrail 和主 Agent 同时跑（不适合长任务 Agent，因为 token 已消耗）

关键洞察:

Guardrail 本身也是 Agent — 可以用小模型做快速检查，成本可控
触发 tripwire = 抛异常 = 流程立即停止 — 代码层面的强制执行
声明式定义 + 程序式执行 — 规则声明为函数/配置，执行由框架保证
Input Guardrail 只在第一个 Agent 执行，Output Guardrail 只在最后一个 Agent 执行
Tool Guardrail 粒度最细 — 每次工具调用都可以检查

5. 其他优秀实践

5.1 Edict 的门下省审核（封驳打回机制）

项目: cft0808/edict — 三省六部制 Multi-Agent Orchestration

核心流程：

皇上 → 太子分拣 → 中书省规划 → 门下省审议 → 尚书省派发 → 六部执行 → 回奏
                                  ↑                │
                                  └── 封驳打回 ─────┘

门下省角色：

质量管控中心 — 对中书省方案进行质量评审、风险识别与标准把控
封驳权 — 不合格方案可直接"封驳"，打回中书省重新规划
状态机：已派发 → 执行中 → 待审查 → 已完成，中间可 阻塞 Blocked

关键洞察:

封驳打回是一种方向级否决 — 不只是修改建议，而是"方案不对，重来"
门下省是独立于执行链的审核层 — 不参与执行，只负责审核
类似 moziplus 中司马懿的角色定位

5.2 wanman 的评估引擎（三阶段 explore→evaluate→execute）

项目: chekusu/wanman — Agent Matrix Runtime

核心流程：

Explore 阶段 → 多 Agent 并行探索，收集方案
    ↓
Evaluate 阶段 → 评估引擎打分（4 维度加权）
    ↓
Execute 阶段 → 执行最优方案

评估维度（据 PRD 中描述）：

Feasibility（可行性）
Risk（风险）
Impact（影响）
Cost（成本）

信心度机制：信心度 < 0.7 升级到人工审批。

关键洞察:

量化评估比定性评估更可追溯 — 4 维度加权打分，不是"感觉行不行"
阈值自动升级 — 信心度低于阈值自动升级，不需要人判断
适合方案选择场景 — 多个方案用同一标准评估

5.3 SWE-agent 的 RetryLoop（多次尝试 + Reviewer 选最优）

项目: SWE-agent/SWE-agent — AI Software Engineering Agent

核心机制：

agent:
  type: retry
  retry_loop:
    cost_limit: 6.00
    max_attempts: 3
    agent_configs:
      - <config 1>  # 可能用不同的 prompt
      - <config 2>  # 可能用不同的 model

多次独立尝试 — 可以用不同配置（prompt/model/参数）尝试多次
预算继承 — 每次尝试继承上一次失败后剩余的预算，不浪费
Reviewer LLM 选最优 patch（tools/review_on_submit_m）
Trajectory 审计 — 每次尝试的完整轨迹都保存，可回溯

关键洞察:

多尝试优于单次完美 — LLM 输出有随机性，多次尝试取最优是务实策略
Trajectory 是审计基础 — 完整保留每次尝试的过程，可以对比分析
实际效果：SWE-agent 团队承认 reviewer 有时"rejects correct patches" — LLM 评审不是万能的

综合对比表

项目	审查模式	强制力	粒度	协商轮次	失败处理	声明式
Superpowers	串行双审（spec→quality）	✅ 系统触发	每任务	0（只审不改）	返回 implementer	❌ 硬编码
TradingAgents	多空辩论 + 裁决	✅ 图结构	每决策	max_debate_rounds	裁决者决定	✅ 条件边
oh-my-claudecode	三方共识循环	⚠️ prompt	规划阶段	共识达成	循环/超时	❌ prompt
OpenAI Agent SDK	Input/Output Guardrail	✅ 代码层	每工具调用	0（tripwire）	抛异常停止	✅ 声明式
Edict	门下省封驳	⚠️ 状态机	每方案	封驳打回	打回中书省	✅ 状态机
wanman	量化评估打分	✅ 阈值	每方案	0	低于阈值升级	✅ 声明式
SWE-agent	多次尝试取最优	✅ 代码层	每任务	max_attempts	reviewer 选最优	✅ YAML 配置

v1.0 三层体系评估

三层体系分析

层级	机制	优点	缺点
第 1 层：PAV	Agent 自律 Plan→Act→Verify	轻量、无额外成本	依赖模型自觉，skill 是"菜单"不是"触发器"，实践中经常被忽略
第 2 层：节点 review	司马懿独立评审	独立视角、有结构化 verdict	每个节点都审过重（成本高、延迟大），协商轮次固定 3 轮不够灵活
第 3 层：最终整合审查	庞统汇总 + 司马懿终审	全局视角、质量兜底	和第 2 层重复（司马懿审了两次），庞统的角色定位模糊

三层是否高效？

结论：不够高效，主要体现在：

第 1 层形同虚设 — PAV 是 prompt 层面的约束，模型可以忽略。张飞调查报告（Mail #214）已证明 skill 是"菜单"不是"触发器"
第 2 层过重 — 每个节点产出都过司马懿，对于简单任务（如格式化输出、数据搬运）是过度审查
第 2 层和第 3 层重复 — 司马懿既审每个节点又审最终整合，角色重叠
没有任务类型适配 — 编码任务、调研任务、数据任务用同一个审查标准，不灵活

三层是否足够？

结论：在特定场景下不够：

缺少方案阶段审查 — 只审产出，不审方案。编码前的方案设计没有独立审查
缺少量化评估 — 只有 pass/fail/revise，没有打分机制，难以对比多方案
缺少安全红线 — 没有 tripwire 机制，危险操作没有代码级拦截
缺少并行审查 — 只有一个审查者（司马懿），没有多视角对抗

三层是否过重？

结论：在简单任务上过重，在复杂任务上不够 — 需要分级。

任务类型	方案审查	产出审查	审查模式	最大轮次
高风险（生产部署/资金操作）	✅ 必须独立审查	✅ 独立审查 + 安全 Guardrail	对抗（多空辩论）	5 轮
标准（编码/设计/架构）	✅ 方案过挑战	✅ 产出过挑战	单审（指定挑战者）	3 轮
低风险（文档/格式化/数据搬运）	❌ 跳过	⚡ 轻量 Guardrail（格式检查）	自动检查	0 轮
调研/分析	❌ 跳过	✅ 结论过挑战	单审	2 轮

改进点	v1.0	v2.6 推荐
第 1 层 PAV	依赖模型自律	替换为声明式 Output Guardrail — 系统自动执行，不依赖模型
第 2 层节点 review	每个节点都审	分级审查 — 按任务类型和风险级别选择审查深度
第 3 层最终整合	司马懿再审一次	保留但简化 — 只在高风险任务终审，标准任务由最后节点的审查覆盖
方案审查	❌ 无	✅ 新增方案先审 — 关键节点先审方案再执行
量化评估	❌ 无	✅ 可选 — 支持打分机制（参考 wanman），信心度 < 0.7 升级
对抗辩论	❌ 无	✅ 高风险任务启用多视角对抗（参考 TradingAgents）

课题 5：质量门控结构化

业界优秀实践对比表（课题5）

1. Control Center 的 Task Store（artifacts + rollback + review 结构）

项目: keshrath/agent-tasks（参考 Control Center 模式）

核心结构：

Task
├── definitionOfDone（完成标准）
├── artifacts[]（产出物列表，按 stage 组织）
│   ├── id, stage, type, path, metadata
│   └── version（版本化）
├── comments[]（评论，结构化）
├── dependencies[]（依赖关系）
└── pipeline（流水线配置）
    └── stages[]（阶段定义 + 审查规则）

API 设计：

GET /api/tasks/:id/artifacts — 按 stage 过滤产出物
PUT /api/tasks/:id/stage — 推进/回退阶段（支持 regress）
POST /api/tasks/:id/comments — 添加评论

关键洞察:

Artifacts 按 stage 组织 — 每个阶段有独立的产出物列表
支持阶段回退（regress） — 不只是前进，可以打回
definitionOfDone 是结构化的 — 不是自然语言描述，是可验证的条件列表

2. SWE-agent 的 Trajectory 审计

项目: SWE-agent/SWE-agent

核心机制:

SWE-agent 的每次尝试产生一个 Trajectory（轨迹），是完全线性的事件序列：

Trajectory = [
  { step: 1, action: "open_file", args: {...}, observation: "..." },
  { step: 2, action: "search", args: {...}, observation: "..." },
  { step: 3, action: "edit", args: {...}, observation: "..." },
  ...
  { step: N, action: "submit", args: {...}, observation: "patch applied" }
]

线性追加 — 每个步骤只是追加到 messages，不修改历史
轨迹 = 消息 — trajectory 和传给 LLM 的 messages 是同一个东西
可回溯 — 完整保留每次尝试的所有步骤
Trajectory Inspector — 命令行工具，可以滚动查看数百条轨迹

在 RetryLoop 模式下：

多次尝试产生多条 Trajectory
Reviewer LLM 对比多条 Trajectory，选择最优 patch
所有 Trajectory 都保存，可用于后续分析

关键洞察:

审计粒度是每步操作 — 不是每任务，是每个 action
不可变追加 — 不修改历史记录，只追加新记录
多次尝试可对比 — 重试机制下保留所有尝试的轨迹

3. Hermes 的 Comment 线程 + 结构化状态

项目: NousResearch/hermes-agent — Kanban Multi-Agent Board

核心结构：

Hermes 的 Kanban 系统中，Comment 是持久化标注通道：

kanban_comment:
  - id, task_id, author, body, metadata JSON, created_at

关键设计:

机制	描述
Comment 即审计	所有审计相关字段（changed_files, tests_run, diff_path, PR url, decisions）都放在 comment 的 metadata 中
Block with reason	`kanban_block` 带理由，reason 前缀 `review-required:` 表示等待审查
Bulk-close guard	不允许批量 close 多个 task 用同一个 summary — 因为每个 task 的元数据是不同的
Worker lanes	每次执行产生独立的 worker lane，reviewer 看到完整的 comment thread
Structured metadata	接受标准（acceptance criteria）写在 spec metadata 中，engineer 的 worker 自动看到

审查流程：

Engineer 完成工作
    → 写 structured metadata 到 kanban_comment
        (changed_files, tests_run, diff_path, decisions)
    → kanban_block "review-required: 等待审查"
    → Reviewer 看到 comment thread + metadata
    → Reviewer 批准: kanban_unblock
    → Reviewer 要求修改: 再写 comment，下次 worker 运行时看到

关键洞察:

Comment 是主要通信和审计通道 — 不只是讨论，是结构化数据的载体
metadata JSON 承载结构化数据 — body 是人类可读的，metadata 是机器可读的
Block reason 前缀约定 — 用前缀区分 block 类型（review-required / blocked-by / waiting-on）
每次执行独立的 worker lane — 不同次执行的结果不会混淆

4. 其他优秀实践

4.1 PRD 中定义的 review_result JSON

moziplus PRD v1.0 已定义了结构化评审结果：

{
  "review_id": "uuid",
  "task_id": "uuid",
  "stage_id": "coding",
  "reviewer": "simayi",
  "verdict": "approved|rejected|needs_revision",
  "issues": [
    {
      "severity": "critical|major|minor",
      "location": "文件:行号 或 方案:章节",
      "description": "问题描述",
      "suggestion": "修改建议"
    }
  ],
  "round": 1,
  "max_rounds": 3,
  "consensus_reached": true
}

优点：结构清晰，verdict 明确，issues 可追溯不足：没有信心度/评分，没有关联到产出物，没有历史版本

4.2 GitHub PR Review 的结构化模式

GitHub PR Review API 提供了业界最成熟的结构化审查模式：

Pull Request Review:
├── event: APPROVE | REQUEST_CHANGES | COMMENT
├── body: "总结性评论"
└── comments[]:
    ├── path: "src/file.py"
    ├── position: 42
    ├── body: "这行有问题"
    ├── in_reply_to_id: (支持嵌套回复)
    └── side: LEFT | RIGHT

关键特性：

三种 verdict：APPROVE / REQUEST_CHANGES / COMMENT — 明确表达意图
行级定位：comment 精确到文件+行号
嵌套回复：支持 comment 线程中的子讨论
review 和 comment 分离：review 是整体评审，comment 是行级细节
多 reviewer 支持：多个 reviewer 可以各自提交独立的 review

4.3 代码审查工具的结构化输出模式

业界代码审查工具（SonarQube / CodeClimate / reviewdog）的共同模式：

Review Output:
├── summary: { verdict, score, total_issues }
├── issues[]:
│   ├── severity: critical | major | minor | info
│   ├── rule_id: "S1234" (规则 ID，可查文档)
│   ├── location: { file, line, column }
│   ├── message: "问题描述"
│   └── suggestion: "修改建议"
└── metadata:
    ├── tool_version
    ├── analyzed_files
    └── duration_ms

共同特点：

severity 有标准分级（critical/major/minor/info）
location 精确到文件+行+列
rule_id 关联到可查的规则文档
summary 包含总体评分和统计

综合对比表（课题5）

项目	评审存储位置	结构化程度	可追溯性	多轮支持	关联产出
Control Center	Task Store（内置）	✅ artifacts + stage	✅ 版本化	⚠️ 阶段回退	✅ artifact 关联
SWE-agent	Trajectory 文件	✅ 每步结构化	✅ 线性追加	✅ 多次尝试	✅ patch 关联
Hermes	Comment metadata JSON	✅ 结构化 metadata	✅ 追加写入	✅ worker lanes	✅ 手动关联
moziplus PRD	comments 表	⚠️ 自然语言为主	❌ 无版本	❌ 无	❌ 无
GitHub PR Review	Review API	✅ 行级定位	✅ 嵌套回复	✅ 多 reviewer	✅ diff 关联
代码审查工具	独立输出	✅ rule_id + severity	✅ 标准化	❌ 单次	⚠️ 工具特定

推荐方案：评审结果存储与结构

设计原则

黑板索引 + 文件详情 — 黑板存储结构化摘要（索引），文件系统存储完整评审记录（详情）
追加写入，不修改历史 — 每轮评审是新的记录，不覆盖旧记录
结构化 verdict — 评审结论必须是枚举值，不是自然语言
关联产出物 — 评审记录通过 output_id 关联到具体产出
人类可读 + 机器可读 — body 给人看，metadata 给程序用

评审详情文件结构

tasks/{task_id}/
├── output.md                          # 任务产出
├── output.json                        # 产出元数据
└── reviews/
    ├── rev-001-round1.json            # 第 1 轮评审
    ├── rev-001-round2.json            # 第 2 轮评审（协商后修改）
    └── rev-001-round3.json            # 第 3 轮评审（最终通过）

评审详情 JSON：

{
  "review_id": "rev-001",
  "task_id": "task-001",
  "output_id": "out-001",
  "reviewer": "simayi-challenger",
  "review_type": "output_review",
  "verdict": "needs_revision",
  "confidence": 0.65,
  "round": 1,
  "max_rounds": 3,
  "summary": "代码逻辑正确但缺少错误处理和单元测试",
  "issues": [
    {
      "id": "iss-001",
      "severity": "critical",
      "category": "correctness",
      "location": "src/trading.py:42",
      "description": "未处理网络超时异常",
      "suggestion": "添加 try-except 包装，设置 30s 超时",
      "rule_id": "ERR-001"
    },
    {
      "id": "iss-002",
      "severity": "major",
      "category": "testing",
      "location": "tests/",
      "description": "缺少单元测试",
      "suggestion": "至少覆盖正常路径和异常路径",
      "rule_id": "TEST-001"
    }
  ],
  "positives": [
    "代码结构清晰，职责分离做得好",
    "命名规范，可读性强"
  ],
  "metadata": {
    "model": "zhipu/glm-5.1",
    "duration_ms": 12500,
    "files_reviewed": ["src/trading.py", "src/utils.py"],
    "total_lines_reviewed": 150
  },
  "created_at": "2026-05-15T10:30:00Z"
}

Guardrail 自动检查结果

Guardrail 检查结果也存入 reviews 表（review_type = 'guardrail'），但来源是系统自动执行：

{
  "review_id": "rev-auto-001",
  "reviewer": "system",
  "review_type": "guardrail",
  "verdict": "rejected",
  "issues": [
    {
      "severity": "blocking",
      "rule_id": "GUARD-FILE-EXISTS",
      "description": "产出文件不存在: output.md",
      "location": null
    }
  ],
  "metadata": {
    "guardrail_config": "guardrails.yaml#coding.output_guardrails",
    "checks_run": 3,
    "checks_passed": 2,
    "checks_failed": 1
  }
}

评审产出物与任务产出物的关系

Task (task-001)
├── Output 1 (out-001) → 编码产出
│   ├── Review 1 (rev-001, plan_review, round 1) → 方案评审
│   ├── Review 2 (rev-002, guardrail, round 1) → 自动 Guardrail
│   └── Review 3 (rev-003, output_review, round 1) → 产出评审
│       └── Review 4 (rev-004, output_review, round 2) → 协商后再审
└── Output 2 (out-002) → 测试报告
    └── Review 5 (rev-005, output_review, round 1) → 测试产出评审

关系规则：

一个 output 可以有多个 review（多轮协商）
一个 review 关联一个 output（不跨产出）
review 按时间追加，不修改历史（round 递增）
黑板只存摘要（verdict + summary + round），完整详情在文件

多轮协商的追溯

-- 查看某个任务的所有评审历史
SELECT r.id, r.round, r.verdict, r.summary, r.created_at
FROM reviews r
WHERE r.task_id = 'task-001'
ORDER BY r.created_at ASC;

-- 查看某个产出的最新评审
SELECT * FROM reviews
WHERE output_id = 'out-001'
  AND review_type = 'output_review'
ORDER BY round DESC
LIMIT 1;

对比现有 comments 表的改进

维度	现有 comments 表	推荐 reviews 表
数据类型	自然语言	结构化 JSON
结论	无（靠读 body 推断）	✅ verdict 枚举
关联产出	❌ 只关联 task	✅ 关联 output
评分	❌ 无	✅ confidence + scores
轮次追踪	❌ 无	✅ round + max_rounds
评审类型	❌ 无	✅ plan_review / output_review / guardrail / final_review
详情	❌ body 只有自然语言	✅ body + detail_path 文件

comments 表保留用途：日常讨论、@ mention、非结构化沟通。reviews 表专注评审。

附录：关键参考源码

A. Superpowers 串行双审

skills/subagent-driven-development/SKILL.md
skills/requesting-code-review/code-reviewer.md
skills/subagent-driven-development/code-quality-reviewer-prompt.md

B. TradingAgents 辩论条件边

# tradingagents/graph/trading_graph.py
workflow.add_conditional_edges(
    "Bull Researcher",
    should_continue_debate,
    {"Bear Researcher": ..., "Research Manager": ...}
)

C. oh-my-claudecode Critic 工具限制

# agents/critic.md
disallowedTools: Write, Edit

D. OpenAI Agents SDK Tripwire

# agents/guardrails.py
@output_guardrail
async def guardrail_fn(ctx, agent, output):
    return GuardrailFunctionOutput(
        tripwire_triggered=output.is_invalid
    )

E. SWE-agent RetryLoop

# config.yaml
agent:
  type: retry
  retry_loop:
    cost_limit: 6.00
    max_attempts: 3

F. Hermes Kanban Comment

-- kanban_comment with structured metadata
INSERT INTO kanban_comment (task_id, author, body, metadata)
VALUES (?, ?, ?, json(?))
-- metadata: {"changed_files": [...], "tests_run": 5, "tests_passed": 5, "diff_path": "..."}

35 KiB Raw Blame History Unescape Escape

调研报告：挑战/评审体系 + 质量门控结构化

目录

课题 3：挑战/评审体系设计

已有经验（知识库/wiki + v1.0 三层实践）

知识库已有调研

v1.0 三层挑战控制回顾

v2.6 架构现状

业界优秀实践对比表（课题3）

1. Superpowers：三阶段审查（implementer → spec reviewer → code quality reviewer）

2. TradingAgents：多空辩论（Bull↔Bear + Judge 裁决）

3. oh-my-claudecode：ralplan（Planner→Architect→Critic 三方共识）

4. OpenAI Agent SDK：OutputGuardrail + 声明式 Guardrail

5. 其他优秀实践

5.1 Edict 的门下省审核（封驳打回机制）

5.2 wanman 的评估引擎（三阶段 explore→evaluate→execute）

5.3 SWE-agent 的 RetryLoop（多次尝试 + Reviewer 选最优）

综合对比表

v1.0 三层体系评估

三层体系分析

三层是否高效？

三层是否足够？

三层是否过重？

推荐方案（课题3）

设计原则

分级审查矩阵

三阶段审查流程（关键节点）

声明式 Guardrail 规则示例

对 v1.0 三层体系的改进

课题 5：质量门控结构化

业界优秀实践对比表（课题5）

1. Control Center 的 Task Store（artifacts + rollback + review 结构）

2. SWE-agent 的 Trajectory 审计

3. Hermes 的 Comment 线程 + 结构化状态

4. 其他优秀实践

4.1 PRD 中定义的 review_result JSON

4.2 GitHub PR Review 的结构化模式

4.3 代码审查工具的结构化输出模式

综合对比表（课题5）

推荐方案：评审结果存储与结构

设计原则

推荐的评审结果结构

评审详情文件结构

Guardrail 自动检查结果

评审产出物与任务产出物的关系

多轮协商的追溯

对比现有 comments 表的改进

附录：关键参考源码

A. Superpowers 串行双审

B. TradingAgents 辩论条件边

C. oh-my-claudecode Critic 工具限制

D. OpenAI Agents SDK Tripwire

E. SWE-agent RetryLoop

F. Hermes Kanban Comment

35 KiB

Raw Blame History