如果说上篇是在讲“LangChain 和 LangGraph 到底怎么分”，中篇是在讲“图怎么搭、状态怎么流转”，那这一篇就是真正把 Agent 系统跑起来。

很多人谈 Agent 时，容易把所有东西揉成一团，仿佛只要模型会调用工具、能循环几轮、能自动执行任务，就都叫 Agent。可一旦进入工程落地，我们会很快发现，不同复杂度的 Agent，设计重点完全不一样。

有的系统本质上是工作流，只是看起来像 Agent；有的系统已经能自主决定工具调用；再往上则会出现多角色协作、状态管理、长期运行，甚至发展到最近很火的 OpenClaw 这类 computer-use / personal automation agent。

这一篇就围绕这条线展开：先做一个基于 LangChain 体系的 Agent 实战，再把几种典型范式拆开来看。

1. 先说结论：不是所有 LLM 应用都该做 Agent

在真正写 Agent 之前，先下一个很重要的判断：

如果业务流程足够确定，优先做工作流；只有当“步骤不确定，需要模型决定下一步动作”时，才考虑 Agent。

这是因为 Agent 的核心代价就是不确定性：

  1. 路径不固定
  2. 工具调用不固定
  3. token 成本不固定
  4. 调试难度更高
  5. 结果稳定性更弱

所以 Agent 最大的价值，不是“看起来更智能”，而是能够处理那些流程难以预先写死的问题。

2. 我对 L2/L3/L4 的一个工程化理解

这里先说明一下，L2/L3/L4 并不是所有团队都完全统一的标准命名。为了方便工程讨论，本文采用一个比较实用的分法：

L2：Workflow 型智能应用

特点是：

  1. 主流程由开发者定义
  2. 模型负责局部理解与生成
  3. 节点顺序总体可控

典型场景：

  1. 分类后路由
  2. 文本清洗后检索
  3. 问答后结构化输出
  4. 审核后再发布

它更像“LLM 增强工作流”。

L3：Tool-Using Agent

特点是：

  1. 模型会根据任务自主选择工具
  2. 执行路径不完全固定
  3. 通常有 ReAct、Tool Calling、Observation 这样的循环

典型场景：

  1. 搜索后总结
  2. 查数据库再分析
  3. 多工具协同完成任务

它更像“单 Agent 自主执行器”。

L4：Multi-Agent / Stateful Agent System

特点是：

  1. 多角色协作
  2. 状态显式管理
  3. 有长期任务或复杂任务分解
  4. 通常带审批、回滚、人工介入和记忆

典型场景：

  1. Planner + Executor + Reviewer
  2. 研究员 Agent + 编码 Agent + 审核 Agent
  3. 长周期任务追踪

它更像“Agent 系统”，不是单个 Agent。

如果再往前走，就会碰到现在非常热的一类方向：

OpenClaw 类 Computer-Use Agent

这类系统不只是调用几个函数，而是直接接近“个人自动化操作系统”：

  1. 可控制浏览器
  2. 可连接消息入口
  3. 可调度任务
  4. 可持久化记忆
  5. 可长期驻留运行

所以它和传统“聊天框里的 Agent”已经不完全是一个量级的问题了。

3. 一个最小可用的 LangChain Agent 长什么样

先从 L3 风格的单 Agent 入手。

假设我们要做一个“技术研究助理”，需求如下：

  1. 用户给一个技术主题
  2. Agent 可以调用搜索工具
  3. Agent 最后输出结构化调研结果

最简思路是：

  1. 定义模型
  2. 定义工具
  3. 创建 Agent
  4. 让 Agent 在推理中决定何时调用工具

示意代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
from langchain_openai import ChatOpenAI
from langchain.tools import tool
from langchain.agents import create_tool_calling_agent, AgentExecutor
from langchain_core.prompts import ChatPromptTemplate


@tool
def search_docs(query: str) -> str:
    """搜索技术资料并返回摘要结果"""
    return f"以下是关于 {query} 的模拟搜索结果：LangChain 常用于构建 RAG、Agent 和多步工作流。"


llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

prompt = ChatPromptTemplate.from_messages([
    ("system", "你是一名 AI 技术研究助理，必要时调用工具，不要编造事实。"),
    ("human", "{input}"),
    ("placeholder", "{agent_scratchpad}")
])

tools = [search_docs]

