什么是 AI Agent：它与普通大模型调用有什么区别？

在上一篇文章中，我们通过LangChain框架介绍了AI Agent，也提到了对LLM的调用，那么对LLM的调用和AI Agent之间究竟有什么区别？本文则继续基于LangChain详细介绍两者的本质区别以及相应的使用场景。

先看最简单的大模型程序。

01用户输入
02   ↓
03构造 Prompt / Messages
04   ↓
05调用 LLM
06   ↓
07获得 Response
08   ↓
09程序继续执行

例如：

01from langchain.chat_models import init_chat_model
02 
03model = init_chat_model("openai:gpt-5.4")
04 
05response = model.invoke(
06    "请解释 Python 中 list 和 tuple 的主要区别。"
07)
08 
09print(response.content)

模型生成内容具有随机性，下面展示一次典型结果：

01list 和 tuple 都用于保存有序数据。
02
03主要区别是 list 可以修改，而 tuple 通常作为不可变序列使用。
04list 使用 []，tuple 通常使用 ()。

这里有两个角色。

LLM 负责：

01输入 → 推理 → 输出

应用程序负责：

01什么时候调用 LLM
02↓
03给 LLM 什么数据
04↓
05拿到结果之后做什么

也就是说，模型拥有内容生成权，但没有程序流程的控制权。

它完成的是一次推理任务。

翻译、摘要、分类、信息抽取、文本改写、生成 SQL 等大量场景，本质上都可以采用这种模式。LangChain 当前也把 Model 作为可以独立调用的基础组件，同时说明模型也可以作为 Agent 的推理引擎。

这里有一个特别容易混淆的问题：

模型可以自己选择工具，是不是就已经成为 Agent 了？

不一定。

现代模型普遍支持工具调用（Tool Calling / Function Calling）。开发者先告诉模型有哪些工具以及每个工具的参数结构，模型可以返回一个结构化的工具调用请求。

例如：

01from langchain.chat_models import init_chat_model
02from langchain.tools import tool
03 
04@tool
05def get_order_status(order_id: str) -> str:
06    """查询订单当前状态。"""
07    return f"订单 {order_id} 已发货"
08 
09model = init_chat_model("openai:gpt-5.4")
10model_with_tools = model.bind_tools([get_order_status])
11 
12response = model_with_tools.invoke(
13    "查询订单 A1024 的状态"
14)
15 
16print(response.tool_calls)

01[
02    {
03        "name": "get_order_status",
04        "args": {"order_id": "A1024"},
05        ...
06    }
07]

模型确实已经做出了一个决定：

01应该调用 get_order_status
02参数是 A1024

但这里需要注意，模型只是提出了调用请求，并没有真正执行 Python 函数。

在独立使用 Model 时，LangChain 官方文档明确说明：模型返回 Tool Call 之后，需要应用程序执行工具，再把 Tool Result 放回消息历史，然后再次调用模型。

完整过程实际上是：

01LLM
02 ↓
03我要调用 get_order_status
04 ↓
05你的 Python 程序执行工具
06 ↓
07得到工具结果
08 ↓
09你的程序重新调用 LLM
10 ↓
11LLM 生成最终答案

因此：

Tool Calling 是模型的一种能力，而 Agent 是围绕这种能力构建出来的一种执行系统。

这是理解 Agent 非常重要的一层边界。

普通 LLM 调用与 Agent 最根本的区别，可以从“控制流”来理解。

传统程序通常是：

01result_a = step_a()
02 
03if result_a:
04    result_b = step_b()
05 
06result_c = model.invoke(...)

下一步做什么，由开发者提前写进代码。

即使中间使用了 LLM，程序整体仍然是：

01开发者定义流程
02↓
03程序按照流程执行
04↓
05LLM只是其中一个节点

Agent 则引入了一种不同的运行方式：

01目标
02 ↓
03LLM判断
04 ↓
05选择Action
06 ↓
07环境执行
08 ↓
09获得Observation
10 ↓
11重新判断
12 ↓
13选择下一步Action
14 ↓
15……
16 ↓
17完成任务

LangChain 当前的 create_agent 正是围绕这个循环运行：调用模型，让模型选择工具，执行工具，然后把结果重新送入模型；当模型不再请求工具时结束。

所以，更准确地说：

普通 LLM 调用把模型放在流程里面；Agent 则让模型参与决定流程本身。

变化的不是“调用次数”，而是决策权的位置。

假设用户提出一个稍微复杂的任务：

查询订单 A1024。如果已经发货，查询物流状态；如果物流异常，再查询售后处理规则，然后告诉我应该怎么办。

传统 Workflow 可以直接写：

01查询订单
02   ↓
03判断是否发货
04   ↓
05查询物流
06   ↓
07判断是否异常
08   ↓
09查询售后规则
10   ↓
11调用 LLM 生成回答

这个方案没有任何问题。

