大多数agent系统失败，不是因为模型太弱。而是因为围绕模型的系统从未被当作系统来设计。工具不可靠，状态在运行之间消失，agent重试却不学习任何东西，工作流以无人可检查的方式分支——然后每一次失败都被归咎于模型。这是错误的诊断。

一个严肃的agent背后有三个不同的工程层：harness给模型一个工作场所，loop给工作一个反馈循环，graph给过程一条明确的路线。它们重叠，它们可以相互包含，但它们解决不同的问题。

核心框架（30秒版本）：

·模型决定 →Harness让它行动 →Loop让它证明结果 →Graph控制接下来允许发生什么
·Harness工程：构建模型周围的操作环境（工具、记忆、文件、权限、沙箱、路由、检查点、追踪、人工审批）
·Loop工程：设计重复工作和反馈（产出→检查→失败信号→有界重试）
·Graph工程：让控制流显式化（节点、分支、合并、并行、合法循环、状态转换、退出路径）

01 第一层：Harness Engineering（Harness工程）

Harness工程构建模型周围的操作环境。工具、记忆、文件、权限、沙箱、路由、检查点、追踪和人工审批——所有这些都在这里。

当任务持续时间超过一个上下文窗口时，harness工作变得至关重要。一个工作数小时的编码agent不能仅依赖聊天历史。它需要持久的产物，让另一个会话能够理解。

一个实用的harness配置可能包括：

·初始化器：检查工作空间
·进度文件：解释已完成和待完成的事项
·Git提交：保留工作状态
·检查点：在风险操作之前保存
·验证工具：产出清晰的证据

这不是一个更好的prompt，而是一个更好的工作环境。

何时需要harness工程？

· Agent无法访问正确的功能
· Agent在会话之间丢失进度
· 权限过于宽泛
· Agent在不同环境中表现不同
· 无法暂停、检查或恢复运行
· 产出的失败无人能重建

02 第二层：Loop Engineering（循环工程）

每个使用工具的agent都已经有一个小的内部循环：model → action → observation → model。Loop工程始于你有意识地设计围绕这一行为的循环。

目标不是让agent永远重复自己，而是将一次性尝试转化为一个可管理的过程。

验证循环：最有用的外循环

最简单的验证循环是这样的：

BUILD（构建） ↓ CHECK AGAINST EVIDENCE（对照证据检查） ↓ PASS? ── yes ──> STOP（通过？是 → 停止） │ no ↓ RETURN SPECIFIC FEEDBACK（返回具体反馈） ↓ RETRY WITH A LIMIT（有限重试）

检查可以是确定性的（测试通过、schema验证、链接解析、数字核对、文件编译），也可以需要评审员（论证是否完整、语气是否匹配受众、证据是否支持结论、变更范围是否正确）。

循环的七个组成部分

1.触发器：启动下一次循环的条件
2.目标：一个可测量的状态，而非"持续改进"
3.状态：下一次尝试必须知道的信息，无需重放整个历史
4.行动策略：Agent可以更改、调用、委托或花费什么
5.证据：测试、引用、diff、指标、schema或人工评审
6.反馈：什么失败了、必须改变什么的简洁解释
7.停止规则：成功、最大尝试次数、预算耗尽、超时、硬错误或人工升级

循环可以堆叠

EVENT LOOP（事件循环） └── VERIFICATION LOOP（验证循环） └── AGENT LOOP（Agent循环） TRACE IMPROVEMENT LOOP（追踪改进循环） └── 更新 prompts、工具、策略和评分器

这就是为什么loop工程大于prompt工程。Prompt定义一次模型调用期间应该发生什么。Loop定义那次调用之后系统做什么。每次重试、评分器和评审员都会增加延迟和开销——当失败的预期成本高于验证的成本时，添加一个循环。

03 第三层：Graph Engineering（图工程）

Graph工程问的是不同的问题。不是"agent应该如何工作"，而是"接下来允许运行什么"。工作变成节点，允许的转换变成边，状态在图中流动。

