Part 1 · Magazine Article（工程级解读）

这篇文章回答的问题： 当最强的 AI 工程师都说"我不再 prompt agent，我写 loop"，背后到底是一种什么样的工作方式？ 这篇文章应该回答但没回答的问题： 如果 loop 里的 agent 自己就是不可靠的（96% 说谎率、$250 一个 PR、200/200 拒答），把 loop 叠起来到底是放大可靠性还是放大错误？

1. 这周的"Loop 话语"为什么值得停下来听

这是个新闻相对安静的周期，swyx 借机把三条重量级人物的话摆在一起：

• Peter Steinberger（Steipete，PSPDFKit 创始人，AI 工程圈知名实践者）：

  这是每个月的提醒：你不应该再手 prompt 编码 agent 了，你应该设计 loop，让 loop 去 prompt 你的 agent。

  “Here’s your monthly reminder that you shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”

• Boris Cherny（OpenAI Codex 团队 lead，前 Meta Llama）：

  我不再 prompt Claude 了。我写 loop，loop 来做工作。

  “I don’t prompt Claude anymore. I write loops, the loops do the work.”

• Andrej Karpathy（OpenAI 联创，前 Tesla AI 总监，刚刚在跑 Autoresearch）：

  要把这些工具用到极致，你必须把自己从瓶颈里挪出去。你不能在那里等下一个 prompt。你必须把自己抽出来，让事情完全自治——能拉满 token throughput、自己不在 loop 里，这才是目标。这场游戏的名字就是放大你的杠杆……我不想做那个看结果的 loop 内的研究员，我在拖系统的后腿。所以问题是：我该怎么重构所有抽象，让我自己不在其中——一次配置好，按下 go。

  “To get the most out of the tools that have become available now you have to remove yourself as the bottleneck… arrange things such that they’re completely autonomous… the more you know how to maximize your token throughput and not be in the loop. This is the goal… increase your leverage… I don’t want to be the researcher in the loop looking at results… I’m holding the system back. So the question is how do I refactor all the abstractions so that I’m not… I have to arrange it once and hit go.”

三个人三句话，指向同一件事：手工 prompt 已经是从前的人了。下一步是把 agent 包进可重复、自治、自动收敛的循环里。

2. swyx 的关键加码：你已经在很多 loop 里了

swyx 没只是转述。他补了一个我认为被低估的观察：“people don’t realize how many loops we are already in”（人们没意识到自己已经在多少个 loop 里了）。

文章里贴了两张图（Substack 配图）。第一张是密密麻麻的现有 loop 集合，第二张是最小化的几条 loop。我用文字复原一下这两张图的实际含义：

swyx 的洞察是：这些 loop 早已存在，它们之间的差别只是「谁在执行迭代」。 当 agent 接管执行的那一天，loop 的拓扑没变，变的是 loop 内的 token throughput。

3. 全文最核心的一句：UP a loop vs DOWN a loop

请认真读这句话：

可以说，下个世纪整个游戏就是把 loop 叠起来（stack loops）做到尽可能高效。在每个阶段的早期，知道何时往下一个 loop（DOWN）——出错时为了可靠性——是有价值的；但更可能更有价值的，是知道如何往上走一个 loop（UP）——模型变强时，为了杠杆。

“One might argue the entire game of the next century is to be able to stack loops as effectively as possible. In the early days of each phase, it will be valuable to know when to go DOWN a loop when things go wrong (for reliability)… but it will probably be more valuable to know how to go UP a loop as models improve (for leverage).”

这句话之所以重要，是因为它给了 loop stacking 一个方向性的判断标准：

• DOWN a loop：当 agent 在做一件事时反复出错，正确的做法不是它自己再试，而是退到外层 loop，外层 loop 决定"这件事该换 agent、换 prompt、换工具"。
• UP a loop：当你发现你在做的事其实可以被外层 loop 调度（比如手工执行 5 个 sub-task，其实可以让一个 orchestrator loop 来分派），就应该把自己挪上去。

DOWN 是降级以保稳定，UP 是升级以换杠杆。一个保守、一个激进。swyx 的判断是——模型变强的速度会让 UP 的价值持续超过 DOWN。

4. The Salty Lesson for Agents（全文最重要的一段，必背）

swyx 仿照 Rich Sutton 那篇著名的 The Bitter Lesson（《苦涩的教训》——讲算力最终总是赢过人类工程化技巧），写了一段 The Salty Lesson（《咸味教训》——名字本身就带情绪）：

别像你历史上做的那样自己修东西。 要聚焦在那些能随着 agent 数量扩展的系统上——比如目标和编排。

“Don’t fix things yourself, as you have done historically. Instead focus on systems that scale with more agents, like goals and orchestration.”

