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