Loop 不是 Agent 架构，Harness 才是

我还是原来的观点，harness > all（除 llm 外），没必要一直造词了。真是共识不够，造词硬凑。即：意图 → Harness → 目标。

编程也是类似，从指令到意图，写代码，维护代码的方式也在发生根本性转变。即：意图 → 文档（Harness 架构工程） → 代码。

其实之前写过不少类似文章，忘记的朋友可以回看：

• 深度思考：架构腐朽 & Loop Engineering
• 浅谈 AI 编程
• 第一个 Agent 从 Pi 开始
• 深度解析：Harness Engineering
• 顶层思维
• Token 命名困境：当信息论闯入语言学
• AI 操作系统：从指令到意图

先放下 Loop

只要一个系统根据反馈调整行为，loop 就会出现。

恒温器是 loop。瓦特的离心调速器是 loop。PID 控制器、操作系统 event loop、TCP 拥塞控制、数据库重试、CI/CD 流水线、Raft 心跳和选举，也都有 loop。

但成熟工程从不因为「它会循环」就以 loop 命名自己。控制工程不叫 Loop Engineering，网络协议不叫 Retry Engineering，数据库不叫 Transaction Loop Engineering，分布式共识也不叫 Heartbeat Engineering。

原因很简单：loop 只是外观，工程含量藏在 loop 背后的控制律、状态语义、边界条件、失败处理、验证机制和系统不变量里。

更直接一点：loop 不是工程，受控的 loop 才可能成为工程。

下面用五级台阶把这个问题拆开。每一级都不是在证明「loop 没用」，而是在说明：loop 必须依附于更强的工程结构，才有可靠性可言。

五级台阶

控制系统：循环只是载体

恒温器有 loop：传感器采样，控制器判断，执行器调节，环境反馈回来。

但恒温器真正的工程问题，从来不是「有没有 loop」，而是滞回区间怎么设、采样频率多少合理、异常读数如何处理、极端环境下是否安全。

没有滞回，临界温度附近就会反复抖动；没有安全阈值，执行器可能把系统推向危险区；没有故障检测，传感器坏了以后，控制器仍然会认真执行错误判断。

PID 也是闭环，但大家讨论的是控制律、稳定性、过冲、振荡、参数整定和抗扰动能力。没人画一张「输入 → 输出 → 反馈」的图，就宣布自己发明了控制理论。

对应到 agent，单纯的：Plan → Act → Observe → Repair → Repeat。

这还只是水管图，真正问题是：怎么判断偏差？怎么限制动作？怎么避免震荡？怎么停止？怎么证明这一步确实让系统更接近目标？

这一层交出的关键词是：控制律 / 稳定性 / 安全边界

TCP：可靠来自状态

TCP 也有反馈闭环：观察 ACK、丢包、延迟和超时，然后调整发送窗口，触发重传或恢复。

但 TCP 的可靠性不来自「会重试」，而来自一整套协议语义：序列号 / ACK / 窗口 / 超时 / 拥塞判断 / 顺序恢复 / 流控边界

没有这些状态语义，重试只是重复发送；有了这些语义，重试才变成可靠传输的一部分。

Agent 也是一样。一个 agent 不是因为会 retry 就可靠，而是因为它知道当前处在哪个状态、这一步依赖什么上下文、之前做过什么、哪些结果可信、哪些失败需要换路径、哪些动作不能再来一次。

否则所谓 loop 很容易变成：失败 → 再试 → 再失败 → 再烧钱

这不是智能增强，而是自动化扩大事故半径。

这一层交出的关键词是：状态 / 契约 / 失败语义

CI/CD：核心是检查点

CI/CD 也是 loop：提交、构建、测试、检查、部署、报警、回滚，失败后修复再提交。

但 CI/CD 的价值不是「它会一直跑」，而是它把软件交付变成了一套可验证制度。每一道检查点都回答一个具体问题：

• 什么变更能进入下一阶段？
• 什么风险必须拦截？
• 什么结果可以被接受？
• 什么失败必须停下来？

CI/CD 不是让代码一直跑，而是让代码过不了就停。

这点对 agent 更关键。一个会自动迭代的 agent，如果没有检查点，就只是在更高频率地产生未经验收的动作。它可能每一步都显得合理，但整体上不断偏离目标。

所以「自动修复」之前必须有「什么算修好」；「继续执行」之前必须有「什么条件下允许继续」。

