目录

从 LangChain 到 LangGraph，再到 DeepAgent：Agent 架构为什么不断演进？

01｜为什么 Agent 架构一直在演进？

02｜阶段一：LangChain 更像组件流水线

03｜阶段二：LangGraph 把 Agent 变成有状态的执行图

04｜阶段三：Agent Harness 把状态机升级为受控执行闭环

05｜LangChain、LangGraph 和 DeepAgent 不是替代关系

06｜三次演进，本质上改变了什么？

07｜面向企业 SaaS，三层架构应该如何组合？

08｜单个 Agent Loop 的边界在哪里？

09｜什么时候应该选择哪一种架构？

10｜五个常见误区

11｜总结：从 Chain 到 Loop，下一步是 Graph of Graphs

参考资料

---

从 LangChain 到 LangGraph，再到 DeepAgent：Agent 架构为什么不断演进？

摘要： 从组件流水线、有状态编排到 Agent Harness，本文拆解企业 Agent 架构的三次能力升级，以及它们为什么最终会走向 Graph Engineering。

---

前面八篇文章，我们已经从 Prompt Engineering、Context Engineering、Workflow、Harness Loop，一直讲到了 Agent Runtime、AI Data Platform、多租户治理，以及 MCP、A2A 与 Agent Registry。

第八篇解决了能力如何接入、注册和治理的问题。但当越来越多模型、工具与专业 Agent 被接入平台之后，还需要继续回答一个更底层的问题：

这些能力应该以什么样的执行结构运行，才能同时管理状态、分支、循环、恢复、委派和长期任务？

如果回头看这条技术路线，会发现一个很明显的变化：

最早，我们关心的是如何把模型、Prompt、Retriever 和 Tool 连接起来。

后来，我们开始关心任务执行到了哪一步、当前状态是什么、失败以后如何恢复。

再后来，我们开始关心：

• Agent 能不能自己拆解任务？

• 能不能根据执行结果重新规划？

• 能不能把复杂任务交给不同的专业 Agent？

• 能不能管理长上下文和中间产物？

• 能不能在权限、预算和终止条件约束下持续执行？

这背后对应着企业 Agent 架构的三次升级：

执行流程： LangChain 组件流水线 → LangGraph 有状态编排 → DeepAgent / Agent Harness 动态执行闭环

它们看起来像三个框架阶段，实际上分别代表三种不同的工程抽象：

• LangChain 主要解决组件如何连接。

• LangGraph 主要解决状态和流程如何显式管理。

• Agent Harness 主要解决长任务如何规划、执行、修正和结束。

而当企业系统中同时存在多个这样的 Agent Loop 时，新的问题就出现了：

多个 Loop 如何协作、如何相互制约、如何共享证据，又如何共同进化？

这个问题最终会把架构推向 Graph Engineering。

01｜为什么 Agent 架构一直在演进？

Agent 架构不断演进，不是因为旧框架突然不能用了，而是因为工程问题的边界变大了。

早期 LLM 应用通常只有一条简单链路：

执行流程： 用户输入 → Prompt → LLM → 输出

这个阶段的核心问题是：

• 如何调用不同模型？

• 如何设计 Prompt？

• 如何解析输出？

• 如何接入知识检索？

• 如何调用一个外部工具？

当这些问题逐渐被解决后，应用开始进入更复杂的业务场景：

• 一个任务需要调用多个工具。

• 工具之间存在前后依赖。

• 某些步骤可以并行。

• 某些步骤失败后需要重试。

• 某些信息不足时需要追问用户。

• 某些动作执行前需要权限检查。

• 某些高风险结果需要人工确认。

• 某些长任务需要中断、保存和恢复。

这时，问题已经不再是“怎么调用模型”。

而是：

关键判断： 如何把一个非确定性的模型，放进一个有状态、有边界、可恢复的业务执行系统。

再往后，任务复杂度继续增加。

单个状态图即使能够表达循环，也不代表它适合承载所有领域能力。一个大型 Agent 同时掌握大量工具、上下文和业务规则，通常会带来新的问题：

