使用说明
拉尔夫MCP
平行拉尔夫环:PRD→ ralph_start → 继续聊天 → 合并。在具有自动质量门和合并的隔离工作树中同时运行多个PRD。
基于 杰弗里·亨特利的拉尔夫模式.
配套项目:使用 Ralph CLI 当你想要一个独立的终端管理器时,启动重启、租赁/修订恢复和一个专用的集成工作树。需要时使用Ralph MCP ralph_start, ralph_status,以及可从MCP原生Claude Code工作流中获得的Ralph Runner。
拉尔夫循环(2步)
Step 1: Generate PRD
User: "Create a PRD for user authentication"
Claude: [Generates tasks/prd-auth.md]
Step 2: Execute
User: "Start" or "Execute this PRD"
Claude: ralph_start → Task Agent handles everything automatically
就这样 Ralph MCP自动处理:分支创建、工作树隔离、代码实现、质量检查、提交、合并和文档同步。
为什么选择Ralph MCP?
| 没有拉尔夫 | 有拉尔夫 |
|---|---|
| 一次一个功能 | 并行多个功能 |
| 手动PRD编写 | 克劳德为您生成PRD |
| 手动git分支管理 | 自动工作树隔离 |
| 重启时丢失进度 | 持久状态(JSON) |
| 手动合并协调 | 自动合并并解决冲突 |
| 无法查看进度 | 实时状态跟踪 |
| 等待时被阻止 | 继续聊天 当代理人工作时 |
对原版Ralph的改进
拉尔夫MCP扩展 snarktank/ralph 在保持其核心优势的同时,实现生产级自动化。
新增功能
| 特写 | 原版Ralph | Ralph MCP |
|---|---|---|
| 代理生命周期 | 每个用户故事一个进程 | 每个PRD一个长期代理 |
| 执行模型 | 手动脚本调用 | 后台运行器+MCP集成 |
| 并行PRD | 仅顺序 | 同时有5+个PRD |
| 依赖管理 | 手动协调 | 合并依赖关系后自动触发 |
| 停滞检测 | 无 | 自动检测到卡住的代理,标记为失败 |
| 代理内存 | 无 | 进度日志记录了各个故事中的学习情况 |
| 合并协调 | 手动 | 具有冲突解决功能的串行合并队列 |
| 通知 | 无 | 完成时Windows吐司 |
| Claude代码集成 | 需要包装脚本 | 本机MCP工具(ralph_start, ralph_status等等) |
保存了什么
Ralph MCP保持了久经考验的基础:
- 珠三角驱动发展 -带有用户故事和验收标准的结构化需求
- 迭代执行 -一次一个用户故事,有质量关卡
- Git工作树隔离 -并行特征之间无冲突
- 质量门 -每次提交前进行类型检查、lint、build
- 自动合并 -当所有故事都通过时,实现免提集成
关键架构更改
- 长寿特工:一个代理完成PRD中的所有用户故事(不为每个故事生成新流程)
- 跑步者自动化:后台进程管理执行生命周期,不运行手动脚本
- MCP本地:通过MCP协议与Claude Code直接集成
- 状态持久性:基于JSON的状态在重启后仍然有效,并支持并行执行跟踪
特性
- 两步工作流程 -只需创建PRD并运行
ralph_start,其他一切都是自动的 - 并行执行 -与长期使用的Ralph代理同时运行5+个PRD
- CLI第一代理运行时 -默认为CLI执行,SDK回退仍然可用
- Git工作树隔离 -每个PRD都在自己的工作树中运行,零冲突
- 依赖管理 -PRD可以依赖于其他PRD;依赖项只有在依赖项PRD集成到同一项目中后才会启动
- 停滞检测 -自动检测卡住的代理(无进度、重复错误)并标记为失败
- 代理内存 -持久的“进度日志”从用户故事中的错误中学习
代理支持
Ralph MCP将代理执行分为两个维度:
agent.backend:cli(默认)或sdkagent.provider:codex(默认)或claude
默认情况下,运行者现在更喜欢CLI启动器,当CLI启动失败时,可以回退到SDK后端。
Codex CLI(默认)
通过Codex CLI使用GPT-5.3 Codex执行代理。
要求:
- 已安装Codex CLI
- LiteLLM代理正在运行
localhost:4000 - 环境变量:
export OPENAI_BASE_URL=http://localhost:4000/v1 export OPENAI_API_KEY=<your-litellm-master-key>
配置:
# .ralph.yaml
agent:
backend: cli
provider: codex
coAuthor: "GPT-5.3 Codex <noreply@openai.com>"
codex:
# Path to Codex CLI (default: "codex")
codexPath: "codex"
# Approval policy for command execution
# Options: never, on-request, on-failure, untrusted
approvalPolicy: on-request
# Sandbox mode for filesystem access
# Options: read-only, workspace-write, danger-full-access
sandboxMode: workspace-write
# Execution level (L1=Executor, L2=Builder, L3=Autonomous, L4=Specialist)
level: L2
# Max auto-recovery attempts when stalled
maxRecoveryAttempts: 2
# Minutes of inactivity before detecting stall
stallTimeoutMinutes: 5
Claude 命令行界面
当您需要CLI后端但更喜欢Claude作为提供者时,可以直接使用Claude Code CLI。
要求:
- 已安装Claude Code CLI
- LiteLLM代理正在运行
localhost:4000(可选,适用于自定义型号)
配置:
# .ralph.yaml
agent:
backend: cli
provider: claude
coAuthor: "Claude Opus 4.6 <noreply@anthropic.com>"
claude:
claudePath: claude
additionalFlags: []
SDK后端(回退/覆盖)
如果您更喜欢进程内SDK路径,或者希望在CLI启动器不可用时有一个稳定的回退,请切换 agent.backend 到 sdk.
agent:
backend: sdk
provider: claude # or codex
比较
| 尺寸 | 克劳德 | 法典 |
|---|---|---|
| CLI命令 | claude |
codex |
| SDK后端 | 支持 | 支持 |
| 审批政策 | 跳过权限/CLI标志 | 可配置 |
| 沙盒模式 | CLI管理 | 可配置 |
| 最适合 | Claude Code工作流 | Codex首次自动化 |
切换代理
要切换提供商或后端,请更新您的 .ralph.yaml:
# Use Claude CLI
agent:
backend: cli
provider: claude
# Use Codex CLI (default)
agent:
backend: cli
provider: codex
# Use Claude SDK instead
agent:
backend: sdk
provider: claude
然后重新启动Ralph MCP服务器或运行 ralph_doctor 以验证配置。
为什么是长寿特工?
Ralph MCP的长寿命代理设计不同于原始的Ralph模式。本节解释了这两种方法背后的推理。
拉尔夫哲学
Geoffrey Huntley在设计Ralph时考虑到了一个明确的约束: 上下文窗口限制 (当时约17万个代币)。他的哲学:
- 每个代理进程一个用户故事 -每个故事都有一个新的主体,具有集中的背景
- 避免多代理复杂性 -无代理间通信或协调开销
- 快速反馈回路 -无上下文膨胀的快速迭代
- 简单的编排 -基于脚本的执行,易于理解和调试
这种设计对于2024年的限制是最优的:有限的上下文窗口意味着做好一件事比试图一次完成所有事情要好。
为什么Ralph MCP改变了这一点
Ralph MCP采用长期代理(每个PRD一个代理),因为约束已经演变:
1.更大的上下文窗口(20万+令牌)
- 现代Claude模型可以处理具有多个用户故事的整个PRD
- 上下文窗口不再是多层执行的瓶颈
2.学习积累
- 进度日志记录了同一PRD内用户故事的学习情况
- 后来的故事受益于早期故事中的发现
- 示例:“US-001发现
pnpm db:migrate:dev必须在模式更改后运行”→US-003预先知道这一点
3.降低启动开销
- 为每个故事生成一个新的代理进程会增加延迟(模型加载、上下文注入)
- 长期代理在PRD的所有故事中摊销这一成本
4.上下文连续性
- Agent记住以前故事中的架构决策
- 无需为每个故事重新解释项目结构或惯例
- 自然对话流程:“继续使用US-002中的相同方法”
权衡比较
| Aspect | 原版Ralph | Ralph MCP |
|---|---|---|
| 上下文窗口 | 17万个代币 | 20多万个代币 |
| 代理生命周期 | 短(每个用户故事) | 长(每个PRD) |
| 学习积累 | 无(每个故事都有新的开始) | 进度日志在故事中持续存在 |
| 启动开销 | 高(每个故事) | 低(每个PRD一次) |
| 上下文连续性 | 无(无状态) | 已满(代理记得以前的故事) |
| 复杂性 | 简单(基于脚本) | 中等(后台运行+状态管理) |
| 最适合 | 小上下文窗口,简单PRD | 大上下文窗口,多层PRD |
何时使用每种方法
原始拉尔夫 在以下情况下更好:
- 上下文窗口有限(<20万个令牌)
- PRD很简单(1-3个用户故事)
- 您更喜欢基于脚本的简单性,而不是自动化
- 每个用户故事都是独立的,没有共享的学习内容
拉尔夫MCP 在以下情况下更好:
- 上下文窗口很大(200k+令牌)
- PRD很复杂(5+用户故事)
- 您希望并行执行多个PRD
- 后来的故事受益于早期的发现
- 您需要具有状态持久性的后台执行
设计理念
这两种方法都遵循相同的核心原则: 具有质量门的结构化迭代执行不同之处在于他们如何管理代理生命周期:
- 原始拉尔夫:“做好一件事,然后退出”(最适合2024年的限制)
- 拉尔夫MCP:“在一次会议中完成所有相关工作”(最适合2025年以上的能力)
- Ralph CLI:“将任务队列和终结器保持在聊天会话之外”(最适合终端优先的自动化和始终在线的管理员)
Ralph MCP并没有取代原始模式,而是将其扩展到上下文窗口和自动化基础设施支持寿命更长的代理的环境中。
- 上下文注入 -将项目规则(CLAUDE.md)注入代理上下文
- 汽车质量门 -每次提交前进行类型检查、lint、build
- 自动合并 -当所有用户故事通过时合并到主
- 合并队列 -串行合并队列以避免冲突
- 通知 -PRD完成时的Windows吐司
进度日志(代理内存)
拉尔夫保持着 ralph-progress.md 每个工作树中的文件,用于保存用户故事中的学习。这为代理人提供了“记忆”,让他们知道哪些有效,哪些无效。
运作原理
- 当代理完成用户故事时,它会在
notes领域ralph_update - 拉尔夫将这些笔记附加到
ralph-progress.md在工作台上 - 当下一个用户故事开始时,代理在其提示中收到此日志
- 该文件会自动被git忽略(通过
.git/info/exclude)
进度日志示例
## [2024-01-15 14:30] US-001: Setup Database Schema
- Used Prisma with PostgreSQL
- Added index on `userId` for faster queries
- Note: Must run `pnpm db:migrate:dev` after schema changes
## [2024-01-15 15:45] US-002: User Registration API
- Reused validation patterns from existing auth module
- BCrypt rounds set to 12 for password hashing
- Integration test requires test database to be running
这使得后来的故事可以从早期的发现中受益,而无需重新学习。
安装
来自npm
npm install -g ralph-mcp
来源
git clone https://github.com/G0d2i11a/ralph-mcp.git
cd ralph-mcp
npm install
npm run build
配置
添加 ~/.claude/mcp.json:
{
"mcpServers": {
"ralph": {
"command": "npx",
"args": ["ralph-mcp"]
}
}
}
或者,如果从源代码安装:
{
"mcpServers": {
"ralph": {
"command": "node",
"args": ["/path/to/ralph-mcp/dist/index.js"]
}
}
}
重新启动Claude代码以加载。
运行程序后端默认值
ralph-runner现在分别解析后端和提供者- 默认行为是
agent.backend: cli和agent.provider: codex - 当CLI启动失败时,运行器可以回退到SDK后端
- 集
agent.backend: sdk强制项目的SDK路径
复制 examples/ralph.config.example.yaml 到 .ralph.yaml 在您的项目中,或 ~/.ralph/config.yaml 对于全局默认值:
agent:
backend: cli
provider: codex
codex:
codexPath: codex
approvalPolicy: never
sandboxMode: workspace-write
level: L2
# Optional: switch the runner to Claude CLI instead
# agent:
# backend: cli
# provider: claude
# Optional: force the SDK backend instead
# agent:
# backend: sdk
# provider: claude
PRD摄入观察者
ralph-mcp 可以在内部运行第二个独立的监视器 ralph-runner 摄取新的PRD JSON文件,并通过正常的 ralph start 流动。
- 启用它
ralph-runner --watch-prds - 通过以下方式明确提供手表目录
--watch-prds-dir,watchers.prdIngestion.watchDir,或RALPH_PRD_WATCH_DIR - 现有的匹配文件会像第一次启动时那样被引导,因此之后只会接收新发现的文件
- 如果
projectRoot如果省略,观察者将从PRD JSON解析它repository领域
CLI使用示例:
ralph-runner --watch-prds --watch-prds-dir ~/incoming-prds
配置示例:
watchers:
prdIngestion:
enabled: true
watchDir: ~/incoming-prds
filePattern: ^ez4ielts-.*\.json$
projectRoot: ~/Project/ez4ielts
worktree: true
包脚本 npm run runner:watch-prds 和 pnpm runner:watch-prds 现在调用相同的 --watch-prds 标志,因此一旦配置了上述显式监视目录输入之一,它们就会工作。
Claude代码技能设置(推荐)
为了获得最佳体验,创建一个技能文件,教克劳德如何使用拉尔夫。
看 SKILL-EXAMPLE.md 获取完整的、可复制粘贴的技能配置快速设置
# 1. Create skill directory
mkdir -p .claude/skills/ralph
# 2. Copy the example (adjust path as needed)
cp /path/to/ralph-mcp/SKILL-EXAMPLE.md .claude/skills/ralph/SKILL.md
# 3. Customize quality check commands for your project
添加到CLAUDE.md(可选)
## Skills
| Skill | Trigger |
|-------|---------|
| `ralph` | PRD execution (generate PRD → start → auto merge) |
这使Claude能够在您提到PRD执行时自动使用Ralph。
工具
| 工具 | 说明 |
|---|---|
ralph_start |
启动PRD执行(解析PRD,创建工作树,为Runner排队) |
ralph_batch_start |
通过依赖解析和Runner队列启动多个PRD |
ralph_status |
查看所有PRD执行状态 |
ralph_get |
获取单个PRD详细信息 |
ralph_update |
更新用户故事状态(由代理调用) |
ralph_stop |
停止执行 |
ralph_merge |
合并到主+清理工作台 |
ralph_merge_queue |
管理串行合并队列 |
ralph_set_agent_id |
记录代理任务ID |
ralph_retry |
重试失败的PRD执行 |
ralph_reset_stagnation |
手动干预后重置停滞计数器 |
用法
典型会话
User: Help me finish the Speaking module from TODO.md
Claude: Let me check TODO.md... Found 3 incomplete items:
- Speaking dialogue practice
- Speaking scoring optimization
- Speaking question bank
I'll create 3 PRDs...
[Generates prd-speaking-dialogue.md]
[Generates prd-speaking-scoring.md]
[Generates prd-speaking-qb.md]
User: Start
Claude:
[ralph_start × 3]
[Task Agent × 3 running in parallel]
3 PRDs started. They'll auto-merge when complete.
Use ralph_status to check progress.
--- Some time later ---
User: Progress?
Claude: [ralph_status]
✅ prd-speaking-dialogue - Merged
✅ prd-speaking-scoring - Merged
🔄 prd-speaking-qb - US-003/005 in progress
User: 👍
手动工作流程
// 1. Start PRD execution
ralph_start({ prdPath: "tasks/prd-feature.md" })
// 2. Check status anytime
ralph_status()
// 3. Manual merge if needed (usually automatic)
ralph_merge({ branch: "ralph/prd-feature" })
API 参考
// Start PRD execution.
// Default Runner mode returns null agentPrompt and lets ralph-runner claim it.
ralph_start({ prdPath: "tasks/prd-feature.md" })
// Start multiple PRDs in parallel
ralph_batch_start({ prdPaths: ["tasks/prd-a.md", "tasks/prd-b.md"] })
// View all PRD status
ralph_status()
// Get single PRD details
ralph_get({ branch: "ralph/prd-feature" })
// Update User Story status (called by agent)
ralph_update({ branch: "ralph/prd-feature", storyId: "US-1", passes: true, notes: "..." })
// Stop execution
ralph_stop({ branch: "ralph/prd-feature" })
// Merge to main
ralph_merge({ branch: "ralph/prd-feature" })
// Record Task agent ID (for tracking)
ralph_set_agent_id({ branch: "ralph/prd-feature", agentTaskId: "abc123" })
// Retry a failed execution
ralph_retry({ branch: "ralph/prd-feature" })
// Reset stagnation counters (after manual fix)
ralph_reset_stagnation({ branch: "ralph/prd-feature" })
PRD格式
Ralph解析markdown和JSON PRD文件。PRD监视器默认为JSON文件,例如 ez4ielts-*.json;包括 repository 在JSON PRD中,观察者应该推断什么时候 projectRoot PRD文件本身。
Markdown示例:
---
title: User Authentication
priority: high
---
# User Authentication
Implement user login and registration.
## User Stories
### US-1: User Registration
Users can create new accounts.
**Acceptance Criteria:**
- [ ] Email validation
- [ ] Password strength check
- [ ] Confirmation email sent
### US-2: User Login
Users can log into their accounts.
**Acceptance Criteria:**
- [ ] Email/password authentication
- [ ] Remember me option
- [ ] Forgot password flow
JSON示例:
{
"repository": "~/Project/my-app",
"branchName": "ralph/prd-feature",
"description": "Implement feature",
"dependencies": ["ralph/prd-base"],
"userStories": [
{
"id": "US-001",
"title": "Feature",
"description": "As a user, I want the feature, so that I can work faster.",
"acceptanceCriteria": ["Works end to end"],
"priority": 1
}
]
}
冲突解决
ralph_merge 支持以下策略:
| 策略 | 行为 |
|---|---|
auto_theirs |
git merge -X theirs,更喜欢main |
auto_ours |
git merge -X ours,更喜欢分行 |
notify |
暂停,通知用户手动解决 |
agent |
启动合并子代理进行解析(默认) |
数据存储
- 国家:
~/.ralph/state.json - 日志:
~/.ralph/logs/
用覆盖数据目录 RALPH_DATA_DIR 环境变量。
高级选项
ralph_start选项
| 选项 | 默认值 | 描述 |
|---|---|---|
prdPath |
必需 | PRD标记或JSON文件的路径 |
projectRoot |
cwd | 项目根目录 |
worktree |
true |
创建隔离的git工作树 |
autoStart |
true |
跑步者模式将PRD排队;手动提示生成仅在以下情况下有效 RALPH_AUTO_RUNNER=false |
autoMerge |
true |
所有故事通过后自动添加到合并队列 |
notifyOnComplete |
true |
完成时显示Windows通知 |
onConflict |
"agent" |
冲突解决: auto_theirs, auto_ours, notify, agent |
contextInjectionPath |
undefined |
用于注入手动模式提示的可选文件(例如CLAUDE.md) |
ignoreDependencies |
false |
即使未合并依赖项,也跳过依赖项检查并启动 |
queueIfBlocked |
false |
如果未合并依赖项,请创建挂起执行,而不是失败 |
依赖关系在回购范围内。待处理的PRD被同一项目合并执行记录或包含以下内容的PRD元数据解锁 mergeSha 从合并流中。一个只完成了故事但尚未合并的珠三角并不能解除下游工作的阻碍。
带有选项的示例
ralph_start({
prdPath: "tasks/prd-feature.md",
autoMerge: true, // Auto-merge when done
notifyOnComplete: true, // Windows Toast notification
onConflict: "auto_theirs" // Prefer main on conflicts
})
ralph_batch_start选项
使用依赖解析和串行启动多个PRD pnpm install.
| 选项 | 默认值 | 描述 |
|---|---|---|
prdPaths |
必需 | PRD标记文件的路径数组 |
projectRoot |
cwd | 项目根目录 |
worktree |
true |
创建用于隔离的工作树 |
autoMerge |
true |
所有故事通过后自动添加到合并队列 |
notifyOnComplete |
true |
完成时显示Windows通知 |
onConflict |
"agent" |
冲突解决策略 |
contextInjectionPath |
undefined |
要注入到提示符中的文件路径(例如CLAUDE.md) |
| 热` | true \ |
在挂接代理之前,依次运行pnpm install |
ralph_batch_start({
prdPaths: [
"tasks/prd-auth.md",
"tasks/prd-dashboard.md",
"tasks/prd-settings.md"
],
contextInjectionPath: "CLAUDE.md",
autoMerge: true
})
拉尔夫尝试
重试失败的PRD执行。重置停滞计数器并生成新的代理提示,从停止的地方继续。
// Retry a failed execution
ralph_retry({ branch: "ralph/prd-feature" })
// Returns: { success, branch, message, previousStatus, agentPrompt, progress }
ralph_reset_签名
手动干预后重置停滞计数器。当您修复了问题并希望代理继续时使用。
| 选项 | 默认值 | 描述 |
|---|---|---|
branch |
必填 | 分行名称 |
resumeExecution |
true |
如果当前“失败”,请将状态设置回“正在运行” |
// Reset counters and resume
ralph_reset_stagnation({ branch: "ralph/prd-feature" })
// Reset counters only (keep failed status)
ralph_reset_stagnation({ branch: "ralph/prd-feature", resumeExecution: false })
最近的改进
2026-03-06
- 已验证完成的US跳过逻辑:确认ralph-mcp的数据库驱动架构通过以下方式自动跳过已完成的用户故事
stories.filter((s) => !s.passes)在代理提示生成中。与需要手动操作的ralph-cli不同completedUS.includes()经检查,ralphmcp的设计本质上防止了已完成故事的重新执行。 - 修复了进度检测误报问题
- 添加了提交计数跟踪,以区分实际进度和停滞
- 防止代理在成功提交代码后被标记为停滞
学分
许可证
麻省理工学院