这一层交出的关键词是：验证 / 质量闸门 / 验收标准

数据库：重试不是本体

数据库里全是失败处理：事务冲突重试，死锁回滚再试，网络失败后恢复。但数据库不会把自己宣传成 Transaction Loop Engineering。

因为真正支撑可靠性的，是 ACID、隔离级别、锁、MVCC、日志、恢复协议和幂等设计。重试只是其中一种处理策略，不是系统本体。

Agent 一旦开始改代码、调接口、写数据库、发邮件、发通知、下单、部署，就会面对同一类问题：

• 这个动作能重复执行吗？
• 执行到一半失败怎么办？
• 状态记录在哪里？
• 谁能证明它完成了？
• 能不能回滚？
• 不能回滚时如何补偿？

这些问题没有一个能靠「再 loop 一次」解决。相反，loop 往往会放大它们：

• 没有幂等设计的 loop = 重复副作用机器
• 没有事务边界的 loop = 自动化灾难发生器
• 没有审计证据的 loop = 事后无法复盘的黑箱

这一层交出的关键词是：边界 / 幂等 / 审计 / 恢复

Raft：循环服从不变量

分布式系统里的 loop 更多：心跳是 loop，选举是 loop，日志复制是 loop，失败检测也是 loop。

但 Raft 的价值不在它一轮轮发心跳，而在它无论怎么循环都必须守住一组不变量：

• 同一任期最多一个 leader
• 已提交日志不能丢
• 多数派确认才算提交
• 状态机按日志顺序执行
• 故障后必须能恢复一致

没有不变量，loop 越勤快，系统越混乱；有了不变量，loop 才有方向和边界。

这也是 agent 工程最容易漏掉的一点。很多演示把「能自己多跑几轮」当成能力，但真正重要的是：它多跑几轮以后，哪些事实不能被改写？哪些权限不能被扩张？哪些副作用不能被重复？哪些失败必须显式暴露？

这一层交出的关键词是：不变量 / 一致性 / 可恢复性

合起来才是 Harness

现在把五级台阶攒下来的词放在一起：

控制律 / 稳定性 / 安全边界
状态 / 契约 / 失败语义
验证 / 质量闸门 / 验收标准
边界 / 幂等 / 审计 / 恢复
不变量 / 一致性 / 可恢复性

这些词叠起来，才是 agent 系统真正需要的骨架。这个骨架可以叫 harness。

一个面向 agent 的通用 harness，至少要回答五类问题：

目标与边界：要逼近什么，能在哪些范围内行动？
上下文与状态：它看见了什么，当前站在哪里？
规则与工具：什么能做，什么不能做，用哪些工具做？
验收与证据：什么算成功，如何证明结果？
失败与停止：失败后怎么回来，什么时候必须停？

其中「证据」很关键：一次执行不能只停留在模型说了什么、工具返回了什么，而要把尝试、成功结果或失败原因写成可审计事实。

这时再看 loop，它的位置就清楚了：loop 不是上面任何一个问题的答案。它只是这些问题被反复执行时形成的节拍。

错误的层级是：

Loop
  → Harness
    → Context
      → Tools

这等于把控制流当成系统边界。更稳的层级是：

Intent
  → Harness
    → Goal / Boundary
    → Context / State
    → Rules / Limits
    → Tools / Sandbox
    → Evidence / Review
    → Failure Handling / Stop
      → Loop: execute → observe → adjust
  → Goal

Loop 可以在里面跑，而且应该跑。但它必须被 harness 包住。

因为最外层代表的是系统边界、责任归属和不变量。Loop 负责下一轮，Harness 负责这一轮能不能发生、发生后算什么、失败后怎么收场。

一句话收束：模型可以犯错，但 harness 不能跟着失控。

新变量：LLM 进了控制器

Agent 当然有新东西，但新的不是 loop。

控制系统有 loop，操作系统有 loop，网络协议有 loop，数据库恢复有 loop，CI/CD 有 loop，分布式共识也有 loop。人类工程系统早就被 loop 浸透了。

Agent 真正的新东西，是 LLM 被放进了控制器里最不稳定、也最有价值的位置：判断、规划、解释、修复、生成、取舍。

过去的 controller 多数是规则、算法、状态机、控制律。它可能复杂，但行为边界相对明确。

现在，一部分控制逻辑变成了概率模型：

