Workflow、Agent、Harness 与 Loop Engineering

在一张 Agent 架构图里，常能同时看到 Workflow、Agent、Harness 和 Loop。它们被放在一起，不代表它们是同一种东西；把四个词混成一个“Agent 方案”，选型和排障很快就会失焦。

有人把工具调用叫 Agent，有人把状态图叫 Agent，有人把定时任务套一层模型也叫 Agent。Harness Engineering 和 Loop Engineering 进入讨论后，概念更容易被当成同一层的竞争品。

先把职责分开，后面才不用回答“LangGraph 和 OpenAI Agents SDK 谁更强”“MCP 能不能替代多 Agent”这类错位问题。这篇给出四个可以在架构评审里直接使用的工作定义：

• Workflow 决定预定路径；
• Agent 处理运行时的不确定选择；
• Harness 提供一次运行的执行边界；
• Loop Engineering 设计跨轮次的执行-验证-恢复闭环。

它们可以同时存在，而且经常应该同时存在。

先把已知过程写进 Workflow

Workflow 回答的是：哪些步骤必须发生，它们之间有什么依赖，失败后走哪条路径。

一个内容审核流程可以写成：

接收稿件
  -> 检查格式
  -> 检查敏感信息
  -> 事实核对
  -> 人工终审
  -> 发布或退回

其中某些节点可以调用大模型，但整体控制仍由工程师设计。Workflow 的优点是可预测、可审计、容易定义责任；它的局限也很明确：开放任务的分支很难穷举，网页会变化，用户表达千差万别，研究任务也无法提前知道所有分支。Workflow 不是旧技术，它是把已知约束留在代码中的方法。

在不确定处，才交给 Agent 选择

Agent 解决的问题是：面对当前目标和环境反馈，下一步应该做什么。

在刚才的“事实核对”节点里，Agent 可能决定搜索官方文档、查看 GitHub Release、读取论文，或者指出证据不足。开发者无法提前写出所有查询，却能限定它可用的工具、预算和输出格式。

Agent 的价值来自开放选择，风险也来自开放选择。如果一个系统里的所有步骤、分支和参数都由程序提前确定，大模型只是为某个节点生成文本，那么它更接近 AI Workflow。只有当模型在运行时拥有一定行动选择权，才出现 Agency。

Anthropic 的工程文章用 workflows 和 agents 区分预定义代码路径与模型动态控制，并建议从最简单的可组合方案开始。[1] 这张原文截图值得先看：它不是在给 Agent 贴更高级的标签，而是在把“预定义路径”和“模型动态控制”分开。这个边界比框架名称更有用。

图 1：Anthropic 的原始文章明确区分 Workflow 与 Agent。来源见文末。

Harness 负责把这一轮运行关进边界里

Harness 回答的是模型怎样运行。它装配上下文和工具，管理状态、权限和生命周期，执行动作、反馈结果、记录 Trace，并限制循环。第 2 讲已经详细讨论了八类责任。

关键区别在于：Harness 本身不必规定完整业务流程，也不必跨天重复同一目标。它首先承接一次 Agent Run。同一个 Agent 逻辑可以运行在不同 Harness 中：本地命令行、IDE、客服系统、后台 Worker。不同 Harness 会给它不同工具、权限、上下文和恢复能力，因此最终表现也会不同。SWE-agent 的研究把 Agent-Computer Interface 当作性能变量，就是一个直接提醒：模型相同，接口和 Harness 不同，结果也会变化。[2]

Loop Engineering 关心的是：下一轮为什么还要继续

Loop Engineering 是这四个词里最年轻、也最需要谨慎使用的一个。2026 年 6 月，Addy Osmani 用“Loop Engineering”总结围绕 Coding Agent 设计循环、反馈和 Harness 的工程实践，并引用 Peter Steinberger、Boris Cherny 等人的公开表达。随后出现了相关项目、文章和预印本。[3][4]

先看原始文章与原帖。它们说明这个词在公开讨论中如何出现，不是稳定性或成熟度的证明。

图 2：Addy Osmani 对 Loop Engineering 的原始公开总结。它是新兴工程术语，不是已经统一的行业标准。

图 3：Peter Steinberger 关于“设计 prompts Agent 的 loops”的原帖截图。来源见文末。

这里不把 Loop Engineering 当成已经定型的学科，只采用一个窄而可操作的定义：

Loop Engineering 是围绕持续目标，设计触发、执行、验证、状态、预算、恢复和停止规则的工程方法。

它关心的不是一次模型如何调用工具，而是系统怎样一轮接一轮推进现实状态，同时避免无限运行、错误验证和状态污染。一个 Coding Agent 可以在一次 Run 内修复测试；一个外部 Loop 则可能每天扫描新失败、创建隔离工作区、调用 Agent 修复、运行独立验证、保存证据，然后等待下一次触发。

内环负责“这一轮怎样做”，外环负责“为什么再次做、做到什么程度、什么时候永远停”。

用一个 CI Sweeper 把四层放到同一张桌子上

假设团队要建设一个 CI Sweeper：发现主分支失败后，自动分析并尝试修复。

Workflow 负责固定步骤：

收到 CI 失败事件
-> 收集日志和提交信息
-> 分类失败
-> 允许时创建隔离修复
-> 运行验证
-> 提交人工审查或结束

Agent 负责开放判断：阅读日志，判断是 Flaky Test、真实回归、基础设施故障还是权限问题；在允许修复时选择文件、命令和补丁。

