长任务实战 · 让 Agent 跑一整天而不翻车

2026-07-07 18:40 Vibe Coding; Codex; 长任务; 反馈闭环; TDD 3188 字 16 min read

前面几篇讲的是”心法”——怎么想、怎么问、怎么审、什么时候收。这一篇讲一件很具体的工程事:怎么让 Agent 自主工作几个小时,产出一个真正能用的东西,而不是让你被拴在电脑前每五分钟确认一次。

这是 Vibe Coding 从”玩具”走向”生产力”的分水岭。做得好,你丢一个需求进去,喝杯茶回来就是一个跑通的项目;做得差,你熬到凌晨三四点,改一个 bug 来回十几轮,最后代码还支离破碎。

一、为什么大部分人的长任务体验很差

先看一个典型的失败场景。你要开发一个聊天机器人插件:

写完代码 → 手动部署 → 手动测试 → 发现 Bug → 把日志喂给 AI → 修复 → 再部署……

一个 Bug 来回改好几轮,等功能”看起来能跑了”,代码已经乱成一团。想重构,又怕引入新 Bug。整个过程高度依赖人工介入,既费时又不可控。

问题的根源只有一句话:缺少反馈闭环。

当你把需求、文档、示例都给了 AI,它理论上已经具备开发的全部前置条件。为什么还需要你不断介入?因为 AI 在盲射。它写出来的东西拿不到反馈——不知道跑起来对不对、日志里报什么错、业务场景通不通。每次直接写出来的代码,大概率不能直接跑。于是就得你来当”反馈中转站”

、看日志、复制回去。你成了闭环里最慢的那一环。

长任务的核心,不是让 AI”写得多”,而是让 AI”能自己验证自己写的东西”。 一旦 AI 能自助验证,它就能一直转下去,而你可以走开。

二、第一层
TDD

既然 AI 写代码容易出 Bug,那就立规矩,让它严格遵循测试驱动开发(TDD):

Red
(此时运行失败)
Green
Refactor

关键在于:编写测试、运行测试、根据报错自行修复,全过程都交给 AI。 测试是 AI 的第一个反馈来源——它写完代码跑测试,红了就知道错在哪,绿了才继续。你不需要在每一步盯着。

这一层解决的是”逻辑对不对”。但它有个天花板

,保不了业务场景。一个聊天机器人的单测全绿,不代表用户发消息真能收到正确回复。所以还需要第二层。

三、第二层
(关键)

这是整套方法的核心,也是最需要你亲自投入的地方。

举个真实例子。开发一个 QQ 机器人框架(AstrBot)的插件,传统的”上号测试”——真登录一个 QQ 号发消息看回复——效率极低,而且 AI 根本没法操作 QQ 客户端。

换个思路

”输入消息 → 处理 → 输出响应”。既然 AI 操作不了 QQ 客户端,能不能给它做一个基于命令行的模拟器?

于是就有了一个 CLI 测试平台

Agent 直接在命令行里模拟发送消息、接收回复、甚至重启服务。这样一来,闭环就通了:

AI 写完代码,直接在命令行跑 E2E 测试
发现回复不对,AI 自动读日志,反思并修改
改完再跑,直到测试通过

全程无需人工介入。 实测

”钓鱼游戏插件”的需求(要有鱼类品种、稀有度、金钱、概率、钓鱼工具系统,聊天交互,用户记录和签到),AI 自主工作 35 分钟,通过所有测试用例和端到端测试,直接产出可用插件。对比之前”写几分钟就要交互一次、写完还要手动测、无穷调试”,提升非常明显。

这一层的投入产出比: 为你的项目做一个”能让 AI 操作的 CLI 平台”是有初期成本的,但它是基础设施——一次投入,之后每一个功能、每一次重构都能自动验证。这是把 AI 从”盲射”变成”自助验证”的那把钥匙。

不同项目的 E2E 平台形态不同

应用可以是 Playwright 脚本或一个能起服务打接口的脚本;CLI 工具本身就好测;数据处理可以是”喂样本数据看输出”。核心不变:给 AI 一个它能亲手跑、能亲眼看到结果、能读到错误的通道。

四、第三层

功能跑通了,但代码不一定易读,可能还有安全隐患。这时进入重构阶段。方法是:预设一份问题清单,让模型带着具体问题逐项审查代码。

这里有个关键能力,可以叫它**“非退化性”**:

模型带着一个具体问题审查代码时,不会把正常代码误判为问题,同时能准确识别出真正有问题的代码。

看起来平平无奇,但正是它保证了 AI 最终能写出好代码。论证如下:

单次审查
(比如”有没有违反单一职责”)审查,AI 总能找到可改进的地方
多次迭代
,该类问题的出现次数递减
收敛性
,代码在这个维度上的问题趋于消失,对 AI 来说变得”平滑”——不再有突兀之处,这个问题就算解决了

进一步

每个问题的解决都不引入新问题,那么只要你预设了足够多维度的问题(SOLID、DDD 分层、防御式编程……),反复让 AI 带着这些问题重构,最终代码就会在所有维度上达标。

那”不引入新问题”怎么保证?靠第二、三层留下的测试集。 每次重构都必须保持测试全绿,任何破坏逻辑的修改都会立刻被测试拦下。测试集是安全网,非退化性是方向——两者合起来,保证代码始终向变好的方向迭代。

操作方法:

