我们一开始问的是一个很具体的问题：如果一个 Agent Harness 里面已经有目标、状态、QA、工具和停止条件，那么 Loop 到底比 Harness 多了什么？

这个问题问得很准，很多关于 Loop Engineering 的讨论，最容易滑向一种新概念崇拜：好像 prompt 过时了，harness 也过时了，接下来只要把东西叫成 loop，就进入了下一层。

真正的变化不是这样。Loop 不是比 Harness 多了一套神秘组件，而是把 Harness 里的组件放进了时间、反馈和控制关系里。它解决的不是“Agent 能不能完成这次任务”，而是“这个系统下次醒来时，能不能知道自己该继续什么、放弃什么、等待什么、验证什么”。

当 Harness 已经足够强，下一步缺的往往不是更多工具，而是把状态、验证、等待、停止和下一轮输入串起来的控制关系。这才是从 Harness 到 Loop 的分水岭。

Harness 解决一次执行，Loop 解决持续运行

Harness 这个词，最初有点像“给 Agent 搭一个能干活的工位”。一个好的 Harness 会给 Agent文件系统、命令行、浏览器、数据库、MCP、内部文档、项目规则、测试命令、沙箱、记忆、状态记录和 QA 检查。没有这些东西，Agent 只能在聊天框里给建议；有了这些东西，Agent 才能进入真实环境，读材料、改文件、跑工具、生成交付。

所以 Harness 不是一个小东西。它本身就可以很完整：它可以有目标，可以有状态，也可以有 QA。目标是这次要修什么 bug、写什么报告、生成什么任务卡；状态是当前做到哪一步、哪些输入已经收到、哪些输出还没验证；QA 是文档能不能打开、敏感信息有没有泄露、测试有没有通过、图像有没有乱码、任务有没有owner。

问题在于，这些能力在 Harness 里通常围绕“这一次执行”组织。Harness 问的是：这次能不能交付。Loop 问的是：交付之后，系统如何继续活着。

一次执行里，状态是过程记录；持续运行里，状态是下一轮的入口。一次执行里，QA 是验收；持续运行里，QA 是路由器：通过了就发布，没通过就修复，修复失败就停止，等待外部输入就挂起。一次执行里，目标是任务说明；持续运行里，目标会根据新证据、新反馈、新缺口被重新计算。

所以 Loop 不是替代 Harness。更准确地说，Loop是 Harness 在时间维度上的控制结构。

为什么“定时任务”不是 Loop

很多人第一次听到 Loop，会立刻想到定时任务。每天九点跑一次，每周一周四跑一次，群里有人 @ 就触发一次。看起来这已经是循环了。

但这只是 trigger，不是 loop。

如果一个系统只是到点启动，给 Agent 一大段 prompt，让 Agent 执行，再输出一份结果，最后等下次再来一遍，那它更像 cron 加 Harness。它有定时，有执行，但还没有真正的持续控制。

因为它没有回答几个更硬的问题：上次失败写在哪里？下次醒来先读什么状态？哪些外部信号会改变下一步？什么条件下不能继续？失败几次必须停？等待别人提交材料时，系统是“忘了”，还是进入可恢复的等待态？结果通过 QA 之后，是发布、补图、提醒、归档，还是进入下一轮任务？

这些问题不解决，定时任务只是让一次性执行重复发生。自动启动不等于 Loop。真正的 Loop 是有条件地继续、有证据地推进、有边界地停止。

这也是很多“无人值守 Agent”容易出问题的地方。它看起来在工作，实际上只是在重复启动。它可能每次都重新理解项目，每次都重新猜规则，每次都重新犯同一种错误。

这种系统不是智能，而是带有 token 账单的健忘。

Loop 的核心不是继续，而是路由

我更愿意把 Loop 理解成一个路由系统。它不只是让 Agent 继续跑，而是根据当前状态决定下一步应该去哪。这里的状态不是一段聊天记忆，而是一组可被读取、可被验证、可被改写的外部事实。

这些动作看起来都不神秘，但它们共同形成了 Loop 的控制层。Loop 真正管理的不是 prompt，而是状态到动作的映射关系。Prompt 只是某一轮里 Agent 要读的一段输入，不是整套系统的规则。

这里可以用一个很具体的例子来理解。假设我们有一个周一、周四的团队机会洞察流程：先生成洞察版，再等待成员分身建议，收到足够建议后合成最终版，再生成视觉报告和任务卡，最后检查任务反馈。如果只是周一、周四 11 点定时启动 Codex，让它从头跑一遍，这只是一个强 Harness。

但如果系统能做到这些，它才开始像 Loop：

1.11点生成洞察版后，状态写入 run 目录

2.成员建议文件夹有新文档，轻量watcher记录信号

3.收到3位成员建议后，启动5分钟缓冲

4.缓冲结束后，自动进入最终版合成

5.最终版链接必须验证可打开，才能发团队群

6.视觉报告生成失败，记录为可恢复阻塞，而不是假装完成

7.任务卡必须发图片本体，不能用链接冒充

8.周二、周五检查反馈文档，反馈不足就提醒对应owner

9.下一轮洞察读取上轮反馈、缺口和被证伪机会

这里的关键不是“它会自动跑”。关键是它知道什么时候等待，什么时候推进，什么时候修复，什么时候停止。这就是 Loop 的实际含义。

正在用 Codex 或 Claude Code，怎么搭Loop

很多人现在已经在用 Codex、Claude Code 或者类似的coding agent，它们本身已经有很强的 Harness：能读仓库、改文件、跑命令、调用工具、理解项目规则。问题不在它们会不会干活，而在它们下次怎么知道该从哪里继续。

