Workflow、Agent、Harness、Loop、Graph，这几个概念是理解现代 AI Agent 系统最重要的一组基础概念。但它们经常被混用，例如：

• Agent 是不是就是 LLM + Memory + Tools？

• Harness 和 Agent 到底有什么区别？

• Agent Loop 与 Graph 是不是两种不同的 Agent 架构？

• LangGraph、OpenAI Agents SDK 究竟是在实现什么？

• 为什么有些 Agent 只用几十行 Python 就能实现，而有些需要复杂的框架？

看了一些视频和博客，印象还是比较模糊。

所以为了理清楚这些问题，我查阅了 Anthropic、OpenAI、LangGraph、Microsoft 和 Google 等官方技术资料。一个比较关键的结论是：

这五个概念并非同一层级的五种技术（尤其是Loop-Graph以及Harness-Loop-Graph的概念容易混淆），而是分别描述了 AI 系统的智能能力、行为主体、执行机制、运行基础设施和流程组织方式。

一、先建立一套统一的概念体系

1.1 五个概念的核心定义

概念	一句话定义	本质上是什么	关注的问题
LLM	提供语言理解、推理和决策能力	智能模型	应该做什么？
Agent	能根据目标和环境反馈自主决定并执行行动的系统	LLM + 决策机制 + 外部交互能力	如何完成任务？
Loop	持续执行“决策—行动—观察”的循环	一种执行控制逻辑	是否继续行动？
Graph	通过节点、边和状态组织任务执行路径	一种流程与状态编排结构	下一步执行哪个模块？
Harness	负责驱动模型、管理上下文、调用工具和保障执行的运行基础设施	Agent Runtime / 执行控制层	如何让 Agent 稳定、安全地运行？

其中有两个容易混淆的地方：

第一，Agent 是完整的能力系统，而 Loop、Graph、Harness 更多描述它如何运行。

第二，Graph 与 Loop 不是互斥关系。 Graph 可以包含 Loop；Harness 可以执行一个简单的 Loop，也可以驱动一个由 Graph 定义的复杂流程。

1.2 从整体上看它们的关系

这是一张概念关系图，并不是要求所有 Agent 必须按这种方式部署。

可以先记住一个工程上很实用的近似表达：

其中：

• Harness 提供工具执行、循环、状态管理等基础机制。

• Task Configuration 决定 Agent 的目标、角色、工具权限和行为边界。

• Graph 可以作为 Harness 内部的编排方式，也可以由独立工作流引擎执行。

这一理解与 Anthropic 对 Agent 的区分、Microsoft 和 Google 对 Harness 的定义一致。

二、Agent：究竟什么才算智能体？

2.1 Agent 不只是给 LLM 加几个工具

之前我常常和其他人这样描述Agent：

这个公式清晰易懂，但实际上并不完整。

假设你给 LLM 提供一个天气查询工具，然后写死下面的程序：

def get_weather_agent():

    weather = get_weather("西安")
    answer = llm(f"根据天气信息回答：{weather}")

虽然同时具有 LLM 和 Tools，但它不一定是严格意义上的自主 Agent。因为：

• 工具调用由程序员预先确定。

• LLM 不能选择是否需要查询。

• LLM 不能根据查询结果动态决定下一步。

• 整个执行路径基本固定。

这更接近 LLM Workflow（大模型工作流）。

现在换一种设计：

while not task_finished:    
    action = llm.decide(context, available_tools)   
 
    if action.type == "tool_call":       
        result = execute(action)        
        context.append(result)   
    else:        
        task_finished = True

模型可以自主决定是否调用工具、调用哪个工具、是否继续执行。

这就更接近 Agent。

Anthropic 特别区分：

• Workflow： 执行路径主要由预先编写的代码控制。

• Agent： 执行路径和工具使用主要由 LLM 根据任务和环境动态决定。

2.2 更准确的 Agent 定义

可以把 LLM Agent 理解为：

一个以目标为导向、基于当前状态与环境反馈选择行动，并通过持续交互推进任务的计算系统。

它通常具备五种能力：

