AI Agent 如何从提示词走向可控工作流？《Loop Engineering 从入门到进阶手册》免费公开

你可能已经把 AI Agent 用进了工作，但仍然在重复做这些事：

每次开新任务，都要重新解释项目背景；Agent 说已经修好，你还得确认测试是否真的运行；它连续尝试几轮后，你很难判断该继续、回滚，还是交给人处理。

Agent 在执行，人仍然承担着上下文、调度、验收和最终责任。

当任务只做一次，这套协作方式还能运转。任务开始重复、跨越多个轮次、接入真实工具后，单条提示词很快就会超过承载范围。

这也是 Loop Engineering 要解决的问题：把目标、状态、工具、反馈、停止规则和人的判断边界组织成一个可控循环，让 Agent 能够持续做事，也能在证据不足、连续失败或触碰风险时停下来。

过去一段时间，我围绕这个主题连续发布了 7 篇内容。前 5 篇建立基础方法和 CI 实战，第 6 篇用 UI 精准复刻验证视觉反馈闭环，第 7 篇把任务设计工具 loop-builder 正式开源。

现在，我把这条从概念、方法到实战和工具的路径，重新整理、扩写成了《Loop Engineering 从入门到进阶手册》。

完整电子书免费公开。

七篇内容之后，还缺一条完整路线

前 5 篇分别讲了 Loop Engineering 的概念、六块积木、五种模式、三角色闭环，以及 Codex CI 自动修复实战。随后两篇继续向真实应用推进：一篇完整复盘 UI 精准复刻过程，一篇公开 loop-builder 项目和最小使用入口。

这 7 篇内容解决了几个局部问题：Loop 是什么，一个循环靠什么运行，Planner、Generator、Evaluator 怎么分工，Agent 如何根据测试或截图反馈继续修正，以及如何把任务设计方法沉淀成开源工具。

但文章是按单个主题展开的。读者收藏了其中一两篇，仍然需要自己回答一组更实际的问题：

• 我的任务到底需不需要 Loop？
• Prompt、Checklist、工作流和完整 Loop 应该怎么选？
• 外部反馈从哪里来？
• Agent 连续失败几轮必须停止？
• 哪些动作可以自动执行，哪些决定必须留给人？
• 跑通一次之后，怎样沉淀成可复用的个人资产？

所以这次成书没有沿用公众号文章的顺序。全书按照“判断任务、设计结构、选择模式、分工验收、真实实践、处理失败、沉淀资产”的路径重新组织。

当前公开版为 v1.1，共 10 章，包含两种真实实践、一套 7 天落地计划和 13 组可复制模板。

先判断任务值不值得做成 Loop

Loop Engineering 很容易被误解成“让 Agent 一直跑”。

持续运行只是表象。一个合格的 Loop 至少应该满足四个条件：可验证、可停止、可纠错、可交接。

如果任务没有外部反馈，Agent 只能反复确认自己的输出；如果没有停止规则，错误会在多轮执行中继续放大；如果状态只留在聊天记录里，下一轮仍然要从头解释；如果高风险动作没有人工确认，自动化会把一次失误变成系统性风险。

因此，书里的第一步，是先判断任务应该停在哪一层，再决定需要多复杂的 Loop：

• 一次性、边界清楚的任务，用 Prompt。
• 步骤固定、判断很少的任务，用 Checklist 或普通工作流。
• 有明确反馈、需要多轮修正的任务，再设计 Loop。
• 涉及权限、支付、生产配置、数据删除和公开发布的任务，保留人工确认。

这一步能省下很多无效工程。简单任务没有必要为了追赶概念而变复杂。

从 Prompt 到可控 Loop 的四层演进

从 Prompt 到可控 Loop 的四层演进

六块积木、五种模式、三个角色

判断任务适合 Loop 之后，接下来才是结构设计。

书中把 Loop 拆成六块积木：Automations、Worktrees、Skills、Connectors、Sub-agents 和 Memory。它们分别解决触发、隔离、规则复用、工具连接、角色分工和跨轮记忆问题。

不同任务的循环方式也不同。Retry Loop 适合有明确错误反馈的小修复；Plan-Execute-Verify 适合目标明确、需要分阶段验收的任务；Explore-Narrow 适合研究和选题；Human-in-the-Loop 负责保留人的判断；Lifecycle Loop 用来管理长期运行和状态变化。

模式选定以后，Planner、Generator 和 Evaluator 承担不同职责：Planner 把目标变成可执行规格，Generator 完成最小动作，Evaluator 根据独立证据验收。

三者之间还需要 Harness，把上下文、工具权限、反馈格式、停止规则和人工确认点固定下来。否则角色名称写得再完整，Agent 仍可能在同一段上下文里生成、解释并认可自己的结果。

五种 Loop 模式决策图

五种 Loop 模式决策图

两个案例，验证同一套方法

这本书保留了 Codex CI 自动修复案例，并新增了 UI 精准复刻案例。

把这两个任务放在一起，是因为它们的反馈完全不同。

CI 修复依赖失败日志、测试结果和代码 diff。Maker 每轮只处理一个问题，Checker 检查测试是否通过、有没有修改测试预期、有没有顺手重构。连续失败、改动越界或成本超限时，Loop 必须停止。

UI 复刻依赖目标图、当前截图和视觉差异清单。每一轮先比较差异，再只处理最影响相似度的问题，随后重新截图验收。没有目标图，Agent 就缺少可靠的收敛方向。

两个案例共享同一副骨架：明确目标，读取外部反馈，做最小动作，独立验收，记录状态，再决定继续、停止或交给人。

CI 自动修复 Loop

CI 自动修复 Loop

我把设计过程也做成了工具

面对一个新任务，最费力的环节经常发生在执行之前：目标怎么收窄，缺哪些输入，用什么反馈验收，允许 Agent 做什么，什么情况下必须停。

我把这部分方法做成了开源项目 loop-builder，并写进了第 6 章。

你只需要描述一个真实任务，它会先检查目标、输入、证据和风险边界，再判断当前更适合 Prompt、Checklist、Human-in-the-Loop、完整 Loop、专用 Agent 包，还是值得长期维护的 Skill。

当前项目以 Codex Skill 形态提供，核心方法可以迁移到其他 Agent 工作流。它负责帮助人把工作逻辑写清楚，最终边界和关键决定仍由人确认。

为什么完整免费公开

我希望这本书成为一份可以被使用、验证和持续修订的公开作品。

一套方法真正产生价值，要进入真实任务，经得起失败、反馈和复盘。完整开放能让读者看到从判断到实践的整条链路，也能让不同岗位的人带着自己的场景来检验它。

这也是我理解的个人品牌：公开你持续研究的问题，拿出可以复用的成果，对能力边界保持诚实，再用后续行动更新它。

当前公开的是 v1.1。后续版本会继续补充更多真实案例、工具迁移实测、失败记录和成本数据。书中涉及的工具能力会随版本变化，具体命令仍需以官方文档和本地帮助为准。

免费公开阅读不等于放弃版权。个人读者可以学习、引用并在自己的任务中使用书内模板；商业转载、再出版和再授权需要获得许可。