Dynamic Workflow

Dynamic Workflow — 动态工作流执行引擎

不是审计清单。是执行引擎。隔离 = 质量。

基于 Claude Code Harness 六种隔离模式，三层触发自动构建 Agent 工作流并通过 delegate_task 执行。

关键：这是真正的多 Agent 隔离，不是角色模拟

delegate_task 会 spawn 真正的子 Agent 进程，每个子 Agent 拥有：

• 独立的上下文窗口（不共享父 Agent 的对话历史）
• 独立的终端会话
• 独立的工具集
• 无父 Agent 记忆

这意味着 ③ Adversarial Verification 的隔离是真实的：verifier 子 Agent 看不到 worker 子 Agent 的推理过程，只看到 worker 的最终产出。不存在同一上下文中"维护先前成果"的自我偏好偏差。

这不是一个 Agent 假装自己是三个不同角色在顺序对话——那是假的隔离，解决不了 Harness 定义的三种故障模式。

三层触发架构

Priority 1: 业务上下文 (references/business-triggers.md)
  → 数据采集 | 内容创作 | 工具编排 | API批量 | 项目决策 | 工作流联动

Priority 2: 任务类型 (7 种，见下方 Layer 1)
  → T1 Audit | T2 Decision | T3 Research | T4 Build | T5 Debug | T6 Creative | T7 Execute

Priority 3: 维度计分上调 (8 维度，见下方 Layer 2)
  → D1-D8 在 Priority 1+2 的默认模式上做增强

自动加载条件（任一命中）：

总分 ≤ 5 静默跳过。

通用领域触发矩阵

6种隔离模式覆盖7大领域，35个子场景。DW根据三层检测自动选择模式组合和Agent数量。

AI / 大模型 / 智能体

产品 / 商业

企业管理 / 战略

学术 / 研究

安全 / 合规

技术 / 架构

内容 / 创作

Layer 1: 任务类型 → 默认模式

根据关键词 + 任务结构自动归类：

Layer 2: 维度计分 → 上调/降级

每种任务类型有默认最低配置。维度分数只能向上增强（加模式、加 Agent 数量），不能降级低于默认。降级仅两个例外。

上调规则

降级规则（仅此两条）

D1-D8 计分标准

决策示例

示例 1: "审查所有微服务的 SQL 注入风险"

Layer 1: T1 Audit → Default: ①+②+③

Layer 2:
  D1=3 → ② 升级: N 个 reviewer（每文件）
  D3=3 → ③ 升级: 3 verifier（误报/漏报/修复质量）
  D2=0 D4=0 D5=0 D6=0 D7=0 D8=0

Final: ① + ②(×N) + ③(×3)
  → Classify 分文件组 → N reviewer 并行 → 汇总 → 3 verifier 交叉验证

示例 2: "选一个最适合的技术栈"

Layer 1: T2 Decision → Default: ④+⑤

Layer 2:
  D1=1 D2=0 D3=1 D4=2 D5=2 D6=0 D7=1 D8=1
  无上调触发（默认已覆盖 ④+⑤）

Final: ④ + ⑤
  → 3 generator（不同偏好）→ Filter → Pairwise → Winner

执行流程

Phase 1: Classify（内部推理，不输出）
  ├─ 业务上下文匹配 → 任务类型归类 → D1-D8 计分
  └─ Final = Default ∪ Upgrades \ Downgrades

Phase 2: Build（构建 delegate_task 调用，不输出表格）
  └─ 按下方的执行模板生成具体的 task goals + toolsets + context

🔴 **CHECKPOINT** — 工作流已构建。确认后执行：
>- [ ] 选择的模式组合是否匹配 Layer 1 默认 + Layer 2 上调？
>- [ ] 子 Agent 数量是否在并发限制内（≤3/批）？
>- [ ] 每个 task 的 goal 是否有明确验收标准？
>- [ ] toolsets 分配是否符合分配规则？
>- [ ] 若配置不当 → 回到 Phase 1 重新计分

🛑 确认通过 → 进入 Phase 3 执行

Phase 3: Execute（实际执行，用户可见）
  ├─ delegate_task 并行分派 → 汇总 → 质量门验证
  └─ 每步完成后输出状态

