🧭 先给结论：环境、反馈、流程
Agent 工程里最容易出现的误解，是把所有“让 Agent 更可靠”的代码都叫成一个东西。
有人把工具调用叫 Agent Loop，有人把多步骤流程画成 Graph，也有人把系统提示词和记忆模块叫 Harness。它们确实都围绕同一个模型，都可能包含“循环”，也都会影响最终可靠性，但解决的是不同层级的问题。
可以先记住这组三句话：
Harness Engineering：搭建模型运行的机器； Loop Engineering：设计重复工作与反馈验证的循环； Graph Engineering：把工作流的拓扑结构显式化。
更简洁地说：
Harness 管环境，Loop 管反馈，Graph 管流程。
图：原文用“environment → feedback → flow”概括三层工程关系。
这三个词目前还没有完全统一的行业标准。尤其是 Loop Engineering，它是实践者在 2026 年逐渐使用的新说法；Graph Engineering 也更接近一种实用工程方法，而不是一个边界严格的学术领域。
但这种区分非常有用，因为它能防止“Agent”这个大词掩盖真正的设计问题。
🏗️ Harness Engineering：模型之外的整个工作环境
一个裸的语言模型只能根据输入生成输出。它不会天然拥有以下能力：
创建和修改文件； 维护一个项目的长期状态； 运行测试套件； 查看浏览器页面； 调用企业 API； 遵守审批规则； 重启失败的任务； 在多个会话之间记住进度。
这些能力来自模型所处的环境，也就是 Harness。
在 LangChain 的定义里，Agent 可以理解为“模型 + Harness”，而 Harness 就是模型之外的代码、配置和执行逻辑。OpenAI Agents SDK 也从运行时角度描述了类似的核心：Runner 调用模型、执行工具调用、处理 handoff、携带状态，并且只有在真正达到终止条件时才停止。
Harness 通常包含什么？
一个严肃的 Agent Harness，至少会处理以下六类问题：
1. Context Injection：上下文注入
包括系统指令、检索结果、对话状态、技能、任务策略和权限规则。
2. Action Surfaces：行动接口
包括 API、浏览器、Shell、代码解释器、数据库和兼容 MCP 的工具。
3. Persistence：持久化
包括文件、检查点、会话、进度日志、Git 历史和长期记忆。
4. Execution Control：执行控制
包括超时、重试、预算、模型路由、子 Agent、审批门和并发控制。
5. Safety and Governance：安全与治理
包括权限、隔离、Allowlist、Secret 管理和人工授权。
6. Observability：可观测性
包括 Trace、工具输入输出、状态迁移、成本、延迟和评测结果。
图：Harness 不是一段循环代码，而是围绕模型的完整运行系统。
因此可以做一个很实用的判断：
把模型从架构图里拿掉之后，剩下的工具、数据访问、状态存储、沙箱、中间件、评估器、重试策略和 UI，基本都属于 Harness。
为什么 Harness 比提示词更重要？
两支团队使用同一个基础模型，最后效果可能完全不同。
一支团队给模型准备了干净的工具、稳定的工作区、受限的权限、可观察的状态和清晰的终止条件；另一支团队只给了一个模糊提示词和不稳定的 API 包装层。模型智力相同，但工作环境不同，结果当然也会不同。
这就是 Harness Engineering 的核心价值：它把模型能力转化成可重复运行的系统能力。
🔄 Loop Engineering：让 Agent 不要“一次回答就算完成”
每个会使用工具的 Agent，其实都带着一个小循环：
调用模型； 查看结果； 执行工具； 把观察结果输入模型； 重复，直到返回最终答案。
当工程师开始有意识地设计、叠加和管理这些循环时，就进入了 Loop Engineering。
它的重点不是“多写一个 while 循环”，而是回答几个问题：
下一次循环由什么触发？ 循环的目标状态是什么？ 下一轮需要保留哪些信息？ Agent 可以改变什么、调用什么、花费多少？ 失败后应该提供什么反馈？ 什么条件下必须停止？
一个合格的 Loop 有七个部件
Trigger：触发器
可能是用户请求、定时任务、测试失败、新数据到达或评估器反馈。
Goal：目标
必须是一个具体的可判断状态，而不是“继续改进”这种模糊命令。
State and Memory：状态与记忆
下一轮需要知道什么？哪些内容不必重新播放？哪些中间结果需要持久化？
Action Policy：行动策略
Agent 可以修改什么、调用什么、委派什么任务，以及可以花费多少预算？
Evidence：证据
包括测试、Schema 校验、引用、Diff、指标或人工审核。
Feedback：反馈
反馈不能只是“失败了”，而要告诉 Agent 为什么失败、下一步可能修正什么。
Stopping Rule：停止规则
成功、预算耗尽、超时、不可恢复错误或需要人工升级，都应该是明确的终止条件。
不要围绕“自信”循环，要围绕“证据”循环
这是原文最值得记住的一句话：
不要让 Agent 围绕自信程度循环，要让它围绕证据循环。
“Agent 说自己完成了”不是停止条件。
更可靠的停止条件应该是：
测试通过； 链接可以访问； Schema 校验通过； 代码 Diff 符合预期； 指标达到阈值； 审核者确认交付。
图：一个典型的验证循环，会把模型产物交给外部检查器，而不是只听模型自己宣布成功。
验证循环、事件循环和改进循环
验证循环
Agent 创建一个产物，运行确定性检查或评估器，获得明确反馈；只有在证据失败时才继续修改。
事件驱动循环
当定时任务、Webhook 或新文档到达时唤醒 Agent。
改进循环
分析 Trace 和失败原因，修改指令或工具，再测试新版本是否确实更好。
这些循环的代价也必须计算：每多一个评估器、审查者或重试，就可能增加一次模型调用或工具执行。好的工程不是循环越多越好，而是在失败代价高于验证代价的地方增加循环。
🕸️ Graph Engineering：把“下一步能运行什么”画清楚
Loop 主要关心重复执行和反馈；Graph 关心的是工作流拓扑：当前节点完成后，哪个组件被允许运行？
在 Graph Engineering 中：
节点代表步骤或组件； 边代表允许的下一步； 分支代表条件判断； 汇合代表多路任务重新合并； 状态迁移代表流程如何前进； 受控循环代表哪些路径可以返回之前的节点。
这让流程从一段隐含在代码里的控制逻辑，变成可以检查、测试和审计的显式图结构。
图：Harness 提供能力，Graph 路由工作，Loop 负责在条件不足时重新执行。
一个研究报告 Agent 的例子
假设我们要构建一个研究报告 Agent，它可能包含这样的 Graph：
任务拆解
↓
并行检索多个来源
↓
来源质量筛选
↓
证据聚合
↓
草稿生成
↓
事实核查
↓
人工审核
↓
发布或退回修改
这里有三种不同的工程问题：
浏览器、搜索工具、文档系统和权限属于 Harness； 当来源不足或事实核查失败时重新检索，属于 Loop； 并行检索、质量筛选、聚合和审核的先后关系，属于 Graph。
如果把这些都塞进一个大提示词，模型也许能在演示中完成任务，但流程很难审计；如果把所有问题都写成一个无限重试循环，又可能造成费用失控、状态污染和无法终止。
🧩 三层架构的区别，用一张表看懂
图：原文对三种方法的关注点、构建模块和主要风险进行对比。
这张表也说明，三种工程方法不是互相替代关系，而是可以叠加：
Graph：决定流程怎么走
↓
Loop：决定失败后怎么反馈和重试
↓
Harness：提供工具、状态、权限和执行环境
实际系统里，它们通常是嵌套的。一个 Graph 节点内部可能运行一个 Loop；整个 Graph 又必须运行在 Harness 提供的环境中。
🧪 什么时候该用哪一种？
当 Agent 缺能力：先做 Harness
适合使用 Harness Engineering 的情况包括：
Agent 无法访问必要工具； 无法回到上一次的进度； 无法安全读取或写入文件； 任务执行结果无法审计； 不同环境下行为不一致； 需要模型路由、权限管理、沙箱或人工审批。
如果问题是“Agent 根本没有能力完成任务”，增加重试循环通常无效，应该先补齐运行环境。
当 Agent 会做但经常失败：增加 Loop
适合使用 Loop Engineering 的情况包括：
代码需要运行测试； 文档需要检查链接和引用； 数据需要经过 Schema 校验； 结果需要评估器打分； 任务会因为外部状态变化而重新触发； 模型第一版结果经常需要修订。
这里的重点是给 Agent 提供可操作的反馈，而不是让它凭感觉继续思考。
当流程变复杂：使用 Graph
适合使用 Graph Engineering 的情况包括：
有多个明确阶段； 需要并行执行和最后汇合； 不同条件进入不同分支； 某些节点必须人工审批； 任务可能回退到特定节点，而不是从头再来； 不同团队需要共同维护流程。
如果流程只有两个简单步骤，硬画成复杂 Graph 反而会增加维护负担。
🧱 Harness 的具体边界：它不是“一个系统提示词”
很多 Agent 项目把系统提示词写得很长，就认为自己已经完成了 Harness。其实 Harness 的边界远大于 Prompt。
一个更完整的 Harness 还应该管理：
上下文压缩； 多会话状态； 文件系统和 Git 历史； 子 Agent 派生； 模型切换； 预算和限流； 工具输入输出日志； Secret 访问； 权限和人工确认； 任务恢复和重新投递。
例如，长时间、多会话的代码任务不能只依赖上下文压缩。更好的工作系统会创建初始化器、进度文件和 Git 历史，并要求每一轮增量完成工作。这样，即使进入新的上下文，Agent 仍然能知道已经完成了什么、还有什么没有完成。
这不是更好的 Prompt，而是更好的工作环境。
图：模型嵌入在更大的上下文、控制、行动、持久化和验证系统中。
🧠 从模型崇拜转向系统工程
这三个概念背后，其实是同一个趋势：Agent 的竞争越来越不只是基础模型竞争。
同一个模型，可以被放进完全不同的系统：
一个系统给它完整工具和受限权限； 一个系统给它可靠状态和清晰反馈； 一个系统把流程拆成可审计的图； 另一个系统只给它一个聊天框。
最终效果自然不同。
这并不是说基础模型不重要。模型决定了系统的能力上限，但 Harness、Loop 和 Graph 决定了有多少模型能力能够稳定兑现。
可以把最终效果粗略理解为：
Agent 可靠性
≈ 模型能力 × 环境质量 × 反馈质量 × 流程清晰度
这个公式不是严格的数学定律，但它提醒我们：任何一个乘数接近零，系统都会失效。
⚠️ 最常见的四种误区
误区一：把更长的 Prompt 当作 Harness
Prompt 只能描述规则，不能替代文件系统、权限、工具、持久化和可观测性。
误区二：把无限重试当作 Loop Engineering
没有目标、证据、预算和停止规则的循环，只是故障放大器。
误区三：所有流程都画成 Graph
简单任务不需要复杂编排。Graph 的价值来自显式控制，而不是图本身的复杂程度。
误区四：让 Agent 自己判断“我完成了”
模型的自我评价不能替代外部证据。测试、校验、引用、Diff 和人工审核才是可靠的完成条件。
🛠️ 一个实用的落地顺序
如果团队准备把一个 Demo Agent 变成生产系统，可以按以下顺序推进：
第一步：先补 Harness
确认模型能访问什么工具、读写哪些数据、使用哪些权限、如何保存状态，以及失败后如何恢复。
第二步：再补 Evidence
为任务定义可验证的完成标准，例如测试通过、JSON 合法、引用可访问、指标达到阈值。
第三步：围绕证据设计 Loop
只有在证据失败时继续循环，并把失败原因压缩成下一轮可执行的反馈。
第四步：把复杂流程显式化为 Graph
当任务出现分支、并行、汇合、人工审批或回退时，使用节点和边表达流程。
第五步：最后做成本与延迟优化
减少无效重试，设置预算和超时，按任务选择模型，必要时把确定性步骤从模型中移到普通代码里。
🏁 结语：可靠 Agent 的核心不是“更会说”，而是“更能完成”
Harness、Loop 和 Graph 三个概念，实际上是在回答三个不同问题：
模型有什么能力可以使用？——这是 Harness； 结果不好时如何继续变好？——这是 Loop； 整个工作流下一步怎么走？——这是 Graph。
把三者混在一起，系统会显得“很 Agent”，但很难解释、测试和维护；把三者分开，工程团队就能更准确地定位问题：
是环境缺能力？ 是反馈不充分？ 是流程没有显式定义？ 是停止条件不清楚？ 还是权限和状态管理出了问题？
最终，一套生产级 Agent 架构大致可以这样理解：
Harness 提供环境，Loop 提供反馈，Graph 提供方向。
模型仍然是核心发动机，但真正决定它能否在文件、API、客户和生产代码上可靠工作的，是发动机周围那套被认真设计过的工程系统。