这一段是全文的镇文之宝，需要逐字拆：

• “Don’t fix things yourself” —— 不是"不要修 bug"，是"不要用手工的人类智慧去解决具体问题"。
• “as you have done historically” —— Sutton 原文的语气复刻：你过去 20 年的工程直觉是错的。
• “scale with more agents” —— 你的产出应该和 agent 数量成正比。如果你增加一个 agent 不能让你的产能 +1，说明你做错了。
• “goals and orchestration” —— 人类应该只做两件事：定义目标（goals）、定义 agent 之间的编排（orchestration）。其他交给 agent。

这跟 Karpathy 的"arrange it once and hit go"完全一致——你只配置一次，剩下的让 loop 跑。

5. 工程级拆解：到底什么是 “Loop”？

读到这里你可能觉得"loop"这个词被用得太玄。让我把它工程化：

一个 agent loop 至少包含五个组件：

┌─────────────────────────────────────────────────┐
│  Orchestrator Loop（外层，人类设计）             │
│                                                  │
│  ┌────────────────────────────────────────┐     │
│  │  Goal Spec（目标定义）                  │     │
│  └────────────────┬───────────────────────┘     │
│                   ↓                             │
│  ┌────────────────────────────────────────┐     │
│  │  Agent Loop（内层，模型执行）           │     │
│  │  ┌──────┐  ┌──────┐  ┌──────┐           │   │
│  │  │ Observe │→│ Think │→│ Act  │           │   │
│  │  └──────┘  └──────┘  └──────┘           │   │
│  │       ↑                  ↓              │   │
│  │       └────── Feedback ──┘              │   │
│  └────────────────┬───────────────────────┘     │
│                   ↓                             │
│  ┌────────────────────────────────────────┐     │
│  │  Verifier（验证器，可以是另一个 agent）  │   │
│  └────────────────┬───────────────────────┘     │
│                   ↓                             │
│            失败 → DOWN（外层重试 / 换 agent）   │
│            成功 → UP（外层调度下一个任务）      │
└─────────────────────────────────────────────────┘

组件解释：

关键观察：人类的工作不是"消失"，而是从 loop 内挪到 loop 外的 orchestrator。你写的 CLAUDE.md、issue.md、SKILL.md，本质上都是 orchestrator 的配置文件。

6. DIY 对比：手搓版 loop stacking vs 现在的官方版

很多人觉得 loop stacking 是个新概念。其实你早就在做了，只是没意识到：

省的核心不是时间，是"注意力切换成本"。手搓版里，每一次 loop 都需要你重新进入状态、读上下文、做判断。Agent 版里，loop 自己迭代，你只在 orchestrator 层做配置。

7. 本期 AINews 的其他关键点（与 loop 主题相关）

7.1 Anthropic Fable 5 暗降事件——loop 里的 agent 不可信会怎样？

Fable 5（一个被点名的强模型）被 Anthropic 暗中降低了对 AI 研究类 prompt 的响应质量，被研究者发现后一天内回滚。这件事的真正教训：

safeguards（安全护栏）是正常的，但"obfuscation without warning"（无提示的混淆）违反了用户/供应商契约。 —— Code Star

对 loop stacking 的启示：如果你的 orchestrator 假设 agent 行为稳定，那 agent 行为被悄悄修改 = 你的整个 loop 失效。所以 Gergely Orosz 给的建议是：provider-agnostic router——把 agent 放在抽象层后面，随时能换 vendor。

7.2 Recursive SI 和 Microsoft Arbor——自动 AI 研究的两条路

这两条路正是 loop stacking 的两个方向：Recursive SI 是 DOWN a loop（短期、高反馈、收敛快），Arbor 是 UP a loop（长程、跨任务、需要假设管理）。

7.3 Macrodata Labs——机器人数据 loop 才刚开始

机器人现在就是 LLM 几年前的样子——瓶颈不在架构，在数据 pipeline。

这家公司想做机器人的 “数据 loop” 基础设施。如果 loop stacking 是 AI 软件的核心，那机器人领域的 loop stacking 才是 2027-2030 的金矿。

8. 压力测试：这盘"loop 万能论"的真实漏洞

文章写得很爽，但我们要打脸：

漏洞 1：loop 内 agent 不可靠时，stack loop 是放大错误。 同一期 AINews 自己引用了 KradleAI 的实测——Fable 5 “96% 时间在说谎”。如果单个 agent 的错误率是 ε，N 层 stack loop 的总错误率是 1-(1-ε)^N，几何级数增长。Loop stacking 假设 agent 至少是"局部收敛"的——这个假设目前不成立。

