当一个多 Agent 系统开始稳定运行之后，很快会遇到一个非常现实的问题：

是不是所有结果都应该直接交给用户看？

如果答案是“是”，用户很快就会发现自己在替系统做最基础的质检。
这会让体验越来越差。

所以当前项目后来继续往前走了一步：

在人工审批之前，先让系统做一层质量闸门。

这章就围绕这个问题来讲：

  • 为什么生成和校验最好分开
  • Dispatcher 后为什么要做一致性检查
  • Reviewer 为什么要输出结构化结论
  • 什么情况下应该自动回炉，而不是直接抛给用户

为什么“生成”和“校验”最好拆开

这是一个很重要的工程经验。

生成模型擅长的是：

  • 往前写
  • 补全内容
  • 给出看起来合理的结果

但它不一定擅长稳定地做这些事：

  • 严格贴题
  • 严格执行约束
  • 严格判断是否达标

换句话说：

生成和校验虽然都可以用 LLM 做，但它们是两类不同的工作。

当前项目后来的演进，本质上就是把这两类工作逐步拆开。

第一层质量闸门：Dispatcher 一致性检查

为什么首先要检查 Dispatcher？
因为它决定了整个任务的方向锚点。

如果 Dispatcher 一开始就跑偏了，后面的：

  • Research
  • Writer
  • Reviewer

都会沿着错误方向往下走。

当前检查什么

在当前项目里，Dispatcher 后面会做一个轻量检查，重点看三件事：

  • 是否贴合原始选题
  • 是否符合用户给定角度
  • 是否存在明显偏题或概念偷换

为什么不检查太多

因为这一层的目标不是“审稿”，而是“守住方向”。
它只要负责把明显偏题的情况拦下来就够了。

发现明显偏题后怎么办

这里当前项目采取的是比较合理的策略：

先系统自修，而不是立刻丢给用户。

也就是说，如果 Dispatcher 结果明显不一致，系统会自动让它重做一次。

这符合一个很重要的产品原则：

事实性偏题，优先系统修；偏好性取舍，再让用户定。

第二层质量闸门：Reviewer 结构化输出

到了 Writer draft 之后，系统已经有了真正的文章内容。
这时单靠一段自然语言审稿意见已经不够了，因为流程需要知道：

  • 是可以继续
  • 还是需要修订
  • 还是应该整体重写

所以当前项目后来把 Reviewer 升级成了结构化质量闸门。

当前的结构化结果是什么

Reviewer 会输出：

  • pass
  • revise
  • rewrite

再配上：

  • 原因
  • 必改项
  • 审核意见

这让系统不只是“拿到一段评论”，而是能基于结果做流程判断。

为什么 Writer 后不再额外加一个新检查器

在这个项目里，Writer 后本来就已经有 Reviewer。
所以更好的做法不是再加一个重复检查节点，而是：

让 Reviewer 兼任质量闸门。

这比再加一个独立 Agent 更合理，因为它能避免：

  • 职责重复
  • 流程变长
  • 成本和时延增加

当前项目走的正是这条路。

pass / revise / rewrite 这三个结论为什么很关键

这三个结论本质上是在定义：

当前产物有没有资格进入下一阶段。

pass

说明当前内容质量足够，可以继续。

revise

说明方向基本对，但还有必须修的问题。
这时候不需要整篇推倒重来，而是进入修订流程。

rewrite

说明当前初稿已经明显不合格，比如：

  • 明显跑题
  • 讨论对象错了
  • 结构性失真很严重

这时如果还把内容交给用户确认，用户会很容易觉得系统在让自己做底层质检。

为什么 rewrite 时应该自动回炉

这是当前项目最近非常关键的一次演进。

在以前，如果初稿很差，系统也可能直接把它放到 writer_done 审批点。
这样的问题是：

  • 用户体验差
  • 多轮 reject 增多
  • 系统缺少最低限度的自救能力

所以当前项目后来增加了自动回炉逻辑：

  1. Reviewer 判定为 rewrite
  2. 系统自动回炉一次 Writer draft
  3. 回炉成功后再次跑 Reviewer
  4. 再决定是否继续进入 revision

这一步的意义不是“更智能”，而是：

把明显不合格的内容尽量挡在用户看到之前。

自动回炉为什么还要配失败重试和状态修复

自动回炉一旦进入真实系统，很快就会碰到一个比“能不能回炉”更现实的问题：

回炉过程中失败了怎么办？

当前项目在这一块其实踩过很真实的坑：

  • 自动回炉触发后，Writer draft 超时
  • 通用失败重试恢复时，曾经错误地直接掉回 writer_done
  • 结果绕过了“重写后再复审”这条预期路径

后来项目专门补了这块语义：

  • 为自动回炉引入独立状态标记
  • 失败恢复时继续留在自动回炉子流程里
  • 回炉成功后强制再跑第二次 Reviewer

这说明质量闸门不是“判断一下就完了”，它一旦接入真实流程，就必须考虑恢复语义。

最近这个项目还对自动回炉做了什么优化

为了让这条链路更稳，项目最近还对自动回炉阶段单独调了调用策略：

  • 自动回炉 Writer draft 用更长的超时
  • 第二次 Reviewer 用更长的超时
  • Writer revision 也用了更稳的参数

这些优化不是理论推演，而是结合真实任务跑通结果做出来的。

当前已经通过：

  • 真实任务验证
  • 自动化测试

确认了整条闭环可以走通：

Reviewer -> reviewer_auto_rewrite -> Writer draft -> Reviewer -> Writer revision -> revision_done

当前项目里的质量闸门本质上解决了什么

如果总结一下，这套设计本质上解决了三个问题。

1. 不要把明显偏题的方向放大

靠 Dispatcher 一致性检查来守方向。

2. 不要把明显不合格的初稿直接丢给用户

靠 Reviewer 的 rewrite 和自动回炉来挡掉低质量内容。

3. 不要让系统只会生成，不会自检

靠结构化质量闸门把“生成”和“校验”分开。

当前项目下一步还能怎么继续演进

质量闸门现在已经成型了，但后面仍然可以继续增强。

比如：

  • 更细的质量标签
  • 根据文章类型切换不同审稿标准
  • 让任务详情页更明确展示当前质量结论
  • 针对 pass / revise / rewrite 做更细的自动流程策略

但即使不继续扩展，当前这套设计本身已经非常值得借鉴。

这一章的结论

在 Agent 系统里，生成和校验最好分开处理。

当前项目给出的一个很实用的路线是：

  • Dispatcher 后先做轻量一致性检查
  • Writer draft 后由 Reviewer 负责结构化质量闸门
  • 对 rewrite 的情况先系统自修，再让用户确认

这让系统从“只会输出内容”升级成了“会先做最低限度自检”。

下一章看什么

当系统开始有：

  • 上下文系统
  • 多轮反馈
  • 质量闸门

之后，调试难度也会显著上升。
这时候只看 Prompt 已经远远不够了。

下一章我们就讲，当前项目是怎么把调试体系补起来的，包括：

  • Context Breakdown
  • LLM Call
  • Quality Gate
  • 步骤日志和快照

也就是一个 Agent 产品到底该怎么调试。