目錄?編輯1. 消息Messages1.1 LLM 消息結構1.2 LangChain 消息1.2.1 BaseMessage 抽象消息類1.2.2 對話模式1.3 緩存歷史消息1.3.1 多輪對話1.3.2 內存緩存1.4 管理歷史消息1.4.1 前置概念1.4.1.1 上下文窗口1.4.1.2 Token1.4.2 消息裁剪1.4.2.1 基于輸入 Token 數的修剪1.4.2.2 基于消息數的修剪1.4.3 消息過濾按類型進行篩選按類型 ID 進行篩選1.4.4 消息合并1. 消息Messages消息是聊天模型中的通信單位用于表示聊天模型的輸入和輸出以及可能與對話關聯的任何其他上下文或元數據。1.1 LLM 消息結構每條消息都有一個角色和內容以及因 LLM 的不同而不同的附加元數據。消息角色Role角色描述system系統角色用于告訴聊天模型如何行為并提供額外的上下文。并非所有聊天模型提供商都支持。user用戶角色表示用戶與模型交互的輸入通常以文本或其他交互式輸入的形式。assistant助理角色表示來自模型的響應其中可以包括文本或調用工具的請求。tool工具角色用于在檢索外部數據或將工具調用的結果傳遞回模型的消息。與支持工具調用的聊天模型一起使用。用來區分對話中不同類型的消息并幫助聊天模型了解如何響應給定的消息序列。消息內容 (Content)表示多模態數據例如圖像、音頻、視頻的消息文本或字典列表的內容。內容的具體格式可能因底層不同的 LLM 而異。目前大多數模型都支持文本作為主要內容類型對多模態數據的支持仍然有限。消息其他元數據 (Additional metadata)元數據描述ID消息標識符。Name名稱允許區分具有相同角色的不同實體。并非所有型號都支持此功能Metadata有關消息的其他信息例如時間戳、令牌使用情況等。Tool Calls模型發出的一個或多個工具的調用請求下面展示一個 OpenAI 的格式消息列表[ { role: user, content: Hello, how are you?, }, { role: assistant, content: Im doing well, thank you for asking., }, { role: user, content: Can you tell me a joke?, } ]LangChain 接受下面的格式作為聊天模型的輸入chat_model.invoke([ { role: user, content: Hello, how are you?, }, { role: assistant, content: Im doing well, thank you for asking., }, { role: user, content: Can you tell me a joke?, } ])1.2 LangChain 消息LangChain 提供了一種統一的消息格式可以跨聊天模型使用允許用戶使用不同的聊天模型而無需擔心每個模型提供商使用的消息格式的具體細節。例如openai_model init_chat_model(gpt-4o-mini, model_provideropenai) anthropic_model init_chat_model(claude-3-5-sonnet-latest, model_provideranthropic) deepseek_model init_chat_model(deepseek-chat, model_providerdeepseek) google_genai_model init_chat_model(gemini-2.5-flash, model_providergoogle_genai) model init_chat_model(...)這些模型提供商不同但對于其輸入和輸出統一使用 LangChain 的消息格式。LangChain 消息格式主要分為五種分別是消息類型對應角色描述SystemMessage對應 system 系統角色用于啟動 AI 模型的行為并提供額外的上下文例如指示模型采用特定角色或設定對話的基調例如你是一個后端開發的專家。HumanMessage對應 user 用戶角色人類消息表示用戶與模型交互的輸入。大多數聊天模型都希望用戶輸入采用文本形式。AIMessage對應 assistant 助理角色這是來自模型的響應其中可以包括文本或調用工具的請求。它還可能包括其他媒體類型如圖像、音頻或視頻 —— 盡管這目前仍然不常見。AIMessageChunk對應 assistant 助理角色用于流式響應通常在生成聊天模型時流式傳輸響應因此用戶可以實時看到響應而不是等待生成整個響應后再顯示。ToolMessage對應 tool 工具角色這表示一條角色為 tool 的消息其中包含調用工具的結果。這幾個消息類型我們已經全部見過它們都是 LangChainBaseMessage的子類全部是作為 LangChain 聊天模型的輸入和輸出。1.2.1 BaseMessage 抽象消息類class langchain_core.messages.base.BaseMessage是作為 LangChain 聊天模型的輸入和輸出參數如下content消息的字符串內容。additional_kwargs與消息關聯的其他有效負載數據。對于來自 AI 的消息可能包括模型提供程序編碼的工具調用。response_metadata響應元數據。例如響應標頭、logprobs、令牌計數、模型名稱。type消息類型。必須是消息類型唯一的字符串。此字段的目的是在對消息進行序列化時方便地識別消息類型。name消息名稱為消息提供一個人類可讀的名稱。該字段的使用是可選的是否使用它取決于模型實現。id消息的可選唯一標識符。理想情況下這應該由創建消息的提供者 / 模型提供。modelChatDeepSeek(modeldeepseek-chat) print(model.invoke(你好啊))content你好呀很高興見到你 我是DeepSeek你的AI助手。有什么我可以幫你的嗎無論是聊天、解答問題、寫作、翻譯還是其他需求盡管告訴我我會盡力幫你搞定。你今天過得怎么樣 additional_kwargs{refusal: None} response_metadata{token_usage: {completion_tokens: 50, prompt_tokens: 6, total_tokens: 56, completion_tokens_details: None, prompt_tokens_details: {audio_tokens: None, cache_write_tokens: None, cached_tokens: 0}, prompt_cache_hit_tokens: 0, prompt_cache_miss_tokens: 6}, model_provider: deepseek, model_name: deepseek-v4-flash, system_fingerprint: a26a7955944dc5c60445bff77fac9c8e, id: 526f8f0f-aaad-44d0-b390-b2160d1654f2, finish_reason: stop, logprobs: None} idlc_run--01a041fb-82f7-7e82-a124-45478c326e03-0 tool_calls[] invalid_tool_calls[] usage_metadata{input_tokens: 6, output_tokens: 50, total_tokens: 56, input_token_details: {cache_read: 0}, output_token_details: {}}內置方法pretty_print() → None打印消息的漂亮表示。pretty_repr(html: bool False) → str獲得消息的漂亮表示。請求是否將消息格式化為 HTML。如果為 True則消息將使用 HTML 標記進行格式化。默認值為 False。響應這是消息的漂亮表示。text() → str獲取消息的文本內容。aimessmodel.invoke(你好啊) aimess.pretty_print()print(aimess.text)1.2.2 對話模式大多數對話都以設置對話上下文的系統消息開始。接下來是包含用戶輸入的用戶消息然后是包含模型響應的助手消息。兩種對話流轉示意圖1.3 緩存歷史消息1.3.1 多輪對話在與大型語言模型交互的過程中我們常常體驗到與智能助手進行連貫多輪對話的便利性。但目前我們的系統還不支持此功能代碼如下modelChatDeepSeek(modeldeepseek-chat) print(model.invoke(你好啊,我的名字叫王小明).content) print(model.invoke(你知道我的名字叫什么嗎).content)這里我們可以發現雖然我們在第一段對話的時候就告訴了AI我的名字但是在第二次對話的過程中AI并不知道我們的名字。在這樣的對話方式里AI并不具有存儲歷史消息或者說記憶的功能。解決這個問題的方式就是在每次對話的過程中應該將歷史對話的上下文合并為一個消息列表然后傳遞給AI代碼如下message[ SystemMessage(你是一個人工智能助手), HumanMessage(你好啊,我的名字叫王小明), AIMessage(你好呀王小明很高興認識你。), HumanMessage(你知道我的名字叫什么嗎) ] modelChatDeepSeek(modeldeepseek-chat) print(model.invoke(message).content)可以看到當我們將歷史上下文傳遞給AI的時候就能發現它能準確地說出我們的名字了。換句話說只要將歷史消息重新發送給聊天模型那么就可以實現多輪對話的功能。1.3.2 內存緩存那么對于歷史消息的管理就顯得尤為重要。在 LangChain 老版本中可以使用RunnableWithMessageHistory消息歷史類來包裝另一個 Runnable 并為其管理聊天消息歷史記錄。它將跟蹤模型的輸入和輸出并將其存儲在某個數據存儲中。未來的交互將加載這些消息并將其作為輸入的一部分傳遞給鏈。from langchain_core.chat_history import InMemoryChatMessageHistory, BaseChatMessageHistory from langchain_core.messages import SystemMessage, HumanMessage, AIMessage from langchain_core.runnables import RunnableWithMessageHistory, configurable from langchain_deepseek import ChatDeepSeek modelChatDeepSeek(modeldeepseek-chat) store{} def Get_History_ssid(ssid:str)-BaseChatMessageHistory: if ssid not in store: store[ssid]InMemoryChatMessageHistory() return store[ssid] with_History_modelRunnableWithMessageHistory(model,Get_History_ssid) config{configurable:{session_id:1}} print(with_History_model.invoke([HumanMessage(你好我的名字叫王小明)], configconfig).content) print(with_History_model.invoke([HumanMessage(你知道我的名字嗎)], configconfig).content)class langchain_core.runnables.history.RunnableWithMessageHistory類初始化參數說明runnable被包裝 Runnable 實例這里就是我們定義的聊天模型Get_History_ssid返回類型為BaseChatMessageHistory的函數傳入后作為回調函數。此函數接受一個session_id字符串類型并返回相應的聊天消息歷史記錄實例。class langchain_core.runnables.history.RunnableWithMessageHistory類方法說明.invoke()方法此方法與其他 Runnable 實例的.invoke()方法相同。只不過注意其 config 配置需要配置成config{configurable: {session_id: }}讓RunnableWithMessageHistory可以讀取到會話 id。記憶功能已經實現但是需要注意的是從 LangChain 的 v0.3 版本開始官方建議 LangChain 用戶不要使用RunnableWithMessageHistory而是利用 LangGraph 持久性 來完成見 LangGraph 章節。原因是它們的功能有限不太適合現實世界的對話式 AI 應用程序。這些內存抽象缺乏對多用戶、多對話場景的內置支持而這對于實際的對話式人工智能系統至關重要。這些實現中的大多數已在 LangChain 0.3.x 中被正式棄用取而代之的是 LangGraph 持久性。LangGraph 持久性 非常靈活可以支持比RunnableWithMessageHistory接口更廣泛的用例。我們會在 LangGraph 篇章中學習它因此RunnableWithMessageHistory這部分我們講解的并不深入。在之前對于生產環境我們還需要使用聊天消息歷史記錄的持久化實現例如RedisChatMessageHistory()而不是InMemoryChatMessageHistory()但現在也已不推薦新應用使用它們了。1.4 管理歷史消息1.4.1 前置概念1.4.1.1 上下文窗口管理歷史消息無非就是理解如何 “管理”“管理” 無非也就是一些 “CRUD”。那么在了解如何管理消息之前需要先了解下多輪對話的核心概念上下文窗口。上下文窗口可以理解為模型的 “短期工作記憶區”即 LLM 在一次處理請求時所能查看和處理的最大 Token 數量它包含了用戶的輸入大模型的輸出有時還包括系統指令SystemMessage和對話歷史。不同大模型支持的上下文窗口大小不同例如OpenAI 下 GPT?5 模型上下文窗口為 400000最大 Token 數量GPT?4.1 模型上下文窗口為 1047576最大 Token 數量其他模型上下文窗口可參考對應模型官網說明如 OpenAI 下模型可以參考這里。1.4.1.2 Token在自然語言處理NLP中Token 是文本的基本單位。它不是完全等同于一個單詞或一個漢字而是一個更細粒度的劃分。為什么用 Token計算機無法直接理解文字它需要將文本轉換為數字向量。Tokenization令牌化就是這個轉換過程的第一步將句子分解成模型可以理解和處理的碎片。對于英文1 個 Token ~ 4 個字符或 0.75 個單詞1000 個 Tokens 約等于 750 個英文單詞。一個 Token 可以是一個單詞如apple、一個詞根如un在unlikely中或者一個標點符號如.。例如ChatGPT is great!可能會被分成[Chat, G, PT, is, great, !]這 6 個 Token。對于中文1 個漢字 1.5?2 個 Tokens1000 個 Tokens 大約相當于 500?700 個漢字。常見的詞和字可能是一個 Token生僻字或復雜詞可能會被拆分成多個。舉個例子上下文窗口就像一個固定大小的工作臺再把 Token 比作一個積木零件把大模型比作一個工匠。工匠需要拼出模型必須把所需的零件輸入的 Token放在工作臺上一邊拼裝生成回復一邊把拼好的部分輸出的 Token也放在工作臺上。整個過程輸入 輸出中工作臺上的所有積木Tokens總數都不能超過工作臺的最大容量上下文窗口大小。如果最初的零件太多占滿了工作臺工匠就沒有空間進行拼裝了。這時你就需要減少零件精簡輸入。如果最初的零件太多占滿了工作臺工匠就沒有空間進行拼裝了。這時你就需要減少零件精簡輸入1.4.2 消息裁剪有了上下文窗口和 Token 的認知再來看多輪對話的實現原理其實就是輸入 系統消息 對話歷史 最新用戶問題對于模型來說并不真正 “記憶”而是每次都將完整的上下文重新輸入。由于所有模型的上下文窗口大小都是有限的這意味著作為輸入的 Token 也是有限的。如果有累積了很長的消息歷史記錄則需要管理傳遞給模型的消息的長度。trim_messages可用于將聊天歷史記錄的大小減小為指定的令牌計數或指定的消息計數。1.4.2.1 基于輸入 Token 數的修剪下面演示一個通過trim_messages裁剪消息的示例基于輸入 Token 數的修剪。先來看看不做任何輸入限制的聊天from langchain_core.messages import SystemMessage, HumanMessage, AIMessage from langchain_deepseek import ChatDeepSeek modelChatDeepSeek(modeldeepseek-chat) message[ SystemMessage(contentyoure a good assistant), HumanMessage(contenthi! Im bob), AIMessage(contenthi!), HumanMessage(contentI like vanilla ice cream), AIMessage(contentnice), HumanMessage(contentwhats 2 2), AIMessage(content4), HumanMessage(contentthanks), AIMessage(contentno problem!), HumanMessage(contenthaving fun?), AIMessage(contentyes!), HumanMessage(contentWhats my name?), ] print(model.invoke(message))運行結果contentYour name is Bob! additional_kwargs{refusal: None} response_metadata{token_usage: {completion_tokens: 7, prompt_tokens: 64, total_tokens: 71, completion_tokens_details: None, prompt_tokens_details: {audio_tokens: None, cache_write_tokens: None, cached_tokens: 0}, prompt_cache_hit_tokens: 0, prompt_cache_miss_tokens: 64}, model_provider: deepseek, model_name: deepseek-v4-flash, system_fingerprint: a26a7955944dc5c60445bff77fac9c8e, id: f5f92cf5-00c1-4b8c-a36c-76efcd7963f8, finish_reason: stop, logprobs: None} idlc_run--01a04292-0afb-74b1-8b13-6ad989118566-0 tool_calls[] invalid_tool_calls[] usage_metadata{input_tokens: 64, output_tokens: 7, total_tokens: 71, input_token_details: {cache_read: 0}, output_token_details: {}}在運行結果的usage_metadata字段我們可以看到這些屬性usage_metadata{input_tokens: 64, output_tokens: 7, total_tokens: 71, input_token_details: {cache_read: 0}, output_token_details: {}}從打印結果來看LLM 還認識我們且共輸入了 64 tokens。接下來讓我們對消息進行裁剪我們只希望將來輸入時最多輸入 50 tokens超出的需要按照一定的 “規則” 進行裁剪代碼如下from typing import List import tiktoken from langchain_deepseek import ChatDeepSeek from langchain_core.messages import HumanMessage, SystemMessage, AIMessage, trim_messages modelChatDeepSeek(modeldeepseek-chat) message[ SystemMessage(contentyoure a good assistant), HumanMessage(contenthi! Im bob), AIMessage(contenthi!), HumanMessage(contentI like vanilla ice cream), AIMessage(contentnice), HumanMessage(contentwhats 2 2), AIMessage(content4), HumanMessage(contentthanks), AIMessage(contentno problem!), HumanMessage(contenthaving fun?), AIMessage(contentyes!), HumanMessage(contentWhats my name?), ] # 自定義token計數器tiktoken估算不需要導入不存在的函數 def tiktoken_counter(messages: List) - int: enc tiktoken.get_encoding(cl100k_base) num_tokens 3 # 每條消息固定前綴開銷 for msg in messages: num_tokens 3 num_tokens len(enc.encode(msg.content)) return num_tokens # 使用 trim_messages 減少發送給模型的消息數量 trimmer trim_messages( max_tokens50, # 修剪消息的最大令牌數根據你想要的談話長度來調整 strategylast, # 修剪策略: # last(默認): 保留最后的消息。 # first: 保留最早的消息。 token_countertiktoken_counter, # 傳入一個函數或一個語言模型(因為語言模型有消息令牌計數方法) include_systemTrue, # 如果想始終保留初始系統消息可以指定 allow_partialFalse, # 是否允許拆分消息的內容 start_onhuman, # 如果需要確保我們的第一條消息(不包括系統消息)始終是特定類型可以指定 start_on ) chain trimmer | model print(chain.invoke(message))運行結果contentI dont actually know your name—you havent told me! \n\nIf youd like to tell me, Id be happy to use it. What should I call you? additional_kwargs{refusal: None} response_metadata{token_usage: {completion_tokens: 39, prompt_tokens: 31, total_tokens: 70, completion_tokens_details: None, prompt_tokens_details: {audio_tokens: None, cache_write_tokens: None, cached_tokens: 0}, prompt_cache_hit_tokens: 0, prompt_cache_miss_tokens: 31}, model_provider: deepseek, model_name: deepseek-v4-flash, system_fingerprint: a26a7955944dc5c60445bff77fac9c8e, id: eca83f67-5368-46c8-be82-606313c5b2c4, finish_reason: stop, logprobs: None} idlc_run--01a042a8-2bbe-7571-86c6-35a5c2c7d165-0 tool_calls[] invalid_tool_calls[] usage_metadata{input_tokens: 31, output_tokens: 39, total_tokens: 70, input_token_details: {cache_read: 0}, output_token_details: {}}此時我們可以發現我們的歷史消息被裁剪了AI并不知道我們的名字是誰。被修剪了哪些消息呢來看下print(trimmer.invoke(message))輸出結果[SystemMessage(contentyoure a good assistant, additional_kwargs{}, response_metadata{}), HumanMessage(contentthanks, additional_kwargs{}, response_metadata{}), AIMessage(contentno problem!, additional_kwargs{}, response_metadata{}, tool_calls[], invalid_tool_calls[]), HumanMessage(contenthaving fun?, additional_kwargs{}, response_metadata{}), AIMessage(contentyes!, additional_kwargs{}, response_metadata{}, tool_calls[], invalid_tool_calls[]), HumanMessage(contentWhats my name?, additional_kwargs{}, response_metadata{})]從結果來看確實是按照我們給定的裁剪 “規則” 來完成的。修剪聊天記錄后生成的聊天記錄輸入應該有效需遵循對話模式原則聊天記錄以HumanMessage或SystemMessage開頭后跟HumanMessage。這可以通過設置start_onhuman來實現。聊天記錄以HumanMessage或ToolMessage結尾。這可以通過設置ends_on(human, tool)來實現。ToolMessage只能出現在涉及工具調用的AIMessage之后。如果原始聊天歷史記錄中存在SystemMessage則新聊天歷史記錄應包括SystemMessage因為SystemMessage包含對聊天模型的特殊說明。SystemMessage總是歷史記錄中的第一條消息如果存在。這可以通過設置include_systemTrue。1.4.2.2 基于消息數的修剪除了基于 token 的修剪還可以通過設置token_counterlen根據消息數修剪聊天記錄。在這種情況下max_tokens將控制最大消息數。示例如下from langchain_deepseek import ChatDeepSeek from langchain_core.messages import HumanMessage, SystemMessage, AIMessage, trim_messages modelChatDeepSeek(modeldeepseek-chat) message[ SystemMessage(contentyoure a good assistant), HumanMessage(contenthi! Im bob), AIMessage(contenthi!), HumanMessage(contentI like vanilla ice cream), AIMessage(contentnice), HumanMessage(contentwhats 2 2), AIMessage(content4), HumanMessage(contentthanks), AIMessage(contentno problem!), HumanMessage(contenthaving fun?), AIMessage(contentyes!), HumanMessage(contentWhats my name?), ] # 使用 trim_messages 減少發送給模型的消息數量 trimmer trim_messages( max_tokens11, # 修剪消息的最大令牌數根據你想要的談話長度來調整 strategylast, # 修剪策略: # last(默認): 保留最后的消息。 # first: 保留最早的消息。 token_counterlen, # 傳入一個函數或一個語言模型(因為語言模型有消息令牌計數方法) include_systemTrue, # 如果想始終保留初始系統消息可以指定也就是第一個SyStemMessage allow_partialFalse, # 是否允許拆分消息的內容 start_onhuman, # 如果需要確保我們的第一條消息(不包括系統消息)始終是特定類型可以指定 start_on ) chain trimmer | model print(trimmer.invoke(message))運行結果[SystemMessage(contentyoure a good assistant, additional_kwargs{}, response_metadata{}), HumanMessage(contentI like vanilla ice cream, additional_kwargs{}, response_metadata{}), AIMessage(contentnice, additional_kwargs{}, response_metadata{}, tool_calls[], invalid_tool_calls[]), HumanMessage(contentwhats 2 2, additional_kwargs{}, response_metadata{}), AIMessage(content4, additional_kwargs{}, response_metadata{}, tool_calls[], invalid_tool_calls[]), HumanMessage(contentthanks, additional_kwargs{}, response_metadata{}), AIMessage(contentno problem!, additional_kwargs{}, response_metadata{}, tool_calls[], invalid_tool_calls[]), HumanMessage(contenthaving fun?, additional_kwargs{}, response_metadata{}), AIMessage(contentyes!, additional_kwargs{}, response_metadata{}, tool_calls[], invalid_tool_calls[]), HumanMessage(contentWhats my name?, additional_kwargs{}, response_metadata{})]可以看到代碼中我們指定了最大消息數為11個消息。并且第一個消息必須是HumanMessage所以一共裁剪掉了除系統消息之外最早的兩個消息如圖1.4.3 消息過濾按類型進行篩選在更復雜的場景下我們可能會使用消息列表來跟蹤狀態例如我們可能只想將這個完整消息列表的子集傳遞模型調用而不是所有的歷史記錄。filter_messages方法則可以輕松地按類型、ID 或名稱過濾 message。如以下代碼的效果就是獲取message消息列表中的所有HumanMessage:message[ SystemMessage(content你是一個人工智能助手,id1), HumanMessage(content示例輸入,id2), AIMessage(content示例輸出,id3), HumanMessage(content示例輸入,id4), AIMessage(content示例輸出,id5) ] #獲取mesage這個消息列表中所有的HumanMessage并打印 print(filter_messages(message, include_typeshuman)) #等價于 # print(filter_messages( include_typeshuman).invoke(message))運行結果[HumanMessage(content示例輸入, additional_kwargs{}, response_metadata{}, id2), HumanMessage(content示例輸入, additional_kwargs{}, response_metadata{}, id4)]按類型 ID 進行篩選獲取mesage這個消息列表中所有除了id3的HumanMessage與AIMessage并打印message[ SystemMessage(content你是一個人工智能助手,id1), HumanMessage(content示例輸入,id2), AIMessage(content示例輸出,id3), HumanMessage(content示例輸入,id4), AIMessage(content示例輸出,id5) ] #獲取mesage這個消息列表中所有除了id3的HumanMessage與AIMessage并打印 print(filter_messages(message, include_types[HumanMessage,AIMessage],exclude_ids3)) #等價于 #print(filter_messages( include_types[HumanMessage,AIMessage],exclude_ids3).invoke(message))運行結果[HumanMessage(content示例輸入, additional_kwargs{}, response_metadata{}, id2), HumanMessage(content示例輸入, additional_kwargs{}, response_metadata{}, id4), AIMessage(content示例輸出, additional_kwargs{}, response_metadata{}, id5, tool_calls[], invalid_tool_calls[])]1.4.4 消息合并若我們的消息列表存在連續某種類型相同的消息但實際上某些模型不支持傳遞相同類型的連續消息。因此對于這種情況我們可以使用merge_message_runs方法輕松合并相同類型的連續消息。# 定義大模型 model ChatDeepSeek(modeldeepseek-chat) # 歷史消息記錄 messages [ SystemMessage(你是一個聊天助手。), SystemMessage(你總是以笑話回應。), HumanMessage(為什么要使用 LangChain?), HumanMessage(為什么要使用 LangGraph?), AIMessage(因為當你試圖讓你的代碼更有條理時LangGraph 會讓你感到“節點”是個好主意), AIMessage(不過別擔心它不會“分散”你的注意力), HumanMessage(選擇LangChain還是LangGraph?), ] mergemerge_message_runs(messages) #調用大模型方法一 print(model.invoke(messages).content) # #調用大模型方法二 # mergemerge_message_runs() # # chainmerge | model # # print(chain.invoke(messages).content)運行結果選 LangChain 還是 LangGraph這就像問“我該用錘子還是螺絲刀”——如果我想把代碼釘進墻里就選 LangChain如果我想畫一幅流程圖選 LangGraph 準沒錯不過說真的如果你總是選錯我們可能需要聊聊“鏈”接心理醫生的問題了 LangChain 消息組件：從基礎消息到歷史消息處理
目錄?編輯1. 消息Messages1.1 LLM 消息結構1.2 LangChain 消息1.2.1 BaseMessage 抽象消息類1.2.2 對話模式1.3 緩存歷史消息1.3.1 多輪對話1.3.2 內存緩存1.4 管理歷史消息1.4.1 前置概念1.4.1.1 上下文窗口1.4.1.2 Token1.4.2 消息裁剪1.4.2.1 基于輸入 Token 數的修剪1.4.2.2 基于消息數的修剪1.4.3 消息過濾按類型進行篩選按類型 ID 進行篩選1.4.4 消息合并1. 消息Messages消息是聊天模型中的通信單位用于表示聊天模型的輸入和輸出以及可能與對話關聯的任何其他上下文或元數據。1.1 LLM 消息結構每條消息都有一個角色和內容以及因 LLM 的不同而不同的附加元數據。消息角色Role角色描述system系統角色用于告訴聊天模型如何行為并提供額外的上下文。并非所有聊天模型提供商都支持。user用戶角色表示用戶與模型交互的輸入通常以文本或其他交互式輸入的形式。assistant助理角色表示來自模型的響應其中可以包括文本或調用工具的請求。tool工具角色用于在檢索外部數據或將工具調用的結果傳遞回模型的消息。與支持工具調用的聊天模型一起使用。用來區分對話中不同類型的消息并幫助聊天模型了解如何響應給定的消息序列。消息內容 (Content)表示多模態數據例如圖像、音頻、視頻的消息文本或字典列表的內容。內容的具體格式可能因底層不同的 LLM 而異。目前大多數模型都支持文本作為主要內容類型對多模態數據的支持仍然有限。消息其他元數據 (Additional metadata)元數據描述ID消息標識符。Name名稱允許區分具有相同角色的不同實體。并非所有型號都支持此功能Metadata有關消息的其他信息例如時間戳、令牌使用情況等。Tool Calls模型發出的一個或多個工具的調用請求下面展示一個 OpenAI 的格式消息列表[ { role: user, content: Hello, how are you?, }, { role: assistant, content: Im doing well, thank you for asking., }, { role: user, content: Can you tell me a joke?, } ]LangChain 接受下面的格式作為聊天模型的輸入chat_model.invoke([ { role: user, content: Hello, how are you?, }, { role: assistant, content: Im doing well, thank you for asking., }, { role: user, content: Can you tell me a joke?, } ])1.2 LangChain 消息LangChain 提供了一種統一的消息格式可以跨聊天模型使用允許用戶使用不同的聊天模型而無需擔心每個模型提供商使用的消息格式的具體細節。例如openai_model init_chat_model(gpt-4o-mini, model_provideropenai) anthropic_model init_chat_model(claude-3-5-sonnet-latest, model_provideranthropic) deepseek_model init_chat_model(deepseek-chat, model_providerdeepseek) google_genai_model init_chat_model(gemini-2.5-flash, model_providergoogle_genai) model init_chat_model(...)這些模型提供商不同但對于其輸入和輸出統一使用 LangChain 的消息格式。LangChain 消息格式主要分為五種分別是消息類型對應角色描述SystemMessage對應 system 系統角色用于啟動 AI 模型的行為并提供額外的上下文例如指示模型采用特定角色或設定對話的基調例如你是一個后端開發的專家。HumanMessage對應 user 用戶角色人類消息表示用戶與模型交互的輸入。大多數聊天模型都希望用戶輸入采用文本形式。AIMessage對應 assistant 助理角色這是來自模型的響應其中可以包括文本或調用工具的請求。它還可能包括其他媒體類型如圖像、音頻或視頻 —— 盡管這目前仍然不常見。AIMessageChunk對應 assistant 助理角色用于流式響應通常在生成聊天模型時流式傳輸響應因此用戶可以實時看到響應而不是等待生成整個響應后再顯示。ToolMessage對應 tool 工具角色這表示一條角色為 tool 的消息其中包含調用工具的結果。這幾個消息類型我們已經全部見過它們都是 LangChainBaseMessage的子類全部是作為 LangChain 聊天模型的輸入和輸出。1.2.1 BaseMessage 抽象消息類class langchain_core.messages.base.BaseMessage是作為 LangChain 聊天模型的輸入和輸出參數如下content消息的字符串內容。additional_kwargs與消息關聯的其他有效負載數據。對于來自 AI 的消息可能包括模型提供程序編碼的工具調用。response_metadata響應元數據。例如響應標頭、logprobs、令牌計數、模型名稱。type消息類型。必須是消息類型唯一的字符串。此字段的目的是在對消息進行序列化時方便地識別消息類型。name消息名稱為消息提供一個人類可讀的名稱。該字段的使用是可選的是否使用它取決于模型實現。id消息的可選唯一標識符。理想情況下這應該由創建消息的提供者 / 模型提供。modelChatDeepSeek(modeldeepseek-chat) print(model.invoke(你好啊))content你好呀很高興見到你 我是DeepSeek你的AI助手。有什么我可以幫你的嗎無論是聊天、解答問題、寫作、翻譯還是其他需求盡管告訴我我會盡力幫你搞定。你今天過得怎么樣 additional_kwargs{refusal: None} response_metadata{token_usage: {completion_tokens: 50, prompt_tokens: 6, total_tokens: 56, completion_tokens_details: None, prompt_tokens_details: {audio_tokens: None, cache_write_tokens: None, cached_tokens: 0}, prompt_cache_hit_tokens: 0, prompt_cache_miss_tokens: 6}, model_provider: deepseek, model_name: deepseek-v4-flash, system_fingerprint: a26a7955944dc5c60445bff77fac9c8e, id: 526f8f0f-aaad-44d0-b390-b2160d1654f2, finish_reason: stop, logprobs: None} idlc_run--01a041fb-82f7-7e82-a124-45478c326e03-0 tool_calls[] invalid_tool_calls[] usage_metadata{input_tokens: 6, output_tokens: 50, total_tokens: 56, input_token_details: {cache_read: 0}, output_token_details: {}}內置方法pretty_print() → None打印消息的漂亮表示。pretty_repr(html: bool False) → str獲得消息的漂亮表示。請求是否將消息格式化為 HTML。如果為 True則消息將使用 HTML 標記進行格式化。默認值為 False。響應這是消息的漂亮表示。text() → str獲取消息的文本內容。aimessmodel.invoke(你好啊) aimess.pretty_print()print(aimess.text)1.2.2 對話模式大多數對話都以設置對話上下文的系統消息開始。接下來是包含用戶輸入的用戶消息然后是包含模型響應的助手消息。兩種對話流轉示意圖1.3 緩存歷史消息1.3.1 多輪對話在與大型語言模型交互的過程中我們常常體驗到與智能助手進行連貫多輪對話的便利性。但目前我們的系統還不支持此功能代碼如下modelChatDeepSeek(modeldeepseek-chat) print(model.invoke(你好啊,我的名字叫王小明).content) print(model.invoke(你知道我的名字叫什么嗎).content)這里我們可以發現雖然我們在第一段對話的時候就告訴了AI我的名字但是在第二次對話的過程中AI并不知道我們的名字。在這樣的對話方式里AI并不具有存儲歷史消息或者說記憶的功能。解決這個問題的方式就是在每次對話的過程中應該將歷史對話的上下文合并為一個消息列表然后傳遞給AI代碼如下message[ SystemMessage(你是一個人工智能助手), HumanMessage(你好啊,我的名字叫王小明), AIMessage(你好呀王小明很高興認識你。), HumanMessage(你知道我的名字叫什么嗎) ] modelChatDeepSeek(modeldeepseek-chat) print(model.invoke(message).content)可以看到當我們將歷史上下文傳遞給AI的時候就能發現它能準確地說出我們的名字了。換句話說只要將歷史消息重新發送給聊天模型那么就可以實現多輪對話的功能。1.3.2 內存緩存那么對于歷史消息的管理就顯得尤為重要。在 LangChain 老版本中可以使用RunnableWithMessageHistory消息歷史類來包裝另一個 Runnable 并為其管理聊天消息歷史記錄。它將跟蹤模型的輸入和輸出并將其存儲在某個數據存儲中。未來的交互將加載這些消息并將其作為輸入的一部分傳遞給鏈。from langchain_core.chat_history import InMemoryChatMessageHistory, BaseChatMessageHistory from langchain_core.messages import SystemMessage, HumanMessage, AIMessage from langchain_core.runnables import RunnableWithMessageHistory, configurable from langchain_deepseek import ChatDeepSeek modelChatDeepSeek(modeldeepseek-chat) store{} def Get_History_ssid(ssid:str)-BaseChatMessageHistory: if ssid not in store: store[ssid]InMemoryChatMessageHistory() return store[ssid] with_History_modelRunnableWithMessageHistory(model,Get_History_ssid) config{configurable:{session_id:1}} print(with_History_model.invoke([HumanMessage(你好我的名字叫王小明)], configconfig).content) print(with_History_model.invoke([HumanMessage(你知道我的名字嗎)], configconfig).content)class langchain_core.runnables.history.RunnableWithMessageHistory類初始化參數說明runnable被包裝 Runnable 實例這里就是我們定義的聊天模型Get_History_ssid返回類型為BaseChatMessageHistory的函數傳入后作為回調函數。此函數接受一個session_id字符串類型并返回相應的聊天消息歷史記錄實例。class langchain_core.runnables.history.RunnableWithMessageHistory類方法說明.invoke()方法此方法與其他 Runnable 實例的.invoke()方法相同。只不過注意其 config 配置需要配置成config{configurable: {session_id: }}讓RunnableWithMessageHistory可以讀取到會話 id。記憶功能已經實現但是需要注意的是從 LangChain 的 v0.3 版本開始官方建議 LangChain 用戶不要使用RunnableWithMessageHistory而是利用 LangGraph 持久性 來完成見 LangGraph 章節。原因是它們的功能有限不太適合現實世界的對話式 AI 應用程序。這些內存抽象缺乏對多用戶、多對話場景的內置支持而這對于實際的對話式人工智能系統至關重要。這些實現中的大多數已在 LangChain 0.3.x 中被正式棄用取而代之的是 LangGraph 持久性。LangGraph 持久性 非常靈活可以支持比RunnableWithMessageHistory接口更廣泛的用例。我們會在 LangGraph 篇章中學習它因此RunnableWithMessageHistory這部分我們講解的并不深入。在之前對于生產環境我們還需要使用聊天消息歷史記錄的持久化實現例如RedisChatMessageHistory()而不是InMemoryChatMessageHistory()但現在也已不推薦新應用使用它們了。1.4 管理歷史消息1.4.1 前置概念1.4.1.1 上下文窗口管理歷史消息無非就是理解如何 “管理”“管理” 無非也就是一些 “CRUD”。那么在了解如何管理消息之前需要先了解下多輪對話的核心概念上下文窗口。上下文窗口可以理解為模型的 “短期工作記憶區”即 LLM 在一次處理請求時所能查看和處理的最大 Token 數量它包含了用戶的輸入大模型的輸出有時還包括系統指令SystemMessage和對話歷史。不同大模型支持的上下文窗口大小不同例如OpenAI 下 GPT?5 模型上下文窗口為 400000最大 Token 數量GPT?4.1 模型上下文窗口為 1047576最大 Token 數量其他模型上下文窗口可參考對應模型官網說明如 OpenAI 下模型可以參考這里。1.4.1.2 Token在自然語言處理NLP中Token 是文本的基本單位。它不是完全等同于一個單詞或一個漢字而是一個更細粒度的劃分。為什么用 Token計算機無法直接理解文字它需要將文本轉換為數字向量。Tokenization令牌化就是這個轉換過程的第一步將句子分解成模型可以理解和處理的碎片。對于英文1 個 Token ~ 4 個字符或 0.75 個單詞1000 個 Tokens 約等于 750 個英文單詞。一個 Token 可以是一個單詞如apple、一個詞根如un在unlikely中或者一個標點符號如.。例如ChatGPT is great!可能會被分成[Chat, G, PT, is, great, !]這 6 個 Token。對于中文1 個漢字 1.5?2 個 Tokens1000 個 Tokens 大約相當于 500?700 個漢字。常見的詞和字可能是一個 Token生僻字或復雜詞可能會被拆分成多個。舉個例子上下文窗口就像一個固定大小的工作臺再把 Token 比作一個積木零件把大模型比作一個工匠。工匠需要拼出模型必須把所需的零件輸入的 Token放在工作臺上一邊拼裝生成回復一邊把拼好的部分輸出的 Token也放在工作臺上。整個過程輸入 輸出中工作臺上的所有積木Tokens總數都不能超過工作臺的最大容量上下文窗口大小。如果最初的零件太多占滿了工作臺工匠就沒有空間進行拼裝了。這時你就需要減少零件精簡輸入。如果最初的零件太多占滿了工作臺工匠就沒有空間進行拼裝了。這時你就需要減少零件精簡輸入1.4.2 消息裁剪有了上下文窗口和 Token 的認知再來看多輪對話的實現原理其實就是輸入 系統消息 對話歷史 最新用戶問題對于模型來說并不真正 “記憶”而是每次都將完整的上下文重新輸入。由于所有模型的上下文窗口大小都是有限的這意味著作為輸入的 Token 也是有限的。如果有累積了很長的消息歷史記錄則需要管理傳遞給模型的消息的長度。trim_messages可用于將聊天歷史記錄的大小減小為指定的令牌計數或指定的消息計數。1.4.2.1 基于輸入 Token 數的修剪下面演示一個通過trim_messages裁剪消息的示例基于輸入 Token 數的修剪。先來看看不做任何輸入限制的聊天from langchain_core.messages import SystemMessage, HumanMessage, AIMessage from langchain_deepseek import ChatDeepSeek modelChatDeepSeek(modeldeepseek-chat) message[ SystemMessage(contentyoure a good assistant), HumanMessage(contenthi! Im bob), AIMessage(contenthi!), HumanMessage(contentI like vanilla ice cream), AIMessage(contentnice), HumanMessage(contentwhats 2 2), AIMessage(content4), HumanMessage(contentthanks), AIMessage(contentno problem!), HumanMessage(contenthaving fun?), AIMessage(contentyes!), HumanMessage(contentWhats my name?), ] print(model.invoke(message))運行結果contentYour name is Bob! additional_kwargs{refusal: None} response_metadata{token_usage: {completion_tokens: 7, prompt_tokens: 64, total_tokens: 71, completion_tokens_details: None, prompt_tokens_details: {audio_tokens: None, cache_write_tokens: None, cached_tokens: 0}, prompt_cache_hit_tokens: 0, prompt_cache_miss_tokens: 64}, model_provider: deepseek, model_name: deepseek-v4-flash, system_fingerprint: a26a7955944dc5c60445bff77fac9c8e, id: f5f92cf5-00c1-4b8c-a36c-76efcd7963f8, finish_reason: stop, logprobs: None} idlc_run--01a04292-0afb-74b1-8b13-6ad989118566-0 tool_calls[] invalid_tool_calls[] usage_metadata{input_tokens: 64, output_tokens: 7, total_tokens: 71, input_token_details: {cache_read: 0}, output_token_details: {}}在運行結果的usage_metadata字段我們可以看到這些屬性usage_metadata{input_tokens: 64, output_tokens: 7, total_tokens: 71, input_token_details: {cache_read: 0}, output_token_details: {}}從打印結果來看LLM 還認識我們且共輸入了 64 tokens。接下來讓我們對消息進行裁剪我們只希望將來輸入時最多輸入 50 tokens超出的需要按照一定的 “規則” 進行裁剪代碼如下from typing import List import tiktoken from langchain_deepseek import ChatDeepSeek from langchain_core.messages import HumanMessage, SystemMessage, AIMessage, trim_messages modelChatDeepSeek(modeldeepseek-chat) message[ SystemMessage(contentyoure a good assistant), HumanMessage(contenthi! Im bob), AIMessage(contenthi!), HumanMessage(contentI like vanilla ice cream), AIMessage(contentnice), HumanMessage(contentwhats 2 2), AIMessage(content4), HumanMessage(contentthanks), AIMessage(contentno problem!), HumanMessage(contenthaving fun?), AIMessage(contentyes!), HumanMessage(contentWhats my name?), ] # 自定義token計數器tiktoken估算不需要導入不存在的函數 def tiktoken_counter(messages: List) - int: enc tiktoken.get_encoding(cl100k_base) num_tokens 3 # 每條消息固定前綴開銷 for msg in messages: num_tokens 3 num_tokens len(enc.encode(msg.content)) return num_tokens # 使用 trim_messages 減少發送給模型的消息數量 trimmer trim_messages( max_tokens50, # 修剪消息的最大令牌數根據你想要的談話長度來調整 strategylast, # 修剪策略: # last(默認): 保留最后的消息。 # first: 保留最早的消息。 token_countertiktoken_counter, # 傳入一個函數或一個語言模型(因為語言模型有消息令牌計數方法) include_systemTrue, # 如果想始終保留初始系統消息可以指定 allow_partialFalse, # 是否允許拆分消息的內容 start_onhuman, # 如果需要確保我們的第一條消息(不包括系統消息)始終是特定類型可以指定 start_on ) chain trimmer | model print(chain.invoke(message))運行結果contentI dont actually know your name—you havent told me! \n\nIf youd like to tell me, Id be happy to use it. What should I call you? additional_kwargs{refusal: None} response_metadata{token_usage: {completion_tokens: 39, prompt_tokens: 31, total_tokens: 70, completion_tokens_details: None, prompt_tokens_details: {audio_tokens: None, cache_write_tokens: None, cached_tokens: 0}, prompt_cache_hit_tokens: 0, prompt_cache_miss_tokens: 31}, model_provider: deepseek, model_name: deepseek-v4-flash, system_fingerprint: a26a7955944dc5c60445bff77fac9c8e, id: eca83f67-5368-46c8-be82-606313c5b2c4, finish_reason: stop, logprobs: None} idlc_run--01a042a8-2bbe-7571-86c6-35a5c2c7d165-0 tool_calls[] invalid_tool_calls[] usage_metadata{input_tokens: 31, output_tokens: 39, total_tokens: 70, input_token_details: {cache_read: 0}, output_token_details: {}}此時我們可以發現我們的歷史消息被裁剪了AI并不知道我們的名字是誰。被修剪了哪些消息呢來看下print(trimmer.invoke(message))輸出結果[SystemMessage(contentyoure a good assistant, additional_kwargs{}, response_metadata{}), HumanMessage(contentthanks, additional_kwargs{}, response_metadata{}), AIMessage(contentno problem!, additional_kwargs{}, response_metadata{}, tool_calls[], invalid_tool_calls[]), HumanMessage(contenthaving fun?, additional_kwargs{}, response_metadata{}), AIMessage(contentyes!, additional_kwargs{}, response_metadata{}, tool_calls[], invalid_tool_calls[]), HumanMessage(contentWhats my name?, additional_kwargs{}, response_metadata{})]從結果來看確實是按照我們給定的裁剪 “規則” 來完成的。修剪聊天記錄后生成的聊天記錄輸入應該有效需遵循對話模式原則聊天記錄以HumanMessage或SystemMessage開頭后跟HumanMessage。這可以通過設置start_onhuman來實現。聊天記錄以HumanMessage或ToolMessage結尾。這可以通過設置ends_on(human, tool)來實現。ToolMessage只能出現在涉及工具調用的AIMessage之后。如果原始聊天歷史記錄中存在SystemMessage則新聊天歷史記錄應包括SystemMessage因為SystemMessage包含對聊天模型的特殊說明。SystemMessage總是歷史記錄中的第一條消息如果存在。這可以通過設置include_systemTrue。1.4.2.2 基于消息數的修剪除了基于 token 的修剪還可以通過設置token_counterlen根據消息數修剪聊天記錄。在這種情況下max_tokens將控制最大消息數。示例如下from langchain_deepseek import ChatDeepSeek from langchain_core.messages import HumanMessage, SystemMessage, AIMessage, trim_messages modelChatDeepSeek(modeldeepseek-chat) message[ SystemMessage(contentyoure a good assistant), HumanMessage(contenthi! Im bob), AIMessage(contenthi!), HumanMessage(contentI like vanilla ice cream), AIMessage(contentnice), HumanMessage(contentwhats 2 2), AIMessage(content4), HumanMessage(contentthanks), AIMessage(contentno problem!), HumanMessage(contenthaving fun?), AIMessage(contentyes!), HumanMessage(contentWhats my name?), ] # 使用 trim_messages 減少發送給模型的消息數量 trimmer trim_messages( max_tokens11, # 修剪消息的最大令牌數根據你想要的談話長度來調整 strategylast, # 修剪策略: # last(默認): 保留最后的消息。 # first: 保留最早的消息。 token_counterlen, # 傳入一個函數或一個語言模型(因為語言模型有消息令牌計數方法) include_systemTrue, # 如果想始終保留初始系統消息可以指定也就是第一個SyStemMessage allow_partialFalse, # 是否允許拆分消息的內容 start_onhuman, # 如果需要確保我們的第一條消息(不包括系統消息)始終是特定類型可以指定 start_on ) chain trimmer | model print(trimmer.invoke(message))運行結果[SystemMessage(contentyoure a good assistant, additional_kwargs{}, response_metadata{}), HumanMessage(contentI like vanilla ice cream, additional_kwargs{}, response_metadata{}), AIMessage(contentnice, additional_kwargs{}, response_metadata{}, tool_calls[], invalid_tool_calls[]), HumanMessage(contentwhats 2 2, additional_kwargs{}, response_metadata{}), AIMessage(content4, additional_kwargs{}, response_metadata{}, tool_calls[], invalid_tool_calls[]), HumanMessage(contentthanks, additional_kwargs{}, response_metadata{}), AIMessage(contentno problem!, additional_kwargs{}, response_metadata{}, tool_calls[], invalid_tool_calls[]), HumanMessage(contenthaving fun?, additional_kwargs{}, response_metadata{}), AIMessage(contentyes!, additional_kwargs{}, response_metadata{}, tool_calls[], invalid_tool_calls[]), HumanMessage(contentWhats my name?, additional_kwargs{}, response_metadata{})]可以看到代碼中我們指定了最大消息數為11個消息。并且第一個消息必須是HumanMessage所以一共裁剪掉了除系統消息之外最早的兩個消息如圖1.4.3 消息過濾按類型進行篩選在更復雜的場景下我們可能會使用消息列表來跟蹤狀態例如我們可能只想將這個完整消息列表的子集傳遞模型調用而不是所有的歷史記錄。filter_messages方法則可以輕松地按類型、ID 或名稱過濾 message。如以下代碼的效果就是獲取message消息列表中的所有HumanMessage:message[ SystemMessage(content你是一個人工智能助手,id1), HumanMessage(content示例輸入,id2), AIMessage(content示例輸出,id3), HumanMessage(content示例輸入,id4), AIMessage(content示例輸出,id5) ] #獲取mesage這個消息列表中所有的HumanMessage并打印 print(filter_messages(message, include_typeshuman)) #等價于 # print(filter_messages( include_typeshuman).invoke(message))運行結果[HumanMessage(content示例輸入, additional_kwargs{}, response_metadata{}, id2), HumanMessage(content示例輸入, additional_kwargs{}, response_metadata{}, id4)]按類型 ID 進行篩選獲取mesage這個消息列表中所有除了id3的HumanMessage與AIMessage并打印message[ SystemMessage(content你是一個人工智能助手,id1), HumanMessage(content示例輸入,id2), AIMessage(content示例輸出,id3), HumanMessage(content示例輸入,id4), AIMessage(content示例輸出,id5) ] #獲取mesage這個消息列表中所有除了id3的HumanMessage與AIMessage并打印 print(filter_messages(message, include_types[HumanMessage,AIMessage],exclude_ids3)) #等價于 #print(filter_messages( include_types[HumanMessage,AIMessage],exclude_ids3).invoke(message))運行結果[HumanMessage(content示例輸入, additional_kwargs{}, response_metadata{}, id2), HumanMessage(content示例輸入, additional_kwargs{}, response_metadata{}, id4), AIMessage(content示例輸出, additional_kwargs{}, response_metadata{}, id5, tool_calls[], invalid_tool_calls[])]1.4.4 消息合并若我們的消息列表存在連續某種類型相同的消息但實際上某些模型不支持傳遞相同類型的連續消息。因此對于這種情況我們可以使用merge_message_runs方法輕松合并相同類型的連續消息。# 定義大模型 model ChatDeepSeek(modeldeepseek-chat) # 歷史消息記錄 messages [ SystemMessage(你是一個聊天助手。), SystemMessage(你總是以笑話回應。), HumanMessage(為什么要使用 LangChain?), HumanMessage(為什么要使用 LangGraph?), AIMessage(因為當你試圖讓你的代碼更有條理時LangGraph 會讓你感到“節點”是個好主意), AIMessage(不過別擔心它不會“分散”你的注意力), HumanMessage(選擇LangChain還是LangGraph?), ] mergemerge_message_runs(messages) #調用大模型方法一 print(model.invoke(messages).content) # #調用大模型方法二 # mergemerge_message_runs() # # chainmerge | model # # print(chain.invoke(messages).content)運行結果選 LangChain 還是 LangGraph這就像問“我該用錘子還是螺絲刀”——如果我想把代碼釘進墻里就選 LangChain如果我想畫一幅流程圖選 LangGraph 準沒錯不過說真的如果你總是選錯我們可能需要聊聊“鏈”接心理醫生的問題了