能力	含义	是否必须由 LLM 实现
Perception 感知	获取用户输入和环境反馈	否
State 状态维护	记录任务进度及必要上下文	否
Decision 决策	根据目标选择下一步行动	通常由 LLM 主导
Action 执行	调用工具、生成回复或影响外部环境	否
Feedback 反馈	根据行动结果调整后续行为	否，决策模型可利用反馈

这也与强化学习中的 Agent 概念接近：观察状态、选择动作、得到环境反馈，然后继续决策。当然，LLM Agent 不一定经过强化学习训练。

2.3 Agent 的核心特点

最重要的不是“工具数量”，而是以下三个特征：

1. 目标驱动： 关注如何完成任务，而不只是生成一段文本。

2. 动态决策： 不同的观察结果可能引导不同的执行路径。

3. 闭环反馈： 行动之后能够观察结果并修正后续决策。

因此，可以进一步区分三种系统：

系统	典型行为	自主程度
LLM Chatbot	输入问题，生成回答	低
LLM Workflow	按固定流程调用模型和工具	中低
LLM Agent	动态选择步骤、工具和行动	较高

实际系统往往处于连续谱上，不一定存在绝对清晰的分界线。

三、Loop：Agent 最基本的执行机制

3.1 Loop 的本质是什么？

这就是常见的 Agent Loop，也可以看作一种简化的 Observe–Decide–Act 循环。

OpenAI Agents SDK 当前文档描述的运行流程也是类似的：

调用模型、检查输出、执行工具或进行 Agent handoff，再继续，直到满足停止条件。

3.2 为什么需要 Loop？

举个例子：孩子问一个陪伴机器人：

“帮我找三首适合二年级学习的李白古诗，然后选一首给我讲讲。”

如果只调用一次 LLM，它可能直接凭模型知识生成答案。

但假设你希望使用可信诗词资料，那么需要多个步骤：

• 第一次决策：需要查询诗词数据库。

• 第一次行动：调用 search_poems()。

• 第二次决策：筛选出适合二年级的诗。

• 第二次行动：查询其中一首的详细内容。

• 第三次决策：组织讲解并返回。

不同查询结果会影响后续步骤，因此很难在开始时完全规定每一步。

Loop 使模型能够根据执行结果继续工作。

3.3 Loop 的特点与局限

优点	局限
实现非常简单	复杂任务中控制逻辑容易混乱
执行路径灵活	很难直接观察多分支流程
能自然处理工具反馈	容易反复调用同一工具
适合未知步骤数的任务	需要限制轮数、费用和执行时间

尤其需要注意：

Loop 不意味着无限循环。

生产环境通常必须设置最大迭代次数、工具调用限制、超时和异常处理机制。

例如，对实时语音陪伴机器人，一次普通问答可能只允许最多 3～4 轮工具调用，以控制用户等待时间。

另外要区分两个 Loop：

• Agent Loop： 单次任务内部的多步决策循环。

• Conversation Loop： 用户说一句、机器人回答一句、用户再说一句的跨轮对话过程。

两者可以嵌套，但不是同一个东西。

四、Graph：用显式结构管理复杂执行流程

4.1 Graph 的本质

Graph（图）本身是一种通用的数据结构，由节点和边组成。

在 Agent 系统里，它通常指以图结构组织执行流程的编排方式。

例如，LangGraph 中的三个基础概念是：

组成	作用	例子
State	保存当前共享状态	用户输入、历史、意图、工具结果
Node	执行具体计算	调用 LLM、查询数据库、更新记忆
Edge	决定后续执行路径	查询成功后回答、失败后重试

LangGraph 的官方定义也强调：

节点可以是 LLM，也可以只是普通 Python 函数；边可以是固定连接，也可以根据状态决定下一步。

4.2 一个典型的 Graph 长什么样？

下面是一个儿童陪伴Agent 的简化 Graph：

这张图中，开发人员预先定义了可能执行的节点与分支，但具体走哪个分支，可以由 LLM 或其他逻辑动态决定。

4.3 Graph 和 Loop 到底有什么区别？

这是最值得理解的部分。

Loop 是一种执行控制模式，Graph 是一种工作流表示和编排结构。

它们并不处于同一维度。

