WTF Is a Loop? Peter Steinberger vs. Boris Cherny

作者：Matt Van Horn (@mvanhorn)

翻译

本周 AI 编程圈被引用最多的一句话只有六个单词，但几乎每个说这句话的人都无法定义它。一条推文本周让整个时间线陷入疯狂，所以我对所有人争论的这个词跑了 /last30days（最近30天搜索）。答案是真实的，它有五年的演进脉络，而最终的结论是：Loop（循环），而不是模型，现在是成本最高的部分。（The loop, not the model, is now the expensive part.）

让时间线疯狂的推文

一条推文本周让整个 AI 编程时间线为之着迷。Peter Steinberger 在6月7日发布了它，浏览量突破220万，评论区演变成了一场关于它到底意味着什么的混战。

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

“这是你每月的提醒：你不应该再手动 prompt（提示）编程 agent 了。你应该设计 loop 来 prompt 你的 agent。”

— @steipete，2026年6月7日

这就是所有人都在引用的那句话。最有说服力的回复来自 Varadh Jain，他问了唯一重要的问题：这在实践中是什么样的？而让整个氛围定调的回答来自 Matthew Berman。

“nobody knows but him and boris.”

“除了他和 Boris，没人知道。”

— @MatthewBerman，2026年6月7日

这才是真正的故事。不是 loop 是未来，而是一个六个词的短语获得了200万浏览量，而转发它的人在评论区争论它到底是什么意思。我没有翻白眼，因为我每天晚上都会运行一个 loop，在我睡觉的时候跨大约30个开源仓库提交 PR。90秒的研究搜出了15个 Reddit 帖子、21条 X 推文，以及一个令人不安的模式：AI 编程圈最响亮的想法，大多数重复它的人无法解释。一个阵营高喊 prompt engineering（提示工程）已死。另一个阵营——那些真正手放在键盘上的人——更加谨慎。

“It’s not ralph/goal loops, that’s old hat by now. It’s probably some kind of continuous orchestration loop that oversees other threads/agents.”

“这不是 ralph/goal loop，那已经是旧帽子了。这大概是某种持续编排循环，监督其他线程/agent。”

— @trashpandaemoji，2026年6月7日

这条回复是任何人贴出的最接近正确答案的东西。记住它。

Loop 到底是什么

Boris Cherny 在2024年9月作为副项目创建了 Claude Code。据报道，它现在支撑着 GitHub 上接近4%的所有公开提交。6月2日，在 WorkOS 主办的 Acquired Unplugged 活动上，他给出了关于 loop 最干净的定义。

“Now it’s actually leveled up, I think, again, to the next wave of abstraction where I don’t prompt Claude anymore. I have loops that are running. They’re the ones that are prompting Claude and figuring out what to do. My job is to write loops.”

“现在它又升级到了下一波抽象层次，我不再 prompt Claude 了。我有 loop 在运行。是它们在 prompt Claude 并决定该做什么。我的工作是写 loop。”

— Boris Cherny，WorkOS Acquired Unplugged，2026年6月2日

所以大白话版本是这样的：**Loop 是你写的一个小程序，它替你 prompt 编程 agent，读取它产出的内容，判断是否完成，如果没有，就再次 prompt 它。**你不再是循环里面那个打字输入 prompt 的人。你变成了 loop 的作者。模型变成了一个子程序。

Boris 把它分成三个阶段，把自己放在他的阶梯上是理解它的最快方式。一年前，他靠自动补全手写代码。然后他并行运行5到10个 Claude 会话，逐个 prompt。现在他完全不 prompt 了。他写的是 prompt Claude 的 loop，几百个 agent 读取他的 GitHub、Slack 和 Twitter，决定接下来构建什么。他有收据。

“In the last 30 days, 100% of my contributions to Claude Code were written by Claude Code. I landed 259 PRs.”

“过去30天，我对 Claude Code 的贡献100%由 Claude Code 编写。我合并了259个 PR。”

— Boris Cherny，via Simon Willison，2025年12月27日

他在11月删掉了 IDE，此后再也没打开过。prompt-engineering-is-dead（提示工程已死）阵营忽略的微妙之处：他不是说工程师被淘汰了。仍然需要有人决定构建什么、跟客户沟通、协调团队，而且他说优秀的工程师比以往任何时候都重要。工作没有消失。它上升了一个海拔——从写代码，变成了写那个写代码的东西。

