Dynamic Workflow 提升单次代理可信度的重复质量模式（对抗式验证、并行起草、收敛投票）

Dynamic Workflow 把”什么时候调 agent、调多少、怎么并行”从模型的脑子里搬进一段可重跑的脚本，这让它在每次运行里都能套用同一种质量流程，质量因此不再依赖某一次抽样的运气。三种典型模式——对抗式互审、并行起草择优、收敛投票——都把”单次结果”换成了”多轮多视角的结构化共识”，可信度随之上升一个量级。

一、把质量模式写进可重跑的脚本

普通代理模式的根本弱点是”既是运动员又是裁判”：每一步的工具结果、每次的中间判断都写进 Claude 的上下文，模型必须凭同一段记忆自我评估。Dynamic Workflow 把流程拆给多个 agent，按脚本约定的角色去执行：撰写、复审、投票、合成。脚本是确定性的代码，每次跑都走相同路径，质量保障因此可以被复现。

把质量从”看运气”转成”看脚本”是 Dynamic Workflow 的本质收益。下面三种模式都是这一收益的具体落地。

二、模式一：对抗式互审

第一种模式由两组 agent 构成正反方：撰写组产出一份结论，复审组对结论逐条挑战，只有经复审挑不掉的结论才进入最终报告。这种模式适合安全审计、鉴权检查、合约审查等”找错比找对更重要”的场景。

1. 撰写组用 read_file、grep 等工具扫描目标范围，按 rubric 输出发现；
2. 复审组拿到撰写组结论后，尝试找到反例或边界失效场景；
3. 脚本按复审反馈把发现分成”确认””可疑””否定”三档；
4. 合成 agent 只取”确认”档生成最终报告，并附每条的复审记录。

// 伪代码：撰写 → 复审 → 合成
const drafts = await parallel(files.map(f => agent({
  prompt: `审计 ${f} 的鉴权覆盖，输出 JSON: {file, finding, severity}`,
  tools: ["ReadFile", "Grep"],
})));

const reviews = await parallel(drafts.map(d => agent({
  prompt: `独立验证以下发现，给出 confirm/reject + 证据: ${JSON.stringify(d)}`,
  tools: ["ReadFile", "Grep"],
})));

const confirmed = drafts.filter((_, i) => reviews[i].verdict === "confirm");
return synthesize(confirmed);

优势是抓到了”测试通过但漏了某条业务规则”这类单 agent 极难自察的盲点。代价是 token 消耗约为单 agent 的两到三倍，复审的提示词需要单独调试。

三、模式二：并行起草择优

第二种模式让多个 agent 独立起草同一份产出，再由一个合成 agent 抽取每份草稿里相对突出的片段拼成最终方案。适合方案规划、文案撰写、UI 设计等”主观但有优劣”的场景。

1. 同一份任务描述并行派给 N 个起草 agent（默认 N=3 即可）；
2. 每个 agent 在独立上下文里产出一份完整草案；
3. 合成 agent 拿到 N 份草案，按 rubric（覆盖度、清晰度、可执行性）逐项打分；
4. 取每项得分靠前的片段拼合，附每段的来源草案 ID 便于追溯。

const drafts = await parallel([1, 2, 3].map(n => agent({
  prompt: `起草产品方案 #${n}，关注 X / Y / Z 三个维度`,
  model: "claude-opus-4-5",
})));

const best = synthesizeBest(drafts, rubric);
return { plan: best, sources: drafts.map((d, i) => ({ id: i, hash: hash(d) })) };

这种模式的可信度来自”多视角独立起草”：单 agent 容易陷入路径依赖，多份草案相互对照后选择面更大。代价是合成 agent 的设计较难，rubric 必须写得可比较。

四、模式三：收敛投票

第三种模式用在信息检索与事实核查：多 agent 各自搜索同一主题，把命中的每条声明收集起来，按”几个 agent 同时支持”作为可信度评分。这是内置 /deep-research 工作流采用的方法。

1. N 个 agent 用相同的搜索 query 各自拉取资料；
2. 脚本对声明做去重，并统计每条声明被多少 agent 独立支持；
3. 设定阈值（如至少 2 个 agent 支持）才把声明保留到最终报告；
4. 合成 agent 按声明可信度排序输出带引用的报告。

const reports = await parallel(angles.map(a => agent({
  prompt: `围绕 "${query}" 在 ${a} 维度搜索，返回 5 条可引用声明`,
  tools: ["WebSearch", "WebFetch"],
})));

const claims = mergeClaims(reports);
const verified = claims.filter(c => c.supportCount >= 2);
return formatReport(verified);

可信度来自”独立来源数”，每个声明都附了原始链接，便于读者复核。代价是对搜索 query 的设计敏感，query 太宽会让大量声明被多个 agent 误支持，query 太窄又会漏掉重要角度。

五、三种模式的横向对比

三种模式常常组合使用：先并行起草，再用对抗式互审挑刺，最后按投票结果收敛。一个工作流内可按 phase() 串接多阶段，phase 之间由脚本守住数据流。

六、落地时容易踩的三个坑

第一是 agent() 不指定 model。在大规模工作流里，模型参数会继承会话当前模型，外部因素（如 /model 切换）会让同一种行为跑出不同结果。在关键阶段显式指定 model 参数，可以稳定跨会话的质量。

第二是把脚本本身当成 agent。脚本是编排，不是判断。脚本能决定什么时候调 agent，但不能代替 agent 做语义判断。把”哪种方案更好”这种问题硬塞进脚本的 if-else，等于把质量保障从模型搬回程序员，得不偿失。

第三是忘记把脚本保存成命令。Dynamic Workflow 的一次性脚本价值有限，用 /workflows 视图按 s 把成功的脚本保存为命令，下次直接 /命令名 调用，可重复运行才能把质量模式沉淀为团队资产。

七、配合 ultracode 模式与深度研究

/Effort ultracode 模式让 Claude 自动判断哪些任务需要触发工作流，一个请求可能被拆成多个工作流串行：先理解代码、再做修改、再验证结果。适合”任务量大但要求可信”的大规模迁移与安全审计。

内置的 /deep-research 则是收敛投票模式的现成实现：提示词里写”围绕 X 做深度研究并交叉验证来源”即可触发，省去自己编排的步骤。日常的代码审查、API 鉴权扫描、死代码巡检等任务都可以用类似模板快速复用。

常见问题（FAQ）

Q1：Dynamic Workflow 与并行子代理有什么本质区别？

并行子代理是”模型在每轮决定下一步”，Dynamic Workflow 是”脚本一次性决定流程”。前者灵活但不可复现，后者确定但可重跑。

Q2：可信度提升到底来自哪里？

来自”多视角独立产出 + 客观规则筛选”。单 agent 既生成又评估的循环被打破，结论必须经结构化流程存活。

Q3：什么任务不适合用 Dynamic Workflow？

一次性小任务、纯对话问答、需要人类反复确认的开放式决策，这些用 Dynamic Workflow 反而更慢更贵。