你在调试 LangChain Agent 时很容易看到这样的代码result agent.invoke({ messages: [ {role: system, content: 你是一个天气预报员}, {role: user, content: 北京天气怎么样} ]})print(result[messages])然后打印出来的并不是一句简单的回答而是一长串SystemMessage(...) HumanMessage(...)AIMessage(...)ToolMessage(...)AIMessage(...)  第一次看到这里最容易产生两个疑问 为什么一次提问会返回这么多消息 这些 SystemMessage、HumanMessage、ToolMessage、AIMessage 到底分别代表什么 其实只要先抓住一条主线就很好理解 plaintext 用户输入 ↓模型决策 ↓如果需要工具发起 tool call ↓工具执行 ↓工具结果返回模型 ↓模型继续决策或生成最终回答LangChain 的 messages本质上就是在记录这条执行链路。先搞清楚result[“messages”] 是什么在当前 LangChain Agent 中Agent 会维护一个 AgentState。其中最核心的内置字段就是AgentState└── messages # 当前线程中的消息历史类型为 list[BaseMessage]也就是说result agent.invoke(...)拿到的 result 通常不是“模型的一句话回答”而是 Agent 执行结束后的状态。而result[messages]才是这次 Agent 执行过程中积累下来的消息序列。可以简单理解成result│├── messages # 消息历史├── structured_response # 如果配置了结构化输出可能存在└── 其他自定义 State 字段所以以后看到result[messages][-1].content它的意思就是取当前消息历史里的最后一条消息。在大多数普通 Agent 场景中最后一条通常就是模型最终生成的 AIMessage。BaseMessage所有消息的共同父类SystemMessage、HumanMessage、AIMessage、ToolMessage 都继承自 BaseMessage。因此它们会共享一批基础字段。按照当前 LangChain 的消息结构可以重点理解成BaseMessage│├── content # 消息原始内容可以是文本也可以是内容块列表├── additional_kwargs # 模型供应商或扩展数据├── response_metadata # 响应元数据如模型名、finish_reason、headers 等├── name # 可选的人类可读名称├── id # 消息唯一 ID├── type # 消息类型如 human / ai / tool / system├── content_blocks # 标准化后的内容块例如文本、图片、文件、推理块等└── text # 从消息内容中提取出的文本视图  这里最需要记住的是 content 是消息主体其他字段更多是在描述“这条消息是什么、从哪里来、还带了什么额外信息”。 --- SystemMessage告诉模型“应该怎么工作” -------------------------- SystemMessage 主要负责给模型提供系统级规则。 例如 plaintext from langchain_core.messages import SystemMessageSystemMessage( content你是一个天气助手回答要简洁准确。)它表达的是SystemMessage│├── content # 系统提示词、规则、角色、行为约束├── additional_kwargs # 扩展字段├── response_metadata # 响应元数据├── name # 可选名称├── id # 消息 ID└── type system # 固定类型在普通聊天模型调用中系统消息通常位于消息序列前面SystemMessage ↓HumanMessage ↓AIMessageHumanMessage用户输入HumanMessage 最简单。它就是用户发送给模型的消息。例如from langchain_core.messages import HumanMessageHumanMessage(content北京天气怎么样)核心字段可以理解成HumanMessage│├── content # 用户输入├── additional_kwargs # 额外扩展数据├── response_metadata # 响应元数据普通输入消息通常没有重要内容├── name # 用户或发送者名称可选├── id # 消息唯一 ID└── type human # 固定类型当你这样调用 Agentagent.invoke({ messages: [ {role: user, content: 北京天气怎么样} ]})LangChain 会把这种标准消息格式转换成对应的消息对象。也就是可以把它理解成{role: user, content: 北京天气怎么样} ↓HumanMessage(content北京天气怎么样)AIMessage最重要的一种消息AIMessage 不只是“AI 回答了什么”。在 Agent 场景中它还有一个更重要的作用记录模型这一轮做出的决策。模型这一轮可能有两种典型行为。情况一直接回答比如用户问1 1 等于多少模型不需要调用工具。那么可能直接产生AIMessage└── content 2情况二模型决定调用工具比如用户问北京天气怎么样Agent 有一个天气工具。模型可能不会立刻给最终答案而是返回AIMessage│├── content └── tool_calls └── get_weather(city北京)所以在 Agent 里AIMessage 既可以表示最终回答也可以表示“我要调用哪个工具”的中间决策。AIMessage 里有哪些重要字段可以重点记住下面这些AIMessage│├── content # 模型输出正文├── additional_kwargs # 模型供应商原始扩展字段├── response_metadata # 模型名、finish_reason、响应头等├── name # Agent 名称可选例如 Alice / Bob├── id # 消息唯一 ID├── type ai # 固定类型├── tool_calls # 已成功解析的工具调用├── invalid_tool_calls # 解析失败或格式异常的工具调用└── usage_metadata # LangChain 标准化后的 Token 使用统计这里真正和 Agent 执行关系最大的是tool_callstool_calls 里面又有什么假设模型决定调用get_weather(city北京)对应的 tool_calls 大致可以理解成[ { name: get_weather, args: { city: 北京 }, id: call_123, type: tool_call }]字段关系是tool_calls└── ToolCall ├── name # 要调用哪个工具 ├── args # 传给工具的参数 ├── id # 这一次工具调用的唯一标识 └── type # tool_call所以AIMessage.tool_calls真正表达的是模型认为下一步应该执行哪些工具以及分别传什么参数。这一步非常关键。模型本身并没有执行工具。它只是生成了一个“工具调用请求”。真正执行工具是 Agent 框架后面的工具执行节点完成的。ToolMessage把工具执行结果重新交给模型假设模型刚刚产生AIMessage└── tool_calls └── id call_123 name get_weather args {city: 北京}Agent 框架看到这个 tool call 后就会真正执行get_weather(city北京)假设工具返回北京今天晴25°CLangChain 会把这个结果包装成ToolMessage│├── content 北京今天晴25°C└── tool_call_id call_123然后再交回给模型。模型看到工具结果后才继续生成最终回答。一次完整工具调用messages 是怎么变化的现在把整个流程串起来。假设用户输入北京天气怎么样Agent 有一个get_weather工具。一次典型执行过程就是HumanMessage用户北京天气怎么样 ↓AIMessage模型我要调用 get_weathertool_calls [ { name: get_weather, args: {city: 北京}, id: call_123 }] ↓ToolMessage工具北京今天晴25°Ctool_call_id call_123 ↓AIMessage模型北京今天晴气温约 25°C。也就是说result[“messages”] 最终可能类似[ HumanMessage(...), AIMessage(tool_calls[...]), ToolMessage(...), AIMessage(...)]这就是最典型的 Agent 消息链路。用一棵树把四种消息理清楚如果只看最常用字段可以整理成下面这样BaseMessage│├── content # 消息主体内容├── additional_kwargs # 扩展数据├── response_metadata # 响应元数据├── name # 可选名称├── id # 消息唯一 ID├── type # 消息类型├── content_blocks # 标准化内容块│├── SystemMessage # 系统规则│ ├── content # 系统提示词、角色、规则、行为约束│ └── type system # 固定类型│├── HumanMessage # 用户消息│ ├── content # 用户输入│ └── type human # 固定类型│├── AIMessage # 模型输出 / 模型决策│ ├── content # 模型正文│ ├── tool_calls # 成功解析的工具调用请求│ │ └── ToolCall│ │ ├── name # 工具名称│ │ ├── args # 工具参数│ │ ├── id # 工具调用 ID│ │ └── type # tool_call│ ├── invalid_tool_calls # 无效或解析失败的工具调用│ ├── usage_metadata # 标准化 Token 使用统计│ └── type ai # 固定类型│└── ToolMessage # 工具执行结果 ├── content # 返回给模型的工具结果 ├── tool_call_id # 对应 AIMessage 中的 ToolCall.id ├── artifact # 完整附加工具结果 ├── status # success / error └── type tool # 固定类型刚开始学习 Agent其实先把这棵树记住就够了。如果你已经能看到一串 messages并快速判断“哪条是用户输入、哪条是模型工具调用、哪条是工具结果、哪条是最终回答”那 Agent 最核心的执行轨迹就已经看懂了。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】