GPT88 Agent Docs

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

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

This page is accessible in English navigation, but the full body has not been translated yet. The original Chinese content is kept below for accuracy.

来源与抽取方式

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?”