ZENTHOS Workspace
RAW · · 2026-05-05 · 32 min · #072WTA6

architecture-blueprint

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

  1. Dispatcher 扫描 cards/*.md → 发现 status: NEGOTIATING
  2. 验证 spec_ready: true
  3. 调用 Curator 注入经验 → experience_ready: true
  4. 双向标志确认 → status: ACCEPTED
  5. 创建 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_readyexperience_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 在原始经验块基础上追加:

  1. 失败详情(Evaluator 的 verdict + evidence)
  2. 匹配的反模式(A###)及完整解决方案文本
  3. 基于失败根因的二次经验匹配

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###-*.mdlessons/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% 覆盖率