• Prompt 越来越长。

• Tool 数量越来越多。

• 工具选择准确率下降。

• 不同领域上下文互相污染。

• 权限边界越来越难解释。

• 失败以后不知道应该从哪里修正。

• 一个任务的局部问题拖累整个执行链路。

于是，架构开始从“一个复杂 Agent”演进为：

• 一个主调度 Loop。

• 多个领域 Agent。

• 每个领域 Agent 拥有自己的工具和上下文。

• 主调度 Loop 负责计划、依赖、权限、聚合和终止。

这就是从 Chain 到 StateGraph，再到 Agent Harness 的真实背景。

图｜组件、状态、Loop 与 Graph Engineering 解决不同层次的问题

02｜阶段一：LangChain 更像组件流水线

先从 LangChain 说起。

LangChain 最重要的价值，不是创造了某一种固定的 Agent 架构，而是把 LLM 应用里大量重复的能力抽象成了可组合组件：

• Model

• Prompt Template

• Message

• Retriever

• Document

• Tool

• Output Parser

• Memory

• Callback

• Runnable

有了这些组件，开发者不需要为每一个模型供应商、向量库和工具接口重新设计一套调用方式。

在最常见的早期架构里，LangChain 更像一条组件流水线：

执行流程： 输入 → Prompt → LLM → Retriever / Tool → Output Parser → 输出

图｜LangChain 通过统一组件和调用接口降低 LLM 应用集成成本

这类结构特别适合：

• 企业知识库问答。

• FAQ 检索。

• 文档摘要。

• 单 Agent 工具调用。

• 结构化信息抽取。

• 简单的数据查询和结果解释。

它解决的是“能力连接”问题。

例如，一个企业知识问答应用可以被拆成：

1. 接收用户问题。

2. 改写检索 Query。

3. 从知识库检索文档。

4. 将文档装配到 Prompt。

5. 调用模型生成答案。

6. 解析引用和结构化字段。

只要业务步骤相对明确，这种流水线非常有效。

LangChain 阶段的核心工程对象

这个阶段最重要的工程对象通常是组件和调用关系：

PromptTemplate
Retriever
Model
Tool
Parser

系统设计重点在于：

• 组件是否容易替换？

• 输入输出是否统一？

• Prompt 如何复用？

• Retriever 如何接入？

• Tool 如何暴露给模型？

• 输出如何解析？

这仍然是今天企业 Agent 开发的重要基础。

但当执行过程出现复杂分支、循环、暂停和恢复时，仅仅把组件串起来就不够了。

流水线的边界

假设一个任务需要：

1. 先判断用户意图。

2. 根据意图调用不同的业务模块。

3. 如果缺少字段，暂停并追问。

4. 如果工具失败，换一种查询方式。

5. 如果结果冲突，进入人工审核。

6. 审核完成后从原位置恢复。

这时，真正需要管理的已经不只是组件。

而是：

• 当前状态。

• 已完成节点。

• 待执行节点。

• 条件分支。

• 循环次数。

• 中间结果。

• 恢复位置。

于是，架构进入第二阶段。

03｜阶段二：LangGraph 把 Agent 变成有状态的执行图

LangGraph 的核心变化，是把 Agent 执行过程显式建模为：

• State

• Node

• Edge

State 表示当前任务快照。

Node 表示一次计算、模型调用、工具执行、校验或人工交互。

Edge 表示下一步应该执行什么，可以是固定边，也可以是条件边。

执行流程： 输入 State → 执行 Node → 更新 State → 根据 Edge 路由 → 继续执行或结束

图｜LangGraph 将分支、循环、状态和恢复位置显式建模

这一步的价值很大。

因为 Agent 不再只是“调用模型直到返回答案”，而是成为一个可以被观察和控制的状态机。

State：从聊天记录升级为任务快照

很多系统一开始会把 State 简化成消息列表。

但企业 Agent 的 State 往往还需要包含：

• 当前任务目标。

• 租户与用户上下文。

• 已提取字段。

• 当前执行计划。

• 已完成步骤。

• 工具返回。

