Loop Engineering 不是 Harness Engineering 的下一代，是它的一种长运行形态

这两天，我的信息流被"Loop Engineering"占领了。

叙事很整齐：AI 工程方法经历了 Prompt Engineering → Context Engineering → Harness Engineering，现在正式进入 Loop Engineering 时代。文章一篇比一篇恢宏，仿佛旧范式正在被新范式替代。

但我越读越觉得不对劲。

不是因为 Loop 这个概念没有价值。它捕捉到了一个真实的变化。人开始从亲自 Prompt Agent，转向设计能够持续发现任务、调用 Agent、验证结果并再次运行的自动化系统。这个变化是真实的。

问题出在命名上：把一个 Harness 体系内的编排模式，包装成了与 Harness 平级、甚至超越 Harness 的"新时代"。

这轮热潮是怎么来的

这一轮传播的直接来源非常集中。

2026 年 6 月 7 日，Addy Osmani 发表《Loop Engineering》，引用了 Peter Steinberger 和 Claude Code 负责人 Boris Cherny 的两句话：

不应该再亲自 Prompt Agent，而应当设计"能够 Prompt Agent 的循环"；
"我现在不再直接 Prompt Claude，我的工作是写 Loop。"

Addy 随后将 Loop 描述为一个系统：自动发现和分配工作，定时或事件触发，启动 Agent，检查结果，写入外部状态，决定下一项工作，再次执行。

但 Addy 自己其实已经明确说了：Loop Engineering"位于 Harness 之上一层"。更直白地说，是"一个运行在定时器上、能够产生辅助 Agent、并把结果重新喂给自己的 Harness"。

这句话恰恰说明，它并没有摆脱 Harness。所谓 Loop 仍然要依赖：Automations、Worktrees、Skills、MCP/Connectors、Sub-agents、外部 Memory、权限控制、评估器、状态机、失败重试、人工接管。这些全部是 Harness 的组成部分，或者 Harness 所提供的运行原语。

这个词更像是一线实践者对工作方式变化的一个传播性概括，而不是经过系统定义、边界论证和实践验证的成熟学科。

Loop 只是控制流形态，不是完整工程体系

这里需要做一个区分。不能把 Loop Engineering 简单地等同于 Claude Code 的 /loop 命令。后者只是 Claude Code 在单次 CLI 会话内反复执行 Prompt 的轻量触发机制。当前博主讨论的 Loop Engineering 范围要大得多：定时器触发、任务发现与分类、建立隔离工作区、调用 Agent 执行、另一 Agent 验证、记录进度、判断继续或停止或升级给人、进入下一轮。

它是一个更完整的编排模式。但问题在于：这个模式里的所有能力，都不来自 Loop 本身。

在每一轮循环内部，系统仍然需要回答：模型能看到什么上下文？能使用哪些工具？权限边界在哪里？如何保存和恢复状态？失败后怎么处理？多 Agent 如何隔离？什么时候停止，什么时候交还给人？

这些问题的答案，全部属于 Harness 设计。Anthropic 对 Agent Harness 的定义非常清楚：Harness 是使模型能够作为 Agent 运作的系统，负责处理输入、编排工具调用并返回结果。Claude Code 本身就是一个 Agent Harness。

从系统结构上看，四个概念的关系不是线性替代：

Model
  ↓
Prompt / Context
  ↓
Agent Harness
  ├─ 工具
  ├─ 权限
  ├─ Skills
  ├─ Hooks
  ├─ Memory
  ├─ Sub-agents
  ├─ Evaluators
  ├─ Worktrees
  └─ 状态管理
         ↓
Loop / Schedule / Event Trigger

Loop 甚至不是严格位于 Harness"上面"，而是 Harness 内部可采用的一种控制策略。Harness = 执行环境 + 控制结构。Loop = Harness 可采用的其中一种控制结构。

单纯因为系统多了 while not done: run_agent() 就宣布进入一个新工程时代，命名膨胀的痕迹太重了。

这四个概念本来就不是同一层级

互联网最容易制造的叙事，就是把不同层级的东西排成进化树：

Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering

仿佛前者已经过时，后者依次替代前者。

实际上，四个词的研究对象完全不同：

概念	主要工程对象	回答的问题
Prompt Engineering	单次指令表达	怎么把任务说清楚
Context Engineering	输入信息的选择与组织	模型这一次应当看到什么
Harness Engineering	Agent 的运行环境与约束系统	模型如何使用工具、权限、状态和反馈完成任务
Loop Design	重复执行与持续反馈机制	系统何时再次运行，如何利用上一轮结果

它们不是版本迭代关系。它们是包含和协同关系。一次 Loop 需要一个 Harness 执行，一次 Harness 执行需要组织 Context，Context 中仍然包含 Prompt。

