这三个概念经常被混为一谈，本文从架构层次出发，说明它们各自解决什么问题。
产生混淆并不奇怪。三者都围绕模型展开，都会影响可靠性，也都可能包含“循环”。但它们并非同义词，描述的是不同的工程决策。当智能体走出演示用的 Notebook，开始操作文件、调用 API、处理客户数据或修改生产代码时，这些区别就会直接影响系统设计。
- Harness Engineering 构建支撑模型工作的运行环境
- Loop Engineering 设计重复执行、验证和反馈的过程
- Graph Engineering 显式定义工作流拓扑，包括节点、分支、汇合、状态转换和受控循环
最简洁的理解方式是：环境 → 反馈 → 流程。
目录
1. 为什么这些术语突然变得重要
单独的语言模型无法自行创建文件、维护项目状态、运行测试套件、操作浏览器、执行审批流程或重启失败的任务。这些能力来自模型所处的运行环境。随着智能体软件逐渐成熟，一套相对稳定的工程栈正在形成。底层是智能体运行框架，也就是负责运行模型的代码；其上是循环，负责重复执行与质量检查；再往上是图，用明确的路径编排整个流程。
这些名称还没有完全统一。目前，“Agent Harness”已经开始形成较明确的定义；“Loop Engineering”则是 2026 年才在从业者中流行起来的说法。这里的 Graph Engineering 也不是一个学术领域，指的是把智能体工作流建模为显式有向图或状态机。区分这三个概念，可以让团队把注意力放回具体的设计问题。
2. Harness Engineering
- 按照 LangChain 的定义，智能体由模型和运行框架组成。运行框架是模型之外的代码、配置与执行逻辑。在实际系统中，它包括系统提示词、工具定义、记忆、文件系统、沙箱、模型路由、任务交接、中间件钩子、上下文压缩、权限、日志和验证接口。
- OpenAI Agents SDK 从运行时角度描述了相同的核心机制：Runner 调用模型、执行工具、处理任务交接并维护状态，直到满足明确的终止条件。
“运行框架”这个词的价值，在于提醒团队不要只关注模型本身。两个团队使用同一个基础模型，结果可能完全不同。一个团队为模型提供清晰的工具、稳定的工作区、受控的权限和可观测的状态；另一个团队只提供模糊的提示词和不可靠的 API 封装。模型能力或许相近，工作条件却截然不同。
一套成熟的运行框架通常包含：
- 上下文注入：指令、检索到的事实、对话状态、技能和针对具体任务的策略
- 操作入口：API、浏览器、Shell、代码解释器、数据库和兼容 MCP 的工具
- 持久化：文件、检查点、会话、进度日志、Git 历史和长期记忆
- 执行控制：超时、重试、预算、模型路由、子智能体调度和审批节点
- 安全与治理：权限、隔离、允许列表、密钥处理和人工授权
- 可观测性：执行轨迹、工具输入与输出、状态转换、成本、延迟和评估结果
模型只是整个运行框架的一部分。运行框架为它提供上下文、执行控制、操作能力、持久化和验证机制。试着从架构图中拿掉模型，剩下的大多属于运行框架：工具、数据访问、状态存储、沙箱、中间件、评估器、重试策略和用户界面。
2.1 Harness Engineering 在哪些场景最有价值
Harness Engineering 对长时间运行的任务尤其重要。Anthropic 在多会话编程实践中发现，只做上下文压缩并不够。他们为智能体建立了一套完整的工作机制，包括初始化程序、进度文件、Git 历史和增量工作规范。每次开始新的会话，智能体都能据此了解已经完成的工作和剩余任务。这类改进针对的是智能体的工作系统，单靠修改提示词无法实现。
当智能体缺少必要能力、任务中断后无法顺利恢复、经常丢失状态、访问权限过大、操作无法审计，或者在不同环境中表现不一致时，应优先检查运行框架。
3. Loop Engineering
每个使用工具的智能体内部都有一个基础循环：
- 调用模型
- 查看结果
- 运行工具
- 把工具返回的结果交给模型
- 重复以上步骤，直到得到最终答案
开发者可以在这个基础循环之外继续增加新的反馈周期。OpenAI 将这类工作称为 Loop Engineering。
例如，在验证循环中，智能体先生成产物，再运行确定性校验或评分器，并根据明确的反馈决定是否重试。只有证据表明结果存在问题时，系统才会进入下一轮。事件驱动循环会在定时任务触发、收到 Webhook 或新文档时唤醒智能体。优化循环则会分析执行轨迹和失败记录，调整指令或工具，再测试新版本是否有所改善。LangChain 在 2026 年将其描述为一组相互叠加的循环，不能归结为一个简单的 while 语句。
3.1 一个设计良好的循环包含什么
- 触发器：什么事件会启动下一轮，例如用户请求、定时任务、测试失败、新数据或评估结果
- 目标：需要达到的明确状态，不能只是“继续改进”这样的模糊指令
- 状态与记忆：下一轮需要保留哪些信息，避免重放全部历史
- 操作策略：智能体可以修改什么、调用什么、将哪些工作委派出去，以及可以消耗多少资源
- 证据：测试、Schema 校验、引用来源、变更差异、指标或人工评审
- 反馈：用简洁、可执行的方式说明校验为何未通过
- 停止规则：成功、预算上限、超时、不可恢复错误或转交人工
验证循环在智能体的基础循环之外增加了外部评分器和明确的通过条件。是否继续循环应由证据决定，模型的置信度不能作为依据。“智能体声称已经完成”不能作为停止条件；“测试通过、链接可以访问、Schema 校验成功且评审已经批准”才是有效证据。
3.2 Loop Engineering 为什么不只是提示词工程
提示词告诉模型在一次调用中要做什么。循环则定义本次调用结束后，系统如何继续：
如何观察结果、选择反馈、判断是否继续、保存进度，以及在何时终止。
提示词质量仍然重要，但循环把一次性指令变成了可管理的过程。代价主要体现在成本和延迟上。每增加一个评分器、评审器或重试步骤，通常就会多一次模型调用或工具执行。
Anthropic 的通用建议是优先采用能够解决问题的最简单架构，只在收益足以覆盖成本时增加智能体系统的复杂度。循环也应遵循同样的原则：当失败成本高于验证成本时，再引入新的验证循环。
4. Graph Engineering
Graph Engineering 关注的是另一个问题：除了决定智能体做什么，还要明确接下来允许哪个组件运行。
工作步骤表示为节点，节点之间允许的执行路径表示为边。边可以表达顺序执行、条件分支、并行扇出、汇合、循环和人工介入。状态沿图流转，系统可以通过拓扑结构约束和检查控制流。
LangGraph 是面向长期运行、有状态智能体的底层编排基础设施，提供持久化执行、状态管理和人工介入能力。它侧重控制智能体的执行过程，并明确保留工作流细节。Microsoft AutoGen 的文档给出了很直接的判断标准：如果需要精确控制智能体的执行顺序、根据不同结果选择后续步骤、按照确定性条件分支，或者管理带循环的复杂多步流程，就应使用图。
Graph Engineering 主要处理以下设计决策：
- 节点边界：哪些工作交给确定性函数、LLM 调用、专用智能体或人工评审
- 状态 Schema：每个节点可以读取或更新哪些字段，以及如何合并并行产生的更新
- 路由条件：哪些证据会让任务继续、退回、转向其他分支或升级处理
- 并发：哪些任务可以并行，哪些必须汇合，共享资源如何协调
- 循环与退出：哪里允许重试、最多重试几次，以及如何保证循环安全
- 持久化：在哪里创建检查点，中断后如何恢复执行
这里的 Graph Engineering 指基于图的执行编排，与知识图谱工程不同。知识图谱表示数据实体及其关系，工作流图表示控制流和状态转换。
4.1 什么时候值得引入图
当流程包含明确的分支、并行任务、审批、恢复路径或多个专用智能体时，图很有价值。如果任务只是“给一个智能体三个工具，让它自己工作”，引入图的收益就比较有限。
图可以改善调试，也可能过早固化假设。如果模型需要动态制定计划，把所有可能路径都强行画进图里，反而会让系统更加脆弱。
4.2 三个层次如何在真实系统中协作
以一个负责调研、撰写并发布行业简报的智能体为例：
这里存在明确的嵌套关系：图在运行框架中执行，图内包含一个或多个循环，运行框架为这些循环提供状态、工具和评估器。三个层次会有交叉，但系统发生故障时，它们对应不同的排查入口和改进手段。
4.3 根据故障选择工程层次
| 症状 |
优先检查 |
可能的修复方式 |
| 智能体无法安全访问所需的数据或工具 |
Harness Engineering |
工具契约、权限、沙箱、上下文注入 |
| 智能体跨会话丢失进度 |
Harness Engineering |
持久化状态、检查点、进度记录、上下文压缩 |
| 第一次尝试通常接近目标，但结果不够可靠 |
Loop Engineering |
外部评分器、确定性测试、反馈和限定次数的重试 |
| 智能体成功后仍继续工作，或在获得充分证据前停止 |
Loop Engineering |
基于证据的终止条件和受预算约束的停止规则 |
| 多个专用智能体必须按受控顺序运行 |
Graph Engineering |
显式节点、边、路由条件和汇合点 |
| 多步流程中的故障难以定位 |
Graph Engineering + Harness Engineering |
记录执行轨迹，并与图节点和状态转换对齐 |
| 工作流变化太快，不适合固化为图 |
简化 Harness |
保留模型驱动的控制方式，推迟图的形式化 |
5. 智能体架构中的常见误区
5.1 尚未理解工作方式就开始画图
一些团队还没观察过能力较强的智能体会如何解决问题，就先把业务流程拆成几十个节点。更稳妥的做法是从简单的运行框架起步，先收集真实的执行轨迹，再把其中稳定的路径固化为图。
5.2 在没有护栏的情况下，让同一个模型既写又评
自我评审有一定作用，但同一个模型在生成和评审时可能存在相同的盲区。能使用确定性校验时应优先使用。用于评审的模型应采用独立上下文，高影响操作还需要人工批准。
5.3 用“继续尝试”定义循环
无上限的重试会持续消耗成本。每个循环都需要可衡量的目标、每轮产生的新证据、最大尝试次数，以及明确的升级处理路径。
5.4 把运行框架当成杂物堆
工具和记忆并非越多越好。工具集过大，会增加选错工具的概率；上下文噪声过多，会干扰模型判断；权限范围过宽，则会放大操作风险。
5.5 把编排故障归咎于模型
模型无法可靠地弥补状态过期、工具 Schema 含糊、API 异常或退出条件缺失等问题。应当定位问题所属的工程层，再有针对性地修复。
5.6 生产环境设计检查清单
- 运行框架：工具的职责是否单一，文档是否完整，调用是否可观测？状态是否持久化？权限是否遵循最小权限原则？运维人员能否暂停、检查和恢复任务？
- 循环：什么证据可以证明成功？失败后返回什么反馈？允许重试几次？预算耗尽后如何处理？
- 图：哪些路径必须采用确定性流程？哪里可以并行？哪些状态需要共享？人工审批点和恢复路径在哪里？
- 评估：团队能否重放真实执行轨迹、比较不同版本，并判断具体变更带来了什么改进？
- 运维：是否在生产环境中监控成本、延迟、失败率、人工干预率和任务级成功率？
6. 最简单的记忆方法
Harness Engineering 为模型提供稳定、可控的工作环境。Loop Engineering 让执行过程能够持续迭代和验证，并在中断后恢复。Graph Engineering 则明确描述复杂的执行路径，使其可检查、可控制。
三者不能互相替代。运行框架一旦丢失状态，再精美的流程图也无法补救。即使运行框架非常完善，如果循环缺少验证证据和停止规则，系统仍会浪费资源。当分支、并行和审批逻辑全部藏在零散代码中时，精心设计的循环也很难维护。
设计可靠的智能体系统，需要同时考虑这三个层次，并明确每个层次各自解决什么问题。
7. 资料与延伸阅读
以下为原文推荐的阅读资料。
发表于 1 小时前
|
查看: 4|
回复: 0