• 证据列表。

• 风险等级。

• 权限检查结果。

• 人工审核状态。

• 当前轮次。

• 错误与重试信息。

这意味着 State 不是“无限累积的上下文”。

它是一份结构化的运行快照。

Node：不同确定性程度的执行单元

LangGraph 里的 Node 不一定都是 LLM。

一个 Node 可以是：

• 普通 Python 函数。

• 一次 LLM 调用。

• 一个 Tool 调用。

• 一个 RAG 检索过程。

• 一个规则校验器。

• 一个权限检查节点。

• 一个完整 Agent。

• 一个人工审核节点。

这使系统可以把确定性逻辑和模型推理放在不同位置。

例如：

• 意图候选可以由模型生成。

• 允许访问哪些数据由权限系统决定。

• 计划可以由模型提出。

• 计划是否合法由代码校验。

• 高风险动作是否执行由人工确认。

模型负责它擅长的语义理解和推理。

确定性系统负责边界、权限和最终执行。

Edge：把业务约束写进执行路径

Edge 决定下一步去哪。

典型条件包括：

• 信息是否完整。

• 计划是否合法。

• 权限是否通过。

• 工具是否成功。

• 证据是否冲突。

• 是否需要继续检索。

• 是否达到最大轮次。

• 是否需要人工介入。

当这些条件被显式建模以后，系统不再完全依赖 Prompt 告诉模型“请遵守规则”。

规则成为执行图的一部分。

Checkpoint：让执行可以暂停和恢复

企业任务经常不是一次请求内完成。

例如：

• 等待用户补充材料。

• 等待人工审批。

• 等待外部系统回调。

• 服务重启以后继续任务。

• 工具暂时不可用，稍后恢复。

Checkpoint 保存的是执行状态和恢复位置。

它让 Agent 从一次性请求变成长生命周期任务。

这里也要明确：

关键判断： Checkpoint 是执行恢复机制，不等于长期记忆，也不等于企业知识库。

State 管理当前任务。

Checkpointer 管理执行恢复。

长期 Memory 管理跨会话稳定事实。

RAG 和业务系统管理外部知识与业务事实。

这些边界不能混在一起。

04｜阶段三：Agent Harness 把状态机升级为受控执行闭环

LangGraph 解决了状态、节点、边、循环和恢复问题。

但一个新的问题仍然存在：

图里的每一步由谁决定？

如果所有节点和路径都由开发者提前写死，那么它更接近有状态 Workflow。

而复杂 Agent 任务往往无法在执行前完整预测。

例如，一个企业数据诊断任务可能需要：

1. 理解用户描述。

2. 判断应该检查哪些数据源。

3. 并行查询多个系统。

4. 根据中间结果决定是否继续。

5. 生成新的子任务。

6. 将部分任务交给专业 Agent。

7. 发现证据不足后补充检索。

8. 生成结论前进行一致性校验。

这些步骤的数量和顺序，会随着任务内容动态变化。

这时，需要在 Runtime 之上增加 Agent Harness。

图｜Agent Harness 围绕计划、工具、子 Agent、上下文和终止条件形成动态调度 Loop

什么是 Agent Harness？

Agent Harness 可以理解为包裹在模型外部的一套执行环境。

它通常负责：

• 任务规划。

• Todo 或任务列表管理。

• 工具选择。

• 子任务委派。

• 子 Agent 调用。

• 中间产物管理。

• 长上下文压缩。

• 失败观察。

• 重新规划。

• 终止条件判断。

• 人工介入。

模型仍然是推理核心。

但模型不再直接面对整个系统。

Harness 决定模型能看到什么、能调用什么、如何保存中间结果，以及什么时候必须停止。

DeepAgent 代表的不是“更大的 Agent”

这里的 DeepAgent，不应该被理解成拥有全部工具、全部权限和全部上下文的超级 Agent。

更合理的理解是：

关键判断： DeepAgent 是面向复杂长任务的 Agent Harness，让模型能够在受控环境中规划、委派、使用工具和管理中间产物。

它与 LangGraph 不是互相替代关系。

