AI Agent循环实战：睡一觉自动合并四个PR

从手动提示到自动循环：编程范式的又一次跃迁

如果你还在一条一条地给AI编程助手写提示词，然后手动复制粘贴结果到代码库里，那你可能已经落后了。知名开发者Theo（t3.gg创始人）在最新视频中分享了他从"手动提示"到"构建Agent循环"的转变历程——让AI Agent自己提示自己，自己审查自己，自己推进整个工作流。

这不是科幻，这是他正在日常使用的工作方式。而且效果出奇地好。

什么是Agent循环？为什么它比手动提示强？

过去我们使用AI编程的典型流程是：让模型制定计划→阅读计划→逐步执行→让另一个Agent审查→把反馈带回第一个Agent。整个过程中，人类是循环的驱动者。你负责在各个环节之间传递上下文，确保每个Agent都有足够的信息。

这种模式本质上仍然是传统提示工程（Prompt Engineering）的延伸——一种人机交互的多轮对话模式，人类始终扮演"调度员"角色。而Agent循环（Agentic Loop）则借鉴了自动化编排（Orchestration）的思想，让AI系统具备自主规划、执行、评估和迭代的能力。这一概念与软件工程中的CI/CD（持续集成/持续部署）流水线有异曲同工之妙——只不过流水线中的每个节点不再是预定义的脚本，而是具备推理能力的AI Agent。

Theo坦言，他之前也是这样工作的。虽然他早就见过Ralph Loop之类的自动循环方案，但那些方案大幅增加了错误率，看起来很酷却不够实用。

真正让他改变想法的是Pete的一条推文："告诉Codex维护你的仓库。每五分钟唤醒一次，把工作分配到不同线程。"关键洞察在于——Codex的一个线程可以启动另一个线程。这意味着Agent可以自己编排并行工作。

这里的Codex指的是OpenAI的云端Agent产品（而非早期的代码补全模型），它支持多线程并发执行。每个线程本质上是一个独立的沙箱环境，拥有自己的文件系统快照和执行上下文。关键的技术突破在于线程间的通信能力——一个线程可以通过API调用或工具使用来启动另一个线程，并传递必要的上下文信息。这类似于操作系统中的进程fork机制，但运行的不是确定性程序，而是具备推理能力的AI Agent。这种架构使得一个"协调者"Agent可以将大任务拆分为多个子任务，分配给不同线程并行执行，最后汇总结果。

Theo特别强调，那种预定义各种"角色人设"（安全审查员、对抗性审查员、探索Agent等）的做法是错误的。AI的核心优势在于动态性——Agent可以根据需要自行构建上下文和工作方式，不需要预先硬编码一切。这就像给你一个项目模板，所有文件都已创建好，你只能在现有文件里编辑——这很蠢。

实战案例：一条消息触发四个PR自动合并

Theo分享了一个令人印象深刻的实战案例。他在重构Lakebed的隔离层时，Claude 5.5分析后指出数据架构有大量优化空间，包括依赖感知的失效机制、mutation合并、按应用的失效批处理等。

这里涉及的几个技术概念值得展开说明。"依赖感知的失效机制"（dependency-aware invalidation）是数据缓存层的核心策略，确保当底层数据变化时，所有依赖该数据的缓存条目都被正确失效，避免脏数据问题。"mutation合并"（mutation coalescing）则将多个写操作合并为一次批量操作以减少I/O开销和数据库压力。这些都是构建高性能数据层时必须精心设计的关键机制，通常需要资深工程师花费大量时间来规划和实现。

这显然不是一个PR能搞定的事。模型自己判断需要至少三个堆叠的PR（Stacked PRs），部分可以并行。堆叠PR是一种高级的代码审查策略，指的是将一个大型变更拆分为多个有依赖关系的Pull Request，按顺序排列成"栈"。每个PR只包含一个逻辑上独立的变更，但后续PR依赖于前序PR的代码。这种做法让代码审查更加聚焦和高效，审查者每次只需要理解一个较小的变更。

然后Theo发出了他称之为"对心理冲击最大的一条消息"：

他问Agent：能否创建一个工作流——

1. 启动新线程创建PR
2. PR提交后启动另一个线程审查
3. 让实现线程循环处理审查意见直到全部通过
4. 合并PR后自动触发下一个

Agent不仅理解了这个需求，还设计了一个心跳机制：每5-10分钟轮询一次，检测PR状态，创建审查线程，发送反馈，修复后重新审查，合并后拉取最新main分支再创建下一个工作树。

心跳机制（Heartbeat Mechanism）是分布式系统中的经典设计模式，最初用于检测集群中节点是否存活。在Agent循环的语境中，它被重新定义为一种轮询（Polling）策略：Agent每隔固定时间间隔主动检查外部状态的变化，比如PR是否有新的审查评论、CI流水线是否通过、代码是否已合并等。相比事件驱动（Event-driven）的Webhook方式，轮询虽然不够实时，但实现更简单且更具容错性——即使某次事件通知丢失，下一次轮询也能捕获状态变化。这种"唤醒-检查-行动-休眠"的循环模式，本质上就是一个简化版的事件循环（Event Loop）。

