从Harness Engineering到Loop Engineering，AI工程领域正经历概念爆炸式增长。本文深度解析谷歌提出的Loop Engineering框架，拆解其六大核心组件如何通过自动化工作流、独立环境隔离、技能封装等机制，实现AI代理从单次任务执行到持续智能进化的质变。

最近AI圈继harness engineering后刚4个月左右的时间，又出现了一个为各方大佬频繁讨论的loop engineering，那么为何从prompt、context到26年harness、loop，新的工程出现的这么频繁，到底是造概念还是真的技术更迭的太快？开头的引句其实是我的理解，这篇《道德经》中有一句话：周行而不殆，可以为天地母。原意为：循环运行而不止息，可以作为天下万物的母体。是老子对”道”的理解，其实和loop engineering的本质，也就是“循环”工程，讲的原理乃尽似相同。

一、loop engineering概念

loop engineering到底是什么？事情的开始是在6月7号，Openclaw的创始人Peter Steinberger在x社交平台发文：“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”

Claude code负责人Boris Cherny同样也表示过：“I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops”。

这两位大佬，其实表达的都是一个观点，简单点说就是：他们都不再去编写智能体提示词了，而是去设计一个loop循环来代替自己去指示你的智能体。

而loop engineering这个概念，由谷歌的Addy Osmani特针对loop整体讲解总结出的一篇文章。loop engineering（循环工程）：循环工程是指用设计系统来代替你来引导智能体，而不是由你来执行指令。

原文参考下述：https://addyosmani.com/blog/loop-engineering/

二、LE框架拆解

如上图哈：从框架上拆解loop engineering，一共有5个核心的环节，外加一个Memory/State。其实就是一个外部记录额外信息的内存，保存在电脑本地的磁盘中，这个部分可以放在下面的拆解中再详情说明。

先拆解一个可视化的六要素体系：

逐步分开来看：

1. Automations

“Automations”的核心是让loop真正跑起来，而不是和react一样只跑单次任务。

有意思的是，Addy Osmani把它称为loop engineering中的”心跳”，有了自动化后，Loop 才像心脏一样，持续、有节奏地跳动。这个比喻比较形象描述了”Automations”在整个loop工程体系中的作用，可以按计划自动触发，自己完成发现问题和分类筛选。例如在codex中，这一步的设计你可以创建一个“自动化”任务，自由选择project、prompt、运行的频率（多久/何时触发）、以及运行的环境如何。有问题的运行/处理不了的问题，会自动透传到Triage收件箱等待人工审阅，而没有问题的结果则会自动归档。除此之外，Automation可以去调用一个skill，只需要触发$skill-name就行，而不是把一大段指令粘贴进去。这么做的好处就是更方便的保持了循环任务的可维护性，逻辑的变化可以只改skill而不动调度的本身。

在这里还提到了两个会话内的原始能力/loop、/goal。 /loop 会按一定节奏重复运行，比如每隔一小时去获取最新的AI热点新闻，时间驱动任务。每隔小时就会跑一遍这个任务，不管结果怎么样都不会改变

/goal则是以完成的条件为终，会一直运行直到设定的条件被验证后真正成立为止。那么在这里会有一个关键设计是每次循环结束后，都会有一个独立的小模型检查验证任务是否完成，也就是说写代码的agent会和review代码的agent分开，其实和下面sub-agent的思路大概相似，双模型的架构防止代码撰写的agent造成自欺现象。

那说明到这了，其实大多数人应该也能明白和cron任务的区别在哪里了。定时触发的本质是相同的，不同的是问题的自我发现和多层分发的功能，这点极大的方便了内部的自动化工作，例如在日常问题分类、总结 CI 失败、编写提交简报等，从问题的被动等待- >主动提交，这点是单cron难以做到的。

（os：所以不用再喊着loop 就是cron啦，又是造概念造概念。。。。。。）

2. Worktrees

工作树的能力应该很多人都不陌生了。总结就一句话：防止agent之间互相打架，也就是给每一个agent隔离出来独立的工作环境。

一个不恰当的比喻：想象一下在同一个屋檐下让两条狗在一个盆里吃饭，是不是会互相抢夺干架，哪怕给每条狗都配一个单独的饭盆，有时也避免不了。那么解决的方法就是吃饭的时候把两条狗分开，互相看不见也就不存在干架的问题了。当然这里把agent比喻成了狗狗，吃饭就是在运行任务，干架就是会造成任务代码冲突和损坏。