不存在"Prompt 时代结束，Loop 时代到来"。实际发生的是：随着 Agent 自主运行时间增长，工程重心从单条 Prompt 逐步扩展到 Context、Harness、Evaluation 和长期状态管理。这是关注面的扩张，不是旧范式被新范式替代。

Anthropic 自己的研究也这么说

Anthropic 在长时间运行 Agent 的研究中，始终使用的是 Harness 语言，而不是 Loop Engineering。

2025 年 11 月，Anthropic 为长期任务设计的方案包括：初始化 Agent、分阶段编码、claude-progress.txt、Git 历史、每轮留下结构化交接材料、跨 Context Window 恢复工作。这些 Agent 当然在反复循环执行，但 Anthropic 称之为"long-running agent harness"，并明确指出：仅仅把模型放进循环中并不足以完成复杂应用。

2026 年 3 月，Anthropic 进一步设计了 Planner、Generator、Evaluator、Context reset、Structured handoff、多轮迭代。这已经具备了今天所谓 Loop Engineering 的大部分结构，但 Anthropic 依然将其称为 Harness Design，而且明确说这些多 Agent 和循环机制是建立在原有 Harness 基础之上的。

技术结构早已存在。新出现的主要是命名，而不是全新的工程对象。

Loop 真正新增的，是一个值得强调的控制维度

Loop 这个概念并非毫无价值。它提醒使用者从一次性任务转向持续性系统。

以前是：人找任务 → 人写 Prompt → Agent 执行。

Loop 之后是：系统找任务 → 系统组装 Context → Agent 执行 → 系统验证 → 系统记录 → 系统再次触发。

其中真正值得独立研究的问题包括：触发策略（定时、事件还是状态变化）、停止条件（怎样防止无限循环）、反馈设计（上一轮结果如何影响下一轮）、状态持久化（怎样跨会话保存进度）、任务选择（系统下一步做什么）、验证机制（谁检查 Agent）、升级机制（何时交给人）、成本预算、幂等性、漂移控制和退化控制。

这些确实构成一个相对聚焦的工程专题。但比较合适的名字可能是 Agent Loop Design、Long-running Agent Orchestration 或 Recurring Agent Workflow Design，而不是用"Loop Engineering"制造一种已经超越 Harness Engineering 的历史阶段感。

一个更准确的定位

我建议用三个层次重新理解这件事。

第一层，Agent Loop。模型内部已经存在基本循环：观察、推理、工具调用、获取结果、再推理。这是 Agent 能够行动的基本机制。

第二层，Harness。Harness 决定这个循环如何运行：允许调用什么工具、读取什么上下文、采用什么权限、如何验证、如何处理错误、如何保存状态、何时终止。

第三层，Long-running Orchestration。通过定时器、事件、任务队列或外部状态，反复启动 Harness：发现任务、启动 Harness、得到结果、更新外部状态、再发现任务。

所谓 Loop Engineering 主要是在强调第三层。但第三层并没有使第二层失效。相反，它越长期、越自动，越依赖成熟的 Harness。

简化成一个公式：

Loop Engineering ≈ Harness Engineering + 定时触发 + 跨轮次状态传递 + 任务发现

这不是一个新范式。这是 Harness Engineering 在持续运行场景中的一种配置。

Loop 不是 Harness 之后的新范式，而是 Harness 走向持续运行以后暴露出来的一个编排维度。

Loop Engineering 不是 Harness Engineering 的下一代，是它的一种长运行形态。

或者更尖锐一点：Loop 只是让 Harness 再跑一遍。没有好的 Harness，Loop 只是在重复制造错误。

下次有人在时间线上宣布"X Engineering"时代来临，先别急着转发。看看 X 到底定义了什么新控制结构，改变了什么解题方式。如果答案只是"它让旧系统多跑了几次"，那不是工程革命，是营销革命。

作者简介： 陈石律师，浙江海泰律师事务所副主任、高级合伙人、房地产与建设工程部主任，宁波市律师协会副秘书长、第七届宁波仲裁委员会仲裁员，聚焦建筑房地产、投融资、并购重组及商事争议解决。曾获多家法律媒体与专业机构认可，荣登 LegalOne 2025 中国区建工及房地产实务先锋 45 强、律新社 2025 年度管理合伙人 20 佳（华东），入选《商法》The A-List 法律精英，获评 ALB China 区域市场十五佳长三角地区律师新星，并获律新社 2024 年度并购领域品牌之星。长期为万科、华润置地、信达地产、保利置业、招商蛇口、中海地产等企业提供法律服务，承办"首宗百亿地王""长春第一高楼""台州第一高楼"等代表性项目，累计服务项目投资额超千亿。近年来持续推动 AI 与法律实务融合，强调以结构化方法打通技术逻辑、法律判断与商业场景；著有《赋能法律人：AI 底层思维与应用范式》，并在多地开展相关主题讲座与分享。四明山法师 AI 夜校（legalAGI.cn）发起人。