GPT88 Agent Docs

Loop Engineering 是什么：Harness 之后的下一步

基于 Smith 铜匠在 X 上发布的《Harness之后,最近爆火的 Loop Engineering 是什么？怎么做？》正文稳定抽取结果，系统整理 Prompt、Context、Harness、Loop 四层结构，以及如何把 Loop Engineering 落到 Codex 工作流。

来源与抽取方式

Loop Engineering 相关文章封面图
来源封面：X Article《Harness之后,最近爆火的 Loop Engineering 是什么？怎么做？》。

原始 X Article 页面本身几乎不输出可见正文，SSR 数据里也没有直接展开文章内容。稳定抽取正文的方式， 是先定位 tweet detail GraphQL 查询，再从返回里的文章字段取出 plain_text 与区块结构。

Prompt 之后为什么会走到 Loop

这篇文章的核心起点，不是单纯讨论 prompt 是否过时，而是指出高强度使用 AI 的人，工作方式已经从 Prompt 走到 Context，再走到 Harness。

Harness 让 agent 能干活。Loop 让 agent 的工作可以被持续调度、验证和积累。

文章认为，真正的问题已经不是“怎么把一句提示写得更好”，而是“当我们已经有了一个 agent harness， 下一层到底是什么”。答案就是 loop。

Prompt → Context → Harness → Loop

原文把这四层明确拆开，避免把不同问题揉在一起讨论。

阶段原文要点解决的问题
Prompt靠表达能力赢，谁更会拆任务、写约束、追问、纠错，谁更像高手。把意图说清楚。
Context开始管理 repo、docs、examples、memory、constraints。减少模型乱猜，补足背景。
Harnessagent 能读文件、改代码、跑命令、查 issue、用 connector、在隔离 worktree 工作。让 agent 真正进入可执行环境。
Loop让 agent 的工作被持续调度、验证、记录、恢复和停止。把单次执行变成闭环系统。

为什么说 Loop 是 Harness 上面一层

原文对 Harness 和 Loop 的区分非常清楚。Harness 主要解决的是单次执行质量，核心问题是：

  • agent 能不能拿到正确上下文
  • agent 能不能调用需要的工具
  • agent 能不能访问真实文件
  • agent 能不能跑测试
  • agent 能不能交付一个结果

而真正连续工作的麻烦，才是 Loop 的问题：

  • 谁来发现任务
  • 谁来启动任务
  • 谁来判断结果能不能用
  • 失败写在哪里
  • 明天从哪里继续
  • 跑偏了怎么停
harness 是单个 agent 的运行环境。loop 在它上一层，负责触发、分派、检查、记录、恢复和停止。

原文的比喻也很准确：如果 harness 是工作台，loop 就是工单系统、班次表和质检规则。工作台决定能不能干， loop 决定什么时候干、谁来干、谁检查、干到哪里、明天怎么接。

最小可用 Loop 需要什么

原文把一个最小可用 loop 拆成五个部件：

done check

先用代码定义什么叫完成，不让“完成”停留在模糊感受上。

context builder

每一轮从当前 state 生成 prompt，而不是靠人手动重新喂上下文。

act and capture

让 agent 执行，并捕获 diff、输出、错误和新状态。

feedback path

失败不是终点，失败要成为下一轮输入。

stop conditions

限制轮数、预算和风险动作，必要时强制拉人确认。

loop 不是一个更长的 prompt。loop 是一个把 prompt、状态、执行、验证和停止条件接起来的控制结构。

为什么 Loop Engineering 突然变热

原文的判断是，大家并不是突然喜欢上了 “loop” 这个词，而是高强度 AI 用户集体撞上了同一个瓶颈： 单次 agent 已经很强，但真实工作很少是一次性任务。

当决策越来越多地发生在运行时，设计重点就不再只是代码本身，也不只是单个 agent， 而是模型、工具、记忆、规划、状态和验证之间的执行结构。也正因为这样，Harness 和 Loop 才一起重要起来。

怎么设计一个可控的 Loop

原文建议，设计 loop 的第一步不是写 prompt，也不是加定时任务，而是先画出六个接口：

  1. 目标接口：这次 loop 到底要推进什么任务。
  2. 状态接口：每一轮开始时，它能读到哪些 state。
  3. 上下文接口：state 怎么被组装成这一轮 prompt。
  4. 执行接口：agent 能做哪些动作，能调用哪些工具。
  5. 结果接口：执行后必须捕获哪些输出。
  6. 停止接口：什么叫完成，什么叫失败，什么时候必须停。