所以，worktree的本质就是：一旦多个智能体运行时，共享的那个文件就会存在冲突。两个agent写入同一个文件，就像两个工程师没沟通就提交了同一行代码一样。而Git 工作树解决的就是这个冲突的问题，它是一个位于独立分支上的独立工作目录，共享同一个仓库历史记录，因此一个agent的编辑完全不会影响到另一个agent的检出。

在这点上无论是codex还是claude都内置了worktree的支持，因此多个线程可以同时访问同一个仓库而不会相互干扰。claude code中使用git worktree 命令，通过–worktree 标志将会话搁置在一个独立的检出目录中，并通过 ` isolation: worktree 设置将工作树配置到subagent上，这样每个辅助程序都能获得一个全新的检出目录，并在完成后自动清理自身。简单说就是给目前自己的会话创建一个独立的副本，从而不干扰主线，且运行合并完成后支持自动删除。（就如同工作中创建另一个文件的副本，修改完复制过来后再删除的这个动作）

但是，worktree解决的只是机械层面的冲突，最终决定权还是在于我们的瓶颈。技术上支持同时运行多个agent，但是每个pr都需要review，人工判断和审查的成本是多少？当然，你也可以用另一个代理去充当人工审查的角色，代替人工去re pr，但是完全放任的状态真的是一个合格的loop吗？这个观点文中的后面也会讨论到哈

3. skills

skill的本质其实就是一个文件夹，如同下结构：

my-skill/

├── SKILL.md ← 核心：指令 + 元数据

├── scripts/ ← 可选：脚本

├── references/ ← 可选：参考文档

└── assets/ ← 可选：其他资源

每一次新的session对于agent来说都是一个“0基础”的新的开始，而更危险的不是“0基础”，而是Agent 会用自信的猜测来填补空白的部分。（也就是最经典的幻觉问题，它不知道的时候它会自信的去“编故事”）每一次意图的空白编补，都是在累积错误的风险。skill就是为了避免这种「意图债务」反复造成损失的关键所在。skill将意图写在外部，包括约定、构建步骤、代码规范以及“由于某个事件，我们不这样做”之类的规则，这些规则只需编写一次，agent每次运行都会读取。如果没有技能，循环每次都会从零开始重新推导你的整个项目。这会造成大量的空白工作。

其实简单来说，skill就是把要和agent交代的内容（如同你的上级交代给你的工作内容和注意事项）写在了系统的外面，让 Agent 自己去读取，而并不是靠每一次的seesion中口头和它阐述。

在codex和claude code这两个工具中是如何运用的？其实就是上述skill文件夹的结构，都会包含一个 SKILL.md 文件，其中有指令和元数据，以及可选的脚本、参考文档和资源。当你使用 $ 或 /skills 调用时运行技能，或者任务意图与技能的描述相匹配的时候自动运行skill。

（听上去这段是不是有点像对harness中项目规则文件的描述，其实本质是在harness中约束的基础上加入了更多的描述。且保存在电脑的本地磁盘中让agent自动读取。而skill结构的本身是中性的，可以在skill.md这个文件中放任何东西，比如项目测试的规范配合scripts的运行，比如代码审查的流程及范式。在一个loop中，每一次的循环打开的每一次的对话，都需要skill）

4. Plugins and connectors

插件和连接器、基于mcp构建的连接器，这些是agent时代下老生常谈的能力了。对于一个loop，只能访问文件系统的循环是一个很小的循环，而构建的连接器可以让agent读取你的问题跟踪系统、查询数据库、调用暂存 API 并在 Slack 中发送消息等等。

一个没有 Connectors 的 Agent，通常是一个封闭的文件系统。它可以告诉你bug 对应哪个 issue、自己开 PR、检查 CI 有没有过、提供修复方案等等，但是仅限于告诉你，剩下的实际操作都需要你来完成。有了 Connector的Agent则能做到+Issue Tracker（GitHub Issues、Linear）、链接数据库去查询和测试数据、调用Staging API接口、通知内部团队等动作。整个链条可以自己跑完，不仅局限于“方案、方案、方案”的文件系统中了。

一个通用的mcp connectors，在codex和claude code两个工具中都支持使用。插件则将连接器和技能捆绑在一起，这样就可以一次性安装你的配置，而无需从记忆中重新构建整个系统。

5. Sub-agents

子智能体-整个loop工程中最为重要的一环。这里面主要提出的是一个核心的做法，就是通过subagent分成多个协作者（如同你公司的部门架构），把loop循环中的写代码和审核代码分开。由于编写代码的模型review自己写出来的代码的时候表现比较宽松，打分较高，通常如果在second agent中用另一个不同指令的不同模型，很容易会审查出第一个agent review通过的代码逻辑问题。这就是常说模型的Self-preference bias（自我偏好偏差）。当然，subagent不仅仅只局限于区分写代码和re代码，任务规划、方案研究/探索、案例测试都可以通过subagent独立完成，除了记忆清晰之外，并发的任务进程以及各精专一件工作，配合worktree更能保证项目代码的规范。

当然，目前最热门的两款工具codex和claude code肯定也均都适配了这个能力。Codex 是发出请求时才会生成子代理，同时运行，然后将结果合并成一个答案。可以在 .codex/agents/ 目录下以 TOML 文件的形式定义自己的代理，每个代理都包含名称、描述、指令以及可选的模型和推理难度。比如：

# .codex/agents/security-reviewer.toml

name = “security-reviewer”

description = “专门审查安全漏洞的 Agent”

instructions = “检查所有输入验证、SQL 注入风险、权限控制漏洞”

model = “o3”

reasoning_effort = “high”

# .codex/agents/explorer.toml

name = “explorer”

description = “快速探索方案可行性的 Agent”

instructions = “只读，快速评估技术方案，不做实际修改”

model = “fast-model”

reasoning_effort = “low”

这样，安全审查员可以是一个高难度的强大模型，而负责explorer则可以是一个快速的只读代理。

Claude Code 也同样采用类似的方式，在 .claude/agents/ 下创建subagent，并由agent团队在它们之间互相传递任务。

还有一个重要的，永远避不开一个讨论点：tokens。子代理会消耗更多tokens，因为每个子代理都会执行自己的模型和工具工作，所以应该把token用在值得付费的第二意见上（也就是真正信任的Verifier，因为loop是在人力不监督的环境下运行，所以这在loop内部尤为重要），这基本上也是 Claude Code 的 /goal 命令的底层工作原理：由一个全新的模型来判断循环是否结束，而不是由之前执行工作的模型来判断，这种maker和checker的分离机制也应用到了停止条件本身。

6. State file

还有最后一点–state file。固定存储在外部/本地的进程文件，可以是 Markdown 文件，也可以是 Linear 看板。毫不夸张的说可以是整套loop engineering中的“脊梁”。独立于单个对话之外、它会记录什么被尝试过,什么通过了,什么还开着,所以明天早上的运行能接着从今天停下的地方继续运行。由于loop是一个循环系统，而不是一个独立的对话/任务，所以它的“连续性”则需依赖state file去保障，可以兜底loop累积的动态进程，这也同样和Automation节奏触发的效果完成闭环。

三、Loop到底长啥样？

先看图

上面这个循环的流程图大体就是整个loop e的架构了。

下面真实拆解一个loop engineering的案例：

每天早上，代码仓库都会运行一个自动化脚本（Automation），脚本会调用一个分类技能，读取昨天的持续集成失败记录、未解决的问题、最近的提交记录，并将结果写入 Markdown 文件或 Linear 看板（state file）。对于每个值得解决的问题（模型判断），脚本会创建一个独立的工作树（worktree独立运行环境），并派出一个子代理（subagent）来编写修复方案；第二个子代理（subagent）则会根据项目技能和现有测试用例来审核这些修复方案。

连接器（connecter）让循环能够打开 PR 并更新工单。任何循环无法处理的问题都会进入我的分诊收件箱（Automation，和cron的区别所在）。

（state file）状态文件是整个流程的核心，它记录了哪些尝试过、哪些通过、哪些仍然未解决，以便明天早上运行能够从今天停止的地方继续。

这就是一个完整的loop engineering案例，尽管任务并没有那么复杂，但在整个loop循环中各个环节仍在其中发挥着不可或缺的作用

四、光说不练假把式之—loop实践

基于上述的流程，用claude code项目中实践loop engineering。首先先对标明确各环节在claude code中对应的能力列表，如下

背景：现在需要维护一个电商平台的订单服务，这个服务需要做到以上案例中的三点：

1. CI 在 main 分支上偶尔跑红（flaky test 或真 bug）
2. GitHub 上积累一些标了 bug 标签、没人认领的 issue
3. 生产环境的错误监控（用一个简化的 alerts.json 模拟 Sentry webhook）会新增一些异常堆栈

任务目标：搭一个 loop，每天早上自动扫一遍这三个来源，挑出”值得修的”，在隔离的 worktree 里让一个 agent 起草修复，再让另一个独立 agent 拿着项目规范和测试去verify，verify 通过就自动开 PR、更新进度看板；verify 不通过或者判断风险太高，就丢进”人工分诸箱”等你来看。

前置准备：先建好本教程会用到的目录骨架（默认已安装claude code且版本在v2.1.72+）

创建一个项目文件“order-service”，然后在终端这个项目文件的目录下（cd order-service)，运行以下命令：

mkdir -p .claude/skills/triage-findings

mkdir -p .claude/skills/pr-conventions

mkdir -p .claude/agents

mkdir -p .claude/hooks

mkdir -p loop-state

echo “.claude/worktrees/” >> .gitignore

正式开始—第一步：需要先在loop-state目录下创建一个.md文件backlog.md，这就是一个markdown的看板，相当于上面环节中的state file，在本地磁盘上以文件的方式记录了任务的进程详情。

# Order Service · 自愈 Loop 看板

> 本文件由 loop 自动维护，人工只在 `## 待人工确认` 区块留言。 > 格式：`- [ ] <ID> <一句话描述> (来源: ci|issue|alert, 发现时间, 状态)`

