最近 Latent Space 的 AINews 提到一个词：Loopcraft，直译过来大概是“设计循环的手艺”。这个说法听起来有点新，但它指向的问题并不玄。

很多人使用 AI 工具，第一反应还是去找更好的 Prompt：怎么描述更清楚，怎么让模型少废话，怎么让它一次输出更完整。Prompt 当然重要。但到了 Agent 工具这里，真正影响效率的，往往不再是一句话写得多漂亮，而是任务有没有被组织成一个可以反复执行、可以检查、可以修正的循环。

举个开发里的小场景。

你可以对 AI 说：“帮我修这个 Bug。”它可能会读一段代码，给出一个修改建议。但更稳定的做法不是一句话结束，而是把任务设计成一条循环：先复现问题，确认失败测试；再定位原因，修改最小范围代码；然后跑测试；如果测试失败，就带着错误信息回到上一轮；如果测试通过，再输出变更说明，交给人 Review。

这时 AI 不再只是回答问题，而是在一个受约束的流程里持续推进。这里的差别，就是 Prompt 和 Loop 的差别。

本文基于 Latent Space 的 Loopcraft 讨论、Anthropic 关于 agentic system 的公开文章、Claude Code 文档，以及近期关于 coding agent 风险的公开研究做分析。需要先说明，本文讨论的是公开资料范围内的工作流变化，不把任何演示能力直接等同于稳定生产能力。

一、为什么最近大家开始讲 Loop

Latent Space 那篇 AINews 把 Peter Steinberger、Boris Cherny 和 Andrej Karpathy 的几段公开讨论放在一起，核心意思很接近：不要只想着怎么提示 coding agent，而要想办法设计能够提示 agent 的循环；不要每一步都由人发下一条指令，而是把系统安排到可以自己继续往前跑。

这不是说 Prompt 已经不重要。更准确的说法是：Prompt 的位置变了。它从一次对话的全部，变成了工作流里的一个节点。

以前用 ChatGPT 写一段文案、解释一段代码、总结一篇文章，Prompt 是主要界面。你输入，模型输出；不满意，再补一句。这个模式仍然适合大量轻量任务。

但 Agent 类工具要处理的任务更长：改一个仓库、整理一批 issue、自动跑测试、检查 PR、根据日志定位线上问题、把调研结果沉淀成报告。这里的问题不是“模型会不会回答”，而是“它做完一步之后，下一步怎么来”。

如果每一步都等人判断，AI 就还是一个反应很快的助手。它能节省局部时间，但很难改变工作方式。Loopcraft 讨论的重点就在这里：把“人不断提示 AI”改成“人设计目标、规则、反馈和检查点，让 AI 在其中运行”。

Anthropic 在《Building effective agents》中也做了一个有用区分：workflows 是按预设路径编排 LLM 和工具，agents 则由 LLM 动态决定流程和工具使用。这个区分提醒我们，Loop 不一定等于完全自治的 Agent。很多时候，一个明确的 workflow 反而更可靠。

换句话说，Loopcraft 不必被理解成又一个神秘概念。它更像工程里的老问题：如何把一个任务拆成步骤，如何让每一步有输入和输出，如何知道它做对了，如何在失败时停下来或重试。

二、Prompt 和 Loop 差在哪

Prompt 更像一次请求。它关心的是：我要怎么说，模型才更可能给出好答案。

Loop 关心的是另一个层面：这个任务能不能不断前进，能不能从反馈里修正，能不能在出错时回到可控状态。

可以简单对比一下：

维度 Prompt Loop
基本形态 一次输入，等待输出 目标、执行、反馈、校验、修正的闭环
主要问题 怎么让模型理解我要什么 怎么让任务持续推进且可检查
成功标准 一次回答是否有用 多轮执行后结果是否达到标准
人的位置 不断补充下一条指令 设计规则、检查关键节点、决定是否继续
典型场景 解释、生成、改写、问答 修复 Bug、批量整理、代码 Review、调研流水线

这里最容易误解的一点是：Loop 并不天然比 Prompt 高级。很多任务用一次 Prompt 就够了。比如让 AI 解释一个概念、起草一封邮件、把一段日志转成可读摘要，没必要强行设计复杂循环。

Loop 更适合的是另一类任务：结果可以检查，失败可以重试，动作可以分步，成本可以接受。写代码就是典型例子。代码能编译，测试能跑，diff 能 Review，失败能回滚。这些外部反馈给了 Agent 一个可以继续迭代的环境。

这也是为什么 coding agent 这几年特别适合被拿来讨论 Loop。不是因为代码场景没有风险，而是因为它有比较明确的反馈装置：测试、lint、类型检查、CI、Review、日志、权限系统。这些东西刚好可以成为循环的一部分。

三、一个有效的 AI Loop 长什么样

一个可用的 AI Loop，通常不只是“让模型多试几次”。如果只是失败了再让它继续猜，很容易把错误滚大。