光谱：从 ReAct 到编排

评论区一团糟，因为"loop"至少隐藏着五种不同的东西。这是阶梯，从最老到最新，让你别再跟人说交叉话了。

**第一阶段是学术界的 while 循环。**2022年的 ReAct 论文将其形式化：模型推理、调用工具、读取结果、重复直到完成。一个模型、一个循环、一个人在旁边看着。

第二阶段是2023年的 AutoGPT，它给了模型一个目标并让它自行 prompt，结果因无限空转什么都没做成而闻名。那次失败种下了数年"agent 是玩具"的论调。

第三阶段是 Trash Panda 所说的"旧帽子"：ralph loop，由 Geoffrey Huntley 在2025年7月发布。它简单得近乎侮辱人——一个 bash 单行命令，把同一个 prompt 文件反复喂给 agent。它真正的创新是纪律性：每次迭代都将上下文重置为一组固定的锚定文件，而不是让对话无限增长。Huntley 用它构建了一整门编程语言，花费大约297美元。

**第四阶段将其产品化：**2026年春季，Codex 和 Claude Code 都发布了 /goal 命令，运行 ralph loop 直到一个小型验证模型确认任务完成。

**第五阶段是 Boris 和 Steinberger 真正的意思，而且它确实是新的，不只是换了个名字。**四个东西变了。Loop 变成了工作单元，而不是任务。Loop 开始监督其他 Loop，并发地、按计划执行。调度取代了人工触发，所以 loop 运行在基础设施时间上而不是你的注意力上。持久性变得显式化——有 git 支撑的状态和崩溃恢复，因为这些东西必须能在重启后存活。Ralph 假设你的终端保持打开。2026年的版本假设它不会。所以 Trash Panda 对了两次：单 agent 的 ralph loop 是旧帽子，在它之上的多 agent 编排 loop 才是新东西。

它只是戴了顶帽子的 cron job

整个语料库中最棒的质疑线只有四个字，贴在某人热情洋溢地说"loop 是未来方向"的下面。

“Cronjobs have funny re-branding rn.”

“Cron job 现在有了好笑的新品牌名。”

— X 回复，loop 讨论，2026年6月

这值得一个直接的回答，而不是闪躲，因为它说对了一半。是的，调度层就是 cron。Boris 字面上就是用 cron 运行的。Claude Code 的 /loop 命令底层用的就是 cron。如果你对 loop 的全部定义就是"一个按时间运行的东西"，那么是的，我们在1975年就发明了它，你可以回家了。

**Cron 从来没有的是中间那个部分。**Cron job 运行一个固定脚本。Loop 运行一个模型——它审视当前状态，决定下一步做什么，执行它，检查是否成功，再决定是否继续。决策权在 agent 手里，不在你手里，也不在硬编码的分支里。把这些叠加起来，让一个 loop 调度和监督其他 loop，给它们持久的共享状态，你就有了 cron 无法表达的东西。诚实的框架不是说 loop 是新魔法，也不是说 loop 只是 cron。而是：loop 是 cron 加上一个决策者，而有趣的工程是你在那个决策周围包裹的所有东西——确保它不会跑下悬崖。

真正构建一个是什么样子

够了理论。入门只需一行。Claude Code 发布了 /loop，Boris 自己的示例就是经典的起步模板。粘贴这个，把名词换掉。

/loop babysit all my PRs. Auto-fix build issues, and when comments come in, use a worktree agent to fix them.

这是他更完整的配方。几天后，Boris 发布了五个运行 Opus 自主工作数小时或数天的建议。

**五条建议，用他的话说：**使用 auto 模式管理权限，让 Claude 不需要请求批准；使用动态工作流让 Claude 编排成百上千个 agent 来完成任务；使用 /goal 或 /loop 推动 Claude 持续工作直到完成；在云端运行 Claude Code，这样你可以合上笔记本电脑；确保 Claude 有端到端自检工作的方式。

— @bcherny，2026年6月

建议五是炒作方跳过、实践者痴迷的那个：一个 loop 的可信度取决于它检查自身工作的能力。

这就是整个思想的缩影。你没有写步骤。你写了意图和停止行为，loop 每次 tick 时 prompt agent。在 TikTok 上，这个概念对普通观众也讲得很清楚。