## 待分类

（/loop 每次运行后把新发现塞进这里）

## 处理中

– [ ] ORD-2026-0031 order总价四舍五入误差导致对账不一致 (来源: alert, 2026-06-30, worktree: fix-ord-0031, agent: fixer, 状态: 等待verifier)

## 已验证待开PR

## 已完成

– [x] ORD-2026-0029 库存扣减并发下多扣 (来源: issue#412, 2026-06-28, PR: #418, 状态: 已合并)

## 待人工确认

– [ ] ORD-2026-0030 支付回调偶发500 (来源: alert, 2026-06-29, 原因: verifier 两轮都判定”无法在不改动支付网关签名逻辑的前提下修复”, 需要人来定策略)

同时，需要把项目级的”意图”和”规则”写进 CLAUDE.md放进项目目录下（注意要和系统.claude/CLAUDE.md的全局文件分开），这是 loop 里每一次 agent 冷启动都会自动加载并读取的那部分。

# CLAUDE.md

## 项目

order-service：处理下单、库存扣减、支付回调的核心服务。

## 硬规矩（出过事故，别再犯）

– 金额计算必须用 `Money` 类型（cents 整数），禁止用 float 做金额运算—— 2025-11 的四舍五入 bug 就是因为用了 float。

– 支付回调（`/webhooks/payment/*`）的改动必须过 `payment-signature.spec.ts`， 不允许仅靠单测通过就合并，历史上出过签名校验被绕过的事故。

– 数据库迁移用 `pnpm db:migrate:new`，禁止手写 SQL migration 文件。

## 验证方式

– `pnpm test` 全绿 + `pnpm lint` 无 error 才算”完成”。

– 涉及金额/库存逻辑的改动，额外跑 `pnpm test:invariants`。

## 看板

进度记录在 `loop-state/backlog.md`，每次收尾前更新它。

创建2个skill技能，一个分类判断技能，还有一个pr规范技能。这两个skill是后续执行步骤的关键所在。

创建 .claude/skills/triage-findings/SKILL.md：

—

name: triage-findings

description: 扫描 CI 失败、带 bug 标签的 GitHub issue、以及 alerts.json 里的新异常， 判断哪些值得自动修复、哪些该丢给人工，并把结果写入 loop-state/backlog.md。 当用户说”跑一次分类”、”看看有什么新问题”或作为 /loop 的一部分被调用时使用。

allowed-tools: Bash(gh *), Bash(pnpm *), Read, Write, Edit, mcp__github__list_issues,mcp__github__get_issue,mcp__github__create_issue

—

## 数据源

– CI 状态：!`pnpm test 2>&1 | tail -30`

– 打了 bug 标签且未指派的 issue（如果本地仓库还没连 GitHub，跳过这一项）：

!`gh issue list –label bug –state open –json number,title,createdAt 2>/dev/null || echo “[]”`

– 最新告警：!`cat alerts.json 2>/dev/null || echo “[]”`

## 判定规则

一条发现”值得自动修”，需要同时满足：

1. 能用一句话描述根因猜测（不是”未知崩溃”这种模糊描述）；

2. 不涉及支付网关密钥、加密算法、权限模型这类高风险区域（对照 CLAUDE.md 硬规矩）；

3. 过去 7 天内没有对同一模块的自动修复被人工回退过（查 `loop-state/backlog.md` 的”已完成”区）。

不满足任一条，直接归入”待人工确认”并写明原因，不要尝试自动修。

## 输出

把每条新发现追加到 `loop-state/backlog.md` 的”待分类”区，

格式：`- [ ] <生成的ID> <一句话描述> (来源: xxx, 发现时间: xxx)`。

对判定为”值得自动修”的条目，将其移入”处理中”并调用 fixer 子代理

（定义见 `.claude/agents/fixer.md`）。

创建 .claude/skills/pr-conventions/SKILL.md：

—

name: pr-conventions

description: 本项目的 PR 标题、描述模板、必须关联的 issue 格式。

开 PR 之前使用。

disable-model-invocation: true

allowed-tools: Bash(gh pr create *), Bash(git *),mcp__github__create_branch,mcp__github__push_files,mcp__github__create_pull_request

—

开 PR 时遵守：

1. 标题格式：`fix(<模块>): <一句话>`，例如 `fix(order): 修复折扣计算浮点误差`

2. 描述必须包含：

– `## 根因`

– `## 修复方式`

– `## 验证方式`（贴出跑过的测试命令和结果）

3. 自动生成的 PR 一律加 `automated-fix` 标签：

`gh pr create –label automated-fix …`

4. 不要在 PR 描述里写”应该没问题”这类话，必须写清楚跑了什么测试。

如果本地仓库还没关联远程 GitHub 仓库（没有 origin），改成本地创建一个feature 分支 + commit，并在汇报里说明”未推送，因为没有配置远程仓库”，不要因为 `gh pr create` 失败就报错中断整个 loop。

disable-model-invocation这个参数，如果只想让人或者信任的Automation来明确是否调用它，不想让 Claude 自己判断”看起来可以开 PR 了”就开，那就把值写成true，反之则false。

设置子代理sub-agent。在这里我们需要设置两个子代理，也就是在文中介绍的由于通常情况下自己写代码的agent会给自己写出来的结果打分过高（Self-preference bias），需要把“写代码”的agent和“审查”代码的agent分开以降低模型的自我偏好偏差。

两个子代理：fixer（写代码），verifier（审查代码）

创建 .claude/agents/fixer.md：

—

name: fixer

description: 针对 backlog 里”处理中”状态的一条发现，在隔离 worktree 中起草最小化修复。 由 triage-findings 技能或人工显式调用，不做自我验证判断——验证交给 verifier。

tools: Read, Edit, Write, Bash, Grep, Glob

model: sonnet

isolation: worktree

—

你是本项目的修复起草者。你会收到 backlog 里的一条发现描述。

工作方式：

1. 先读 CLAUDE.md 里的”硬规矩”，任何修复都不能违反它们。

2. 定位根因，写最小化的修复——不要顺手重构不相关的代码。

3. 补一个能复现原问题的测试用例（修复前失败，修复后通过），

如果已有测试文件（如 tests/order.spec.ts）已经覆盖了这个问题， 不用重复造新测试。

4. 跑 `pnpm test` 和 `pnpm lint`，把结果原样贴在你的最终汇报里，不要用”应该通过了”这类话代替真实运行结果。

5. 汇报格式：根因 / 改动文件列表 / 新增测试 / 测试运行结果原文。

你不负责判断这个修复是否”足够好可以合并”——那是 verifier 的工作，

你只需要诚实地汇报你做了什么、跑了什么、结果是什么。

创建 .claude/agents/verifier.md：

—

name: verifier

description: 独立审查 fixer 起草的修复，对照 CLAUDE.md 规矩和测试结果做出”通过/不通过”判定。 在 fixer 完成后被调用，绝不由 fixer 自己触发。

tools: Read, Grep, Glob, Bash(pnpm test *), Bash(pnpm lint *), Bash(git diff *)

model: opus

—

你是独立审查者，职责是发现 fixer 说服自己相信”没问题”但实际有问题的地方。不要相信 fixer 汇报里的结论性语言，只相信可复现的证据。

审查清单：

1. `git diff` 里的改动是否严格对应根因？有没有夹带无关改动？

2. 独立重新跑一遍 `pnpm test` 和 `pnpm lint`——不要用 fixer 贴的结果，自己跑。

3. 涉及金额/库存的改动，额外跑 `pnpm test:invariants`。

4. 是否触碰了 CLAUDE.md 里的高风险区域（`src/payment-webhook.ts` 等）？ 触碰了就直接判”需人工”，不管测试是否通过。

5. 新增或修改的测试是否真的覆盖了原问题（改回旧代码，这个测试会失败吗）？

输出三选一的结论：

– `PASS`：附上你独立跑出的测试结果

– `FAIL`：附上具体原因和给 fixer 的修改建议

– `NEEDS_HUMAN`：附上为什么这不该由自动化决定

两个子代理跑在不同 worktree，fixer 靠 isolation: worktree 自动获得隔离，而verifier 用只读工具审查同一份 diff，不需要自己再开一个 worktree。同样的模型层也可以永不同的模型。

worktree工作环境隔离—让并行的agent工作之间不互相干扰

其实大家仔细看其实能发现，fixer.md文件中已经写入了isolation: worktree这行参数，这样每次调用 fixer，Claude Code 都会有以下几个动作：

• 从默认分支（origin/HEAD）拉出一个临时 worktree；
• 让 fixer 只在这个隔离目录里工作；
• fixer 完成后，如果没有改动就自动清理掉这个 worktree，如果有改动就保留，等人工来决定 keep 还是 remove。

需要注意的一点是：如果项目里有 .env 之类敏感信息没进 git ，但是每个worktree之后的运行又都需要的文件，那可以在项目根目录下加一个 .worktreeinclude，然后把.env等文件名写进去（如下：），这样AI 在worktree环境中工作的时候就会自动把这类“共享文件”（没有被git管理的敏感信息文件）加载进去啦。

.env

.env.xxx

当然也可以手动开多个并行会话，自己可以同时盯一个大功能。

claude –worktree fix-xx-xx

# 另一个终端

claude –worktree fix-xx-xx

通过Connectors连接github

通过mcp连接github，这样就能访问issue、PR等，而不再仅仅依赖gh CLI。

需要先去github生成一个PAT，https://github.com/settings/tokens，给予项目任务的 Issues、Pull requests 的读写权限。

把拿到的token代入环境变量，使用官方add-json命令连接

export GITHUB_PAT=”token”

claude mcp add-json github ‘{“type”:”http”,”url”:”https://api.githubcopilot.com/mcp”,”headers”:{“Authorization”:”Bearer ‘”$GITHUB_PAT”‘”}}’ #使用官方验证的add-json 命令

然后终端进入order-service项目，进入claude code，/mcp查看验证连接结果,正常连接情况如图所示：

接着最后在order-service项目/.claude目录下创建一个settings.json，团队共享可以被git提交的文件。直接运行下面这一整段命令（注意需要在order-service项目根目录下执行），会在order-service/.claude这个目录下创建一个settings.json文件，并提交进git，支持团队共享。

cat > .claude/settings.json << ‘EOF’

{

“permissions”: {

“allow”: [

“mcp__github__list_issues”,

“mcp__github__get_issue”,

“mcp__github__create_issue”,

“mcp__github__create_branch”,

“mcp__github__push_files”,

“mcp__github__create_pull_request”,

“mcp__github__get_*”

],

“ask”: [

“mcp__github__merge_pull_request”

]

}

}

EOF

git add .claude/settings.json

git commit -m “chore: 添加团队共享的 GitHub MCP 权限策略”

在项目的根目录下创建一个.claude/loop.md，作为claude code /loop的默认指令

执行 triage-findings 技能，扫描 CI、issue、alerts.json。

对每条”值得自动修”的发现：

1. 在 backlog 里标记为”处理中”；

2. 调用 fixer 子代理起草修复；

3. fixer 完成后调用 verifier 子代理审查；

4. verifier 判 PASS：用 pr-conventions 技能开 PR（或本地建分支+commit）， backlog 移到”已验证待开PR”，PR/commit 完成后移到”已完成”；

5. verifier 判 FAIL：把 verifier 的建议喂回 fixer，最多重试 2 轮；

6. verifier 判 NEEDS_HUMAN，或重试 2 轮仍 FAIL：移到”待人工确认”并写明原因。

全部处理完、且没有新发现时，用一句话汇报本轮结果，不要主动发起新任务。

最后一步就可以开始运行了，如果你没有一个真实的项目，那么对应上述真实实践的文件夹，在下面了⬇️

实践文件夹

需要安装pnpm依赖

pnpm install

ok，下面就在项目根目录下打开终端，输入：

pnpm test

运行后应该能看到下面这个响应，tests/order.spec.ts里一共三个，有两个测试失败。不用担心，这是真实留的浮点误差 bug，下面就是要通过loop去自动处理这个点。

同时再运行以下两个命令，确认没有error。

pnpm lint # 没有任何输出，代表没有 error

pnpm test:invariants # 预期2 个测试都通过

项目根目录下打开claude，首先输入/memery和/agents确认是否正确加载真实的配置文件？

如下：

建议：在/loop前先手动跑一遍，了解fixer → verifier → backlog 这条链路实际运行的流程，建立对这套loop的信任感。手动跑的过程也很简单吗，就直接在对话框输入：

按照 .claude/loop.md 里描述的流程，处理 loop-state/backlog.md 里”待分类”区的发现

下面的流程基本就是:

本质上的效果上和/loop 10m每 10 分钟自动唤起运营后台任务没什么区别。就是有无Automation.

当然，手动跑一遍流程只是建议各位去试一下哈。我这里就直接激活/loop去跑了。claude code对话里输入：

/loop 10m 按照 .claude/loop.md 里描述的流程，处理 loop-state/backlog.md 里”待分类”区的发现 # 没10分钟按照loop.md中的流程跑一遍

刚刚设计的那些模块就都开始正常工作了

处理完成后进一步验证一下处理结果：

verifier测试验证后是给了pass通过，我们可以手动验证一下修复的结果：依旧还是进入项目文件终端中，输入以下命令：

pnpm test

看9个测试均已通过。

不过这只是这一轮修复结果跑完并通过了，我们在claude code中输入的/loop 10m是每10分钟claude 都会根据loop.md文件红的流程去扫一遍的，不过短时间可能没有什么bug可以让claude去修复的了，所以会一直显示“无新发现”

这大概就是整个实践的全过程了哈！

五、时代洪流下，我们该如何思考？

根据上面的流程其实可以感受到，通过现在loop e确实可以在很大程度上加大工作的效率和生产，但是对于我们普通人来说到底意味着什么呢？是契机还是淘汰？

在回复这个问题之前，我们可以先梳理一下agent发展的路径。其实可以发现，从24年的prompt engineering工程，为了让模型更好的听懂我们的需求，到25年的context engineering工程，为了给模型更好的上下文信息，再到26年初的harness engineering驾驭工程，真正打通agent运行的良性循环或者说自我进化，再到如今的loop engineering工程。

可以发现，从26年初到现在，似乎几个月就会有一个新的工程概念蓬勃而出。很多人会说这是时代大佬们造的概念、不管是为了公司的股值还是造势，其实从需求分析会发现这似乎有可能是一个必经的过程？

一开始使用模型就像二者之间的对话，我们需要pe来确保我们之间的交流是在同一个维度之上

交流的维度对上了，说的多了它又会失忆。所以又来了ce来给它充足的信息确保任务的流畅

但是，仅凭对话式的规范又很难跑通复杂的进程，所以行业又规范了he体系，可以更成体系的驾驭agent

到现在的loop e，不满足于你来我往的回合制的运用，所以又迎来了loop e来设计规范循环体系把人类自身从任务系统的摘了出去。

而如今在人工智能浪潮下的时代飞跃，正在不断重新定义我们在技术谱系中的位置。人类本身的“思考”成为了转变的核心。需要的是在“洪流”下保持清晰的逻辑和主动迭代于学习的意愿。

“人机协同的闭环思维”至关重要，这也是为什么发展到现在loop engineering的原因之一。就像我开头所述的“有物混成，先天地生。寂兮寥兮，独立而不改，周行而不殆，可以为天地母。”一样，这个是老子对“道”的描述，同样的放在今天AI其实就是“道”，人和“道”的关系不是淘汰与替代的关系，而是相辅相成、互通协作的一体，正如均存在于天地间一样。

参考文章：https://addyosmani.com/blog/loop-engineering/