模式矩阵 /模式白皮书/F1

文档状态：本页为公开评审稿。模式定义与分类可供讨论和引用；未附来源链接的数字与应用示例只用于说明机制，不作为行业基准。

问题

主观判断密集的任务没有标准答案，只有质量谱系——写作、设计、代码风格、产品文案、学术摘要都属于这一类。便宜模型第一次往往写不到位，但人类作家写完文章会回头读三遍，每读一遍改一遍，到边际收益降下来就停笔。这个"自己回看、自己改进"的能力是输出质量的关键，单次生成拿不到。

Generator-Critic 把这个流程编码进 agent：generator 写初稿，critic 回看挑问题，generator 拿着反馈再改，循环到 critic 满意或触及迭代上限。它是反思模块里最简的工程实现，2023 年 Reflexion 论文奠定，到 2026 年仍是反思模式的工业基线——Self-Refine 在 7 个任务上平均拿到约 20% 的绝对提升，且不需要训练数据。

分类依据：反思 × 链式

• 纵轴 · 反思：critic 是 agent 对自己输出的审视，让 agent 自己批评自己，这是最经典的反思形态。它不引入新 agent，也不检索外部知识，整个回看动作发生在同一个推理过程内部。
• 横轴 · 链式：它的骨架是 generate → critique → revise 的三步线性管道，每步一个角色、一段独立 prompt，前一步的产出喂给后一步。这条 chain 可以重放、必要时多走几轮，但迭代不是它的强制结构——强制循环是自愈循环（F4）的领域。F1 与 F4 的本质边界正在这里：F1 起点是"输出可用、想再好一点"的链式精修，F4 起点是"输出已坏、必须修好"的强制循环。

解决方案与机制

一个 Generator-Critic 闭环由三段组成：

1. 生成：generator 产出初稿。这一步用什么模型决定了 critic 要补多少。
2. 批评：critic 评估当前输出，产出结构化判决（issues 列表 / severity / 一个显式的 no_changes_needed 字段）。Reflexion 论文的关键创新是 critic 产出自然语言 reflection 文本而非单纯打分，告诉 generator 哪里错、为什么错、下次怎么改。
3. 改进：generator 拿着 critique 重写。然后回到第 2 步，直到 critic 通过或迭代触底。

critic 的可靠性是整个闭环的命门。它的来源按可靠性递增分三类，选哪一类取决于任务有没有 deterministic 信号：

适用条件

• 内容生成类任务：写作、翻译、摘要、文案、学术摘要润色——没有客观对错但有明显质量差异，critic 能稳定看出"哪里不够好"。
• 代码风格与可读性优化：命名、注释、结构调整这类不影响正确性但影响质量的改进。
• 便宜模型托底的高频任务：用 cheap model 做 generator，critic 把质量抬到可接受线，整体成本远低于直接上昂贵模型。

已知失效方式

• 在 Reflection Light 领域硬用：人一眼能看出对错、有客观判据的任务（数学题、SQL、单元测试结果），直接拿测试或 schema 当 critic 比让 LLM 自评准得多，套 Generator-Critic 是绕远路。
• critic 比 generator 还弱：critic 模型能力不足时，它评不出真问题反而引入噪声，闭环越跑越差。critic 至少要和 generator 同档或更强。
• critic 强行找问题：critic prompt 没明示"no changes needed 是合法选项"，它会凑数虚构问题。Reflexion 在 MBPP 上测出 critic 给已经正确的代码挑错的概率达 16.3%，加一句"已合格就输出 no changes needed"能把这个比例显著压下来。
• 同源偏差不设防：critic 和 generator 是同一个 LLM 时存在 self-enhancement bias，它倾向给自己的输出打高分。高 stake 任务要换 vendor 或加 external grounding。
• 迭代不熔断：不设 max_iterations 会触发 over-thinking——critic 把上一轮的虚构当依据继续虚构，几轮后 agent 说服自己输出严重有问题。

验证指标

