让 Agent 自己跑几小时：异步协作工作流的 5 个设计原则

现状：agent 能跑几小时，你还不会「放手」

多家媒体 10 月初的观察指向同一个结论：AI coding agent 现在能独立完成真实的工程任务，连续自主运行几小时不再稀奇。剩下的主要挑战不是速度，是信任——你敢不敢让它在你不看的时候动你的代码库。

大多数人的用法还停留在「结对模式」：发一条指令，盯着屏幕看它跑，跑完检查，再发下一条。这相当于雇了个能干的远程员工，却要求他每 5 分钟跟你视频汇报一次。agent 的能力已经异步了，你的工作流还停留在同步。

原则一：任务切分到「可验证」，而不是「可描述」

异步的前提是：agent 跑完一段，你能低成本验证对错。切分任务的标准不是「这段话我说得清」，而是「做完我怎么知道它做对了」。每个子任务必须自带验收标准：测试通过、lint 干净、截图对比、API 返回符合契约。

反模式：「把用户系统重构一下」——做完你根本不知道从哪验起。正模式：「把 auth 模块的 6 个函数抽到新文件，保持所有现有测试通过，新增函数的单元测试覆盖率 80%+」——跑完看测试报告就行。

原则二：用检查点代替盯屏

长任务拆成 3-5 个检查点，每个检查点结束时 agent 必须停下来做三件事：git commit（可回滚）、写一段进度摘要（做了什么、为什么这么做）、列出阻塞和疑问。然后它可以继续，也可以等你。

检查点的价值是把「信任」变成「可审计」：你不需要全程看着，但任何时候回来，都能从 commit 历史和摘要里 reconstruct 它干了什么。出问题最多回滚到上一个检查点，而不是「这 3 小时全白干」。

原则三：用通知代替轮询

「去喝杯咖啡，回来看看跑完没」是最低效的协作。正确姿势是让 agent 能触达你：跑完/卡住/需要决策时，推送到你的手机。有人已经把 Cursor 接到 WhatsApp 上：agent 跑完长任务给你发消息，遇到不可逆操作先问你，收到回复才继续。

工具不重要（MCP、webhook、企业微信机器人都行），模式重要：agent 主动推，你被动收。你的注意力只花在「需要人类判断」的时刻，而不是「看看它跑到哪了」的轮询上。

原则四：给失败留预算，而不是追求一次成功

异步跑 3 小时的任务，不可能一次全对。成熟的做法是给每次长任务设「失败预算」：允许 agent 在测试失败时自主重试 N 次（比如 3 次），超过预算才升级给你。预算内的问题是 agent 的学费，预算外的问题才是你的工作。

关键是把「重试策略」写进任务指令：「测试失败时先读报错、定位根因再改；同一测试连续失败 3 次就停下，把报错摘要和已尝试方案发我，不要继续烧 token。」没有失败预算的异步，就是放任。

原则五：复盘代替重跑

长任务结束后的 10 分钟复盘，价值超过任务本身：让 agent 总结「哪些决策是对的、哪些是蒙的、哪里浪费了时间」，把结论写进项目的 AGENTS.md 或复盘文档。下次同类任务，它就站在上次的肩膀上。

这也是人和 agent 的分工本质：agent 负责执行和试错，你负责把试错沉淀成资产。不做复盘的团队，每次长任务都是从零开始烧钱；做复盘的团队，agent 越用越像「懂你们代码库的老人」。

一句话总结

把 agent 当异步同事：给它可验证的任务、检查点、触达你的通道、失败预算，和每次的复盘。你不需要更强的 agent，你需要的是配得上它的工作流。