甚至从工程角度看，这种流程往往更加可靠。

因为每一步都是开发者预先确定的：

01条件 A → 执行 B
02条件 C → 执行 D

但如果任务变成：

帮我调查为什么订单 A1024 还没有收到，并给出处理建议。

事情就变得不同。

完成这个目标可能需要：

01查订单？
02查物流？
03查仓库？
04查天气？
05查客服记录？
06查退款政策？

而且查询物流之后得到的信息，可能决定下一步是否还需要查询其他系统。

这时很难提前写出一棵完整的 if/else 决策树。

Agent 更适合处理这种情况。

它可能第一次执行：

01get_order_status("A1024")

得到：

01已发货

然后决定：

01继续查询物流

得到：

01包裹停留在上海中转站 3 天

模型发现仍然不能解释原因，于是继续：

01get_logistics_exception(...)

最后才生成回答。

这就是 Agent Loop 的意义：

下一步不是只由最初的问题决定，也由前一步执行结果决定。

LangChain 官方把 Agent 描述为动态定义自身过程和工具使用方式的系统，而 Workflow 则具有预先确定的代码路径。

如果继续向下拆，Agent 至少包含几个相互配合的部分。

Model 是推理引擎。

它读取当前上下文，然后决定：

01直接回答
02还是
03调用工具

如果调用工具，还要决定：

01调用哪个工具
02使用什么参数

工具返回以后，模型还要再次判断：

01信息够了吗？
02还需要做什么？
03是否应该结束？

因此 Model 提供的是决策能力，但 Model 本身并不是 Agent。LangChain 官方也明确把模型描述为 Agent 的 reasoning engine。

LLM 本身主要处理上下文中的信息。

Tool 则把模型连接到外部系统，例如：

01数据库
02搜索引擎
03文件系统
04浏览器
05Python
06GitHub
07企业 API
08邮件系统
09日历

工具既可以读取信息，也可能产生真实副作用，例如：

01发送邮件
02创建订单
03修改数据库
04提交代码

因此工具不是“给模型补充知识”这么简单，它实际上提供了 Agent 观察环境和作用于环境的接口。LangChain 的 Tool 也是具有明确输入、输出和描述的可调用函数。

一次普通 LLM 调用通常只关心：

01Input → Output

但 Agent 需要知道自己已经执行到了哪里。

例如：

01用户原始任务
02历史消息
03已经调用过哪些工具
04工具返回了什么
05当前有哪些中间结果
06任务是否已经完成

这些信息共同形成执行过程中的状态（State）。

如果没有状态，每次模型调用都会像重新开始一样，它无法根据之前的工具结果继续工作。

LangGraph 的 Graph API 将 State 定义为应用当前状态的共享数据结构；LangChain 的 Agent 又运行在 LangGraph Runtime 之上，因此状态和执行过程不是附加功能，而是 Agent 编排的重要基础。

Model 只负责产生决策。

Tool 只负责执行某个动作。

还需要一个 Runtime 把它们连接起来：

01调用模型
02↓
03读取 Tool Call
04↓
05执行 Tool
06↓
07更新 State
08↓
09再次调用模型
10↓
11检查是否结束

LangChain 当前的 create_agent 底层运行在 LangGraph Runtime 上。这个 Runtime 还可以承载上下文、Store、执行信息以及流式输出等能力。

因此一个更完整的 Agent 可以理解为：

01Agent
02=
03Model
04+
05Tools
06+
07State
08+
09Agent Loop
10+
11Runtime
12+
13控制规则

而不是简单的：

01Agent = LLM + Tools

后者适合作为入门记忆，前者才更接近工程实现。

理解 Agent 时，最容易犯的另一个错误，是把所有多步骤 LLM 程序都叫作 Agent。

例如：

01用户问题
02 ↓
03分类器
04 ↓
05搜索
06 ↓
07RAG
08 ↓
09LLM总结
10 ↓
11返回

这可能是一个非常完整的 AI 应用，但它并不一定是 Agent。

判断标准不是：

01有没有 LLM？
02有没有 Tool？
03步骤多不多？

而是：

执行路径主要由谁决定？

LangGraph 官方给出的区分非常直接：Workflow 的代码路径是预先确定的，而 Agent 的过程和工具使用是动态的。

因此可以形成三个层级。

01开发者决定：什么时候调用模型
02模型决定：生成什么

01开发者决定：整个执行路径
02模型负责：某些节点中的推理

01开发者决定：目标、工具、规则和边界
02模型决定：运行过程中下一步采取什么行动

这个区别比“Agent 可以调用工具”更加准确。

把控制权交给模型之后，会产生一个很直接的结果：

系统的执行路径变得不完全确定。

对于传统 Workflow：

01A → B → C → D

开发者通常知道下一步一定是什么。

对于 Agent：

01A
02↓
03LLM
04├─→ B
05├─→ C
06└─→ D

