解析拉尔夫循环模式：从验证器到工件演化
拉尔夫循环是自主代理的迭代机制，结合了改进循环与进度验证。核心问题在于如何区分执行循环（任务执行）与演化循环（状态演化）。分析揭示了五种模式，它们在验证器、预言机和工件的处理方式上各有不同。
在基础方案中，存在一个循环、对抗上下文腐化的斗争以及外部驱动者——验证器。实现差异包括内部/外部循环、内存清理方法和成功标准类型。
拉尔夫代理基础术语
验证器——在迭代后提供质量信号：通过/失败、错误列表或评分。类似于强化学习中的奖励函数，它定义进度而不自欺欺人。
预言机——关于完成度的终极真相来源。可以是测试、人类、平台或基准；验证器是访问它的机制。
系统提示定义角色、操作和完成格式。可能动态生成。
工件——迭代间持久存在的对象：日志摘要、规则、失败分析所得知识。
模式一：同提示拉尔夫
代理重复使用相同提示，直到输出完成令牌（如“完成”）。外部钩子检查该令牌。示例：Anthropic插件。
内部循环包括类似TDD的方法：代理编写代码、测试、调试直至测试通过。验证通过环境（如代码检查器、构建工具）进行，但在提示中描述，而非作为独立模块。
问题：
- 无上下文清理：单会话导致日志累积。
- 预言机在提示内部，易产生幻觉。
- 依赖提示质量进行测试。
模式二：外部验证器拉尔夫
外部验证器在每次迭代后决定完成度。示例：Vercel拉尔夫与AI SDK工具循环。
内部循环：LLM ↔ 工具（读取文件、写入文件、执行）。之后，verifyCompletion注入反馈。
退出内部循环的逻辑：模型基于提示决定，无需语义令牌。外部循环增加确定性。
优势：生成与验证分离，领域调优（代码、测试、评分）。
模式三：工件演化拉尔夫
工件演化：失败分析生成新规则/知识。预言机在工件中；代理“学习”。
拉尔夫放置“路标”——结构化错误摘要供后续迭代使用。内存被清除，但知识得以保留。
模式四：带外部验证器的工件演化
组合：工件演化 + 外部验证。示例：类Codex系统。
模式五：自我演化代理
完全自主：代理基于自我分析突变提示/工件。最高形式，需要强大预言机。
| 模式 | 循环 | 验证器 | 预言机 | 工件 |
|------|------|-------------|--------|-----------|
| 同提示 | 内部 | 名义上 | 在提示中 | 无 |
| 外部验证器 | 外部 | 独立模块 | 环境/API | 摘要 |
| 工件演化 | 迭代 | 在工件中 | 演化 | 规则/知识 |
| +外部 | 混合 | 外部 | 环境 | 演化中 |
| 自我演化 | 自主 | 自我分析 | 内部 | 突变 |
工件演化：为何有效
上下文腐化通过压缩而非完全重置解决：识别失败模式 → 生成启发式规则。代理“变得更聪明”，专注于根本原因。
- 分析迭代日志。
- 提取错误/模式。
- 创建工件（带规则的JSON）。
- 注入到下一个提示。
- 清理原始日志。
架构师设计清单
- 预言机在何处：模型内部还是外部？
- 执行与演化循环是否分离？
- 如何对抗上下文腐化：摘要还是工件？
- 二进制信号还是丰富反馈？
- 是否可扩展到长时任务？
- 验证器是否单独测试？
关键要点
- 分离循环防止自欺：执行生成，演化验证。
- 工件是扩展关键：持久知识而无上下文膨胀。
- 外部验证器增加可靠性：确定性对抗幻觉。
- 提示中TDD是基线，但复杂任务需要演化。
- 分类法辅助设计：基于领域（编码、数据分析）选择模式。
— Editorial Team
暂无评论。