Workflow、Agent、Harness 与 Loop Engineering

Agent 领域最麻烦的问题之一，不是缺少新概念，而是不同层级的概念常被放进同一句话。

有人把工具调用叫 Agent，有人把状态图叫 Agent，有人把定时任务套一层模型也叫 Agent。近来 Harness Engineering 和 Loop Engineering 又进入讨论，概念更容易混在一起。

如果不先分层，后面的技术选型会变成品牌比较：LangGraph 和 OpenAI Agents SDK 谁更强，MCP 能不能替代多 Agent，Loop Engineering 是不是新的 Prompt Engineering。

这些问题之所以难答，是因为比较对象本来就不在同一层。

这一讲给出四个工作定义：

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

它们可以同时存在。

一、Workflow：把已知过程写出来

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

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

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

其中某些节点可以调用大模型，但整体控制仍由工程师设计。

Workflow 的优点是可预测、可审计、容易定义责任。缺点是开放任务很难穷举。网页会变化，用户表达千差万别，研究任务也无法提前知道所有分支。

所以，Workflow 不是旧技术。它是把已知约束留在代码中的方法。

二、Agent：在不确定处选择动作

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

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

Agent 的价值来自开放选择。风险也来自开放选择。

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

Anthropic 的工程文章用 workflows 和 agents 区分预定义代码路径与模型动态控制，并建议从最简单的可组合方案开始。[1]

图 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：发现主分支失败后，自动分析并尝试修复。

Workflow 负责固定步骤

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

Agent 负责开放判断

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

Harness 负责这一轮运行

Harness 提供代码仓库、终端、测试工具、上下文、沙箱、预算和 Trace。它限制 Agent 不能读取 Secret、不能直接推送主分支。

Loop Engineering 负责跨轮次控制

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

四者缺一不可，但职责不同。

六、用两条轴判断一个系统

比争论“它到底算不算 Agent”更有用的方法，是画两条轴。

横轴：运行时决策自由度

左侧是所有路径由代码规定，右侧是模型可以动态选择更多动作。

纵轴：生命周期长度

下方是单次请求，向上是跨分钟、小时、天甚至持续运行。

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

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

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

七、Loop Engineering 的八个字段

旧稿曾把一个可靠 Loop 拆成八个字段。迁入新体系后，这套结构仍然成立：

1. Trigger

什么事实允许创建新一轮？定时器、CI 事件、队列消息还是人工请求？

2. Goal

要改变什么现实状态？目标必须能被验证。

3. Scope

允许接触哪些仓库、目录、系统和数据？明确非目标。

4. Harness

这一轮由什么模型、工具、沙箱和权限运行？

5. Verification

谁检查结果？检查环境终态、测试、工件还是业务规则？

6. State

下一轮从哪里知道已经发生了什么？状态是否绑定源码和环境版本？

7. Budget

最多运行多久、调用多少次模型、花费多少、连续失败几次？

8. Ownership

谁拥有当前尝试？怎样避免两个触发器同时修改同一个目标？谁能暂停或取消？

这些字段的共同目的，是让循环从“不断 Prompt”变成可治理的系统。

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

八、四个常见误判

误判一：只要有 while 就是 Loop Engineering

程序循环只是语法。Loop Engineering 关心目标、证据、状态、预算和责任。

误判二：用了状态图就不需要 Agent

状态图可以限定路径，节点内部仍可以由 Agent 处理开放问题。图和 Agent 常常互补。

误判三：Agent 越自由，Workflow 越落后

高风险步骤恰恰需要固定 Workflow。审批、付款、发布和数据删除不适合交给模型自由发挥。

误判四：外层 Loop 能修复内层错误

如果验证器本身错误，外层循环只会更稳定地制造错误。这叫 Verifier Theater：看起来有检查，实际检查没有证明力。

九、30 分钟练习：把一个任务分成四层

选择一个真实任务，例如“每周生成销售异常报告”，分四栏填写：

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

最后问三个问题：

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

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

十、这一讲的结论

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] 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