同时，原文特别强调一个容易被误解的点：

真正的 loop 不是自动继续，而是有条件地继续。
  • 没有 done check，继续就是失控。
  • 没有 capture，继续就是失忆。
  • 没有 feedback，继续就是重复撞墙。
  • 没有 state，继续就是重新开聊。
  • 没有 stop condition，继续就是账单事故。

为什么 Skill 才是可复利资产

这部分是全文里非常重要的一层判断：

loop 是 plumbing，skill 才是资产。

如果 loop 只是每次把一大段 prompt 塞给 agent，让它重新理解项目、重新猜规则、重新摸索做法， 那它只是一个很贵的 while true。真正能复利的是 skill，因为 skill 把规则、经验、 检查方式写到外部，让 agent 每轮都能读到同一套意图。

  • 没有 skill，loop 会反复冷启动。
  • 有 skill，loop 才会积累。
  • 重复出现的步骤，应该抽成 skill。
  • 解决过的难问题，也应该沉淀成 skill。

从 Harness 到 Loop 的正确顺序

原文明确反对一上来就追复杂 loop，尤其是先上定时、并发、多 agent、自动开 PR。

先有 harness，再有 loop。跳过 harness 直接 loop，容易得到一台定时制造混乱的机器。

它给出的更稳路径是：

  1. 选一个你已经用 AI 做过 10 次以上的重复任务。
  2. 先写完成条件，不写自动化。
  3. 固定 context pack，让模型每次拿到同一组关键背景。
  4. 把稳定做法沉淀成 skill。
  5. 把 agent 放进已有 harness 里跑，确认它能访问工具、文件和测试。
  6. 单独设计 checker，不让 maker 自己判自己完成。
  7. 把结果、失败、下一步写进外部 state。
  8. 最后才加 trigger：定时、事件、手动按钮，或 goal 条件。
  9. 补预算上限、最大迭代次数、无进展检测和停止条件。

原文还强调，trigger 之所以要最后加，是因为没有完成条件、没有 checker、没有 external state 的 trigger， 只是把不可靠的单次执行改成不可靠的定期执行。

Loop 的真实风险

Prompt 写坏了，通常一眼能看出来；Loop 设计坏了，可能连续几天产出看起来很完整的垃圾， 而且你不一定第一时间察觉。

  • 它可能不停重试。
  • 它可能每一轮都把 context 塞得更大，最后噪音压过信号。
  • 它可能把第一轮的小错误带到第三轮、第五轮、第十轮。
  • 它可能让 checker 变成摆设。
  • 它可能让人误以为“系统在跑，我就不用看了”。
loop 不会删除人。它只是把人的判断放到更高的位置。

原文还给出一个很现实的提醒：写代码本身可能很便宜，但让一个 loop 一遍又一遍地写代码并不便宜。 真正成熟的 loop 设计，必须把“会不会成功”和“失败时怎么停”放在同一优先级。

真正的分水岭

原文最后用一个问题来判断一个人是否已经进入下一层 AI 使用：

他是不是还在展示“我让 AI 做了什么”，还是已经开始描述“我设计了一套什么系统，让 AI 持续做什么，并且我怎么知道它没跑偏”。

前者更像 agent demo，后者才是 loop thinking。真正拉开差距的，也不是谁写了更长的 prompt， 而是谁能把自己的 harness 变成一个有节奏、有状态、有验证、有停止条件的 loop。

对 Codex 用户的直接启发

1. 不要把经验只留在聊天上下文

反复出现的目录规范、构建顺序、SEO 检查、图片命名、发布流程，应该写进 skill、脚本或固定流程， 而不是每次重新解释。

2. 每轮都要留下可续跑状态

工作日志、任务文档、中间文件、提取结果、失败原因，都应该落盘。否则新会话只会重新冷启动。

3. Checker 不能只是 maker 自评

对文档站来说，checker 可以是 npm run build、路由存在性检查、截图检查、链接检查和 SEO 产物检查。 没有 checker 的 loop，本质上还是半自动猜测。

资料来源

原文列出的资料来源如下：

  • Zhenfeng Cao, “The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm”, arXiv 2606.05608v1
  • Matt Van Horn, “WTF Is a Loop? Peter Steinberger vs. Boris Cherny”
  • Addy Osmani, “Loop Engineering.”
  • Amit Shekhar, “How to design a loop that prompts your agent?”