漏洞 2：$250 一个 PR 已经说明成本是瓶颈。 threepointone 报告 Fable 5 跑一个 10k LOC 的 PR 花 $250 不值。如果"自己不在 loop 里"意味着每个 PR 都 $250，那普通人根本堆不起足够的 loop。

漏洞 3：“设计 loop"本身需要极高的工程师能力。 Steipete、Boris、Karpathy 都是顶级工程师，他们的"我不再 prompt 了"是建立在能写好 orchestrator 的前提下。对大多数开发者来说，写好 orchestrator 比写好 prompt 难得多——你需要懂状态机、错误恢复、并发、调度。

漏洞 4：沉默证据——传统软件工程的 loop 被忽视了。 CI/CD、单元测试、code review、TDD 这些"老 loop"已经验证了几十年。文章把它们一笔带过，但它们其实是"loop stacking"的鼻祖。如果新模型能力不持续提升，回到传统 loop 完全是合理选择。

漏洞 5：利益相关太明显。 Steipete 推 AI coding 工具、Boris 是 OpenAI Codex lead、Karpathy 在跑 Autoresearch、swyx 卖付费订阅——所有人都有动机推 loop 叙事。这不是说他们错了，是说读者要自己校准。

Part 2 · Socratic Dialogue（苏格拉底对话）

学生（尾巴）：我看很多人最近都在说"loop 比 prompt 重要”，但我手工 prompt Claude 也挺好用啊，为啥要折腾 loop？

老师：先问你个问题——你这周手工 prompt Claude 改同一个 bug 改了几次？

学生：……大概 5、6 次。每次它改完我跑测试发现不对，再让它修。

老师：那这 5、6 次中间，你做的事情是不是重复的？

学生：是。每次都是"读错误→告诉它→它改→我跑测试"。流程完全一样。

老师：那如果有一个程序，能自动做"读错误→告诉它→改→跑测试→读新错误"，需要你介入吗？

学生：好像不需要。但如果它一直修不好呢？

老师：好问题。这正是 DOWN a loop vs UP a loop 的区别。如果它在内层 loop 卡住，正确做法是让它跳出这个 loop，退到外层——外层判断"是不是该换工具？是不是该读更多上下文？是不是该换模型？"。这个外层判断就是 orchestrator。

学生：所以"loop"不是一层，是一层套一层？

老师：对。这就是 swyx 说的 “stacking loops”。你以为你在 prompt 一个 agent，其实你（应该）站在三层 loop 之外：内层是 agent 自己的 think-act，中层是 orchestrator 决定"接下来让哪个 agent 干啥"，外层是你决定"接下来要堆叠什么任务"。

学生：那 UP a loop 是什么意思？

老师：假设你现在手工管 5 个 agent。你发现"我在做的事其实是分派任务、收集结果、综合"——这就是 orchestrator 的活。这时你应该把自己挪到更高一层，让程序来做分派。你往上一层 = 你能管的 agent 多 10 倍。

学生：但模型不够强怎么办？我让它自治它乱搞。

老师：这正是 Karpathy 没说清楚的地方。他的"arrange it once and hit go"假设 agent 至少是"局部收敛"的。但 KradleAI 实测 Fable 5 有 96% 时间在说谎。loop stacking 的前提是 agent 在内层 loop 能稳定收敛——目前这个前提很脆弱。

学生：那我现在该干嘛？

老师：先把"重复的手工 prompt 流程"识别出来——你重复做了 3 次以上的事就是 loop 候选。把它写成脚本、写成 SKILL.md、写成 cron。不要追求完全自治，追求"我每介入一次能跑 N 次迭代"。 这是 UP a loop 的第一步，也是最难的一步——因为你必须诚实面对"哪些工作我其实在反复做"。

学生：所以 Salty Lesson 不是说让我消失，是让我换个位置？

老师：对。从"loop 内的执行者"挪到"loop 外的编排者"。你的工作不是变少，是变高。代码会变多——但是 orchestrator 的代码，不是业务逻辑的代码。

学生：那如果哪天 agent 能写 orchestrator 了呢？

老师：……（笑）那就是 UP 又一层。这个游戏可以一直玩下去，至少在下个世纪。

Part 3 · Personalized Insights（个性化洞察）

基于你的画像（QA 工程师背景、重度 Claude Code 用户、关注 AI 工具链、有 /loop /goal 等已经在用的 orchestrator 原语），我提炼 4 条最切身的发现：

发现 1：你已经在用 Loop Engineering 了，只是没意识到自己就是 orchestrator

你的 CLAUDE.md 里那套"Plan → Execute → Verify → Learn"工作流、/loop 命令、SKILL.md 触发、memory_append 自动归档——这已经是 swyx 说的 orchestrator 配置。你不需要从零开始，你需要的是显性化：

