摘要

随着大语言模型（LLM）应用从简单的 RAG（检索增强生成）向自主性更强的 Agent（智能体）演进，开发者们发现 LangChain 早期引以为傲的 "Chain"（链式）架构在处理复杂任务时逐渐显得力不从心。本文将从拓扑结构、状态管理、动态决策及容错机制四个维度，深入剖析 Chain 架构在构建复杂 Agent 时的局限性，并探讨为何架构模式正在从 DAG（有向无环图）向循环图（Cyclic Graph）演进。

---

引言

大家好，我是林康保。在 LLM 应用开发的早期，LangChain 凭借其强大的 Chain 概念——将 Prompt、Model 和 Output Parser 串联成流水线——成为了行业的标准库。对于问答机器人、简单的文档摘要等确定性任务，Chain 架构优雅且高效。

然而，当我们试图构建一个真正的 Agent（例如一个能够自动写代码、运行测试、根据报错修改代码并循环直至成功的智能体）时，经典的 Chain 架构开始变得笨重且难以维护。为什么线性的链条无法承载复杂的思考？让我们深入底层逻辑一探究竟。

---

一、 拓扑结构的僵化：DAG vs. Cyclic Graph

Chain 架构的核心设计理念是 DAG（有向无环图）。无论是 SequentialChain 还是现代的 LCEL（LangChain Expression Language），其本质都是预定义的、单向流动的管道。

1. 缺乏原生循环（Loop）支持

复杂 Agent 的核心特征是迭代（Iteration）。例如，一个 ReAct 模式的 Agent 需要经历 思考 -> 行动 -> 观察 -> 再思考 的循环。
在 Chain 架构中，实现这种循环非常痛苦：

• 你必须使用递归调用 Chain，容易导致堆栈溢出或上下文丢失。
• 或者在 Chain 外部包裹 Python 的 while 循环，但这打破了 Chain 的封装性，使得中间状态难以被 LangSmith 等工具追踪。

2. 难以处理长时间运行的任务

由于 Chain 是一次性执行到底的，如果任务需要暂停、等待人工确认（Human-in-the-loop）后再继续，标准的 Chain 很难保存中间的断点状态。

---

二、 状态管理（State Management）的混乱

在简单的流水线中，上一步的输出是下一步的输入，这种传递方式很清晰。但在复杂 Agent 任务中，我们需要维护一个全局的 "世界状态"（World State）。

1.隐式传递 vs. 显式状态

在 Chain 架构中，变量通常通过 input_variables 和 output_variables 在各个环节间隐式传递。当链条变长（例如 10 个步骤）时：

• 变量名极易冲突。
• 很难弄清楚第 8 步的数据到底是来自第 1 步还是第 7 步。
• 局限性： Agent 需要一个结构化的、持久的 State 对象（类似 Redux 或 Vuex 的 Store），而 Chain 提供的是松散的字典传递，导致随着复杂度增加，数据流向变得不可控。

2. 记忆（Memory）模块的割裂

LangChain 早期的 Memory 组件虽然好用，但它通常被设计为追加式的对话历史。对于 Agent 而言，我们需要修改历史、删除错误的尝试、或者更新特定的槽位（Slot Filling）。标准 Chain 的 Memory 机制在处理这种精细化操作时显得非常僵硬。

---

三、 动态决策与路由的笨重

Agent 的智能体现在动态规划：根据当前的观察结果，决定下一步是查天气、算数学还是直接回答。

1. 静态编排 vs. 动态路由

Chain 通常是在代码运行时构建好的静态图。虽然 LangChain 提供了 RouterChain，但在实际使用中：

• 它的条件判断逻辑通常比较简单。
• 很难实现 "如果 A 失败了尝试 B，如果 B 也失败了则回退到 C" 这种复杂的动态分支逻辑。

2. 缺乏"规划"的灵活性

在一个 Plan-and-Solve 的 Agent 中，计划是动态生成的。Chain 架构要求开发者预先定义好步骤，这与 Agent "走一步看一步" 的本质相悖。

---

四、 错误处理与自愈能力（Self-Correction）

这是 Chain 架构在 Agent 开发中最大的痛点。

1. "一损俱损"的线性逻辑

在传统的 Chain 中，如果中间某一步骤（比如工具调用）抛出了异常，整个链条通常会直接中断（Raise Error）。

2. Agent 需要的是"捕获并重试"

对于一个鲁棒的 Agent，工具调用失败不应该导致程序崩溃，而应该将错误信息（Error Message）作为新的 Observation 反馈给 LLM，让 LLM 尝试修正参数并重试。
在 LCEL 或标准 Chain 中实现这种细粒度的 try-catch-retry 逻辑，会导致代码嵌套极深，可读性极差，且难以复用。

---

五、 解决方案：从 Chain 到 Graph

面对上述局限性，社区和 LangChain 官方都已经意识到了问题，这也是 LangGraph 诞生的原因。

LangGraph 引入了 State Machines（状态机） 的概念，解决了 Chain 的核心痛点：

1. 支持循环（Cycles）： 原生支持图中的环，完美适配 Agent 的循环推理。
2. 共享状态（Shared State）： 定义统一的 Schema，所有节点都对同一个 State 进行读取和更新。
3. 持久化（Persistence）： 可以在图的任意节点暂停、保存状态、并在未来恢复（支持 Time Travel）。

代码对比示意

传统 Chain (伪代码):

# 线性结构，难以回头
chain = Step1 | Step2 | Step3
try:
    chain.invoke(input)
except:
    print("Failed") # 很难让 Step2 知道失败并重试

Graph 架构 (LangGraph 理念):

# 定义节点
workflow = StateGraph(AgentState)
workflow.add_node("agent", call_model)
workflow.add_node("action", call_tool)

# 定义循环逻辑
workflow.add_conditional_edges(
    "agent",
    should_continue,
    {
        "continue": "action",
        "end": END
    }
)
workflow.add_edge("action", "agent") # 这里的边构成了一个环！

---

结语

LangChain 的 Chain 架构并没有过时，它依然是处理确定性、线性工作流的最佳选择。但在构建自主 Agent 这一特定领域，线性的 Chain 已经无法模拟人类复杂的非线性思维过程。

作为开发者，我们需要认清工具的边界。当你发现自己在 Chain 里面写了太多的 if-else 或者试图在外部包裹复杂的 while 循环时，也许是时候放下 Chain，拥抱基于图（Graph）的架构了。

---

关于作者：
林康保，AI 技术实践者，专注于 LLM 应用架构与工程化落地。希望能通过这篇文章帮助大家在 Agent 开发中少走弯路。欢迎在评论区交流你的看法！