Phase 4: Deliver（最终交付）
  └─ 整合所有子 Agent 产出 → 一份最终结果

执行模板（每个模式组合一个模板）

以下模板是 Phase 2 Build 的产出物。直接按模板构造 delegate_task 调用。

模板 A: ② Fanout + ③ Adversarial（审查/审计类）

适用于 T1 Audit，或任何 D1≥2 + D3≥2 的组合。

Step 1: 并行审查（② Fanout）
  delegate_task(tasks=[
    {goal: "<子任务1的完整描述，含输入文件/路径/检查标准>", toolsets: ["terminal","file"], context: "..."},
    {goal: "<子任务2>", toolsets: [...]},
    ...  # N 个子任务，N = D1≥3 时按实际数量
  ])
  # 子任务数量 > 3 时分批，每批 3 个

Step 2: 汇总综合（② Synthesize）
  delegate_task(
    goal: "将以上 N 个审查结果合并去重，按严重程度排序，输出 consolidated report",
    context: "<Step 1 所有子任务的关键发现摘要>"
  )

Step 3: 独立验证（③ Adversarial）
  delegate_task(tasks=[
    {goal: "独立验证 consolidated report —— 检查是否有误报。逐条验证每个 finding 的证据", 
     context: "你是独立验证者，未参与原始审查。只评价证据是否充分，不评价审查质量"},
    {goal: "独立验证 consolidated report —— 检查是否有漏报。对比原始文件列表和 finding 覆盖",
     context: "你是独立验证者，检查覆盖率"}
  ])

Step 4: 最终交付
  将验证后的 report 作为最终结果输出给用户

模板 B: ④ Generate-Filter + ⑤ Tournament（决策/选型类）

适用于 T2 Decision。

Step 1: Rubric 先行（必须在生成前定义）
  明确评分标准: 维度1(权重) / 维度2(权重) / 维度3(权重)
  向用户确认 rubric 是否合理

🔴 **CHECKPOINT** — Rubric 需用户确认后才能继续。若用户未确认，暂停并等待。

Step 2: 并行生成（④ Generate）
  delegate_task(tasks=[
    {goal: "产出方案 A：倾向 <维度1优先>，输出结构化方案",
     context: "rubric: <维度1权重0.5, 维度2权重0.3, 维度3权重0.2>"},
    {goal: "产出方案 B：倾向 <维度2优先>",
     context: "rubric: ..."},
    {goal: "产出方案 C：倾向 <维度3优先>",
     context: "rubric: ..."},
  ])

Step 3: Rubric 筛选（④ Filter）
  delegate_task(
    goal: "按 rubric 对 3 个方案打分排序，筛选 top 2，输出评分表和各方案优劣",
    context: "<rubric + 3 个方案摘要>"
  )

Step 4: 两两比较（⑤ Tournament）
  delegate_task(
    goal: "对 top 2 方案做 pairwise 比较。从 <N个维度> 逐项对比，说明每项谁优谁劣及理由，最终给出 winner 和推荐理由",
    context: "<top 2 方案全文 + rubric>"
  )

Step 5: 最终交付
  输出 winner + 对比理由

模板 C: ② Fanout + ⑥ Loop（调研/探索类）

适用于 T3 Research。

Step 1: 并行初探（② Fanout）
  delegate_task(tasks=[
    {goal: "从维度 <1> 调研 <主题>，输出初步发现和关键数据", toolsets: ["web"]},
    {goal: "从维度 <2> 调研 <主题>", toolsets: ["web"]},
    {goal: "从维度 <3> 调研 <主题>", toolsets: ["web"]},
  ])

Step 2: 收敛判断（⑥ Loop）
  检查 Step 1 的发现：是否有值得深入的新线索？
  
  → YES: spawn 下一轮
    max_iter = D6 × 3（上限 10）
    每轮追问: "上轮发现中提到的 <新线索>，深入挖掘"
    
  → NO: 进入 Step 3

Step 3: 综合报告
  delegate_task(
    goal: "将所有轮次的发现整合为一份结构化调研报告",
    context: "<所有轮次的摘要>"
  )

模板 D: ② Fanout only（构建/实现类）

适用于 T4 Build。

