一份实用指南，解析人们常混淆的三个架构层
这种混淆情有可原。这三个概念都围绕着同一个模型，都影响着可靠性，也都可能包含"循环"。但它们并非同义词。它们描述的是不同的工程决策，而当一个 Agent 离开演示笔记本，开始接触文件、API、客户或生产代码时，这些区别就变得至关重要了。
30 秒速览答案
- 工具集工程构建模型周围的运行机制
- 工作循环设计规划重复的工作与反馈循环
- 执行图设计将工作流拓扑结构显式化：节点、分支、汇合、状态转换及受控循环
清晰的心智模型是：环境 → 反馈 → 流程
为什么这些术语突然变得重要
原始的语言模型无法创建文本、为项目维护状态、运行测试套件、查看浏览器、执行审批规则或重启失败的任务。这些能力来自于它所处的环境。随着代理软件的成熟，一个标准的工程栈正在逐步形成。其基础是代理控制框架（Agent Harness），即实际运行模型的代码。接下来是工作循环（Loops），负责处理重复执行和质量检查。最后，执行图（Graphs）描绘出指导整个流程的结构化路径。
标签尚未完全标准化。在当前框架中，"代理控制框架"（Agent Harness）这个术语正开始获得一个相当具体的定义。而"工作循环设计"（Loop Engineering）则是 2026 年从业者中兴起的一个较新术语。"执行图设计"（Graph Engineering）应被理解为一种实践而非学术领域；它仅仅是创建以显式有向图或状态机形式呈现的 Agent 工作流的过程。这种实践上的区分很有帮助，因为它能防止流行语掩盖真正的设计问题。
代理控制框架工程
- 根据 Langchain 的定义，Agent 是模型加上控制框架，而控制框架是模型之外的代码、配置和执行逻辑。在实践中，这包括系统提示词、工具定义、记忆、文件系统、沙箱、模型路由、任务交接、中间件钩子、上下文压缩、权限管理、日志记录和验证接口。
- OpenAI 的 Agents SDK 从运行时角度描述了相同的操作核心：运行器调用模型、执行工具调用、处理任务交接、携带状态，并且仅在运行达到真正的终止条件时停止。
"控制框架"这个词之所以有用，是因为它将注意力从对模型的崇拜上转移开。两个团队可以使用相同的基座模型，但得到截然不同的结果，因为一个团队给模型提供了干净的工具、稳定的工作空间、受限的权限和可观测的状态，而另一个团队只给了它一个模糊的提示词和一个不可靠的 API 封装。智能水平可能相似，但工作条件却天差地别。一个严谨的控制框架通常包含：
- 上下文注入： 指令、检索到的事实、对话状态、技能和特定任务的策略
- 操作界面： API、浏览器、Shell、代码解释器、数据库和 MCP 兼容工具
- 持久化： 文件、检查点、会话、进度日志、Git 历史记录和长期记忆
- 执行控制： 超时、重试、预算、模型路由、子 Agent 生成和审批关卡
- 安全与治理： 权限、隔离、允许列表、密钥处理和人工授权
- 可观测性： 追踪、工具输入输出、状态转换、成本、延迟和评估结果
模型位于一个更广阔的控制框架之内，该框架包含上下文、控制、行动、持久化和验证。将模型从你的架构图中移除。剩下的所有东西可能都是控制框架的一部分：工具、数据访问、状态存储、沙箱、中间件、评估器、重试策略和用户界面。
控制框架工程的价值所在
在长时间运行的任务中，控制框架的工作至关重要。在多会话编码场景中，Anthropic 发现仅仅使用上下文压缩是不够的。这并非一个更好的提示词本身就能解决的问题，但他们建立了一个良好的设置，创建了初始化器、进度文件、Git 历史记录以及增量工作的纪律，使得每个新的上下文都能理解发生了什么以及还有哪些待办事项。这是针对 Agent 的改进后的工作系统。当 Agent 缺少某项能力、无法干净地恢复、丢失状态、访问权限过大、无法被审计、或在不同的环境中表现不一致时，就应该应用控制框架工程。
工作循环设计
每个使用工具的 Agent 都内嵌了一个小循环：
- 调用模型
- 查看结果
- 运行工具
- 将观察结果输入模型
- 重复直到返回最终答案
当构建者有意识地围绕这种行为构建或堆叠新的循环时，就是工作循环设计的开始，正如 OpenAI 所称。例如，一个验证循环允许 Agent 创建工件，执行确定性检查或评分器，接收明确的反馈，并且仅在存在证据错误时才重复。一个事件驱动循环会在计划、Webhook 或新文档到达时唤醒 Agent。一个改进循环会分析跟踪和失败，修改指令/工具，并测试新版本是否工作得更好。LangChain 在 2026 年的框架将其描述为一组循环的堆叠，而非一个单一的魔法 while 语句。
一个精心设计的工作循环的结构：
- 触发条件： 启动另一个循环的因素；用户请求、计划、测试失败、新数据或评估器反馈
- 目标： 一个需要达到的特定状态，而非一个含糊的"持续改进"指令
- 状态与记忆： 下一个循环需要知道的信息，无需重放所有内容
- 行动策略： Agent 可以修改、调用、委派或花费的内容
- 证据： 测试、模式验证、引用、差异、指标或人工审查
- 反馈： 一个简洁、可操作的描述，说明证据为何失败
- 停止规则： 成功、预算限制、超时、不可恢复的错误或人工升级
一个验证循环用外部的评分器和明确的通过条件来包装 Agent 循环。不要基于置信度来循环。要基于证据来循环。"Agent 说它完成了"不是一个停止条件；"测试通过、链接可解析、模式验证通过、审查者批准"才是。
为什么工作循环设计不仅仅是提示词工程
提示词告诉模型在一次调用中要做什么。而工作循环则规定了系统在调用之后做什么：
系统如何观察结果、选择反馈、决定是否继续、持久化进度以及终止
提示词的质量仍然重要，但工作循环将一次性的指令转化为一个被管理的过程。主要的权衡是成本和延迟。每个评分器、审查者或重试都会增加一次模型调用或工具运行。Anthropic 的更广泛指导是优先选择最简单的可行架构，并且仅当性能提升证明其合理性时，才增加代理的复杂性。同样的建议也适用于工作循环：在失败成本高于验证成本的地方添加它们。
执行图设计
执行图设计提出了一个不同的问题：不仅仅是 Agent 做什么，而是哪个组件被允许下一步运行。步骤由节点表示，允许的步骤由边表示。这些边可用于指示顺序、条件分支、并行扇出、汇合、循环和人工中断。状态遍历整个图，拓扑结构允许检查所需的控制流。LangGraph 是用于长时间运行、有状态 Agent 的底层编排基础设施，具有持久执行、状态与人机协同控制，并明确关注对 Agent 的控制，而不是对工作流的抽象。Microsoft AutoGen 的文档非常直接：当你需要精确控制 Agent 顺序、针对不同结果有不同的下一步、确定性分支或包含循环的复杂多步骤过程时，请使用图。执行图设计者实际要决定的内容：
- 节点边界： 哪些工作属于确定性函数、LLM 调用、专家 Agent 或人工审查步骤
- 状态模式： 每个节点可以读取或更新什么，以及如何合并并行更新
- 路由条件： 哪些证据将工作向前、向后、侧向发送或升级处理
- 并发性： 哪些可以并行运行，哪些必须汇合，以及哪些共享资源需要协调
- 循环与出口： 哪些地方允许重试，允许多少次，以及什么使循环安全
- 持久性： 检查点发生在哪里，以及中断后执行如何恢复
上述画布使得 Agent、技能和关系作为一个组合系统可以被检查。这里的执行图设计意味着设计基于图的执行。这与知识图谱工程不同，后者在数据中表示实体和关系。工作流图表示控制和状态转换。
什么时候值得为图增加复杂度
当流程包含有意义的分支、并行工作、审批、恢复路径或多个专家 Agent 时，图是有价值的。当工作仅仅是"给一个 Agent 三个工具，让它自己干"时，图就没那么有用了。图可以改善调试，但也可能过早地固化假设。如果模型必须动态地制定计划，那么将每个可能的路径都强制放入一个图中可能会使系统变得更脆弱，而不是更健壮。
三个层如何在一个真实系统中协同工作
考虑一个负责生成事实性行业简报的研究和发布 Agent。
注意其嵌套关系：图在控制框架内运行；一个或多个工作循环位于图内部；控制框架提供这些工作循环所需的状态、工具和评估器。这些类别有重叠，因为软件层本身就有重叠，但每个类别仍然为团队提供了一个不同的杠杆，用于在系统失败时进行调整。
通过诊断故障来选择工程层
症状
从何处入手
可能的修复方案
Agent 无法安全地访问正确的数据或工具。
控制框架
工具契约、权限、沙箱、上下文注入。
Agent 在会话之间忘记进度。
控制框架
持久化状态、检查点、进度工件、上下文压缩。
首次尝试通常接近正确但不可靠。
工作循环
外部评分器、确定性测试、反馈和有界重试。
Agent 在成功后继续工作，或在有证据前停止。
工作循环
基于证据的终止状态和预算感知的停止规则。
多个专家 Agent 必须以受控顺序运行。
执行图
显式节点、边、路由条件和汇合。
在多步骤过程中难以定位失败。
执行图 + 控制框架
与图节点和转换对齐的有状态追踪。
工作流变化太频繁，不适合固定图。
简化控制框架
保持控制由模型驱动；推迟图的正式化。
薄弱 Agent 架构背后的昂贵错误
在理解工作内容之前就构建图
团队有时会在观察到一个能干的 Agent 如何实际解决业务问题之前，就将一个业务流程翻译成几十个节点。从更简单控制框架的追踪开始，然后才将稳定的路径正式化。
让同一个模型在缺乏保障措施的情况下既编写又评分
自我审查可能有所帮助，但它容易受到共同盲点的影响。优先使用确定性检查，使用独立的审查者上下文，并要求对高影响行为进行人工审批。
将"继续尝试"用作循环规范
无限制的重试循环是一个成本漏洞。每个循环都需要一个可衡量的目标、新的证据、最大尝试次数和一个明确的升级路径。
将控制框架视为一个"垃圾场"
更多的工具和记忆并不自动意味着更好。拥挤的工具集增加了选择错误，嘈杂的上下文增加了混乱，宽泛的权限增加了风险。
将编排失败归咎于模型
模型无法可靠地补偿陈旧的状态、模糊的工具模式、损坏的 API 或缺失的退出条件。改进拥有该故障的层。
一个生产就绪的设计检查清单
- 控制框架： 工具是否狭窄、文档完善且可观测？状态是否持久化？权限是否遵循最小权限原则？操作员能否暂停、检查和恢复运行？
- 工作循环： 什么证据证明成功？失败时返回什么反馈？允许多少次重试？预算耗尽时会发生什么？
- 执行图： 哪些路径必须是确定性的？哪些工作可以并行运行？哪些状态是共享的？人工审批关卡和恢复路径在哪里？
- 评估： 团队能否重放真实的追踪、比较版本并将改进归因于特定的变更，而非直觉？
- 运维： 是否在生产环境中监控成本、延迟、失败率、干预率和任务级成功率？
记住差异的最简单方法
控制框架工程是让模型能够运行起来的工程。工作循环设计方法论是迭代的、可验证的和可恢复的。执行图设计使复杂的执行路径变得显式化和可控。这三个方面中的任何一个都不能被其他方面所替代。即使控制框架丢失了状态，一个画得再漂亮的图也是不够的。然而，即使拥有最好的控制框架，如果没有证据或停止规则，那也是浪费金钱！当分支、并行和审批嵌入在临时代码中时，精心设计的工作循环仍然难以操作。如果这三个层被联合设计，并且团队清楚每个层应该解决什么问题，那么可靠的 Agent 系统就会应运而生。
读者常用的搜索词
- agent harness vs loop engineering
- graph engineering for AI agents
- AI agent orchestration
- LLM agent architecture
- production AI agents
- LangGraph workflows
- AutoGen GraphFlow
- agent verification loops
来源与延伸阅读
The Anatomy of an Agent Harness - 了解代理控制框架如何将 AI 模型转变为自主工作引擎。探索核心组件：文件系统、沙箱和记忆
LangChain and LangGraph Agent Frameworks Reach v1.0 Milestones - LangChain 1.0 和 LangGraph 1.0 已发布。通过标准化工具、中间件定制和持久化状态，更快地构建生产就绪的 AI Agent
GraphFlow (Workflows) - AutoGen - 在本节中，你将学习如何使用图流（GraphFlow），或简称为"流"，来创建多 Agent 工作流。它使用结构化执行并精确控制 Agent 如何交互以完成任务。我们将首先向你展示如何创建和运行一个流
The Art of Loop Engineering - Agent 自动化了现实世界的工作，但可靠的性能需要的不仅仅是一个好模型，它需要一个为特定任务精心设计的控制框架。这篇文章探讨了核心 Agent 循环，如何堆叠和扩展循环以构建更有效的 Agent，以及如何使用 LangChain 原语来检测每一层
Introducing AutoGen Studio from Microsoft Research - AutoGen Studio 建立在微软灵活的开源 AutoGen 框架之上，用于编排 AI Agent，它提供了一个用户友好的界面，使开发者能够快速构建、测试、定制和共享多 Agent AI 解决方案，几乎无需编写代码
How to Build a Custom Agent Harness - 有效的 Agent 是通过与手头任务紧密耦合的控制框架构建的。构建自定义控制框架最简单的方法是使用 LangChain 的 create_agent 加上中间件。本指南涵盖了核心 Agent 循环以及如何为你 Agent 的用例进行自定义
A practical guide to building agents - 一份关于设计、编排和部署 AI Agent 的综合指南，涵盖用例、模型选择、工具设计、防护栏和多 Agent 模式
Building Effective AI Agents - 来自 Anthropic 及其客户关于构建生产就绪的单 Agent 和多 Agent 系统的实用建议和指导
保存此文，以免丢失
关注 @beamnxw 获取更多技术文章 :)
