Loop Engineering 14 步路线图：以及 Codex /goal 在哪里最有用
参考链接
一句话总结
Loop Engineering 不是“把 prompt 写得更长”，而是把 Agent 的工作发现、执行、验证、记录和下一步决策做成一个可持续运行的闭环；Codex /goal 则更像这个闭环在单次 coding session 里的最小可行入口。
为什么现在该从 Prompt 走向 Loop
很多 AI 编程讨论，默认前提仍然是“人写 prompt，模型给结果”。
这个模式在一次性任务里足够好，但只要任务开始重复出现，比如修 CI、批量升级依赖、清理 lint、按规则整理 PR，真正决定效率的就不再是某一句提示词，而是下面这些工程问题：
- 任务是否会反复出现
- 结果是否能自动验证
- 失败后是否能恢复或重试
- 运行过程是否可审计
- 多个 agent 是否会互相干扰
这时你需要的已经不是一个更聪明的回答，而是一个能持续推进目标、遇错可停、完成可验的 loop。
这 14 步其实是三层结构
如果只看 14 个步骤，容易觉得它像一张技巧清单；但把它重新整理后，会发现它更像三层递进结构。
第一层：先判断值不值得做成 loop
真正适合 loop 的任务，通常有四个共同点：
- 会重复出现，而不是只做一次
- 有客观 gate，例如测试、lint、typecheck、build
- token 和运行成本在可接受范围内
- agent 有运行、日志、复现和记录结果的工具
如果这些前提都不成立，强行上 loop 往往只是把模糊任务自动化，并不会真的提高交付质量。
第二层：理解 loop 的五个构建块
一套能跑起来的 loop，至少会逐步碰到这些部件：
Automations：什么时候启动，什么时候再次运行Worktrees：多个 agent 如何并行而不互相踩文件Skills：项目规则、禁区、验证命令如何被反复读取Connectors：如何接入 GitHub、工单、告警、数据库、staging APISub-agents：maker 和 checker 如何拆开，减少“自己说自己对”的风险
第三层：从最小可行 loop 出发，再补风险控制
文章里最值得借鉴的顺序不是“功能尽量多”，而是“先搭最小系统，再补纪律”：
- 先手动跑通一次任务
- 再沉淀 skill 和 state
- 再加自动 gate
- 最后再考虑 schedule、并行、外部连接和权限扩张
也就是说，loop engineering 的重点不是炫技，而是让系统长期不失控。
14 步路线图，以及用 Codex 怎么落
| 阶段 | 步骤 | 原意与目的 | 用 Codex 怎么做 |
|---|---|---|---|
| 第一阶段：先判断要不要做 loop | 1. Loop Engineering：把自己从“提示者”位置替换掉 | 从“人不断手动提示 agent”切换到“设计一个会持续推进任务的系统”。核心是把发现、执行、检查、记录、决策串成闭环。 | 先不要把 Codex 当成“写一段代码的聊天窗口”，而是把任务写成一个完整执行单元：目标、完成证据、范围、约束、停止条件都先定义好，再让 Codex 围绕这份执行合同推进。 |
| 2. 建 loop 前先跑 4 个条件测试 | 先判断任务是否重复、可自动验证、预算是否能承受、agent 是否有足够工具，避免把一次性任务硬做成高成本 loop。 | 先让 Codex 读仓库、找测试、看脚本、确认是否能运行验证命令，再判断这类任务是不是值得重复交给它。也就是说，先用 Codex 做可行性勘探，再决定要不要做 loop。 | |
| 3. 判断谁适合、谁暂时不适合 | 明确适用边界：适合有重复任务、强测试、多 agent 协作的团队；不适合无测试、预算紧张、review 才是真瓶颈的场景。 | 落地时先把 Codex 用在低风险、高重复、可验证的工程任务上，例如 lint 修复、依赖升级、测试修复；不要一开始就把架构决策、支付链路、鉴权改造这类高风险任务全交给它。 | |
| 4. 30 秒任务检查表 | 用一组快速问题筛任务：是否每周重复、是否可自动 gate、agent 能否运行代码、是否有硬停止条件、上线前是否有人审。 | 可以把这张检查表直接变成给 Codex 的任务模板：先检查是否重复、能否验证、能否运行、何时停止、谁来 review。只有这些问题都有答案时，才进入真正执行。 | |
| 第二阶段：理解 5 个构建块 | 5. Automations：loop 的心跳 | 给 loop 一个触发机制，让 agent 按时间、事件或条件反复检查、执行、归档、进入 triage。 | 在 Codex 里先把单次执行流程跑稳定，再接 automation 触发它。也就是说，先证明“这一轮怎么跑”，再让定时器、事件或监控去反复拉起同一个流程。 |
| 6. Worktrees：并行但不互相踩文件 | 让多个 agent 在隔离目录或分支中并行工作，减少 checkout 冲突和文件互相覆盖。 | 如果要让多个 Codex 线程或 agent 并行处理任务，就给它们明确分开的工作目录、分支或 worktree，不要让多个执行单元在同一个目录里直接互改文件。 | |
| 7. Skills：项目知识写一次，每次运行都读取 | 把目录职责、操作禁区、脚本用法、分类规则、验证流程写成可复用知识，避免每轮都重新解释。 | 把项目约定提前写成 skill、README、工作流文档或状态说明，然后让 Codex 每次开工前先读取。这样做的重点不是“补充背景”，而是把行为边界显式化。 | |
| 8. Connectors：让 loop 接触真实工具 | 通过 GitHub、Linear、Jira、Slack、Sentry、数据库、staging API 等让 loop 进入真实工程流。 | 当本地改文件已经不够时，就让 Codex 通过连接器去读 issue、查告警、回写状态、触发外部流程。这样它才不是只在本地改代码，而是真正进入团队工作流。 | |
| 9. Sub-agents：把 maker 和 checker 分开 | 把实现者和验证者拆开，降低同一个模型自我说服、“自己写自己验”的风险。 | 用 Codex 落这一步时，不要只让同一个执行单元“改完就宣布完成”。可以拆成实现者和验证者两个角色，或者至少让第二个线程专门负责 review、测试和挑错。 | |
| 10. State file：agent 会忘，文件不会 | 用 Markdown、JSON、看板或外部状态持续记录分支、进度、阻塞点、学习结果和停止条件。 | 让 Codex 把每轮结果写回 STATE.md、JSON 文件或任务看板，包括做到哪一步、为什么停下、下次从哪继续。这样下一轮运行才不是重新从零理解上下文。 | |
| 第三阶段：最小可行 loop 与风险边界 | 11. 最小可行 loop | 先用 automation、skill、state file、gate 组合一个能工作的最小系统，不要一开始就上复杂 swarm。 | 最稳的做法是先让 Codex 在一个小任务上完成“读取规则 -> 执行修改 -> 运行验证 -> 记录状态”这四步，再逐步补 automation、并行和外部连接，而不是一开始就搭复杂多 agent 系统。 |
| 12. 静默失败的 loop | 防止 agent 过早宣布“完成”，但实际上没有通过测试、构建、类型检查等客观标准。 | 给 Codex 的完成条件一定要写成可执行 gate，例如测试全绿、build 通过、lint 通过、目标字符串消失。不要接受“我觉得改好了”这种语言式完成。 | |
| 13. Comprehension debt：越快越危险 | 警惕代码生成速度超过团队理解速度，避免仓库里堆满没人真正理解的改动。 | 即使 Codex 改得很快，也要强制保留人工读 diff、抽查关键改动、补文档和限制单次改动规模的环节。落地重点不是让它改得更多，而是让团队跟得上理解速度。 | |
| 14. 安全税：无人值守 loop 也是攻击面 | 处理自动合并、权限膨胀、日志泄密、技能注入、依赖风险等问题，需要审计、扫描、脱敏和审批。 | 如果让 Codex 接触凭据、外部系统或自动化权限，就要提前收紧权限边界，限制可访问范围，开启日志脱敏，并把合并、发布、危险写操作继续留给人工审批。 |
/goal 更像什么，不像什么
把上面的 14 步看完之后，一个很有用的结论是：/goal 不是 Loop Engineering 的缩写版，而是它在单次会话中的 MVP 入口。
它最擅长覆盖的是三件事：
- 把目标写成可验收的任务
- 把执行过程限制在明确范围内
- 用停止条件防止 agent 一直盲猜
它不太擅长单独解决的，则是另外三类问题：
- 定时触发和长期运行
- 多 agent 并行隔离
- 外部系统接入后的权限、审计与安全
所以更准确的说法不是“有了 /goal 就不需要 loop engineering”，而是：
/goal很适合让你先练会闭环工作方式，但一旦任务开始跨会话、跨人、跨系统运行，完整 loop 的那些部件就必须补上。
实际落地时，最值得先学的是哪几步
如果你不是在搭一个成熟的 agent 平台，而是想在真实项目里先把这套思路用起来，我会建议优先把注意力放在前四步和第 12 步：
- 先做任务筛选，不要什么都自动化
- 先把验证方式写成客观 gate
- 先让 agent 有明确停止条件
- 先接受“有人 review”仍然是必要成本
- 优先防止静默失败，而不是优先追求无人值守
这也是为什么很多团队真正的起点不是复杂的 orchestration，而是一个写得足够好的 /goal，外加一组能跑通的测试、lint 和 build 命令。
一条更稳的递进路线
如果把这篇 14 步路线图压缩成一条更实操的路径，大致可以分成三段：
第一步：先用 /goal 跑通一个小闭环
选择低风险、可验证、可复现的任务，例如：
- 修一组 lint 错误
- 修复单模块测试
- 做一次小范围依赖升级
重点不是任务本身，而是你是否真的完成了这条链路：
目标 -> 执行 -> 验证 -> 失败重试 -> 达不到条件时停下并报告
第二步：把成功经验外化成 skill 和 state
当某类任务开始重复，就不要继续靠临场说明，而是逐步沉淀：
- 项目规则文档
- 常用验证命令
- 进度与阻塞记录
- 禁区和边界条件
这一步做完，loop 才开始摆脱“依赖某个熟练操作者”的状态。
第三步：只有在收益成立时，再升级成完整 loop
等你确认这类任务确实重复出现，且客观 gate 足够强，再考虑补齐：
- automation 调度
- worktree 并行
- connectors 接入真实系统
- maker/checker 分离
- 更正式的审计与安全控制
顺序很重要。先证明闭环有价值，再扩大自动化边界，通常比一开始就追求“全自动”更稳。
总结
如果只记住一句话，我觉得应该是：
prompt 只是一次指令，loop 才是持续交付的结构。
这 14 步路线图的价值，不在于告诉你“所有事情都该交给 agent”，而在于提供了一套筛选标准、一组构建块和一条更稳的升级顺序。
而 Codex /goal 的价值，则在于它把这套思维压缩成了一个今天就能上手的最小实践单元。
先把一个小闭环跑通，再决定值不值得把它做成长期系统，这大概才是大多数团队最现实的起点。