对比	Loop	Graph
核心问题	是否继续执行？	下一步走哪里？
基本结构	重复执行	节点 + 边 + 状态
流程组织	通常是单一主循环	支持分支、汇合、循环、并行
状态管理	自己实现或依赖 Runtime	通常显式定义状态结构
适合任务	开放式工具调用	多阶段复杂工作流
控制复杂度	简单任务较低	复杂任务更容易模块化

例如：

Graph:
  Node A → Node B → Node C
             ↑       |
             └───────┘

这里的 Graph 本身就包含一个 Loop。

反过来，你也完全可以不用 Graph，直接在 Python 的 while 循环里面实现所有逻辑。

4.4 Graph 不等于 Multi-Agent

另一个常见误解是：只有多个 Agent 才需要 Graph。

实际上：

• 一个 Agent 可以使用 Graph。

• 多个 Agent 也可以不使用 Graph（例如：多轮讨论后决策）。

• 一个 Graph 的节点可以完全不调用 LLM（例如直接调用现有的函数取值）。

• 一个 Graph 的节点可以调用一整个 Agent Loop（例如调用的函数中存在Loop逻辑）。

因此，Graph 解决的是流程编排与状态组织问题，不是 Agent 数量问题。

五、Harness：让 Agent 真正运行起来的基础设施

这是五个概念中最容易被误解、但工程价值非常高的一个。

5.1 Harness 的准确含义

Harness 原本有“装具、连接与约束结构”的含义。

在现代 Agent 工程中，可以理解为：

围绕 LLM 构建的一套运行系统，负责将模型的决策转换为实际动作，并管理整个执行过程。

Microsoft、Google 和 VS Code 的技术文档都使用了相近的定义：

Harness 负责组织模型与工具调用、维护会话状态、提供上下文、实施权限和运行控制。

用通俗的比喻来说：

• LLM 是大脑。

• Tools 是能够使用的工具或操作能力。

• Loop 是反复思考与执行的工作方式。

• Graph 是工作流程图。

• Harness 是让整套系统能够工作、持续工作、受到约束的运行环境。

5.2 Harness 内部一般包含什么？

不是每个 Harness 都需要实现以上所有能力，但成熟的 Harness 通常会覆盖其中大部分。

5.3 Harness 和 Agent 的本质区别

从工程角度看：

Agent 是面向用户目标的完整系统，Harness 是承载它的执行基础设施。

举个例子，你们需要开发两个 Agent：

• 儿童陪伴 Agent：负责诗词教学、知识问答、学习引导。

• 老人陪伴 Agent：负责长辈陪伴、家庭关系维护、生活提醒。

它们的业务目标、Prompt、Tools 和 Memory 策略不同。

但底层可以复用同一套 Harness：

                  Shared Harness
                        |
        +---------------+---------------+
        |                               |
    儿童陪伴 Agent                 老人陪伴 Agent
        |                               |
  教学工具 / 学习档案             家庭工具 / 生活档案

因此，Harness 的主要工程价值就是：

避免为每一个 Agent 重复开发模型调用、工具执行、状态管理、权限校验和监控机制。

5.4 Agent = LLM + Harness，这个公式正确吗？

在当前工程语境下，这是一个很有解释力的近似公式。

但它取决于你如何界定 Harness 的范围。

如果 Harness 已经包含 Tools、Memory、Loop 和上下文管理，那么：

如果 Harness 只指基础执行器，那么 Memory 和业务工具可能由 Agent 应用层提供。

所以：

• LLM + Tools + Memory 是一种能力组成视角。

• LLM + Harness 是一种系统实现视角。

• LLM + Loop 是一种最小运行机制视角。

它们描述同一类系统的不同侧面，不应被当作互相矛盾的标准公式。

六、最重要的关系：它们究竟是包含关系，还是替代关系？

可以从三个维度理解。

6.1 能力维度、控制维度、工程维度

维度	对应概念	解决的核心问题
智能与行为主体	LLM、Agent	系统能理解什么、决策什么、完成什么
控制与编排	Loop、Graph	系统如何一步步执行任务
运行基础设施	Harness	系统如何可靠地管理和执行这些步骤

最容易犯的错误是把三者混在一起。

例如：

• “我们要用 Agent 还是 Graph？”——不合理，因为 Agent 可以通过 Graph 实现。

• “我们有 Harness，还需要 Loop 吗？”——Harness 通常就需要某种 Loop 或执行调度机制。

