一份实用指南：解释人们经常混为一谈的三层架构

Agent Harness 工程、Loop 工程与 Graph 工程

这种混淆并不奇怪。三种工程方法都围绕同一个模型展开，都会影响系统可靠性，而且三者内部都可能包含“循环”。但它们并不是同义词，而是在描述不同的工程决策。一旦 Agent 不再停留在演示用的 Notebook 里，而是开始操作文件、调用 API、服务客户或修改生产代码，这些区别就会变得非常重要。

30 秒讲清楚

• • Agent Harness 工程：构建模型周围的运行基础设施。
• • 循环工程（Loop Engineering）：设计反复执行、获取反馈和继续改进的工作周期。
• • 图工程（Graph Engineering）：把工作流拓扑显式表示出来，包括节点、分支、汇合、状态转换和受控循环。

最简洁的理解方式是：环境 → 反馈 → 流程。

为什么这些概念突然变得重要

单独一个裸语言模型无法创建文件、维护项目状态、运行测试套件、查看浏览器、执行审批规则，也无法重新启动失败的任务。这些能力都来自模型所处的运行环境。随着 Agent 软件逐渐成熟，一套相对标准的工程栈正在形成：底层是负责真正运行模型的 Agent Harness；其上是负责重复执行和质量检查的 Loop；最后是用来刻画完整执行路径的 Graph。

译注：原文此处写的是 “cannot create text”。语言模型显然能够生成文本，结合后文的 filesystems、workspace 和生产任务语境，原作者应当是想表达 “cannot create files”。译文按上下文校正为“无法创建文件”。

这些术语目前仍没有完全统一的标准定义。在当下的讨论框架中，Agent Harness 正逐渐形成相对明确的含义；Loop Engineering 是 2026 年开始在从业者中流行起来的新说法；Graph Engineering 则不必被理解成一个独立的学术领域，它在这里指的是：把 Agent 工作流实现为显式的有向图或状态机。

这种区分的价值在于，它可以阻止流行词掩盖真正的设计问题。

三种工程层的对照

---

Agent Harness 工程

LangChain 对 Agent 的描述是：Agent = 模型 + Harness。其中 Harness 指模型之外的代码、配置和执行逻辑。实际系统通常包括：

• • System Prompt
• • Tool Definitions
• • Memory
• • Filesystem
• • Sandbox
• • Model Routing
• • Handoff
• • Middleware Hooks
• • Context Compaction
• • Permissions
• • Logging
• • Verification Interfaces

OpenAI Agents SDK 从运行时角度描述了同一个核心过程：Runner 调用模型、执行 Tool Call、处理 Handoff、携带 State，并且只在本次运行到达真正的终止条件时停止。

Agent Harness 的组成

“Harness”这个词很有用，因为它迫使工程团队把注意力从模型崇拜转移到工作系统本身。两支团队即使使用完全相同的基础模型，也可能得到截然不同的结果：一支团队给模型提供清晰的工具、稳定的 Workspace、受约束的权限和可观察的状态；另一支团队只提供一个含糊的 Prompt，再套上一层不可靠的 API Wrapper。模型的智能水平也许差不多，但工作条件完全不同。

一套严肃的 Harness 通常包含：

• • 上下文注入（Context Injection）：指令、检索到的事实、对话状态、Skills 和任务专用策略。
• • 行动界面（Action Surfaces）：API、Browser、Shell、Code Interpreter、Database 和兼容 MCP 的工具。
• • 持久化（Persistence）：文件、Checkpoint、Session、Progress Log、Git History 和 Long-term Memory。
• • 执行控制（Execution Control）：Timeout、Retry、Budget、Model Routing、Subagent 创建和 Approval Gate。
• • 安全与治理（Safety and Governance）：权限、隔离、Allowlist、Secret Handling 和人工授权。
• • 可观测性（Observability）：Trace、工具输入与输出、状态转换、成本、延迟和评测结果。

模型外部的 Harness

模型处在一个更大的 Harness 之中。这个 Harness 负责上下文、控制、行动、持久化和验证。

可以用一个简单方法识别 Harness：从架构图中拿掉模型，剩下的大多数部分都属于 Harness，例如工具、数据访问、状态存储、Sandbox、Middleware、Evaluator、Retry Policy 和 UI。

Harness 工程在什么地方最有价值

Harness 工程对长时间运行的任务尤其重要。在多 Session 编码任务中，Anthropic 发现，仅仅依赖 Context Compaction 并不够。真正有效的方案并不是换一个“更好的 Prompt”，而是搭建一套更好的工作系统：

• • 创建初始化程序；
• • 维护 Progress File；
• • 保留 Git History；
• • 坚持增量工作；
• • 让每个新 Context 都能理解此前发生了什么、还有哪些工作没有完成。

当 Agent 缺少某项能力、无法干净地恢复任务、频繁丢失状态、访问范围过大、无法审计，或者在不同环境中表现不一致时，应优先改进 Harness。

---

