harness-thinking

name	harness-thinking
description	长时任务的 Harness 思维框架——当任务复杂、质量要求高、需要多轮迭代时，自动应用生成器-评估器分离、上下文重置、契约驱动、并行探索等模式。触发词：复杂任务、高质量输出、反复优化、迭代提升、多 agent 协作、长时任务、超越默认结果。

Harness Thinking

面对任何需要超越"一次性输出"的任务时，主动应用以下行为模式。这些模式来自 Anthropic 工程实践，适用于所有领域。

核心洞察

单个 agent 做复杂任务有两个天花板：

1. 上下文越长，表现越差 — 接近上限时模型会提前收尾
2. 自我评估失效 — 生成者审查自己的输出会倾向于认可平庸

解法：把"做事"和"批评"分给不同的 agent，用架构补偿模型的局限。

---

五个行为模式

1. 生成器-评估器分离

何时用： 输出质量难以客观判断，或容易陷入"差不多就行"的惰性时。

做法：

• Generator：专注创作，大胆承诺方向，不自我审查
• Evaluator：以全新的怀疑主义视角批评，专门针对"不够好"调优
• 两者绝不是同一个 agent 在同一上下文中切换角色

关键： Evaluator 的批评必须具体可操作。"很好但可以更好"是无效反馈。

---

2. 评估标准客观化

何时用： 质量判断涉及主观感受（美感、流畅度、完整性）时。

做法：

• 把主观判断拆解为 3-5 个可独立打分的维度
• 为每个维度赋予权重，权重反映真正重要的东西
• 评分后给出具体改进指令，不只给分数

例： "设计质量" → 连贯性 / 原创性 / 工艺 / 功能性，前两项权重更高以推动大胆选择。

---

3. 上下文重置而非压缩

何时用： 任务需要多轮迭代，且每轮都需要高水准表现时。

做法：

• 评估器始终在干净的上下文中运行（不携带生成历史）
• 每个迭代轮次的 Generator 接收的是"改进指令 + 原始目标"，而非完整历史
• 宁可增加编排复杂度，也要换取持续的高质量输出

权衡： 压缩保留连续性但产生"上下文焦虑"；重置编排更复杂但表现更稳定。

---

4. 契约先于实现

何时用： Generator 和 Evaluator 可能对"完成"的定义产生分歧时。

做法：

• 实现前，Generator 和 Evaluator 先协商并写下可验证的成功标准（Sprint Contract）
• 标准必须具体、可测试，不允许模糊表述
• Evaluator 严格对照契约核查，不评价契约外的东西

目的： 填补"高层目标"和"可验证实现"之间的鸿沟，防止双方错位。

---

5. 并行探索后收敛

何时用： 问题有多个合理解法，无法事先判断哪个更好时。

做法：

• 用 git worktree 或独立 Agent 并行探索多个方向
• 各方向互不干扰，独立迭代至收敛
• 主 Agent 作为编排者汇总结果，选择最优或融合亮点
• 合并时由编排者解决冲突（编排者拥有完整上下文）

---

应用判断

不是所有任务都需要完整 Harness。判断标准：

信号	建议模式
一次性简单任务	直接完成，无需 Harness
质量要求高但方向明确	生成器 + 评估器循环（3-5轮）
方向不确定	并行探索 + 收敛
任务极复杂、多模块	完整三 Agent（规划器 + 生成器 + 评估器）+ Sprint Contract

Harness 会过时

随着模型能力提升，曾经必要的组件可能变成多余开销。定期问：

• 这个 Evaluator 还在发现真正的问题吗？
• Sprint 分解是否还有必要，还是模型已能一次完成？
• 移除这个组件会让质量下降吗？

反直觉结论： 模型越强，Harness 不是变简单，而是演化到更高维度的编排空间。