agent = create_tool_calling_agent(llm, tools, prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

result = agent_executor.invoke({
    "input": "请调研 LangChain 在 Agent 开发中的作用，并给出三点结论"
})

print(result["output"])

这个例子已经具备 Agent 的几个核心要素：

  1. 模型不是只回答问题，而是会决定是否行动
  2. 工具被显式暴露给模型
  3. 模型在“思考-行动-观察”中迭代推进任务

这就和上篇的普通链不一样了。

4. 但真正落地时，LangGraph 往往比纯 AgentExecutor 更靠谱

为什么很多生产项目后来都转向 LangGraph？

因为一旦任务复杂起来，单纯的 Agent 循环会暴露很多问题：

  1. 状态不透明
  2. 节点不可控
  3. 重试逻辑难写
  4. 中间产物不易保存
  5. 人工审核难插入

而 LangGraph 更适合表达下面这种流程：

  1. 先计划
  2. 再执行
  3. 失败则重试
  4. 风险高则人工确认
  5. 最后总结与写回状态

也就是说，现代 Agent 实战已经越来越像“图上的状态流转”，而不是“让模型在一个 while 循环里自己乱跑”。

5. 一个更像工程的 Agent 设计方式

如果让我今天用 LangChain 体系来做 Agent，我通常会按这几个层次设计：

5.1 任务层

定义用户真正想完成什么，例如：

  1. 调研一个主题
  2. 生成报告
  3. 安排会议
  4. 执行批量操作

5.2 规划层

决定任务要拆成哪些步骤，例如：

  1. 是否需要检索
  2. 是否需要结构化提取
  3. 是否需要调用内部系统
  4. 是否需要人工确认

5.3 执行层

真正调用工具完成动作，例如：

  1. 搜索
  2. 读写文件
  3. 调 API
  4. 发消息

5.4 记忆与状态层

保存：

  1. 当前执行到哪一步
  2. 已经看过哪些资料
  3. 用户偏好是什么
  4. 是否出现异常

5.5 观测与安全层

记录：

  1. 模型输入输出
  2. 工具调用参数
  3. 执行结果
  4. 风险动作审批

把这几层拆开之后，你会发现 Agent 并不是一个“神秘的大脑”，而是一套由模型、工具、状态、流程和治理共同组成的系统。

6. 从 L2 到 L4，开发重点到底变了什么

下面我们把三种典型范式直接对比一下。

6.1 L2：Workflow 的重点是确定性

L2 里最重要的是：

  1. 节点边界清晰
  2. 输入输出固定
  3. 错误可定位

例如一个“客服工单分发系统”：

  1. 模型识别工单类型
  2. 路由到不同处理链
  3. 检索知识库
  4. 输出回复建议

这里即使用到了模型，本质上还是工作流，不一定需要 Agent。

适合 L2 的问题通常是：

  1. 步骤明确
  2. 需要稳定
  3. 结果要可控

6.2 L3：单 Agent 的重点是工具选择

L3 的重点不再是固定流程，而是：

  1. 给模型哪些工具
  2. 工具描述是否清楚
  3. 如何约束模型少走弯路
  4. 如何防止无意义循环

这时 Prompt 工程会从“生成提示词”变成“执行策略设计”。

你需要考虑：

  1. 什么时候必须调用工具
  2. 什么时候禁止调用工具
  3. 一次最多调用几步
  4. 工具失败怎么兜底

6.3 L4：系统级 Agent 的重点是状态与治理

到了 L4，问题就不再只是“模型能不能做”，而是：

  1. 多角色如何协作
  2. 状态如何共享
  3. 子任务如何回收
  4. 出错如何中断
  5. 风险动作如何审批

这已经非常接近分布式系统思维了。

你会开始认真面对这些工程问题：

  1. 幂等性
  2. 可恢复性
  3. 可观测性
  4. 权限隔离
  5. 人机协同

7. 一个实战案例：做一个“研究报告 Agent”

下面给一个更实用的案例思路。目标是：

  1. 输入一个主题
  2. 自动调研
  3. 归纳观点
  4. 输出报告草稿

7.1 L2 做法

L2 会这么做：

  1. 固定先检索
  2. 固定再抽取要点
  3. 固定再汇总成报告

优点：

  1. 稳定
  2. 易调试

缺点：

  1. 遇到复杂问题不够灵活

7.2 L3 做法

L3 会这么做：

  1. Agent 自己判断要不要继续搜索
  2. 判断还缺什么信息
  3. 决定是否调用第二个工具

优点：

  1. 更灵活
  2. 更接近“助理”

缺点：

  1. 不稳定因素明显增加

7.3 L4 做法

L4 会这么做：

  1. Planner 先拆任务
  2. Researcher 去找资料
  3. Writer 写草稿
  4. Reviewer 审核逻辑
  5. 必要时人工确认

优点：

  1. 更适合复杂长任务

缺点：

  1. 系统复杂度大幅上升

所以真正落地时，不是“越高级越好”，而是“问题配什么形态最合适”。

8. OpenClaw 为什么会火

这里我把 OpenClaw 看成最近一类很有代表性的 computer-use / self-hosted agent 方向。

它之所以让很多人兴奋，不只是因为“它也是 Agent”，而是因为它把 Agent 往前推进了一步：

  1. 从聊天框里的建议，走向真实操作
  2. 从一次性调用，走向长期驻留
  3. 从单轮任务，走向持续自动化
  4. 从纯文本工具，走向浏览器、系统、消息入口和调度系统

也就是说，OpenClaw 类产品更像“一个运行在你电脑或环境里的行动型代理”。

这和传统 LangChain Agent 的差别，大致在于：

8.1 传统 LangChain Agent 更像应用内 Agent

典型特征：

  1. 嵌在某个业务系统里
  2. 为某个具体场景服务
  3. 工具边界较清晰
  4. 生命周期相对短

8.2 OpenClaw 类系统更像个人自动化操作层

典型特征：

  1. 常驻
  2. 跨应用
  3. 有浏览器和系统操作能力
  4. 有持续任务与记忆
  5. 更强调“替用户执行”

所以它们不是简单替代关系，更像是两个层面：

  1. LangChain / LangGraph 更适合搭建应用内智能流程
  2. OpenClaw 更像把 Agent 推向个人操作系统与自动化平台

9. LangChain 体系能从 OpenClaw 学到什么

虽然两者定位不同，但 OpenClaw 这类系统给我们很多启发。

9.1 Agent 不只是推理，还要有执行面

过去很多 Agent 项目停留在“会说”，而真正有价值的是“能做事”。

9.2 工具不是越多越好，而是要有控制平面

浏览器、文件系统、消息、任务调度，这些能力一旦进入系统，就不能只靠 Prompt 约束，必须有权限管理和隔离机制。

9.3 长期运行能力会改变 Agent 设计

一次性会话和持续运行代理是两种完全不同的工程问题。

9.4 记忆真正重要的是可治理

长期记忆如果没有分类、清理和权限控制，很快就会变成噪声与风险源。

10. 如果让我今天做一个可上线的 LangChain Agent，我会这样选型

适合直接用 LangChain 链的场景

  1. 信息抽取
  2. 问答生成
  3. 摘要改写
  4. 固定流程 RAG

适合 LangChain + Tool Agent 的场景

  1. 研究助理
  2. 数据查询助理
  3. 多工具分析助手

更适合 LangGraph 的场景

  1. 多步骤复杂任务
  2. 有状态工作流
  3. 需要人工审批
  4. 需要多 Agent 协作

更接近 OpenClaw 思路的场景

  1. 跨应用自动化
  2. 浏览器操作代理
  3. 长期驻留型个人助理
  4. 自托管、强调本地控制的自动化系统

11. 开发 Agent 时最容易忽略的五件事

11.1 工具描述本身就是产品设计

Tool description 写得模糊，模型就很容易乱用工具。

11.2 不要把所有问题交给模型规划

能由程序写死的约束，就别全部交给模型临场发挥。

11.3 把失败当常态

Agent 一定会失败，关键是失败后能不能被看到、被重试、被人工接管。

11.4 观测能力比 Demo 能力更重要

一个能跑十次成功八次但无法定位问题的 Agent，实际上远不如一个成功率稍低但链路清晰的系统。

11.5 安全设计必须前置

只要涉及：

  1. 发消息
  2. 发邮件
  3. 操作网页
  4. 执行命令
  5. 调业务接口

就必须考虑权限、审批、白名单和审计。

12. 小结

这一篇真正想说明的，不是“怎么把 Agent 写出来”，而是“怎么分清不同层级 Agent 的问题本质”。

如果做个总结，我会这么说：

  1. L2 的关键是把工作流写稳
  2. L3 的关键是把工具调用管住
  3. L4 的关键是把状态、协作和治理做好
  4. OpenClaw 代表的是 Agent 从应用能力走向持续执行能力的一条更激进路线

所以，今天聊 LangChain Agent，不能只盯着几行 API。真正的难点已经不再只是“模型怎么调”，而是：

  1. 任务怎么拆
  2. 状态怎么管
  3. 工具怎么控
  4. 风险怎么兜

如果只想快速起步，我的建议是：

  1. 先做一个 L2 工作流
  2. 再做一个单 Agent 工具调用版本
  3. 最后再上 LangGraph 或更复杂的系统设计

这样一路走下来，你会真正明白 Agent 不是一个 Demo 名词，而是一套要和工程现实正面碰撞的系统能力。