Agent Harness 可以构建在 LangGraph 之上，利用 LangGraph 提供：

• Durable Execution

• Checkpoint

• Streaming

• Human-in-the-loop

• State Persistence

Harness 再在这些运行能力之上增加：

• Planning

• Subagents

• Filesystem / Artifact

• Context Management

• Long-running Task Support

所以，两者关系更像：

LangGraph
负责低层状态与持久化执行
        ↓
Agent Harness
负责高层规划、委派与上下文管理

Harness Loop 与普通 ReAct 的区别

普通 ReAct 往往是：

执行流程： Reason → Act → Observe → Reason

企业级 Harness Loop 则更完整：

执行流程： Context → Plan → Validate → Permission → Execute → Observe → Aggregate → Decide → Replan / Clarify / HITL / Finish

多出来的部分非常关键：

• Validate：模型计划必须经过结构化校验。

• Permission：执行之前检查权限。

• Aggregate：多来源结果需要统一聚合。

• Decide：是否继续不能只依赖模型直觉。

• HITL：高风险或不确定任务进入人工审核。

• Finish：必须有明确终止条件和预算。

因此，Agent Harness 的目标不是让 Agent 无限自主。

而是让自主执行变得可控。

05｜LangChain、LangGraph 和 DeepAgent 不是替代关系

很多人在学习这些框架时，容易形成一条简单判断：

LangChain 过时了
    ↓
应该换成 LangGraph
    ↓
LangGraph 又被 DeepAgent 替代

这个理解并不准确。

更合理的关系是：

层次	主要解决的问题	典型能力
LangChain	模型与组件如何集成	Model、Prompt、Tool、Retriever、Parser
LangGraph	状态和执行流程如何管理	State、Node、Edge、Checkpoint、Interrupt
Agent Harness	长任务如何动态执行	Planning、Subagents、Artifacts、Context Management
Agent Platform	多租户生产系统如何治理	Runtime、Registry、Permission、Trace、Evaluation

一个企业 Agent 系统完全可能同时使用这些能力：

• 使用 LangChain 统一模型和 Tool 接口。

• 使用 LangGraph 构建主状态机。

• 使用 Agent Harness 处理复杂长任务。

• 使用企业 Runtime 负责多租户、权限、审计和评测。

它们处在不同层次。

框架是实现，架构是职责边界

企业系统不应该把架构完全绑定到框架名称。

真正需要稳定的是：

• 统一任务协议。

• 统一证据协议。

• Agent 能力协议。

• Tool 调用协议。

• 状态和 Checkpoint 边界。

• 权限与风险模型。

• Trace 与评测数据模型。

底层框架可以升级。

但这些平台协议不能随着每次框架升级全部推倒重来。

06｜三次演进，本质上改变了什么？

从 LangChain 到 LangGraph，再到 Agent Harness，本质上发生了三次工程对象迁移。

第一次：从模型调用迁移到组件组合

最早的工程对象是一次 API 调用。

LangChain 把工程对象扩展为：

• Prompt。

• Retriever。

• Tool。

• Parser。

• Memory。

开发者开始构建 LLM Application，而不是孤立的模型调用。

第二次：从组件组合迁移到运行状态

当任务出现分支、循环和恢复需求时，工程对象变成：

• State。

• Node。

• Edge。

• Checkpoint。

• Interrupt。

系统开始管理任务生命周期，而不是只管理调用链。

第三次：从固定状态机迁移到受控目标执行

复杂任务无法完全提前定义路径。

于是工程对象继续扩展为：

• Goal。

• Plan。

• Task。

• Artifact。

• Subagent。

• Budget。

• Stop Condition。

系统开始管理目标完成过程。

这三次变化可以概括成：

执行流程： Call → Chain → StateGraph → Agent Loop

但演进到这里，仍然主要在讨论“一个执行单元如何完成任务”。

企业平台下一步必须面对的是：

• 多个 Loop 同时运行。

• 多个 Loop 共享部分证据。

• 多个 Loop 拥有不同权限。

• 多个 Loop 具有不同预算和时效。