传统系统：显式规则或状态机参与控制
  → 更确定，更容易验证边界

Agent 系统：LLM 参与规划、判断和修复
  → 更灵活，也更可能幻觉、越界、误判和过度自信

这不是让 harness 变得不重要，恰恰相反。LLM 越强，越需要外层结构把它的能力压进可治理流程里。

所以 agent 工程的底层逻辑应该是：

模型越强，harness 越不能弱。
agent 越自主，边界越要硬。
任务越长，状态越要可回放。
工具越多，权限越要细。
副作用越真实，结果越要落账成可审计事实。

如果 loop 只是让模型多试几次，那么模型越强，事故半径也会越大。只有 harness 能把「多试几次」变成「在可控边界内逐步逼近目标」。

迁移：从 Prompt 到 Harness

早期 AI 编程，本质上还是把 LLM 当生成器：指令 → Prompt → 输出。

人站在循环里，负责补上下文、判断结果、纠正方向、决定是否继续。换句话说，边界、验收和停止条件还都压在人身上。

Loop Engineering 描述的变化是：人不再手动拨动每一轮，而是把发现、计划、执行、验证、迭代交给一个系统去跑。这个变化是真实的，但它只完成了执行自动化，还没有完成治理外部化。

如果只是「让它自动多跑几轮」，人只是从键盘前移到了调度器旁边。真正的迁移，是把人的判断、边界和验收标准外部化成系统契约：

• Prompt 时代：  指令 → Prompt → 模型输出
• Loop 时代：    目标 → 执行 → 观察 → 修正 → 再执行
• Harness 时代： 意图 → 边界 / 权限 / 状态 / 验证 / 恢复 → 受控执行 → 证据

放到编码场景里，就是：意图 → 文档化 Harness → 代码 / 产物 → 运行证据

这里的「文档化 Harness」不是写一堆愿景，也不是把 README 当神谕。它是 agent 行动前必须读取、行动中必须服从、行动后必须接受审计的外部契约。

它先把目标和边界说清楚：什么结果算达成，哪些范围内可以行动，哪些上下文必须读取，哪些工具能用。它再把执行和验收说清楚：哪些动作需要检查或人工确认，中间状态写在哪里，用什么测试和人工标准验收。最后，它把失败和证据说清楚：失败后重试、继续、对账、回滚、询问还是停止，用什么证据证明结果。

这才是「从写代码到设计 harness」的实际含义。代码仍然是运行实体，不会因为 AI 出现就变成无关紧要的副产品；但决定代码能否被接受的上游，正在从一次性 prompt，迁移到文档、契约、测试、日志、结果落账和恢复路径组成的执行系统。

人的位置也随之变化：过去人在 loop 里，手动提供每一轮反馈；现在人在 loop 外，设计 loop 的边界、证据和停止条件。这比「写一个会循环的脚本」难得多，也更接近真正的工程。

Harness > Loop

现在可以回到最初那句话：Harness > Loop。

它不是说 loop 不重要，而是说 loop 的层级不能错。Loop 负责继续跑，harness 负责判断能不能跑、跑到哪里算数、失败后怎么收场。

没有 harness，agent loop 最常见的结果不是智能，而是更快地产生未经约束的动作、消耗更多 token、扩大副作用，并在事后说不清到底发生了什么。有了 harness，loop 才变成工程策略：意图被收束，动作经过检查，工具运行在隔离边界内，结果落账成可审计事实，失败有恢复路径。

所以我更愿意说：Agent 不是 loop 出来的，是 harness 约束出来的。

LLM 提供马力，loop 提供节拍，harness 提供边界、仪表、刹车、护栏和验收标准。

结语：控制流不是世界观

Loop Engineering 的价值在于提醒大家：不要再把 agent 当成单轮生成器，应该设计能持续反馈、持续验证、持续推进的系统。

但它的边界也在这里：如果把 loop 当成总范式，就会把一个局部机制抬成世界观。看到 TCP 重传，不该发明 Retry Engineering；看到数据库事务失败重试，也不该发明 Transaction Loop Engineering。

真正的工程师不会崇拜 loop。他会先问边界、状态、证据、权限、停止条件、恢复路径和不可改写的不变量。回答不了这些，只说「让 agent 自己 loop 起来」，那不是工程，是把控制权外包给概率系统。

Loop 只是闭环的影子，Harness 才是闭环的骨架。