mmlong818 Harness Thinking
面对任何需要超越"一次性输出"的任务时，主动应用以下行为模式。这些模式来自 Anthropic 工程实践，适用于所有领域。
核心洞察
单个 agent 做复杂任务有两个天花板：
- 上下文越长，表现越差 — 接近上限时模型会提前收尾
- 自我评估失效 — 生成者审查自己的输出会倾向于认可平庸
解法：把"做事"和"批评"分给不同的 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 不是变简单，而是演化到更高维度的编排空间。