存了，持久化這次講具體：ChatMemoryStore 落庫與 TokenWindow 裁剪實(shí)戰(zhàn))
1. 從內(nèi)存態(tài)到持久化LangChain4j 聊天記憶為什么必須落庫LangChain4j 的 ChatMemory 是很多 Java 后端接入大模型時(shí)最先接觸的組件它負(fù)責(zé)決定「模型這一輪能看到哪些歷史消息」。默認(rèn)的MessageWindowChatMemory配合InMemoryChatMemoryStore在單機(jī) demo 里跑得飛快但一旦進(jìn)入真實(shí)業(yè)務(wù)問題會(huì)集中爆發(fā)服務(wù)重啟后上下文全丟、多實(shí)例部署時(shí)同一會(huì)話被路由到不同節(jié)點(diǎn)導(dǎo)致「AI 失憶」、會(huì)話歷史無限增長把 token 成本頂穿、用戶申請(qǐng)刪除會(huì)話時(shí)底層沒有按 memoryId 清理的能力。這些問題的根因是把「模型看到什么」和「記憶存在哪里」這兩件事混在了一起。LangChain4j 的設(shè)計(jì)其實(shí)分得很清楚ChatMemory管前者ChatMemoryStore管后者。你只要把 Store 換成自定義實(shí)現(xiàn)記憶就能落到 MySQL、Redis 或文檔庫跨實(shí)例、跨重啟恢復(fù)上下文再配合MessageWindow或TokenWindow兩種裁剪策略就能把每次請(qǐng)求的上下文長度控制在預(yù)算內(nèi)。這篇面向的是已經(jīng)用 LangChain4j 跑通過單輪對(duì)話、準(zhǔn)備把多輪會(huì)話搬上生產(chǎn)的 Java 開發(fā)者。我會(huì)按真實(shí)項(xiàng)目落地的順序講先看內(nèi)存態(tài)在哪些場(chǎng)景會(huì)翻車再給出可復(fù)制的ChatMemoryStore實(shí)現(xiàn)接著分別配置MessageWindowChatMemory和TokenWindowChatMemory然后跑多輪對(duì)話驗(yàn)證重啟恢復(fù)最后把常見報(bào)錯(cuò)逐個(gè)排掉。全程代碼可直接粘進(jìn) Spring Boot 工程數(shù)據(jù)庫用 MySQL 舉例Redis 思路一致。需要先明確一個(gè)邊界ChatMemory 不是完整的歷史歸檔系統(tǒng)。它的職責(zé)是「給模型喂最近的關(guān)鍵上下文」而不是「保存用戶說過的每一句話」。真正的全量歷史、審計(jì)、摘要?dú)w檔應(yīng)該由業(yè)務(wù)側(cè)的會(huì)話表承擔(dān)。把這兩層分開后面的設(shè)計(jì)會(huì)順很多。2. TaoToken 前置準(zhǔn)備拿到 Base URL、API Key 和 Model ID在寫 Store 之前先把模型調(diào)用通道打通否則后面驗(yàn)證多輪對(duì)話時(shí)沒法確認(rèn)「記憶恢復(fù)」和「模型響應(yīng)」是不是同一件事。我用 TaoToken 作為模型接入層它兼容 OpenAI 風(fēng)格的接口LangChain4j 的OpenAiChatModel可以直接對(duì)接。你需要準(zhǔn)備三樣?xùn)|西這三件套在任何 LangChain4j 接入場(chǎng)景里都要寫全配置項(xiàng)取值來源示例Base URLTaoToken API 地址https://taotoken.net/apiAPI Key控制臺(tái)創(chuàng)建的密鑰sk-xxxxxxxxModel ID模型列表里的標(biāo)識(shí)gpt-4o-mini或你選用的模型先到 TaoToken 控制臺(tái) 創(chuàng)建 API Key路徑在「API Keys」頁面。創(chuàng)建后復(fù)制保存頁面只展示一次。模型 ID 可以在模型對(duì)話頁面確認(rèn)選一個(gè)支持多輪對(duì)話的即可。拿到三件套后先在application.yml里配置避免硬編碼langchain4j: openai: base-url: https://taotoken.net/api api-key: ${TAOTOKEN_API_KEY} model-name: gpt-4o-mini temperature: 0.7 timeout: PT60S對(duì)應(yīng)的OpenAiChatModelBeanConfiguration public class ChatModelConfig { Value(${langchain4j.openai.base-url}) private String baseUrl; Value(${langchain4j.openai.api-key}) private String apiKey; Value(${langchain4j.openai.model-name}) private String modelName; Bean public ChatModel chatModel() { return OpenAiChatModel.builder() .baseUrl(baseUrl) .apiKey(apiKey) .modelName(modelName) .temperature(0.7) .timeout(Duration.ofSeconds(60)) .build(); } }這里有個(gè)容易踩的點(diǎn)baseUrl末尾不要帶/v1LangChain4j 的 OpenAI 客戶端會(huì)自己拼接路徑。如果你填成https://taotoken.net/api/v1請(qǐng)求會(huì)變成/api/v1/v1/chat/completions直接 404。我試過在配置里多寫一段路徑排查了半小時(shí)才發(fā)現(xiàn)是重復(fù)拼接。依賴方面pom.xml至少要有dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-open-ai/artifactId version0.35.0/version /dependency dependency groupIddev.langchain4j/groupId artifactIdlangchain4j/artifactId version0.35.0/version /dependency版本號(hào)按你項(xiàng)目實(shí)際鎖定的來LangChain4j 迭代較快ChatMemoryStore接口簽名在 0.3x 系列基本穩(wěn)定。如果你用的是 Spring Boot Starter 方式把langchain4j-open-ai-spring-boot-starter加進(jìn)來配置項(xiàng)前綴會(huì)略有不同但三件套的語義不變。通道打通后先用一個(gè)最小 main 方法驗(yàn)證單輪能通再進(jìn)入記憶持久化。這樣后面出問題時(shí)你能快速判斷是模型通道的問題還是 Store 的問題。3. 可復(fù)制配置自定義 ChatMemoryStore 落庫與兩種窗口裁剪這一節(jié)是全文核心。先給數(shù)據(jù)庫表結(jié)構(gòu)再給ChatMemoryStore實(shí)現(xiàn)最后分別配置MessageWindowChatMemory和TokenWindowChatMemory。3.1 聊天記憶表設(shè)計(jì)create table ai_chat_memory_message ( id bigint primary key auto_increment, memory_id varchar(128) not null, message_no int not null, message_type varchar(32) not null, message_json json not null, created_time datetime not null default current_timestamp, unique key uk_memory_message_no (memory_id, message_no), key idx_memory_id (memory_id) );memory_id是會(huì)話標(biāo)識(shí)建議用「租戶 用戶 業(yè)務(wù)號(hào)」拼比如tenant_a:user_1001:order_20260528001而不是隨機(jī) UUID。隨機(jī) ID 在跨天追問場(chǎng)景里沒法復(fù)用用戶第二天繼續(xù)問同一訂單系統(tǒng)認(rèn)不出來是同一會(huì)話。message_no保證同一會(huì)話內(nèi)消息有序message_json存序列化后的ChatMessage。3.2 自定義 ChatMemoryStore 實(shí)現(xiàn)Repository RequiredArgsConstructor public class MysqlChatMemoryStore implements ChatMemoryStore { private final ChatMemoryDao chatMemoryDao; Override public ListChatMessage getMessages(Object memoryId) { return chatMemoryDao.loadMessages(memoryId.toString()).stream() .map(ChatMessageJsonCodec::deserialize) .toList(); } Override public void updateMessages(Object memoryId, ListChatMessage messages) { chatMemoryDao.replaceMessages( memoryId.toString(), messages.stream().map(ChatMessageJsonCodec::serialize).toList() ); } Override public void deleteMessages(Object memoryId) { chatMemoryDao.deleteByMemoryId(memoryId.toString()); } }ChatMessageJsonCodec是 LangChain4j 自帶的編解碼工具能正確處理UserMessage、AiMessage、SystemMessage、ToolExecutionResultMessage等類型。不要自己用 Jackson 直接序列化ChatMessage接口反序列化時(shí)會(huì)因?yàn)槎鄳B(tài)類型丟失而報(bào)錯(cuò)。DAO 層用replaceMessages做全量替換配合唯一鍵uk_memory_message_no可以用insert ... on duplicate key update或先刪后插。數(shù)據(jù)量大時(shí)建議按memory_id分批避免單次事務(wù)過大。3.3 MessageWindow 版本配置ChatMemory chatMemory MessageWindowChatMemory.builder() .id(tenant_a:user_1001:order_20260528001) .maxMessages(20) .chatMemoryStore(new MysqlChatMemoryStore(chatMemoryDao)) .build();maxMessages(20)表示保留最近 20 條消息。注意它按「條數(shù)」裁剪不區(qū)分消息長短。如果用戶發(fā)了一條超長文本20 條也可能撐爆上下文。適合消息長度相對(duì)均勻的客服場(chǎng)景。3.4 TokenWindow 版本配置TokenCountEstimator tokenCountEstimator new OpenAiTokenCountEstimator(gpt-4o-mini); ChatMemory tokenWindowChatMemory TokenWindowChatMemory.builder() .id(tenant_a:user_1001:order_20260528001) .maxTokens(2500, tokenCountEstimator) .chatMemoryStore(new MysqlChatMemoryStore(chatMemoryDao)) .build();maxTokens(2500, estimator)按 token 數(shù)裁剪更貼近成本控制。OpenAiTokenCountEstimator需要傳入模型名不同模型的 tokenizer 不同。如果你用的是非 OpenAI 系模型可以自己實(shí)現(xiàn)TokenCountEstimator接口用近似估算比如中文按 1 字 ≈ 1.5 token也能跑。3.5 掛到 AI Servicepublic interface CustomerAssistant { String chat(MemoryId String memoryId, UserMessage String message); } CustomerAssistant assistant AiServices.builder(CustomerAssistant.class) .chatModel(chatModel) .chatMemoryProvider(memoryId - MessageWindowChatMemory.builder() .id(memoryId) .maxMessages(20) .chatMemoryStore(new MysqlChatMemoryStore(chatMemoryDao)) .build()) .build();chatMemoryProvider是關(guān)鍵每次調(diào)用時(shí)按memoryId動(dòng)態(tài)構(gòu)建 ChatMemoryStore 從數(shù)據(jù)庫讀歷史。這樣多實(shí)例部署時(shí)任意節(jié)點(diǎn)都能拿到同一份記憶。4. 驗(yàn)證請(qǐng)求多輪對(duì)話、重啟恢復(fù)與 Token 消耗觀察配置寫完后必須驗(yàn)證三件事多輪上下文是否生效、重啟后能否恢復(fù)、Token 是否被窗口控制住。4.1 多輪對(duì)話驗(yàn)證String memoryId tenant_a:user_1001:order_20260528001; String r1 assistant.chat(memoryId, 我昨天買的鞋子什么時(shí)候發(fā)貨); System.out.println(R1: r1); String r2 assistant.chat(memoryId, 訂單號(hào)是 20260528001幫我查一下); System.out.println(R2: r2); String r3 assistant.chat(memoryId, 那能改地址嗎); System.out.println(R3: r3);第三輪里沒有重復(fù)訂單號(hào)如果模型能正確關(guān)聯(lián)到前兩輪的訂單說明記憶生效。跑完后查數(shù)據(jù)庫select message_no, message_type, left(message_json, 80) from ai_chat_memory_message where memory_id tenant_a:user_1001:order_20260528001 order by message_no;你應(yīng)該能看到 user/ai 交替的消息記錄message_no連續(xù)遞增。4.2 重啟恢復(fù)驗(yàn)證停掉服務(wù)重新啟動(dòng)用同一個(gè)memoryId再發(fā)一輪String r4 assistant.chat(memoryId, 剛才說的地址修改進(jìn)度怎么樣了); System.out.println(R4: r4);如果 R4 能接上「地址修改」這個(gè)上下文說明 Store 從數(shù)據(jù)庫成功回讀。這一步是內(nèi)存態(tài)和持久化的分水嶺內(nèi)存態(tài)在這里必然失憶。4.3 Token 消耗觀察在MysqlChatMemoryStore.getMessages里加一行日志打印每次回讀的消息條數(shù)和估算 tokenOverride public ListChatMessage getMessages(Object memoryId) { ListChatMessage messages chatMemoryDao.loadMessages(memoryId.toString()).stream() .map(ChatMessageJsonCodec::deserialize) .toList(); log.info(memoryId{}, loadedMessages{}, memoryId, messages.size()); return messages; }連續(xù)對(duì)話 30 輪后觀察日志MessageWindow版本會(huì)穩(wěn)定在 20 條左右TokenWindow版本的消息條數(shù)會(huì)隨單條長度浮動(dòng)但總 token 不會(huì)超過 2500。這就是窗口裁剪在起作用。如果你需要更精細(xì)的成本觀測(cè)可以在 TaoToken 的模型對(duì)話頁面手動(dòng)對(duì)比不同窗口參數(shù)下的響應(yīng)差異確認(rèn)裁剪沒有丟掉關(guān)鍵上下文。5. 本篇常見錯(cuò)排查401、local proxy failed、reading choices、OAuth這一節(jié)按真實(shí)報(bào)錯(cuò)逐個(gè)排。每個(gè)報(bào)錯(cuò)都給出觸發(fā)條件和修復(fù)動(dòng)作。401 UnauthorizedAPI Key 沒配或配錯(cuò)。檢查TAOTOKEN_API_KEY環(huán)境變量是否注入application.yml里是否寫成了字面量${TAOTOKEN_API_KEY}而沒被解析。另外確認(rèn) Key 沒有多余空格復(fù)制時(shí)容易帶上換行。local proxy failed / connection refusedBase URL 寫錯(cuò)或網(wǎng)絡(luò)不通。確認(rèn)base-url是https://taotoken.net/api不帶/v1不帶末尾斜杠。如果你本地配了 HTTP 代理環(huán)境變量先臨時(shí)清掉再試避免請(qǐng)求被錯(cuò)誤轉(zhuǎn)發(fā)。Error reading choices / choices is null模型返回體解析失敗。常見原因是 Model ID 寫錯(cuò)或者該模型不支持當(dāng)前請(qǐng)求格式?；氐侥Ｐ蛯?duì)話頁面核對(duì) Model ID 拼寫確認(rèn)它支持 chat completions。OAuth / token expired如果你用的是需要 OAuth 的接入方式token 過期會(huì)導(dǎo)致 401。改用 API Key 方式即可繞開。LangChain4j 的OpenAiChatModel走的是 Key 認(rèn)證不需要 OAuth 流程。ChatMessage 反序列化報(bào)錯(cuò)不要用 Jackson 直接反序列化ChatMessage接口用ChatMessageJsonCodec。如果歷史數(shù)據(jù)里混入了舊版本序列化格式清掉對(duì)應(yīng)memory_id的記錄重跑。memoryId 串上下文檢查memoryId生成邏輯確保「租戶 用戶 業(yè)務(wù)號(hào)」唯一。如果兩個(gè)不同訂單共用了同一個(gè)memoryId模型會(huì)把兩個(gè)訂單的信息混在一起回答。窗口裁剪后模型答非所問maxMessages或maxTokens設(shè)得太小把關(guān)鍵上下文裁掉了。先把窗口調(diào)大驗(yàn)證再逐步收緊到成本可接受的值。6. 語義一致 CTA把記憶持久化接進(jìn)你的編碼工作流記憶持久化跑通后下一步通常是把它接進(jìn)更完整的 Agent 或編碼輔助流程。如果你在做長期編碼類項(xiàng)目需要模型在多輪會(huì)話里持續(xù)記住項(xiàng)目上下文可以看 Coding Plan它更適合長會(huì)話、多輪迭代的場(chǎng)景。接入過程中如果卡在 Key 或權(quán)限配置直接去 API Keys 頁面重新生成一個(gè)配合接入文檔核對(duì)參數(shù)。文檔里對(duì) Base URL、Model ID 和請(qǐng)求格式有完整說明比在代碼里反復(fù)試錯(cuò)快得多。最后給一個(gè)實(shí)用建議把ChatMemoryStore的讀寫日志和窗口裁剪日志分開打前者看恢復(fù)是否成功后者看成本是否受控。這兩個(gè)指標(biāo)穩(wěn)定后再考慮加摘要層用 conversation summary 替代被裁掉的舊消息這樣既省 token 又不丟關(guān)鍵信息。 LangChain4j 的聊天記憶別只放內(nèi)存了，持久化這次講具體：ChatMemoryStore 落庫與 TokenWindow 裁剪實(shí)戰(zhàn)
1. 從內(nèi)存態(tài)到持久化LangChain4j 聊天記憶為什么必須落庫LangChain4j 的 ChatMemory 是很多 Java 后端接入大模型時(shí)最先接觸的組件它負(fù)責(zé)決定「模型這一輪能看到哪些歷史消息」。默認(rèn)的MessageWindowChatMemory配合InMemoryChatMemoryStore在單機(jī) demo 里跑得飛快但一旦進(jìn)入真實(shí)業(yè)務(wù)問題會(huì)集中爆發(fā)服務(wù)重啟后上下文全丟、多實(shí)例部署時(shí)同一會(huì)話被路由到不同節(jié)點(diǎn)導(dǎo)致「AI 失憶」、會(huì)話歷史無限增長把 token 成本頂穿、用戶申請(qǐng)刪除會(huì)話時(shí)底層沒有按 memoryId 清理的能力。這些問題的根因是把「模型看到什么」和「記憶存在哪里」這兩件事混在了一起。LangChain4j 的設(shè)計(jì)其實(shí)分得很清楚ChatMemory管前者ChatMemoryStore管后者。你只要把 Store 換成自定義實(shí)現(xiàn)記憶就能落到 MySQL、Redis 或文檔庫跨實(shí)例、跨重啟恢復(fù)上下文再配合MessageWindow或TokenWindow兩種裁剪策略就能把每次請(qǐng)求的上下文長度控制在預(yù)算內(nèi)。這篇面向的是已經(jīng)用 LangChain4j 跑通過單輪對(duì)話、準(zhǔn)備把多輪會(huì)話搬上生產(chǎn)的 Java 開發(fā)者。我會(huì)按真實(shí)項(xiàng)目落地的順序講先看內(nèi)存態(tài)在哪些場(chǎng)景會(huì)翻車再給出可復(fù)制的ChatMemoryStore實(shí)現(xiàn)接著分別配置MessageWindowChatMemory和TokenWindowChatMemory然后跑多輪對(duì)話驗(yàn)證重啟恢復(fù)最后把常見報(bào)錯(cuò)逐個(gè)排掉。全程代碼可直接粘進(jìn) Spring Boot 工程數(shù)據(jù)庫用 MySQL 舉例Redis 思路一致。需要先明確一個(gè)邊界ChatMemory 不是完整的歷史歸檔系統(tǒng)。它的職責(zé)是「給模型喂最近的關(guān)鍵上下文」而不是「保存用戶說過的每一句話」。真正的全量歷史、審計(jì)、摘要?dú)w檔應(yīng)該由業(yè)務(wù)側(cè)的會(huì)話表承擔(dān)。把這兩層分開后面的設(shè)計(jì)會(huì)順很多。2. TaoToken 前置準(zhǔn)備拿到 Base URL、API Key 和 Model ID在寫 Store 之前先把模型調(diào)用通道打通否則后面驗(yàn)證多輪對(duì)話時(shí)沒法確認(rèn)「記憶恢復(fù)」和「模型響應(yīng)」是不是同一件事。我用 TaoToken 作為模型接入層它兼容 OpenAI 風(fēng)格的接口LangChain4j 的OpenAiChatModel可以直接對(duì)接。你需要準(zhǔn)備三樣?xùn)|西這三件套在任何 LangChain4j 接入場(chǎng)景里都要寫全配置項(xiàng)取值來源示例Base URLTaoToken API 地址https://taotoken.net/apiAPI Key控制臺(tái)創(chuàng)建的密鑰sk-xxxxxxxxModel ID模型列表里的標(biāo)識(shí)gpt-4o-mini或你選用的模型先到 TaoToken 控制臺(tái) 創(chuàng)建 API Key路徑在「API Keys」頁面。創(chuàng)建后復(fù)制保存頁面只展示一次。模型 ID 可以在模型對(duì)話頁面確認(rèn)選一個(gè)支持多輪對(duì)話的即可。拿到三件套后先在application.yml里配置避免硬編碼langchain4j: openai: base-url: https://taotoken.net/api api-key: ${TAOTOKEN_API_KEY} model-name: gpt-4o-mini temperature: 0.7 timeout: PT60S對(duì)應(yīng)的OpenAiChatModelBeanConfiguration public class ChatModelConfig { Value(${langchain4j.openai.base-url}) private String baseUrl; Value(${langchain4j.openai.api-key}) private String apiKey; Value(${langchain4j.openai.model-name}) private String modelName; Bean public ChatModel chatModel() { return OpenAiChatModel.builder() .baseUrl(baseUrl) .apiKey(apiKey) .modelName(modelName) .temperature(0.7) .timeout(Duration.ofSeconds(60)) .build(); } }這里有個(gè)容易踩的點(diǎn)baseUrl末尾不要帶/v1LangChain4j 的 OpenAI 客戶端會(huì)自己拼接路徑。如果你填成https://taotoken.net/api/v1請(qǐng)求會(huì)變成/api/v1/v1/chat/completions直接 404。我試過在配置里多寫一段路徑排查了半小時(shí)才發(fā)現(xiàn)是重復(fù)拼接。依賴方面pom.xml至少要有dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-open-ai/artifactId version0.35.0/version /dependency dependency groupIddev.langchain4j/groupId artifactIdlangchain4j/artifactId version0.35.0/version /dependency版本號(hào)按你項(xiàng)目實(shí)際鎖定的來LangChain4j 迭代較快ChatMemoryStore接口簽名在 0.3x 系列基本穩(wěn)定。如果你用的是 Spring Boot Starter 方式把langchain4j-open-ai-spring-boot-starter加進(jìn)來配置項(xiàng)前綴會(huì)略有不同但三件套的語義不變。通道打通后先用一個(gè)最小 main 方法驗(yàn)證單輪能通再進(jìn)入記憶持久化。這樣后面出問題時(shí)你能快速判斷是模型通道的問題還是 Store 的問題。3. 可復(fù)制配置自定義 ChatMemoryStore 落庫與兩種窗口裁剪這一節(jié)是全文核心。先給數(shù)據(jù)庫表結(jié)構(gòu)再給ChatMemoryStore實(shí)現(xiàn)最后分別配置MessageWindowChatMemory和TokenWindowChatMemory。3.1 聊天記憶表設(shè)計(jì)create table ai_chat_memory_message ( id bigint primary key auto_increment, memory_id varchar(128) not null, message_no int not null, message_type varchar(32) not null, message_json json not null, created_time datetime not null default current_timestamp, unique key uk_memory_message_no (memory_id, message_no), key idx_memory_id (memory_id) );memory_id是會(huì)話標(biāo)識(shí)建議用「租戶 用戶 業(yè)務(wù)號(hào)」拼比如tenant_a:user_1001:order_20260528001而不是隨機(jī) UUID。隨機(jī) ID 在跨天追問場(chǎng)景里沒法復(fù)用用戶第二天繼續(xù)問同一訂單系統(tǒng)認(rèn)不出來是同一會(huì)話。message_no保證同一會(huì)話內(nèi)消息有序message_json存序列化后的ChatMessage。3.2 自定義 ChatMemoryStore 實(shí)現(xiàn)Repository RequiredArgsConstructor public class MysqlChatMemoryStore implements ChatMemoryStore { private final ChatMemoryDao chatMemoryDao; Override public ListChatMessage getMessages(Object memoryId) { return chatMemoryDao.loadMessages(memoryId.toString()).stream() .map(ChatMessageJsonCodec::deserialize) .toList(); } Override public void updateMessages(Object memoryId, ListChatMessage messages) { chatMemoryDao.replaceMessages( memoryId.toString(), messages.stream().map(ChatMessageJsonCodec::serialize).toList() ); } Override public void deleteMessages(Object memoryId) { chatMemoryDao.deleteByMemoryId(memoryId.toString()); } }ChatMessageJsonCodec是 LangChain4j 自帶的編解碼工具能正確處理UserMessage、AiMessage、SystemMessage、ToolExecutionResultMessage等類型。不要自己用 Jackson 直接序列化ChatMessage接口反序列化時(shí)會(huì)因?yàn)槎鄳B(tài)類型丟失而報(bào)錯(cuò)。DAO 層用replaceMessages做全量替換配合唯一鍵uk_memory_message_no可以用insert ... on duplicate key update或先刪后插。數(shù)據(jù)量大時(shí)建議按memory_id分批避免單次事務(wù)過大。3.3 MessageWindow 版本配置ChatMemory chatMemory MessageWindowChatMemory.builder() .id(tenant_a:user_1001:order_20260528001) .maxMessages(20) .chatMemoryStore(new MysqlChatMemoryStore(chatMemoryDao)) .build();maxMessages(20)表示保留最近 20 條消息。注意它按「條數(shù)」裁剪不區(qū)分消息長短。如果用戶發(fā)了一條超長文本20 條也可能撐爆上下文。適合消息長度相對(duì)均勻的客服場(chǎng)景。3.4 TokenWindow 版本配置TokenCountEstimator tokenCountEstimator new OpenAiTokenCountEstimator(gpt-4o-mini); ChatMemory tokenWindowChatMemory TokenWindowChatMemory.builder() .id(tenant_a:user_1001:order_20260528001) .maxTokens(2500, tokenCountEstimator) .chatMemoryStore(new MysqlChatMemoryStore(chatMemoryDao)) .build();maxTokens(2500, estimator)按 token 數(shù)裁剪更貼近成本控制。OpenAiTokenCountEstimator需要傳入模型名不同模型的 tokenizer 不同。如果你用的是非 OpenAI 系模型可以自己實(shí)現(xiàn)TokenCountEstimator接口用近似估算比如中文按 1 字 ≈ 1.5 token也能跑。3.5 掛到 AI Servicepublic interface CustomerAssistant { String chat(MemoryId String memoryId, UserMessage String message); } CustomerAssistant assistant AiServices.builder(CustomerAssistant.class) .chatModel(chatModel) .chatMemoryProvider(memoryId - MessageWindowChatMemory.builder() .id(memoryId) .maxMessages(20) .chatMemoryStore(new MysqlChatMemoryStore(chatMemoryDao)) .build()) .build();chatMemoryProvider是關(guān)鍵每次調(diào)用時(shí)按memoryId動(dòng)態(tài)構(gòu)建 ChatMemoryStore 從數(shù)據(jù)庫讀歷史。這樣多實(shí)例部署時(shí)任意節(jié)點(diǎn)都能拿到同一份記憶。4. 驗(yàn)證請(qǐng)求多輪對(duì)話、重啟恢復(fù)與 Token 消耗觀察配置寫完后必須驗(yàn)證三件事多輪上下文是否生效、重啟后能否恢復(fù)、Token 是否被窗口控制住。4.1 多輪對(duì)話驗(yàn)證String memoryId tenant_a:user_1001:order_20260528001; String r1 assistant.chat(memoryId, 我昨天買的鞋子什么時(shí)候發(fā)貨); System.out.println(R1: r1); String r2 assistant.chat(memoryId, 訂單號(hào)是 20260528001幫我查一下); System.out.println(R2: r2); String r3 assistant.chat(memoryId, 那能改地址嗎); System.out.println(R3: r3);第三輪里沒有重復(fù)訂單號(hào)如果模型能正確關(guān)聯(lián)到前兩輪的訂單說明記憶生效。跑完后查數(shù)據(jù)庫select message_no, message_type, left(message_json, 80) from ai_chat_memory_message where memory_id tenant_a:user_1001:order_20260528001 order by message_no;你應(yīng)該能看到 user/ai 交替的消息記錄message_no連續(xù)遞增。4.2 重啟恢復(fù)驗(yàn)證停掉服務(wù)重新啟動(dòng)用同一個(gè)memoryId再發(fā)一輪String r4 assistant.chat(memoryId, 剛才說的地址修改進(jìn)度怎么樣了); System.out.println(R4: r4);如果 R4 能接上「地址修改」這個(gè)上下文說明 Store 從數(shù)據(jù)庫成功回讀。這一步是內(nèi)存態(tài)和持久化的分水嶺內(nèi)存態(tài)在這里必然失憶。4.3 Token 消耗觀察在MysqlChatMemoryStore.getMessages里加一行日志打印每次回讀的消息條數(shù)和估算 tokenOverride public ListChatMessage getMessages(Object memoryId) { ListChatMessage messages chatMemoryDao.loadMessages(memoryId.toString()).stream() .map(ChatMessageJsonCodec::deserialize) .toList(); log.info(memoryId{}, loadedMessages{}, memoryId, messages.size()); return messages; }連續(xù)對(duì)話 30 輪后觀察日志MessageWindow版本會(huì)穩(wěn)定在 20 條左右TokenWindow版本的消息條數(shù)會(huì)隨單條長度浮動(dòng)但總 token 不會(huì)超過 2500。這就是窗口裁剪在起作用。如果你需要更精細(xì)的成本觀測(cè)可以在 TaoToken 的模型對(duì)話頁面手動(dòng)對(duì)比不同窗口參數(shù)下的響應(yīng)差異確認(rèn)裁剪沒有丟掉關(guān)鍵上下文。5. 本篇常見錯(cuò)排查401、local proxy failed、reading choices、OAuth這一節(jié)按真實(shí)報(bào)錯(cuò)逐個(gè)排。每個(gè)報(bào)錯(cuò)都給出觸發(fā)條件和修復(fù)動(dòng)作。401 UnauthorizedAPI Key 沒配或配錯(cuò)。檢查TAOTOKEN_API_KEY環(huán)境變量是否注入application.yml里是否寫成了字面量${TAOTOKEN_API_KEY}而沒被解析。另外確認(rèn) Key 沒有多余空格復(fù)制時(shí)容易帶上換行。local proxy failed / connection refusedBase URL 寫錯(cuò)或網(wǎng)絡(luò)不通。確認(rèn)base-url是https://taotoken.net/api不帶/v1不帶末尾斜杠。如果你本地配了 HTTP 代理環(huán)境變量先臨時(shí)清掉再試避免請(qǐng)求被錯(cuò)誤轉(zhuǎn)發(fā)。Error reading choices / choices is null模型返回體解析失敗。常見原因是 Model ID 寫錯(cuò)或者該模型不支持當(dāng)前請(qǐng)求格式?；氐侥Ｐ蛯?duì)話頁面核對(duì) Model ID 拼寫確認(rèn)它支持 chat completions。OAuth / token expired如果你用的是需要 OAuth 的接入方式token 過期會(huì)導(dǎo)致 401。改用 API Key 方式即可繞開。LangChain4j 的OpenAiChatModel走的是 Key 認(rèn)證不需要 OAuth 流程。ChatMessage 反序列化報(bào)錯(cuò)不要用 Jackson 直接反序列化ChatMessage接口用ChatMessageJsonCodec。如果歷史數(shù)據(jù)里混入了舊版本序列化格式清掉對(duì)應(yīng)memory_id的記錄重跑。memoryId 串上下文檢查memoryId生成邏輯確保「租戶 用戶 業(yè)務(wù)號(hào)」唯一。如果兩個(gè)不同訂單共用了同一個(gè)memoryId模型會(huì)把兩個(gè)訂單的信息混在一起回答。窗口裁剪后模型答非所問maxMessages或maxTokens設(shè)得太小把關(guān)鍵上下文裁掉了。先把窗口調(diào)大驗(yàn)證再逐步收緊到成本可接受的值。6. 語義一致 CTA把記憶持久化接進(jìn)你的編碼工作流記憶持久化跑通后下一步通常是把它接進(jìn)更完整的 Agent 或編碼輔助流程。如果你在做長期編碼類項(xiàng)目需要模型在多輪會(huì)話里持續(xù)記住項(xiàng)目上下文可以看 Coding Plan它更適合長會(huì)話、多輪迭代的場(chǎng)景。接入過程中如果卡在 Key 或權(quán)限配置直接去 API Keys 頁面重新生成一個(gè)配合接入文檔核對(duì)參數(shù)。文檔里對(duì) Base URL、Model ID 和請(qǐng)求格式有完整說明比在代碼里反復(fù)試錯(cuò)快得多。最后給一個(gè)實(shí)用建議把ChatMemoryStore的讀寫日志和窗口裁剪日志分開打前者看恢復(fù)是否成功后者看成本是否受控。這兩個(gè)指標(biāo)穩(wěn)定后再考慮加摘要層用 conversation summary 替代被裁掉的舊消息這樣既省 token 又不丟關(guān)鍵信息。