Step 1: 并行构建（② Fanout）
  delegate_task(tasks=[
    {goal: "构建模块 <1>：<具体产出要求 + 验收标准>", toolsets: ["terminal","file"]},
    {goal: "构建模块 <2>：<具体产出要求>", toolsets: [...]},
    ...
  ])

Step 2: 整合综合（② Synthesize）
  delegate_task(
    goal: "整合所有模块产出，确保接口一致、无冲突，输出最终交付物",
    context: "<各模块产出摘要>"
  )

模板 E: ⑥ Loop + ③ Adversarial（Debug/排查类）

适用于 T5 Debug。

Step 1: 逐层排查（⑥ Loop）
  max_iter = D6 × 3
  
  迭代 1: delegate_task(goal: "排查 <异常现象> 的可能原因，输出初步诊断和下一步调查方向")
  检查: 是否定位到根因？
    → NO: spawn 迭代 2，context 传入迭代 1 的诊断结果
    → YES: 进入 Step 2

Step 2: 修复方案
  delegate_task(goal: "根据根因 <X> 给出修复方案，含具体代码变更和回滚方案")

🔴 **CHECKPOINT** — 修复方案需审查后才能部署验证。确认修复不引入副作用后继续。

Step 3: 独立验证（③ Adversarial）
  delegate_task(
    goal: "验证修复方案是否真正解决根因，且不引入新问题。检查边界情况",
    context: "你是独立验证者，未参与诊断和修复"
  )

模板 F: ① Classify + ② Fanout（跨领域分派类）

适用于 D2≥2 的多领域任务。

Step 1: 领域分类（① Classify）
  按领域拆分 task groups:
  - group-code: 代码相关的子任务
  - group-content: 内容/文案相关的子任务
  - group-ops: 运维/部署相关的子任务
  
Step 2: 并行分派（② Fanout）
  delegate_task(tasks=[
    {goal: "<group-code 所有子任务>", toolsets: ["terminal","file"], context: "你只负责代码部分"},
    {goal: "<group-content 所有子任务>", toolsets: ["file","web"], context: "你只负责内容部分"},
    {goal: "<group-ops 所有子任务>", toolsets: ["terminal"], context: "你只负责运维部分"},
  ])

Step 3: 整合交付
  合并各领域产出

执行规则

并行分派规则

1. 子任务 ≤ 3 个: 一次 delegate_task(tasks=[...]) 全部并行
2. 子任务 4-6 个: 分两批，每批 3 个，第一批完成后立即启动第二批
3. 子任务 7+ 个: 分多批，每批 3 个（Hermes delegation 并发限制）

上下文传递规则

1. worker → verifier: 传递 worker 的完整产出，但声明 "你是独立验证者，未参与原始工作"
2. fanout → synthesize: 传递所有子任务的摘要（每个 ≤ 200 字），不全量传递（节省 token）
3. loop → next iteration: 传递上一轮的 "关键发现 + 下一步方向"，不传递完整对话历史

工具集分配规则

错误处理

1. 单个子 Agent 失败: 标记该子任务为 ✗ FAILED，其他子任务继续。最终交付时说明"/ 完成"
2. 全部子 Agent 失败: 回退为单 Agent 直接执行，并报告失败原因
3. ③ Verifier 发现严重问题: 回退到 Step 1，用 verifier 的反馈重新执行 worker

隔离规则（不可违反）

1. ③ 模式下 worker ≠ verifier — 不同 delegate_task 调用
2. ② 模式并行任务 prompt 同质 — 不因"这个简单"而降级
3. ⑥ 模式必须写死 max_iter — 默认 D6×3，上限 10
4. ④ rubric 在生成前定义 — 不能生成了再编标准

Pitfalls

1. 简单任务不触发（总分 ≤ 5 静默跳过）
2. ③ 的 verifier 必须独立
3. ⑥ 的 max_iter 必须写死
4. rubric 在生成之前定义

⛔ 反例与禁止

以下行为违反隔离原则，导致多 Agent 工作流失效：

参考文件

以上文件为本 Skill 运行时依赖。若缺失，使用 SKILL.md 内嵌的六模式描述和领域矩阵。

Attribution

Claude Code Dynamic Workflows (Harness), Thariq Shihipar & Sid Bidasaria @ Anthropic. 六模式图及钉钉文档解读由秦弋提供参考。