尧图网页设计 
Mastra 中的 Ralph 命令规划用结构化协作方法构建可执行的自主循环任务【免费下载链接】mastraMastra is the modern TypeScript framework for AI-powered applications and agents.项目地址: https://gitcode.com/GitHub_Trending/ma/mastra导读在 Mastra 仓库中RalphRalph Wiggum Loop是一种让代理反复失败直至成功的自主执行模式代理持续迭代、保留上下文、直到满足完成标准测试通过、构建成功才停止。而 .claude/commands/ralph-plan.md 描述的 Ralph Plan正是为这种模式服务的命令规划器——一个引导 Agent 与用户进行多轮对话、把模糊目标逐步细化成结构化 Ralph 命令的协作流程。读完本文你将掌握 Ralph 命令的四段式结构background / setup / tasks / testing、五步规划流程、九条规划准则以及如何在 Mastra 源码中定位支撑这一模式的完成度评分器与自主循环实现从而独立编写出可复制、可执行、可验证的高质量 Ralph 命令。一、Ralph 命令与 Ralph Plan 的定位1.1 Ralph 命令自主循环的最小可执行单元Ralph 命令本质上是给 Agent 的一份作战计划它把一次自主执行拆解为四个强制区块并以一个 promise 作为完成信号。这与仓库 explorations/ralph-wiggum-loop-integration.md 中定义的 Ralph Wiggum Loop 理念完全一致代理需要持续迭代、保留每次运行的结果、依据清晰的完成标准测试通过、构建成功判断是否结束并受最大迭代次数、超时等安全控制约束。从该集成文档看Ralph 模式的五大关键特征为持久迭代Persistent Iteration代理持续循环执行上下文保留Context Preservation每一轮迭代都能看到此前运行的结果完成标准Completion Criteria有明确的成功度量测试通过、构建成功安全控制Safety Controls最大迭代次数、超时失败即数据Failure as Data每次失败的尝试都会反馈给下一轮迭代。Ralph 命令的tasks区块正是完成标准的来源testing区块则是完成标准的验证手段——二者共同构成自主循环的退出条件。1.2 Ralph Plan规划器而非执行器Ralph Plan 是一个规划助手planning assistant。它的目标不是替你执行任务而是通过提问、澄清、逐步细化与你共同产出一份重点明确、可落地的 Ralph 命令。因此它天然是对话式、迭代式的先理解目标再逐段填充命令结构最终给出完整命令供直接复制。在 Claude Code 的命令体系里这类文件位于.claude/commands/目录被 slash command 机制加载为 Agent 的指令让 Agent 在收到用户输入后扮演规划助手角色。二、Ralph 命令的四段式结构一份完整的 Ralph 命令由以下区块构成这是 Ralph Plan 输出结果的唯一合法形态background Context about the task, the users expertise level, and overall goal. /background setup Numbered steps to prepare the environment before starting work. Includes: activating relevant skills, exploring current state, research needed. /setup tasks Numbered list of specific, actionable tasks to complete. Tasks should be concrete and verifiable. /tasks testing Steps to verify the work is complete and working correctly. Includes: build commands, how to run/test, validation steps. /testing Output promiseCOMPLETE/promise when all tasks are done.各区块职责如下区块职责关键要求background描述任务背景、用户专业水平、总体目标让执行 Agent 了解为什么做与以什么身份做setup编号步骤准备开始工作前的环境激活相关技能、探索当前状态、完成必要研究tasks编号的具体可执行任务列表任务必须具体、可验证testing验证工作完成且正确的步骤包含构建命令、运行/测试方式、校验步骤promiseCOMPLETE/promise全部任务完成后的结束信号输出该标记表示循环可以终止注意原文档特意要求输出格式中使用单引号而避免双引号与反引号因为当命令被复制执行时这些字符会干扰格式化。这一细节在输出完整命令时务必遵守。三、五步规划流程从目标到命令Ralph Plan 将规划过程拆成五个明确步骤每一步都对应命令结构中的一个或多个区块。Step 1理解目标Understand the Goal规划器需要向用户确认三件事高层目标是什么What is the high-level goal?涉及代码库的哪个部分What area of the codebase does this involve?是否存在约束或要求Are there any constraints or requirements?。这一步产出是后续所有区块的事实基础。Step 2定义背景Define Background帮助用户确定执行 Agent 应假定的专业身份/人设What expertise/persona should the agent assume?用一句话概括的核心目标What is the core objective in one sentence?。这直接对应background区块。仓库中的示例 Agent 人设可以参考 explorations/ralph-wiggum-loop-prototype.ts 注释中的migrationAgent它被定义为测试迁移专家指令中明确列出分析现有测试结构 → 识别需要改动的内容 → 执行修改 → 验证改动正确正是background应该达到的详细程度。Step 3规划 Setup 步骤Plan Setup Steps确定需要哪些技能或工具What skills or tools are needed?需要先做哪些探索/研究What exploration/research is required first?需要哪些环境准备What environment setup is needed?。这对应setup区块。原文档第七条准则也强调Setup 步骤应包含研究/探索以理解现有代码比如用户说像 tools tab 一样加一个 tab时执行者应先阅读 tools 的实现来理解模式、文件结构和约定。Step 4拆解任务Break Down Tasks与用户协作把目标拆成具体的、编号的、可验证的任务按依赖关系逻辑排序先做被依赖的部分在有助于理解的地方附带实现细节。这对应tasks区块。原文档给出的好例子与坏例子对比非常直观坏Improve the UI过于模糊好Create a /processors endpoint that lists processors, mimicking the /tools endpoint具体、可验证、参考了现有模式。Step 5定义测试Define Testing确定如何构建/编译改动How to build/compile changes如何运行并验证工作How to run and verify the work成功看起来是什么样What success looks like。这对应testing区块。测试是 Ralph 循环的完成标准载体——在 Mastra 的完成度评分机制中一个典型的testsScorer就是通过执行npm test来判断是否完成的详见下文第六节。四、九条规划准则Ralph Plan 明确要求规划过程遵循九条准则这是保证命令质量的核心约束保持探究精神Be Inquisitive主动追问实现细节、边界情况和假设。不要接受模糊描述一直深挖到清晰为止。识别缺口Identify Gaps主动指出缺失、模糊或后续会出问题的内容。原文档给出的三个示例追问你说要创建一个 endpoint但还没指定请求/响应格式——应该是什么样这个任务依赖对 X 的理解但没有对应的研究步骤——要不要加一个如果处理器抛错怎么办UI 应该处理这种情况吗研究代码库Research the Codebase不要只问用户——主动探索代码库填补知识空白。例如用户提到添加一个像 tools tab 一样的 tab就去搜索并阅读 tools 的实现从而在任务中给出具体的文件路径和函数名、识别需要遵循的现有模式、发现需要连带修改的依赖代码、提供具体的实现细节而不是模糊指令。保持迭代Be Iterative不要立即产出完整命令而是提问、讨论选项、逐步精化。保持具体Be Specific模糊任务导致混乱帮助用户把任务具体化。包含上下文Include ContextSetup 步骤应包含理解现有代码所需的研究/探索。参考现有模式Reference Existing Patterns尽可能指出可遵循的既有相似实现。考虑依赖Consider Dependencies任务排序要让依赖先完成。控制范围Keep Scope FocusedRalph 命令应有清晰、可达的范围范围过大时建议拆成多条 Ralph 命令。五、示例对话流程以 playground 新功能为例原文档给出了一个完整的交互示例骨架展示了规划器如何先提问、再起草、逐段确认用户I want to add a new feature to the playground我想给 playground 加一个新功能助手Lets plan this out. Can you tell me more about:你要加什么功能它影响 playground 的哪一部分有没有我应该参考的相似既有功能用户提供细节助手Got it. Let me draft the background section first:background [Draft background based on discussion] /backgroundDoes this capture the goal correctly? Should I adjust anything?继续对每个区块迭代……这个流程的核心是每起草一个区块就停下来与用户确认而不是一次性交出全部内容。仓库中 explorations/agent-network-vs-ralph-wiggum.md 也印证了这种先理解、后结构化的协作思路在 Ralph 相关探索中的地位。六、Ralph 命令背后的运行机制完成度评分器规划出的testing区块最终会落到 Mastra Agent Network 的**完成度评分completion scoring**机制上。仓库 explorations/ralph-wiggum-loop-integration.md 明确指出完成度检查其实就是MastraScorer——返回 0 表示未完成返回 1 表示完成从而把离线评测evals与运行时循环控制统一到同一个原语上。6.1 CompletionConfig 的真实定义在 packages/core/src/loop/network/validation.ts 中CompletionConfig接口与 Ralph Plan 文档描述的结构完全对应scorers?: MastraScorer[]要运行的评分器返回 0 或 1strategy?: all | anyall表示全部通过才完成默认any表示至少一个通过即完成timeout?: number所有评分器的最大耗时毫秒源码中的默认值为60000010 分钟实现中通过setTimeout兜底防止某个评分器永不返回而卡住循环parallel?: boolean是否并行运行评分器源码默认true且并行模式下采用 Promise 竞速race方式丢弃超时的迟到结果onComplete?: (results: CompletionRunResult) void评分结束后的回调。CompletionRunResult返回{ complete: boolean, completionReason?: string, scorers: ScorerResult[] }其中ScorerResult包含score、passed、reason、scorerId、scorerName、duration等字段。特别注意评分器只回答问题这事做完了吗它不生成最终结果——最终结果来自 primitiveagent/workflow/tool的输出。6.2 CompletionContext评分器可访问的完整运行状态源码中CompletionContext通过run.input传入评分器提供了丰富上下文这与 Ralph Plan 强调的具体、可验证一脉相承iteration当前迭代次数从 1 开始maxIterations允许的最大迭代次数messages会话线程中的全部消息MastraDBMessage[]originalTask发起本次网络运行的原始任务/提示词selectedPrimitive本轮选中的 primitive{ id, type: agent | workflow | tool | none }primitivePrompt与primitiveResult发送给 primitive 的输入及其结果networkName、runId、threadId、resourceId运行标识与记忆定位信息customContext请求携带的自定义上下文。6.3 两类评分器的写法代码型评分器适合测试通过构建成功这类硬性检查import { createScorer } from mastra/core/evals; import { execSync } from child_process; const testsScorer createScorer({ id: tests, description: Run unit tests to verify code works, }).generateScore(async ({ run }) { try { execSync(npm test, { stdio: pipe }); return 1; // 测试通过 } catch { return 0; // 测试失败 } });LLM 型评分器适合需要语义判断的场景可叠加judge模型const taskCompleteScorer createScorer({ id: task-complete, description: LLM evaluates if task is complete, judge: { model: openai(gpt-4o-mini), instructions: You evaluate task completion., }, }).generateScore({ description: Evaluate if the task is complete, createPrompt: ({ run }) { const ctx run.input; // CompletionContext return Original task: ${ctx.originalTask} Latest result: ${ctx.primitiveResult} Is this task complete? Return 1 if yes, 0 if no. ; }, });两类评分器可自由混用配合strategy: all或any组合成复杂的完成判定。这与 Ralph Plan 中任务要具体可验证的准则互为表里——testing里写的每条验证步骤最终都会被翻译成这样一个或一组评分器。6.4 自主循环的执行原型仓库中的 explorations/ralph-wiggum-loop-prototype.ts 是这一模式的完整原型实现它展示了 Ralph 循环与 Mastra 既有原语Agent Workflow如何结合CompletionChecker接口check: () Promise{ success, message?, data? }是评分器的早期形态提供现成的检查器工厂testsPassing默认npm test超时 300s、buildSucceeds默认npm run build超时 600s、lintClean默认npm run lint超时 120s、outputContains检查输出是否含特定字符串/正则、allCheckersPassing全部通过才算完成AutonomousLoopConfig给出了循环的安全控制参数maxIterations最大迭代次数、maxTokenstoken 上限、iterationDelay迭代间隔、contextWindow保留多少轮历史结果、onIteration/onIterationStart每轮回调executeAutonomousLoop实现主循环每轮把前contextWindow轮的成败与输出摘要注入下一轮提示词失败的尝试作为数据反馈给 Agent再执行完成检查直到成功或达到maxIterations。这套参数与 Ralph Plan 命令结构高度同构tasks决定每轮做什么testing提供CompletionCheckermaxIterations等安全参数则防止循环失控。6.5 验证桥接LLM 判定与程序化验证互补explorations/network-validation-bridge.ts 进一步演示了如何把 Ralph 风格的程序化验证接入 Agent Network 的既有循环其mode概念值得在规划testing时参考verifyLLM 判定完成且程序化验证通过才算完成override只认程序化验证忽略 LLM 判定llm-fallback优先尝试程序化验证未配置检查项时退回 LLM。桥接文件同样提供了testsPass、buildSucceeds、lintPasses、typeChecksnpx tsc --noEmit等验证工厂并支持strategy: all | any、timeout、parallel配置——与 6.1 节的CompletionConfig语义一致。七、输出格式与交付当规划最终定稿后Ralph Plan 必须把完整的 Ralph 命令放在一个可直接复制的代码块中呈现给用户background ... /background setup ... /setup tasks ... /tasks testing ... /testing Output promiseCOMPLETE/promise when all tasks are done.交付时必须遵守两条硬性规则避免双引号与反引号它们会干扰命令复制执行时的格式化改用单引号或干脆改写以避免引号以promiseCOMPLETE/promise收尾这是自主循环的终止信号缺少它循环将无法按预期结束。此外整个规划会话由规划器主动发起——Ralph Plan 的启动方式就是先问用户你想完成什么Begin by asking the user what they want to accomplish然后倾听目标、提出澄清问题、逐段协作构建命令。八、实战自查清单把 Ralph Plan 的方法论固化成一份可复用的自查清单规划任何命令时逐项核对背景完整吗background是否写明了任务背景、Agent 人设、单句核心目标环境就绪吗setup是否包含技能激活、现状探索、必要研究三个层面的步骤任务可验证吗每个tasks条目是否具体到可以判定对错是否按依赖排序测试可执行吗testing是否给出了明确的构建命令、运行方式和成功标准如npm test、npm run build、npx tsc --noEmit范围可控吗任务范围是否过大是否需要拆分为多条 Ralph 命令语法干净吗命令中是否残留双引号或反引号终止明确吗是否以promiseCOMPLETE/promise结尾按照这份清单生成的 Ralph 命令可以直接对接 Mastra Agent Network 的完成度评分机制packages/core/src/loop/network/validation.ts或自主循环原型explorations/ralph-wiggum-loop-prototype.ts把反复失败直至成功的自主执行从理念落到可运行、可观测的工程实践。【免费下载链接】mastraMastra is the modern TypeScript framework for AI-powered applications and agents.项目地址: https://gitcode.com/GitHub_Trending/ma/mastra创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Mastra 中的 Ralph 命令规划：用结构化协作方法构建可执行的自主循环任务
Mastra 中的 Ralph 命令规划用结构化协作方法构建可执行的自主循环任务【免费下载链接】mastraMastra is the modern TypeScript framework for AI-powered applications and agents.项目地址: https://gitcode.com/GitHub_Trending/ma/mastra导读在 Mastra 仓库中RalphRalph Wiggum Loop是一种让代理反复失败直至成功的自主执行模式代理持续迭代、保留上下文、直到满足完成标准测试通过、构建成功才停止。而 .claude/commands/ralph-plan.md 描述的 Ralph Plan正是为这种模式服务的命令规划器——一个引导 Agent 与用户进行多轮对话、把模糊目标逐步细化成结构化 Ralph 命令的协作流程。读完本文你将掌握 Ralph 命令的四段式结构background / setup / tasks / testing、五步规划流程、九条规划准则以及如何在 Mastra 源码中定位支撑这一模式的完成度评分器与自主循环实现从而独立编写出可复制、可执行、可验证的高质量 Ralph 命令。一、Ralph 命令与 Ralph Plan 的定位1.1 Ralph 命令自主循环的最小可执行单元Ralph 命令本质上是给 Agent 的一份作战计划它把一次自主执行拆解为四个强制区块并以一个 promise 作为完成信号。这与仓库 explorations/ralph-wiggum-loop-integration.md 中定义的 Ralph Wiggum Loop 理念完全一致代理需要持续迭代、保留每次运行的结果、依据清晰的完成标准测试通过、构建成功判断是否结束并受最大迭代次数、超时等安全控制约束。从该集成文档看Ralph 模式的五大关键特征为持久迭代Persistent Iteration代理持续循环执行上下文保留Context Preservation每一轮迭代都能看到此前运行的结果完成标准Completion Criteria有明确的成功度量测试通过、构建成功安全控制Safety Controls最大迭代次数、超时失败即数据Failure as Data每次失败的尝试都会反馈给下一轮迭代。Ralph 命令的tasks区块正是完成标准的来源testing区块则是完成标准的验证手段——二者共同构成自主循环的退出条件。1.2 Ralph Plan规划器而非执行器Ralph Plan 是一个规划助手planning assistant。它的目标不是替你执行任务而是通过提问、澄清、逐步细化与你共同产出一份重点明确、可落地的 Ralph 命令。因此它天然是对话式、迭代式的先理解目标再逐段填充命令结构最终给出完整命令供直接复制。在 Claude Code 的命令体系里这类文件位于.claude/commands/目录被 slash command 机制加载为 Agent 的指令让 Agent 在收到用户输入后扮演规划助手角色。二、Ralph 命令的四段式结构一份完整的 Ralph 命令由以下区块构成这是 Ralph Plan 输出结果的唯一合法形态background Context about the task, the users expertise level, and overall goal. /background setup Numbered steps to prepare the environment before starting work. Includes: activating relevant skills, exploring current state, research needed. /setup tasks Numbered list of specific, actionable tasks to complete. Tasks should be concrete and verifiable. /tasks testing Steps to verify the work is complete and working correctly. Includes: build commands, how to run/test, validation steps. /testing Output promiseCOMPLETE/promise when all tasks are done.各区块职责如下区块职责关键要求background描述任务背景、用户专业水平、总体目标让执行 Agent 了解为什么做与以什么身份做setup编号步骤准备开始工作前的环境激活相关技能、探索当前状态、完成必要研究tasks编号的具体可执行任务列表任务必须具体、可验证testing验证工作完成且正确的步骤包含构建命令、运行/测试方式、校验步骤promiseCOMPLETE/promise全部任务完成后的结束信号输出该标记表示循环可以终止注意原文档特意要求输出格式中使用单引号而避免双引号与反引号因为当命令被复制执行时这些字符会干扰格式化。这一细节在输出完整命令时务必遵守。三、五步规划流程从目标到命令Ralph Plan 将规划过程拆成五个明确步骤每一步都对应命令结构中的一个或多个区块。Step 1理解目标Understand the Goal规划器需要向用户确认三件事高层目标是什么What is the high-level goal?涉及代码库的哪个部分What area of the codebase does this involve?是否存在约束或要求Are there any constraints or requirements?。这一步产出是后续所有区块的事实基础。Step 2定义背景Define Background帮助用户确定执行 Agent 应假定的专业身份/人设What expertise/persona should the agent assume?用一句话概括的核心目标What is the core objective in one sentence?。这直接对应background区块。仓库中的示例 Agent 人设可以参考 explorations/ralph-wiggum-loop-prototype.ts 注释中的migrationAgent它被定义为测试迁移专家指令中明确列出分析现有测试结构 → 识别需要改动的内容 → 执行修改 → 验证改动正确正是background应该达到的详细程度。Step 3规划 Setup 步骤Plan Setup Steps确定需要哪些技能或工具What skills or tools are needed?需要先做哪些探索/研究What exploration/research is required first?需要哪些环境准备What environment setup is needed?。这对应setup区块。原文档第七条准则也强调Setup 步骤应包含研究/探索以理解现有代码比如用户说像 tools tab 一样加一个 tab时执行者应先阅读 tools 的实现来理解模式、文件结构和约定。Step 4拆解任务Break Down Tasks与用户协作把目标拆成具体的、编号的、可验证的任务按依赖关系逻辑排序先做被依赖的部分在有助于理解的地方附带实现细节。这对应tasks区块。原文档给出的好例子与坏例子对比非常直观坏Improve the UI过于模糊好Create a /processors endpoint that lists processors, mimicking the /tools endpoint具体、可验证、参考了现有模式。Step 5定义测试Define Testing确定如何构建/编译改动How to build/compile changes如何运行并验证工作How to run and verify the work成功看起来是什么样What success looks like。这对应testing区块。测试是 Ralph 循环的完成标准载体——在 Mastra 的完成度评分机制中一个典型的testsScorer就是通过执行npm test来判断是否完成的详见下文第六节。四、九条规划准则Ralph Plan 明确要求规划过程遵循九条准则这是保证命令质量的核心约束保持探究精神Be Inquisitive主动追问实现细节、边界情况和假设。不要接受模糊描述一直深挖到清晰为止。识别缺口Identify Gaps主动指出缺失、模糊或后续会出问题的内容。原文档给出的三个示例追问你说要创建一个 endpoint但还没指定请求/响应格式——应该是什么样这个任务依赖对 X 的理解但没有对应的研究步骤——要不要加一个如果处理器抛错怎么办UI 应该处理这种情况吗研究代码库Research the Codebase不要只问用户——主动探索代码库填补知识空白。例如用户提到添加一个像 tools tab 一样的 tab就去搜索并阅读 tools 的实现从而在任务中给出具体的文件路径和函数名、识别需要遵循的现有模式、发现需要连带修改的依赖代码、提供具体的实现细节而不是模糊指令。保持迭代Be Iterative不要立即产出完整命令而是提问、讨论选项、逐步精化。保持具体Be Specific模糊任务导致混乱帮助用户把任务具体化。包含上下文Include ContextSetup 步骤应包含理解现有代码所需的研究/探索。参考现有模式Reference Existing Patterns尽可能指出可遵循的既有相似实现。考虑依赖Consider Dependencies任务排序要让依赖先完成。控制范围Keep Scope FocusedRalph 命令应有清晰、可达的范围范围过大时建议拆成多条 Ralph 命令。五、示例对话流程以 playground 新功能为例原文档给出了一个完整的交互示例骨架展示了规划器如何先提问、再起草、逐段确认用户I want to add a new feature to the playground我想给 playground 加一个新功能助手Lets plan this out. Can you tell me more about:你要加什么功能它影响 playground 的哪一部分有没有我应该参考的相似既有功能用户提供细节助手Got it. Let me draft the background section first:background [Draft background based on discussion] /backgroundDoes this capture the goal correctly? Should I adjust anything?继续对每个区块迭代……这个流程的核心是每起草一个区块就停下来与用户确认而不是一次性交出全部内容。仓库中 explorations/agent-network-vs-ralph-wiggum.md 也印证了这种先理解、后结构化的协作思路在 Ralph 相关探索中的地位。六、Ralph 命令背后的运行机制完成度评分器规划出的testing区块最终会落到 Mastra Agent Network 的**完成度评分completion scoring**机制上。仓库 explorations/ralph-wiggum-loop-integration.md 明确指出完成度检查其实就是MastraScorer——返回 0 表示未完成返回 1 表示完成从而把离线评测evals与运行时循环控制统一到同一个原语上。6.1 CompletionConfig 的真实定义在 packages/core/src/loop/network/validation.ts 中CompletionConfig接口与 Ralph Plan 文档描述的结构完全对应scorers?: MastraScorer[]要运行的评分器返回 0 或 1strategy?: all | anyall表示全部通过才完成默认any表示至少一个通过即完成timeout?: number所有评分器的最大耗时毫秒源码中的默认值为60000010 分钟实现中通过setTimeout兜底防止某个评分器永不返回而卡住循环parallel?: boolean是否并行运行评分器源码默认true且并行模式下采用 Promise 竞速race方式丢弃超时的迟到结果onComplete?: (results: CompletionRunResult) void评分结束后的回调。CompletionRunResult返回{ complete: boolean, completionReason?: string, scorers: ScorerResult[] }其中ScorerResult包含score、passed、reason、scorerId、scorerName、duration等字段。特别注意评分器只回答问题这事做完了吗它不生成最终结果——最终结果来自 primitiveagent/workflow/tool的输出。6.2 CompletionContext评分器可访问的完整运行状态源码中CompletionContext通过run.input传入评分器提供了丰富上下文这与 Ralph Plan 强调的具体、可验证一脉相承iteration当前迭代次数从 1 开始maxIterations允许的最大迭代次数messages会话线程中的全部消息MastraDBMessage[]originalTask发起本次网络运行的原始任务/提示词selectedPrimitive本轮选中的 primitive{ id, type: agent | workflow | tool | none }primitivePrompt与primitiveResult发送给 primitive 的输入及其结果networkName、runId、threadId、resourceId运行标识与记忆定位信息customContext请求携带的自定义上下文。6.3 两类评分器的写法代码型评分器适合测试通过构建成功这类硬性检查import { createScorer } from mastra/core/evals; import { execSync } from child_process; const testsScorer createScorer({ id: tests, description: Run unit tests to verify code works, }).generateScore(async ({ run }) { try { execSync(npm test, { stdio: pipe }); return 1; // 测试通过 } catch { return 0; // 测试失败 } });LLM 型评分器适合需要语义判断的场景可叠加judge模型const taskCompleteScorer createScorer({ id: task-complete, description: LLM evaluates if task is complete, judge: { model: openai(gpt-4o-mini), instructions: You evaluate task completion., }, }).generateScore({ description: Evaluate if the task is complete, createPrompt: ({ run }) { const ctx run.input; // CompletionContext return Original task: ${ctx.originalTask} Latest result: ${ctx.primitiveResult} Is this task complete? Return 1 if yes, 0 if no. ; }, });两类评分器可自由混用配合strategy: all或any组合成复杂的完成判定。这与 Ralph Plan 中任务要具体可验证的准则互为表里——testing里写的每条验证步骤最终都会被翻译成这样一个或一组评分器。6.4 自主循环的执行原型仓库中的 explorations/ralph-wiggum-loop-prototype.ts 是这一模式的完整原型实现它展示了 Ralph 循环与 Mastra 既有原语Agent Workflow如何结合CompletionChecker接口check: () Promise{ success, message?, data? }是评分器的早期形态提供现成的检查器工厂testsPassing默认npm test超时 300s、buildSucceeds默认npm run build超时 600s、lintClean默认npm run lint超时 120s、outputContains检查输出是否含特定字符串/正则、allCheckersPassing全部通过才算完成AutonomousLoopConfig给出了循环的安全控制参数maxIterations最大迭代次数、maxTokenstoken 上限、iterationDelay迭代间隔、contextWindow保留多少轮历史结果、onIteration/onIterationStart每轮回调executeAutonomousLoop实现主循环每轮把前contextWindow轮的成败与输出摘要注入下一轮提示词失败的尝试作为数据反馈给 Agent再执行完成检查直到成功或达到maxIterations。这套参数与 Ralph Plan 命令结构高度同构tasks决定每轮做什么testing提供CompletionCheckermaxIterations等安全参数则防止循环失控。6.5 验证桥接LLM 判定与程序化验证互补explorations/network-validation-bridge.ts 进一步演示了如何把 Ralph 风格的程序化验证接入 Agent Network 的既有循环其mode概念值得在规划testing时参考verifyLLM 判定完成且程序化验证通过才算完成override只认程序化验证忽略 LLM 判定llm-fallback优先尝试程序化验证未配置检查项时退回 LLM。桥接文件同样提供了testsPass、buildSucceeds、lintPasses、typeChecksnpx tsc --noEmit等验证工厂并支持strategy: all | any、timeout、parallel配置——与 6.1 节的CompletionConfig语义一致。七、输出格式与交付当规划最终定稿后Ralph Plan 必须把完整的 Ralph 命令放在一个可直接复制的代码块中呈现给用户background ... /background setup ... /setup tasks ... /tasks testing ... /testing Output promiseCOMPLETE/promise when all tasks are done.交付时必须遵守两条硬性规则避免双引号与反引号它们会干扰命令复制执行时的格式化改用单引号或干脆改写以避免引号以promiseCOMPLETE/promise收尾这是自主循环的终止信号缺少它循环将无法按预期结束。此外整个规划会话由规划器主动发起——Ralph Plan 的启动方式就是先问用户你想完成什么Begin by asking the user what they want to accomplish然后倾听目标、提出澄清问题、逐段协作构建命令。八、实战自查清单把 Ralph Plan 的方法论固化成一份可复用的自查清单规划任何命令时逐项核对背景完整吗background是否写明了任务背景、Agent 人设、单句核心目标环境就绪吗setup是否包含技能激活、现状探索、必要研究三个层面的步骤任务可验证吗每个tasks条目是否具体到可以判定对错是否按依赖排序测试可执行吗testing是否给出了明确的构建命令、运行方式和成功标准如npm test、npm run build、npx tsc --noEmit范围可控吗任务范围是否过大是否需要拆分为多条 Ralph 命令语法干净吗命令中是否残留双引号或反引号终止明确吗是否以promiseCOMPLETE/promise结尾按照这份清单生成的 Ralph 命令可以直接对接 Mastra Agent Network 的完成度评分机制packages/core/src/loop/network/validation.ts或自主循环原型explorations/ralph-wiggum-loop-prototype.ts把反复失败直至成功的自主执行从理念落到可运行、可观测的工程实践。【免费下载链接】mastraMastra is the modern TypeScript framework for AI-powered applications and agents.项目地址: https://gitcode.com/GitHub_Trending/ma/mastra创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考