这种结构可以表示：固定序列、条件分支、并行展开、合并、有界循环、恢复路径、人工中断。

图工程师实际决定什么

·节点边界：哪些工作属于普通代码、LLM调用、专业agent还是人工评审步骤
·状态schema：每个节点可以读取或更新什么，以及并行结果如何合并
·路由条件：哪些证据推动工作向前、向后、向侧面或进入升级
·并发控制：哪些路径可以并行，共享什么状态
·审批和恢复：加入点、审批点和恢复路线在哪里
·合法循环：哪些循环是合法的，它们如何终止

04 三者如何在一个真实系统中协同工作

想象一个研究-发布agent，它产出一份事实性的行业简报。

Harness提供：

· 浏览器和搜索工具
· 源存储
· 写作工作空间
· 引用检查
· 权限和审批规则
· 检查点和追踪

Graph控制路线：

RESEARCH（研究） ↓ DRAFT（起草） ↓ FACT CHECK（事实检查）── fail ──> RESEARCH │ pass ↓ EDITORIAL REVIEW（编辑评审）── fail ──> DRAFT │ pass ↓ HUMAN APPROVAL（人工审批） ↓ PUBLISH（发布）

Loop存在于路线内部：

· 研究节点可以持续搜索直到源覆盖足够
· 起草节点可以反复修改直到风格评分器通过
· 事实检查节点可以返回精确的不支持声明，而非模糊的拒绝

嵌套是重要的部分。Graph运行在harness内部，loop运行在graph的某些部分内部，harness提供那些loop需要的工具、状态和证据。层级重叠，因为真实软件层级重叠。但当系统失败时，它们给你三个不同的杠杆。

05 诊断失败：症状 → 起点 → 可能的修复

06 常见反模式：别再犯这些错

1. 把harness变成仓库。更多工具不会自动创造更好的agent。拥挤的工具集增加选择错误，嘈杂的上下文增加困惑，宽泛的权限增加风险。给agent最小但能完成工作的环境。

2. 把编排失败归咎于模型。一个更强的模型无法可靠修复陈旧的状态、损坏的API、模糊的工具schema或缺失的退出条件。在证明模型是问题之前，不要升级模型。

3. Loop没有新鲜证据。每次循环都需要新鲜证据、最大尝试次数和一条明确的升级路径。

4. Graph隐藏复杂性。当分支、并行和审批隐藏在临时代码中时，一个强大的loop也会变得难以操作。

07 生产就绪检查清单

Harness

· 工具是否 narrow、有文档且可观察？
· 状态是否在会话间持久？
· 权限是否最小权限？
· 操作员能否暂停、检查和恢复运行？
· 每个重要动作能否从追踪中重建？

Loop

· 什么证据能证明成功？
· 失败后返回什么反馈？
· 允许多少次重试？
· 预算耗尽时发生什么？
· 哪里需要人工判断？

Graph

· 哪些路径必须是确定性的？
· 哪里可以并行运行？
· 共享什么状态？
· 合并、审批和恢复路线在哪里？
· 哪些循环是合法的，它们如何终止？

评估与运维

· 团队能否重放真实追踪？
· 版本能否在相同任务上比较？
· 改进能否归因于特定变更？
· 成本和延迟是否被监控？
· 失败率是否按节点和工具可见？
· 人工干预是否被衡量？
· 任务级成功是否在生产中被衡量？

结语

记住三者区别的最简单方式：

ENVIRONMENT → HARNESS（环境）
FEEDBACK → LOOP（反馈）
FLOW → GRAPH（流程）

Harness工程让模型可操作。Loop工程让工作可迭代和可验证。Graph工程让复杂执行显式和可控。没有谁可以取代其他。

一个完美的graph无法拯救丢失状态的agent。一个完美的harness在没有证据或停止规则的loop中仍然会浪费钱。一个强大的loop当分支、并行和审批隐藏在临时代码中时，会变得难以操作。可靠的agent出现在三层被一起设计时——当每一层都有一个明确的职责时。

这就是整个框架。