• 多个 Loop 的结论可能冲突。

• 某些 Loop 能够否决其他 Loop。

• 某些 Loop 负责执行，另一些 Loop 负责评测。

这就是 Graph Engineering 出现的位置。

07｜面向企业 SaaS，三层架构应该如何组合？

在通用企业 SaaS Agent 系统里，可以把这三层组合成下面的结构。

Access Layer
    ↓
Context Engineering
    ↓
Root StateGraph
    ↓
Agent Harness / Dynamic Planner
    ↓
Domain Agents / Tools / RAG
    ↓
Verifier / Permission / HITL
    ↓
Result / Trace / Evaluation

Access Layer

负责：

• 用户身份。

• 租户上下文。

• 会话。

• 请求幂等。

• 附件。

• API 协议适配。

它不直接决定调用哪个 Agent。

Context Engineering

负责把：

• 用户文本。

• 图片与语音。

• 会话历史。

• 长期记忆。

• RAG 证据。

• 业务查询结果。

• 权限上下文。

整理成可追溯的上下文快照。

Root StateGraph

负责全局流程：

• 计划。

• 校验。

• 权限。

• 调度。

• 聚合。

• 审核。

• 回复。

这是企业系统的根控制图。

Agent Harness

只在任务确实复杂时启用。

它负责：

• 动态拆解任务。

• 生成子任务。

• 调用领域 Agent。

• 管理中间产物。

• 根据结果重新规划。

Domain Agents

负责局部领域能力。

每个领域 Agent 应该只拥有完成自身任务所需的：

• Prompt。

• Context。

• Tools。

• Knowledge。

• Permission Scope。

不要把全部平台能力都暴露给每一个 Agent。

Verifier 与 Permission

Verifier 判断结果是否完整、一致、可信。

Permission Gate 判断动作是否允许执行。

两者不能被合并成一句 Prompt。

Trace 与 Evaluation

记录：

• 输入了什么。

• 使用了什么上下文。

• 生成了什么计划。

• 调用了哪些 Agent 和 Tool。

• 为什么重试。

• 为什么被拦截。

• 最终结果如何。

这些数据会成为后续 Graph Engineering 进化闭环的基础。

08｜单个 Agent Loop 的边界在哪里？

Agent Harness 能让一个 Agent 处理更复杂的任务。

但它并不能解决所有问题。

上下文边界

一个 Agent 不应该看到所有领域上下文。

上下文越多，不代表决策越准确。

过多上下文会导致：

• 重要证据被淹没。

• 不同领域规则冲突。

• 敏感信息暴露范围扩大。

• Token 和推理成本上升。

工具边界

一个 Agent 不应该拥有所有工具。

Tool 数量增加后，模型需要在更多候选能力中选择，错误调用和参数幻觉的概率也会增加。

权限边界

模型不能通过“重新规划”扩大权限。

即使 Agent 判断某个动作有助于完成任务，也必须重新经过权限系统。

故障边界

某个领域 Agent 失败，不应该让整个任务失去恢复能力。

主调度层需要知道：

• 哪个子任务失败。

• 是否可以重试。

• 是否有替代 Agent。

• 是否保留已完成结果。

• 是否应该降级或转人工。

评测边界

只评测最终答案，会掩盖中间链路问题。

系统还需要评测：

• 路由是否正确。

• 计划是否合理。

• 工具选择是否正确。

• 权限是否拦截。

• 证据是否充分。

• 重试是否有效。

• 是否在正确时机结束。

这些问题已经超出单个 Loop 的局部优化范围。

09｜什么时候应该选择哪一种架构？

不是所有系统都需要从第一天开始建设复杂 Agent Graph。

适合使用简单 LangChain / Agent 的场景

• 单一知识库问答。

• 工具数量很少。

• 流程短。

• 不涉及长任务。

• 不需要人工中断恢复。

• 失败后可以直接重新请求。

适合使用 LangGraph 的场景

• 有明确状态。

• 有条件分支。

• 有循环和重试。

• 需要 Checkpoint。

• 需要人工审批。

