01 触发事件

Lenny's Newsletter 这篇最新实操内容，核心不是模型发布，而是 Claire 用 Claude Code 和 Codex 演示了几类 AI agent loops：heartbeat、cron、webhook、goal-based loop，以及一个会继续派生 subagents 的 PR review loop 和 skills loop。

原文最值得记的一句，其实不是功能清单，而是这个判断：

A loop is just a prompt that fires itself, nothing more exotic than that.

这句话把整个 agent 叙事往下拽了一层。

不是“自治体”神话，不是 AGI 前夜，也不是某种只有 frontier lab 才能掌握的新 engineering discipline。它更接近一个被重新包装过的老概念：调度系统 + 状态检查 + LLM 作为执行器。

另一个值得抓住的点，是原文直接把成本问题拉到了台前。文中明确说，goal loop 如果 success criteria 模糊，就会“keep running and keep charging without meaningful progress”。这不是使用建议，这是产品边界。

我没在 Claude Code 或 Codex 内部跑过他们的 loop runtime，所以这点我可能误判；但从文章透露的信息看，至少在当前阶段，这场竞争还不是“谁更智能”，而是“谁更能让开发者把自动化任务写成可控的 token burn”。

02 这事的真正含义

这事表面上看，是 Claude Code 和 Codex 都在教用户如何写 loop。

真正的含义是：AI coding tool 的竞争，正在从单次交互式 completion，转向持续运行的任务系统。

这才是它在说的事。

过去一代 coding assistant 的基本单位是 request-response：你提一个问题，模型吐一个答案，session 结束。即便有长上下文、diff edit、terminal 调用，本质还是人驱动的同步式工作流。

loop 把单位换掉了。

新的基本单位，不再是“一个 prompt”，而是“一个可持续触发、可验证终止、可派生子任务的 job”。一旦单位从 prompt 变成 job，产品竞争的关键指标也会改：

  • 不只是模型质量，而是 validation 设计
  • 不只是响应速度，而是 runtime observability
  • 不只是 context window，而是长期任务的 state management
  • 不只是 token 单价，而是单位有效结果成本

这里最关键的，不是 loop 会不会写，而是谁来承担“定义完成”的责任。

goal-based loop 听上去强大，但它天然有一个结构性问题：模型很擅长生成行动，没那么擅长定义严格 completion boundary。原文给出的建议是“让 Codex 写自己的 goals，参考 OpenAI 的 guide”。这很实用，但也暴露出一个尴尬现实：如果用户连任务完成条件都要交给模型来写，那么真正被定价的商品就不是 inference，而是“可验证任务规范”。

这会把 developer tools 往更像 workflow software 的方向推。

Claude Code、Codex、Cursor、Cline 这类产品，下一阶段 moat 不一定来自最强基模，而可能来自三个层面：

  • loop 模板库
  • 与 repo / CI / Slack / issue tracker 的深集成
  • 对 runaway token cost 的 guardrail

我没拿到这些产品在真实企业环境里的 retention 数据，所以这点我可能看得偏早；但如果 loop 成为主流交互范式，那么“能写代码”会迅速商品化，“能把自动化任务安全跑起来”才开始有 switching cost。

03 历史类比 / 结构对照

更合适的类比，不是 2022 年 ChatGPT，而是 2014 年前后的 AWS。

为什么。

因为当年真正改变开发范式的，不是“服务器可以租”这个事实本身，而是 cloud 把一堆已有能力——计算、存储、队列、调度、监控——打包成默认可调用的 primitives。开发者不再从零搭基础设施，而是组合 primitives 去交付业务。

agent loop 现在像极了那个阶段。

heartbeat、cron、webhook，本来就是老 primitives。文章自己也承认这一点：新东西不是调度，而是把调度目标从 batch job 换成 AI agent。换句话说，今天的 Claude Code 和 Codex，正在尝试把 AI 执行器接到传统 automation stack 上，再提供一层 prompt-native orchestration。

这和早年 cloud 的路径几乎一致：不是发明新计算，而是把旧计算重新产品化。

这里还有一个更值得警惕的结构对照：当基础能力被封装得足够简单时，应用层会先爆发，随后成本与治理问题集中反噬。

AWS 时代的问题是：

  • resource sprawl
  • 权限边界失控
  • bill shock

agent loop 时代的问题会变成：

  • subagent sprawl
  • success criteria 漂移
  • token bill shock
  • 难以审计的自动决策链

原文里最重要的产品洞察，其实是这一句：

The power move is loops that generate their own subagent loops.

这听起来很强，但也最危险。

因为一旦允许 loop 递归地产生 loop，成本结构就不再线性。builder 以为自己买的是一个 assistant，最后得到的可能是一套不停自我扩张的任务树。这个时候，真正的 infra 需求不是更大的 context，而是更严格的 budget、rate limit、termination policy 和 execution logs。