进入 B 以后，模型还可能继续选择：

01B
02├─→ E
03└─→ F

于是一次任务可能执行：

01A → B → E → Response

另一次相似任务可能执行：

01A → C → F → B → Response

这就是 Agent 可以处理开放问题的原因，也是 Agent 更难工程化的原因。

两者实际上是在做一种交换：

因此 Agent 并不是免费获得“自主性”。

它实际上完成了一次交换：

01降低部分确定性
02↓
03换取更强的运行时适应能力

这也是为什么 Agent 系统往往需要更多的可观测、重试、限流、权限、终止条件和人工介入机制。LangChain 当前通过 Middleware 提供日志、工具选择控制、重试、提前终止、Guardrails 和 Human-in-the-loop 等控制能力。

Agent 经常被描述成“自主执行任务的 AI”。

这个说法容易产生另一个误解，好像模型获得了完全自由的执行能力。

实际上，工程中的 Agent 更接近：

在开发者规定的行动空间中，由模型动态选择下一步动作。

开发者仍然决定：

01给它什么模型
02给它哪些工具
03工具具有什么权限
04能够访问什么上下文
05最多执行多少步
06什么操作需要人工确认
07发生错误如何处理
08什么时候强制停止

例如一个 Agent 只有：

01search_web
02read_file

两个工具，那么无论模型如何推理，它都不能发送邮件。

如果再增加：

01send_email

它才拥有发送邮件的行动能力。

因此 Agent 的能力边界，并不只是由模型决定，而是由：

01Model 能力
02×
03Tool 能力
04×
05Context
06×
07Runtime
08×
09Policy

共同决定。

这也是为什么 Agent 工程中经常会出现 Middleware、Guardrails、权限控制以及 Human-in-the-loop。它们并不是额外装饰，而是在动态执行过程中重新建立可控性。

实际开发中，不应该从“Agent 更先进”这个角度做选择。

更实用的判断方式，是看任务路径是否可以提前确定。

例如：

01文本 → 摘要
02文本 → 分类
03数据 → JSON
04中文 → 英文

直接调用 LLM 即可。

如果任务是：

01读取用户问题
02→ 查询知识库
03→ 把资料交给模型
04→ 生成答案

流程已经非常明确，更适合 Workflow。

即使其中调用了向量数据库、搜索 API 和 LLM，也没有必要强行做成 Agent。

但如果需求是：

调查这个项目为什么部署失败，并尽可能找到原因。

模型可能需要：

01读日志
02↓
03判断问题
04↓
05查配置
06↓
07发现依赖异常
08↓
09查 package.json
10↓
11搜索文档
12↓
13再次检查日志
14↓
15给出结论

开发者很难提前知道需要执行哪些步骤。

这种目标明确，但解决路径不明确的问题，更适合 Agent。

可以用一句简单的判断来区分：

01步骤已知 → 优先 Workflow
02
03目标已知、步骤未知 → 考虑 Agent

当然，两者并不是互斥关系。

实际生产系统经常采用混合方式：

01确定性 Workflow
02      ↓
03某个开放问题
04      ↓
05Agent
06      ↓
07返回 Workflow
08      ↓
09继续确定性处理

LangChain 的 Middleware 文档也明确支持把完整 Agent 作为节点或子图放入更大的 LangGraph 工作流中，用确定性步骤包围 Agent。

这通常比“所有事情全部交给 Agent”更加容易控制。

回到最开始的问题。

普通大模型调用、Tool Calling、Workflow 和 Agent，并不是四个完全独立的技术。

它们更像是逐步增加模型决策范围的几种系统形态：

01普通 LLM
02模型决定：说什么
03
04        ↓
05
06Tool Calling
07模型还可以决定：想调用什么工具
08
09        ↓
10
11Workflow
12模型参与多个步骤
13但整体路径仍由代码决定
14
15        ↓
16
17Agent
18模型持续根据当前状态决定：
19下一步做什么、用什么工具、是否继续

所以，AI Agent 与普通大模型调用之间最值得理解的差异，并不是“Agent 调用了更多次 LLM”，也不是“Agent 能联网、能搜索、能调用 API”。

它改变的是应用程序中的控制权分配。

普通调用中，模型是被程序调用的一个能力；Agent 中，模型进一步成为运行时的决策组件，而 Runtime 负责不断把模型决策、工具执行和状态更新组织成反馈循环。

本文可以最终把这个关系总结成一句话：

LLM 负责推理，Tool 负责行动，State 记录现场，Runtime 负责执行循环，而 Agent 让模型在这些能力之上持续决定“下一步做什么”。

这也是为什么学习 Agent 时，不必急着进入多 Agent、长期记忆或复杂规划。先真正理解一次 Model Call、一次 Tool Call 和一个 Agent Loop 之间发生了什么，后面的 LangChain、LangGraph 和 Deep Agents 才会自然衔接起来。