核心思想：不要只研究“这一条提示词怎么写”，而要设计一套能够自动发现问题、执行任务、验证结果、记录进度并决定下一步的工作循环。
过去使用 Claude Code、Codex 等编程 Agent 时，常见流程是：
你提出需求
→ AI 写代码
→ 你让它运行测试
→ AI 发现报错
→ 你让它修复
→ 你再让它测试
→ 直到任务完成
看起来 AI 在干活，但真正推动任务前进的仍然是人。你需要不断输入“继续”“修一下”“再测试”，本质上还是一个人工循环。
Loop Engineering（循环工程）要改变的，正是这种工作方式：
人定义目标、规则和验收标准
↓
AI 规划 → 执行 → 测试 → 检查 → 修正
↑ ↓
└──────── 未达标则继续 ────────┘
↓
达标后自动停止
人不再是每一轮都要按回车的操作员，而是循环的设计者和最终验收者。
理解 Loop Engineering，可以从 AI 编程方式的演进开始。
| 阶段 | 关注的问题 | 通俗理解 |
|---|---|---|
| Prompt Engineering | 怎么问得更清楚 | 把任务说明白 |
| Context Engineering | 应该给 AI 哪些信息 | 把正确资料交给它 |
| Harness Engineering | 怎样让 Agent 完成一次任务 | 给它工具、权限和工作环境 |
| Loop Engineering | 怎样让 Agent 持续完成很多轮任务 | 让整套系统自己运转 |
最早使用 AI 时，我们主要研究：
它解决的是“单次回答质量”问题。
但 AI 回答完以后，任务是否真的完成、代码是否通过测试、下一步做什么，仍然要由人来判断。
后来大家发现，提示词写得再漂亮，如果 AI 不知道项目结构、技术约束和历史背景，结果仍然不会好。
于是开始重视：
这一阶段解决的是“AI 是否掌握了足够且正确的信息”。
当 Claude Code、Codex 等 Coding Agent 出现后，AI 不再只生成代码，还可以：
Harness 可以理解为 Agent 的“工作台”：工具、权限、规则和运行环境都准备好了，让它有能力完成一次复杂任务。
但一次任务结束后，下一次什么时候启动、进度如何接续、结果由谁检查，往往仍然依赖人。
Loop Engineering 位于 Harness 的上一层。
Harness 解决的是：
Agent 如何把一个任务做好？
Loop Engineering 解决的是：
系统如何持续发现和处理任务，并在多轮、跨会话甚至跨天运行中保持可控？
它并没有淘汰 Prompt、Context 或 Harness，而是建立在它们之上。腾讯云文章将其概括为：把“做好一次”升级为“自动地做好很多次”。腾讯云原文
Loop 不是简单地重复执行同一条提示词。
一个真正的循环通常包括：
发现任务
→ 判断优先级
→ 制定计划
→ 执行任务
→ 验证结果
→ 记录状态
→ 决定继续、停止或交给人
可以抽象成下面的伪代码：
state = load_state()
for cycle in range(MAX_CYCLES):
tasks = discover_tasks(state)
if not tasks:
break
for task in tasks:
result = execute(task)
passed = verify(result)
if passed:
mark_done(task)
else:
record_failure(task)
save_state(state)
关键并不在这段代码本身，而在四个问题：
如果这些问题没有明确答案，那么它只是“让 Agent 重复运行”，还算不上成熟的 Loop Engineering。
两篇文章分别从工程结构和工具实践进行了说明。综合来看，循环主要可以分为两类。
Goal Loop 的特点是“完成即停止”。
给定目标
→ Agent 执行
→ 检查验收条件
→ 不满足则继续修改
→ 满足后退出
适合：
例如：
实现用户注册功能，完成条件如下：
1. 支持手机号和密码注册；
2. 密码使用 BCrypt 加密；
3. 手机号不能重复；
4. 参数校验完整；
5. 单元测试覆盖率不低于 80%；
6. 所有测试必须通过；
7. 最多尝试 15 轮，仍失败则停止并报告原因。
这类目标之所以适合循环，是因为“完成”可以被客观验证。
Timer Loop 是周期性醒来检查：
定时或事件触发
→ 检查当前状态
→ 有任务则处理
→ 没任务则结束本轮
→ 等待下一次触发
适合：
例如：
每隔 10 分钟检查一次当前分支的 CI 状态。
如果失败：
1. 获取失败日志；
2. 定位根因；
3. 在独立分支尝试修复；
4. 运行本地测试；
5. 测试通过后创建提交；
6. 涉及依赖升级、权限或生产配置时停止并请求人工确认。
CI 通过后结束本轮任务。
一句话区分：
腾讯云文章把 Loop 拆成五个工程组件和一个外部记忆层。腾讯云原文
Automation 负责决定循环何时启动，例如：
Automation 只是入口。真正的循环还必须包含判断、验证和停止条件。
需要特别注意：触发频率越高，模型调用和验证次数越多，成本也会快速增长。因此应从低频、目标明确的任务开始。
多个 Agent 如果在同一个目录修改文件，很容易互相覆盖。
Git worktree 可以让每个任务拥有：
例如：
Agent A → worktree-A → 修复登录模块
Agent B → worktree-B → 修复订单模块
Agent C → worktree-C → 审查安全问题
Worktree 解决的是文件和分支冲突，但不能解决业务冲突，也不能代替代码审查。
Skill 适合记录长期稳定的知识，例如：
没有 Skill 时，Agent 每次都要重新猜测项目规则；有了 Skill，团队经验可以在每轮运行中复用。
例如：
# Backend Development Skill
- 使用 Java 21 和 Spring Boot 3
- Controller 不允许直接访问 Repository
- 业务异常统一使用 BusinessException
- 新增接口必须包含单元测试
- 提交前运行：mvn test
- 禁止修改生产环境配置
通过插件或 MCP 等连接方式，Agent 可以访问：
这使循环能够从“给出建议”升级为“发现任务—处理任务—更新状态”的完整流程。
但外部连接越多，权限风险越大，必须遵循最小权限原则。
这是 Loop 中非常重要的结构。
Maker Agent：负责写代码、修改文件
Checker Agent：负责测试、审查和判断是否达标
不能完全相信执行 Agent 对自己的评价，因为它可能认为“已经修好了”，实际测试却仍然失败。
更可靠的方式是：
有条件时，Maker 和 Checker 可以使用不同的提示词、不同的上下文，甚至不同的模型。
模型会忘记，文件不会。
Memory 应当记录会不断变化的状态，例如：
{
"task": "修复登录模块测试",
"status": "running",
"attempts": 3,
"completed": [
"修复密码加密逻辑",
"补充手机号格式校验"
],
"remaining": [
"处理手机号重复注册"
],
"last_error": "duplicate phone test returned 500 instead of 400"
}
下一次循环启动时先读取这个文件，就能从上次停止的位置继续，而不是从头猜测。
需要区分三个概念：
| 机制 | 保存什么 |
|---|---|
| Skill | 相对稳定的项目知识和规范 |
| Memory | 不断变化的任务进度和失败记录 |
| Connector | 访问外部工具与数据的能力 |
这些概念不是互相替代，而是不同层次。
ReAct 是 Agent 内部的基础循环：
思考 → 行动 → 观察结果 → 再思考
它负责“下一步应该怎么做”。
Harness 为 Agent 提供：
它负责“怎样把一个任务做完”。
Loop 负责：
它负责“怎样让多个任务跨时间持续运转”。
三者可以组合成：
Loop 外循环定时醒来
↓
发现并分配任务
↓
启动 Harness 执行任务
↓
Harness 内部使用 ReAct 调用工具
↓
独立验证结果
↓
写入 Memory
↓
等待下一次触发
简单类比：
模糊目标：
帮我优化这个项目，直到足够好。
这类目标没有明确终点，Agent 很难判断何时完成，容易不断修改并消耗大量 Token。
更好的目标：
完成订单查询接口优化，满足：
1. P95 响应时间低于 200ms；
2. 原有接口返回结构不变；
3. 所有单元测试通过；
4. 不允许修改数据库表结构；
5. 最多迭代 10 轮；
6. 无法达到目标时，输出瓶颈分析并停止。
一个合格的 Loop 目标应包含：
目标 + 范围 + 验收标准 + 权限边界 + 预算上限 + 停止条件
推荐模板：
目标：
要完成什么？
允许修改：
哪些目录、模块或资源可以修改？
禁止操作：
哪些文件、环境和行为不能触碰？
验收标准：
通过哪些测试、指标或检查才算完成？
失败策略：
失败后最多重试多少次？什么情况交给人工？
成本限制：
最大轮数、最大运行时间或最大 Token 预算是多少？
交付物：
最终需要代码、测试、报告、提交还是 PR？
至少设置：
否则一个无法收敛的任务可能持续消耗资源。
优先使用机器可判断的标准：
“Agent 觉得已经完成”不能作为可靠的验收标准。
以下操作不应完全自动化：
推荐流程：
AI 开发
→ 自动测试
→ 静态扫描
→ 安全扫描
→ 独立 Agent 审查
→ 人工 Review
→ 合并或上线
可以按环境划分：
| 环境 | 建议权限 |
|---|---|
| 开发环境 | 读写代码、运行测试 |
| 测试环境 | 有条件部署，禁止修改关键基础设施 |
| 生产环境 | 默认只读，写操作必须人工批准 |
更稳妥的落地顺序是：
先让单次任务稳定
→ 使用 Goal Loop
→ 增加状态记录和失败恢复
→ 增加定时或事件触发
→ 分离 Maker 与 Checker
→ 最后再考虑多 Agent 并行
如果一个 Agent 连单次任务都无法稳定完成，增加并行只会更快地产生错误。
适合 Loop 的任务通常具有以下特征：
典型场景：
不适合直接无人值守的任务：
判断一个任务是否适合 Loop，可以先问：
触发条件：
当前分支 CI 失败。
任务目标：
定位并修复导致 CI 失败的问题。
执行流程：
1. 获取失败日志；
2. 判断失败属于测试、编译、格式还是环境问题；
3. 在独立 worktree 中修改代码；
4. 运行对应测试；
5. 再运行完整测试；
6. 由 Checker 独立检查修改；
7. 通过后生成提交或 PR；
8. 将处理结果写入状态文件。
限制条件：
- 最多重试 5 次；
- 最长运行 30 分钟；
- 禁止修改生产配置；
- 禁止跳过或删除失败测试；
- 禁止降低质量门槛；
- 涉及依赖大版本升级时请求人工确认。
停止条件：
- CI 全部通过；或者
- 达到重试/时间上限；或者
- 检测到高风险操作；或者
- 连续两次修改没有产生有效进展。
这里最有价值的并不是“让 AI 自动修代码”，而是循环拥有清晰的：
Loop Engineering 并不是“完全不需要 Prompt”，而是把 Prompt 放进了一个更完整的工程系统里。
过去的工作方式是：
人发现问题 → 人提示 AI → 人检查 → 人决定下一步
新的工作方式是：
系统发现问题
→ Agent 执行
→ 独立验证
→ 写入记忆
→ 自动决定继续或停止
→ 关键节点交给人
它真正带来的变化，是人的角色发生了转移：
可以用一句话记住整篇笔记：
Prompt 决定一次回答得好不好，Context 决定 AI 知道得够不够，Harness 决定一个任务能不能做完，Loop Engineering 决定整套系统能不能长期、稳定、可控地持续运转。
参考文章：CSDN：Loop Engineering 实操指南、腾讯云：Loop Engineering 循环工程
那跟自己手写agent 处理返回一次次的确认结果有啥区别？
本质上没有根本区别。如果你手写的 Agent 已经能够：
执行 → 获取结果 → 判断是否完成 → 调整策略 → 再执行
那么你实际上已经实现了一个 Loop。Loop Engineering 不是新算法，而是把这种循环从一段“能跑的代码”，提升成一套可长期运行、可验证、可恢复、可治理的工程方法。
Agent Loop不完全是Loop Engineering，但很多文章确实把两者混着说，所以你的感觉没错。
最简洁的区分是：
关系可以写成：
Agent Loop
+ 自动触发
+ 持久化状态
+ 独立验证
+ 重试与成本上限
+ 权限隔离
+ 人工接管规则
= 一个工程化的 Loop 系统
举例：
while not done:
result = agent.run()
done = agent.check(result)
这是 Agent Loop。
如果再考虑：
state = load_state()
while within_budget(state):
task = discover_task(state)
result = run_in_isolated_workspace(task)
passed = independent_verify(result)
save_state(state)
if passed:
create_pr()
break
if high_risk(result):
request_human_review()
break
这就是 Loop Engineering 所强调的工程化设计。
不过它们的边界并没有严格的行业标准。如果你写的 Agent Loop 本来就包含持久化、独立验证、调度、权限和停止条件，那么从实现上看，两者就是同一套东西。区别主要在命名视角：
Agent Loop 描述“循环在运行”；Loop Engineering 描述“怎样把这个循环设计得可靠、可控并能长期运行”。
类似于“程序”和“软件工程”的关系：底层都是代码，但后者更关注如何把代码变成可维护、可测试、可交付的系统。
Loop Engineering / Agent Loop 不是新的问题求解算法，而是在手写 Agent 循环的基本原理之上，增加了经验与状态持久化、自动调度、独立验证、失败恢复以及成本和权限控制，使 Agent 能够长期、稳定、可控地自主运行。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。