我没见到文中 demo 的完整计费结果，所以这点我可能说得比实际更重；但历史上所有“组合后威力更大”的 primitives，都会在某个时刻从生产力工具变成成本黑洞。agent loop 不会例外。

04 对 AI builder 意味着什么

对 builder 来说，这周和这个月要改的，不是“马上做一个 agent 产品”，而是先把任务系统的抽象层重写。

第一，别把 loop 当功能，把它当成本中心。

任何 loop 都应该先有三组约束：

  • 触发频率
  • 成功判定
  • 最大 token / 最大运行轮次 / 最大 wall-clock time

没有这三组约束，goal loop 不是 automation，是失控支出。

第二，优先做“高验证性任务”，不要先做“高想象空间任务”。

文章里的 PR review、skills gap identification、morning briefing 之所以适合 demo，不是因为它们酷，而是因为它们天然有外部 state 可核验：PR checks 是否通过、日历是否存在、邮件是否已发送。这类任务更容易建立闭环。

真正应该先上的 loop 类型包括：

  • PR merge readiness 检查
  • support triage
  • ticket 分类与补全
  • 每日 brief
  • repo hygiene 检查
  • 文档同步

不应该先上的，是那种“持续优化某个战略目标”的模糊任务。那类任务最容易无限循环。

第三，subagent 不是魔法，是并发预算分配。

如果你的产品要支持 subagents，不要只暴露“spawn agent”按钮。至少要同时暴露：

  • parent-child execution graph
  • 每个 subagent 的 token 消耗
  • stop / retry / escalate policy
  • 输出合并规则

问题不在于能不能生成更多 agents，而在于开发者能否读懂系统为什么花了这些 token。

第四，工具选型上，开始比较 runtime，而不是只比较模型。

接下来评估 Claude Code、Codex、Cursor、Cline，不能只看：

  • 代码补全质量
  • benchmark 分数
  • 支持哪些模型

还要看：

  • loop 调度能力
  • hook / webhook 接入
  • approval gating
  • execution trace
  • 和 GitHub / Slack / CI 的连接深度

这决定的是能不能进入团队工作流，而不只是个人 IDE 玩具。

第五，如果你卖 API access 或 routing，机会点会出现在“长任务的模型编排”。

因为 loop 的不同阶段不需要同一种模型：

  • planner 用强模型
  • 执行用便宜模型
  • validator 用稳定模型
  • summarizer 用小模型

这意味着 model routing 不再只是单轮请求优化，而是 job graph 优化。那个真正会被定价的，是“每完成一个任务要烧多少 token”，不是“每百万 token 多便宜”。

我没在生产环境里验证所有这类拆分都成立，所以这点我可能高估了 routing 收益；但对 token 网关、agent infra、observability 产品来说，这几乎是最直接的新需求入口。

05 反方观点 / 风险

我上面的判断，最大的风险在于：也许 loop 根本不是一个足够大的产品分层，只是 demo 友好的包装层。

换句话说，也许这整件事没那么深。

第一种反驳是，heartbeat、cron、webhook 本来就在，开发者完全可以用现有 workflow 工具加 API 拼出来。那 Claude Code 和 Codex 的“loop engineering”价值，可能只是教育市场，而不是形成 moat。要是真这样，最终吃掉价值的不会是 IDE 工具，而是 GitHub Actions、Zapier、Temporal、Airflow 这类现有 orchestration 层，再外接模型 API。

第二种反驳是，文章本身偏 beginner-friendly，展示的是可讲清楚的 use case，不代表真实团队会把关键流程交给 loop。企业最怕的不是能力不够，而是责任不清。subagent 带来的不是生产率想象，而是审计 nightmare。只要 security、compliance、repo governance 没跟上，很多团队宁可停留在人类审批为主的 copilot 阶段。

第三种反驳是，模型成本也许下降得足够快，导致“loop 失控 burn token”这件事不再构成主要摩擦。如果 inference 单价持续下行，那 runtime governance 可能不会成为核心卖点，大家最后还是回到谁的模型更好、分发更强。这个判断我可能低估了供给侧降价速度。

第四种反驳更直接：loop 可能不会成为主交互范式，只会停留在 power user 工具箱里。多数开发者真正需要的，仍然是一个足够聪明的同步 assistant，而不是一个会自己排班、自己派生 subagent 的系统。如果 adoption 最终停在少数高技术团队，那它就更像高阶 feature，不是市场重构。

所以，我不会把这篇文章看成“agent 时代已经到来”的证据。

但我会把它看成另一个更重要的信号：developer tooling 竞争，已经开始从“聊天框里的模型能力”，转向“任务系统里的执行纪律”。

前者决定 demo 能不能出圈。

后者决定账单出来以后，用户会不会续费。