• “我们用了 LangGraph，是不是就有完整 Agent 了？”——不是，还需要模型、工具、任务目标等。

• “我们用了 OpenAI Agents SDK，是不是不需要 Graph？”——未必；复杂工作流仍可能需要显式编排。

6.2 四种典型实现形态

四种形态	结构	使用情况
形态 A：纯 LLM 调用	用户输入 → LLM → 输出	适用于闲聊、文本改写、简单问答。没有必要设计完整 Agent。
形态 B：固定 Workflow	输入 → 检索 → LLM → 校验 → 输出	路径由代码规定。适用于标准化、确定性要求高的流程。不一定需要自主 Agent。
形态 C：Loop-based Agent	LLM → Tool → Observation → LLM → ...	模型动态选择工具与行动，Harness 驱动循环。适合开放式、步骤数量未知的任务。
形态 D：Graph-orchestrated Agent System	状态 → 路由 → 专业节点/Agent → 检查 → 后续节点	显式管理多阶段流程，部分节点内部还可以运行 Agent Loop。适合复杂业务、多分支任务和多 Agent 协作。

这四种形态可以逐步演进，也可以互相组合。

例如，在刚才儿童陪伴智能体的例子里，复杂 Graph 中的知识检索节点可以是固定 Workflow，教学节点可以是 Loop-based Agent，而普通闲聊节点只需一次 LLM 调用。

七、工程实践：什么时候使用哪一种？

这部分可以直接作为你们进行 Agent 技术选型时的参考。

7.1 按任务复杂度选择

任务场景	推荐实现	原因
简单闲聊、诗词解释	直接 LLM	单次调用即可完成
知识库检索问答	Workflow / RAG	检索步骤相对明确
天气查询、音乐播放	LLM + Function Calling	动态选择少量工具即可
多步知识探索	Agent + Loop	需要根据工具结果决定下一步
自适应教学、阶段性测验	Graph + Agent Loop	既有固定教学流程，也有动态策略
多 Agent 分工	Graph 或 Orchestrator	需要任务分配、依赖管理和结果汇总
长期运行的复杂任务	Harness + 状态持久化 + 编排	需要恢复、权限、监控和可靠执行

这张表有一个隐含原则：尽量从能够完成任务的最简单架构开始，不要一开始就使用多 Agent 和复杂 Graph。

在其 Agent 架构实践中也强调，复杂性会带来额外延迟、成本以及错误累积风险。

7.2 主流开发框架分别解决什么？

框架	主要定位	什么时候考虑
OpenAI Agents SDK	Agent 执行、工具调用、handoff、会话与追踪	想快速实现工具型 Agent
LangGraph	有状态 Graph、复杂流程和执行控制	需要显式分支、循环、状态恢复
LangChain	模型、提示词、检索与工具的组件集成	需要快速集成不同能力
AutoGen	多 Agent 交互与协作框架	需要多个 Agent 相互协商、分工
自建 Python Loop	最小自主 Agent Runtime	任务简单、需要完全控制底层行为

其中，OpenAI Agents SDK 并非只能实现简单 Loop，它也包含多 Agent handoff、guardrails、sessions 和 tracing。LangGraph 也不只是可视化流程图，而是具有状态管理和执行控制能力的工作流运行框架。

八、最终总结：用五句话彻底区分

LLM — 智能决策引擎：负责理解、推理和生成决策。

Agent — 面向目标的行动系统：利用模型和外部能力，根据反馈自主完成任务。

Loop — 行动闭环：负责反复决策、执行、观察，直到满足停止条件。

Graph — 流程组织方式：负责定义有哪些执行节点、状态如何传递、下一步走哪里。

Harness — 运行基础设施：负责让模型决策可靠地转化为行动，并管理执行、上下文、安全和恢复。

参考资料：

1. Anthropic — Building Effective Agents：区分 Workflow、Agent 和自主执行循环。

2. OpenAI — Running Agents：解释 Agent Loop、工具调用和状态延续。

3. LangGraph — Graph API Overview：理解 State、Node、Edge。

4. VS Code — Understand Agent Harnesses：解释 Model、Agent、Harness 和运行环境的边界。

5. Microsoft — Agent Harness：了解 Harness 在工程层面的组成与职责。