• 需要恢复执行。

• 需要确定性节点和模型节点混合。

适合增加 Agent Harness 的场景

• 任务步骤无法提前完全确定。

• 需要动态拆解。

• 需要管理大量中间产物。

• 需要使用子 Agent。

• 需要长时间执行。

• 需要根据结果持续修正计划。

适合进入 Graph Engineering 的场景

• 存在多个独立 Agent Loop。

• 不同 Agent 由不同团队维护。

• 任务具有跨领域依赖。

• 需要全局权限和预算治理。

• 需要跨图 Checkpoint 与 Trace。

• 需要评测、审计和灰度进化。

最合理的建设顺序通常是：

执行流程： 先解决真实业务问题 → 抽象稳定协议 → 建立状态图 → 增加 Harness → 再演进为 Graph of Graphs

不要为了使用新概念，提前建设没有业务必要性的复杂拓扑。

10｜五个常见误区

误区一：LangChain 只能做固定 Chain

LangChain 自身也在持续演进，现代 Agent 能力并不等同于早期固定 Chain。

本文使用“组件流水线”描述的是一种工程抽象阶段，不是给某个版本下永久定义。

误区二：用了 LangGraph 就有企业级 Runtime

LangGraph提供状态编排和持久化执行能力。

但企业 Runtime 还需要：

• 多租户。

• 权限中心。

• Agent Registry。

• Tool 治理。

• 审计。

• 限流与预算。

• Evaluation。

• 灰度发布。

框架是 Runtime 的重要组成部分，但不是完整平台。

误区三：DeepAgent 就是一个超级 Agent

Agent Harness 的价值是规划、委派和上下文管理。

它不应该拥有无边界权限，也不应该替代企业控制面。

误区四：自主执行就是不断循环

没有预算、停止条件和失败分类的循环，不是智能，只是不可控。

每一次继续执行都应该有依据：

• 新证据出现。

• 缺失字段已补齐。

• 计划得到修正。

• 替代工具可用。

• 人工批准继续。

误区五：框架越高级，系统就越可靠

可靠性来自：

• 明确协议。

• 状态边界。

• 确定性校验。

• 权限治理。

• Checkpoint。

• Trace。

• Evaluation。

• 灰度与回滚。

不是来自框架名称。

11｜总结：从 Chain 到 Loop，下一步是 Graph of Graphs

LangChain、LangGraph 和 Agent Harness，分别推动了企业 Agent 架构的三次升级。

LangChain 让模型、Prompt、Retriever 和 Tool 变成可组合组件。

LangGraph 让任务状态、执行节点、条件边、循环和恢复位置可以被显式管理。

Agent Harness 让复杂任务能够在受控环境中规划、委派、执行、观察和修正。

可以用一条路径总结：

执行流程： Component Integration → Stateful Orchestration → Controlled Agent Loop

但企业系统不会永远只有一个 Loop。

当多模态处理是一个 Graph、根调度中心是一个 Graph、每个领域 Agent 内部也拥有独立 Graph 时，系统就会变成：

Context Graph
    ↓
Root Control Graph
    ↓
Dynamic Work Graph
    ↓
Domain Subgraphs

这时，最重要的问题已经不再是：

某一个 Agent 应该怎么执行？

而是：

• 多个 Graph 如何交换状态？

• 多个 Loop 如何共享 Artifact 和 Evidence？

• 根 Graph 如何约束领域 Subgraph？

• 子图失败后如何恢复？

• Checkpoint 如何隔离？

• 权限与预算由谁控制？

• 多个 Loop 如何通过评测共同进化？

这就是下一篇要讲的主题：

Graph Engineering：企业级 Agent 如何从单个 Loop 走向 Graph of Graphs？

感谢阅读与关注。如果文章对你有所启发，欢迎在评论区交流企业 AI Agent 落地过程中遇到的问题。

参考资料

• LangChain 官方文档：LangChain Overview

• LangGraph 官方文档：LangGraph Overview

• LangChain 官方文档：Frameworks、Runtimes 与 Harnesses

• LangGraph 官方文档：Graph API