Harness、Loop 与 Graph：Agent 工程真正要设计的，是不确定性

过去一年，Agent 工程里陆续流行起三个词：harness engineering、loop engineering、graph engineering。它们听起来像又一轮术语竞赛，甚至像一条升级路线：写完 prompt，开始做 harness；做完 harness，升级成 loop；loop 不够，再画 graph。但这三个词仍是快速形成中的业界实践标签，并没有一套统一的学术定义。

我更愿意把它们理解成三个正交的控制面，而不是三个互相替代的流派：Harness 控制 Agent 的工作世界，Loop 控制它在时间中的反馈，Graph 控制多个步骤之间的拓扑。真正的 Agent 系统，无论有没有使用同名框架，都必须回答这三类问题。

这个区分之所以重要，是因为 Agent 的基本工程单位已经不是提示词，而是一个可控系统。模型只负责在局部做判断；系统还要决定它能看到什么、能调用什么、怎样知道自己错了、何时继续、何时停止，以及哪一步必须交还给确定性代码或人。

如果要把三者压缩成三个问题，就是：Agent 能看见、行动并证明什么？它如何根据行动后果继续、纠错并停止？任务允许沿哪些路径分支、并行、回退和汇合？第一个问题属于 Harness，第二个属于 Loop，第三个属于 Graph。

一、Harness 定义工作世界。OpenAI 在 2026 年 2 月复盘 Codex 团队的 agent-first 开发时，发现瓶颈往往不是模型不会写代码，而是环境没有被表达清楚：工具不足、仓库结构不易理解、约束只存在于人的脑子里、失败以后也没有足够明确的修复信号。于是工程师的工作从“亲自实现”转向设计环境、表达意图和建设反馈。

所以 Harness 不只是套一层 CLI，也不只是把 prompt 变长。它包括工作目录、工具、权限与沙箱、项目说明、可查询的文档、持久化状态、上下文交接、日志，以及测试和 lint 产生的反馈。它回答的是：这个 Agent 进入了一个怎样的世界，这个世界允许什么，又如何把对错说清楚。

一个好的 Harness 会让代码库对 Agent 可读。规则不该埋在几百页说明里，而应成为一张可以逐层展开的地图；架构边界不该只靠 review 发现，而应尽可能被类型、测试、静态检查和带修复建议的错误信息执行。模型能力越强，这类环境设计越重要，因为 Agent 能走得更远，也就能把一个模糊假设放大得更远。

但 Harness 解决不了时间问题。你可以给 Agent 很好的工具、完整的仓库和精确的权限，它仍可能只做一次尝试，然后用一段流畅的文字宣布完成。Harness 让它有能力工作，却不自动保证它会在失败以后继续，也不保证它知道什么时候应该停。

二、Loop 定义时间中的反馈。最小的 Agent loop 是：接收目标，选择行动，观察结果，根据新证据调整，再决定继续还是结束。ReAct 在 2022 年展示了推理、行动与环境观察的交错；今天所谓 loop engineering，是把这个模式从模型行为扩展成可运营的执行制度。

Loop 工程绝不是给任务外面套一个 `while true`。一个可用的 loop 需要显式状态、可恢复的检查点、失败分类、重试预算、上下文压缩、评价器、升级路径和停止条件。最关键的一点是：下一轮必须消费上一轮的新证据。如果每轮只是把原来的提示词再发一次，重复不会带来收敛，只会更快地固化错误。

OpenAI Agents SDK 的运行模型很能说明这件事：模型输出最终答案时循环结束；模型请求工具时，系统执行工具并把结果送回下一轮；发生 handoff 时，当前 Agent 和输入被更新；超过最大轮数则停止。IBM 在 2026 年对 loop engineering 的总结也把目标、行动、观察、调整，以及调度、hooks、上下文、工具和人工监督放在同一套系统里。