构建安全网
E2E 覆盖了关键逻辑
预设问题清单
CLAUDE.md / AGENTS.md 里列出重构维度(SOLID、分层、防御式编程等)
迭代优化
AI 对照清单逐项优化,测试兜底

五、第四层
”跑到底”——CSV 四状态闭环

前三层解决了”AI 能自己验证”。但当任务很大(几十个子任务、要跑几小时),还有两个新问题

AI 中途会莫名其妙停下;二是 AI 会偷懒骗人——跑个 smoke test、用假数据,就声称”跑通了”。

社区里摸索出一套很实用的解法:把大任务拆成一张 CSV,每条是一个原子任务(atomic issue),每条任务用四个状态字段强制走完整闭环。

核心是这四个状态:开发 → 初始审查 → 回归审查 → 提交。只有四个状态全部到位,这条任务才算关闭。这就是”少返工”的机制——不是靠最后一条 review 命令补救,而是每一条任务都自带”写完 → 自查 → 回归 → 提交”的微观闭环,AI 不能跳过任何一步就声称完成。

再加一个宏观保险:在 CSV 末尾加一条整体 REVIEW 行。就这么简单一条,但很多人的任务清单都下意识漏了它。加上之后,每条任务执行完还会做一次整体验收,直到完全闭环。“微观闭环 + 宏观验收”的双保险,是长任务不跑偏的关键。

还有一个防偷懒的细节

”验证策略”和”验证手段”分开写。

验证策略
AI 这条任务的验证思路是什么(比如”通过发消息看回复验证”)
验证手段
(比如指定用某个 MCP)。因为实践发现,不指定工具,AI 就倾向于跳过真实验证、直接从代码层面”假装测试”

两者分开,AI 既知道验证的”策略”又知道验证的”手段”,就很难再用”跑了个 smoke test 就说通过”糊弄过去。

六、让它扛得住中断——长任务执行入口

最后一个现实问题

,难免遇到 API 供应商掉线、额度耗尽、甚至你不小心关机。如果一断就前功尽弃,那”跑一整天”就是空话。

好在现在的工具已经把这件事解决了。以 Codex 的 /goal 为例

,供应商掉线它会挂着等你恢复,恢复后自动 resume;关机了回来也能自动继续。 于是任务的目标从”怎么跑得久”变成了”怎么跑得好”。

一个救命的小细节: 用 Codex 长任务入口时,先随便发一句 hello 让它回一句,再发正式指令。如果第一条就是长任务命令,那条会话记录可能丢失,恢复时找不回上下文。开头发过占位消息,codex resume 才能可靠地接着跑。

七、把四层拼起来

一套经过实战检验的协同流程(Claude 出方案、Codex 执行):

你的需求
  │
  ├─ 复杂/模糊 → 用 Claude 讨论(brainstorming)→ 写成 spec 文档 → 转成 CSV
  │                                                              ↓
  ├─ 清晰/直接 → 直接把需求描述丢给任务路由,自动拆成 5-15 条原子任务的 CSV
  │                                                              ↓
  └─ 已有 CSV ─────────────────────────────→ /goal @xxx.csv 执行
                                                              ↓
                                          每条 issue:开发 → 初始审查 → 回归审查 → 提交
                                                              ↓
                                          末尾 REVIEW 行:整体验收
                                                              ↓
                                          全部关闭 = 任务完成

几条实战心得(来自社区反复调优的经验):

方案让 Claude 讨论,CSV 让 Claude 转,执行交给 Codex。 Claude 转 CSV 会转得很详细(常有十几二十条),Codex 倾向于”少”,容易漏。时间换准确率,值得。
不是越详细越好。 过度详细的计划文档反而更难完成,尤其是前端。一份 spec 直接转 CSV,往往比”spec → 复杂 plan → CSV”效果更好——给 AI 留发挥空间。
约束别给太满。 Codex 会很老实地遵守 AGENTS.md,给太多限制反而放不开手脚。放宽一些,只保留真正的红线。
把项目的固定信息写进 AGENTS.md。 账号密码、端口、该用哪个库——不然每次跑它都要去查,浪费时间。

八、一个反直觉的结论

如果反馈闭环建好了、非退化性成立,那么模型只要”会做题、会写代码”,就能通过这套循环产出足够好的代码——理论上一个中等模型也行。

那为什么还需要更强的模型?区别在于**“做题”的效率和上限**

、能读长上下文、能根据日志分析定位难缠的 bug。分析能力有限的模型,遇到硬 bug 会陷进去反复无效思考,卡死在循环里出不来。

换句话说:闭环决定了”能不能到达”,模型强弱决定了”多快到达、能不能越过难关”。 两者都重要,但先把闭环建起来,比一味追求最强模型更划算。

这一篇的核心: 让 Agent 跑一整天,靠的不是更长的 prompt 或更强的模型,而是给它一个能自助验证的闭环——TDD 保逻辑、E2E 平台保场景、问题清单保质量、CSV 四状态保不偷懒、长任务入口保不中断。把 AI 从”盲射”改造成”自助验证”,你才能真正走开。

下一篇是专题收尾:负责任的 Vibe 与”AI 不能当架构师”,聊聊这套能力背后不能丢的东西——判断、责任和手艺。

本文主要参考

.do 社区《如何高效地 Vibe Coding》(反馈闭环、TDD、E2E 平台、非退化性重构)、《让长任务可控坚韧
mission + goal 让 Codex 跑一天不累》(CSV 四状态闭环、/goal 长任务入口)。文中观点已重新组织,具体工具命令请以官方最新文档为准。