“Loop mode is one of the clearest signs that AI coding is moving from one-off prompts to background operations.”

“Loop 模式是 AI 编程从一次性 prompt 转向后台操作的最清晰信号之一。”

— @ai.native.founder 在 TikTok，2026年6月

深水区是 Steve Yegge 的 Gas Town，1月份发布：20到30个 Claude Code 实例由一个 Mayor agent 协调，配有巡逻 agent 运行持续循环，状态存储在 git 中确保工作能在崩溃后存活。这就是 Trash Panda 所触及的持续编排循环，已上线且开源。

但研究中最实际的教训是，一个 loop 的好坏只取决于它自检的能力。增长最快的子主题不是编排，而是验证。

“Your coding agent can move fast, but bad commits compound fast too.”

“你的编程 agent 可以跑得很快，但糟糕的 commit 也会加速复合。”

— @DanKornas，2026年6月

Kornas 正在发布 roborev，一个在后台审查每个 commit 并在上下文仍然新鲜时将发现反馈给 agent 的工具。一个没有反馈的开放循环写代码，就是一台生产自信错误的机器。一个写、运行、读取结果并纠正的循环，才是真正能工作的东西。Loop 不是魔法。里面的反馈才是。

剧情转折：Loop 现在是成本最高的部分

这就是研究从哲学转向财务问题的地方。对整个 agent 神话最尖锐的通缩来自一位在职工程师。

“Every ai agent i shipped this year is a for-loop, an llm call, and a try/catch around the json parsing. The only thing agentic about it is the anthropic bill at the end of the month.”

“今年我发布的每个 AI agent 都是一个 for 循环、一个 LLM 调用、和一个包在 JSON 解析外面的 try/catch。唯一’agentic’的地方就是月底的 Anthropic 账单。”

— @rohit_jsfreaky，2026年6月

那张账单不是开玩笑。本月的收据：Uber 在4个月内烧完了年度 AI 预算后，将工程师的 Claude Code 和 Cursor 使用限额设定为每人每工具每月1500美元。一旦模型几乎免费地写代码，成本就转移到了运行它的 loop 上。

“The costliest thing in AI coding is no longer writing code, it’s managing the agent loop.”

“AI 编程中成本最高的东西不再是写代码，而是管理 agent loop。”

— @runes_leo，2026年6月

而生产环境中所有人都害怕的失败模式是那个不停下来的 loop。

“Without guardrails, you get infinite loops and billing surprises orders of magnitude over budget.”

“没有护栏，你会得到无限循环和超出预算数个数量级的账单惊喜。”

— @cv_usk，2026年6月

这就是为什么2026年每一篇严肃的 loop 文章都收敛到同样的三个硬性停止条件：最大迭代次数限制、无进展检测、以及 token 或美元预算上限。Loop 的浪漫版本是你写了 loop，然后一千个 agent 一夜之间帮你建好公司。生产版本是你写了 loop，然后你的大部分工作是确保它们能停下来。Gartner 将 agentic AI 放在膨胀期望的峰值，只有大约17%的组织真正部署了 agent。时间线和收据之间的差距才是真实的状况。

不是 Loop。是 Skill。

这是我自己的看法，也是我观察了一周后的结论。Loop 是管道。它调用的 skill 才是资产。

Steinberger 的另一个反复出现的观点与 loop 那条配对，而且是更持久的另一半：**如果你做某件事超过一次，就把它变成一个自动化的 skill；如果你做了一件难事，事后把它变成 skill，这样下次就是免费的。**一个没有可复用 skill 的 loop 只是一个包在陌生人外面的 while-true。一个调用由锋利、经过测试、有命名的 skill 库的 loop，才是一个能复合增长的系统。

Reddit 上真正在实践的从业者说得最好。

“A lot of people are rolling their eyes on Twitter, but my ears are perked up.”

“很多人在 Twitter 上翻白眼，但我的耳朵竖起来了。”

— r/ChatGPTCoding，2026年6月

所以"WTF is a loop"的答案不是关于 prompt engineering 消亡的热门观点。它是这样的：**停止做循环里面的那个东西。写一次 loop，给它值得调用的 skill 和让它自检的反馈，给它上限让它能停下来，让它在 cron 上运行，你去决定下一步构建什么。**Steinberger 和 Boris 从两面描述着同一只动物。真正知道的唯一方法是，你已经构建过一个。好消息是，从本月开始，入门只需一个斜杠命令。

