AI Agent 是什么？一篇文章讲透概念、组成与 LangChain 实战

AI-智能

214人浏览 · 2026-07-30 21:36:18

AI-智能 · 2026-07-30 21:36:18 发布

读完需：12 分钟 | 面向：有 1 年以上开发经验、懂 LLM 基本概念的同学

引言

用 ChatGPT 查资料，每一步都得自己打字告诉它该干啥。但 Cursor、Claude 这些同样基于 LLM 的工具，却能自己拆需求、读写文件、跑命令、看报错修 bug——你全程只需要看着。差在哪？

因为后者是一个 Agent。

可以这样理解：ChatGPT 是一个"被关在房间里的天才"——能思考，但出不了门。Agent 就是给这个天才装上了眼睛、双手、笔记本和日程表。它能感知周围、制定计划、调用工具、记住聊到哪了，然后自己把事情干完。

用一句话概括：Agent = LLM + Planning + Memory + Tool Use。

下面从概念到组成再到实战，把 Agent 的完整图景拆开讲清楚。读完之后你会明白，Agent 不是什么黑魔法，而是一套你今天就能上手的工程设计。

一、什么是 AI Agent？

1.1 从 LLM 到 Agent

LLM 的本质是一个函数：文本进去，文本出来。能写诗、能翻译、能回答复杂问题——但有个致命局限：只能想，不能做。它不知道今天天气怎么样，发不了邮件，也查不了数据库。每次对话一结束，它就全忘了。

Agent 解决的正是这些限制。它把 LLM 当作认知中枢（大脑），在外面包了一层基础设施，让模型能：

感知环境：读取当前状态、用户输入、工具返回的结果
制定计划：把"帮我订一张去北京的机票"拆成查航班、比价、填信息、付款
调用工具：通过 API 查航班、调支付接口、写数据库
记住上下文：知道你是谁、之前聊了什么、上次订票选了靠窗

下面是 LLM 和 Agent 的核心差异，一眼看懂：

┌─ LLM（传统对话模型）─────────────┐
│                                    │
│  用户输入 ──→ LLM 推理 ──→ 文本输出   │
│                                    │
│  单次线性管道，无记忆，无行动能力         │
└────────────────────────────────────┘

┌─ AI Agent（智能体）────────────────────────────────────┐
│                                                          │
│                      ┌─→ 规划模块 ──→ 工具调用 ──→ 外部世界 │
│                      │                    ↑              │
│  用户输入 ──→ LLM 认知中枢 ────────────────┘              │
│                  ↑   ↓                                  │
│                  │   └──→ 记忆存储 ←── 观察结果              │
│                  └─────────────────────┘                 │
│                                                          │
│  感知 → 思考 → 行动 → 记忆，闭环系统                         │
└──────────────────────────────────────────────────────────┘

LLM 像单次输入输出的直管道，Agent 是一个感知-思考-行动-记忆的闭环系统。

LangChain 2026 年提出了一个更精炼的说法：Agent = Model + Harness。Harness 就是连接模型和真实世界的脚手架，负责每一步给模型喂正确的上下文——工具返回的结果、历史对话、记忆里的信息。说白了，Agent 就是"让模型在一个循环里调用工具，直到任务搞完"。

1.2 Agent 的四个特征

特征	啥意思	举个栗子
自主性	自己决策，不用人一步步教	收到需求后自己拆任务，不等你喊下一步
感知能力	能理解输入和反馈	API 报错了能解析错误信息
行动能力	调用工具改变外部状态	读写文件、调 API、执行代码
适应性	根据反馈调整策略	API 挂了换备用方案，重试 3 次还不行就转人工

啥时候用 Agent？

任务需要多步推理且步骤有依赖（比如"分析这个 CSV 然后生成可视化报告"）

需要动态决策（客户对话里根据情绪换策略）

需要结合实时信息（“查北京明天天气，下雨提醒我带伞”）

啥时候别用？翻译一段文字、写周报、简单问答——普通 LLM 调用就够了。Agent 的多轮调用和工具路由会让简单任务变慢变贵，不值当。

二、Agent 的核心组件

这是最关键的章节。四个组件不是各干各的，而是一个有机协作的系统。下面逐个拆。

2.1 LLM——认知中枢（大脑）

干啥的：负责推理、意图识别、决策。Agent 的"调度中心"，所有组件围着它转。

没它行吗：不行。没有 LLM，系统就只能按 if-else 规则跑——用户说 A 就调接口 B。有了 LLM，系统能理解"帮我订个便宜的"背后的意思（要查几个平台比价、可能想用优惠券、甚至能接受红眼航班），然后自己规划路径。

