AI Loop 到底是什么？从 Claude Code 到 Mira Skills 的完整心智模型

原文链接：https://x.com/AnatoliKopadze/article/2068328135611822149

过去几年，绝大多数人使用 AI 的方式并没有真正变过：

你写一个 prompt，等回复，发现不对，再补一句，继续等。看起来是 AI 在干活，其实每一步都还是你在推着它走。

Anatoli Kopadze 在 X 上写了一篇长文，试图解释最近 AI 工程师圈子里反复出现的一个词：loop。

这篇文章的价值不在于介绍某个新工具，而是把一个容易被神化的概念拆开了：loop 不是「更长的 prompt」，也不是「让 AI 多想几步」。它是一套让 AI 能够围绕目标持续推进、验证、修正、退出的工作结构。

Prompt 是一次请求，loop 是一份工作

prompt 的本质是一条指令。

你给 AI 一个输入，它返回一个输出，然后停下来等你判断下一步。这个模式很适合单次任务，比如改一段文案、解释一个概念、生成一个初稿。

loop 不一样。loop 交给 AI 的不是一条指令，而是一份工作：

目标是什么？
怎么判断完成？
每次失败后如何继续？
最多允许尝试几次？
中间状态保存在哪里？

所以一个最小 loop 通常会包含五个动作：

DISCOVER  -> 找出需要做什么
PLAN      -> 决定先做哪一步
EXECUTE   -> 执行
VERIFY    -> 检查结果是否达标
ITERATE   -> 不达标就把结果带回下一轮

这也是为什么 coding agent 最先把 loop 跑起来。

代码天然适合验证。测试过了就是过了，类型检查失败就是失败，构建报错就是报错。只要验证器足够硬，agent 就知道自己还没完成，而不是凭感觉宣布「差不多了」。

真正重要的是 verify，不是 repeat

很多人一听 loop，脑子里想到的是「重复运行」。

但重复本身没有价值。一个没有验证的循环，只是模型在反复说服自己。

loop 的核心是 verify。

验证可以是：

• 测试是否通过
• lint 是否干净
• 类型检查是否为零错误
• 输出是否满足明确规则
• 某个指标是否超过阈值

如果验证条件是「看起来不错」「风格高级」「更有感染力」，loop 就会变得很虚。因为它没有一个外部标准去拒绝坏结果。

这也是一个很实用的判断：

凡是没有自动拒绝机制的任务，都不适合上重型 loop。

写代码可以。跑数据清洗可以。批量检查链接可以。每天生成一份固定结构的报告也可以。

但如果任务本质上依赖审美、判断、编辑品味，那就别急着自动化到底。你可以让 AI 迭代，但最后那道门最好还是人来守。

一个能工作的 loop 至少要有三件事

Anatoli 在原文里强调了三块基础设施，这也是我觉得最值得记下来的部分。

第一是 验证器。

它决定循环是不是在变好。没有验证器，agent 只是不断产出更多文本；有了验证器，它才有机会把失败变成下一轮输入。

第二是 状态。

如果每一轮都忘记上一轮做过什么，loop 就会陷入同样的错误。一个真正能跑的 loop 需要记录：

• 已经尝试过什么
• 哪些失败了
• 当前最重要的问题是什么
• 下一轮应该从哪里继续

第三是 停止条件。

loop 必须知道什么时候成功，也必须知道什么时候放弃。

例如：

成功：所有测试通过，lint 为 0，类型错误为 0
失败：最多迭代 8 次；仍未通过则停止并汇报剩余问题

没有停止条件的 loop，不是自动化，是账单黑洞。

为什么 loop 先在代码里爆发

原文给了一个典型 coding loop 的规格：

目标：让 /tests/auth 下的所有测试通过，并保持 lint 和类型检查干净。

每一轮：
1. 运行测试，读取失败信息
2. 找出影响最大的一个失败
3. 做最小修改
4. 重新运行测试、lint 和 type check

停止：
验证通过，或达到最大迭代次数

这个规格看起来朴素，但已经具备了生产级 loop 的骨架：目标明确、验证明确、每轮动作明确、停止条件明确。

更复杂的系统会继续往上叠几层：

