距 iflow-bot 上线到现在，也过了半个月了。
这段时间自己长期用下来，最大的感受其实很直接：
虽然 bot 已经能接入多个渠道，也能完成不少事情，但在实际使用时，整体交互方式依然很容易退化成“一问一答”。
尤其是一旦开始处理长任务，问题就会变得非常明显：
- 主会话容易被长任务占住。
- 我无法清楚知道它当前到底执行到哪里。
- 我甚至分不清，它到底是卡住了、挂了，还是还在默默执行。
这种体验其实很不理想。
因为我相信，很多人真正想要的，不是反复沟通、反复确认、反复盯过程，而是：
我把任务交代清楚之后，你自己持续做下去，必要时让我审批一下，剩下的时间我只需要等结果。
那么，有没有一种方式，能让 iflow-bot 真正做到这种效果？
带着这个问题，我又去看了很多类似项目，比如 openclaw、nanobot 等。
它们当然也有自己的思路，也支持 subagent、agent team 之类的机制，但实际体验下来，还是很难脱离“一问一答”的处理方式。能力是有的，但离“真正好用”还有距离。
问题并不是它们不能做，而是：
不够顺手，不够稳定，也不够符合我自己对长任务执行的预期。
后来我又把目标重新转回到了 iflow CLI 本身。
我突然意识到一件事：
既然 iflow CLI 本身就是 CLI 工具，那我为什么不基于它，给 iflow-bot 做一层“长任务 orchestrator”？
比如：
我把一个复杂任务交给 bot，它先帮我整理成一个明确的执行计划，然后创建独立的 subagent session，逐个去处理拆分出来的 story，过程中不阻塞主会话，而我只需要在关键节点介入。
再往下想一步：
既然都已经用 subagent 了，那是不是还可以给不同 story 分配不同身份？
比如：
researcherengineerwriterqa
这样每个子任务就不是“同一个 agent 什么都做”，而是“按角色专注完成自己的工作”。
这会带来两个直接好处：
subagent不依赖主会话上下文，可以更聚焦当前任务。- 不同角色有不同关注点，交付物会更完整，执行质量也会更高。
再然后，我又想到自己很喜欢的一个 Claude Code 插件：ralph loop。
这个插件的思路其实很简单，甚至可以说有点“朴素”：
它本质上就是不断鞭策 CLI 继续工作，继续推进，继续完成任务。
你可以把它理解成一个受控的任务循环，它会不断告诉底层 agent：
“继续。”
“继续往下做。”
“别停，直到完成。”
我以前甚至让它连续跑过 20+ 小时，中间自己只是偶尔去看产出物。
想到这里，我一下就明确了：
这不就是我想要的效果吗？
我需要的，不是一个只能陪我聊天的 bot。
我需要的是一个真正能持续推进任务、真正能完成长任务的 bot。
于是，iflow-bot 里的 Ralph 功能就这样开始设计并实现了。
Ralph 的核心目标
Ralph 不是普通聊天命令。
它解决的是“长任务执行”问题。
它的设计目标很明确：
- 不阻塞主会话
- 使用独立
subagent执行任务 - 支持按 story 分配角色身份
- 支持人工审核 PRD 后再执行
- 支持随时停止
- 支持中断后恢复
- 支持在聊天渠道里直接查看状态
也就是说，它不是 cron，也不是普通的一轮对话增强。
它更像是一个运行在 iflow-bot 里的长任务执行器。
Ralph 的基本执行流程
整个流程大致是这样的：
- 用户先提交一个长任务 prompt
- bot 先生成澄清问题
- 用户补充答案
- bot 生成 PRD
- 用户审核 PRD
- 用户批准后，Ralph 开始真正执行
- 每一轮由独立 subagent 处理一个 story
- story 完成后更新进度，再进入下一个 story
- 直到整个 PRD 完成，或用户主动停止
这里最关键的一点是：
执行任务的是独立 subagent，不是主会话本身。
所以即使 Ralph 在跑长任务，主会话也不会被彻底卡死，你依然可以继续查看状态，或者做别的事情。
为什么一定要用 subagent
这一点我自己非常看重。
如果长任务直接占着主会话执行，会有几个明显问题：
- 主会话上下文会越来越脏
- 长任务很容易把普通聊天能力拖死
- 用户无法区分“主会话回复”与“任务执行输出”
- 一旦中途中断，恢复也很难做干净
而用了 subagent 之后，事情就清晰很多：
- 主会话负责控制
- 子会话负责执行
- 状态和进度单独存储
- 停止和恢复都更容易做
- 不同 story 还可以带不同角色身份执行
这就是 Ralph 设计里最核心的一条：
主会话负责“管控”，subagent 负责“干活”。
为什么还要给 subagent 分角色
因为长任务本身就不是单一能力问题。
比如一个“开发 Todo List Web 应用”的任务，天然就可能包含这些角色：
- 产品
- 调研
- 后端
- 前端
- 测试
- 文档
如果让一个 agent 用同一种视角把所有事情都做完，往往结果就是：
什么都做了，但每一块都不够专注。
所以在 Ralph 里，我更倾向于按 story 分角色，比如：
researcher负责调研、技术选型、对比结论engineer负责实现和落地qa负责测试和验证writer负责文档整理与交付说明
这样子任务的执行目标会更清晰，产出物也更接近真实协作流程。
Ralph 不是 cron
这个点要特别强调一下。
很多人容易把它和定时任务混在一起。
但其实两者目的完全不同：
cron 是：
- 到时间执行一次
- 或按固定频率执行
- 更偏自动触发
Ralph 是：
- 接收一个长任务
- 持续推进直到完成
- 可以暂停、恢复、查看状态
- 更偏任务编排和持续执行
所以 Ralph 没有“执行频率”这个概念。
它不是定时调度器，它是长任务 loop。
当前支持的 Ralph 命令
下面这几条是当前 iflow-bot 已支持的 Ralph 命令：
/ralph "<prompt>"
创建一个新的 Ralph 长任务。
它不会直接执行，而是会先根据任务生成澄清问题，帮助把需求定义清楚。
示例：
/ralph 做一个 Todo List Web 应用，使用 Python 3 + uv，输出到 .iflow-bot/workspace/project/todolist，支持新增、完成、删除任务。
/ralph answer <回复>
回答 Ralph 提出的澄清问题。
你可以一次性回答，也可以按自然语言补充。
示例：
超长PRD，就不全展示了。。。。。。
/ralph approve
在 PRD 生成并审核通过后，明确批准执行。
Ralph 的设计是“先审 PRD，再执行”，避免 agent 直接在错误需求上一路跑偏。
示例：
/ralph approve
/ralph status
查看当前 Ralph 任务状态。
会展示例如：
- 当前是否运行中
- run_id
- 当前执行到第几个 story
- 当前 pass
- 当前子角色
- 当前阶段
示例：
/ralph status
/ralph stop
停止当前 Ralph 任务。
它会取消当前执行中的 subagent session，让长任务安全停下来，而不是继续后台失控跑下去。
示例：
/ralph stop
/ralph resume
恢复最近一个未完成的 Ralph 任务。
这在长任务中非常重要，因为现实里任务不可能保证一次跑完。支持恢复，才能真正可用。
示例：
/ralph resume
一个典型场景
比如我现在要做一个长任务：
“开发一个 Todo List Web 应用。”
在 Ralph 的思路里，它不会直接莽着开干，而是会先走一遍更可靠的流程：
- 我提交任务 prompt
- 它先问清楚技术栈、输出路径、功能边界
- 生成 PRD
- 我审核 PRD
- 开始逐 story 执行
- 不同 story 用不同角色处理
- 执行过程中主会话不阻塞
- 我随时可以
/ralph status - 不满意就
/ralph stop - 之后还可以
/ralph resume
比如这个任务里，可能涉及的角色就有：
- 后端
- 前端
- 测试
- 产品
而 Ralph 做的事情，就是把这类“长任务执行”真正从普通聊天里拆出来，变成一个可控、可恢复、可观察的流程。
我为什么要做这个功能
因为我越来越不满足于：
“bot 能回答问题”
“bot 能接几个平台”
“bot 看起来挺聪明”
这些事情当然重要，但它们不够。
我更想让 iflow-bot 真正变成一个可以长期干活的助手。
不是只会聊天，而是可以：
- 接任务
- 理清需求
- 拆解执行
- 持续推进
- 中途可控
- 最终交付
而 Ralph，就是朝这个方向迈出去的一步。
它不一定是最终形态，但它已经让 iflow-bot 从“会聊天的 bot”，开始变成“能持续完成长任务的 bot”。
如果你也和我一样，厌倦了一轮又一轮地反复对话、反复确认、反复盯过程，那么我觉得你可以试试看这个能力。
也欢迎大家继续提意见。
我会继续把这个功能往“真正可用、真正稳定、真正能干活”的方向打磨下去。
最后，我们看看一轮对话的最终产物如何。
感觉真的超有意思，不过一时半会看不懂，慢慢消化吧