前言仔细阅读了《Loop Engineering: The Anthropic Playbook for Designing Systems That Prompt Your Agents》.让我更进一步理解了Loop Engineering。其中感触最深的是循环使生成变得廉价而使判断力变得稀缺that loops make generation cheap and leave judgment scarce.循环不是一种被工具本身能力固化的工具。它会不加改变地放大你带来的任何东西带来理解它就放大理解带来懒惰它就放大懒惰。它是一个忠实的乘号它乘以的是人本身。A loop is not a tool whose quality is fixed by the tool. It is so strong that it amplifies, unchanged, whatever one brings: bring understanding and it amplifies understanding; bring laziness and it amplifies laziness. It is a faithful multiplication sign, and what it multiplies is the person.分享出来和大家一起学习。1. 核心定义循环工程Loop Engineering不是教你如何更好地提示 AI而是教你如何设计一个能自动提示 AI、自我运转并自我纠错的系统。它的目的是将人类从“执行者”在循环内变为“设计者”在循环外。循环并非简单的定时重跑而是一个能自我发现工作、隔离执行、独立验证、持久记忆并自动调度的闭环系统。2. 底层基础六大核心组成部分这是搭建循环所需的“物理硬件”或基础设施。在实施前请务必确认您的系统是否具备了这六个“器官”。按从底层保障到上层调度的逻辑排列如下部件 (Part)物理形态 / 实现方式解决什么问题1. 记忆磁盘上的持久化状态文件如state/triage.md或数据库记录。对抗失忆代理的上下文窗口一关就会忘记一切但磁盘不会。它让循环隔夜还能记得昨天的进度和结论。2. 技能项目根目录下的SKILL.md文件存储永久性项目知识。偿还“意图债务”不用每天早上一遍遍告诉代理“这个项目是干嘛的、代码规范是什么、陷阱在哪里”。3. 连接器基于 MCP 协议的外部接口连接 Jira、GitHub、Slack、数据库、浏览器。拓展视野让循环能看到文件系统之外的世界读取工单、发送通知、操作网页截图。4. 子代理独立运行的其他 Agent 实例通常一个负责写代码一个负责审查。实现“裁判分离”防止生成器自我审查时的“灯下黑”。5. 工作区git worktree生成的多个独立目录。解决并行冲突每个任务拥有自己的文件夹多个代理同时修改代码也不会互相踩踏。6. 自动化定时器Cron或触发器Webhook如 GitHub Actions。赋予生命让循环“活”起来而不是一个需要手动点击运行一次的僵硬脚本。好的我将为您详细展开五个动作的说明从设计意图、实施要点到常见反模式逐一拆解便于您在实际构建循环时能准确落地。3. 循环的五个动作详细操作指南这五个动作不是可选项而是必须全部安装的强制流程。缺少任何一个循环就会退化为第五章节所列举的五种失败模式之一。3.1. 动作一发现Discovery一句话定义让代理自行找到“今天该做什么”而不是人类告诉它。设计意图发现是循环的“眼睛”。如果这一步做得不好后续四个动作再漂亮也只是在错误的事情上浪费算力。人类的价值不应消耗在“指派任务”上而应集中在“判断结果是否正确”上。实施要点要点具体做法触发源读取 CI 失败记录、新提交的 Issue、最近的 Commit、监控告警、收件箱中的未处理请求。承载形式将“读什么、怎么判断优先级”封装进技能Skill即SKILL.md文件而非直接粘贴到 Cron 脚本中。判断标准对每个候选条目回答三个问题① 可操作吗还是噪音② 阻塞发布吗优先级③ 已在处理中吗去重输出格式生成结构化的发现列表如表格写入状态文件供下一轮使用。常见反模式盲目循环❌ 人类每天早上手动告诉循环“修 Bug #123、#456、#789”。❌ 发现逻辑硬编码在自动化脚本中导致维护困难。✅正确做法循环自行读取数据源自主裁定今日工作清单。检查清单你的循环是否能在无人干预下独立输出一份“今天值得做的事情”清单3.2. 动作二移交Handoff一句话定义将每个发现的任务安全、隔离地移交给执行代理。设计意图移交是循环的“手臂”。它的核心目的是隔离。如果多个代理同时修改同一份代码会产生无法解决的合并冲突。移交的质量决定了并行效率的上限。实施要点要点具体做法隔离载体每个任务使用独立的git worktree工作区即claude --worktree fix/slug。任务粒度每个工作区只负责一个原子性任务如“修复登录超时”不要将多个不相关修复塞进同一个工作区。启动参数每个工作区启动时带入该任务专属的上下文相关文件路径、预期目标、停止条件。清理机制任务完成后自动归档或删除工作区避免磁盘膨胀。常见反模式混乱循环❌ 五个代理同时修改同一个目录编辑相互覆盖合并时一团乱麻。❌ 任务粒度太粗一个工作区修了三个不相关的 Bug导致验证和回滚困难。✅正确做法每个任务独立工作区互不干扰每个工作区只做一件事。检查清单你的循环是否能在并行运行5个代理时依然保持代码库整洁、无冲突3.3. 动作三验证Verification一句话定义用独立的、持怀疑态度的另一个代理来检查生成器的输出能说“不”。设计意图验证是循环的“刹车片”和“良心”。这是五个动作中最关键也最容易被跳过的一个。经验证明生成器审查自己的代码会不自觉地自我表扬“看起来没问题”。验证的本质是引入对抗性视角打破生成器的“自我说服链”。实施要点要点具体做法角色分离评估器必须是独立的子代理与生成器使用不同的系统指令System Prompt甚至不同的底层模型。验证方式行动而非阅读评估器不能只看代码文本。它必须实际执行跑测试、启动页面、点击按钮、截图、检查 DOM。评判的基准是“它跑得对吗”而非“它看起来对吗”。默认立场评估器的默认态度是“假定代码是坏的直到被证明是好的”。持怀疑态度是它的第一天职。停止条件/goal使用/goal命令设定明确的成功标准如“所有测试通过且 lint 干净”并由第三个全新模型来裁决是否达成而非生成器自己说了算。制造者-检查者原则源自银行业的“双人复核”原则写代码的人和审核代码的人不能是同一个。常见反模式点头循环❌ 生成器写完代码后调用go test看到全绿就宣称“验证通过”。❌ 让同一个代理既写代码又做 Code Review。❌ 评估器仅凭肉眼阅读代码从不实际运行。✅正确做法换入一个独立代理让它实际运行你的应用如用 Playwright 点按钮凭事实证据下结论。检查清单你的循环是否曾经对任意一个输出说过“不”如果几百轮以来它从来没有拒绝过任何东西那你的验证环节可能根本不存在。3.4. 动作四持久化Persistence一句话定义将本轮的状态、结论、产出物保存到对话之外的持久存储中。设计意图持久化是循环的“记忆硬盘”。代理的上下文窗口一刷新就失忆如果结果只活在聊天记录里循环就永远在原地打转。持久化让循环具备累积性——今天的结论是明天的基础。实施要点要点具体做法状态文件将每个发现及其处理进度写入./state/triage.md或类似的 Markdown / JSON 文件。外部同步通过连接器Connector自动更新 Jira 工单状态、创建 GitHub PR、向 Slack 发送通知。提交回仓库状态文件应被 git 跟踪并提交确保跨日、跨机器可读。记忆 ≠ 上下文清晰区分两者上下文是代理本轮看到的、用完即清的数据记忆是磁盘上永久保存的、跨轮次存续的状态。常见反模式健忘循环❌ 把所有结论只写在聊天窗口里第二天刷新后一切归零。❌ 状态文件只存在于本地没有提交到仓库云端调度器读取不到。✅正确做法每轮结束前将关键发现、已完成项、待办项、阻碍项全部写入磁盘并提交。检查清单你的循环是否能在你合上电脑一周后重新开机时准确记得上周干到哪一步了3.5. 动作五调度Scheduling一句话定义让循环“活”起来——按定时或事件自动触发下一轮无需人类点击“运行”。设计意图调度是循环的“心脏起搏器”。没有调度你拥有的只是一份写得不错的脚本需要你手动拉绳才能动一下。调度让循环从“工具”变成“员工”。实施要点要点具体做法本地调度使用/loop命令如/loop 5m check deploy适合需要高频分钟级访问本地文件的场景。代价机器必须保持开机且会话打开。云端调度使用 GitHub Actions cron如0 6 * * *或 Cloud Routines。适合真正“睡觉时运行”的场景。代价最小间隔通常 1 小时且每次全新克隆看不到本地进程。触发形式除定时外也可通过事件触发如 机器人的 Slack 消息、Emoji 反应、Webhook。调度载体调度器应调用技能claude --skill而非一大段脚本以便维护和复用。混合模式成熟循环通常两者兼用本地做高频内测如每分钟检查 dev server云端做夜间清扫如凌晨三点扫描全库。常见反模式手动循环❌ 循环跑得再好但人类忘了点“运行”它就安静地躺平。❌ 把本地/loop当成“无人的云端作业”一关机就傻眼。✅正确做法根据任务性质选择合适的调度器——本地高频率云端真自主。检查清单你的循环能否在你休假一周、电脑关机的情况下每天依然自动运行并产出成果4. 运行机制五个动作如何在六大部件上实施有了上面的“基础设施”循环运转时的5 个动作就不再是抽象的概念而是对6 个部件的具体调用和组合。动作 (Moves)动作目标依赖哪些部件实施具体实施逻辑如何调用部件1. 发现找活干让系统自动判断今天该修什么 Bug而非人告诉它。技能连接器自动化触发技能SKILL.md技能指示代理使用连接器去读取 CI 失败日志、Jira 工单和 Git 提交记录。2. 移交分配任务把发现的任务安全地派发给“工人”代理。工作区为每个发现的任务利用git worktree创建一个独立的工作区。保证每个代理只在自己的目录里改代码。3. 验证质量把控确保代码正确杜绝自我陶醉。子代理连接器生成器写完代码后换入另一个子代理评估器评估器通过连接器实际运行测试或打开浏览器截图凭事实判断而非凭感觉阅读。4. 持久化存档记忆将结果和状态记下来防止刷新丢失。记忆连接器将进度和结论写入磁盘记忆Markdown文件通过连接器自动更新工单状态、创建 PR同步到外部系统。5. 调度闭环循环让整个流程在无人干预下自动进入下一轮。自动化自动化如 Cron作为总开关。本轮结束后由它决定何时触发下一轮的“发现”动作。5. 开箱即用最小可行的循环工程样例这是论文提供的“麻雀虽小五脏俱全”的完整骨架。您可以直接复制此模板启动您的第一个循环。# 1. 调度 (Scheduling) -- 依赖【自动化】部件# 文件: .github/workflows/triage.ymlon:schedule:-cron:0 6 * * *# 每天早上6点云端运行jobs:triage:runs-on:ubuntu-lateststeps:# 2. 发现 (Discovery) -- 依赖【技能】【连接器】部件-name:读取CI失败和待处理Issuerun:claude--skill morning-triage# 3. 持久化 (Persistence) -- 依赖【记忆】部件# 技能会自动写入 ./state/triage.md 并提交回仓库# 4. 移交 (Handoff) 验证 (Verification)# 依赖【工作区】【子代理】部件-name:并行修复run:|for finding in $(parse ./state/triage.md); do claude --worktree fix/$finding \ -goal tests pass and lint is clean \ draft a fix for $finding done# 5. 人工审核 (Human Review) -- 最后的防线# 注意PR是打开的但【绝不自动合并】不确定的放入 ./inbox/您必须自定义的部分技能文件(.claude/skills/morning-triage/SKILL.md)告诉代理去读哪些 CI 日志、哪些 Issue以及如何判断优先级。状态文件(./state/triage.md)记录上一轮发现了什么处理到了哪一步。5.1. 启动顺序建议论文明确建议不要一上来就追求“五个全装 大规模并行”。安全的成长路径是阶段实施内容目标第1周调度 发现 持久化先让循环能每天早上自动读 CI、写状态文件证明“它能找到活”。第2周添加验证评估器 /goal最关键的一步。先不要开并行用单任务证明“它能对坏输出说‘不’”。第3周添加移交工作区在验证已可靠的前提下开启多任务并行。长期调优评估器的判断标准不断强化“刹车片”这是最值得投入精力的地方。核心原则先证明它能停住再让它跑起来。一个不会拒绝的循环跑得越快离灾难越近。6. 避坑指南对 Loop Engineering 的 5 大常见错误理解在实际操作中您的循环并不一定会因为代码写得好而成功反而会因为观念上的偏差而失败。以下是论文指出的五个致命误区错误理解误区导致的结果反模式正确理解与解法误区1验证就是加个单元测试“点头循环”代理写完代码自己跑一遍测试就说“没问题”。结果累积了一堆测试通过但实际逻辑错误的垃圾代码。验证必须“换人”必须用另一个独立子代理且让它实际运行行为如 Playwright 截图检查 UI而非仅凭阅读代码。误区2循环跑起来就行结果不重要“健忘循环”结果只存在聊天窗口窗口一关第二天循环忘了昨天干了啥从头再来。记忆必须持久化所有结论必须写入磁盘文件Markdown/数据库。代理会忘但仓库Git不会。误区3本地/loop就是“睡觉时运行”“手动循环”合上笔记本盖子循环就停了。你以为它在云端跑其实它在等你开机。区分本地与云端本地适合高频短任务需开机云端适合夜间长跑如 GitHub Actions但云端通常看不到本地文件且间隔 1 小时。误区4找活干也是人的事“盲目循环”循环只负责写代码但每天做什么活还是人脑决定。省了手脚没省大脑。必须自动化“发现”让代理自己去读 CI 报告、新 Issue 来决定今天修什么而不是人类告诉它“修 Bug #123”。误区5循环做决策我当甩手掌柜“认知投降”因为循环太靠谱你放弃了思考看不懂它改的代码。出大故障时你完全失控。永远留一扇门设置人工检查点如绝不自动合并 PR。循环是放大镜放大你的判断力也放大你的懒惰。7. 终极准则两条必须遵守的“黄金铁律”生成器与评估器必须分离。这是循环的“刹车片”。如果没有独立的评估器即另一个子代理您的循环就是一台没有刹车的跑车。先证明它能停住一个坏的结果再放手让它去跑一百个好结果。永远不要移除人工审核点并设置预算上限。在运行前设置每日 Token 上限和最大重试次数防止一个死循环 Bug 烧光账户余额。同时永远不要删除检查点如要求人工点击合并 PR。那个检查点是您保持工程师控制权、避免被机器“架空”的最后一道门。