Loop Engineering：Agent 工作方式正在从提示词迁移到系统设计
最近几篇关于 coding agent 的长文都指向同一个变化：我们正在从“人不断提示 Agent”进入“人设计循环，让 Agent 在循环里工作”的阶段。
这不是说 prompt 不重要了。恰好相反，prompt 变成了系统里的一部分：它被放进 skill、routine、goal、grader rubric、memory 文件、权限策略和触发器里。真正变化的是，人不再充当每一步的手动反馈回路。
过去两年常见的工作方式是：
人提出任务 -> Agent 输出 -> 人检查 -> 人补充上下文 -> Agent 再输出 -> 人再检查
新的方向更像：
人定义目标和边界 -> 系统发现工作 -> Agent 执行 -> 独立验证 -> 写入记忆 -> 决定下一轮
也就是说，工程师的杠杆点从“把一句话写得更准”，移动到了“把反馈系统设计得更稳”。
Loop Engineering 解决的不是提示词问题
Loop Engineering 可以理解为：设计一套可重复的反馈循环，让 Agent 从尝试走到可验证结果，而不是让人反复敲下一句提示。
它至少包含五个阶段：
这张图看起来很朴素，但它解释了为什么单纯“写好 prompt”已经不够：如果没有验证，Agent 只是生成；如果没有记忆，它每轮都从零开始；如果没有权限边界，它可能把错误自动化；如果没有停止条件，它会烧 token 而不产出确定结果。
真正有价值的 loop，不是“让模型多试几次”，而是把每次尝试变成下一轮的可靠输入。
六个基础部件
几篇材料里反复出现的共识是：Codex 和 Claude Code 正在收敛到一套相似的能力组合。名字可以不同，但系统形状很接近。
| 部件 | 在 loop 中的角色 | 没有它会怎样 |
|---|---|---|
| Automations / schedule | 让循环按时间或事件启动 | 只能手动运行一次 |
| Worktrees | 让多个 Agent 并行而不互相覆盖 | 文件冲突、分支混乱 |
| Skills | 把项目知识固定下来 | 每轮重新猜架构和约定 |
| Plugins / Connectors | 连接 issue、CI、Slack、DB、API | Agent 只能在文件系统里自言自语 |
| Subagents | 把实现者和检查者分开 | 写代码的模型给自己打高分 |
| Memory | 跨 session 保存状态和教训 | 第 47 轮不知道前 46 轮试过什么 |
这六个部件里，最容易被低估的是 memory。很多人一开始会把 memory 想成“更长上下文”。但在长期循环里，更可靠的 memory 往往是外部状态：一个 Markdown 文件、一张 Linear 看板、一个数据库表、一份实验日志。
模型会忘，仓库不会。循环能不能长期运行，关键看状态是否落在模型上下文之外。
从 prompt 到 harness，再到 loop
可以把 Agent 工程分成三层：
| 层级 | 关注点 | 典型产物 |
|---|---|---|
| Prompt engineering | 单次调用怎么表达清楚 | prompt 模板、角色说明、上下文拼接 |
| Harness engineering | 单个 Agent 在什么环境里运行 | 工具权限、文件读写、测试、日志、sandbox |
| Loop engineering | 多次运行如何形成闭环 | 触发器、状态机、grader、memory、恢复策略 |
Prompt 关心“这次让它做什么”。Harness 关心“它能安全地怎么做”。Loop 关心“它做完之后，系统如何判断下一步”。
这也是为什么 loop engineering 更像软件工程，而不是文案工程。你写的不是一句更漂亮的指令，而是一套能重复运行、能观测、能恢复、能控制成本的执行系统。
开放循环与闭合循环
材料里有一个很实用的区分：open loop 和 closed loop。
| 类型 | 适合 | 优点 | 风险 |
|---|---|---|---|
| Open loop | 探索式研究、开放设计、未知空间搜索 | 可能发现人没想到的路径 | token 消耗高，质量漂移大，容易产出噪声 |
| Closed loop | 工程修复、迁移、CI、文档漂移、评审 | 边界明确，成本可控，结果可验 | 需要人先设计流程和评价标准 |
大多数团队今天应该先做 closed loop。因为真实工程不是“让 Agent 自由发挥”，而是“让 Agent 在一条有护栏的路径里反复尝试，直到过验证”。
一个好的 closed loop 通常有五个要素：
| 要素 | 写法 |
|---|---|
| Goal | 明确什么叫完成，不要写“尽量做好” |
| Context | 用 VISION.md、ARCHITECTURE.md、RULES.md 写清项目背景 |
| Action | 限定它能做什么，避免无关探索 |
| Feedback | 测试、lint、CI、rubric、人工评论都可以是反馈 |
| Stop condition | 通过什么检查就停，遇到什么情况必须交还给人 |
这也是 /goal 这类能力的价值：它不是让 Agent 更“自主”，而是把停止条件显式化。很多 Agent 失败不是因为不会写代码，而是因为过早宣布完成。
为什么 verifier 要独立出来
一个反复出现的经验是：写代码的 Agent 不适合独自判断自己是否完成。
原因很简单：它刚刚花了很大上下文去证明自己的路线是对的，继续让它自评，很容易把局部成功当成整体完成。更稳的结构是拆成 maker 和 checker。
| 角色 | 任务 | 权限建议 |
|---|---|---|
| Explorer | 读代码、找路径、提出计划 | 只读 |
| Implementer | 修改代码、跑测试、写说明 | 有限写入 |
| Verifier | 按 rubric、测试和 diff 审查 | 只读，最好独立上下文 |
| Orchestrator | 分配任务、合并结果、决定下一轮 | 记录状态，不直接改核心代码 |
独立 verifier 的价值，不只是“多一个模型看一眼”。它让 loop 的完成判断从“实现者觉得可以了”变成“另一个上下文按标准验收通过”。
这会增加 token 成本，但在长任务、迁移、安全评审、生产问题排查上，这笔钱通常比人工返工便宜。
成本会决定谁能把 loop 真正跑起来
Loop 的隐藏门槛是成本。单个中等编码任务可以很快烧掉几十万 token；如果再加 orchestrator、多个 specialist、verifier、重复实验和定时运行，周级成本会变得非常明显。
所以 loop 的经济性会催生几类新架构：
| 成本策略 | 做法 |
|---|---|
| 模型分层 | 便宜模型做搜索和分类，强模型做架构判断和关键修复 |
| 阶段预算 | 每轮规定 token 上限，超预算就写状态并退出 |
| 缓存上下文 | 项目规则和常用事实写进 skill / memory，不重复推理 |
| 先 closed 后 open | 先跑窄路径，只有验证稳定后才扩大探索空间 |
| verifier 精准使用 | 只在高风险节点调用强 verifier，不给每个小改动配大模型 |
这也是为什么低成本长上下文模型会变得重要。它们不一定每次都最强，但可以承担大量探索、批处理、索引和初筛，让昂贵模型只接最需要判断力的环节。
未来成熟的 Agent 系统不会只问“哪个模型最好”，而会问“这一步应该用哪个模型、给多少预算、失败后如何降级”。
会衍生出哪些新机会
如果 loop engineering 成为主流，它会带出一批比“更好的聊天框”更有价值的产品。
| 方向 | 为什么会出现 |
|---|---|
| Agent Control Plane | 团队需要统一管理任务、权限、预算、审计和状态 |
| Loop Template Marketplace | 通用流程会沉淀成可安装模板：PR review、CI triage、docs drift、release notes |
| Eval-as-Infrastructure | 每个 loop 都需要可执行、可复用、可版本化的验收标准 |
| Memory Layer | 跨 session、跨仓库、跨工具保存事实、失败和决策 |
| Worktree Orchestrator | 多 Agent 并行需要分支隔离、冲突检测、合并策略 |
| Cost Router | 根据任务阶段在不同模型和上下文预算之间路由 |
| Audit and Replay | 自动化越强，越需要回放“它为什么这样做” |
| Human Review Console | 人不再盯每一步，但要能在关键节点接管 |
最有意思的是，这些机会都不是单纯模型能力。它们更像“Agent 时代的工程基础设施”。
对团队组织的影响
Prompt engineer 和 loop engineer 的差别会越来越明显。
| 维度 | Prompt engineer | Loop engineer |
|---|---|---|
| 主要产物 | 单次输出质量 | 可重复的验证结果 |
| 技能重心 | 表达、上下文组织 | 系统设计、测试、权限、状态 |
| 失败方式 | 输出不够好 | 循环失控、成本失控、错误自动化 |
| 衡量标准 | 这次答得怎么样 | 多轮运行后是否可靠 |
| 工作位置 | 人在循环中间 | 人设计循环并审查关键节点 |
这不是说 prompt engineer 消失，而是它会并入更大的工程系统。好的 loop 仍然需要好 prompt，只是 prompt 不再孤立存在。
风险也会同步放大
Loop 越强，错误就越不应该被忽视。因为一次坏输出只是一段文字；一个坏 loop 可能会每天重复、跨仓库传播、自动开 PR、消耗预算，甚至影响真实环境。
必须提前设计的护栏包括：
| 风险 | 护栏 |
|---|---|
| 自动化噪声 | 每轮必须有验收标准和退出条件 |
| 理解债务 | 人定期阅读 diff、transcript 和 memory |
| 成本失控 | token budget、最大轮数、模型分层 |
| 权限越界 | deny list、只允许 draft PR、禁止直接改生产 |
| 评价偏差 | verifier 独立上下文，rubric 可版本化 |
| 状态污染 | memory 要有事实、假设、待验证三类区分 |
最危险的不是 Agent 写错代码，而是团队逐渐不再理解它写了什么。Loop 应该扩大工程师的执行半径，不应该变成逃避理解的工具。
我的判断
Loop Engineering 的核心不是“让 Agent 自动驾驶”，而是把人从低价值的手动重复中移出来，让系统承担发现、执行和初步验证，再把关键判断交还给人。
这会重塑 coding agent 的使用方式：从聊天窗口，走向带触发器、状态、权限、评估和记忆的工程系统。
下一阶段真正有壁垒的能力，不是会不会写一句更好的提示词，而是能不能设计出这样的循环：
- 目标明确；
- 成本可控；
- 失败可恢复；
- 结果可验证；
- 行为可审计；
- 人类仍然掌握最终判断。
一个可靠 loop 的价值，通常大于一千个漂亮 prompt。但前提是：设计 loop 的人仍然是工程师，而不是只负责按下开始按钮的人。
参考材料
- Addy Osmani：关于 Loop Engineering、Codex 与 Claude Code 能力收敛的长文，2026-06-09。
- Codez：关于 Claude Code
/loop、scheduled tasks、Routines 与自动化层级的长文，2026-06-05。 - Rahul：关于 loop 成本、open / closed loop、单 Agent 与 fleet loop 的长文，2026-06-09。
- Lance Martin：关于 Fable 5、自纠错、grader sub-agent 与 memory 外循环的长文，2026-06-10。