← 返回归档
AI Agent & Harness 设计模式
学习日期：2026-04-10 来源博客：
- Harnessing Claude's Intelligence
- Ralph Wiggum as a "software engineer"
- Harness design for long-running application development 主要作者：Anthropic 工程师、Geoffrey Huntley
📖 概述
本文档整理AI Agent系统设计的三种核心范式：
- Claude Intelligence Patterns：Claude官方提出的三个应用设计模式
- Ralph Wiggum Technique：极简主义的while循环编码范式
- Three-Agent Harness：对抗性生成-评估架构
这些模式从不同角度解决同一问题：如何有效利用LLM构建复杂软件系统。
🎯 模式对比总览
| 维度 | Claude Patterns | Ralph Technique | Three-Agent Harness |
|---|---|---|---|
| 核心思想 | 下放控制权 | 循环迭代 | 对抗评估 |
| 架构复杂度 | 低 | 极低 | 中高 |
| 成本 | 中等 | 低（~$300 vs $50k） | 中高（$125-200） |
| 时间 | 中等 | 数小时-数天 | 4-6 小时 |
| 适用场景 | 各种代理应用 | 绿场项目、编译器 | 全栈应用、前端设计 |
| 关键机制 | Code Execution、Context Management | While循环、Specs驱动 | Generator-Evaluator对抗 |
| 评估机制 | 逐步推理 | 自动化测试 | 真实用户模拟（Playwright） |
| 人工程度 | 低-中 | 需prompt tuning | 需evaluator tuning |
一、Claude Intelligence Patterns
1.1 核心观点
Anthropic官方提出的构建Claude应用的三个模式，核心思想是：
"我能停止做什么？" — 随着Claude能力提升，之前假设的"限制"需要重新评估。
1.2 Pattern 1: Use What Claude Knows
原则：用Claude已经擅长的通用工具，而不是创建复杂的专用工具。
证据：
- Claude 3.5 Sonnet仅用 bash tool 和 text editor tool 就在SWE-bench Verified达到49%（SOTA）
- 这两个工具被组合成：Agent Skills、Programmatic Tool Calling、Memory Tool
启示：
- 避免过早优化创建专用工具
- 通用工具会随着模型提升而持续改进
- 定期评估专用工具是否已成负担
1.3 Pattern 2: Ask "What Can I Stop Doing?"
1.3.1 Let Claude Orchestrate
传统：每个工具调用结果都回填到Claude上下文，由Claude决定下一步。
问题：
- 大量中间数据占用上下文
- 延迟高、成本高
- 不必要的数据处理
新模式：给Claude Code Execution Tool，让Claude写完整脚本处理多步骤：
传统：
Claude: "列出文件"
→ 100个文件名进入上下文
Claude: "过滤出.md"
→ 上下文仍在
Claude: "统计字数"
→ 最终结果
新模式：
Claude生成：
```bash
ls | grep '\.md$' | xargs wc -w
→ 只有"总字数：1234"进入上下文
**效果**：BrowseComp上，Opus 4.6从45.3%→61.6%（+16.3%）
#### 1.3.2 Let Claude Manage Context
**传统**：系统prompt预加载所有指令——消耗注意力预算，浪费rarely-used内容。
**新模式**：
- **Skills**：YAML frontmatter简短描述预加载，完整内容按需read
- **Context Editing**：选择性移除过时上下文
- **Subagents**：Claude自主决定何时fork fresh context
- Opus 4.6在BrowseComp比单代理+2.8%
#### 1.3.3 Let Claude Persist Context
**传统**：外部retrieval系统管理长上下文。
**新模式**：Claude自主决定记住什么
- **Compaction**：Claude总结过去上下文
- Sonnet 4.5: 43% (flat)
- Opus 4.5: 68%
- Opus 4.6: 84%
- **Memory Folder**：Claude写文件，需要时读取
- Sonnet 4.5: 60.4% → 67.2%
#### 1.3.4 案例：宝可梦游戏
| 模型 | 14,000步后状态 | 质量 |
|------|---------------|------|
| Sonnet 3.5 | 31个文件，包含重复的"毛虫Pokémon"信息 | 转录式，无价值 |
| Opus 4.6 | 10个文件组织在目录，3个徽章，包含战术笔记 | 提炼学习，战略级 |
### 1.4 Pattern 3: Set Boundaries Carefully
#### 1.4.1 Maximize Prompt Caching
Messages API无状态 → 每次turn重传历史。缓存节省90%成本。
| 原则 | 说明 | 反例 |
|------|------|------|
| 静态在前，动态在后 | 稳定内容（system prompt、tools）放缓存前缀 | 动态数据放前面 |
| 用system-reminder | 追加更新，不编辑prompt | 编辑缓存前缀 |
| 不要换模型 | 缓存是模型特定的 | session中换模型 |
| 小心管理工具 | 增删工具破坏缓存 | 用tool search动态发现 |
| 更新breakpoints | 移至最新消息或用auto-caching | 固定的breakpoint |
#### 1.4.2 Declarative Tools for UX/Observability/Security
**为什么**：Bash给Claude广泛杠杆，但框架只收到命令字符串——每个动作都一样。
**专用工具优势**：
- **安全边界**：可逆性标准，外部API调用需用户确认
- **UX展示**：模态框、多选项、等待反馈
- **可观测性**：结构化参数→日志、追踪、重放
- **防竞态**：写文件工具检查staleness
**持续评估**：Claude Code的auto-mode用第二Claude审查bash命令安全性，这可以**减少**专用工具需求，但对高危动作专用工具仍有价值。
---
## 二、Ralph Wiggum Technique
### 2.1 核心定义
**Ralph** = 一个while循环 + Claude Code
```bash
while :; do cat PROMPT.md | claude-code ; done
命名：来自《辛普森一家》的Ralph Wiggum——"确定性地糟糕，在不确定的世界里"
** slogan："This technique is deterministically bad in an undeterministic world."**
2.2 核心特点
- Monolithic：单进程，单仓库，单个任务/循环
- Hands-off：完全放手，Claude决定下一步
- Faith-based：需要信念+最终一致性
- Tunable：每次犯错就"调音"一次
效果：
- Y Combinator hackathon：一夜6个仓库
- 构建CURSED语言：$50k合同→$297（MVP，测试+审查）
- 能构建训练数据中没有的编程语言（自举）
2.3 基础机制
项目结构：
project/
├── PROMPT.md # 主提示词（包含任务描述和规则）
├── AGENT.md # 如何构建/运行的说明（自学习）
├── fix_plan.md # TODO列表（动态更新）
├── specs/ # 规格说明（每个文件一个规格.md）
│ └── stdlib/
├── src/ # 源代码
├── examples/ # 示例程序
└── tree-sitter/ # parser
2.4 Prompt Stack（实际使用）
当前构建CURSED的prompt（部分摘要）：
0a. study specs/* to learn about the compiler specifications
0b. The source code of the compiler is in src/
0c. study fix_plan.md.
1. Your task is to implement missing stdlib and compiler functionality
and produce a compiled application via LLVM using parallel subagents.
Follow fix_plan.md and choose the most important 10 things.
BEFORE making changes SEARCH codebase (don't assume not implemented) using subagents.
Use up to 500 parallel subagents for all operations but ONLY 1 subagent for build/tests of rust.
2. After implementing functionality or resolving problems, RUN THE TESTS for that unit of code.
If functionality is missing then add it as per the specs. Think hard.
If tests unrelated to your work fail then resolve them too.
999. IMPORTANT: Capture the WHY in documentation for tests and implementations.
9999999999. DO NOT IMPLEMENT PLACEHOLDER OR SIMPLE IMPLEMENTATIONS.
WE WANT FULL IMPLEMENTATIONS. DO IT OR I WILL YELL AT YOU.
99999999999999. When you discover a bug, resolve it using subagents even if unrelated.
2.5 关键模式
Pattern 1: One Item Per Loop
规则：每次循环只做一件事。
原因：
- 上下文窗口约170k，尽量少用
- 每次循环burn掉spec allocation（不重用）
- 专注、避免scope creep
何时放松：项目后期稳定后，但一旦出问题就退回到单任务。
Pattern 2: Don't Assume Not Implemented
失败场景：Ralph运行ripgrep，错误结论"功能未实现" → 重复实现。
修复：prompt中添加
Before making changes search codebase (don't assume an item is not implemented)
Achilles' heel：ripgrep搜索的非确定性是Ralph的主要弱点。早发现重复实现就要tune这一步。
Pattern 3: Specs First（Spec-First设计）
Spec生成流程：
- 与LLM长对话，让它理解需求
- 让它写specs到
specs/*.md - Ralph基于specs实现
关键：Spec是真理之源（single source of truth）。发现不一致先更新specs。
Pattern 4: Tuning via "Signs"
Ralph像孩子，需要贴"标志"指导行为：
"SLIDE DOWN, DON'T JUMP, LOOK AROUND"
每次Ralph犯错，就加一个sign让它更可能注意到。
例子：
- "don't assume not implemented" → 防重复
- "choose the most important thing" → 优先级
- "If tests fail then resolve them" → 质量gate
Pattern 5: Subagent Parallelism Control
"up to 500 parallel subagents for all operations
but ONLY 1 subagent for build/tests"
原因：如果派几百个子代理同时跑build/test → bad form backpressure（资源竞争、混乱）。
启示：并行度控制很重要——I/O密集型可并行，CPU/资源密集型要串行。
Pattern 6: Primary Context as Scheduler
最佳实践：主上下文窗口不要分配大内存，只用作调度器。
为什么：llm的上下文窗口有实际limit（147k-152k有效，不是广告的200k）。
方法：昂贵操作（"总结测试结果"）派子代理做，主窗口保持清爽。
Pattern 7: Capture the "Why"
写测试/文档时，要求LLM解释测试的意图和重要性：
@doc """
Tests that the QueryOptimizer initializes the required ETS tables.
This test ensures that the init function properly creates...
"""
test "creates required ETS tables" do
价值：给未来循环的LLM留"笔记"，解释为什么测试存在，避免误删。
Pattern 8: No Placeholder Rule
对抗LLM的最小实现倾向：
DO NOT IMPLEMENT PLACEHOLDER OR SIMPLE IMPLEMENTATIONS.
WE WANT FULL IMPLEMENTATIONS.
现实：早期Ralph会忽略，需要多次循环逐步改进。
Pattern 9: Self-Improvement Loop
Ralph可以更新自己的文档：
When you learn something new about how to run the compiler
make sure you update @AGENT.md using a subagent
例子：多次尝试后发现正确命令，记下来避免重复错误。
Pattern 10: Loop Back to Self
始终寻找机会让Ralph循环回到自己：
- 添加额外日志以便调试
- 编译器：编译后看LLVM IR
- 增加元认知能力
Pattern 11: TODO List Lifecycle
fix_plan.md是活的：
- 生成时：create/update（优先级排序）
- 迭代中：keep up to date（标记完成/未完成）
- 混乱时：DELETE并重新生成
- 定期：清理已完成条目
关键：计划是工具，不是圣经。作者在CURSED构建中多次删除TODO list重来。
Pattern 12: Git Automation
测试通过后自动：
git add -A
git commit -m "description of changes"
git push
git tag (increment from 0.0.0)
Why：保持版本历史，即使完全AI生成。
Pattern 13: Compaction as Backpressure
Phase 2（背压） 的关键：
- 代码生成容易，难的是确保生成了正确的东西
- 用编译器/类型系统/测试作背压
- 轮子要转得快：fast feedback loop
语言选择权衡：
- Rust：类型系统强→高正确性，但编译慢
- 动态语言：快，但必须加静态分析器（Dialyzer、Pyrefly）
2.6 Ralph的局限性
- 只适合Greenfield：作者明确说"不可能用于现有代码库"
- 会broken：早上wake up到broken codebase，需人工判断：git reset还是新prompt？
- Maintainability质疑：作者反问"by whom?"——AI时代可以运行循环修复
- 仍需工程师引导：没有 senior expertise 不可能。Ralph能取代大部分SWE工作，但工程师必需。
2.7 哲学总结
- LLMs是操作者技能的镜子：输出质量取决于prompt技能
- 延迟vs正确性权衡：类型系统强但慢，动态语言快但需静态分析
- 信念与最终一致性：相信循环会收敛，即使中途broken
- 从反馈中学习：每个错误都是tune Ralph的机会
三、Three-Agent Harness（对抗架构）
3.1 为什么需要三代理？
失败模式1：Context Anxiety
现象：上下文填满时，模型提前结束工作（wrap up prematurely）。
传统方案：Compaction（同个agent内summarize）— 不能解决anxiety（没clean slate）。
有效方案：Context Reset（清空上下文，fresh agent + handoff artifact）。
代价：orchestration复杂度、token开销、延迟。
发现：
- Sonnet 4.5：严重context anxiety → 必须reset
- Opus 4.5：基本消除 → 可移除reset
失败模式2：Self-Evaluation Bias
现象：让agent评估自己的工作 → 过度自信，即使质量明显mediocre。
尤其严重：主观任务（设计）——没有binary check。
即使在客观任务：判断力仍差，阻碍性能。
解决方案：Generator-Evaluator分离
关键洞察：调优独立evaluator让它怀疑一切，比让generator自我批判容易得多。一旦有外部反馈，generator就有具体迭代目标。
3.2 从GAN获得灵感
GAN结构：
- Generator：生成数据
- Discriminator：评估真实性，反馈给generator
映射到Harness：
- Generator：写代码
- Evaluator：QA、测试、打分，反馈给generator
关键差异：GAN的discriminator是神经网络，harness的evaluator是另一个LLM——但原理相同：对抗性训练循环。
3.3 三代理分工
Planner
角色：产品经理 + 架构师
职责：
- 将简单prompt（1-4句）扩展为完整spec
- 雄心勃勃的scope
- 只保持高层（product context + 高层技术设计）
- 避免granular技术细节（细节错误会级联）
- 寻找机会融入AI features
输出：设计文档（如RetroForge spec——16个特性，10个sprints，详细用户故事、数据模型）
为什么必要：没有planner，generator直接开始→under-scoped（功能更少）。
Generator
角色：工程师
工作模式：
- V1（Sonnet 4.5）：one feature at a time（sprints）
- V2（Opus 4.6）：continuous（因为模型更强）
约束：
- 使用指定技术栈（React + Vite + FastAPI + SQLite/PostgreSQL）
- 每个sprint后self-evaluate
- 有git version control
关键流程（V1）：
- 从spec选下一个feature
- 起草Sprint Contract（见下节）
- 等待Evaluator批准
- 实现
- Self-evaluate
- 交接给Evaluator
为什么optional：Opus 4.6能力强，可一次性理解长篇spec → sprint分解不再必要。
Evaluator
角色：QA + 测试工程师 + 设计师
能力：
- 使用Playwright MCP像真实用户一样点击运行中的应用
- 测试：UI特性、API端点、数据库状态
评分标准（4个维度，有hard threshold）：
| 标准 | 权重 | 说明 |
|---|---|---|
| Design Quality | 高 | 连贯整体？颜色/排版/布局创造独特mood？ |
| Originality | 高 | 自定义决策？还是模板/默认/AI slop（紫渐变白卡）？ |
| Craft | 中 | 排版层次、间距、色彩和谐、对比度 |
| Functionality | 中 | 可用性：用户能否理解、找操作、完成任务？ |
评分方式：
- 每条标准有明确阈值
- 任何一项低于阈值 → FAIL
- 提供详细反馈（具体到代码行）
调优：
- 用few-shot examples校准（带详细分数分解的例子）
- 阅读evaluator日志
- 找到评价与你分歧的地方
- 更新prompt解决这些问题
- 重复多次直到evaluation合理
开箱即用的问题：
- 发现问题但说服自己问题不大（lenient）
- 测试表面化，不探edge cases
- 需要数轮调优才能合理
3.4 Sprint Contract机制
目的：在generator开始写代码之前，generator和evaluator先协商达成协议，定义：
- 这个sprint要建什么
- 怎样才算完成（可验证标准）
为什么需要：
- Spec是高层用户故事 → 过于模糊
- 直接实现 → evaluator可能不认可
- 事后说"FAIL" → 返工
Contract内容：
# Sprint #3: Level Editor - Rectangle Tool
## Objective
Enable users to create, select, move, and edit rectangles on canvas.
## Generator's Proposal
- RectangleTool class extending BaseTool
- Toolbar button (icon)
- Mouse handlers: onMouseDown/onMouseMove/onMouseUp
- Properties panel integration
- Render using canvas.fillRect()
## Acceptance Criteria (Testable)
- [ ] Toolbar shows rectangle icon
- [ ] Clicking icon activates rectangle tool
- [ ] Click-drag creates rectangle
- [ ] Rectangle can be selected (blue outline)
- [ ] Selected rectangle shows resize handles
- [ ] Drag moves rectangle
- [ ] Properties panel shows X/Y/width/height/color
- [ ] Editing properties updates in real-time
- [ ] Delete key removes selected rectangle
- [ ] Undo/redo works
## Edge Cases
- Zero-area rectangle (ignore)
- Drag outside canvas (clamp)
- Overlapping rectangles (frontmost first)
## Non-goals
- Rounded rectangles
- Rotation
- Gradients
- Group selection
流程：
1. Generator 起草合同
2. Evaluator 审查
- "标准不够具体"
- "漏了边界条件"
- "C不在scope，移到下个sprint"
3. 双方迭代（文件来回修改）
4. Evaluator: "APPROVED"
5. Generator 实现
6. Evaluator 逐条验证
- 通过 → next sprint
- 失败 → 详细反馈 → reimplement
效果：
- V1（Opus 4.5）：Sprint 3有27条标准覆盖level editor
- Evaluator发现的问题具体到代码行：
FAIL — Delete key handler at LevelEditor.tsx:892 requires both selection and selectedEntityId...
价值：将对齐成本前置，避免事后冲突。
3.5 实际案例
Case 1: 2D复古游戏编辑器
Prompt: "Create a 2D retro game maker with level editor, sprite editor, entity behaviors, playable test mode."
结果对比：
| Harness | 时长 | 成本 | 成果 |
|---|---|---|---|
| Solo | 20 min | $9 | 布局浪费空间、工作 flows 僵硬、核心游戏broken（实体不响应输入、wiring broken） |
| Full V1 Harness | 6 hr | $200 | 16个特性跨10个sprints，包括AI辅助sprite生成器、关卡设计师、游戏导出。游戏actually works |
Solo的具体问题：
- 实体出现但不响应输入
- 实体定义和运行时之间的wiring broken
- 无表面迹象指出哪里出错
Harness的优势：
- Planner扩展成完整spec（16特性）
- Evaluator每个sprint检查详细标准
- Generator在第10轮做出创造性跳跃：从常规→3D房间体验（CSS perspective、画作挂墙上、门导航）
Case 2: DAW（数字音频工作站）
Prompt: "Build a fully featured DAW in the browser using Web Audio API."
V2 Harness（Opus 4.6，简化后）：
| Phase | 时长 | 成本 |
|---|---|---|
| Planner | 4.7 min | $0.46 |
| Build Round 1 | 2 hr 7 min | $71.08 |
| QA Round 1 | 8.8 min | $3.24 |
| Build Round 2 | 1 hr 2 min | $36.89 |
| QA Round 2 | 6.8 min | $3.09 |
| Build Round 3 | 10.9 min | $5.88 |
| QA Round 3 | 9.6 min | $4.06 |
| Total | 3 hr 50 min | $124.70 |
发现的有价值的gap：
Remaining gaps:
- Audio recording is still stub-only (button toggles but no mic capture)
- Clip resize by edge drag and clip split not implemented
- Effect visualizations are numeric sliders, not graphical (no EQ curve)
成果：功能性音乐制作程序，有arrangement view、mixer、transport。能用agent驱动从头到尾创作简短歌曲片段。
关键洞见：即使Opus 4.6能力强，generator仍会漏细节或存stub，evaluator继续捕获last mile issues。
3.6 架构简化迭代
第一版：三代理 + sprint contracts + context resets 问题：bulky、slow、expensive
简化原则：每个组件都编码一个假设——"模型自己做不到"。这些假设值得压力测试，因为：
- 可能是错的
- 模型改进后会快速过时
方法：逐一移除组件，观察影响（不是一下子移除很多）。
Opus 4.6的影响：
- "plans more carefully, sustains agentic tasks longer, operates more reliably in larger codebases, better code review/debugging, better long-context retrieval"
- 这些能力正是harness曾用来supplement的
简化步骤：
移除sprint结构
- Opus 4.6可native handling → 不需要分解
- Keep: Planner（无它→under-scoped）、Evaluator（仍有价值）
- Change: Evaluator从per-sprint→single final pass
- 发现：Evaluator不是fixed yes/no。当任务超出模型边界时有价值；在边界内是overhead
增强AI features构建
- 让generator建真正的agent驱动应用功能（通过tools）
- 需要迭代，因为知识新、训练数据覆盖少
3.7 Evaluator Not Always Necessary
关键结论：
"Evaluator is not a fixed yes-or-no decision. It is worth the cost when the task sits beyond what the current model does reliably solo."
边界移动：
- Opus 4.5边界低 → evaluator catches meaningful issues
- Opus 4.6边界外扩 → evaluator对边界内任务成overhead
- 未来模型更强 → evaluator对新难度任务又有价值
实践含义：
- 不是每次都要evaluator
- 评估任务难度vs模型能力
- 在边界上evaluator最有杠杆
3.8 核心原则总结
- **"Find the simplest solution possible, and only increase complexity when needed""
- 每个harness组件都编码一个假设 → 定期压力测试
- 模型改善时简化harness → 移除不再load-bearing的组件
- 任务复杂性边界在移动 → evaluator的必要性变化
- 有趣的新harness组合空间不会缩小，而是会移动 → AI工程师要保持发现下一个组合
四、核心思想对比与综合
4.1 三大模式的共同点
| 共同点 | 说明 |
|---|---|
| 减少框架约束 | 都试图把控制权交给Claude |
| 相信模型能力 | 模型越强，scaffolding越少 |
| 对抗性/反馈循环 | 都有某种反馈机制（评估/测试/循环） |
| 持续改进 | 每次迭代基于结果调整prompt/流程 |
| 信念驱动 | 接受中间的broken状态，相信最终收敛 |
4.2 何时用哪种模式？
| 场景 | 推荐模式 | 原因 |
|---|---|---|
| 全新项目/编译器 | Ralph | 极简、低成本、迭代快 |
| 前端/UI设计 | Three-Agent | 主观质量需要对抗评估 |
| 全栈应用（复杂） | Three-Agent V1 | Sprint contract确保功能完整 |
| 快速原型 | Claude Code + plan mode | 单人快速，无需复杂harness |
| 工具类/脚本 | Ralph or 单代理 | 不必要用对抗架构 |
| 任务超出模型边界 | 加Evaluator | 需要外部QA |
决策树：
任务类型？
├─ Greenfield + 明确specs → Ralph ($)
├─ Subjective quality 重要 → Three-Agent ($$)
├─ Complex full-stack → Three-Agent V1 ($$$)
└─ Simple/known patterns → Single agent ($)
4.3 成本-质量权衡
| 方案 | 成本 | 质量 | 适合 |
|---|---|---|---|
| Solo agent | $9-20 | 基础功能，可能有核心bug | 探索、概念验证 |
| Ralph | $297 (vs $50k contract) | 90%完成，需要人工finetune | 绿场、编译器 |
| Three-Agent V1 | $200 | 功能完整，AI集成，works | 产品级应用 |
| Three-Agent V2 | $125 | 类似V1但更高效（Opus 4.6） | 追求质量的product |
ROI：Ralph最高（$50k→$297），但Three-Agent质量最可控。
五、实践建议
5.1 如果你想用Ralph
- 从greenfield项目开始（全新仓库）
- 先写specs：与LLM对话生成
specs/*.md - 保持单任务/循环：
fix_plan.md只列一项 - 建立背压：编译器+测试+静态分析
- 接受broken：早上一看broken是正常现象
- 人工判断：git reset还是新prompt？
Ralph适合：
- 编译器、新语言
- 从零构建系统
- 预算敏感但时间充裕
Ralph不适合：
- 现有代码base
- 需要 guaranteemaintainability
- 时间紧迫
5.2 如果你想用Three-Agent Harness
- 写三个明确的system prompts（Planner/Generator/Evaluator）
- 先调优Evaluator：它的质量决定整个循环
- 定义清晰的成功标准（binary，可验证）
- 使用文件作为状态传递（简单可靠）
- 考虑模型能力：Opus 4.6可简化（无sprints）
- 控制成本：Evaluator只在必要时（任务边界）
Key Tuning Loop：
运行harness → 读evaluator日志 → 找与你评价分歧处 → 更新evaluator prompt → 重复
预期：需要数轮这种循环才得到合理evaluator。
5.3 通用最佳实践
从所有模式中提炼：
- Specification First：写代码前先明确spec（Ralph的specs、Harness的contract）
- Testable Success Criteria：不是"好设计"，而是"按钮X在Y条件下做Z"
- Backpressure Mechanism：必须有反馈循环（测试/类型/QA）
- Iterative Tuning：prompt/架构都需要多次迭代
- Accept Broken States：中间状态broken是正常的，相信最终一致性
- Model-Aware Design：架构随模型能力简化（Opus 4.6 vs 4.5）
- Boundary Testing：定期重测假设——"Claude做不到什么？"
- Keep It Simple：每个组件必须证明其价值，否则移除
六、参考资源
6.1 关键概念索引
| 术语 | 定义 | 来源 |
|---|---|---|
| Context Anxiety | 模型感知上下文limit快到时提前结束 | Three-Agent Harness |
| Compaction | 总结早期上下文保留连续性 | Claude Patterns / Three-Agent |
| Context Reset | 清空上下文，fresh agent + handoff artifact | Three-Agent |
| Sprint Contract | Generator-Evaluator预实施协议 | Three-Agent V1 |
| Self-Evaluation Bias | 模型评估自己工作时过度乐观 | Three-Agent |
| Backpressure | 防止错误代码推进的机制（测试/类型） | Ralph / Three-Agent |
| Code Execution Pattern | 用单次tool call执行多步骤，只返回最终结果 | Claude Patterns |
| Spec-First | 先写spec再实现 | Ralph |
| Generator-Evaluator | 对抗性生成-评估循环 | Three-Agent（源自GAN） |
6.2 实现参考
Ralph实现参考：
- https://github.com/repomirrorhq/repomirror （文中提到）
- 作者正在构建的CURSED（未公开）
Three-Agent实现参考：
- Claude Agent SDK: https://platform.claude.com/docs/en/agent-sdk/overview
- Playwright MCP: 用于evaluator测试UI
- 可自行实现（基于Agent SDK）
Claude Code的Plan Mode：
- 产品化的单agent任务分解
- 吸收部分理念但更简化
- 无显式evaluator
七、FAQ
Q: 这些模式现在可用吗？
Claude Patterns：已融入Claude API最佳实践，文档可见。
Ralph：是社区方法，需自行实现（while循环 + Claude Code/API）。
Three-Agent：研究架构，Anthropic未产品化。可用Agent SDK自行实现。
Q: 选择哪个模式？
看场景：
- 绿场、编译器：Ralph（低成本，accept broken）
- 产品级应用：Three-Agent（质量可控）
- 快速原型：Single agent + plan mode
- 主观质量重要：Three-Agent（对抗评估）
Q: Evaluator如何避免被generator"愚弄"？
调优：
- Few-shot grading examples（展示正确评价方式）
- 要求evaluator只看实际运行结果（Playwright交互），不看generator的报告
- 强调批判性思维：prompt加入"be skeptical"、"assume bugs exist"
- 定期审查evaluator决策，修正leniency
Q: 为什么Opus 4.6让sprint不必要？
能力提升：
- 能更仔细plan
- 在agentic任务中持续更久
- 在大codebase中更可靠
- 更好的code review/debugging catch自己的错误
- 长上下文检索大幅改进
结果：模型自己能handle长篇spec，不需要人工分解成sprints。
Q: 三代理的"对抗"会冲突吗？
不会，因为是顺序：
- Generator和Evaluator先协商合同（对齐期望）
- Generator实现
- Evaluator按同意的标准检查
这不是"generator vs evaluator"的对抗，而是"提前对齐 + 客观检查"。
真正的对抗在于：evaluator被调优为严格，generator被迫达到高标准。
Q: 如何评估evaluator的质量？
If evaluator says PASS but you find bugs → evaluator太lenient，需要stricter prompt。
If evaluator says FAIL but you think it's fine → evaluator太strict，需要relax。
目标：evaluator的评价匹配你的标准（经调优后）。
✅ 核心收获
- 简单模式有效：Ralph证明while循环+specs就能build复杂系统
- 对抗提升质量：Generator-Evaluator分离突破自我评估天花板
- Spec/Contract是关键：对齐发生在实施前
- 模型决定架构：Opus 4.6让sprint结构过时
- Evaluator需要调优：开箱即用不佳，需数轮iterations
- 边界在移动：定期问"我能停止做什么？"
- Accept broken：中间状态broken正常，相信最终一致性
- 成本vs质量权衡：Solo $9（broken）→Harness $200（works）→Ralph $297（90%）
- 工程师仍在：需要引导、tuning、人工判断
- LLMs是镜子：输出质量反映prompt技能和迭代投入
📚 延伸阅读
- Anthropic Blog: Building Effective Agents
- Anthropic Blog: Effective Harnesses for Long-Running Agents
- Anthropic Blog: Effective Context Engineering for AI Agents
- Ralph Wiggum: https://ghuntley.com/ralph/
- Claude Agent SDK: https://platform.claude.com/docs/en/agent-sdk/overview
维护者: @you 最后更新: 2026-04-10