怎么增强：

手段	啥时候用	效果
微调（Fine-tuning）	需要模型懂特定领域的术语	比如医疗问诊
RAG	需要访问私有或实时知识库	企业客服知识库
思维链（CoT）	多步推理任务	数学题、逻辑分析

# LLM 在 Agent 里的角色：接收上下文，输出决策
from langchain.chat_models import init_chat_model

# 初始化模型——Agent 的"大脑"
model = init_chat_model(
    "anthropic:claude-sonnet-4-5",
    temperature=0.3  # Agent 场景用低温度，决策更稳
)

2.2 Planning——规划模块（策略）

干啥的：把复杂目标拆成可执行的子任务，一边执行一边根据反馈调整。

没它行吗：没有规划，Agent 面对"帮我分析这三个季度的销售数据，找出下滑原因"直接傻眼——得先加载数据、做同比环比、定位异常月份、关联外部因素、最后写报告。规划模块就是帮它自动画出这条路径。

三种模式对比：

模式① 无反馈规划
  制定完整计划 ──→ 顺序执行 ──→ 输出结果
  适合：步骤固定的流程（如订单状态查询）

模式② 带反馈规划
  制定初始计划 ──→ 执行一步 ──→ 结果对吗？
                          ├─ 对 → 继续下一步
                          └─ 不对 → 修正计划 → 重新执行
  适合：需要动态调整的任务（如客户投诉处理）

模式③ ReAct 循环
  思考(Thought) ──→ 行动(Action) ──→ 观察(Observation)
        ↑                                      │
        └──────────────────────────────────────┘
  适合：大多数 Agent 的默认起点

选型指南：流程固定选无反馈；需要纠偏选带反馈；不确定选 ReAct。ReAct 超过 10-15 步还搞不定，就升级到带反馈规划。

2.3 Memory——记忆系统（经验）

干啥的：让 Agent 拥有跨会话的记忆——从"每次都是陌生人"变成"老朋友"。

没它行吗：LLM 天生无状态，每次调用都是独立的。不记得上一轮说了啥，更别说上周的偏好。没有记忆，Agent 就是个只有 7 秒记忆的天才。

记忆架构全景：

┌─ 短期记忆 ────────────────────┐
│  当前会话上下文                    │
│  存放：Redis / 内存               │
│  有效期：~30 分钟                 │
└──────────┬────────────────────┘
           │ 重要信息沉淀
           ↓
┌─ 长期记忆 ────────────────────────────────┐
│                                            │
│  ┌─ 情景记忆 ─┐  ┌─ 语义记忆 ─┐            │
│  │ 事件+时序    │  │ 向量数据库    │            │
│  │ 上次聊了啥   │  │ 用户偏好/知识  │            │
│  └───────────┘  └────────────┘            │
│         │              │                   │
│         └──────┬───────┘                   │
│                ↓                           │
│  ┌─ 记忆整合（Dreaming 管道）─┐              │
│  │ 空闲时后台整理、去重、构建知识图谱    │              │
│  └────────────────────────────┘              │
└────────────────────────────────────────────┘

三种记忆类型：

类型	放哪	活多久	干嘛用
短期记忆	上下文 / Redis	当前会话（~30 分钟）	记住这轮聊了啥
长期-情景记忆	向量数据库	永久	“上次用户让我查的是纽约天气”
长期-语义记忆	向量库/知识图谱	永久	用户偏好、常见问答、业务知识

Red Hat 2026 年提了个有趣的概念——"Dreaming"管道：Agent 空闲时在后台整理记忆、检测矛盾、构建知识图谱，就像人睡觉时大脑在整理白天的记忆。这还是个前沿方向，但思路很妙。

工程参考：Redis 存短期会话（30 分钟过期） + 向量数据库（Pinecone / Milvus）存长期知识 + 定期把知识蒸馏成规则来减少检索成本。

啥时候加记忆？单次独立任务（翻译）不需要；多轮对话（客服）加短期；个性化服务（私人助理）加长期。注意：检索记忆要消耗 token，先想清楚 Agent 到底需要"记得"什么，别一股脑全存。

2.4 Tool Use——工具调用（手脚）

干啥的：Agent 和外部世界打交道的通道。API 调用、搜索引擎、计算器、代码执行器、数据库查询——只要能让 Agent 获取信息或产生效果，都算工具。

没它行吗：没有工具，Agent 只能空想。不知道今天天气、不会做精确计算、查不了数据库。工具让它从"一个会说话的模型"变成"一个能干活的助手"。

底层原理：Function Calling。LLM 输出结构化的 JSON，描述要调哪个函数、传什么参数，Harness 层负责实际执行，结果再喂回模型。

