一文读懂 Agent 的三层工程：Harness、Loop 与 Graph
文/Lunar
智能体系统中，有三个概念总被混在一起：
智能体运行环境工程（Agent Harness Engineering）
循环工程（Loop Engineering）
图工程（Graph Engineering）
它们都围绕同一个模型展开。
它们都会影响可靠性。
没错，它们也都可以包含循环。
但它们解决的是不同的问题。
一旦混淆，就会在错误的层次上排查问题。
30 秒说明白
可以把它们清晰地理解为：
运行环境工程：构建模型周围的运行环境
循环工程：设计反复执行工作与接收反馈的循环
图工程：把工作流的拓扑结构明确表达出来
一个好记的心智模型是：
环境 → 反馈 → 流程
运行环境为模型提供工具、记忆、控制能力和工作空间
循环决定工作如何重试、检查和改进
图定义下一步允许发生什么
差别就在这里。
为什么这些术语现在很重要
一个裸模型无法独立完成真实工作。
它无法：
跨会话维护项目状态
安全调用工具
检查浏览器
强制执行权限控制
重试失败的工作
验证输出质量
在不同专家之间路由任务
在正确时机停止
这些能力都来自模型周围的系统。
随着智能体软件走向成熟，一种实用的技术栈正在形成：
运行环境为模型提供运行条件
循环让工作可重复、可验证
图让复杂工作流明确且可控
一旦把它们视为彼此独立的层次，许多 AI 架构上的困惑就会消失。
一个专业安全的运行环境通常包含什么
1. 上下文注入
模型在采取行动之前能看到什么：
指令
检索到的知识
对话状态
记忆
策略
与任务相关的规则
2. 操作入口
模型可以做什么：
API 调用
浏览器操作
Shell 命令
代码执行
MCP 工具
数据库操作
自定义函数
3. 持久化
什么能够跨时间保存：
文件
检查点
会话状态
进度日志
Git 历史
长期记忆
4. 运行控制
一次运行如何被管理：
重试
超时
预算
模型选择
创建子智能体
审批关口
5. 安全与治理
什么让系统保持安全：
最小权限
隔离
允许名单
密钥处理
人工审批
6. 可观测性
什么让你能够调试系统：
追踪记录
工具输入与输出
状态转换
延迟
成本
评测结果
为什么运行环境工程如此重要
两个团队可能使用同一个模型，却得到完全不同的结果。
为什么？
因为其中一个团队为模型提供了：
清晰的工具
稳定的状态
结构化记忆
明确的权限
可观测的执行过程
而另一个团队提供的却是：
含糊的提示词
混乱的工具
嘈杂的上下文
没有记忆
没有验证
模型可能相同。
运行条件并不相同。
只要智能体存在以下问题，运行环境工程就至关重要：
无法访问正确的能力
在不同会话之间丢失上下文
在不同环境中行为不一致
无法审计
权限过大
中断后无法平稳恢复
如果模型无法可靠运行，首先应该检查运行环境。
2. 循环工程
它是什么
每个会调用工具的智能体，其实都内置了一个很小的循环：
调用模型
观察结果
运行工具
将观察结果反馈给模型
重复直到完成
当你开始有意地围绕这一行为设计额外循环时，循环工程就开始了。
它不只是“再问一次”。
也不只是“重试”。
而是一个真正的工作与反馈系统。
优秀循环的构成
触发器
什么会启动一轮新的循环？
用户请求
测试失败
新文档
定时运行
Webhook
评估器反馈
目标
我们试图达到的具体条件是什么？
不是“持续改进”。
而是一个真实、明确的目标。
状态
下一轮循环需要知道什么？
当前草稿
上一次尝试
工具结果
错误
进度状态
行动策略
智能体被允许做什么？
编辑
委托任务
调用工具
消耗词元
写入文件
创建 PR
证据
我们如何知道它是否奏效？
测试
结构验证
引用
差异
指标
审核者批准
反馈
具体是什么失败了？
反馈应当简洁且可执行。
停止规则
它何时结束？
成功
超时
预算耗尽
达到最大重试次数
不可恢复的失败
升级交由人工处理
循环工程最重要的原则
不要围绕信心循环。 要围绕证据循环。
“智能体说它完成了”不是停止条件。
真正的停止条件更像这样：
测试通过
结构验证通过
引用链接可正常解析
审核者已批准
策略检查无异常
这才是循环工程。
为什么循环工程不只是提示词工程
提示词告诉模型在一次调用期间该做什么。
循环定义系统在调用之后该做什么。
这包括：
如何检查结果
如何应对失败
如何持久化进度
如何决定是否继续
如何终止
提示词改善的是一次回答。
循环改善的是整个过程。
这两者面对的是完全不同的工程问题。
3. 图工程
它是什么
图工程让工作流结构显式化。
它回答的是另一个问题：
不只是“智能体应该做什么？”，而是“下一步允许发生什么？”
在图工程中：
步骤是节点
转换是边
分支是明确的
并行工作是明确的
汇合是明确的
重试是明确的
人工中断是明确的
这张图会成为系统的控制地图。
图工程师实际在设计什么
节点边界
哪些工作应属于：
一个确定性函数
一次 LLM 调用
一个专业智能体
一个人工审核步骤
状态结构
每个节点可以读取或写入什么。
路由条件
哪些证据会将任务推向：
前进
后退
横向分流
升级处理
并发
哪些工作可以并行运行，哪些必须等待。
循环与出口
在哪里允许重试，最多允许多少次，以及如何停止。
耐久性
检查点应设置在哪里，工作流中断后又如何恢复。
图在何时值得使用
当一个流程包含下列情况时，图很有价值：
有意义的分支
审批
专家之间的交接
并行工作
恢复路径
带有明确控制点的多步骤工作流
当任务只是下面这样时，图的作用则比较有限：
“给一个智能体几个工具，然后让它去做。”
在这种情况下，一个扎实的运行环境加上几个循环可能已经足够。
图会带来清晰度，但也会增加结构。
过早加入过多结构，可能让系统变得脆弱。
三个层次如何协同工作
假设你正在构建一个研究与发布智能体。
它需要：
明确研究主题的范围
收集来源
筛选引用
撰写报告草稿
通过法务审核
仅在批准后发布
三个层次可这样映射：
运行环境
提供：
浏览器访问能力
搜索工具
文件工作空间
记忆
引用功能
审批能力
追踪记录
模型路由
循环
处理：
当证据不足时重试来源检索
修复引用失败
运行评分器检查
在市场变化时更新工作内容
图
控制路径：
确定范围
研究
筛选
综合
起草
审核
发布
并在发布前设置人工关口。
这就是为什么三个层次不能相互替代。
它们协同工作，但并不是同一种东西。
在选择修复方案前，先诊断失败发生在哪一层
一条实用规则是：
如果智能体无法运行，先修复运行环境
例如：
缺少工具访问权限
状态过期
记忆薄弱
权限配置不当
没有可观测性
如果智能体差一点能完成工作，但表现不可靠，先修复循环
例如：
初稿接近目标但质量偏弱
成功结果不稳定
重试不受控制
没有完成证明
如果流程本身很复杂，先修复图
例如：
专家数量很多
存在审批
有分支逻辑
有并行路径
有结构化交接
常见错误
1. 过早构建图
团队常常在还没观察工作实际如何运行之前，就先画出庞大的工作流。
更好的方法是：
从更简单的运行环境开始
收集追踪记录
找出稳定模式
只将真正值得控制的部分形式化
2. 没有保护措施，就让同一个模型既编写又评分
自我审查可以有帮助，但它也会共享同样的盲点。
更好的选择包括：
尽可能使用确定性检查
使用独立的审核上下文
引入外部评估器
对高影响操作加入人工审批
3. 把“继续尝试”当成循环
这不是循环设计。
这是不受控制的成本泄漏。
每个循环都需要：
可衡量的目标
真实证据
重试上限
升级规则
4. 把运行环境当成杂物抽屉
工具更多，不会自动让智能体更好。
工具过多会导致：
选择错误
上下文嘈杂
可靠性变弱
风险面扩大
好的运行环境不是拥挤的。
而是精确的。
5. 将编排失败归咎于模型
模型无法弥补：
损坏的 API
过期的状态
缺失的退出条件
含糊的工具定义
不可见的失效模式
应该修复拥有该失败责任的那一层。
一份简明的生产检查清单
运行环境
工具是否足够聚焦且有文档？
状态是否可持久保存？
权限是否遵循最小权限原则？
运维人员能否暂停、检查与恢复？
追踪记录是否可见？
循环
什么证据能证明成功？
失败时会返回什么反馈？
允许多少次重试？
停止规则是什么？
预算耗尽时会发生什么？
图
哪些路径必须是确定性的？
什么可以并行运行？
人工关口设置在哪里？
共享哪些状态？
恢复路径从哪里开始？
评测
能否重放真实追踪记录？
能否比较不同版本？
能否将改进归因到真实的变更？
运行情况
是否跟踪成本？
是否跟踪延迟？
是否跟踪失败率？
是否跟踪人工干预率？
是否跟踪生产环境中的任务成功率？
记住三者差别的最简单方法
如果你只记住一件事，就记住下面这三条：
运行环境工程让模型能够工作
循环工程让工作可以迭代并得到验证
图工程让执行路径明确且可控
三者谁都无法取代谁。
一张完美的图救不了薄弱的运行环境。
没有优秀循环的强大运行环境，仍会浪费成本。
而当分支和审批仍隐藏在临时代码里时，即便循环很清晰，也会变得难以管理。
可靠的智能体系统，来自于有意识地设计好这三个层次。
这才是真正的架构技术栈。
真正的关键
人们总把 AI 智能体说得仿佛突破点在模型本身。
在生产环境中，这很少是真正的差异化因素。
真正的差异在于模型周围的系统：
让它能够工作的运行环境
让它能够改进的循环
让它能够受控运行的图