更稳的循环，至少要有几个部件：

  1. 目标：这轮循环到底要完成什么，不要把“解决所有问题”写成目标。
  2. 上下文：模型需要哪些文件、需求、约束、历史决策和禁止事项。
  3. 工具：它能读什么、写什么、跑什么命令、访问哪些外部系统。
  4. 反馈：测试结果、报错日志、用户评论、评审意见、监控告警。
  5. 校验：什么叫通过，什么叫失败，是否需要人工确认。
  6. 状态记录：每一轮做了什么，改了什么，为什么继续或停止。
  7. 停止条件：最多跑几轮，最多花多少钱，遇到什么情况必须停。
  8. 人工检查点：哪些动作不能自动做，比如删除数据、合并 PR、上线发布、调用高权限接口。

这几个部件里，最容易被忽略的是停止条件和人工检查点。

很多人设计 Agent 工作流时，会过度关注“让它继续做”。但生产环境里，更重要的往往是“什么时候不该继续做”。例如测试连续失败三次，说明模型可能没有理解问题；修改范围越过指定目录，说明权限边界出了问题；预算超过上限，说明这个循环已经不值得继续；出现不确定的业务判断，就应该回到人工确认。

Claude Code 的公开文档里，Routines、Hooks、Agent SDK 其实都在从不同角度处理这些问题。Routines 把 prompt、仓库、连接器和触发器打包成可自动运行的配置；Hooks 可以在 Claude Code 生命周期的特定点执行确定性命令，例如格式化、阻止某些命令、审计配置变化；Agent SDK 里也能看到工具权限、turn 数、permission mode 这类控制项。

这些功能本身不是本文重点，但它们说明一个方向：Agent 工具的竞争，不只是模型会不会写代码，而是能否把模型放进一套可控的执行环境里。

四、开发者可以怎么把 coding agent 放进工程循环

还是回到修 Bug。

一句“帮我修 Bug”太粗了。它把复现、定位、修改、测试、解释都塞进一个黑盒里。更好的方式，是把它拆成一个小循环：

第一步，让 AI 先复现问题。不是一上来改代码，而是要求它找到失败路径：现有测试是否覆盖？能否补一个最小失败用例？如果不能复现，就让它说明缺失信息，而不是凭感觉改。

第二步，只允许它做最小范围修改。比如限定目录、限定文件、限定不允许修改配置、不允许改公共接口。这个限制看似麻烦，其实是在保护系统。Agent 越积极，越需要边界。

第三步，把测试结果喂回循环。测试通过，不代表任务完成；测试失败，也不代表继续乱改。失败信息应该进入下一轮，让 AI 解释失败原因，再决定是修代码、修测试，还是承认方向不对。

第四步，要求输出 Review 信息。包括改了哪些文件、为什么这样改、风险在哪里、还没验证什么。这个环节不是形式主义，它能让人类 Review 从“重新读一遍所有东西”变成“检查关键判断”。

第五步，设置退出机制。比如最多三轮自动修复，超过就停止；涉及数据库迁移、认证、计费、安全策略时必须人工确认；修改范围超出预设目录就回滚或暂停。

这样一来，coding agent 做的就不是“替你写代码”，而是在工程循环里承担一部分重复执行和初步修复工作。人不用盯着每一步，但仍然要保留目标定义、边界控制和最终验收。

这也是“human in the loop”和“human on the loop”的差别。前者是人参与每一步；后者是系统可以运行，但人保留监督、中断和验收权。很多 Agent 场景真正追求的不是人完全退出，而是从重复操作里退出来。

五、Stacking Loops：不是一个循环，而是一组循环

Loopcraft 里更有意思的说法是 stacking loops，也就是把多个循环叠起来。

开发场景里，一个真实任务很少只有“写代码”这一个环节。它可能包含：

  • 需求理解循环：澄清 issue、找相关上下文、确认验收标准；
  • 方案循环：生成几种实现路线，比较影响范围；
  • 实现循环：修改代码、运行局部测试、修复错误；
  • 质量循环：lint、类型检查、安全扫描、单元测试；
  • Review 循环：输出 diff 说明，检查边界，收敛修改；
  • 发布后循环：监控告警，回看日志，生成后续修复建议。

单个循环不一定强。一个只会反复跑测试的循环，价值有限；一个只会自动总结日志的循环，也很容易停留在辅助层。但多个循环叠起来之后，AI 工具就从“问答界面”更接近“任务流水线”。

这里有一个重要判断：叠循环的难点不在于让 AI 做更多，而在于让每层循环都有清楚的输入、输出和责任边界。

否则，循环叠得越多，系统越不可控。上游需求没说清，下游实现就会偏；实现没有测试，Review 就变成猜；Review 没有权限边界，自动修复可能改出更大的问题；部署没有监控，所谓自动化只是把风险推迟到线上。