• critic 收敛率（健康区 2-3 轮内收敛）：超过 3 轮还不通过，说明 critic 标准失调或 generator 能力不够。
• phantom issue 率（健康区 <10%）：critic 对已合格输出挑错的比例。高于 15% 说明 critic prompt 缺"no changes needed"出口。
• critic-vs-expert 一致率（健康区 >70%）：每周抽 50-100 条 critic 输出对比专家判断。低于 70% 要重写 critic prompt 或换模型。
• 质量增量（健康区比单次生成高 5-15%）：低于 3% 说明反思没起作用，高于 25% 说明 generator 单次配置本身有问题，先修 generator。

参考实现

output = generator(task)
for i in range(MAX_ITERATIONS):       # MAX=3, Aider 同源熔断
    if external_critic:               # 有 deterministic 信号优先
        critique = external_critic(task, output)
    elif multi_critic:                # 多角色并行 + 仲裁
        critique = merge(critic(task, output, role=r) for r in roles)
    else:
        critique = critic(task, output)
    if critique.no_changes_needed:    # 合法出口, 防 phantom issue
        return output, "converged"
    output = generator(task, previous=output, feedback=critique)
return output, "max_iterations_reached"   # 触底转 HITL

四个工程要点：critic prompt 必须明示 no_changes_needed 是合法选项；有 test/schema/引用库等 deterministic 信号时优先走 external critic；max_iterations 不要随便调大，3 是经验上的最优；完整 history 留档作为 critic calibration 的源数据。

应用示例

一家学术出版社的论文摘要润色 Agent，第一版用单 prompt 完成（"请优化这段摘要"），线下评测平均编辑评分 8.2/10。第二版加了 Generator-Critic 循环（"写完自己 review，找 3 个改进点再优化"），平均分反而掉到 7.4——复盘 trace 发现 critic 在过度修改，把简洁摘要改写成冗长版，三个 issue 全是虚构的。第三版改了三件事：critic prompt 加"已写好就输出 no changes needed"，phantom issue 率从 16.3% 降到 7%；引入 3 角色 multi-critic（学术严谨性 / 简洁性 / 术语准确度）并行评后仲裁，其中术语 critic 是 external-grounded，查引用数据库验证摘要里的 cite 是否真实存在；每周抽 50 条 critic 输出对比专家判断校准 prompt。修完平均分升到 8.9，比第一版基线高 0.7，代价是单次 token 成本涨 2.8 倍。摘要属于 high-stake 内容，这笔账划算。

相关模式

• Self-Heal Loop（F4）：兄弟模式，边界要钉清楚。Generator-Critic 是"生成后改进"，起点是输出可用、循环是质量提升、replay 是 optional；Self-Heal Loop 是"失败后修复"，起点是输出已坏、loop 是 mandatory 结构。前者用于主观任务，后者用于有 deterministic 失败信号的任务。
• Adversarial Review（协作模块）：升级形态。Generator-Critic 是"同一个模型换 prompt"，Adversarial Review 是"独立 agent 带对抗激励"。前者解决"agent 怎么改自己"，一个 LLM 进程加两段 prompt 即可；后者解决"决策怎么经过 audit-grade 独立审查"，需要 model routing、独立 trace、跨 agent 编排，token 成本约 9 倍。错代价低用前者，金融审批 / 医疗诊断这类需要监管独立性的场景升级到后者。
• Skill Package（F2）：衔接关系。Generator-Critic 改的是当下这次输出，Skill Package 沉淀的是跨任务的成功流程。

设计结论

Generator-Critic 的本质不是"加一个评审"，而是把"评估比生成简单"这条软件工程几十年的不对称性显式化——让同一个模型用"易"（评估）反过来约束"难"（生成）。

企业证据

当前没有与本模式绑定的公开评审案例。模式定义不因此视为已经获得企业验证。

案例收录要求说明业务约束、实现结构、已知失败和迁移边界。参见 贡献与评审规则。