大家好我是二哥呀。Prompt Engineering、Context Engineering、Harness EngineeringAI 圈造新词的速度比大模型迭代还快。这不Loop Engineering 新鲜出炉了。有人说Prompt Engineering 是手动挡Loop Engineering 是自动挡。但要我说都特喵的一样好吧。只是我们不再写简单的 Prompt 等 LLM 回复后写下一条而是尽量写一套更复杂的提示词让 Agent 多消耗一点 token。哦不。尽量榨干 LLM 的能力让它在一个 loop 里自己转起来自己找信息自己验证结果自己调整方案直到完成目标。01、Loop Engineering 是什么Prompt Engineering 时期大家研究的是“怎么写一句好 Prompt”措辞、格式不断打磨单次输入的质量。Context Engineering 时期关注点从写什么转向给模型看什么。CLAUDE.md、RAG、摘要压缩、上下文窗口管理核心问题变成了如何在有限的上下文窗口里塞进最有价值的信息。再后来Harness Engineering 把 Agent 当成一个工程系统来设计涵盖工具集成、状态持久化、Sub-agent 编排关注的是整个执行框架。Loop Engineering 站在 Harness 之上解决的是怎么让这套系统自己转起来。一个 loop 能自己启动知道去哪找信息做完一轮知道怎么检查结果失败了知道要不要重试每轮把进展记到指定位置也知道什么时候该停下来交给人。Harness 是基础设施Loop 是让基础设施自动运转的设计方式。02、Loop 的六大组件在我看来Loop 的六大组件为定时任务、Worktree、Skill、MCP、Sub-agent、Memory。这六个组件构成了一个完整的 Loop Engineering 技术栈。缺一不可缺了哪个都不算真正的 loop。定时任务在 Claude Code 中/loop 命令就是一个定时任务触发器。/loop 5m /code-review表示每 5 分钟触发一次代码审查。传统 cron 执行的是确定性脚本执行 A 脚本、输出到 B 文件而 loop 里的定时任务触发的是一个 Agent 会话。Agent 会根据当前上下文自主决策下一步做什么。WorktreeWorktree 允许在同一个仓库下创建多个工作目录每个工作目录对应一个独立的分支。在 loop 场景中一个 Agent 在 worktree A 里改代码另一个 Agent 在 worktree B 里做审查彼此的文件操作互不干扰。没有隔离的多 Agent 并行操作文件冲突是必然的。Claude Code 提供了--worktree参数启动隔离实例Sub-agent 也支持isolation: worktree配置项。启用后Agent 在一个独立的 Git worktree 中工作改动不会影响主工作目录。如果 Agent 没有产生任何修改worktree 会被自动清理不会留下无用的分支。# 在独立 worktree 中启动 Claude Codeclaude--worktree修复 issue #42 的内存泄漏问题SkillSkill 是技能包。一个SKILL.md文件加上可选的references/目录记录一个工作流的工作规范、构建命令、审查标准、常见问题的处理方式。没有 SkillAgent 不知道项目用什么构建工具不知道测试怎么跑不知道代码风格偏好。Skill 把这些信息持久化下来让 loop 的每一轮都能站在同样的知识基础上执行。Claude Code 和 Codex 都使用相同的 Skill 格式一份 Skill 写好之后两个工具都能直接使用。一个典型的 Skill 结构如下。.claude/skills/daily-review/ ├── SKILL.md # 主文件审查策略、输出格式、判断标准 └── references/ ├── coding-style.md # 项目编码规范 └── common-bugs.md # 历史高频 bug 清单loop 每一轮启动时加载 SkillAgent 就知道“用什么标准审查”而不是“凭感觉审查”。MCPMCP 是连接器让 loop 能执行真实的跨系统操作。没有 MCPAgent 只能读写本机文件和执行本机命令。有了 MCPAgent 可以创建 PR、更新远程任务、发送 IM 消息、查询数据库、操作浏览器。MCP 已经成为 Agent 工具生态的事实标准。一个 MCP 服务器写好之后Claude Code、Codex 都能接入不需要为每个工具单独开发插件。loop 的目标往往不只是修改代码还包括提交 PR、通知团队、更新项目管理工具。这些操作全靠 MCP 完成。举个例子一个每天早上 9 点运行的 loop扫描仓库里所有过期的依赖自动创建升级 PR然后在飞书通知团队审查。这里面“创建 PR”需要 GitHub MCP“发飞书消息”需要 Feishu MCPAgent 本身只负责决策和编排。Sub-agent一个 Agent 负责修改maker另一个 Agent 负责审查checker。绝对不能修改者给自己的作业打分这是工程领域的基本常识。在 loop 中这种分离通过 Sub-agent 实现。Claude Code 的 Sub-agent 机制会为每个子任务启动一个独立的 ReAct 循环带有过滤后的工具注册表。Sub-agent 完成后结果返回给主 Agent 整合。搭配 worktree 隔离使用多个 Sub-agent 可以并行修改代码而不产生冲突。// Workflow 脚本中的 maker-checker 模式constfixawaitagent(修复这个安全漏洞,{label:maker,isolation:worktree})constreviewawaitagent(审查这个修复方案检查是否引入新问题,{label:checker,agentType:code-reviewer})maker 在隔离环境中修改代码checker 独立审查修改结果。两个 Agent 互不干扰判断也互不影响。MemoryMemory 是 loop 跨轮次保持状态的机制。模型没有记忆。每次对话开始时上一轮的所有上下文都消失了。如果 loop 第 3 轮需要知道第 1 轮做了什么修改这个信息必须写在模型之外的地方比如文件系统、数据库、或者其他外部存储。Claude Code 的 CLAUDE.md 文件和 memory 目录就是一种 Memory 实现。每轮 loop 结束时Agent 可以把关键结论写入文件下一轮启动时读取这些文件就能接续上一轮的进度。Memory 是六个组件中最容易被忽视的也是 loop 能否真正“积累经验”的关键。没有 Memoryloop 的每一轮都是独立的它能重复执行但不能从过去的执行中学到东西。一个典型的场景loop 第 1 轮扫描到 10 个 bug修复了 3 个剩余 7 个写入memory/pending-bugs.md。第 2 轮启动时读取这个文件继续修复剩下的 7 个而不是重新扫描一遍、重新发现同样的 bug。03、Claude Code 中的 /loop/loop 是 Claude Code 内置的定时任务命令语法如下。/loopintervalprompt or slash command间隔时间支持分钟m和小时h默认 10 分钟最小间隔 1 分钟。不指定间隔直接/loop /code-review就是每 10 分钟执行一次。三个实际场景场景一定时代码审查/loop 30m /code-review--fix每 30 分钟扫描当前 diff找出潜在的 bug 和优化点能自动修的直接修。适合长时间开发过程中保持代码质量。场景二监控 CI 状态/loop 5m 检查当前分支的 CI 状态如果有失败的 job分析原因并尝试修复每 5 分钟检查一次 CI pipeline发现失败就自动排查。PR 提交后不用一直盯着 CI 面板Agent 会在后台持续跟进。场景三技术债扫描/loop 4h 扫描最近4小时新增的 TODO 和 FIXME 注释整理成清单写入 docs/tech-debt.md04、用 Loop 回复 GitHub IssuePaiAgent 是一个工作流编排项目类似扣子和dify刚好GitHub上有一些issue没有回复我们就可以借助Claude Code的 /loop 命令让 Agent 自动回复这些 issue。三个问题都很简单#6 “请问这个项目已经开发完成了吗还是在进行中”#5 “这个和 PaiFlow 有什么区别”#4 “可以二开吗”但需要了解项目背景才能准确回答。这正是 loop 适合接管的场景高频重复、规则明确、有明确的完成标准issue 被准确回复。一条命令启动/loop 30m 检查 itwanger/PaiAgent 仓库的openissue对没有回复的 issue 根据项目 README 和已有信息生成准确的回复并提交评论。已回复过的跳过不要重复评论。这条命令拆开来看每一部分都对应 loop 的一个设计要素。30m是心跳频率每 30 分钟唤醒一次 Agent。中间那段自然语言是任务描述Agent 每轮需要做什么扫描 issue → 判断是否已回复 → 生成回复 → 提交。“已回复过的跳过”是防重机制。没有这句话Agent 每轮都会对所有 open issue 重新评论。Agent 的执行过程Agent 启动后实际的执行过程是这样的。第一步通过 GitHub CLI 拉取所有 open issue 的标题、正文和已有评论。这一步依赖 MCP 或者命令行工具对应六大组件中的 MCP。gh issue list--repoitwanger/PaiAgent--stateopengh issue view6--repoitwanger/PaiAgent--jsontitle,body,comments第二步Agent 判断哪些 issue 需要回复。#3 和 #1 已经有 owner 的评论了跳过#6、#5、#4 没有任何回复标记为待处理。第三步Agent 读取项目的 README 和仓库信息。它需要知道 PaiAgent 是什么、用了哪些技术栈、和 PaiFlow 的关系、是否允许二次开发这些信息全靠项目文档提供。这一步对应六大组件中的 Skill——项目知识的持久化。知识的质量直接决定回复的质量。第四步生成回复并逐条提交。gh issue comment6--repoitwanger/PaiAgent--body项目目前仍在持续开发中...gh issue comment5--repoitwanger/PaiAgent--bodyPaiAgent 和 PaiFlow 的定位不同...gh issue comment4--repoitwanger/PaiAgent--body当然可以PaiAgent 是开源项目...三条评论在同一轮 loop 内全部提交完毕。回复效果看一下 Agent 实际提交的回复。#6 的回复——问项目进度的Agent 准确说明了项目在持续开发中列出了已完成的核心功能可视化编辑器、DAG 引擎、LangGraph4j 引擎、Skills 技能系统、多模型接入并给出了教程链接。#5 的回复——问 PaiAgent 和 PaiFlow 区别的Agent 从架构层面区分了两个项目PaiAgent 是轻量级单体架构适合学习PaiFlow 是微服务架构面向企业生产环境。这个信息是 Agent 综合了 README 和 #3 里 owner 的历史回复推断出来的。#4 的回复——问能否二次开发的Agent 确认可以并给出了 Fork → 开发 → 保留引用说明的建议流程。这三条回复都不是模板化的敷衍而是基于项目实际情况生成的。这个 Loop 用到了哪些组件回头对照六大组件。定时任务/loop 30m提供了每 30 分钟一次的心跳MCP通过 GitHub CLI 读取 issue、提交评论连接了外部系统Skill/项目知识README 和仓库元信息为 Agent 提供了回复所需的上下文MemoryAgent 通过检查已有评论判断是否重复避免同一个 issue 被回复多次Worktree 和 Sub-agent 在这个场景里没用到——因为不涉及并行修改代码也不需要写查分离。更进一步这个 demo 只是最简单的一层。还可以做得更多。第一加上 Skill 文件issue-reply-guide.md定义回复的语气、格式、哪些问题需要转交人工处理Agent 就不只是回答问题而是按照你的标准回答问题。第二加上 Memory让 Agent 记录“#5 提问者关心的是架构选型”这类信息。下次同类问题进来Agent 可以直接引用之前的回答而不是每次都从头推理一遍。第三加上 Sub-agent一个负责分类 issuebug report、feature request、usage question另一个负责生成回复。分类 Agent 的判断决定了回复 Agent 用什么策略——回答使用问题时引用文档确认 bug 时给出排查步骤。从一条 /loop 命令开始逐步叠加组件loop 的能力边界就这样被不断扩大了。05、Loop 的代价上 loop 之前三个问题必须想清楚。Token 消耗loop 一旦跑起来就不是问一次答一次的计费模式了。Agent 会反复读上下文、反复调用工具、反复验证结果有时还会启动多个 Sub-agent 同时工作。换句话说这玩意虽然牛逼但如果设计不当可能会烧掉大量 Token。就比如说loop 中的 Agent 调用了一个有 bug 的 MCP 工具5 分钟内重试了 400 次。工具每次返回错误Agent 每次都觉得“再试一次应该可以”。没有熔断机制的 loop 就是一台烧钱机器。几个控制成本的手段。给 loop 设置合理的最大迭代次数防止 Agent 在失败循环中空转/loop 的每轮执行有独立的上下文窗口不会在多轮之间无限累积上下文安全边界loop 里的 Agent 有文件读写权限、命令执行权限还可能有 MCP 授予的外部系统访问权限。一个设计不当的 loop 有可能在凌晨 3 点自动向生产环境推送未经审查的代码。什么场景适合 Loop适合 loop 的场景有几个共同特征高频重复、规则明确、有自动化验证手段。代码审查每隔 N 分钟扫描 diff有 linter 和测试做验证CI 修复CI 失败后自动分析日志并尝试修复测试通过就是验证文档同步代码变了自动更新文档diff 可以检查依赖升级自动创建升级 PR 并跑测试安全扫描定期检查已知漏洞