深度解读

这篇文章回答的问题： AI 编程中的"Loop"到底是什么？为什么一个六个词的短语能让200万人争论？

这篇文章应该回答但没回答的问题： Loop 在大规模生产环境中真正失败的模式是什么？有多少"成功的 loop"是幸存者偏差？

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

运行时模型：Loop 到底在跑什么

先别被"循环"这个词骗了。这个概念的核心不是循环本身，而是谁来决策。

传统编程的执行流是：人写代码 → 代码被运行 → 结果被验证。Loop 的执行流是：人写意图 → Loop 调用 LLM → LLM 看状态、决策、执行、验证 → 如果没完再来一次。

用系统架构的视角看：

关键洞察：**Loop 不是让 AI 更聪明，而是让 AI 更持久。**它解决的不是智能问题，而是耐力问题。

五阶段演进：一条清晰的抽象阶梯

文章把 Loop 的演进画成了五个阶段。但更有信息量的方式是看每阶段解决的核心矛盾：

这条演进线的趋势很明显：人一步步从循环中退出，但每退一步，就需要更多的工程来确保退出的安全性。

“The loop, not the model, is now the expensive part.”

“Loop，而不是模型，现在是成本最高的部分。”

— JimmyHsuBen (@JimmyHsuBen)，2026年6月

“Cron + 决策者"框架：理解 Loop 最实用的心智模型

文章中最重要的反驳不是来自支持者，而是来自质疑者：“Cron job 现在有了好笑的新品牌名。”

这个质疑的核心是对的：**调度层确实就是 cron。**但 cron 做不了的事是中间那个"看一眼当前状态，判断该干什么"的环节。这是 Loop 区别于传统自动化的根本所在。

用一个更精确的类比：Loop = Cron + State Machine（状态机）+ LLM as Policy（大模型做策略）。

• Cron：决定"什么时候跑”
• State Machine：决定"跑到哪了、下一步去哪"
• LLM as Policy：决定"面对这个具体状态，我该做什么"

这个框架也解释了为什么 Loop 的成本会成为瓶颈——模型推理不是在"写代码"时才发生，而是在每一次决策点都发生。一个复杂的编排 Loop 可能在完成一个任务前做几百次决策，每次都是一次 API 调用。

DIY 对比：手搓版 vs 官方版

如果你现在就想手搓一个最简 Loop，大概长这样：

# 手搓版 Ralph Loop（5行 bash）
while true; do
  cat prompt.md | claude --auto-accept 2>&1 | tee output.log
  if grep -q "DONE" output.log; then break; fi
  sleep 5
done

但 Boris 级别的编排 Loop 需要处理的东西远不止这些：

**省的到底是什么？**不是省了写代码的时间，而是省了"盯"的时间。从"人在循环中"到"人在循环外"，释放的是注意力，不是键盘时间。

压力测试：Loop 的三个致命假设

假设1：Loop 在大规模生产环境中可靠。

现实：dev.to 上的一篇文章《AI Agent Failure Loops: When Persistence Becomes a Quality Bug》精确描述了 Loop 的暗面——agent 看起来在持续工作，文件在生成、进度在报告、错误在被修复，但同一类缺陷不断回来。这不是 Loop 的 bug，而是 Loop 的本质特征：它把持久性赋予了模型，但模型对"我一直在犯同一个错"没有元认知。

假设2：成本会从模型转移到编排。

Uber 的案例恰恰说明，成本不是在转移，而是在叠加。模型费用在降，但 Loop 的每次决策点都要调用模型。200个并行 agent × 每个做100次决策 × 每次决策一次 API 调用 = 你的 Anthropic 账单爆炸。真正的成本不是编排本身，而是编排中的每次决策都要烧 token。

假设3：Skill 是比 Loop 更有价值的资产。

这是作者自己的观点，也是最有洞察力的。但需要注意：Skill 的价值来自复用次数。如果你的 Loop 每天跑30个仓库，一个 Skill 确实能复合增长。但对于大多数开发者，他们的 Loop 规模不足以让 Skill 的复利效应显现。

选型决策框架

诚实的限制