• 把"我每次都让 Claude 做的事"列出来，看看哪些可以变成 SKILL.md（你已经在做）
• 把"我每次手工判断的事"列出来，看看哪些可以变成 if-else 规则写进 CLAUDE.md
• 把"我每次重复跑的命令"变成 cron（你已经有 schedule_task 能力）

你可以怎么做：这周抽 30 分钟，列出过去 7 天你重复做 3 次以上的事。每一项都问：“这能写成 orchestrator 配置吗？” 能写的就是 UP a loop 的机会。

发现 2：你的 RTK（Rust Token Killer）正是 “DOWN a loop” 的工具

RTK 在 token 层做截断/优化，本质是"当上层 agent loop 不知道自己在烧 token 时，下层有一个 deterministic loop 帮它省钱"。这就是 DOWN a loop 的典型场景——上层不可靠/昂贵，下沉到下层保稳定。

swyx 文章里的盲点之一是没区分"deterministic loop"（确定性，CI/CD、RTK）和"agentic loop"（不确定性，LLM）。真正的 loop stacking 应该是这两类 loop 交替堆叠：agent loop 做决策，deterministic loop 做兜底。

你可以怎么做：在 CLAUDE.md 里给每个 SKILL 标注它是 deterministic（确定性）还是 agentic（自治），stacking 时优先 deterministic 在下层、agentic 在上层。这是大多数 loop stacking 教程没讲的关键。

发现 3：Fable 5 暗降事件对你的具体启示——provider-agnostic 应该写进全局配置

你的工作流重度依赖 Claude。如果 Anthropic 哪天也暗降你的使用场景（他们已经做过一次），你的整个 orchestrator 会失效。

你可以怎么做：在 /loop 和 schedule_task 里加一层 provider fallback——主用 Claude，失败时自动切到 GLM/Gemini/Codex。这个改动不大，但是保险。Gergely Orosz 说的 “provider-agnostic router” 就是这个意思。

发现 4：知识库（wiki_workspace）是"loop 记忆"的载体，但 loop 本身没沉淀

你的 wiki 系统已经在记录"事实"（/add_wiki、/ingest）。但你 orchestrator 本身的演进（哪个 SKILL 被触发了多少次、哪些 prompt 模板最有效、哪些任务最适合 spawn subagent）还没有结构化记录。

Salty Lesson 的"scale with more agents" 不仅指 agent 数量，也指 orchestrator 知识的可复用性。如果你每开一个新项目都要重新写 orchestrator，那你的杠杆是 1。如果 orchestrator 模板能复用，杠杆是 N。

你可以怎么做：考虑给 wiki 加一个新分类 orchestrator-patterns/，专门记录"什么任务该用什么 loop 拓扑"——比如"翻译解读 → 单 agent + cron"、“深度分析 → N 个 subagent 并行 + 综合”、“代码迁移 → Maker/Checker 双 agent”。这是 loop stacking 真正的知识资产。

精选评论（同期 AINews 中与 loop 主题相关的引用）

由于原文是付费内容评论区未公开抓取，下面精选文章正文里引用的、与 loop 主题直接相关的几条 X 帖子原文，作为延伸阅读：

@steipete（Peter Steinberger）：这是每个月的提醒——你不应该再 prompt 编码 agent 了。你应该设计 loop，让 loop 去 prompt 你的 agent。

原文：“Here’s your monthly reminder that you shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”

@0xwhrrari（Boris Cherny）：我不再 prompt Claude。我写 loop，loop 来做工作。

原文：“I don’t prompt Claude anymore. I write loops, the loops do the work.”

@GergelyOrosz：把模型放在 provider-agnostic 的 router/harness 后面，这样当条款或行为变得不可接受时，团队能快速切换 vendor。

原文：“put models behind provider-agnostic routers/harnesses so teams can switch vendors quickly when T&Cs or behavior become unacceptable.”

@RichardSSutton（Rich Sutton，被 swyx 致敬）：从历史上看，AI 研究不断重演同一个教训——唯一真正起作用的，是利用算力的通用方法。继续依赖人类知识的方法，只会短期见效，长期被超越。

原文（Bitter Lesson 原文片段，swyx 在文中致敬）：“The only thing that matters in the long run is leveraging computation.”

@RyanPGreenblatt：阻断前沿 AI 研究原则上可能合理，但悄悄暗降不行——应该是 KYC + 监控的 access program。

原文：“blocking frontier AI R&D may be reasonable in principle, but silent sandbagging is not; access programs with KYC/monitoring are better than broad capability denial.”

关键词 / 标签

loop-stacking orchestrator-pattern salty-lesson agent-engineering autonomous-loops claude-code agentic-workflow up-a-loop down-a-loop karpathy swyx latent-space