AFK Agent：让AI在你离开键盘时自主编码

从多阶段计划到自动化执行

在AI编程的实践中，一个被反复验证的思维模型是多阶段计划（Multi-Phase Plan）。它的核心理念很简单：把大块的工作分解成若干阶段，让每个阶段都落在AI代理的"智能舒适区"内，从而获得最佳的输出质量。

多阶段计划并非AI编程领域的原创概念，它的思想根源可以追溯到软件工程中经典的"分而治之"（Divide and Conquer）策略和敏捷开发中的迭代交付模型。在传统软件开发中，瀑布模型将项目分为需求、设计、编码、测试等线性阶段；而在AI代理的语境下，多阶段计划的核心创新在于每个阶段的粒度被精心调校到与大语言模型的上下文窗口和推理能力相匹配的范围内。所谓"智能舒适区"，本质上是指模型在单次交互中能够保持高质量输出的任务复杂度边界——超过这个边界，模型就容易出现幻觉、遗漏关键约束或产生逻辑不一致的代码。

要驱动这样的流程，通常需要三个关键输入：

• 目标 PRD（产品需求文档）：定义要做什么
• 计划（Plan）：也就是整个任务的"旅程"路线图
• 执行阶段指令：告诉代理依次执行第一、第二、第三阶段

这套设置看起来很完善，但它隐藏着一个关键痛点——那个"执行第 N 阶段"的指令，意味着必须有一个人时刻陪着代理，手动告诉它现在该做哪一步。

HITL的浪费：人为什么要一直守着？

这种模式在业界被称为 HITL（Human-In-The-Loop，人在环中）。理论上它保证了可控性，但在实际操作中却带来了巨大的人力浪费。

HITL 是机器学习和自动化领域的经典设计模式，最早广泛应用于主动学习（Active Learning）和半自动标注系统中。在这些场景下，人类的介入是为了处理模型不确定性较高的边界案例，从而提升整体系统的可靠性。然而，当HITL被应用于AI编程代理时，其角色发生了微妙的退化——人类往往不是在做"判断"，而只是在做"确认"和"推进"，即机械地告诉系统进入下一步。这种退化的HITL实际上违背了该模式的设计初衷：它本应让人类在关键决策点发挥不可替代的判断力，而不是充当一个定时器或按钮点击器。

试想一下这个场景：你的目标已经完整规划好了，大语言模型的整个执行旅程也已经铺设完毕，你需要做的仅仅是在终点等待，然后处理最终的输出结果。既然如此，为什么还要一个人在每个阶段结束时手动点击"下一步"？

作者一针见血地指出："执行第 N 阶段"本质上就是一个 for 循环。既然每个阶段的内容都已经明确定义、已经自动化，那么阶段之间的推进逻辑同样可以被自动化——用一个简单的循环反复运行提示，让代理自己一步步走完全程。

转折点：模型能力达到临界水平

作者坦言，在很长一段时间里使用 Claude Code 时，他都感觉自己"守在旁边其实没什么必要"，但又不敢完全放手。真正的转折发生在模型的能力终于强大到了一个临界点的时候。

Claude Code 是 Anthropic 推出的面向开发者的命令行AI编程工具，它允许开发者在终端中直接与Claude模型交互，让模型读取代码库、编辑文件、运行命令并调试错误。与IDE插件（如GitHub Copilot或Cursor）不同，Claude Code更强调代理式（agentic）的工作方式——模型不仅生成代码片段，还能自主规划文件修改、执行测试、处理错误反馈。所谓"临界点"，指的是模型从"偶尔犯错需要频繁纠正"进化到"大多数情况下能独立完成明确定义的子任务"的能力跃迁。这个转变并非线性的，而是在模型规模、训练数据质量和后训练对齐（RLHF/Constitutional AI）达到某个阈值后突然显现的涌现能力（emergent capability）。

此时，你真的可以把这些定义清晰的任务派发给代理去独立完成，而且它们能做得非常出色。这不再是一个理论上的可能，而是一个已经成熟的工程实践。

启发作者做出这一判断的，是 Jeffrey Huntley 关于 Ralph Wiggum 的文章。Huntley 是AI辅助开发领域的知名实践者，他提出的 Ralph Wiggum 方法以《辛普森一家》中那个天真的角色命名，暗喻这种方法的"愚蠢般的简单"。其核心思想是：不需要复杂的编排框架或多代理协调系统，仅用一个 bash 脚本中的 for 循环反复调用同一个代理提示，就能驱动分阶段的复杂任务执行。这个发现之所以重要，是因为它打破了业界对AI代理框架（如LangChain、AutoGPT、CrewAI等）的过度依赖——这些框架引入了大量抽象层和复杂性，但真正的自动化瓶颈往往不在编排逻辑的复杂度，而在于每个阶段的任务定义是否足够清晰。

