“replacing yourself as the person who prompts the agent.”
这句话抓住了 Loop Engineering 的边界：人转而设计会提示 Agent 的系统，取代每一步手动提示。早期 Geoffrey Huntley 的 Ralph loops 可以作为先声，而 2026 年 6 月的讨论已经更强调系统化组件。
AI Native Delivery Method
Loop Engineering 实践介绍
Loop Engineering 的核心是设计一个会持续提示、执行、验证并记录状态的 AI 工程循环，它超越了单纯把 prompt 写得更长的思路。 它的核心目标是让人转向设计递归目标、工具连接、隔离执行和证据闭环，取代逐步 prompting。
Chapter 01
Loop Engineering 是什么
更准确地说，它是在设计一个能替代人工逐步 prompting 的循环系统：系统自己读取状态、触发 Agent、分派任务、执行验证，并把下一步写回外部状态。
Peter Steinberger 与 Boris Cherny 的讨论把它推向工程实践。
Peter Steinberger 关注自动循环里的真实生产效率；Claude Code 负责人 Boris Cherny 则把 Agent 迭代为更能持续工作的工程搭档。页面下文采用这个”系统循环”视角，把它作为系统循环框架来呈现。
图示说明：上图保留 CA 项目“Executor / Verifier / Memory Keeper / Orchestrator”的实践语言，并把这些实践角色映射到 5+1 框架：
Automations、Worktrees、Skills、Plugins and Connectors、Sub-agents，以及 Memory / State。Human Gate 作为贯穿循环的治理约束处理。
Chapter 02
怎么利用 Codex /goal 实现 Loop Engineering
/goal 可以被看成一个 recursive goal 容器：直到停止条件满足，Agent 会持续读取上下文、执行下一步、验证结果并更新状态。
用 /goal 建立递归目标
把业务目标、交付物、停止条件、预算上限和证据要求写进目标描述，让循环知道何时继续、何时停止。
把 Skills 与 Memory 放进上下文
要求 Codex 先读取项目 SKILL.md、仓库内 md 业务记忆、源码、配置和日志，再输出证据状态与必要假设。
用 worktree 和 connectors 执行
每条任务优先进入独立 worktree；通过 SSH、浏览器、Git、CI、日志平台等连接器完成真实操作。
用 Checker 和证据关闭目标
最终输出必须包含 diff 摘要、测试/E2E/日志证据、残留风险和记忆更新；仅在证据充足时宣布目标完成。
/goal 基于新版 UI 源码完成某业务模块需求开发：
1. 先从页面、接口、状态管理和路由中总结系统需求；
2. 给出最小设计方案和影响范围；
3. 在独立 Git worktree 中修改代码并补充必要测试；
4. 通过 SSH / CI / 日志连接器部署到 CA 测试服务器；
5. 由 Checker 用浏览器 E2E、截图、网络请求和服务端日志验证关键流程；
6. 停止条件：测试通过、主流程可用、高风险日志数量为零、业务记忆已更新；
7. token 预算：每轮先复用 md 记忆和摘要，确保上下文高效利用。
1 个目标
聚焦一条业务闭环
5+1 组件
自动触发、隔离、技能、连接器、子代理、记忆
证据验收
测试、日志、截图闭环
预算约束
token、时间、权限和人工 gate
Chapter 03
CA 项目的当前实践路径
CA 项目当前实践可以作为 Loop Engineering 的起点样例：从源码理解到系统需求、从实现调整到远程部署、从浏览器 E2E 到 md 记忆沉淀，形成一条可重复的工程循环。
Context Builder
读取新版 UI 页面、组件、路由、状态、接口调用、权限逻辑和历史 md 记忆。
Planner
把源码行为整理为系统需求、边界、异常状态、验收条件和最小设计。
Maker
按当前仓库流程完成代码修改、配置调整、测试补充和本地验证。
Connectors
通过 SSH、GitLab、CI、日志平台和测试环境执行构建、发布、重启和巡检。
Checker
打开真实环境页面，模拟用户路径，保存截图、网络请求、控制台日志和服务端日志结论。
当前可形成的交付物
- ✓系统需求表：页面行为、接口依赖、权限规则、异常分支、验收标准。
- ✓设计说明：影响范围、数据流、模块改动、兼容策略、回滚方式。
- ✓实现变更：代码分支或工作区、代码 diff、测试补充、配置调整和部署脚本记录。
- ✓验证证据：Checker 产出的浏览器 E2E 路径、截图、网络请求、控制台日志、服务端日志。
- ✓业务记忆：仓库内 md 文档记录问题原因、修复路径、项目约定、风险和下一次可复用的入口。
一条需求的推荐闭环
- ✓从新 UI 源码出发，同时对照原型，让需求理解和实际实现保持一致。
- ✓先形成需求摘要和设计摘要，再进入编码，便于人工快速校正方向。
- ✓当前实现动作保留清晰代码 diff；后续可升级为独立 worktree，部署动作通过 SSH 留痕。
- ✓E2E 验证交给 Checker，覆盖主流程、失败态、权限态和关键回归点。
- ✓收尾时更新仓库内 md 业务记忆和看板状态，让项目经验进入下一轮上下文。
关键原则：AI 要交付“需求如何得出、设计为何这样、在哪个分支或工作区实现、部署是否成功、用户路径是否可用、下一轮状态写到哪里”的完整证据链。
Guardrails
风险提醒：循环必须可控、可证、可停
Loop Engineering 的风险来自”循环会持续运行”。因此页面需要强调成本、权限、证据和停止条件，与自动化效率并重。
Token 成本控制
每轮优先读取摘要、md 记忆和差异文件；当需要更多证据支撑时再扩展上下文，确保每次读取都有明确目的。
Human Gate
生产发布、权限提升、数据迁移、不可逆操作和业务策略判断必须有人类确认。
证据闭环
输出内容始终包含测试、E2E、截图、日志、diff、版本和残留风险，替代仅输出”已完成”的简单声明。
可验证停止条件
每个 /goal 都要写清退出标准，例如主流程通过、高风险日志数量为零、记忆已更新、PR 已准备好。
Chapter 04
未来计划：从需求开发到自动修复缺陷
下一步可以把 Loop Engineering 扩展成面向进度看板、缺陷卡片和发布流程的自动化平台能力，让 AI 围绕真实项目流持续工作，但仍保留人工 gate。
接入 ONES 进度看板：Automations
以需求卡片、缺陷卡片、优先级、负责人、环境信息和验收标准作为触发输入，自动创建 /goal 与隔离 worktree。
从缺陷卡片自动修复：Sub-agents
Planner 读取缺陷描述、复现步骤、截图、日志和关联版本；Maker 修复；Checker 复现并验证主流程和回归点。
建设 CA QA 机器人：Memory / State
在仓库内 md 业务记忆稳定沉淀后，把问题现象、根因、修复方式、验证路径、环境差异和项目约定接入 QA 机器人知识库。
基于 GitLab 建立控制点：Connectors + Human Gate
使用 GitLab issue 和 PR 承载需求确认、修复方案、代码评审、验证证据和发布确认，让人机协作过程可追踪、可审查、可复用。
平台输入
ONES 卡片、代码仓库、worktree、部署环境、测试账号、日志入口、仓库内 md 业务记忆。
平台处理
自动触发、目标拆解、上下文收集、子代理分工、远程部署、E2E 验证、风险报告。
平台输出
修复结果、验证证据、变更说明、业务记忆更新、看板状态和下一步待办。