先说一个边界：Codex 和 Claude Code 本身不应该被理解成完整 Loop。它们更像Loop里的大脑和执行器。真正负责“什么时候唤醒、读哪份状态、触发哪条规则、什么时候必须停下”的，是外层控制壳。

最小可用的做法，不是先写一个复杂平台，而是先给一个已经跑通的工作流补5 个东西。

第一，补一份外部状态。不要把状态只留在聊天窗口里。聊天会压缩，会换线程，会丢上下文。一个真正能恢复的 Loop 至少要有state.md或state.json，里面写清楚目标、当前阶段、上次运行时间、下一次触发、已有输入、已生成输出、阻塞点、QA 状态、允许自动做的动作、必须问人的动作。

第二，补一个轻 watcher。它不负责思考，只负责记录信号：到点了，有新文件了，群里有人@了，反馈文档变了，某个链接失效了。Watcher 不应该每分钟唤醒一个完整 Agent，那会很贵，也很吵。它只要把信号写进signals.jsonl、run 目录或者任务表里。

第三，补一份交接协议。每次你打开 Codex 或 Claude Code，不要重新解释世界，而是让它先读固定材料：state.md、最近的 signals.jsonl、本项目的 SKILL.md 或 CLAUDE.md、上一轮 run 目录、当前 QA 结果。真正要写的不是一个更长的 prompt，而是一份稳定的交接协议。

第四，补一个 checker。不要让生成者自己宣布完成。Codex 说“我已经做好了”，不算完成；测试通过、文档可打开、图片已经上传、草稿箱回拉 QA 通过、团队群消息真的发出去了，这些外部信号才算完成。Checker 的价值不是挑错，而是决定下一步能不能路由。

第五，补一张 router 表。最简单的 router 只需要几条规则：QA 通过且低风险，写回状态；QA 失败，进入修复；连续失败，进入 blocked；缺输入，进入 waiting；涉及发布、发群、@ 成员、删除数据、改派任务，停下来问人。

把这 5 件事串起来，一个本地 Loop 就够用了。目录可以很朴素：一个状态文件，一个信号日志，一个 run 目录，一个项目规则文件，一个 checker 脚本，一张路由规则表。复杂系统当然可以往后长，但第一步不是做平台，而是把“下次怎么继续”从聊天框里拿出来。

这也是 Codex 和 Claude Code 真正适合的位置：外层负责唤醒和记账，Agent 负责读账、判断、执行、解释和写回。如果让 Agent 自己监控自己的 Harness，很容易变成自说自话；如果把监听、状态、QA、路由拆到外层，它才有可能成为一个可恢复的工作系统。从 Harness 到 Loop，不是给 Agent 更多自由，而是给系统更多可恢复的约束。

Skill才是复利，Loop只是管道

Loop 这个词容易让人兴奋，因为它听起来像自动化、无人值守、持续运行。但真正能复利的不是 Loop 本身，而是Skill。

如果每一轮都把一大段 prompt 重新塞给 Agent，让它重新理解背景、重新摸索工具、重新推导规则，那么 Loop 只是在反复购买同一份上下文。它每跑一轮，成本都会增加，但能力不一定沉淀。

Skill 的价值在这里出现了。它把稳定规则、项目知识、操作流程、失败经验、QA 标准和风格偏好写到外部。下一轮 Agent 不需要从零猜，它可以直接加载这套可复用的工作方式。

没有 Skill，Loop 只是一个昂贵的 while true。有 Skill，Loop 才开始积累组织记忆。

这也是为什么从 Harness 到 Loop，不应该先追复杂调度，而应该先沉淀稳定动作。如果一个任务你已经手动让 AI 做过十次，就可以问：哪些输入每次都要准备？哪些规则每次都要提醒？哪些错误每次都要检查？哪些结果每次都要写回？哪些条件下绝对不能继续？

这些东西写成 Skill，Loop 才有东西可以调用。否则系统看起来在循环，本质上还是每次重新开聊。

这一点很反直觉。很多人以为 Loop 是让 Agent 更自主，实际成熟的 Loop 是让 Agent 的自主行为被状态、验证、预算、权限和停止条件包住。

真正的分水岭，不是概念，而是责任位置

所以，Loop 是不是一个概念？

是。它确实是一个架构概念，不是一个具体按钮，也不是一个新工具名。但它不是空概念。它的价值在于改变我们看Agent系统的方式。

Prompt 时代，人对一次回答负责。Harness 时代，人对一次执行环境负责。Loop 时代，人开始对一个持续运行系统负责。责任位置变了。

你不再只是问：我怎样让 AI 这次做对？而应该开始问：如果它这次没做对，系统怎么知道、怎么记录、怎么修复、怎么停止？如果外部输入晚到了，系统怎么等？如果团队反馈来了，系统怎么进入下一轮？如果一个机会被证伪，它怎么不再反复出现？

这些问题才是 Loop 的本体。它不是更长的 prompt，不是更复杂的自动化，也不是给 Harness 换一个更潮的名字。

Loop 是把一次性智能，改造成可持续运行系统时必须补上的控制层。

这层没有做好，Agent 越强，系统越可能更快地产生混乱。这层做好了，Agent 才不只是一个能干活的助手，而是进入了一个能等待、能验证、能积累、能恢复、能停机的工作系统。

从这个意义上说，Loop Engineering 最值得学的地方，不是“循环”两个字，而是它逼我们承认一件事：当AI开始进入真实工作流，真正稀缺的不再是让它动起来，而是让它在动起来之后仍然可控、可查、可继承。

这是从 Harness 到 Loop 的真正变化。