什么是AFK Agent？

作者起初采用了 Ralph 的方法，但在实践中逐渐偏离了最初的愿景，形成了自己的一套模式，他将其命名为 AFK Agent。

AFK的含义

AFK 是 "Away From Keyboard"（离开键盘）的缩写，这个术语最早流行于网络游戏和在线聊天社区，用来告知他人自己暂时不在电脑前。顾名思义，AFK Agent 就是那些可以在你离开键盘时持续运行的AI代理。

它的核心价值在于"委托"：你可以把大量工作交给这些代理，让它们在你忙碌于其他事情时自主生成一堆代码。而另一边，你可以：

• 规划未来的工作任务
• 检查其他代理已经完成的运行结果
• 处理更需要人类判断的高价值决策

为什么说AFK Agent改变了游戏规则

作者用了"game-changer"（改变游戏规则）来形容这种模式带来的效率飞跃。传统模式下，一个工程师同一时间只能盯着一个代理；而在 AFK 模式下，人的角色从"操作员"转变为"调度者和审阅者"，可以并行推进多条工作线。

这种角色转变与DevOps运动中的演进高度相似。在DevOps出现之前，运维工程师需要手动执行部署脚本、逐台服务器配置环境；而CI/CD管道（如Jenkins、GitHub Actions）将这些重复操作自动化后，运维的角色转变为编写管道配置和监控异常。AFK Agent对编程工程师角色的重塑遵循了同样的逻辑：工程师的价值不再体现在"看着代码一行行生成"上，而是体现在三个更高层次的活动中——任务分解的质量（决定代理能否独立完成）、验证标准的设计（决定输出是否可信）、以及异常情况的处理（当代理偏离预期时的介入策略）。这本质上是将软件开发从"手工作坊"推向"工业流水线"的又一次范式变革。

这本质上是一种从人力密集型到自动化编排的范式转移。当模型足够可靠、任务足够明确时，人为什么还要充当那个廉价的"for 循环执行器"呢？

实现AFK执行的前提条件

说个细节，AFK Agent 并不是一个孤立的技巧，而是一整套方法论的收敛点。作者强调，从反馈循环（Feedback Loops）、到计划（Plans）、规格说明（Specs），再到**追踪子弹（Tracer Bullets）**所学到的一切，最终都汇聚到了让多阶段计划实现 AFK 执行这个目标上。

其中，追踪子弹是一个源自《程序员修炼之道》（The Pragmatic Programmer）的经典概念。在军事中，追踪子弹（曳光弹）会在飞行轨迹上发光，让射手能实时看到弹道并调整瞄准方向。在软件工程中，追踪子弹指的是一种端到端的最小可行实现——它贯穿系统的所有层（从UI到数据库），虽然功能极简，但能验证整个技术栈的连通性。在AI编程的语境下，追踪子弹被用来在正式的多阶段执行之前，先用一个最小任务验证代理是否能正确理解需求、生成可编译的代码、通过基本测试。这种"先打一发看看弹着点"的做法，大幅降低了在无人值守的AFK模式下代理走偏后造成大量返工的风险。

换句话说，前面所有关于结构化、可验证、可追踪的工作，都是为了让代理能够在无人值守的情况下稳定地完成任务。只有当任务被拆解得足够清晰、验证机制足够完善时，把它交给 for 循环自动执行才是安全的。

反馈循环在此扮演了同样关键的角色：每个阶段结束后，代理需要能够自动验证自己的输出（例如运行单元测试、检查类型错误、验证构建是否成功），而不是依赖人类来判断"这一步做对了没有"。这些自动化的验证机制构成了AFK模式的安全网——没有它们，无人值守的执行就如同蒙眼开车。

结语：迈向真正的自主编码

AFK Agent 代表了AI编程实践中的一个重要演进方向。它建立在两个前提之上：一是模型能力达到了可托付明确任务的水平；二是工程师已经掌握了把复杂工作分解为清晰阶段的方法论。

当这两者结合，人类工程师终于可以从繁琐的"陪跑"中解放出来，把注意力投向真正需要创造力和判断力的地方。对于工程师而言，学会构建并信任 AFK Agent，或许正是下一阶段生产力跃迁的关键。

值得注意的是，AFK Agent 并不意味着人类工程师变得无关紧要——恰恰相反，它对工程师的能力提出了更高的要求。你需要具备更强的系统设计能力来拆分任务、更敏锐的质量判断力来审阅输出、更成熟的工程直觉来设计验证标准。从这个意义上说，AFK Agent 不是在取代工程师，而是在筛选工程师——那些能够驾驭自动化编排的人，将获得前所未有的生产力杠杆。

核心要点