循环工程（Loop Engineering）

每个能够调用工具的 Agent，内部都包含一个小型循环：

1. 1. 调用模型；
2. 2. 查看模型输出；
3. 3. 执行工具；
4. 4. 把 Observation 重新输入模型；
5. 5. 重复上述过程，直到模型返回最终答案。

当工程师有意识地在这个基础循环外继续设计或叠加新的周期时，就进入了循环工程。

例如：

• • 验证循环（Verification Loop）：Agent 生成产物，系统运行确定性检查或 Grader，把明确的失败证据反馈给 Agent；只有存在证据性错误时才重试。
• • 事件驱动循环（Event-driven Loop）：当 Schedule、Webhook 或新文档到达时唤醒 Agent。
• • 改进循环（Improvement Loop）：分析 Trace 和失败案例，修改指令或工具，再测试新版本是否真的变得更好。

LangChain 在 2026 年的表述是：这是一组相互叠加的循环，而不是一个神奇的 while 语句。

一个设计良好的循环包含什么

• • Trigger：什么事件触发下一轮，例如用户请求、定时任务、失败的测试、新数据或 Evaluator Feedback。
• • Goal：一个可以判断是否已经到达的具体状态，而不是模糊的“继续改进”。
• • State and Memory：下一轮真正需要知道的内容，而不是把所有历史重新播放一遍。
• • Action Policy：Agent 可以修改什么、调用什么、委派什么，以及可以消耗多少资源。
• • Evidence：测试、Schema Validation、Citation、Diff、Metric 或 Human Review。
• • Feedback：对证据为何不通过所做的简洁、可执行说明。
• • Stopping Rule：成功、预算上限、Timeout、不可恢复错误或升级给人工处理。

文档编写验证循环

验证循环是在 Agent Loop 外再包一层外部 Grader，并设置明确的通过条件。

不要根据“信心”循环，要根据“证据”循环。

“Agent 说自己做完了”不是终止条件。真正的终止条件应该是：“测试通过、链接可以访问、Schema 验证成功，并且 Reviewer 已批准。”

为什么循环工程不只是 Prompt Engineering

Prompt 规定模型在一次调用中应该做什么；Loop 规定系统在调用结束之后应该做什么：

系统如何观察结果、选择反馈、判断是否继续、持久化进度并最终终止。

Prompt 质量依然重要，但循环把一次性的指令变成了一个受管理的过程。它的主要代价是成本和延迟：每增加一个 Grader、Reviewer 或 Retry，就会增加一次模型调用或工具执行。

Anthropic 给出的总体建议是：优先选择能够完成任务的最简单架构，只有当性能提升足以抵消复杂性时，才增加 Agentic Complexity。循环同样遵循这条原则：只有当失败成本高于验证成本时，才值得增加循环。

---

图工程（Graph Engineering）

图工程提出的是另一个问题：不仅要知道 Agent 做什么，还要明确下一步允许哪个组件运行。

在 Graph 中：

• • 工作步骤表示为 Node；
• • 允许发生的状态转移表示为 Edge；
• • Edge 可以表达顺序执行、条件分支、并行 Fan-out、Join、Loop 和 Human Interrupt；
• • State 在图中流动；
• • 拓扑结构使预期控制流能够被检查和约束。

LangGraph 是面向长时间运行、有状态 Agent 的底层编排基础设施，提供 Durable Execution、State 和 Human-in-the-loop Control。它强调的是对 Agent 执行过程的控制，而不是把工作流隐藏在高层抽象后面。

Microsoft AutoGen 的文档给出了非常直接的判断标准：当你需要精确控制 Agent 的执行顺序、针对不同结果选择不同的下一步、实现确定性分支，或处理包含循环的复杂多步流程时，就应该使用 Graph。

图工程实际要决定的是：

• • Node Boundaries：哪些工作由确定性函数、LLM Call、Specialist Agent 或 Human Review 完成。
• • State Schema：每个 Node 可以读取或更新哪些字段，并行更新如何合并。
• • Routing Conditions：哪些证据会让任务向前、向后、横向流转，或者升级处理。
• • Concurrency：哪些步骤可以并行，哪些步骤必须 Join，共享资源如何协调。
• • Cycles and Exits：哪些位置允许重试、最多重试多少次，以及如何保证循环安全。
• • Durability：在哪些位置保存 Checkpoint，中断后如何恢复执行。

AutoGen Studio 中的图式工作流

上图中的 Canvas 把 Agent、Skill 以及它们之间的关系组织成一个可检查的组合系统。这里的 Graph Engineering 指的是基于图的执行工程，不要把它和知识图谱工程混为一谈：

• • 知识图谱中的图表示数据实体及其关系；
• • 工作流图中的图表示控制流和状态转换。

什么时候值得引入 Graph

当流程包含有意义的分支、并行工作、审批、恢复路径或多个 Specialist Agent 时，Graph 很有价值。