from langchain_core.tools import tool
from pydantic import BaseModel, Field

# 工具一：查天气
@tool
def get_weather(city: str) -> str:
    """查询指定城市的实时天气。输入城市中文名，返回温度和天气状况。"""
    weather_data = {
        "北京": "晴，32°C，湿度 45%",
        "上海": "多云，28°C，湿度 70%",
        "深圳": "雷阵雨，30°C，湿度 85%",
    }
    return weather_data.get(city, f"没找到 {city} 的天气数据")

# 工具二：计算器——LLM 做精确计算容易翻车
class CalcInput(BaseModel):
    expression: str = Field(description="数学表达式，比如 '2+3*4'")

@tool(args_schema=CalcInput)
def calculator(expression: str) -> str:
    """执行精确数学计算。输入数学表达式字符串，返回结果。"""
    try:
        import re
        if not re.match(r'^[/d/+/-/*///(/)/./s]+$', expression):
            return "错误：表达式不能有特殊字符"
        result = eval(expression)
        return f"计算结果：{result}"
    except Exception as e:
        return f"算错了：{str(e)}"

工具设计 4 条铁律：

一个工具只干一件事。别把天气和新闻揉一个函数里
描述就是给 LLM 看的说明书。描述越清楚，模型选对工具的概率越高
输入输出定义明确。用 Pydantic Schema 定义参数类型
内部要容错。工具内部捕获异常，返回友好的错误信息，不要直接抛异常

啥工具啥时候用？查实时信息用搜索引擎；做精确计算用计算器（LLM 做三位数乘法都不靠谱）；跑代码验证用代码执行器；查业务数据用数据库；需要标准化接口用 MCP 协议——插上就能用，跟 USB 一样方便。

2.5 四个组件怎么配合

四个组件不是排着队接力跑，而是随时交织在一起——LLM 随时查记忆、随时调工具、随时修正计划，直到任务完成。

完整协作流程（以"分析销售数据找出下滑原因"为例）：

用户："分析今年销售数据，找出下滑原因"
  │
  ├── ① LLM 理解意图
  │
  ├── ② LLM 查记忆系统
  │   └── 记忆返回：用户偏好看同比数据
  │
  ├── ③ LLM 调用规划模块
  │   └── 规划输出：步骤1加数据 → 步骤2同比分析 → 步骤3定位异常 → 步骤4生成报告
  │
  ├── ④ LLM 调用工具（数据库查询）
  │   └── 工具返回：Q1-Q3 销售数据
  │
  ├── ⑤ LLM 分析数据，发现 Q2 下滑 15%
  │
  ├── ⑥ LLM 调用工具（搜索引擎）
  │   └── 工具返回：Q2 行业政策变化
  │
  ├── ⑦ LLM 把分析结果存回记忆系统
  │
  └── ⑧ LLM 输出：完整下滑原因分析报告

每一步 LLM 都在决策"下一步该干啥"，而不是机械地走流程。这就是 Agent 和传统工作流的本质区别。

三、常见 Agent 设计模式

模型调工具的循环长得不一样，就形成了不同的设计模式。以下是业内公认的 7 种：

模式	核心思路	一句话判断
ReAct	想→干→看，循环	默认起点，适合大多数
Reflexion	自我批评 + 迭代改进	有明确对错的任务（写代码、算数学）
Plan-and-Solve	先定完整计划再执行	20 步以上的复杂任务
Tree of Thoughts	树结构探索多条路径	谜题、搜索类推理
Evaluator-Optimizer	生成→打分→优化，反复	有明确质量标准的内容创作
Orchestrator-Workers	中央调度 + 工蚁干活	多步骤多领域协作
Prompt-Chaining	按顺序串起多个专用任务	步骤确定、有顺序依赖

一句话选型：

简单任务 =ReAct，别过度设计
超过 15-20 步的复杂任务 =Plan-and-Solve，ReAct 在长链里容易迷路
需要多个专业能力协作 =Orchestrator-Workers，比如一个写代码一个写文档一个跑测试
输出质量能量化评估 =Evaluator-Optimizer，比如生成翻译后让另一个模型打分

Anthropic 的建议：从最简单的开始。别一上来就搭多 Agent 架构，先用 Solo Agent + ReAct 跑通，看瓶颈在哪里再往上加。

四、用 LangChain 5 分钟搭一个 Agent

理论讲差不多了，上手写个能跑的。我们用 LangChain 2026 年主推的create_agent() API，做一个能查天气、能算数的助手。

环境准备

pip install langchain langchain-core langchain-community

定义工具

把前面写的天气和计算器搬过来，再加一个读文件的。

