这是一份实用指南，讲人们总混在一起的三个架构层。
混淆可以理解。三个概念都围着同一个模型转，都影响可靠性，也都可能包含「循环」。但它们不是同义词，描述的是不同的工程决策。agent 一旦离开演示用的 notebook，开始碰文件、API、客户或生产代码，这个区分就变得要紧。
30 秒版答案
- Harness 工程搭建模型周围的运行设施
- 循环工程设计反复进行的「干活加反馈」周期
- 图工程把工作流的拓扑显式化，包括节点、分支、汇合、状态转移和受控的环
清晰的心智模型就是「环境 → 反馈 → 流程」
这几个词为什么突然重要
裸语言模型能生成文本，但它不能为一个项目维护状态，不能跑测试套件、看浏览器，也不能执行审批规则或重启失败的任务。这些能力来自它所在的环境。随着 agent 软件走向成熟，一套标准的工程栈终于成形。最底层是 agent harness，也就是真正运行模型的那部分代码。往上是循环，负责重复执行和质量检查。最上层是图，规划引导整个过程的结构化路径。
这些标签还没有统一的标准。在当前的框架里，「agent harness」开始有了相当具体的定义；「循环工程」是 2026 年从业者中新出现的说法；图工程应当从实践而非学科的角度理解，它就是把 agent 工作流写成显式有向图或状态机的过程。这种实用的区分有好处，能防止一个流行词把真正的设计问题盖住。
上图把三者并排对照：
| 问题 | Agent harness | 循环工程 | 图工程 |
|---|---|---|---|
| 首要关注 | 运行能力 | 迭代推进与反馈 | 显式的控制流 |
| 核心对象 | 模型外壳／运行时 | 有边界、可重复的周期 | 由步骤组成的有向图 |
| 典型构件 | 工具、记忆、沙箱、中间件、权限、trace | 触发、目标、动作、证据、反馈、停止规则 | 节点、边、共享状态、分支、汇合、中断、环 |
| 修的是哪种故障 | 「模型没法安全地干这活」 | 「agent 停得太早，或反复交差劲的活」 | 「工作流难以推理、难以控制」 |
| 最适合 | 通用 agent 平台或特定任务的运行时 | 能靠验证不断改进的开放式工作 | 决策点已知的复杂多步流程 |
| 主要风险 | 臃肿、不透明的运行时 | 无限重试、烧 token、reward hacking | 过度设计的流程图和脆弱的路径 |
Agent Harness 工程
- 按 LangChain 的说法，agent 等于模型加 harness，harness 是模型之外的代码、配置和执行逻辑。实践中它包括系统提示词、工具定义、记忆、文件系统、沙箱、模型路由、交接（handoff）、中间件钩子、上下文压缩、权限、日志和验证接口。
- OpenAI 的 Agents SDK 从运行时的角度描述了同一个运行核心。runner 调用模型，执行工具调用，处理交接，携带状态，只有运行到达真正的终止条件才停下。
harness 这个词有用，因为它把注意力从模型崇拜上移开了。两个团队可以用同一个基础模型，得到截然不同的结果：一个给模型干净的工具、稳定的工作区、受限的权限和可观测的状态，另一个只给一段含糊的提示词和一个不可靠的 API 封装。两边的智能也许相近，工作条件差得很远。一个认真的 harness 通常包含：
- 上下文注入：指令、检索到的事实、对话状态、技能和特定任务的策略
- 动作面：API、浏览器、shell、代码解释器、数据库和兼容 MCP 的工具
- 持久化：文件、检查点、会话、进度日志、git 历史和长期记忆
- 执行控制：超时、重试、预算、模型路由、派生子 agent 和审批门
- 安全与治理：权限、隔离、白名单、密钥管理和人工授权
- 可观测性：trace、工具的输入输出、状态转移、成本、延迟和评测结果
模型位于一个更大的 harness 之中，四周是上下文、控制、动作、持久化和验证。从你的架构图里把模型拿掉，剩下的大概都属于 harness：工具、数据访问、状态存储、沙箱、中间件、评估器、重试策略和 UI。
harness 工程在哪里见效
harness 工作对长时运行的任务很重要。在跨多个会话的编码任务里，Anthropic 发现光靠上下文压缩不够（Effective harnesses for long-running agents）。他们靠的是一套好的设置，单改提示词做不到：一个初始化器、一份进度文件、git 历史，加上增量推进的纪律，让每个新上下文都能看懂之前发生了什么、还剩什么要做。改进的是 agent 所处的工作系统。下面这些情况适合用 harness 工程：agent 缺某种能力，没法干净地恢复，丢状态，访问范围太大，无法审计，或者在不同环境里表现不一致。
循环工程
每个用工具的 agent 内部都嵌着一个小循环：
- 调用模型
- 查看结果
- 运行工具
- 把观察结果喂回模型
- 重复，直到返回最终答案
构建者有意在这个行为外面搭建或叠加新的周期，就进入了循环工程，这是 OpenAI 的叫法。比如验证循环让 agent 产出一个制品，执行确定性检查或评分器，拿到明确的反馈，只在有证据表明出错时才重来。定时任务、webhook 或新文档到达时，事件驱动的循环会唤醒 agent。改进循环分析 trace 和失败记录，修改指令或工具，再测试新版本是否更好。LangChain 2026 年的表述把这些称为一叠循环（The Art of Loop Engineering），而不是一条神奇的 while 语句。
一个设计良好的循环由这些部分组成：
- 触发：什么开启下一个周期，用户请求、定时、测试失败、新数据或评估器反馈
- 目标：要到达的具体状态，不是一句含糊的「继续改进」
- 状态与记忆：下一个周期需要知道的东西，有了它就不必重放全部历史
- 动作策略：agent 可以改什么、调用什么、委派什么、花多少
- 证据：测试、schema 校验、引用、diff、指标或人工审查
- 反馈：一段简洁、可执行的说明，讲清证据为什么没通过
- 停止规则：成功、预算用尽、超时、不可恢复的错误或升级给人
验证循环在 agent 循环外面包一个外部评分器和一个明确的通过条件。让证据驱动循环，别让信心驱动。停止条件是「测试通过、链接可访问、schema 校验通过、审查者批准」，「agent 说它做完了」不算。
循环工程为什么不只是提示词工程
提示词告诉模型在一次调用里做什么。循环规定系统在调用之后做什么：
怎样观察结果、选择反馈、决定是否继续、保存进度、终止运行
提示词质量依然重要，但循环把一次性的指令变成一个受管理的过程。主要的代价是成本和延迟，每多一个评分器、审查者或一次重试，就多一次模型调用或工具运行。Anthropic 更宏观的建议是，优先用能工作的最简单架构，只在性能收益值得时才增加 agent 式的复杂度（Building Effective AI Agents）。这条建议同样适用于循环：失败的代价高于验证的代价，才在那里加循环。
图工程
图工程问的是另一个问题。除了 agent 做什么，它还关心下一步允许哪个组件运行。步骤用节点表示，允许的流转用边表示。边可以表达顺序、条件分支、并行扇出、汇合、循环和人工中断。状态沿着图流动，拓扑让预期的控制流可以被检查。LangGraph 是面向长时运行、有状态 agent 的底层编排基础设施，提供持久执行、状态和人在回路的控制，明确把重点放在对 agent 的控制上，而不是把工作流抽象掉。Microsoft AutoGen 的文档说得格外直白（GraphFlow）：需要精确控制 agent 的执行顺序，需要不同结果走不同的下一步，需要确定性分支，或者流程复杂、多步且带环时，就用图。图工程师实际要决定的事：
- 节点边界：哪些工作属于确定性函数、LLM 调用、专家 agent 或人工审查步骤
- 状态 schema：每个节点可以读写什么，并行的更新怎么合并
- 路由条件：哪些证据把工作往前送、往回退、转到旁路或升级
- 并发：什么可以并行，什么必须汇合，哪些共享资源需要协调
- 环与出口：哪里允许重试，允许几次，什么让这个环是安全的
- 持久性：检查点设在哪里，中断后怎么恢复执行
上面这张画布（AutoGen Studio）把 agent、技能及其关系做成一个可检查的组合系统。这里说的图工程指基于图的执行工程，和知识图谱工程是两回事，后者的图表示数据里的实体和关系。工作流图表示的是控制和状态转移。
什么时候值得为图多费这番功夫
流程里有实质性的分支、并行工作或审批，需要恢复路径，或者涉及多个专家 agent 时，图很有价值。如果活儿只是「给一个 agent 三个工具让它干」，图的用处就不大。图能改善调试，也可能过早固化假设。如果计划必须由模型动态生成，强行把每条可能的路径画进图里，反而可能让系统更脆弱。
三层在一个真实系统里怎么配合
设想一个研究与发布 agent，负责产出一份基于事实的行业简报。
图中三层的分工是这样的：
- Harness：提供浏览器、搜索工具、文档工作区、引用库、模型路由、密钥、权限、trace 日志和审批界面。
- 图：把任务依次路由经过界定范围 → 并行调研 → 来源筛选 → 综合 → 起草 → 法务审查 → 发布，发布前设一道人工门。
- 循环：覆盖不足时重新检索来源，引用不成立时把草稿退回修改，市场变化时按计划刷新。
注意其中的嵌套关系。图运行在 harness 里面；一个或多个循环位于图里面；harness 提供这些循环需要的状态、工具和评估器。这些类别互相重叠，因为软件的层本来就会重叠，但系统出故障时，每一层都是团队可以单独下手的地方。
按故障诊断来选工程层
| 症状 | 从哪层入手 | 可能的修法 |
|---|---|---|
| agent 无法安全地拿到正确的数据或工具。 | Harness | 工具契约、权限、沙箱、上下文注入。 |
| agent 跨会话忘掉进度。 | Harness | 持久状态、检查点、进度制品、上下文压缩。 |
| 第一次尝试常常差一点就对，但不稳定。 | 循环 | 外部评分器、确定性测试、反馈和有上限的重试。 |
| agent 成功后还在继续，或在拿到证明前就停了。 | 循环 | 基于证据的终止状态和考虑预算的停止规则。 |
| 几个专家 agent 必须按受控的顺序运行。 | 图 | 显式的节点、边、路由条件和汇合。 |
| 多步流程里的故障难以定位。 | 图 + harness | 与图节点和转移对齐的有状态 trace。 |
| 工作流变化太频繁，固定的图跟不上。 | 更简单的 harness | 让控制保持由模型驱动，推迟把图形式化。 |
弱 agent 架构背后代价高昂的错误
还没弄懂工作就先画图
团队有时在观察一个能干的 agent 实际怎么解决问题之前，就把业务流程翻译成几十个节点。应该先从一个更简单的 harness 收集 trace，再把稳定的路径形式化。
让同一个模型既写又评，却没有防护
自我审查可能有帮助，但容易有共同的盲点。能用确定性检查就用，审查者用独立的上下文，高影响的操作要求人工批准。
把「继续试」当成循环规格
没有上限的重试循环是成本漏洞。每个循环都需要可度量的目标和新的证据，要限定最大尝试次数，还要有一条明确的升级路径。
把 harness 当垃圾场
工具和记忆越多，不见得越好。工具集越拥挤，选错工具越多；上下文越嘈杂，越容易混乱；权限越宽，风险越高。
把编排故障怪到模型头上
状态过期，工具 schema 含糊，API 坏了，或者缺了退出条件，这些模型都无法可靠地弥补。该改进的是对这个故障负责的那一层。
一份可用于生产的设计检查清单
- Harness：工具是否职责单一、有文档、可观测？状态是否持久？权限是否最小化？运维人员能否暂停、检查并恢复一次运行？
- 循环：什么证据证明成功？失败时返回什么反馈？允许重试几次？预算用尽时怎么办？
- 图：哪些路径必须是确定性的？哪里可以并行？哪些状态是共享的？人工门和恢复路径在哪里？
- 评测：团队能否重放真实 trace、比较版本，把改进归因到具体的改动而不是直觉？
- 运维：生产环境里是否监控了成本、延迟、失败率、人工干预率和任务级成功率？
记住区别的最简单方式
Harness 工程让模型能运转起来。循环工程让工作可迭代、可验证、可续跑。复杂的执行路径则靠图工程变得显式、可控。三者互不替代。harness 丢了状态，图画得再漂亮也不够用；harness 再好，没有证据和停止规则，也是在白白烧钱；循环设计得再精巧，分支、并行和审批埋在临时拼凑的代码里，照样难以运维。三层一起设计，并且团队清楚每一层要解决什么，可靠的 agent 系统才会出现。