结果是：凌晨2:29启动，早上6:50完成。Theo睡了一觉醒来，发现四个堆叠的PR已经被充分审查并全部合并。

最疯狂的部分是——这不是一个硬编码的固定循环。这是一个动态生成的工作流，Agent的循环自己又创建了子循环，根据具体问题的需求量身定制。

你现在就能开始的Agent循环实践方法

Theo给出了一个非常实用的建议：观察你在Agent完成任务后做了什么，然后把这些步骤也交给Agent。

典型的开发工作流是：Agent写完代码→你运行开发服务器→检查是否正常→提交代码→推送并创建PR→等待代码审查→处理反馈→请团队审查→合并。

这里面每一步都可以让Agent来做：

• 告诉Agent完成后自己运行开发服务器验证
• 告诉Agent验证通过后自动提交并创建PR
• 告诉Agent监控PR评论并自动处理反馈
• 让Agent启动其他线程做独立代码审查

一个更犀利的观点是：我们看代码看得太早了。 如果你在另一个Agent审查之前就自己去读代码，你在浪费时间。那些明显的错误，Agent自己就能发现和修复。等人类介入时，所有低级问题都已经被清理干净，你可以专注于真正需要人类判断的困难部分。

Agent循环的成本与限制：没你想的那么贵

循环确实会消耗更多token。Theo提到一个极端案例：一个Agent花了不到10分钟留下反馈，而Opus工作流基于这些反馈运行了8小时，消耗了超过300万token——只是为了处理三条小评论。

要理解这个数字的含义：token是大语言模型计费的基本单位，大致相当于一个英文单词的3/4（中文则约1-2个字对应一个token）。300万token大约相当于处理了一本2000页技术书籍的文本量。按照Anthropic的API定价（Claude Opus约$15/百万输入token，$75/百万输出token），300万token的推理成本可能高达数百美元。这就是为什么计费方式的选择至关重要。

但如果你使用订阅制计划而非API计费，情况就完全不同了。Theo在$200/月的Claude Code计划上，即使同时运行五个这样的循环，加上其他所有工作，一周的额度也只用了29%。

他算了一笔账：6月份（仅17天）跨所有机器的推理用量约为10,000美元，但他只付了600美元的订阅费（三个$200计划）。这意味着每花1美元订阅费获得约17美元的推理价值。

这个17:1的价值比率揭示了一个重要的市场动态：AI公司目前在重度订阅用户身上可能是亏损运营的，通过补贴来培养用户习惯和锁定市场份额。这与早期云计算厂商（如AWS）的策略如出一辙——先用低于成本的价格获取用户，建立生态粘性，再逐步调整定价。对于开发者来说，这意味着当前是利用订阅制红利的最佳窗口期。

如果你已经在付费订阅但远没有用满额度，那就是在浪费钱。Theo的建议是：把这些限额当作挑战，尽量用满它。

循环的本质：让工作流的形状匹配问题的形状

Theo用了一个精彩的类比。在传统敏捷开发中，团队遵循固定的sprint结构——每周或每两周从backlog中拉取任务，估算工时，按优先级排列。工作被迫适应这个固定的形状。而最高效的团队，是那些围绕具体问题构建自己独特工作流的团队。

传统敏捷开发（Agile Development）框架如Scrum规定了固定的迭代周期（Sprint，通常为1-4周）、固定的仪式（每日站会、Sprint回顾、评审会议）和固定的角色（Scrum Master、Product Owner、开发团队）。这种结构化方法论在过去二十年极大地提升了软件开发效率，但其核心假设是人类开发者的认知带宽有限，需要通过流程来管理复杂性、减少沟通成本。AI Agent循环打破了这一假设——当执行者是不知疲倦、可无限并行的AI时，固定的迭代结构反而成为瓶颈。

AI Agent循环的真正魅力在于：工作流的形状可以根据问题的形状动态生成。 不是你去适应某个固定流程，而是流程自动适应你的问题。简单的bug修复可能只需要一个线性流程，而复杂的架构重构则可能自动生成包含并行分支、审查门控和回滚机制的复杂DAG（有向无环图）结构——所有这些都不需要人类预先设计。

这不仅限于代码。Theo甚至用类似的循环思维来监控5G热点的最佳方案，结果他的循环在Discord上随机提醒他Verizon刚推出的新套餐——比大多数人更早获得了这个信息。

写在最后

循环之所以强大，不是因为技术本身多炫，而是因为让Agent做更多事情这个理念具有巨大的杠杆效应。如果你从这篇文章中只带走一个行动项，那就是：下次Agent完成任务时，不要急着自己接手，先问它——"你能不能也把下一步做了？"

你可能会像Theo一样，对结果感到惊讶。