AI Agent 能写代码、查资料、改文档、跑测试，但真正用起来以后会发现，麻烦并没有完全消失，只是换了位置。
如果每一步都靠人手动推动，工作流通常长这样：你给 Agent 一个任务，它完成一部分；你检查结果，发现上下文不够，于是补充背景；它继续修改，你再提醒哪些文件不能动、哪些规则必须遵守。AI 确实在干活，但整个过程的调度、检查、纠偏和记录仍然压在人身上。
提示词工程主要解决的是“第一句话怎么说清楚”。Loop Engineering 解决的是另一个问题：怎样把一串反复发生的动作设计成闭环，让 AI Agent 不只是被动回答，而是能围绕目标持续执行、检查、记录，并在合适的时候停下来交给人。
从提示词到闭环
传统的 Agent 使用方式更像对话：
sequenceDiagram
participant 人
participant Agent
人->>Agent: 说明任务
Agent-->>人: 返回结果
人->>Agent: 补充背景或指出问题
Agent-->>人: 再次修改
人->>Agent: 继续检查和追问
这种方式适合一次性问题，例如解释一段代码、生成一个脚本、补一段文档。问题是，只要任务变长，重复动作就会越来越多：查上下文、拆任务、执行、跑测试、分析失败、重试、写记录、判断是否继续。
Loop Engineering 的重点是把这些动作组织成一个可运行的小系统：
flowchart TD
A[触发条件] --> B[读取上下文和任务状态]
B --> C[Agent 执行任务]
C --> D[运行检查和验证]
D --> E{结果是否通过}
E -- 通过 --> F[记录进展]
E -- 失败 --> G{是否允许重试}
G -- 是 --> C
G -- 否 --> H[交给人工处理]
F --> I{目标是否完成}
I -- 未完成 --> B
I -- 完成 --> J[停止循环]
这里的关键不是“自动运行”，而是“闭环”。一个 cron 定时任务只能算触发器，不能算完整 loop。真正的 loop 至少要知道：什么时候启动、去哪里取上下文、如何执行、怎样验收、失败后是否重试、状态写到哪里、什么时候停下。
一个可用的 loop 需要哪些部件
把 Loop Engineering 拆开看，它通常由六个部分组成：触发、隔离、技能、工具、验证和记忆。少了其中任何一个，loop 都容易变成“自动化地制造麻烦”。
| 部件 | 要解决的问题 | 常见做法 |
|---|---|---|
| 触发 | 谁来启动任务 | 定时任务、事件触发、测试失败触发、工单触发 |
| 隔离 | 多个 Agent 如何避免互相覆盖 | Git worktree、临时分支、沙箱环境 |
| 技能 | Agent 如何理解项目规则 | 项目说明、编码规范、禁改目录、常见坑记录 |
| 工具 | Agent 如何接触真实系统 | CI、Issue、数据库、日志、PR、通知系统 |
| 验证 | 谁来判断结果是否可靠 | 测试、静态检查、独立 reviewer Agent、人工审查 |
| 记忆 | 如何避免每轮都重新开始 | Markdown 日志、任务看板、状态文件、外部数据库 |
触发：让 loop 有明确入口
loop 可以由人手动启动，也可以由事件触发。常见触发方式包括：
triggers:
- schedule: "每天 09:00 扫描失败 CI"
- event: "新 issue 被打上 bug 标签"
- event: "PR 测试失败"
- condition: "待办队列不为空"
触发器决定 loop 的工作节奏。比如“每天扫描昨晚失败的 CI”适合稳定重复的维护任务；“新 issue 被打上 bug 标签”适合缺陷分流；“测试失败后自动尝试修复”适合反馈非常明确的代码任务。
触发条件越模糊，loop 越容易误启动。一个好的触发器应该能回答两个问题：为什么现在要跑，以及跑完以后怎样判断有没有价值。
隔离：并行之前先避免互相踩踏
多个 Agent 同时改代码时，最容易出问题的不是“它们不会写”，而是“它们都在同一份工作区里写”。一个 Agent 改了测试，另一个 Agent 改了实现，第三个 Agent 又格式化了文件，最后很难判断是谁引入了问题。
代码场景里常用 Git worktree 做隔离：
git worktree add ../repo-agent-fix-login -b agent/fix-login
git worktree add ../repo-agent-update-tests -b agent/update-tests
每个 Agent 在独立目录里工作，完成后再通过分支、Pull Request（合并请求）或人工 review 合并。这样做会多一步合并成本，但能避免并行任务直接污染主工作区。
隔离不只用于代码。数据分析任务可以给每个 Agent 单独的临时表，内容生产任务可以给每个 Agent 单独的草稿区，客服分析任务可以给每个 Agent 单独的样本集。核心原则一样：先让 Agent 在可丢弃的空间里试错，再把结果进入正式流程。
技能：把项目知识写到对话之外
AI Agent 最大的问题之一，是每次启动都像一个刚入职的新同事。它可能不知道项目怎么启动、测试怎么跑、哪些目录不能改、哪些命名规则必须遵守，也不知道之前踩过什么坑。
这些长期规则不适合每次都塞进提示词，而应该沉淀成 skill。它可以是一个约定文件，也可以是工具内置的项目说明，例如：
# Agent Skill: backend-service
## 启动方式
- 本地启动：`pnpm dev`
- 单元测试：`pnpm test`
- 类型检查：`pnpm typecheck`
## 修改规则
- 不要直接修改 `migrations/` 下的历史迁移文件
- API 返回结构必须保持向后兼容
- 新增接口需要补充 OpenAPI 描述
## 常见问题
- 用户 ID 在数据库中是 bigint，前端接收时使用 string
- 支付状态只能通过状态机变更，不要直接更新字段
提示词是临时指令，skill 是长期规则。没有 skill 的 loop 每跑一轮都要重新理解项目，结果就是重复解释、重复踩坑、重复修错。
工具：让 Agent 不只会说，还能做
一个只能读取本地文件的 Agent，最多能给建议。要让 loop 真正推进任务，Agent 需要连接真实工具：Issue 系统、持续集成（CI）、日志平台、数据库、测试环境、代码仓库和通知系统。
典型代码修复 loop 可以这样设计：
flowchart LR
A[读取失败 CI] --> B[定位失败测试]
B --> C[创建隔离分支]
C --> D[Agent 修改代码]
D --> E[运行测试]
E --> F{测试通过?}
F -- 否 --> D
F -- 是 --> G[创建 PR]
G --> H[通知人工 review]
这个流程里，Agent 不只是回答“可能是哪里坏了”，而是能创建分支、修改代码、运行测试、提交 Pull Request，并把结果交给人审查。工具接得越深，loop 的能力越强；但权限也必须越谨慎。删除数据、发布生产、合并主分支这类动作，通常不应该完全交给无人值守的 loop。
验证：不要让执行者给自己打满分
写代码的 Agent 很容易高估自己的结果。它完成修改后再自问“是否正确”，答案往往会偏乐观。可靠的 loop 应该把执行和验证拆开。
一种常见结构是“双 Agent”：
sequenceDiagram
participant 执行Agent
participant 验证Agent
participant CI
participant 人
执行Agent->>执行Agent: 修改代码
执行Agent->>CI: 运行测试
CI-->>执行Agent: 返回结果
执行Agent->>验证Agent: 提交变更说明
验证Agent-->>执行Agent: 指出风险或缺陷
执行Agent->>执行Agent: 修复问题
执行Agent->>人: 提交待审结果
验证方式可以分层：
| 验证层级 | 能检查什么 | 局限 |
|---|---|---|
| 单元测试 | 函数行为是否符合预期 | 覆盖不到的逻辑不会暴露 |
| 静态检查 | 类型、格式、基本代码质量 | 不理解业务正确性 |
| 集成测试 | 多模块协作是否正常 | 成本高、运行慢 |
| Reviewer Agent | 代码风险、遗漏、异常路径 | 仍可能产生误判 |
| 人工审查 | 业务语义、产品取舍、上线风险 | 需要人投入注意力 |
无人值守的 loop 尤其需要验证层。因为错误一旦进入循环，后续步骤会继续建立在错误结果之上，问题可能越滚越大。
记忆：让 loop 记住已经发生过什么
长期 loop 不能只依赖对话上下文。上下文会被截断，Agent 会忘记上次为什么放弃某个方案，也可能重复验证已经确认过的结论。解决办法是把状态写到外部。
最简单的记忆可以是一个 Markdown 文件：
# Loop State: failing-ci-repair
## 当前目标
修复 `main` 分支上最近一次失败的登录测试。
## 已尝试
- 检查 `auth/session.ts`，未发现 token 过期计算错误
- 回滚测试数据后仍失败
- 发现 mock server 没有返回 `refresh_token`
## 当前结论
失败更可能来自测试桩，而不是业务代码。
## 需要人工判断
是否允许调整登录接口测试夹具。
记忆不一定复杂，但必须稳定存在。它的作用是让 loop 能接着昨天的状态继续，而不是每天重新走一遍同样的路。
什么任务适合设计成 loop
Loop Engineering 不适合所有任务。它真正擅长的是重复、可拆、可验证的工作。
| 任务类型 | 是否适合 loop | 原因 |
|---|---|---|
| 修复明确失败的测试 | 适合 | 有清晰反馈，能自动验证 |
| 扫描 issue 并初步分类 | 适合 | 流程重复，判断标准可沉淀 |
| 每天整理技术情报 | 适合 | 数据源固定，产物格式稳定 |
| 重构核心支付流程 | 谨慎 | 风险高，需要强人工审查 |
| 一次性架构决策 | 不适合 | 缺少重复性，判断依赖上下文 |
| 模糊的产品方向探索 | 不适合 | 难以自动验收，容易跑偏 |
判断一个任务能不能做成 loop，可以看三个条件：
- 是否会重复发生；
- 是否有相对稳定的流程；
- 是否存在可检查的反馈信号。
代码任务天然适合 loop，因为测试、编译、类型检查、日志都能提供反馈。内容选题、竞品分析、客服工单分流、运营日报也可以做成 loop，但需要先定义清楚输入来源、筛选规则、输出格式和人工验收点。
成本和边界
loop 不是免费的自动化。它会反复读取上下文、调用模型、运行工具、重试失败步骤。如果还引入多个 Agent 协作，token 和工具调用成本都会上涨。对于一次性小任务，手动问一次可能更便宜、更快。
更重要的是责任边界。AI Agent 可以推进流程，但不能替人承担结果。它说“完成了”，不代表业务逻辑一定正确；它说“测试通过了”，也不代表覆盖了所有风险。设计 loop 时，应该把高风险动作留给人确认，例如：
| 动作 | 建议权限 |
|---|---|
| 读取代码和日志 | 可以自动执行 |
| 创建临时分支 | 可以自动执行 |
| 运行测试和静态检查 | 可以自动执行 |
| 创建 PR | 可以自动执行 |
| 合并主分支 | 需要人工确认 |
| 发布生产环境 | 需要人工确认 |
| 删除数据或迁移数据 | 需要人工确认 |
Loop Engineering 的目标不是把人移出系统，而是把人从重复推进中抽出来，保留判断、验收和刹车的权力。一个健康的 loop 应该让人更清楚系统正在做什么，而不是只剩一个“开始”按钮。
一个最小可行 loop 的设计模板
设计 loop 时，可以先用下面这个模板把关键问题写清楚：
name: repair-failing-ci
trigger:
type: event
condition: "CI failed on main branch"
context:
sources:
- latest_ci_log
- changed_files
- test_report
- project_skill_file
execution:
workspace: isolated_worktree
max_retries: 3
allowed_actions:
- edit_code
- run_tests
- create_pull_request
validation:
required_checks:
- unit_tests
- typecheck
- reviewer_agent
human_review_required: true
memory:
state_file: ".agent/repair-failing-ci.md"
stop:
success: "PR created with all checks passing"
failure: "3 retries failed or risky change detected"
这个模板不依赖特定工具，重点是把闭环的几个问题提前定下来：谁触发、读什么、能做什么、怎么验收、状态放哪、什么时候停。只要这些问题没有说清楚，Agent 越自动，风险越大。
结语
提示词工程关注的是一次对话的质量，Loop Engineering 关注的是一段工作流的稳定性。真正决定结果的，不再只是第一句提示词写得多完整，而是触发是否准确、上下文是否足够、执行是否隔离、验证是否独立、记忆是否可靠，以及人在什么位置接管。
当 AI Agent 能处理更长链路的任务，人和 AI 的协作方式也会从“你一句我一句”变成“人设计闭环，Agent 在闭环里执行”。这不会让工程工作变得无脑，反而要求人更懂流程、更懂验证，也更清楚什么时候该让系统停下来。