目錄?編輯1. 消息Messages1.1 LLM 消息結(jié)構(gòu)1.2 LangChain 消息1.2.1 BaseMessage 抽象消息類1.2.2 對(duì)話模式1.3 緩存歷史消息1.3.1 多輪對(duì)話1.3.2 內(nèi)存緩存1.4 管理歷史消息1.4.1 前置概念1.4.1.1 上下文窗口1.4.1.2 Token1.4.2 消息裁剪1.4.2.1 基于輸入 Token 數(shù)的修剪1.4.2.2 基于消息數(shù)的修剪1.4.3 消息過濾按類型進(jìn)行篩選按類型 ID 進(jìn)行篩選1.4.4 消息合并1. 消息Messages消息是聊天模型中的通信單位用于表示聊天模型的輸入和輸出以及可能與對(duì)話關(guān)聯(lián)的任何其他上下文或元數(shù)據(jù)。1.1 LLM 消息結(jié)構(gòu)每條消息都有一個(gè)角色和內(nèi)容以及因 LLM 的不同而不同的附加元數(shù)據(jù)。消息角色Role角色描述system系統(tǒng)角色用于告訴聊天模型如何行為并提供額外的上下文。并非所有聊天模型提供商都支持。user用戶角色表示用戶與模型交互的輸入通常以文本或其他交互式輸入的形式。assistant助理角色表示來自模型的響應(yīng)其中可以包括文本或調(diào)用工具的請(qǐng)求。tool工具角色用于在檢索外部數(shù)據(jù)或?qū)⒐ぞ哒{(diào)用的結(jié)果傳遞回模型的消息。與支持工具調(diào)用的聊天模型一起使用。用來區(qū)分對(duì)話中不同類型的消息并幫助聊天模型了解如何響應(yīng)給定的消息序列。消息內(nèi)容 (Content)表示多模態(tài)數(shù)據(jù)例如圖像、音頻、視頻的消息文本或字典列表的內(nèi)容。內(nèi)容的具體格式可能因底層不同的 LLM 而異。目前大多數(shù)模型都支持文本作為主要內(nèi)容類型對(duì)多模態(tài)數(shù)據(jù)的支持仍然有限。消息其他元數(shù)據(jù) (Additional metadata)元數(shù)據(jù)描述ID消息標(biāo)識(shí)符。Name名稱允許區(qū)分具有相同角色的不同實(shí)體。并非所有型號(hào)都支持此功能Metadata有關(guān)消息的其他信息例如時(shí)間戳、令牌使用情況等。Tool Calls模型發(fā)出的一個(gè)或多個(gè)工具的調(diào)用請(qǐng)求下面展示一個(gè) 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 提供了一種統(tǒng)一的消息格式可以跨聊天模型使用允許用戶使用不同的聊天模型而無需擔(dān)心每個(gè)模型提供商使用的消息格式的具體細(xì)節(jié)。例如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(...)這些模型提供商不同但對(duì)于其輸入和輸出統(tǒng)一使用 LangChain 的消息格式。LangChain 消息格式主要分為五種分別是消息類型對(duì)應(yīng)角色描述SystemMessage對(duì)應(yīng) system 系統(tǒng)角色用于啟動(dòng) AI 模型的行為并提供額外的上下文例如指示模型采用特定角色或設(shè)定對(duì)話的基調(diào)例如你是一個(gè)后端開發(fā)的專家。HumanMessage對(duì)應(yīng) user 用戶角色人類消息表示用戶與模型交互的輸入。大多數(shù)聊天模型都希望用戶輸入采用文本形式。AIMessage對(duì)應(yīng) assistant 助理角色這是來自模型的響應(yīng)其中可以包括文本或調(diào)用工具的請(qǐng)求。它還可能包括其他媒體類型如圖像、音頻或視頻 —— 盡管這目前仍然不常見。AIMessageChunk對(duì)應(yīng) assistant 助理角色用于流式響應(yīng)通常在生成聊天模型時(shí)流式傳輸響應(yīng)因此用戶可以實(shí)時(shí)看到響應(yīng)而不是等待生成整個(gè)響應(yīng)后再顯示。ToolMessage對(duì)應(yīng) tool 工具角色這表示一條角色為 tool 的消息其中包含調(diào)用工具的結(jié)果。這幾個(gè)消息類型我們已經(jīng)全部見過它們都是 LangChainBaseMessage的子類全部是作為 LangChain 聊天模型的輸入和輸出。1.2.1 BaseMessage 抽象消息類class langchain_core.messages.base.BaseMessage是作為 LangChain 聊天模型的輸入和輸出參數(shù)如下content消息的字符串內(nèi)容。additional_kwargs與消息關(guān)聯(lián)的其他有效負(fù)載數(shù)據(jù)。對(duì)于來自 AI 的消息可能包括模型提供程序編碼的工具調(diào)用。response_metadata響應(yīng)元數(shù)據(jù)。例如響應(yīng)標(biāo)頭、logprobs、令牌計(jì)數(shù)、模型名稱。type消息類型。必須是消息類型唯一的字符串。此字段的目的是在對(duì)消息進(jìn)行序列化時(shí)方便地識(shí)別消息類型。name消息名稱為消息提供一個(gè)人類可讀的名稱。該字段的使用是可選的是否使用它取決于模型實(shí)現(xiàn)。id消息的可選唯一標(biāo)識(shí)符。理想情況下這應(yīng)該由創(chuàng)建消息的提供者 / 模型提供。modelChatDeepSeek(modeldeepseek-chat) print(model.invoke(你好啊))content你好呀很高興見到你 我是DeepSeek你的AI助手。有什么我可以幫你的嗎無論是聊天、解答問題、寫作、翻譯還是其他需求盡管告訴我我會(huì)盡力幫你搞定。你今天過得怎么樣 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: {}}內(nèi)置方法pretty_print() → None打印消息的漂亮表示。pretty_repr(html: bool False) → str獲得消息的漂亮表示。請(qǐng)求是否將消息格式化為 HTML。如果為 True則消息將使用 HTML 標(biāo)記進(jìn)行格式化。默認(rèn)值為 False。響應(yīng)這是消息的漂亮表示。text() → str獲取消息的文本內(nèi)容。aimessmodel.invoke(你好啊) aimess.pretty_print()print(aimess.text)1.2.2 對(duì)話模式大多數(shù)對(duì)話都以設(shè)置對(duì)話上下文的系統(tǒng)消息開始。接下來是包含用戶輸入的用戶消息然后是包含模型響應(yīng)的助手消息。兩種對(duì)話流轉(zhuǎn)示意圖1.3 緩存歷史消息1.3.1 多輪對(duì)話在與大型語(yǔ)言模型交互的過程中我們常常體驗(yàn)到與智能助手進(jìn)行連貫多輪對(duì)話的便利性。但目前我們的系統(tǒng)還不支持此功能代碼如下modelChatDeepSeek(modeldeepseek-chat) print(model.invoke(你好啊,我的名字叫王小明).content) print(model.invoke(你知道我的名字叫什么嗎).content)這里我們可以發(fā)現(xiàn)雖然我們?cè)诘谝欢螌?duì)話的時(shí)候就告訴了AI我的名字但是在第二次對(duì)話的過程中AI并不知道我們的名字。在這樣的對(duì)話方式里AI并不具有存儲(chǔ)歷史消息或者說記憶的功能。解決這個(gè)問題的方式就是在每次對(duì)話的過程中應(yīng)該將歷史對(duì)話的上下文合并為一個(gè)消息列表然后傳遞給AI代碼如下message[ SystemMessage(你是一個(gè)人工智能助手), HumanMessage(你好啊,我的名字叫王小明), AIMessage(你好呀王小明很高興認(rèn)識(shí)你。), HumanMessage(你知道我的名字叫什么嗎) ] modelChatDeepSeek(modeldeepseek-chat) print(model.invoke(message).content)可以看到當(dāng)我們將歷史上下文傳遞給AI的時(shí)候就能發(fā)現(xiàn)它能準(zhǔn)確地說出我們的名字了。換句話說只要將歷史消息重新發(fā)送給聊天模型那么就可以實(shí)現(xiàn)多輪對(duì)話的功能。1.3.2 內(nèi)存緩存那么對(duì)于歷史消息的管理就顯得尤為重要。在 LangChain 老版本中可以使用RunnableWithMessageHistory消息歷史類來包裝另一個(gè) Runnable 并為其管理聊天消息歷史記錄。它將跟蹤模型的輸入和輸出并將其存儲(chǔ)在某個(gè)數(shù)據(jù)存儲(chǔ)中。未來的交互將加載這些消息并將其作為輸入的一部分傳遞給鏈。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類初始化參數(shù)說明runnable被包裝 Runnable 實(shí)例這里就是我們定義的聊天模型Get_History_ssid返回類型為BaseChatMessageHistory的函數(shù)傳入后作為回調(diào)函數(shù)。此函數(shù)接受一個(gè)session_id字符串類型并返回相應(yīng)的聊天消息歷史記錄實(shí)例。class langchain_core.runnables.history.RunnableWithMessageHistory類方法說明.invoke()方法此方法與其他 Runnable 實(shí)例的.invoke()方法相同。只不過注意其 config 配置需要配置成config{configurable: {session_id: }}讓RunnableWithMessageHistory可以讀取到會(huì)話 id。記憶功能已經(jīng)實(shí)現(xiàn)但是需要注意的是從 LangChain 的 v0.3 版本開始官方建議 LangChain 用戶不要使用RunnableWithMessageHistory而是利用 LangGraph 持久性 來完成見 LangGraph 章節(jié)。原因是它們的功能有限不太適合現(xiàn)實(shí)世界的對(duì)話式 AI 應(yīng)用程序。這些內(nèi)存抽象缺乏對(duì)多用戶、多對(duì)話場(chǎng)景的內(nèi)置支持而這對(duì)于實(shí)際的對(duì)話式人工智能系統(tǒng)至關(guān)重要。這些實(shí)現(xiàn)中的大多數(shù)已在 LangChain 0.3.x 中被正式棄用取而代之的是 LangGraph 持久性。LangGraph 持久性 非常靈活可以支持比RunnableWithMessageHistory接口更廣泛的用例。我們會(huì)在 LangGraph 篇章中學(xué)習(xí)它因此RunnableWithMessageHistory這部分我們講解的并不深入。在之前對(duì)于生產(chǎn)環(huán)境我們還需要使用聊天消息歷史記錄的持久化實(shí)現(xiàn)例如RedisChatMessageHistory()而不是InMemoryChatMessageHistory()但現(xiàn)在也已不推薦新應(yīng)用使用它們了。1.4 管理歷史消息1.4.1 前置概念1.4.1.1 上下文窗口管理歷史消息無非就是理解如何 “管理”“管理” 無非也就是一些 “CRUD”。那么在了解如何管理消息之前需要先了解下多輪對(duì)話的核心概念上下文窗口。上下文窗口可以理解為模型的 “短期工作記憶區(qū)”即 LLM 在一次處理請(qǐng)求時(shí)所能查看和處理的最大 Token 數(shù)量它包含了用戶的輸入大模型的輸出有時(shí)還包括系統(tǒng)指令SystemMessage和對(duì)話歷史。不同大模型支持的上下文窗口大小不同例如OpenAI 下 GPT?5 模型上下文窗口為 400000最大 Token 數(shù)量GPT?4.1 模型上下文窗口為 1047576最大 Token 數(shù)量其他模型上下文窗口可參考對(duì)應(yīng)模型官網(wǎng)說明如 OpenAI 下模型可以參考這里。1.4.1.2 Token在自然語(yǔ)言處理NLP中Token 是文本的基本單位。它不是完全等同于一個(gè)單詞或一個(gè)漢字而是一個(gè)更細(xì)粒度的劃分。為什么用 Token計(jì)算機(jī)無法直接理解文字它需要將文本轉(zhuǎn)換為數(shù)字向量。Tokenization令牌化就是這個(gè)轉(zhuǎn)換過程的第一步將句子分解成模型可以理解和處理的碎片。對(duì)于英文1 個(gè) Token ~ 4 個(gè)字符或 0.75 個(gè)單詞1000 個(gè) Tokens 約等于 750 個(gè)英文單詞。一個(gè) Token 可以是一個(gè)單詞如apple、一個(gè)詞根如un在unlikely中或者一個(gè)標(biāo)點(diǎn)符號(hào)如.。例如ChatGPT is great!可能會(huì)被分成[Chat, G, PT, is, great, !]這 6 個(gè) Token。對(duì)于中文1 個(gè)漢字 1.5?2 個(gè) Tokens1000 個(gè) Tokens 大約相當(dāng)于 500?700 個(gè)漢字。常見的詞和字可能是一個(gè) Token生僻字或復(fù)雜詞可能會(huì)被拆分成多個(gè)。舉個(gè)例子上下文窗口就像一個(gè)固定大小的工作臺(tái)再把 Token 比作一個(gè)積木零件把大模型比作一個(gè)工匠。工匠需要拼出模型必須把所需的零件輸入的 Token放在工作臺(tái)上一邊拼裝生成回復(fù)一邊把拼好的部分輸出的 Token也放在工作臺(tái)上。整個(gè)過程輸入 輸出中工作臺(tái)上的所有積木Tokens總數(shù)都不能超過工作臺(tái)的最大容量上下文窗口大小。如果最初的零件太多占滿了工作臺(tái)工匠就沒有空間進(jìn)行拼裝了。這時(shí)你就需要減少零件精簡(jiǎn)輸入。如果最初的零件太多占滿了工作臺(tái)工匠就沒有空間進(jìn)行拼裝了。這時(shí)你就需要減少零件精簡(jiǎn)輸入1.4.2 消息裁剪有了上下文窗口和 Token 的認(rèn)知再來看多輪對(duì)話的實(shí)現(xiàn)原理其實(shí)就是輸入 系統(tǒng)消息 對(duì)話歷史 最新用戶問題對(duì)于模型來說并不真正 “記憶”而是每次都將完整的上下文重新輸入。由于所有模型的上下文窗口大小都是有限的這意味著作為輸入的 Token 也是有限的。如果有累積了很長(zhǎng)的消息歷史記錄則需要管理傳遞給模型的消息的長(zhǎng)度。trim_messages可用于將聊天歷史記錄的大小減小為指定的令牌計(jì)數(shù)或指定的消息計(jì)數(shù)。1.4.2.1 基于輸入 Token 數(shù)的修剪下面演示一個(gè)通過trim_messages裁剪消息的示例基于輸入 Token 數(shù)的修剪。先來看看不做任何輸入限制的聊天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))運(yùn)行結(jié)果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: {}}在運(yùn)行結(jié)果的usage_metadata字段我們可以看到這些屬性u(píng)sage_metadata{input_tokens: 64, output_tokens: 7, total_tokens: 71, input_token_details: {cache_read: 0}, output_token_details: {}}從打印結(jié)果來看LLM 還認(rèn)識(shí)我們且共輸入了 64 tokens。接下來讓我們對(duì)消息進(jìn)行裁剪我們只希望將來輸入時(shí)最多輸入 50 tokens超出的需要按照一定的 “規(guī)則” 進(jìn)行裁剪代碼如下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計(jì)數(shù)器tiktoken估算不需要導(dǎo)入不存在的函數(shù) 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 減少發(fā)送給模型的消息數(shù)量 trimmer trim_messages( max_tokens50, # 修剪消息的最大令牌數(shù)根據(jù)你想要的談話長(zhǎng)度來調(diào)整 strategylast, # 修剪策略: # last(默認(rèn)): 保留最后的消息。 # first: 保留最早的消息。 token_countertiktoken_counter, # 傳入一個(gè)函數(shù)或一個(gè)語(yǔ)言模型(因?yàn)檎Z(yǔ)言模型有消息令牌計(jì)數(shù)方法) include_systemTrue, # 如果想始終保留初始系統(tǒng)消息可以指定 allow_partialFalse, # 是否允許拆分消息的內(nèi)容 start_onhuman, # 如果需要確保我們的第一條消息(不包括系統(tǒng)消息)始終是特定類型可以指定 start_on ) chain trimmer | model print(chain.invoke(message))運(yùn)行結(jié)果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: {}}此時(shí)我們可以發(fā)現(xiàn)我們的歷史消息被裁剪了AI并不知道我們的名字是誰。被修剪了哪些消息呢來看下print(trimmer.invoke(message))輸出結(jié)果[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{})]從結(jié)果來看確實(shí)是按照我們給定的裁剪 “規(guī)則” 來完成的。修剪聊天記錄后生成的聊天記錄輸入應(yīng)該有效需遵循對(duì)話模式原則聊天記錄以HumanMessage或SystemMessage開頭后跟HumanMessage。這可以通過設(shè)置start_onhuman來實(shí)現(xiàn)。聊天記錄以HumanMessage或ToolMessage結(jié)尾。這可以通過設(shè)置ends_on(human, tool)來實(shí)現(xiàn)。ToolMessage只能出現(xiàn)在涉及工具調(diào)用的AIMessage之后。如果原始聊天歷史記錄中存在SystemMessage則新聊天歷史記錄應(yīng)包括SystemMessage因?yàn)镾ystemMessage包含對(duì)聊天模型的特殊說明。SystemMessage總是歷史記錄中的第一條消息如果存在。這可以通過設(shè)置include_systemTrue。1.4.2.2 基于消息數(shù)的修剪除了基于 token 的修剪還可以通過設(shè)置token_counterlen根據(jù)消息數(shù)修剪聊天記錄。在這種情況下max_tokens將控制最大消息數(shù)。示例如下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 減少發(fā)送給模型的消息數(shù)量 trimmer trim_messages( max_tokens11, # 修剪消息的最大令牌數(shù)根據(jù)你想要的談話長(zhǎng)度來調(diào)整 strategylast, # 修剪策略: # last(默認(rèn)): 保留最后的消息。 # first: 保留最早的消息。 token_counterlen, # 傳入一個(gè)函數(shù)或一個(gè)語(yǔ)言模型(因?yàn)檎Z(yǔ)言模型有消息令牌計(jì)數(shù)方法) include_systemTrue, # 如果想始終保留初始系統(tǒng)消息可以指定也就是第一個(gè)SyStemMessage allow_partialFalse, # 是否允許拆分消息的內(nèi)容 start_onhuman, # 如果需要確保我們的第一條消息(不包括系統(tǒng)消息)始終是特定類型可以指定 start_on ) chain trimmer | model print(trimmer.invoke(message))運(yùn)行結(jié)果[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{})]可以看到代碼中我們指定了最大消息數(shù)為11個(gè)消息。并且第一個(gè)消息必須是HumanMessage所以一共裁剪掉了除系統(tǒng)消息之外最早的兩個(gè)消息如圖1.4.3 消息過濾按類型進(jìn)行篩選在更復(fù)雜的場(chǎng)景下我們可能會(huì)使用消息列表來跟蹤狀態(tài)例如我們可能只想將這個(gè)完整消息列表的子集傳遞模型調(diào)用而不是所有的歷史記錄。filter_messages方法則可以輕松地按類型、ID 或名稱過濾 message。如以下代碼的效果就是獲取message消息列表中的所有HumanMessage:message[ SystemMessage(content你是一個(gè)人工智能助手,id1), HumanMessage(content示例輸入,id2), AIMessage(content示例輸出,id3), HumanMessage(content示例輸入,id4), AIMessage(content示例輸出,id5) ] #獲取mesage這個(gè)消息列表中所有的HumanMessage并打印 print(filter_messages(message, include_typeshuman)) #等價(jià)于 # print(filter_messages( include_typeshuman).invoke(message))運(yùn)行結(jié)果[HumanMessage(content示例輸入, additional_kwargs{}, response_metadata{}, id2), HumanMessage(content示例輸入, additional_kwargs{}, response_metadata{}, id4)]按類型 ID 進(jìn)行篩選獲取mesage這個(gè)消息列表中所有除了id3的HumanMessage與AIMessage并打印message[ SystemMessage(content你是一個(gè)人工智能助手,id1), HumanMessage(content示例輸入,id2), AIMessage(content示例輸出,id3), HumanMessage(content示例輸入,id4), AIMessage(content示例輸出,id5) ] #獲取mesage這個(gè)消息列表中所有除了id3的HumanMessage與AIMessage并打印 print(filter_messages(message, include_types[HumanMessage,AIMessage],exclude_ids3)) #等價(jià)于 #print(filter_messages( include_types[HumanMessage,AIMessage],exclude_ids3).invoke(message))運(yùn)行結(jié)果[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 消息合并若我們的消息列表存在連續(xù)某種類型相同的消息但實(shí)際上某些模型不支持傳遞相同類型的連續(xù)消息。因此對(duì)于這種情況我們可以使用merge_message_runs方法輕松合并相同類型的連續(xù)消息。# 定義大模型 model ChatDeepSeek(modeldeepseek-chat) # 歷史消息記錄 messages [ SystemMessage(你是一個(gè)聊天助手。), SystemMessage(你總是以笑話回應(yīng)。), HumanMessage(為什么要使用 LangChain?), HumanMessage(為什么要使用 LangGraph?), AIMessage(因?yàn)楫?dāng)你試圖讓你的代碼更有條理時(shí)LangGraph 會(huì)讓你感到“節(jié)點(diǎn)”是個(gè)好主意), AIMessage(不過別擔(dān)心它不會(huì)“分散”你的注意力), HumanMessage(選擇LangChain還是LangGraph?), ] mergemerge_message_runs(messages) #調(diào)用大模型方法一 print(model.invoke(messages).content) # #調(diào)用大模型方法二 # mergemerge_message_runs() # # chainmerge | model # # print(chain.invoke(messages).content)運(yùn)行結(jié)果選 LangChain 還是 LangGraph這就像問“我該用錘子還是螺絲刀”——如果我想把代碼釘進(jìn)墻里就選 LangChain如果我想畫一幅流程圖選 LangGraph 準(zhǔn)沒錯(cuò)不過說真的如果你總是選錯(cuò)我們可能需要聊聊“鏈”接心理醫(yī)生的問題了