Harness 负责这一轮运行：提供代码仓库、终端、测试工具、上下文、沙箱、预算和 Trace，限制 Agent 不能读取 Secret、不能直接推送主分支。

Loop Engineering 负责跨轮次控制：外层 Loop 定义什么事件能触发；同一失败是否已经处理；最多尝试几次；验证证据绑定哪个 Commit；没有进展时怎样熔断；什么时候转交人类；下一次从何处恢复。

四者可以同时存在，但职责不同。把这个例子换成客服、研究或内容系统，分层方式也不变。

用两条轴看系统，不必先争名字

比争论“它到底算不算 Agent”更有用的方法，是画两条轴。横轴是运行时决策自由度：左侧是所有路径由代码规定，右侧是模型可以动态选择更多动作。纵轴是生命周期长度：下方是单次请求，向上是跨分钟、小时、天甚至持续运行。

这样会得到四种典型系统：

类型	决策自由度	生命周期	主要工程重点
固定 AI Workflow	低	短	数据契约、节点错误
单次工具 Agent	中高	短	Harness、工具、停止
Durable Workflow	低中	长	状态、重试、补偿、版本
长时 Agent Loop	高	长	全部上述问题，再加验证与治理

越靠右上角，系统越不能靠 Prompt 单独承担可靠性。

一次外层 Loop，先把最重要的几件事想清楚

如果要设计一个持续运行的外层 Loop，先想清楚三件最核心的事：什么能触发它、怎样才算完成、谁检查结果。没有明确的触发条件，Loop 会变成无限循环；没有可验证的完成标准，它会一直“努力”却不知道何时停；验证方式不扎实，它会把错误重复很多次。

剩下的问题可以慢慢补充：允许接触哪些仓库、目录、系统和数据？这一轮由什么模型、工具、沙箱和权限运行？下一轮从哪里知道已经发生了什么？状态是否绑定源码和环境版本？最多运行多久、调用多少次模型、花费多少、连续失败几次？谁拥有当前尝试？怎样避免两个触发器同时修改同一个目标？谁能暂停或取消？

这些问题的共同目的，是让循环从“不断 Prompt”变成可治理的系统。下面的社区仓库可以作为实践导航：它整理了模式、starter 和工具，但不应被当作统一规范。

图 4：社区仓库把 Loop Engineering 组织成模式、starter 和工具；它适合作为实践导航，不应被当作统一规范。

几个常见的错位判断

不要以为只要有 while 就是 Loop Engineering。程序循环只是语法，Loop Engineering 真正关心的是目标、证据、状态、预算和责任。

也不要以为用了状态图就不需要 Agent。状态图可以限定路径，节点内部仍可以由 Agent 处理开放问题，图和 Agent 常常互补。反过来也一样：Agent 越自由，Workflow 越不该被当成“落后”的东西–高风险步骤恰恰需要固定 Workflow，审批、付款、发布和数据删除不适合交给模型自由发挥。

最后要注意：外层 Loop 不能自动修复内层错误。如果验证器本身错误，外层循环只会更稳定地制造错误。这叫 Verifier Theater：看起来有检查，实际检查没有证明力。

拿手头任务填完这四格（30 分钟）

选择一个真实任务，例如“每周生成销售异常报告”。不要先画架构图，先按四栏把职责写下来：

Workflow：必须经过哪些固定步骤？
Agent：哪些判断无法穷举，需要模型选择？
Harness：模型能看到什么、调用什么、以什么权限执行？
Loop：何时再次触发，怎样验证、恢复、停止？

最后问三个问题：有哪些确定性规则被错误地塞进了 Prompt？有哪些开放判断被写成了难以维护的分支？如果验证器失效，系统会不会仍然继续运行？

这三个答案，通常比选择哪个框架更早。

边界与下一步

Workflow、Agent、Harness 和 Loop Engineering 是四层责任，不是四个互斥产品。

Workflow defines the path.
Agent chooses under uncertainty.
Harness controls the run.
Loop Engineering controls repetition.

程序规定可控路径，Agent 处理不确定判断，Harness 约束一次运行，Loop Engineering 管理持续推进。四者的边界会因具体产品而有取舍，但不能用一个新名词遮住已经存在的权限、验证和状态问题。

第一单元到这里完成。下一讲进入单 Agent 的第一项硬能力：怎样把模型生成的自然语言，变成程序能够验证和执行的结构化工具契约。

---

资料与延伸阅读

以下链接均为本章已经引用的原始文章、论文或公开项目。先读 [1] 对齐 Workflow 与 Agent，再读 [3]、[4] 追溯 Loop Engineering 的公开语境，最后把 [5] 当作实践导航。

[1] Anthropic, Building Effective Agents. https://www.anthropic.com/engineering/building-effective-agents

[2] Yang et al., SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. https://arxiv.org/abs/2405.15793

[3] Addy Osmani, Loop Engineering. https://addyosmani.com/blog/loop-engineering/

[4] Peter Steinberger, X post. https://x.com/steipete/status/2063697162748260627

[5] cobusgreyling, loop-engineering. https://github.com/cobusgreyling/loop-engineering

[6] Stop Hand-Holding Your Coding Agent. https://arxiv.org/abs/2607.00038

[7] Proof-or-Stop. https://arxiv.org/abs/2607.14890

[8] Wu et al., StateFlow. https://arxiv.org/abs/2403.11322