如果任务只是“给一个 Agent 三个工具，然后让它自己工作”，Graph 往往没有必要。Graph 可以改善调试，但也可能过早冻结团队的假设。如果模型需要动态制定计划，却强行把所有可能路径预先画进图里，系统反而会变得更脆弱。

三层架构如何在真实系统中协同工作

假设有一个研究与发布 Agent，负责生成一份事实准确的行业简报：

研究与发布 Agent 中的 Harness、Graph 与 Loops

这里存在明显的嵌套关系：

1. 1. Graph 运行在 Harness 之中；
2. 2. Graph 的一个或多个节点内部包含 Loop；
3. 3. Harness 为这些 Loop 提供 State、Tools 和 Evaluator。

这些类别会发生重叠，因为软件层本来就会重叠。但当系统出错时，三层架构分别为团队提供了不同的改进抓手。

根据故障选择要改进的工程层

症状	优先检查	可能的修复方式
Agent 无法安全访问正确的数据或工具	Harness	改进 Tool Contract、权限、Sandbox 和 Context Injection
Agent 在不同 Session 之间忘记进度	Harness	Durable State、Checkpoint、进度产物和 Compaction
第一次结果通常接近正确，但不够可靠	Loop	外部 Grader、确定性测试、Feedback 和 Bounded Retry
Agent 在成功后仍继续工作，或尚未证明成功就提前停止	Loop	基于 Evidence 的 Terminal State 和考虑预算的 Stop Rule
多个 Specialist 必须按受控顺序运行	Graph	显式 Node、Edge、Routing Condition 和 Join
多步流程中的失败位置难以确定	Graph + Harness	让 Stateful Trace 与 Graph Node、State Transition 对齐
工作流变化太频繁，不适合固定图	更简单的 Harness	继续由模型主导控制，推迟 Graph 形式化

---

薄弱 Agent 架构背后的高成本错误

1. 还没理解工作，就先构建 Graph

有些团队甚至没有观察过一个能力足够强的 Agent 会怎样解决问题，就先把业务流程拆成几十个 Node。更合理的做法是：先从简单 Harness 中收集真实 Trace，再把其中稳定的执行路径形式化为 Graph。

2. 让同一个模型既写答案又负责评分，却没有任何保护措施

Self-review 有一定帮助，但写作者和评分者容易共享同样的盲点。应该尽可能使用确定性检查，给 Reviewer 提供独立 Context，并对高影响操作强制要求人工批准。

3. 把“继续尝试”当成循环规范

无上限的 Retry Loop 是成本泄漏。每个 Loop 都必须具备：

• • 可度量的目标；
• • 新的 Evidence；
• • 最大尝试次数；
• • 明确的升级路径。

4. 把 Harness 当成什么都往里塞的垃圾场

更多工具和更多 Memory 并不一定更好。工具集越拥挤，选择错误越多；Context 越嘈杂，模型越容易混乱；权限越宽，风险越大。

5. 把编排故障归咎于模型

模型无法稳定弥补过期的 State、含糊的 Tool Schema、损坏的 API 或缺失的 Exit Condition。应该改进真正拥有该故障的工程层。

面向生产环境的设计检查清单

• • Harness：工具是否足够聚焦、文档清楚并可观察？State 是否持久化？权限是否遵循最小权限原则？操作人员能否暂停、检查并恢复一次运行？
• • Loop：什么 Evidence 能证明成功？失败时会返回什么 Feedback？允许重试多少次？预算耗尽后会发生什么？
• • Graph：哪些路径必须是确定性的？哪些工作可以并行？哪些 State 需要共享？人工 Gate 和恢复路径在哪里？
• • Evaluation：团队能否 Replay 真实 Trace、比较不同版本，并把改进归因到某项具体修改，而不是凭直觉判断？
• • Operations：生产环境是否监控成本、延迟、失败率、人工介入率和任务级成功率？

记住三者区别的最简单方法

• • Agent Harness 工程让模型具备实际工作的环境与能力。
• • 循环工程让工作过程能够迭代、验证并恢复。
• • 图工程让复杂执行路径变得显式、可检查、可控制。

三者无法互相替代。

如果 Harness 已经丢失了 State，那么 Graph 画得再漂亮也没有用。反过来，即使拥有最完善的 Harness，如果系统没有 Evidence 和 Stop Rule，也只会持续浪费成本。精心设计的 Loop 如果仍被埋在临时代码里，遇到分支、并行和审批时同样很难维护。

只有把这三层架构放在一起设计，并且明确每一层究竟要解决什么问题，才能构建出可靠的 Agent 系统。

假如你从2026年开始学大模型，按这个步骤走准能稳步进阶。

接下来告诉你一条最快的邪修路线，

3个月即可成为模型大师，薪资直接起飞。

阶段1:大模型基础

阶段2:RAG应用开发工程

阶段3:大模型Agent应用架构

阶段4:大模型微调与私有化部署

配套文档资源+全套AI 大模型 学习资料，朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】👇👇

配套文档资源+全套AI 大模型 学习资料，朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】👇👇