from langchain_core.tools import tool
from pydantic import BaseModel, Field

# ---- 工具定义 ----

@tool
def get_weather(city: str) -> str:
    """查询指定城市的实时天气。输入城市中文名，返回温度和天气状况。"""
    weather_data = {
        "北京": "晴，32°C，湿度 45%",
        "上海": "多云，28°C，湿度 70%",
        "深圳": "雷阵雨，30°C，湿度 85%",
    }
    return weather_data.get(city, f"没找到 {city} 的天气数据")

class CalcInput(BaseModel):
    expression: str = Field(description="数学表达式，比如 '2+3*4'")

@tool(args_schema=CalcInput)
def calculator(expression: str) -> str:
    """执行精确数学计算。输入数学表达式字符串，返回结果。"""
    import re
    if not re.match(r'^[/d/+/-/*///(/)/./s]+$', expression):
        return "错误：表达式包含不允许的字符"
    try:
        result = eval(expression)
        return f"计算结果：{result}"
    except Exception as e:
        return f"算错了：{str(e)}"

@tool
def read_file(filename: str) -> str:
    """读取本地文件。输入文件名，返回文件内容。"""
    try:
        with open(filename, "r", encoding="utf-8") as f:
            return f.read()
    except FileNotFoundError:
        return f"错误：文件 '{filename}' 不存在"
    except Exception as e:
        return f"读文件出错了：{str(e)}"

# 工具清单——Agent 会根据描述自动选对的工具
tools = [get_weather, calculator, read_file]

创建 Agent

from langchain.agents import create_agent
from langchain.chat_models import init_chat_model

# 1. 初始化模型——Agent 的"大脑"
model = init_chat_model(
    "anthropic:claude-sonnet-4-5",
    temperature=0.3,
)

# 2. 系统提示词——定义 Agent 的行为边界
system_prompt = """你是一个有用的助手，可以：
- 查询城市天气
- 执行数学计算
- 读取本地文件

用工具之前先想一想：这个任务真的需要工具吗？一步步推理，用中文回答。"""

# 3. 创建 Agent——一行代码搞定
agent = create_agent(
    model=model,
    tools=tools,
    system_prompt=system_prompt,
)

跑起来看看

# 执行 Agent，观察 ReAct 循环
result = agent.invoke({
    "messages": [
        {
            "role": "user",
            "content": "北京和上海今天哪个城市更热？温差是多少？"
        }
    ]
})

# 打印完整的对话历史
for msg in result["messages"]:
    if hasattr(msg, "content") and msg.content:
        print(f"[{msg.type}] {msg.content}")

实际运行时，你会看到这样的 ReAct 轨迹：

[human] 北京和上海今天哪个城市更热？温差是多少？

[ai]  Thought: 用户想比较两地的温度，得先查数据。
[ai]  Action: get_weather({"city": "北京"})

[tool] 晴，32°C，湿度 45%

[ai]  Thought: 北京 32°C。再看看上海。
[ai]  Action: get_weather({"city": "上海"})

[tool] 多云，28°C，湿度 70%

[ai]  Thought: 北京 32°C，上海 28°C，差了 4°C。算一下确认。
[ai]  Action: calculator({"expression": "32-28"})

[tool] 计算结果：4

[ai]  北京今天更热，32°C vs 上海 28°C，温差 4°C。
      北京湿度也更低（45% vs 70%），体感会更干爽。

代码和理论对号入座

回头看前面的理论，这段代码怎么对应的：

组件	代码里的体现
LLM（大脑）	`init_chat_model("anthropic:claude-sonnet-4-5")`
Planning（规划）	`create_agent()` 内部自动实现了 ReAct 循环
Memory（记忆）	这版还没加。加个`checkpointer=MemorySaver()` 就能跨轮对话
Tool Use（工具）	`@tool` 装饰器定义的三个工具

一个完整的生产级 Agent 还得加 checkpointer（持久化记忆）和 middleware（日志、重试、人工审批），但核心骨架就是这么几行。

五、避坑指南

问题	原因	解法
Agent 死循环反复调工具	工具返回格式不规范，LLM 不知道任务已完成	返回里加状态标识；设`recursion_limit` 硬上限
工具被错误调用	描述不清，LLM 理解错了用途	写清楚输入格式、输出类型、适用场景
简单任务也走 ReAct	Agent 对所有请求都习惯性调工具	提示词里加一句"能直接回答就别调工具"
Token 消耗爆炸	每次循环都传完整历史	加 SummarizationMiddleware 自动压缩
多步任务干一半断片了	没有持久化状态	加 checkpointer，每步自动保存