[LangChain Agent] 01 大模型为什么需要 Agent：create_agent 与一次天气问答

一、本篇要解决什么问题

上一套专栏把 RAG 走通了：私有文档切块、向量化、检索，再塞进提示词让大模型回答。检索解决的是「模型没看过你的资料」。

真正上线之后，还会撞上另一类需求：用户不是只要一段文字，而是要查一下现在的天气、读一下股价、算一个 BMI。这些信息不在知识库里，也不该写死在 Prompt 里，它们来自函数、接口、数据库。

本篇只把第一块地基打实：

Agent（智能体）是什么、为什么 RAG 不够、create_agent 怎么用三个参数跑通一次天气问答。

1.1 学习目标

1.2 一句公式

Agent = LLM（大脑）+ Tools（手）+ 循环（先想再做再看）

RAG 是「先找资料再生成」。Agent 是「先判断要不要动手，动手后再根据结果说话」。

二、从 RAG 到 Agent

2.1 RAG 已经解决了什么

这些能力仍然有用。后面做 Agent 时，检索本身也可以变成其中一把工具，而不是唯一通路。

2.2 RAG 还做不到什么

用户问「明天深圳的天气如何」，向量库里通常没有明天的预报。你就算把去年的气象说明检索出来，模型也只能复述旧文本，不能去调天气接口。

再极端一点：用户说「帮我算 BMI」。检索能翻到公式，但当前身高体重不在文档里，必须调用业务函数。

所以：

• RAG：给模型看资料

• Agent：给模型一双手，让它自己决定何时伸手

2.3 三种形态对比

课件代码把 Agent 的第一课压到 20 多行：不问框架史，先让模型真的去调一个函数。

三、Agent 标准工作流

一次带工具的问答，底层不是「模型直接把天气说出来」，而是一张很短的循环：

用户消息
│
▼
┌─────────────┐
│ LLM 思考 │ 要不要用工具？用哪一个？参数是什么？
└──────┬──────┘
│ 需要工具
▼
┌─────────────┐
│ 执行 Tool │ 跑你写的 Python 函数
└──────┬──────┘
│ 观察结果
▼
┌─────────────┐
│ LLM 再思考 │ 拿工具返回值组织最终回答
└─────────────┘

LangChain 1.x 把这张循环收进一个入口：create_agent。你不再手写「先 bind_tools、再解析 tool_calls、再拼 ToolMessage」那一长串样板，只要交出大脑、工具清单、人设。

3.1 三件套

少任何一件都会变味：没有工具，它只是聊天模型；没有系统提示，它仍能跑，但风格和约束全靠默认；没有足够强的模型，它甚至不会发出合法的工具调用。

3.2 循环什么时候停

模型某一轮决定不再调用工具，只产出对用户的自然语言，循环就结束。invoke 会把整段轨迹装进 res["messages"]，从头到尾都能回放。

四、create_agent 初体验

对照文件：P5_Agent智能体/01Agent智能体初体验.py。

4.1 导入与模型

from langchain.agents import create_agent
from langchain_community.chat_models.tongyi import ChatTongyi
from langchain_core.tools import tool

三行各管一层：

• create_agent：组装智能体（LangChain 1.x 的标准入口）

• ChatTongyi：通义千问聊天模型，和 RAG 专栏用的是同一套社区集成

• tool：把普通函数登记成模型能「看见」的工具

大脑这一行，注释写得很直白：

model=ChatTongyi(model="qwen3-max"), # 智能体的大脑LLM

qwen3-max 要能稳定产出 tool call。教学环境沿用阿里云密钥即可，和前面调用通义千问的方式一致。

4.2 用 @tool 声明工具

@tool(description="查询天气")
def get_weather() -> str:
return "晴天"

这里有三个值得盯住的细节。

4.2.1 description 是给模型看的说明书

模型看不见函数体，只看见名字和描述。description="查询天气" 决定了它会不会在「明天深圳的天气如何」这种问题上伸手。描述写糊了，模型可能直接瞎编天气，工具就成了摆设。

4.2.2 返回值会被当成「观察」

函数返回 "晴天"，下一轮模型看到的不是你的 Python 变量，而是一条工具消息：天气工具说，结果是晴天。最终回答是模型根据这条观察组织出来的，不是 return 直接打印给用户。

4.2.3 本课工具故意没有城市参数

get_weather() 不接收城市，也不查真实接口，永远返回「晴天」。这是教学桩，用来证明：模型会不会调用工具，而不是证明气象 API 怎么签。

4.3 组装智能体

agent = create_agent(
model=ChatTongyi(model="qwen3-max"), # 智能体的大脑LLM
tools=[get_weather], # 向智能体提供工具列表
system_prompt="你是一个聊天助手，可以回答用户问题。",
)

tools 必须是列表。哪怕只有一把工具，也要写成 [get_weather]。后面股价、BMI 都是往这个列表里加函数，组装方式不变。

system_prompt 本课写得很松。第 02、03 篇会把它收紧：先要求「告知思考过程」，再要求「严格 ReAct、每轮只调一个工具」。同一套 create_agent，纪律全写在这句话里。

4.4 invoke 一次天气问答

res = agent.invoke(
{
"messages": [
{"role": "user", "content": "明天深圳的天气如何？"},
]
}
)

调用约定：

和 RAG 专栏里 model.invoke("你好") 不同：Agent 的输入输出都以 messages 为中心。后面 stream、中间件读的都是这份状态。

五、返回值里的消息链路

5.1 为什么要遍历 messages

for msg in res["messages"]:
print(type(msg).__name__, msg.content)

res 不是一句最终答案，而是整段对话轨迹。只打印最后一个 content，你只能看到「明天深圳晴天，适合……」，看不到中间到底调没调工具。

课程选择打印 type(msg).__name__ 和 msg.content，就是为了把类型和正文并排出来：哪一条是人说的，哪一条是模型说的，哪一条是工具回的。

5.2 一次典型轨迹

用户问天气且模型选择用工具时，messages 通常长这样：

读代码时可以按这句话记：

人提问 → 模型申请工具 → 工具回观察 → 模型给结论。

第 2 条 AIMessage 的 content 经常是空的，信息在 tool_calls 里。所以第 02 篇会专门判断 latest_message.tool_calls，否则你会误以为「模型没说话」。

5.3 和直接 chat 的差别

如果把同一句「明天深圳的天气如何」丢给裸的 ChatTongyi.invoke，模型会根据训练数据编一段预报，不会执行你的 return "晴天"。

加上 Agent 之后，「晴天」这两个字来自你的函数。模型负责的是：识别这是天气问题、选出 get_weather、把工具结果说成人话。责任切开了：

• 工具：提供事实（本课是桩数据）

• 模型：决定何时调用、如何措辞

这就是智能体相对「会聊天的模型」真正多出来的那一层。

六、本篇小结