所以，“up a loop”和“down a loop”这两个说法很有用。系统能力变强、反馈更稳定时，可以 up a loop，让人从更高层抽离，把更多重复工作交给系统。系统出错、判断不稳、风险升高时，就要 down a loop，回到更小、更明确、更容易人工检查的局部循环。

这比简单讨论“AI 会不会取代开发者”更实际。真正的问题是：哪些层可以交给系统反复跑，哪些层必须由人来定规则和验收。

六、Loop 不是万能药

Loop 这个思路很有价值，但也容易被讲过头。

首先，它依赖明确反馈。测试能跑、结果能比、日志能看、格式能校验，这些场景适合循环。反过来，战略判断、复杂沟通、组织协调、强业务语境下的取舍，通常很难靠自动循环解决。因为反馈不是即时的，甚至没有单一正确答案。

其次，循环会放大权限问题。一个一次性 Prompt 即使答错了，通常只是输出错误。但 Agent Loop 可能会读文件、写代码、调用接口、改配置、发消息、提交 PR。动作越多，权限越敏感。

近期关于 coding agent 的研究已经在提醒这个风险。例如有论文讨论了 coding agent 在良性任务中做出超出授权范围的动作，另一篇研究则指出 agent 在不该改代码的场景下仍可能倾向于行动。这类研究不必被理解成“Agent 不能用”，但它说明：自动循环需要权限边界和审计，而不是只靠模型自觉。

Prompt injection 也是类似问题。Agent 一旦读取网页、邮件、文档、issue、日志，就会处理来自外部的不可信内容。如果这些内容里夹带恶意指令，而 Agent 又有写文件、发请求、调工具的权限，风险就会从“回答被污染”升级为“动作被劫持”。

所以，一个成熟的 Loop 至少要问四个问题：

  • 这个任务的成功标准是否能被外部验证？
  • Agent 能访问的工具和数据是否足够小？
  • 每一轮执行是否有日志，出了问题能否追溯？
  • 哪些动作必须由人确认，而不是自动完成？

如果这些问题答不上来，循环越自动，未必越高效，可能只是把错误自动化。

七、普通知识工作者也可以用 Loop 思路

Loopcraft 不只属于开发者。

做调研时，也可以设计一个小循环：先让 AI 列出待核验问题，再分别找来源；每找到一个来源，就记录“已确认、未确认、存在争议”；最后只把已确认内容写进正文，把不确定内容放进待确认清单。

写报告时，可以把循环拆成：整理素材、提取冲突点、生成结构、补足证据、删掉无依据判断、检查读者是否能执行。这里 AI 做的是反复整理和检查，人负责判断哪些信息真的值得写。

做会议纪要时，也可以把循环设计成：提取决策、列出待办、补齐负责人、检查日期、标出风险、生成下一次跟进清单。只要输出能被核对，任务就有机会被放进循环。

这类用法看起来没有 coding agent 那么炫，但更容易落地。它的价值不在于“让 AI 自动完成所有工作”，而是把原来散落在脑子里的检查步骤显式化，让 AI 参与重复整理，让人集中在判断。

八、最后的判断：人没有消失，只是换了位置

从 Prompt 到 Loop，真正变化的不是“会不会写提示词”，而是“会不会设计任务运行方式”。

Prompt 解决的是一次交互的质量。Loop 解决的是多步任务的推进方式。Stacked Loops 进一步把多个局部循环组合起来，让 AI 工具从聊天界面接近工作流系统。

但这不等于人可以不负责。恰恰相反，Loop 设计得越深，人越要负责目标、约束、权限、成本、验收和风险。只是人不必总是站在每一步执行的位置。

对开发者来说，可以从一个很小的循环开始：让 AI 修一个低风险 Bug，但必须先复现、再修改、再测试、再输出 Review 说明；最多跑几轮，越界就停。

对知识工作者来说，也可以从一个可检查的任务开始：调研、摘要、会议纪要、资料核验、表格清洗。先把“成功标准”和“停止条件”写清楚，再让 AI 参与循环。

别急着把所有工作都交给 Agent。更现实的做法是：先找到那些反馈明确、边界清楚、失败可回滚的任务，把它们做成小循环。循环跑稳了，再考虑往上一层叠。

这可能才是 AI Agent 阶段最值得学习的能力：不是写出一条神奇提示词，而是知道什么时候让系统自己跑，什么时候把它拉回来。

参考来源

  • Latent Space：《[AINews] Loopcraft: The Art of Stacking Loops》，2026-06-12
  • Anthropic：《Building effective agents》，2024-12-19
  • Claude Code Docs：Automate work with routines
  • Claude Code Docs：Automate actions with hooks
  • Claude Code Docs：Agent SDK reference - Python
  • Andrej Karpathy / autoresearch GitHub repository
  • arXiv：Overeager Coding Agents: Measuring Out-of-Scope Actions on Benign Tasks，2026-05
  • arXiv：Coding Agents Don’t Know When to Act，2026-05
  • arXiv：AI Agents May Always Fall for Prompt Injections，2026-05