QR Agent 团队架构蓝图
GAN 风格 多 Agent 协作系统 / v7.0 / 5+1 Agents / Box0 DAG Workflow 驱动
1. Agent 团队架构
1.1 设计灵感
灵感来自 Anthropic 的 Harness Design 文章,采用 GAN(生成对抗网络)三角 架构:
- qr-planner 生成规格说明(类似 Generator)
- qr-evaluator 对抗性审核产出(类似 Discriminator)
- qr-builder 将规格物化为可运行代码
Builder 与 Evaluator 之间的对抗张力驱动质量持续提升。Curator 捕获成功/失败经验,Dispatcher 编排整条管线。
1.2 团队拓扑
qr-planner (规划器)
/ \
[冲刺合同协商] [方案终审]
/ \
qr-builder (生成器) ──产出工件──→ qr-evaluator (评估器)
│ │
│ qr-curator (经验策展) │
└──────── 注入/捕获 ──────────┘
│
qr-dispatcher (调度器)
│
qr-lead (人机接口)
1.3 Agent 规格矩阵
| Agent |
职责 |
运行时 |
Card 拥有区域 |
写入标记 |
qr-planner |
规划器 — 规格生成 |
Box0 Agent |
YAML 基础字段、Spec、验收标准 |
spec_ready: true |
qr-dispatcher |
调度器 — 生命周期管理 |
Box0 Agent |
status, workflow_run_id, 调度历史 |
status: ACCEPTED / DISPATCHED |
qr-builder |
生成器 — 全栈实现 |
Box0 Agent |
Build Result, 经验应用表, 修复历史 |
status: BUILT |
qr-evaluator |
判别器 — 对抗审核 |
Box0 Agent |
Evaluation Result (verdict + evidence + complexity) |
status: EVALUATED / FAILED |
qr-curator |
策展器 — 经验注入/捕获 |
Box0 Agent |
Experience Context |
experience_ready: true |
qr-lead |
主导 — 人机交互与路由 |
Claude Code Skill |
无(只读) |
CLI 命令 |
1.4 核心设计原则
| 原则 |
说明 |
| 唯一事实来源 |
每个任务有且仅有一个 Card 文件 plans/active/cards/T-{id}.md,每个 Agent 只读写自己拥有的区域,无侧信道状态 |
| 对抗性隔离 |
Evaluator 绝不参与前期工作(不参加合同协商),仅在 Builder 完成后独立出场审核 |
| 经验驱动 |
模式 (P###) 和反模式 (A###) 在 Builder 读取 Card 之前注入,评估后捕获新经验 |
| 单次激活协议 |
Dispatcher 以 b0 run qr-dispatcher "单次激活协议" 运行,每次调用仅执行一轮,无常驻守护进程 |
| 有界重试 |
每个任务最多重试 1 次,连续失败 2 次 → 升级到 Planner 拆分任务,反循环保证 |
| Card 级锁 |
negotiating_at 字段 + 30 分钟 TTL 防止并发 Dispatcher,文件级 .dispatcher.lock 实现跨激活互斥 |
2. 5 阶段运营周期
2.1 主管线
PLAN → CONTRACT → BUILD → EVALUATE → EVOLVE
↑ │
└────────── (fix_task 回路) ←────────┘
| 阶段 |
Agent |
触发条件 |
产出 |
Card 状态 |
| PLAN |
qr-planner |
新 Wave 或重大变更 |
Card + Spec + 验收标准 |
→ NEGOTIATING |
| CONTRACT |
qr-dispatcher + qr-curator |
Dispatcher 扫描到 NEGOTIATING 卡片 |
ACCEPTED Card + Workflow Run |
→ DISPATCHED |
| BUILD |
qr-builder |
DAG Run 自动推进(收到 card_file) |
代码 + 测试 + 配置 + Docker |
→ BUILT |
| EVALUATE |
qr-evaluator |
Builder 步骤完成,DAG 自动推进 |
Verdict + Evidence |
→ EVALUATED / FAILED |
| EVOLVE |
qr-curator |
Evaluator 步骤完成,DAG 自动推进 |
P### / A### / L### 文件 |
→ DONE |
2.2 反馈回路
EVALUATE: FAIL
→ Dispatcher 检测
→ retry < 1?
→ 是: fix_task 重试 → BUILD (第二轮) → EVALUATE
→ 否 (retry ≥ 1): ESCALATE → qr-planner 拆分 → N 个子 Card → 重新进入 PLAN
2.3 各阶段详情
STAGE 1: PLAN — qr-planner
- 通过 Context7 MCP 研究技术文档(LangChain/LangGraph 优先)
- 展开目标为详细规格(不过度指定实现)
- 编写架构方案 → 自审 → 标记 APPROVED
- 初始化
progress.json 的 Wave/Track/Task 结构
- 创建 Task Card(YAML frontmatter + Spec)
STAGE 2: CONTRACT — qr-dispatcher + qr-curator
- Dispatcher 扫描
cards/*.md → 发现 status: NEGOTIATING
- 验证
spec_ready: true
- 调用 Curator 注入经验 →
experience_ready: true
- 双向标志确认 →
status: ACCEPTED
- 创建 Box0 DAG Workflow Run →
status: DISPATCHED
关键:合同协商在代码编写之前完成。
STAGE 3: BUILD — qr-builder
- 只读 Card 文件 — 包含一切:Spec + AC + 经验
- 先读 Experience Context(模式应用、反模式规避)
- 实现全部:代码 + 测试 + 配置 + Docker
- 6 项必过自检:
- 并发检查
- Import 检查
- 已有测试回归无失败
- 新测试通过
- ruff lint clean
- 合同合规:逐条验收标准确认
- 写入 Build Result + 经验应用表 +
status: BUILT
STAGE 4: EVALUATE — qr-evaluator
- 对抗性:不信任 Builder 自检报告,独立验证
- 条件执行:简单任务(单文件、配置、fix_task)→ 跳过,自动 PASS
- 硬性阈值:每条验收标准为二元判定 (PASS/FAIL),无"差不多"
- 三种裁决:
PASS / CONDITIONAL_PASS / FAIL
- 输出结构化 JSON(最后一行供 Dispatcher 解析)
- FAIL → Dispatcher 创建 fix_task workflow run
STAGE 5: EVOLVE — qr-curator
- PASS → 提取成功模式 → 写入/更新 P### 文件
- FAIL → 提取根因 → 写入/更新 A### 或 L### 文件
- ESCALATE → 分析拆分根因 → 写入
docs/experiences/planning/P###
- 去重,更新 index.md
- Wave 完成 → Gate 聚合(仅 Evaluator 可更新
current_wave)
2.4 Box0 DAG Workflow 模板
| 模板名 |
拓扑 |
用途 |
qr-build-eval-evolve |
start → builder → evaluator → curator → end |
正常流程 |
qr-fix-task |
start → builder → evaluator → end |
修复重试,Builder 携带失败上下文 |
qr-escalate |
start → planner → end |
升级拆分,Planner 分解为子 Card |
3. Task Card 状态机
3.1 状态流转图
stateDiagram-v2
[*] --> DRAFTING : 新任务创建
DRAFTING --> NEGOTIATING : qr-planner\nspec_ready: true
NEGOTIATING --> ACCEPTED : qr-dispatcher\n双标志确认
ACCEPTED --> DISPATCHED : qr-dispatcher\n创建 Workflow Run
DISPATCHED --> BUILT : qr-builder\n6项自检通过
BUILT --> EVALUATED : qr-evaluator\n独立验证 PASS
EVALUATED --> DONE : qr-curator\n经验捕获
BUILT --> FAILED : qr-evaluator\n独立验证 FAIL
FAILED --> FIX_QUEUED : qr-dispatcher\nretry < 1
FIX_QUEUED --> DISPATCHED : fix_task 回路\n携带失败上下文
FAILED --> ESCALATED : qr-dispatcher\nretry ≥ 1
ESCALATED --> DRAFTING : qr-planner 拆分\nN 个子 Card
DONE --> [*]
3.2 状态定义
| 状态 |
含义 |
写入者 |
进入条件 |
关键字段 |
DRAFTING |
Card 创建中,Spec 编写阶段 |
qr-planner |
新任务创建 |
spec_ready: false |
NEGOTIATING |
Spec 完成,等待经验注入 |
qr-planner → qr-dispatcher |
spec_ready: true |
negotiating_at: <timestamp> |
ACCEPTED |
合同协商完成,准备派发 |
qr-dispatcher |
spec_ready: true + experience_ready: true |
双标志均为 true |
DISPATCHED |
已创建 Box0 Workflow Run |
qr-dispatcher |
DAG Run 创建成功 |
workflow_run_id: ... |
BUILT |
Builder 完成实现 + 6 项自检 |
qr-builder |
代码 + 测试 + 自检通过 |
Build Result + 经验应用表 |
EVALUATED |
审核通过(终态-成功) |
qr-evaluator |
独立验证 PASS / CONDITIONAL_PASS |
verdict + evidence |
FAILED |
审核失败 |
qr-evaluator |
独立验证 FAIL |
verdict: FAIL + 根因分析 |
FIX_QUEUED |
排队等待修复重试 |
qr-dispatcher |
retry_count < 1 |
retry_count: +1 |
ESCALATED |
升级拆分(终态-放弃原 Card) |
qr-dispatcher |
retry_count ≥ 1 |
escalation_chain: [...] |
3.3 Card 区域读写归属(严格分区)
| Agent |
拥有区域 |
| qr-planner |
task_id, group_id, wave, depends_on,Task Overview + Spec + 验收标准,spec_ready |
| qr-dispatcher |
status, workflow_run_id, retry_count, negotiating_at,调度历史 |
| qr-curator |
Experience Context,experience_ready |
| qr-builder |
Build Result + 经验应用表 + Fix History,live_status, blocked_type |
| qr-evaluator |
Evaluation Result(verdict + evidence + complexity + timing) |
约束:每个 Agent 只写自己拥有的区域,无侧信道状态,Card 是唯一事实来源。
4. Sprint Contract 协商流程
4.1 核心原则
合同协商在代码编写之前完成。 每个 Agent 直接读写 Card 文件。Evaluator 绝不参与前期工作 — 仅在 Builder 完成后独立审核。三个独立部分(Spec / AC / Experience)由三个不同 Agent 编写,互不干扰。
4.2 六步协商流程
┌──────────────────────────────────────────────────────────────────────────┐
│ Step 1: qr-planner │
│ 创建 Card + 编写 Spec + 验收标准 │
│ → 写入 YAML 基础字段、Task Overview、Spec(目标/涉及文件/技术约束/接口) │
│ → 写入验收标准(H1/H2 工程健康 + B1/B2 行为标准) │
│ → 设置 spec_ready: true │
│ → Card 状态: NEGOTIATING │
├──────────────────────────────────────────────────────────────────────────┤
│ Step 2: qr-dispatcher │
│ 扫描 NEGOTIATING 卡片 │
│ → 扫描 cards/*.md,发现 status: NEGOTIATING 且 spec_ready: true │
│ → 检查 negotiating_at TTL(30 分钟)防止并发 │
│ → 调用 Curator 进行经验注入 │
├──────────────────────────────────────────────────────────────────────────┤
│ Step 3: qr-curator │
│ 注入经验上下文 │
│ → 读取 Spec,搜索经验库(P### / A### / L###) │
│ → 匹配 track / task / tech / files 关键词 │
│ → 写入 Experience Context 到 Card │
│ → 设置 experience_ready: true │
├──────────────────────────────────────────────────────────────────────────┤
│ Step 4: qr-dispatcher │
│ 双向标志确认 │
│ → 验证 spec_ready: true 且 experience_ready: true │
│ → 确认 Card 三个区域均已填写 │
│ → 设置 status: ACCEPTED │
├──────────────────────────────────────────────────────────────────────────┤
│ Step 5: qr-dispatcher │
│ 创建 Box0 DAG Workflow Run │
│ → 创建 Run(模板: qr-build-eval-evolve) │
│ → 传入 card_file=plans/active/cards/T-{id}.md │
│ → 设置 status: DISPATCHED,记录 workflow_run_id │
│ → DAG 自动推进: builder → evaluator → curator │
├──────────────────────────────────────────────────────────────────────────┤
│ Step 6: qr-builder │
│ 读取 Card + 实现 + 自检 │
│ → 只读 Card 文件(Spec + AC + Experience) │
│ → 先读 Experience Context(模式应用 / 反模式规避) │
│ → 实现代码 + 测试 + 配置 + Docker │
│ → 6 项自检通过 │
│ → 填写 Build Result + 经验应用表 │
│ → Card 状态: BUILT │
└──────────────────────────────────────────────────────────────────────────┘
4.3 Sprint Contract Card 结构
┌─────────────────────────────────────────────────────┐
│ YAML Frontmatter [qr-planner + dispatcher] │
│ task_id, group_id, wave, depends_on, status, │
│ spec_ready, experience_ready, workflow_run_id, │
│ retry_count, negotiating_at │
├─────────────────────────────────────────────────────┤
│ 规格局 [qr-planner] │
│ • 目标(一句话) │
│ • 涉及文件 │
│ • 技术约束(框架/API 限制) │
│ • 接口(输入输出类型、函数签名) │
├─────────────────────────────────────────────────────┤
│ 验收标准 [qr-planner] │
│ • 工程健康类: pytest 通过, ruff check 零告警 │
│ • 行为类: 具体可测试标准(每条为二元 PASS/FAIL) │
├─────────────────────────────────────────────────────┤
│ 经验上下文 [qr-curator] │
│ • P###: 模式 — 摘要(Builder 应用的模式) │
│ • A###: 反模式 — 警告(Builder 必须规避的陷阱) │
│ • L###: 教训 — 具体约束或变通方案 │
├─────────────────────────────────────────────────────┤
│ Build Result [qr-builder] │
│ • 实现产出、经验应用表、修复历史 │
├─────────────────────────────────────────────────────┤
│ Evaluation Result [qr-evaluator] │
│ • verdict + evidence + complexity + timing │
├─────────────────────────────────────────────────────┤
│ Dispatch History [qr-dispatcher] │
│ • 每次调度记录: 时间, Run ID, 结果, 耗时 │
└─────────────────────────────────────────────────────┘
4.4 关键约束
| 约束 |
说明 |
| 隔离 |
三个独立 Agent 写三个独立区域。Planner 写 Spec+AC,Curator 写 Experience,Builder 写 Build Result。互不读取对方未完成的内容,避免信息污染 |
| 原子门槛 |
spec_ready 和 experience_ready 必须同时为 true,Dispatcher 才推进到 ACCEPTED。任一缺失 → 卡在 NEGOTIATING |
| 对抗保障 |
Evaluator 不参与合同协商。它在 Step 1-5 中完全不存在,仅在 Builder 完成后独立出场。保证审核的对抗性 — 不会因参与设计而产生认同偏差 |
5. 经验系统 — 注入 / 交叉引用 / 捕获
5.1 经验库统计(当前)
| 类型 |
数量 |
存储位置 |
| 教训 L### |
24 |
docs/experiences/lessons/L###-*.md |
| 模式 P### |
43 |
docs/experiences/patterns/P###-*.md |
| 反模式 A### |
11 |
docs/experiences/anti-patterns/A###-*.md |
| 规划教训 P### |
10 |
docs/experiences/planning/P###-*.md |
5.2 经验三触点
经验在运营周期中通过三个触点流动:
触点 1: 注入 (INJECT) 触点 2: 交叉引用 触点 3: 捕获 (CAPTURE)
CONTRACT 阶段 (CROSS-REFERENCE) EVOLVE 阶段
qr-curator → Card EVALUATE 阶段 qr-curator
qr-evaluator
Curator 读取 Spec Evaluator 审核时 PASS → 提取成功模式 → P###
搜索经验库 将失败现象与已知 FAIL → 提取根因 → A### / L###
匹配关键词 反模式交叉比对 ESCALATE → 规划教训 → planning/P###
嵌入 Experience Context 标注对应 A### ID
Builder 第一眼看到经验
5.3 经验循环流
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ EVALUATE 结果 │ ──→ │ Curator 捕获 │ ──→ │ 写入 P/A/L │ ──→ │ 更新 index.md│
└──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘
│
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ Card (注入) │ ←── │ 写入 Exp Ctx │ ←── │ 检索匹配 │ ←──────────┘
└──────────────┘ └──────────────┘ └──────────────┘
│
▼
Builder 读 Card 时消费
5.4 Injection Protocol
查询格式(Dispatcher → Curator)
{track, task, tech, files, failure_context}
| 字段 |
用途 |
track |
当前 Track 名称(用于近邻匹配) |
task |
任务摘要(关键词匹配) |
tech |
技术栈标签(如 LangGraph / SQLite / Docker) |
files |
涉及文件路径(路径级匹配) |
failure_context |
fix_task 时附加的失败上下文(增强匹配) |
响应格式(Curator → Card)
EXPERIENCE_BLOCK 包含:
- 模式 (P###) :推荐应用的设计模式
- 反模式 (A###) :必须规避的已知陷阱
- 教训 (L###) :具体约束或变通方案
检索规则:关键词匹配 + Track 近邻 + 最多 2-5 条结果 + fix_task 增强 + 去重
fix_task 增强注入
修复重派时,Curator 在原始经验块基础上追加:
- 失败详情(Evaluator 的 verdict + evidence)
- 匹配的反模式(A###)及完整解决方案文本
- 基于失败根因的二次经验匹配
5.5 Builder 经验应用表(Card 内必填)
Builder 必须在 Card 中填写以下表格:
| 经验 ID |
状态 |
证据 |
| P### |
Applied / NotApplicable / NeedClarification |
文件:行号 — 说明如何应用 |
| A### |
Avoided / NotApplicable |
说明如何规避该反模式 |
| L### |
Applied / NotApplicable |
说明如何遵循该教训 |
5.6 捕获规则
| 评估结果 |
捕获动作 |
写入文件 |
去重策略 |
| PASS |
提取成功模式 — 哪些设计选择促进了通过 |
patterns/P###-*.md |
检查已有 P### 是否覆盖相同场景,有则更新 |
| FAIL |
提取根因 — 哪个设计缺陷导致了失败 |
anti-patterns/A###-*.md 或 lessons/L###-*.md |
检查已有 A###/L### 是否描述相同问题 |
| ESCALATE |
分析拆分根因 — 任务为何需要升级拆分 |
planning/P###-*.md |
检查已有规划教训是否覆盖同类拆分原因 |
6. 调度决策与错误恢复
6.1 需求路由(三维度评分)
新需求通过三个维度评分后路由到不同处理路径:
| 维度 |
取值 |
| 大小 |
tiny (< 0.5h) / small (0.5-2h) / medium (2h-1d) / large (Wave 级别) |
| 类型 |
bug fix / feature iteration / infrastructure / research |
| 阻塞度 |
blocks mainline(阻塞主线)/ non-blocking(不阻塞) |
6.2 调度决策表
| 场景 |
路由目标 |
执行路径 |
跳过阶段 |
| 微型修复 (< 0.5h) |
b0 run qr-builder |
直接 Builder,跳过合同协商和 Evaluator |
CONTRACT, EVALUATE |
| 标准任务 |
b0 run qr-dispatcher |
自动 CONTRACT → BUILD → EVALUATE → EVOLVE |
无 |
| 需要架构设计 |
先 b0 run qr-planner |
Planner 设计 → 再走标准路径 |
无(额外 PLAN 阶段) |
| fix_task 修复 |
b0 run qr-dispatcher |
Dispatcher 触发 fix_task 循环,Builder 携带失败上下文 |
CONTRACT(使用原合同) |
| Gate 判定 |
b0 run qr-evaluator |
独立审核,输出 Wave 级 Gate 汇总 |
BUILD, EVOLVE |
6.3 Dispatcher 内部状态机
{
"state": "dispatching",
"active_tasks": {},
"max_parallel": 10,
"lock_ttl_minutes": 25,
"dispatch_timeout_s": 600
}
6.4 超时规格
| 参数 |
值 |
说明 |
| Builder 超时 |
1800s |
单次构建最大时长 |
| Dispatch 超时 |
600s |
调度操作最大时长 |
| Lock TTL |
25min |
跨激活互斥锁有效期 |
| Negotiating TTL |
30min |
防止并发 Dispatcher 协商同一 Card |
6.5 错误恢复策略
fix_task 回路
EVALUATED → FAILED → Dispatcher 检测 → retry_count < 1?
→ 是: FIX_QUEUED → 重新 DISPATCHED → BUILD (携带失败上下文)
→ 否: ESCALATED → qr-escalate workflow → Planner 拆分为 N 个子 Card
- Builder 携带失败上下文(Evaluator verdict + evidence + Curator 增强经验)
- 最多 1 次重试
Escalate 升级拆分
- 连续失败 2 次(
retry_count ≥ 1)→ ESCALATED
- Dispatcher 创建
qr-escalate workflow run
- Planner 分析根因,将原任务拆分为 N 个子 Card
- 子 Card 重新进入 DRAFTING → NEGOTIATING 流程
僵尸检测
- Dispatcher 检测到 Run 超过超时阈值但未完成
- 通过
POST /cancel 取消僵尸 Run
- 释放并发槽位,允许后续任务继续
代码残留恢复 (L022)
- Builder 超时但已产出代码 → 标记
FIX_QUEUED
- 不丢弃已有代码,让 Evaluator 单独评估已有产出
- 避免浪费 Builder 已完成的工作
6.6 Builder 阻塞类型
| 类型 |
说明 |
external_dependency |
外部依赖不可用 |
spec_ambiguity |
规格不清晰 |
upstream_blocked |
上游任务未完成 |
infrastructure |
基础设施问题 |
scope_creep |
范围蔓延 |
timeout_overload |
超时/过载 |
6.7 并行策略(Wave 7 示例)
P0: P0A → P0B → P0C → P0D → P0E ← 5 阶段串行链
│
┌──────────────┼──────────────┐
▼ ▼ ▼
W7-Web (8 tasks) P2A (Feishu) P3A (Calibration)
P2B (Weekly) P2C (Integration) P3B (E2E Tests)
│ │ │
└──── P2D ◄───────┘ │
(依赖 P2B + P2C) │
▼
P3C (Gate)
(依赖 P3A + P3B)
6.8 Gate 控制规则
| 裁决类型 |
说明 |
| UNLOCK |
全部通过,进入下一 Wave |
| CONDITIONAL_UNLOCK |
记录非阻塞项,允许前进 |
| BLOCK |
阻塞,必须修复后重试 |
关键约束:
- 仅
qr-evaluator 可更新 current_wave
- 同一合同失败 3 次 → 触发 Planner 升级(架构审查)
- Wave 7 Gate 结果: 1499/1502 测试通过, 75% 覆盖率