企业官网建设流程全解析

Harness Producer-Reviewer模式：质量审查如何避免无限循环

【免费下载链接】harnessA meta-skill that designs domain-specific agent teams, defines specialized agents, and generates the skills they use.项目地址: https://gitcode.com/GitHub_Trending/harness/harness

Harness 是一个面向 Claude Code 的"团队架构工厂"——用一句话描述你的领域，它就能自动生成一支由专职 AI Agent 组成的团队，以及它们各自的技能。在 Harness 提供的 6 种团队架构模式中，Producer-Reviewer 模式（生成-验证模式）是保证产出质量最常用的方案：先由生成者产出，再由审查者质检，不合格就重新生成。但不少用户在实际落地时都踩过同一个坑——审查者总挑出毛病、生成者反复重做，结果陷入"审查→重审"的无限循环，白白烧掉时间和 Token。这篇文章带你用 3 个关键设计（最大重试次数、三级判定、升级路径）彻底避免这个陷阱。

什么是 Producer-Reviewer 模式：先生成，后审查

Producer-Reviewer 模式让**生成 Agent（Producer）与审查 Agent（Reviewer）**成对协作，工作流是一个带回路的闭环：

[生成 Agent] → [审查 Agent] → （发现问题）→ [生成 Agent 重新执行]

它的核心思想借鉴了人类团队的"写稿人 + 编辑"分工：写的人不负责挑错，挑错的人不负责重写。两个角色各司其职，互相制衡，产出质量自然更高。

这个模式最适合两类场景：

• ✅产出质量要求高：内容要对外发布、代码要合并上线
• ✅存在客观验证标准：比如风格一致性、可读性、数据准确性，而不是纯主观偏好

模式的完整定义可以查阅官方参考文档：agent-design-patterns.md。

为什么质量审查容易陷入无限循环？

听起来很美的"生成→审查→再生成"闭环，一旦缺少约束条件，就会变成成本黑洞。常见的三个失控原因：

Harness 的官方文档对此有明确警告："무한 루프 방지를 위해 최대 재시도 횟수(2~3회) 설정 필수"——为防止无限循环，必须设置最大重试次数（2~3 次）（见 agent-design-patterns.md）。下面三个设计点，就是 Harness 给出的完整答案。

避免无限循环的 3 个关键设计

关键一：设置最大重试次数（2~3 次）

这是防循环的第一道"硬闸门"。在审查者的定义文件中明确写死循环上限，例如"再生成后重新审查，最多 2 次循环"。到达上限后不再无限重试，而是进入升级路径（见关键三）。

💡 经验值：2~3 次足够覆盖绝大多数"可以修好"的问题；超过 3 次仍在循环，通常说明问题不在产出本身，而在需求描述或上游输入。

关键二：用客观标准的三级判定（PASS / FIX / REDO）

循环失控往往源于审查结论模糊。Harness 的示例审查者（webtoon-reviewer）要求每次审查必须输出明确的三级判定：

• ✅PASS：合格，直接通过
• 🔧FIX：局部小修即可，附具体修改方向
• 🔄REDO：需要整体重新生成，附具体重做要求

同时强调：审查者必须基于客观标准（一致性、可读性、构图等）判断，而不是主观口味。判定越具体，生成者的返工就越有的放矢，一轮就能修对——减少"修了个寂寞"式的空转循环。

关键三：为"重试用尽"设计升级路径

到达重试上限后，流程不能简单"卡死"，而是向上升级。Harness 的实战方案分三层：

1. 强制 PASS + 警告：2 次重做后仍不合格的面板，带上警告标记放行，不阻塞整体进度
2. 根因升级：如果超过 50% 的产出被判 REDO，说明不是"手滑"而是提示词/需求本身有问题——此时向用户提出修改建议，改源头而不是死磕循环
3. 缺失显式化：单点失败重试 1 次仍不行，就在最终报告中标注"该部分未收集"，继续推进整体流程（见 orchestrator-template.md）

这三层设计保证了：任何情况下，流程都能收敛出结果。

实战案例：Webtoon 制作团队的"最多 2 次循环"

Harness 文档中有一个非常完整的 Producer-Reviewer 落地案例——Webtoon 漫画制作团队，由webtoon-artist（画师）和webtoon-reviewer（质检）两个 Agent 组成：

• Phase 1：画师 Agent 生成面板图像
• Phase 2：质检 Agent 逐面板输出 PASS/FIX/REDO 判定报告
• Phase 3：对 REDO 面板定向重新生成（携带具体修改指令，最多 2 次）

其重试策略原文为：

REDO 判定面板 → 向画师发起重生成请求（含具体修改指令） 最多 2 次循环后强制 PASS 超过 50% 面板为 REDO → 向用户提出提示词修改建议

这个案例完整演示了"硬上限 + 具体反馈 + 根因升级"三件套如何协同，完整定义见 team-examples.md。

循环终止条件：同样适用于技能测试与团队进化

"有限循环"的思想在 Harness 中是全局性的。在技能测试阶段，官方定义了明确的迭代改进循环终止条件（见 skill-testing-guide.md）：

• 用户表示满意
• 反馈全部为空（所有产出无问题）
• 已无有意义的改进空间

此外，Harness 的 QA 指南还建议在每个模块完成后立即执行 QA（增量式审查），而不是等全部做完再一次性审查——早期发现边界问题，能避免错误累积后引发更大范围的返工循环。完整方法见 qa-agent-guide.md。

快速上手：5 分钟搭一支质量审查团队

想在自己的项目中用上 Producer-Reviewer 模式？流程非常简单：

1. 按 docs/quickstart.md 安装 Harness 插件并启用 Agent Teams
2. 对 Claude Code 说一句话触发："Build a harness for this project"
3. Harness 会自动分析你的领域，生成.claude/agents/下的 Agent 定义与.claude/skills/下的技能文件

如果你的领域涉及内容创作、文档生成、代码产出等"质量敏感"任务，可以直接在触发语中说明"生成后需要质量审查"，Harness 会优先为你设计 Producer-Reviewer 架构。整个 6 阶段工作流详解见主技能文件 SKILL.md。

总结：让质量审查"审得动，也停得下"

Producer-Reviewer 模式的价值，不在于"审查"本身，而在于有节制、可收敛的审查。回顾本文的三个关键设计：

• 🔢硬上限：最大重试 2~3 次，从机制上杜绝无限循环
• 📋三级判定：PASS / FIX / REDO 客观标准，让反馈可执行
• 🚀升级路径：重试用尽就放行+警告、改提示词根因、缺失显式标注，流程永远能收敛

记住这个心法：审查者可以挑剔，但流程必须有出口。这既是对产出质量的保证，也是对时间与 Token 成本的尊重。

【免费下载链接】harnessA meta-skill that designs domain-specific agent teams, defines specialized agents, and generates the skills they use.项目地址: https://gitcode.com/GitHub_Trending/harness/harness