Loop Engineering：重新定义代码与系统的循环设计
在 AI 辅助编程领域，技术的范式转换往往比想象中来得更快。2023 年，我们还在讨论如何写出完美的提示词（Prompt Engineering）；2024 年，重点转向了为模型提供精准上下文的 Context Engineering；到了 2025、2026 年，Harness Engineering（为 Agent 构建可靠工作环境的工程）开始火爆。
而在近期，一个更具颠覆性的概念在硅谷和开发者社区引发了广泛讨论，它就是 Loop Engineering（循环工程）。
这个概念的爆火源自两位 AI 领域资深工程师的表态：
- Boris Cherny（Anthropic Claude Code 负责人）表示：“我不再手动给 Claude 写提示词了。我跑了一堆 Loop 去提示它，让它自己判断接下来要做什么。我的工作变成了写 Loop。”
- Peter Steinberger（OpenClaw 创始人）也提到：“你不应该再亲自给 Coding Agent 写提示词了。你应当设计那些能够替你去提示 Agent 的循环系统（Loops）。”
随后，Google 软件工程师 Addy Osmani 将这一实践方法论体系化，命名为 “Loop Engineering”。本文将结合行业专家的讨论以及开发者 “老金” 的实战经验，深度拆解 Loop Engineering 的核心理念、底层架构以及如何在实际业务中落地。
1. 什么是 Loop Engineering？
简单来说，Loop Engineering 是用你设计的 “系统” 来代替 “你” 去向 Agent 发送提示词。
在传统的 “人机乒乓球” 模式中，人类扮演了 AI 的实时调度器：你敲入一行 Prompt，等待代码生成，阅读 Diff，发现 Bug，再敲下一行 Prompt。一旦任务复杂度提升，人类的打字速度和注意力的局限性，就会成为系统交付的瓶颈。
而在 Loop Engineering 视角下，一个 Loop（循环） 是一个具有递归目标（Recursive Goal）的闭环控制系统。它的运行公式大约是：
定义目标→收集上下文→执行行动→结果观察→自我修正→下一轮迭代
在这个闭环里，系统会自动发现工作、分发工作、通过测试验证工作、记录进度并决定下一步，直到达成设定的终极目标（或者触发人工介入标准）。
2. 从 Harness 到 Loop：思维范式的升维
在理解 Loop 之前，有必要理清它与 Harness 的区别：
- Harness Engineering（执行环境工程）：解决的是“单次做对”的问题。它通过注入静态规则、环境约束（如 CLAUDE.md）、工具和 Sandbox，为单个 Agent 搭好一个安全的舞台，引导其发挥出模型的极限表现。
- Loop Engineering（循环工程）：解决的是“持续做对”的问题。它处于 Harness 之上，是动态的。它像一个持续运转的后台引擎，会按时间、事件自动触发，生成子 Agent 去干活，自己读取反馈、记录状态，让整出戏自己演下去。
| 维度 | Harness（环境） | Loop（循环） |
|---|---|---|
| 触发方式 | 你手动启动 | 按时间 / 事件自动触发 |
| 执行周期 | 单次会话（Session） | 持续执行，跨会话（Cross-session） |
| 状态管理 | 在上下文（Context）中 | 固化在磁盘 / 文件 / 看板上 |
| 人类角色 | 操作者、命令下达者 | 设计者、规则制定者 |
3. 支撑 Loop 运转的五个构建块与一个 “脊椎”
要设计一个真正可运行且不会无限消耗 Token 的 Loop，需要组合以下 5 个构建块以及 1 个记忆层：
[Memory (记忆层)] <==== 状态总线
||
+-----+-----+
| |
[Automations] [Sub-agents]
| * |
[Skills] --- [Worktrees]
| |
[Connectors / MCP]
- Automations（自动化 / 调度）：循环的心跳。通过 /loop、cron 任务、Webhook 或 GitHub Actions，给 Loop 的启动设定节奏。
- Worktrees（工作树）：解决多 Agent 并行冲突。让不同的 Agent 在独立、隔离的分支 / 目录中安全执行，共享主仓库历史而互不干扰。
- Skills（技能）：固化领域知识。将项目的特定约定（例如 CLAUDE.md）写好，作为 Agent 的标准操作手册，避免模型盲目试错。
- Plugins & Connectors (MCP)：连接外部世界的触角。通过 Model Context Protocol 接入 issue 看板、数据库、API 或 Slack，让 Agent 能够直接创建 PR 或是汇报状态，而不仅是给出修改建议。
- Sub-agents（子智能体）：实现 “Maker（建设者）” 与 “Checker（校验者）” 的角色分离。这是让人类能够放心放手的前提。让一个 Agent 负责改代码，另一个独立的 Agent 负责挑刺，实现自我博弈和质量控制。
- 支撑 ——Memory（记忆层 / 状态层）： Loop 的 “脊椎”。单次会话之外的持久化层（可使用 markdown 文件、Linear 看板或特定 State 文件），记录 “已经完成了什么，还剩下什么”。没有它，跨会话的 Loop 就会迷失。
4. 实战案例：个人知识库的 “知识编译 Loop”
为了更直观地理解，我们可以参考开发者 “老金” 在实际工作中的一个案例 —— 知识编译 Loop。
老金维护着一个个人知识库。在过去，他需要手动收集内容、整理大纲、编写 Wiki 词条并做关联。而现在，这套流程变成了一条自动运转的 Loop：
流程设计
- 信息收集：通过外部 API（RSS、Twitter 抓取）以及个人日常产生的新素材自动汇入至 inbox/ 文件夹。
- 过滤分类：系统加载 /triage 技能，自动过滤 inbox/ 下的杂质，判定保留价值，筛选后转移至 raw/ 临时文件夹。
- 内容编译：加载 /compile 技能，自动将 raw/ 中的新信息合并、改写成深度概念，更新到 wiki/ 目录中。
- 推送洞见：每天早晨执行 /briefing，生成日报（Briefing）推送给老金，同时检测并重新连接那些被遗忘的知识链接。
- 反馈回流：流程末端重新产生需要继续探索的新话题，回馈至初始阶段。
5个构建块在案例中的落地
- Automation：每天早晨 6:03 自动触发 /briefing；外部 RSS/Twitter 定时采集至 inbox/。
- Worktree：在后台 /compile 知识时，使用独立 worktree 运行，防止与老金正在前端手动编辑的文件冲突。
- Skills：将 /triage、/compile、/briefing 的规则细化写成 Markdown，作为固化的 Skill 引导模型。
- Connectors：利用定制脚本将 RSS 订阅和 Twitter 开放接口连入 inbox。
- Sub-agents：在编译阶段引入一个独立的 Verifier Agent。主 Agent 负责撰写新条目，Verifier Agent 拿着新素材比对所有已存在的词条，判断是否有 “涟漪效应（Ripple Effect）” 需要跨词条联动更新。
- Memory：使用 wiki/_changelog.md 和 raw/_registry.md 作为跨会话的状态记录仪。
运行成效
在两个月的稳定运行中，该系统自动过滤了 200+ 篇素材，Wiki 从 0 被系统自动编译维护出 50+ 个核心概念，老金每天早晨仅需花费 3 分钟查看 Briefing 报告，极大地解放了其日常精力。
附：基于 Claude Code 复刻知识编译 Loop 实操教程
借助 Claude Code 原生的指令体系、工作树、定时能力与多 Agent 协作特性，可快速搭建同款知识编译循环，以下为分步落地步骤，适配本地终端 / VS Code 环境。
一、前期准备
- 环境安装 完成 Claude Code 部署（终端 / VS Code 插件二选一），确保终端可正常执行
claude命令，拥有文件读写、脚本运行权限。 - 目录初始化 在本地新建知识库根目录
knowledge-base，进入目录执行命令，一键创建标准文件夹结构：
目录说明：mkdir -p inbox raw wiki scripts worktree log touch wiki/_changelog.md raw/_registry.md log/loop-run.log CLAUDE.mdinbox：原始素材收纳箱；raw：筛选后待编译内容wiki：最终知识库；worktree：隔离工作目录scripts：采集、调度脚本；log：运行日志
二、配置核心 Skill（规则文件）
1. 编写 CLAUDE.md（全局约束）
写入基础行为规则，作为 Claude Code 的全局技能手册，粘贴内容至根目录 CLAUDE.md：
# 知识库循环工程规则
## 通用要求
1. 所有操作保留日志至 log/loop-run.log，标注执行时间、执行环节
2. 禁止直接修改用户正在编辑的文件，编译任务统一使用 worktree 隔离运行
3. 全流程分为：素材分拣(triage)、内容编译(compile)、日报生成(briefing)三大环节
## 角色划分
- Maker Agent：负责内容撰写、词条合并、新知识入库
- Verifier Agent：独立校验，检查词条关联、内容冲突、知识链接缺失，必须输出校验结论
2. 拆分专项技能文件
在根目录新建 3 个技能指令文件，对应循环三大环节：
triage.md（素材分拣规则）
# 素材分拣 Skill
读取 inbox/ 下所有文件，执行过滤：
1. 剔除广告、重复、无价值碎片化内容
2. 有效素材分类归档至 raw/，并在 raw/_registry.md 记录文件名、来源、入库时间
3. 清空已处理的 inbox 无效内容
compile.md（内容编译规则）
# 内容编译 Skill
读取 raw/ 待处理内容：
1. 梳理知识点，撰写结构化 Wiki 词条存入 wiki/
2. 对比 wiki 已有词条，补充关联引用
3. 在 wiki/_changelog.md 记录本次更新条目
4. 完成后清空已编译的 raw 内容
briefing.md（日报推送规则）
# 每日简报 Skill
1. 读取 _changelog、_registry 日志，汇总当日新增知识、更新词条
2. 检查 Wiki 内断裂的知识链接并标注修复建议
3. 生成当日简报保存为 log/daily-brief.md
三、搭建自动化调度（Automation）
依托 Claude Code 内置 Loop 指令 + 系统 Crontab 实现定时自动触发，分为两步：
-
单次循环指令（终端测试） 在
knowledge-base目录执行，手动启动一轮完整循环，验证流程可用性：claude "/loop run triage then compile then briefing --worktree=worktree"指令释义：
/loop是 Claude Code 原生循环指令，依次执行分拣、编译、简报，强制使用独立工作树。 -
配置定时任务（后台自动运行） 以 Linux/Mac 为例，配置 Crontab 实现每日 6:03 自动执行：
- 打开定时任务编辑：
crontab -e - 添加一行（替换为你的实际目录路径）：
3 6 * * * cd /你的绝对路径/knowledge-base && claude "/loop run triage then compile then briefing --worktree=worktree" >> log/cron-run.log 2>&1Windows 系统可使用「任务计划程序」，创建定时任务调用上述终端命令即可。
- 打开定时任务编辑：
四、配置双 Agent 校验（Sub-agents 角色分离）
利用 Claude Code 多会话能力拆分 Maker / Verifier，杜绝 “自审自改”：
- 新建脚本
scripts/compile-loop.sh，实现编译 + 独立校验串联：#!/bin/bash # 1. Maker 执行内容编译 claude "@compile.md" --worktree=worktree/maker # 2. 独立 Verifier 执行校验 claude "按照 CLAUDE.md 校验 Wiki 词条关联与内容完整性，输出问题清单" --worktree=worktree/verifier - 赋予执行权限并更新定时指令：
修改 Crontab 任务，调用该脚本完成双角色协作。chmod +x scripts/compile-loop.sh
五、接入外部数据源（Connectors 对接 RSS / 抓取）
如需自动采集网络素材进入 inbox，可借助 Python/Shell 简易采集脚本（放入 scripts 目录），搭配定时任务同步内容，示例极简 RSS 采集逻辑：脚本运行后自动将资讯写入 inbox，作为循环的数据源入口。
六、状态记忆与异常告警（Memory + 容错）
- 记忆层校验：全程依靠
wiki/_changelog.md、raw/_registry.md、日志文件持久化状态，Claude Code 每次循环会自动读取历史状态，实现跨会话衔接。 - 异常通知：在脚本末尾添加 Webhook 指令，循环执行失败时推送消息至企业微信 / 飞书 / Slack，避免后台静默故障。
七、上线与迭代建议
- 先关闭定时任务，手动执行多轮
/loop测试，确认目录读写、分类、编译、校验全部正常； - 遵循从小迭代原则：初期只保留「分拣 + 编译」基础循环，稳定后再新增简报、外部采集、告警能力；
- 持续优化 Skill 文件：根据知识库使用场景，不断细化规则，降低模型出错概率。
整套方案完全基于 Claude Code 原生能力搭建，无需复杂第三方服务，落地后即可实现和案例一致的全自动知识管理循环。
5. 设计 Loop 的三个实用原则
如果你也准备着手构建自己的第一个 Loop，这里有几条实战中总结出的教训：
- 从小开始，逐步迭代 不要指望第一天就搭建出一套复杂的 5 层全家桶架构。老金的第一版 Loop 极其精简：仅由一个 cron 定时器 + 一个 skill + 一个用于保存 memory 的 Markdown 文件组成。跑通基本逻辑后，才逐步加入了 Checker 机制（Sub-agent）与外部 Connector。
- Maker ≠ Checker（避免 “既当裁判又当选手”） 如果让同一个 Agent 既负责工作，又负责判断 “工作是否需要修改”，模型为了走捷径，往往倾向于得出 “不需要修改” 的结论（在老金早期尝试中，自我审查下的更新率只有 5%）。当引入专门的 Checker 拆分步骤后，这一更新转化率跃升到了 30%。
- 让沉默成为敌人 Loop 通常是在你看不见的后台静默运行的。如果它执行失败而没有任何声响，可能几天后你才会发现。因此，请确保在关键步骤失败时加入通知机制（如 Webhook / Web Push），并在 Memory 层（如 _changelog.md）输出可被快速 Grep 检索的格式化日志。
结语：谁需要 Loop？
需要明确的是，Loop Engineering 并不是对所有场景都适用的银弹。它存在着显著的局限性：对于一次性的、目标难以被客观验证的模糊任务，设计 Loop 不仅会消耗大量 Token 成本，还容易陷入逻辑死循环。
但对于那些具备明确可验证目标、需要持续演进、高频且单调重复的工程流水线（例如持续 CI 监控、依赖项升级、自动化测试修复以及多源数据编译），Loop 工程展现出了极高的杠杆作用。
正如老金所言：
“两个人可以构建一模一样的 Loop 结构，却得到相反的结果。一个人用它在自己深刻理解的领域中成倍提升效能；另一个人用它来逃避去理解工作本身。Loop 无法分辨这两者的差别，但你知道。如果你对自身领域的判别力不够，Loop 只会带你更快地犯错。”
未来的资深工程师，也许不再是代码行数的产出者，而是整个闭环反馈系统的设计师。
互动话题：从 Prompt Engineering → Context Engineering → Harness Engineering 再到如今的 Loop Engineering，你日常使用 AI 编程时，处在哪个阶段？我是阿宇，欢迎大家评论互动。
内容参考：Smith铜匠・十点睡觉 on X: "Harness之后,最近爆火的 Loop Engineering 是什么？怎么做？" / X，老金 on X: "Loop Engineering 实战" / X
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
23
0- 0
已为社区贡献10条内容
所有评论(0)