Loop 的风险也很直接：如果 Harness 不可靠，循环只是在自动化地重复错误。测试命令本来就错、工具权限过大、验证器读到旧产物、Agent 无法区分可恢复与不可恢复失败时，多跑十轮不会增加可靠性。没有证据门槛的坚持，不叫自主性，只叫失控。

三、Graph 定义协作的拓扑。Graph 把状态、工作单元和转移关系显式化：一个节点可以是一段确定性代码、一次模型调用、一个工具、一个人工审批，也可以是带有自己 Harness 和 Loop 的完整 Agent；边可以固定、条件分支、动态生成、并行扇出，也可以回到前面的节点形成循环。

Graph 的价值不在于图画得漂亮，而在于把不该交给模型临场决定的结构写进系统。分类之后走哪条合规路径，哪些研究任务可以并行，失败几次后必须升级，付款或发布之前谁来批准——这些都适合成为显式的节点和边。Graph 让流程可观察、可恢复，也让责任边界更容易审计。

但 Graph 也不是越细越先进。Anthropic 很早就提醒，Agent 的自由度会带来成本与延迟，应从最简单可行的方案开始；LangChain 在 2026 年回顾 Graph 工程时也承认，他们曾试图把开放式深度研究塞进预定义路径，后来改用更 Agentic 的 Harness。探索性越强，越需要让节点内部保留判断；合规性越强，越需要把边固定下来。

到这里，三者的关系就清楚了：Loop 在拓扑上可以被看作一个有环图，但 Loop 工程关注的是反馈是否新鲜、状态能否恢复、预算和停止条件是否合理；Graph 工程关注的是节点之间允许怎样流动。一个 Graph 可以容纳多个 Loop，一个节点也可以是运行在完整 Harness 里的 Agent。它们是不同尺度的设计镜头。

最常见的失败也可以据此解释。只有 Harness，没有 Loop，是一个装备齐全但仍需人反复催促的一次性执行器；只有 Loop，没有 Harness，是把不可靠的动作高速重复；只有 Graph，没有可靠节点，是一张精致的编排图连接着一组不可预测的黑箱。复杂度并没有消失，只是被藏到了更难诊断的位置。

该先做哪一层，取决于任务的不确定性。一次性的开放探索，优先增强 Harness，让工具、上下文和证据足够好，Graph 保持轻量；重复发生且结果可客观验证的任务，优先设计 Loop；多角色、强分支、需并行或受监管的流程，再把 Graph 显式化。高风险的长期系统最终往往三者都有，但不必同时从最重的实现开始。

以 AI Coding 为例：需求进入、仓库探索、实现、测试、review、人工批准和合并，可以组成外层 Graph；实现与测试之间是一个根据失败证据持续修正的 Loop；每个 coding Agent 则运行在由仓库规则、工具权限、沙箱、测试命令和提交约束构成的 Harness 里。这里不需要三个框架，甚至不需要多 Agent，但三个问题一个都不能缺席。

更深一层看，Harness、Loop 和 Graph 的共同目标，是决定不确定性应该被放在哪里。模糊需求、开放探索和方案生成，可以让模型保留较大的判断空间；权限扩大、数据删除、付款、发布和合并这类不可逆边界，则应该由确定性规则、新鲜证据和人工授权控制。最可靠的系统不是处处自主，而是自由与约束放置得准确。

这也改变了人类在系统中的角色。人不应该永远站在循环外面替 Agent 按“继续”，也不该等到最后才接收一个无法解释的结果。更好的位置是在目标定义、证据标准、异常升级和不可逆节点上。人的判断越稀缺，就越要把它放在会改变风险的地方，而不是平均撒在每一步。

所以我对这三个新词的判断是：可以使用，但不要把它们当成新的身份标签。Harness engineering 让环境可行动、可理解、可验证；loop engineering 让执行从重复走向收敛；graph engineering 让协作从隐含脚本走向显式结构。最终的竞争也不会是谁拥有最时髦的名词，而是谁能把模型的不确定性，组织成可重复、可恢复、可审计的结果。