2026 年 4 月，海外开发者社区出现了一个新词叫"Sleep-Driven Development"——下班前把任务丢给 AI Agent，Agent 通宵干活，早上起来 Review PR。这不是玩笑，多个团队已经在生产环境中这么做了。这篇拆解背后的技术方案和坑。
从"结对编程"到"留作业"
AI 编程工具过去两年的演进路线很清晰：
| 阶段 | 模式 | 人的角色 | 代表工具 |
|---|---|---|---|
| 2024 | 自动补全 | 写代码，AI 补全 | Copilot |
| 2025 | 对话编程 | 描述需求，AI 实现 | Cursor, Claude Code |
| 2026 | 后台自主 | 留任务，AI 通宵做 | Codex Background, Ralph |
2026 年的变化是：开发者不需要在场了。
之前不管是 Copilot 还是 Claude Code，你都得坐在电脑前——要么接受补全，要么和 AI 对话。人离开了，AI 就停了。
现在的后台 Agent 模式彻底改变了这个前提：你提交一个任务描述，关掉笔记本去吃饭、去睡觉，Agent 在 Cloud 或者你的服务器上自主跑。它会：
- 读你的代码库理解上下文
- 制定实现计划
- 分步骤写代码
- 跑测试
- 修复失败的测试
- 全部通过后提交 PR
早上回来你看到的是一个完整的 PR，带代码、带测试、带描述。你的工作变成了 Review。
Ralph Loop：最近最火的实现方案
Ralph 是 4 月底出现的一个开源工具，专门做"AI Agent 自主循环开发"。它的核心思路非常简单：
把一个大任务拆成多个小故事（story），每个故事跑一轮 Agent。
Ralph Loop 的工作流：
1. 读 prd.json（你提前写好的需求列表）
2. 找到第一个状态为 "todo" 的 story
3. 启动 Claude Code（或 Amp），把 story 描述喂进去
4. Agent 自主写代码、跑测试
5. 如果测试通过 → 标记 story 为 done，git commit
6. 如果测试失败 → 最多重试 3 次
7. 回到第 2 步，处理下一个 story
8. 所有 story 完成 → 生成 PR
关键的设计决策：每个 story 用一个全新的 Agent session。 不是一个 Agent 从头跑到尾——而是每一轮重新启动，只给它当前 story 需要的上下文。
为什么要这样做？因为长时间运行的 Agent 会出现上下文污染（我之前写过这个问题——Agent 跑久了回答质量断崖式下降）。每轮用新 session 保证了每个 story 都在"干净"的上下文里执行。
持续性靠的不是 Agent 的记忆，而是git 和文件系统。每个 story 完成后代码已经提交了，下一轮 Agent 读最新的代码库就自然获得了前序 story 的成果。
不只是 Ralph——后台 Agent 已经是标配
Ralph 只是最近最火的一个。2026 年 4 月，几乎所有主流 AI 编程工具都在做后台自主执行：
| 工具 | 后台模式 | 运行环境 | 特点 |
|---|---|---|---|
| Codex | Background Tasks | OpenAI Cloud | 提交任务后关浏览器也能跑 |
| Claude Code | Routines | Anthropic Cloud | 定时触发、API 触发 |
| Cursor | Background Agent | 本地 | 新出的，编辑器后台跑 |
| Ralph | Autonomous Loop | 本地/VPS | 开源，循环执行多个 story |
| Workspace Agents | Event-Driven | OpenAI Cloud | 团队级，事件触发 |
据 Tembo 的分析：
"Agentic coding is autonomous: the developer assigns a task, closes their laptop, and comes back to a pull request — an increasingly common workflow for senior developers shipping non-trivial work."
这个描述在 2025 年听起来像科幻，在 2026 年 4 月已经是一部分高级开发者的日常了。
这个模式真正改变的是什么
表面上看是"AI 替你写代码"。但深层次的变化是开发者的工作节奏被重构了。
之前的一天
9:00 到公司，打开 IDE
9:30 开始写代码
10:00 遇到问题，用 Claude Code 对话解决
12:00 午饭
13:00 继续写代码
15:00 写完一个功能，开始写测试
17:00 测试通过，提交 PR
17:30 下班
人在 IDE 前面坐了 8 小时。AI 是"加速器"——让你写得更快，但你还是得在。
后台 Agent 模式的一天
9:00 到公司，Review 昨晚 Agent 提交的 3 个 PR
10:00 Review 完，合并 2 个，打回 1 个（留注释让 Agent 修）
10:30 写今天的 3 个 story 描述到 prd.json
11:00 启动 Ralph Loop 跑第一个 story
11:05 不用盯着，去做架构设计、写文档、开会
15:00 回来看进度，2 个 story 已经完成，Review PR
16:00 写明天的 story 描述
17:00 启动 Agent 跑通宵任务
17:30 下班
开发者的核心工作从"写代码"变成了"写需求 + Review PR"。
这不是效率提升 30-50% 的量变——这是工作性质的质变。你的产出不再受限于"你一天能写多少行代码"，而是受限于"你一天能写多少个清晰的 story 描述"和"你一天能 Review 多少个 PR"。
这个模式的前提条件
不是所有项目都能这么做。据多个团队的分享，后台 Agent 跑得好需要几个前提：
前提一：完善的测试套件
Agent 写完代码之后靠什么判断"做对了"？跑测试。 如果你的项目没有测试（或者测试覆盖率很低），Agent 就失去了自我验证的能力——它可能写出看起来对但实际有 bug 的代码，而且通宵跑完你早上看不出来。
Ralph 的文档明确说：
"Ralph works best for batch tasks where a clear definition of 'done' can be encoded as tests."
没有测试 = 不能用后台 Agent。 这是硬前提。
前提二：清晰的 story 粒度
故事太大（"实现用户系统"），Agent 做不好——它会在第 5 步偏离架构。故事太小（"给这个变量改个名"），不值得跑一个完整的 Agent 循环。
据实践经验，一个好的 story 大约是：
| 粒度 | 适合后台 Agent？ | 例子 |
|---|---|---|
| 改一行代码 | ❌ 太小 | "修复 null check" |
| 一个函数/组件 | ✅ 刚好 | "实现密码重置 API" |
| 一个模块 | ⚠️ 偏大 | "实现支付模块" |
| 一个系统 | ❌ 太大 | "实现完整的用户系统" |
最佳粒度：一个 story 涉及 1-3 个文件，能在 15-30 分钟内完成。 Agent 在这个范围内的成功率最高。
前提三：可靠的 Agent 运行环境
Agent 通宵跑，你不在场。任何导致 Agent 停止的问题都等于浪费了一晚上：
- API 限流 → 需要自动降级
- 模型超时 → 需要自动重试
- 内存泄漏 → 需要进程守护
- 网络断连 → 需要自动恢复
这些基础设施问题我之前专门写过——3 次生产故障没有一次跟模型能力有关，全是基础设施的坑。后台 Agent 对基础设施的要求比交互式 Agent 高一个量级。
实操：怎么开始
如果你想试试"下班前留作业"的模式，最简单的路径：
第一步：选一个工具
| 你的情况 | 推荐 |
|---|---|
| 已经在用 Claude Code | Claude Code Routines（Cloud 托管，最省心） |
| 已经在用 ChatGPT Plus | Codex Background Tasks |
| 想自己掌控 | Ralph Loop（开源，本地/VPS 跑） |
| 已经有自建 Agent 框架 | 加一个 cron 循环执行就行 |
第二步：写好 story 描述
// prd.json 示例
{
"stories": [
{
"id": "auth-01",
"title": "实现 JWT 刷新 token 逻辑",
"description": "在 /api/auth/refresh 端点实现 token 刷新。access token 过期时间 15min，refresh token 7天。refresh token 要存入数据库并做单次使用限制。",
"acceptance": "所有 auth.test.ts 中的测试通过",
"status": "todo"
},
{
"id": "auth-02",
"title": "添加登录失败限流",
"description": "同一 IP 连续登录失败 5 次后锁定 15 分钟。用 Redis 计数。",
"acceptance": "rate-limit.test.ts 中的测试通过",
"status": "todo"
}
]
}
关键：acceptance 字段写清楚验收标准——Agent 靠这个判断自己有没有做对。
第三步：启动并去睡觉
# Ralph 方式
ralph start --prd prd.json --agent claude-code --max-retries 3
# 或者简单的 shell 循环（穷人版 Ralph）
while true; do
story=$(jq -r '.stories[] | select(.status=="todo") | .id' prd.json | head -1)
[ -z "$story" ] && echo "全部完成" && break
desc=$(jq -r ".stories[] | select(.id==\"$story\") | .description" prd.json)
# 调用 Agent 执行
claude-code --message "$desc" --auto-accept
# 跑测试
if npm test; then
git add -A && git commit -m "feat: $story"
jq "(.stories[] | select(.id==\"$story\")).status = \"done\"" prd.json > tmp && mv tmp prd.json
fi
done
这个 shell 脚本是极简版本。生产级需要加：错误处理、重试逻辑、超时控制、进度通知。Ralph 把这些都封装好了。
风险和局限
风险一：Agent 可能"通过了测试但做错了"
测试只能验证你写了什么测试。测试没覆盖的边界情况，Agent 一样会做错。 而且因为你不在场，这些错误要等你早上 Review 才能发现。
缓解方案：通宵任务只跑有完善测试覆盖的 story。新功能的第一版先自己交互式写（确保架构对），后续的迭代和修复交给后台 Agent。
风险二：模型成本可能超预期
Agent 通宵跑，每个 story 可能要调用模型几十次（写代码 + 跑测试 + 修 bug + 重试）。一晚上跑 5 个 story，模型调用次数可能过百。
按 Claude Sonnet 的价格（15 MTok）估算，一个 story 大约 30-50K token 的消耗，5 个 story 约 60-160。
如果用更便宜的模型（DeepSeek V3 0.41），同样的工作量降到 $3-8/月。但便宜模型的 story 完成率会低一些——简单 story 没问题，复杂的需要更多重试。
风险三：安全
Agent 有代码仓库的写权限。如果你的 Agent 运行在 Cloud 上（Codex Background、Claude Routines），你的代码经过了第三方服务器。
对敏感项目，建议：
- Agent 跑在自己的 VPS 上
- 提交到单独的分支，不直接推主分支
- 早上 Review 时仔细检查是否引入了安全隐患
常见问题
Q: 这个模式适合初级开发者吗？ A: 不太适合。后台 Agent 产出的 PR 需要有经验的人 Review。如果你对代码质量没有判断力，你可能会合并有隐患的代码而不自知。这个模式更适合高级开发者——他们知道什么是"好代码"，能快速发现 Agent 的问题。
Q: 一晚上能跑多少个 story？ A: 取决于 story 的复杂度和模型速度。简单 story（一个 API 端点）大约 10-20 分钟一个。中等 story（带测试的完整功能）30-60 分钟。一晚上 8 小时可以跑 8-20 个简单 story 或 5-10 个中等 story。
Q: Ralph 和 Claude Code Routines 选哪个？ A: Routines 更简单（Cloud 托管，不用维护），但只能用 Claude 模型。Ralph 更灵活（开源，支持多模型，可以自己加规则），但需要自己维护运行环境。如果你的 story 涉及非 Claude 模型（比如成本考虑用 DeepSeek），选 Ralph。