1. 17% 的部署率不是偶然的。Gartner 把 Agentic AI 放在膨胀期望的峰值是有原因的
2. 无限循环是真实的生产事故，不是一个理论问题。NotiLens 这种专门检测 agent 无限循环的产品已经出现
3. 质量复合效应：AI 生成的糟糕 commit 和好的 commit 一样会复合。roborev 这样的工具存在就是因为这个问题很严重
4. 幸存者偏差：你看到的都是"我用了 Loop 合并了259个 PR"的故事。你没看到的是那些跑飞了、账单爆了、代码库被污染了的案例

精选评论

@RhysSullivan（430 likes）：每次看到你的工作流，我都意识到我在这些工具的构建上还有多少要学的，真的每次都让我意识到自己的思维有多窄

原文：@steipete every time i see your workflow i realize how much i have to learn on building with these tools, genuinely always open my mind to how narrow in scope im thinking

@edzitron（241 likes）：你说"我们"的时候指的是几个人？

原文：@steipete When you say “we” how many people are you referring to

（这个问题的尖锐之处在于：Steinberger 描述的工作流可能需要一个团队来支撑，而不是一个人。它挑战了"一个人就能编排200个 agent"的叙事。）

@BeCachet（100 likes）：笑死，“极其精益"配180万美元的 token 费用。

原文：@steipete lmao “extremely lean” w/ $1.8m in tokens.

@robschaper（50 likes）：极其精益？？？你有100+个 Codex 并行运行，你拥有历史上最先进的 DevSecOps 自动化。“精益”

原文：@steipete Extremely lean??? You have 100+ Codex running in parallel, you have the most advanced DevSecOps automation in the history of the world. “Lean”

@PeterBell（15 likes）：这其中大部分可以用确定性方式完成——把流程、昂贵的工具调用和编排编译成代码，薄切智能层，从少样本训练生成基于规则的分类器——用保留数据验证——然后用你能找到的最笨的模型。

原文：@steipete So much of that can be done deterministically - compile the flows, expensive tool calls and orchestration to code, thinly slice the intelligence…

@alexanderrX_（14 likes）：OpenAI 在买单对吧？另外好奇你认为其中一些是不是 agent 被用在了确定性软件更好的地方。如果输出需要精确，agent 总是正确的抽象吗？还是简单的自动化脚本仍然是更干净的方案？

原文：@steipete openai is picking up the bill though, right? also curious if you think some of this is agents being used where deterministic software would be better.

@agrawal_twts：Loop = 暴力穷举 + Token 最大化冲出一条路

原文：@mvanhorn Loop = Brute Forcing and Token Maxxing your way out

@arbidthink：真正的转变不是把 Claude 当作更聪明的搜索框。而是把它配置为一个持久的认知工作空间：上下文、记忆、风格、约束、反馈循环。大多数人仍在 prompt 工具。更深的动作是设计一个思考的操作系统。

原文：The real shift is not using Claude as a smarter search box. It is configuring it as a persistent cognitive workspace…

Part 2: 苏格拉底对话

场景：深夜，尾巴刚看完 Matt Van Horn 的文章，脑子里一团浆糊。

学生： 老师，这篇文章说"Loop，而不是模型，是成本最高的部分”。但我用 Claude Code 写代码，每次 token 费用也没多少啊？

老师： 你现在是怎么用 Claude Code 的？

学生： 打开终端，写个 prompt，它给我生成代码，我检查一下，不满意就再 prompt 一次。

老师： 那你就是循环里面的那个人。每次你 prompt、等回复、判断、再 prompt——你自己在充当 Loop 的调度器。你的注意力就是成本。

学生： 对，但我的注意力不花钱啊。

老师： 是吗？你今天花了多少时间在"看 agent 输出 → 觉得不对 → 重新 prompt"这个循环上？

学生： ……可能有几个小时吧。

老师： 几个小时的注意力，如果你时薪200块，那就是几百块钱。这就是文章说的"Loop 是成本最高的部分"——不是 API 费用，是你守在循环里的时间成本。

学生： 所以 Loop 解决的是把我从循环里拉出来？

老师： 对。但拉出来之后呢？谁来判断 agent 做对了没有？

学生： 另一个模型？验证器？

老师： 没错。而那个验证器本身也在调用模型。所以当 Boris 说他有200个 agent 并行运行时，每个 agent 每次决策都是一次 API 调用。200个 agent × 几百次决策 = 你的 token 账单变成 Uber 的噩梦。