• 自动化触发：定时、事件、hook、CI、cron
• Skill：把稳定指令保存成可复用文件，而不是每次复制 prompt
• Sub-agent：把「做事的人」和「检查的人」分开
• Connector：让 agent 能真正操作 GitHub、Linear、Gmail、Notion 等系统
• Verifier：用测试、构建、规则或指标把关

这里最值得警惕的是 sub-agent。

让同一个模型既写代码又评审自己的代码，很容易变成自我安慰。更稳的结构是：一个 agent 快速实现，另一个 agent 严格检查，必要时再把问题送回第一轮。

这不是为了形式复杂，而是为了避免「作者给自己打高分」。

成本才是 loop 的现实边界

loop 听起来很美，但它不是免费的。

每一轮都要重新读取目标、上下文、失败信息、修改记录。轮数越多，上下文越长。如果再加 maker/reviewer 两个 agent，成本还会翻倍。

所以最该看的指标不是「跑了多少轮」，而是：

每个被接受的结果，实际花了多少 token？

如果一个 loop 产出 10 个结果，你最后只保留 3 个，那你并没有省下多少 review 时间，只是把成本转移到了模型调用上。

原文里有一个很好的提醒：loop 会静悄悄地失败。它不一定崩溃，也不一定报错，它可能只是过早宣布完成，或者一直在无意义地迭代。

这就是为什么重型 loop 必须配：

• 最大迭代次数
• token 预算
• 明确失败汇报
• 便宜模型处理低价值步骤
• 高价值步骤再交给更强模型
• 可观测的日志和产出审计

没有这些护栏，loop 很容易从「自动工作」变成「自动烧钱」。

正确顺序：先手动可靠，再自动循环

如果你真的要搭一个 loop，顺序比工具重要。

我会把它压成四步：

1. 先让一次手动流程稳定跑通
2. 把稳定流程沉淀成 skill
3. 给 skill 加验证器和停止条件
4. 最后再放到定时任务或事件触发里

最危险的做法，是流程还没跑顺就上定时任务。

你还没证明它能做好一次，就让它每天自动跑，这不是工程化，而是把不确定性放大。

日常生活里的轻量 loop

有意思的是，Anatoli 最后把 loop 从代码拉回了普通人的日常场景。

他的例子是 Mira，一个在 Telegram 里的 AI 助手。这里的重点不是这个产品本身，而是它代表的另一种 loop：不是为代码库设计，而是为日常事务设计。

比如你可以用一句话描述一个自动任务：

每个工作日早上 7 点，检查我的 Gmail 和 Google Calendar。
给我一份 120 字以内的简报：今天最重要的 3 个会议、紧急邮件、以及我还没跟进的一件事。

这其实也是 loop：

• 有时间触发
• 有外部连接器
• 有固定动作
• 有输出格式
• 会在你不打开聊天窗口时自动运行

它和 coding loop 的不同在于：验证更软，风险更低，目标更生活化。

对于大多数人来说，这种轻量 loop 可能比「搭一套 agent 工厂」更有价值。

例如：

• 每周五自动整理团队状态
• 开会前提醒上次讨论的决定
• 把转发来的消息变成 Linear ticket
• 把语音想法改成多平台内容草稿
• 每晚追踪习惯并总结一周变化

这些任务不需要你搭复杂基础设施，但它们确实符合 loop 的本质：不靠你记得，不靠你每次手动发起，而是让系统在合适的时机自己运行。

我会怎么用这个概念

我对 loop 的理解是：

它不是让 AI 更聪明，而是让工作流更闭环。

所以判断一个任务是否值得做成 loop，可以问四个问题：

1. 这个任务会不会反复出现？
2. 坏结果能不能被自动识别？
3. agent 能不能自己完成大部分动作？
4. 完成标准是不是足够客观？

四个答案都是「是」，才值得上自动 loop。

如果只有前两个成立，可以先做半自动：让 AI 生成、让脚本检查、人来收尾。

如果只有第一个成立，那就写一个好 prompt 或 skill，别急着自动化。

真正成熟的 AI 使用方式，可能不是「我会写很厉害的 prompt」，而是「我知道哪些工作值得变成循环，哪些工作必须保留人工判断」。

这比追任何单个模型都重要。