学生： 那 Uber 怎么解决的？把限额砍到1500刀/月？

老师： 那是止血。真正的解法是文章末尾那句——Loop 是管道，Skill 才是资产。如果你的 Loop 每次都在从头开始思考，那它必然贵。但如果它调用的是你预先写好的、经过测试的 Skill，那每次调用的成本就是固定的、可预测的。

学生： 所以关键不是"要不要用 Loop"，而是"Loop 里面装的是什么"？

老师： 精确。一个空的 Loop 就是一个 while-true 包着一个陌生人。一个装了 Skill 的 Loop 才是系统。但还有一个问题文章没深入——

学生： 什么？

老师： 如果 Loop 在持续运行，一个错误的 Skill 会被反复调用。好的 commit 复合增长，坏的 commit 也一样。你的 Loop 跑一晚上，第二天你的代码库可能面目全非。所以最关键的不是 Loop 本身，也不是 Skill——而是反馈闭环的质量。

学生： 所以 Loop = Cron + 决策者 + 反馈闭环 + 护栏？

老师： 对。但你觉得这和传统软件工程里的 CI/CD pipeline 有什么本质区别？

学生： ……CI/CD 的每个步骤是确定性的，Loop 的每一步都是概率性的？

老师： 这就是为什么 Loop 的工程难题不在"让它跑起来"，而在"让它停下来，并且停在对的时候"。你觉得什么场景下，概率性决策比确定性脚本更值得？

学生：（思考中……）

Part 3: 个性化洞察

基于尾巴的画像（QA 工程师背景、全栈开发、重度 Claude Code 用户、关注 AI 产品和开发者工具）：

1. 你的 QA 直觉是 Loop 生态中最稀缺的资源

文章提到验证（verification）是增长最快的子主题，roborev 等工具的核心就是"在后台审查每个 commit"。你作为 QA 出身，对"什么能出错"的直觉恰好是 Loop 护栏层最需要的。DanKornas 说"bad commits compound fast too"——这就是 QA 思维在 AI 时代的价值锚点。

你可以怎么做： 把你的 code review 经验编码成 Claude Code 的 Skill（自定义 review 规则、常见 bug pattern 检测），让 Loop 每次提交前自动调用。这不是"被 AI 替代"，而是把你的专业判断变成可复用的资产。

2. 你已经在用 Loop 了，只是没意识到

根据你的使用模式，你日常用 Claude Code 做翻译、分析、开发——每次多轮对话本质上就是一个手动 Loop。文章的价值不在于教你"用 Loop"，而在于让你意识到：把你已经反复做的事情，从手动循环变成自动循环。

你可以怎么做： 识别你日常最高频的3个 Claude Code 使用场景（翻译解读、知识库维护、项目开发），为每个写一个 /loop 或 /goal 模板。先从一个开始——比如让 Loop 每天自动 review 你昨天提交的代码。

3. “Skill 是资产"这个框架直接适用于你的知识库体系

文章的结论——“Loop 是管道，Skill 才是资产”——跟你正在构建的 wiki 知识库体系是同一个思想。你的 /add_wiki、/digest、/ingest 这些 skill 就是文章说的"锋利、经过测试、有命名的 skill”。Loop 只是调用它们的调度器。

你可以怎么做： 把你现有的 Claude Code skills 包装成 Loop 可调用的原子操作。比如：/loop 每天自动 /ingest 今日技术文章到知识库。知识库的复利效应 + Loop 的持久性 = 真正的复合增长系统。

4. 成本管理的视角：从"每 token 计费"到"每 loop 计费"

文章揭示了一个正在发生的范式转移：AI 编程的计费单位正在从"per token"变成"per loop"。这对做 AI 产品的人来说意味着定价模型也要变。

你可以怎么做： 如果你做自己的 AI 产品，考虑按"loop 完成率"而不是"token 消耗"来设计定价。用户不在乎你烧了多少 token，在乎的是 loop 跑完了没有、结果对不对。

5. 评论区 @alexanderrX_ 的质疑值得认真对待

“如果输出需要精确，agent 总是正确的抽象吗？还是简单的自动化脚本仍然是更干净的方案？"——作为一个系统架构师，你需要在每个场景下回答这个问题。不是所有东西都需要 Loop，确定性 > 概率性的场景，脚本永远是更正确的选择。