news 2026/10/10 4:47:14

LangChain4j Java实战：Spring Boot集成RAG与生产调优

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
LangChain4j Java实战：Spring Boot集成RAG与生产调优

1. 这不是又一个“Hello World”式LangChain4j教程——它专为Java工程师真实工作流设计

你点开这个标题，大概率是因为：刚在面试题里看到“LangChain4j和Spring Boot怎么集成”，或者团队技术选型会上被问到“Java后端能不能跑RAG？要不要自己造轮子？”，又或者正被产品经理拉着改需求：“老板说竞品加了AI对话框，咱们下周上线个类似功能”。别急着翻文档、查GitHub star数、看英文API——LangChain4j不是另一个Spring Boot Starter，它是一套面向Java工程实践的LLM应用开发范式重构工具包。我带三个Java团队落地过6个生产级AI功能模块，从客服知识库问答、合同条款智能比对，到内部技术文档摘要生成，踩过的坑比写过的代码还多。这篇教程不讲“什么是Chain”“什么是Agent”，而是直接从你IDE里打开的pom.xml开始：怎么选版本、怎么绕过Spring Boot 3.2+的自动配置陷阱、怎么让LLM调用真正稳定在99.5%成功率、怎么把企业微信消息体无缝喂给模型、怎么用Java原生方式做向量缓存而不依赖Redis集群。核心关键词就四个：LangChain4j、Java、新手入门、实战教程——但这里的“新手”，指的是有Spring Boot和Maven经验、能写MyBatis XML、知道ThreadLocal怎么用的Java工程师，不是零基础小白。如果你还在纠结“该不该学LangChain”，答案很明确：当你的业务需要把非结构化文本（PDF/Word/数据库字段）变成可编程的语义接口时，LangChain4j就是Java生态里目前最省力、最可控、最易维护的那条路。它不替代Spring，而是让你在Spring的容器里，像注入Service一样注入一个ChatModel；它不强制你改架构，而是允许你把LLM能力当成一个可降级、可熔断、可监控的普通HTTP服务来用。接下来所有内容，都来自我们线上系统的真实配置、压测数据和故障日志——没有Demo截图，只有可复制的application.yml片段、可粘贴的@Bean定义、可复现的OOM堆栈分析。

2. 为什么LangChain4j不是LangChain的Java翻译版？——从Java工程师视角重解设计哲学

2.1 核心差异：不是API移植，而是JVM生态适配

很多Java开发者第一次接触LangChain4j时，会下意识打开Python版LangChain文档对照着看，结果发现Runnable对应Runnable、Chain对应Chain，以为只是语法转换。这是最大的认知误区。LangChain4j的设计根本出发点，是解决Java生态特有的工程约束，而非复刻Python的交互式开发体验。举个最典型的例子：Python版LangChain大量使用lambda和动态属性访问（如chain.input_keys），这在Java里意味着反射、泛型擦除、运行时类型检查——而LangChain4j全部规避了这些。它的ChatModel接口强制要求实现generate(List<ChatMessage> messages)，参数是明确的List而非*args；它的RetrievalAugmenter必须返回Stream<ChatResponse>，而不是Python里那种可随意yield的生成器。这种设计背后是Java工程师每天面对的现实：

  • 编译期强校验：ChatMessage类里role字段用enum定义（USER,ASSISTANT,SYSTEM），而不是字符串常量，IDE能直接提示错误；
  • 内存模型适配：StreamingResponseHandler回调方法签名是void onNext(String token)，而非Python的async def on_new_token()，因为Java的Project Reactor和Spring WebFlux的背压机制完全不同；
  • 依赖注入友好：所有核心组件（EmbeddingModel,VectorStore,ChatMemory）都设计成Spring Bean友好的构造函数注入模式，@ConfigurationProperties能直接绑定YAML配置，不像Python需要手动load_config()。

我曾经把一个Python LangChain RAG流程迁移到Java，发现光是处理Document元数据就卡了三天——Python用字典{"source": "xxx.pdf", "page": 3}，Java如果也用Map<String, Object>，序列化时会丢失类型，导致后续过滤逻辑崩溃。LangChain4j的Document类强制要求metadata是Map<String, String>，所有值必须是字符串，这就是为了解决Java里JSON序列化/反序列化的经典坑。这不是妥协，是主动选择。

2.2 版本演进背后的工程决策：为什么必须用4.0+？

截至2024年中，LangChain4j最新稳定版是4.2.0，但很多教程还在用3.x。这里必须划重点：4.0是分水岭版本，它彻底抛弃了对Jakarta EE 8的兼容，全面拥抱Spring Boot 3.x和Jakarta EE 9+规范。这意味着什么？

  • 如果你用Spring Boot 2.7（Jakarta EE 8），强行升级LangChain4j 4.x，会遇到javax.annotation.PostConstruct找不到的错误——因为4.x只认jakarta.annotation.PostConstruct；
  • 如果你用Spring Boot 3.2+，LangChain4j 3.x的AutoConfiguration会和Spring的WebMvcConfigurer冲突，导致@ControllerAdvice全局异常处理器失效；
  • 最关键的是，4.x引入了TokenCountEstimator接口，让开发者能精确控制LLM输入token数，这对企业级应用至关重要——我们线上系统要求单次请求不超过4096 token，否则触发熔断，这个能力在3.x里只能靠正则粗略估算。

我们团队实测过不同版本的内存占用：

版本启动后堆内存占用单次RAG调用GC次数平均响应延迟（P95）
3.12186MB3.2次2.1s
4.0142MB1.8次1.4s
4.2135MB1.5次1.2s

下降的不只是数字，更是运维成本。4.x的StreamingResponseHandler默认使用SynchronousSink，避免了3.x里Flux.create()带来的线程上下文切换开销。所以，新手入门的第一步，不是学API，而是确认你的Spring Boot版本是否匹配：Spring Boot 3.0+ → LangChain4j 4.0+；Spring Boot 2.7 → 只能用LangChain4j 3.12，且必须手动排除jakarta.*依赖。

2.3 和Spring AI的定位差异：不是竞争，而是分工

最近Spring官方推出了Spring AI，很多人问“该选LangChain4j还是Spring AI？”这个问题本身就有陷阱。Spring AI本质是Spring生态的LLM抽象层，它提供AiClient、ChatClient等统一接口，底层可以插拔OpenAI、Azure、Ollama等模型；而LangChain4j是完整的LLM应用开发框架，它内置了RAG流水线、Agent调度、Tool Calling、Prompt模板引擎等一整套能力。它们的关系更像Spring Data JPA和MyBatis——前者提供标准抽象，后者提供完整解决方案。
我们实际项目中的选择策略是：

  • 如果只是简单调用LLM生成文案（比如邮件草稿、营销话术），用Spring AI +spring-ai-openai-spring-boot-starter，配置两行就完事；
  • 如果要做知识库问答（需向量化、检索、重排序）、要做多步骤Agent（先查订单状态，再判断是否需要补偿），必须用LangChain4j，因为Spring AI目前不支持Retriever、Router、ToolExecutor这些高级组件；
  • 更常见的做法是混合使用：用Spring AI管理ChatModel生命周期，用LangChain4j构建业务逻辑链。我们的订单智能助手就是这么做的——ChatModel由Spring AI的AiClient创建，但整个RAG流程（PDF解析→向量化→语义检索→上下文拼接）完全由LangChain4j的RetrievalAugmenter驱动。

提示：不要试图用Spring AI替代LangChain4j的Chain。Spring AI的AiClient.prompt()只能传入单个PromptTemplate，而LangChain4j的ChatChain支持promptTemplate+outputParser+retryPolicy三级组合，比如我们处理合同条款时，必须确保输出是JSON格式，JsonOutputParser能自动校验结构，Spring AI做不到这点。

3. 新手避坑指南：从零搭建第一个RAG应用的完整实操路径

3.1 环境准备：三步锁定稳定版本组合

新手最容易栽在依赖冲突上。我见过太多人卡在NoClassDefFoundError: jakarta/annotation/PostConstruct，其实根源就一个：没搞清Spring Boot、LangChain4j、Llama.cpp（或OpenAI Java SDK）的版本兼容矩阵。以下是经过我们生产环境验证的黄金组合（2024年Q3）：

  1. JDK版本：必须JDK 17+（Spring Boot 3.x强制要求），推荐JDK 21 LTS。注意：JDK 17的G1 GC对大对象（如PDF解析后的文本块）更友好，JDK 21的ZGC在高并发场景下停顿更短，我们线上用JDK 21 + ZGC。

  2. Spring Boot版本：3.2.5（最新稳定版）。不要用3.3.x，因为LangChain4j 4.2.0尚未完全适配其新引入的@AutoConfigurationPackage机制。

  3. LangChain4j版本：4.2.0。这是当前最平衡的选择——比4.1.0多了RetryPolicy的maxAttempts配置项，比4.3.0-beta更稳定（4.3.0-beta的MongoDBVectorStore有连接池泄漏bug）。

pom.xml关键依赖片段（务必按此顺序和版本）：

<properties> <spring-boot.version>3.2.5</spring-boot.version> <langchain4j.version>4.2.0</langchain4j.version> <openai-java.version>0.12.0</openai-java.version> </properties> <dependencies> <!-- Spring Boot Web --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <version>${spring-boot.version}</version> </dependency> <!-- LangChain4j 核心 --> <dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j</artifactId> <version>${langchain4j.version}</version> </dependency> <!-- OpenAI 模型支持 --> <dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j-openai</artifactId> <version>${langchain4j.version}</version> </dependency> <!-- 向量存储：H2嵌入式（新手首选，免部署） --> <dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j-h2-vector-store</artifactId> <version>${langchain4j.version}</version> </dependency> <!-- PDF解析（必备） --> <dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j-pdf</artifactId> <version>${langchain4j.version}</version> </dependency> </dependencies>

注意：langchain4j-h2-vector-store是新手神器。它用H2数据库模拟向量存储，启动快、无外部依赖、支持ACID事务。虽然不能用于生产（H2是内存数据库），但足够验证RAG全流程逻辑。等你跑通后再换成langchain4j-mongodb-vector-store或langchain4j-pgvector，迁移成本极低——因为LangChain4j的VectorStore接口完全抽象，替换只需改一行Bean定义。

3.2 第一个RAG应用：从PDF文档到智能问答

目标：上传一份《Java并发编程实战》PDF，输入问题“volatile关键字的作用是什么？”，返回精准答案。全程不碰任何LLM API密钥，用免费的本地模型（Ollama的phi3）。

Step 1：PDF解析与切片

// 使用LangChain4j内置PDF解析器，自动提取文本+页码 List<Document> documents = PdfDocumentParser.parse( new File("Java并发编程实战.pdf") ); // 切片策略：按段落切，每片最大500字符，重叠50字符（避免语义断裂） DocumentSplitter documentSplitter = new DocumentSplitters.RecursiveCharacterDocumentSplitter( 500, // chunkSize 50 // chunkOverlap ); List<Document> chunks = documentSplitter.split(documents);

这里的关键细节：RecursiveCharacterDocumentSplitter不是简单按字符数截断，它会优先在\n\n、\n、.处切分，保证每个chunk是完整句子。我们实测过，用纯字符切分，问答准确率只有62%，用递归切分后提升到89%。

Step 2：向量化与存储

// 初始化H2向量存储（自动建表，无需SQL） VectorStore vectorStore = H2VectorStore.builder() .dataSource(DataSourceBuilder.create() .url("jdbc:h2:mem:langchain4j;DB_CLOSE_DELAY=-1") // 内存模式，重启即失 .username("sa") .password("") .build()) .build(); // 选择嵌入模型：Ollama的nomic-embed-text（免费、中文好） EmbeddingModel embeddingModel = OllamaEmbeddingModel.builder() .baseUrl("http://localhost:11434") // Ollama服务地址 .modelName("nomic-embed-text") .build(); // 批量向量化并存入H2 EmbeddingStoreIngestor.ingest(chunks, embeddingModel, vectorStore);

注意：nomic-embed-text是目前免费模型中中文效果最好的，比all-MiniLM-L6-v2在法律、技术文档上的召回率高23%。Ollama安装命令：curl -fsSL https://ollama.com/install.sh | sh，然后ollama pull nomic-embed-text。

Step 3：构建RAG链

// 定义检索器：Top 3相似文档 Retriever<Document> retriever = EmbeddingStoreRetriever.from( vectorStore, embeddingModel, 3 // maxResults ); // 定义LLM：本地phi3模型（4GB显存即可跑） ChatLanguageModel model = OllamaChatModel.builder() .baseUrl("http://localhost:11434") .modelName("phi3") .timeout(Duration.ofSeconds(30)) .build(); // 构建RAG链：检索+上下文拼接+LLM生成 RetrievalAugmentor retrievalAugmentor = DefaultRetrievalAugmentor.builder() .retriever(retriever) .build(); ChatChain chain = ChatChain.builder() .chatLanguageModel(model) .retrievalAugmentor(retrievalAugmentor) .build(); // 执行问答 String question = "volatile关键字的作用是什么？"; AiMessage response = chain.send(question); System.out.println(response.text()); // 输出精准答案

这个ChatChain就是LangChain4j的魔法所在——它自动完成：检索文档→拼接成system消息→调用LLM→返回结构化AiMessage。不需要写任何模板字符串，DefaultRetrievalAugmentor已内置了工业级prompt：“你是一个专业的Java技术顾问，根据以下上下文回答问题。上下文：{retrievedDocuments}。问题：{userQuestion}。”

3.3 生产级增强：添加重排序与缓存

上面的Demo在小文档上很准，但面对1000页PDF时，Top 3检索结果可能包含噪声。必须加重排序（Reranking）：

// 使用CrossEncoder进行重排序（比单纯向量相似度更准） CrossEncoder crossEncoder = OllamaCrossEncoder.builder() .baseUrl("http://localhost:11434") .modelName("bge-reranker-large") .build(); // 替换原有检索器 Retriever<Document> rerankedRetriever = RerankRetriever.builder() .retriever(retriever) // 原始向量检索器 .crossEncoder(crossEncoder) .topK(3) // 重排序后取Top 3 .build();

bge-reranker-large是目前开源重排序模型中SOTA，我们在技术文档测试集上，重排序后准确率从78%提升到92%。

缓存同样关键——避免重复问题反复调用LLM：

// 使用Caffeine本地缓存（轻量、高性能） Cache<String, String> answerCache = Caffeine.newBuilder() .maximumSize(1000) .expireAfterWrite(10, TimeUnit.MINUTES) .build(); // 封装成服务方法 public String askQuestion(String question) { return answerCache.get(question, q -> { // 缓存未命中，执行RAG链 AiMessage response = chain.send(q); return response.text(); }); }

这里有个隐藏技巧：缓存key不能直接用question，要标准化——去掉空格、标点，转小写。否则“volatile作用？”和“volatile作用？”会被视为不同key。

4. Java工程师专属调试技巧：从日志、监控到性能调优全链路

4.1 日志追踪：让LLM调用像数据库SQL一样可观察

LangChain4j默认日志级别是INFO，但对调试远远不够。必须开启DEBUG并配置MDC（Mapped Diagnostic Context）传递请求ID：

# application.yml logging: level: dev.langchain4j: DEBUG org.springframework.web.client.RestTemplate: DEBUG pattern: console: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level [%X{traceId}] %logger{36} - %msg%n"

然后在Controller里注入TraceIdGenerator：

@RestController public class ChatController { private final TraceIdGenerator traceIdGenerator = new TraceIdGenerator(); @PostMapping("/ask") public ResponseEntity<String> ask(@RequestBody QuestionRequest request) { String traceId = traceIdGenerator.generate(); MDC.put("traceId", traceId); // 注入MDC try { String answer = chatService.ask(request.getQuestion()); return ResponseEntity.ok(answer); } finally { MDC.clear(); // 清理MDC } } }

这样每条日志都会带上[traceId]，你就能在ELK里搜索traceId=xxx，看到完整链路：
[DEBUG] Retrieving documents for query 'volatile'...
[DEBUG] Retrieved 3 documents, scores: [0.82, 0.75, 0.68]
[DEBUG] Sending request to LLM with 1243 tokens...
[DEBUG] LLM response received in 1.2s, 32 tokens generated

4.2 性能瓶颈定位：三招揪出慢查询元凶

RAG应用最常见的性能问题是“为什么我的问答要3秒？”。我们总结出Java工程师最该检查的三个点：

第一，向量检索耗时过高
H2向量存储在数据量>1万时，ORDER BY cosine_similarity DESC LIMIT 3会变慢。解决方案：

  • 开启H2的CREATE INDEX idx_embedding ON embedding_table (embedding)（LangChain4j 4.2.0已自动创建）；
  • 或直接换pgvector，用IVFFlat索引，100万向量查询<50ms。

第二，PDF解析阻塞主线程
PdfDocumentParser.parse()是同步IO操作，大PDF（>50MB）会卡住Tomcat线程。必须异步化：

// 使用Spring的@Async @Async public CompletableFuture<List<Document>> parsePdfAsync(File pdfFile) { return CompletableFuture.completedFuture(PdfDocumentParser.parse(pdfFile)); }

并在application.yml中配置线程池：

spring: task: execution: pool: max-size: 20 core-size: 5 queue-capacity: 100

第三，LLM Token计算不准导致超时
LangChain4j的TokenCountEstimator默认用OpenAiTokenizer，但对中文支持差。必须自定义：

@Bean public TokenCountEstimator tokenCountEstimator() { return new TokenCountEstimator() { @Override public int estimateTokenCount(String text) { // 中文按字符数*1.3估算（实测误差<5%） return (int) (text.length() * 1.3); } }; }

否则phi3模型可能因token超限被Ollama拒绝，返回400 Bad Request，日志里只显示“LLM call failed”，根本看不出原因。

4.3 内存泄漏排查：那些藏在Stream里的坑

LangChain4j大量使用Stream和Flux，但Java的Stream不是无限的——它会持有上游引用。我们曾在线上遇到OOM，堆dump显示Document对象占内存70%，根源是RetrievalAugmentor的Stream<Document>没关闭：

// 错误写法：Stream未关闭 public Stream<Document> retrieve(String query) { return vectorStore.search(SearchRequest.from(query).withTopK(3)); // 返回Stream } // 正确写法：立即收集，释放引用 public List<Document> retrieve(String query) { return vectorStore.search(SearchRequest.from(query).withTopK(3)) .collect(Collectors.toList()); // 转成List，Stream自动关闭 }

LangChain4j 4.2.0已修复此问题，但如果你用自定义VectorStore实现，必须牢记：所有返回Stream的方法，调用方必须负责关闭，或立即collect()。

5. 面试高频题实战解析：从原理到代码的硬核应答

5.1 “LangChain4j的Chain和Spring的Bean有什么区别？”

这不是考概念，是考你是否真用过。标准答案应该包含三层：
第一层（表面）：Chain是LangChain4j定义的函数式接口，代表一个可执行的LLM处理流程；Bean是Spring的IoC容器管理的对象实例。
第二层（本质）：Chain的生命周期由开发者控制（new ChatChain.Builder().build()），而Bean由Spring容器管理（@Bean注解）；Chain可以嵌套（Chain.of(chain1, chain2)），Bean不能直接嵌套，只能通过依赖注入组合。
第三层（实战）：我们线上用@Bean定义ChatChain，但不是直接new，而是用@ConfigurationProperties绑定配置：

@ConfigurationProperties(prefix = "langchain4j.chain") @Component public class ChatChainConfig { private String modelName = "phi3"; private int maxRetries = 3; @Bean public ChatChain chatChain(ChatLanguageModel model, Retriever<Document> retriever) { return ChatChain.builder() .chatLanguageModel(model) .retrievalAugmentor(DefaultRetrievalAugmentor.builder() .retriever(retriever) .build()) .retryPolicy(RetryPolicy.builder() .maxAttempts(maxRetries) // 从配置读取 .build()) .build(); } }

这样面试官立刻知道：你不仅懂API，还懂如何在Spring里工程化使用。

5.2 “如何保证RAG结果的准确性？”

别只说“加更多文档”“换更好模型”。Java工程师的答案必须带代码：

  • 输入校验：用InputValidator过滤恶意问题
@Bean public InputValidator inputValidator() { return new InputValidator() { @Override public boolean isValid(String input) { // 拒绝包含SQL注入特征的问题 return !input.matches(".*(?:union|select|drop|delete).*"); } }; }
  • 输出校验：用OutputParser强制JSON格式
JsonOutputParser<Answer> parser = new JsonOutputParser<>(Answer.class); // Answer类有@NotNull字段，解析失败自动抛异常
  • 置信度反馈：从AiMessage里提取LLM的自我评估
// 让LLM在回答末尾加置信度，如“置信度：95%” String confidence = response.text().replaceAll(".*置信度：(\\d+)%.*", "$1"); if (Integer.parseInt(confidence) < 80) { throw new LowConfidenceException("LLM置信度不足"); }

5.3 “LangChain4j和自己封装HTTP调用有什么区别？”

这是压轴题，答案决定你是不是真高手。核心对比点：

维度自己封装HTTPLangChain4j
错误重试需手动写while循环+指数退避RetryPolicy一键配置，自动记录重试日志
Token管理自己算长度，超限要截断TokenCountEstimator自动估算，TruncationStrategy智能截断
上下文拼接字符串拼接，易出错ChatMemory自动管理历史，支持TokenWindowChatMemory按token数滚动
可观测性自己打日志内置ObservabilitySPI，对接Micrometer、OpenTelemetry

我们线上系统用LangChain4j后，LLM调用失败率从12%降到0.8%，不是因为模型更好，而是RetryPolicy和CircuitBreaker起了作用。这才是框架的价值。

6. 实战扩展：从单机Demo到高可用生产架构

6.1 模型网关：统一管理多个LLM供应商

生产环境不可能只用一个模型。我们用Spring Cloud Gateway做了模型路由：

  • /api/chat/openai→ OpenAI GPT-4
  • /api/chat/azure→ Azure OpenAI
  • /api/chat/ollama→ 本地phi3
    Gateway配置：
spring: cloud: gateway: routes: - id: openai uri: https://api.openai.com predicates: - Path=/api/chat/openai/** filters: - RewritePath=/api/chat/openai/(?<segment>.*), /v1/chat/completions - id: ollama uri: http://localhost:11434 predicates: - Path=/api/chat/ollama/** filters: - RewritePath=/api/chat/ollama/(?<segment>.*), /api/chat/${segment}

LangChain4j的ChatLanguageModel通过baseUrl动态切换，完全解耦。

6.2 向量存储升级：从H2到MongoDB分片集群

H2只适合开发。生产用MongoDB Vector Search：

@Bean public VectorStore mongoVectorStore(MongoClient mongoClient) { return MongoDBVectorStore.builder() .mongoClient(mongoClient) .databaseName("langchain4j") .collectionName("documents") .embeddingModel(embeddingModel) .indexName("vector_index") .build(); }

关键配置：

  • 创建向量索引：db.documents.createIndex({embedding: "vector"}, {vectorDimensions: 768, vectorSearchOptions: {type: "knn"}})
  • 分片键设为documentId，避免热点
  • 开启changeStream监听文档变更，实时更新向量

6.3 监控告警：用Prometheus抓取LangChain4j指标

LangChain4j 4.2.0内置Micrometer支持：

@Bean public MeterRegistry meterRegistry() { return new PrometheusMeterRegistry(PrometheusConfig.DEFAULT); } // 自动暴露指标：langchain4j_chat_model_requests_total, langchain4j_retriever_latency_seconds

Grafana看板关键面板：

  • LLM调用成功率（rate(langchain4j_chat_model_requests_failed_total[5m]) / rate(langchain4j_chat_model_requests_total[5m])）
  • 向量检索P95延迟（histogram_quantile(0.95, rate(langchain4j_retriever_latency_seconds_bucket[5m]))）
  • Token使用量（sum(rate(langchain4j_chat_model_tokens_used_total[5m]))）

当成功率<95%时，自动触发告警，运维同学就知道该检查OpenAI配额或Ollama服务了。

我在实际项目中发现，LangChain4j最大的价值不是让Java工程师“会用LLM”，而是让LLM能力像数据库连接池一样，成为可配置、可监控、可降级的基础设施。上周我们线上遇到OpenAI服务中断，CircuitBreaker自动熔断，降级到本地phi3模型，用户无感知——这才是企业级AI应用该有的样子。最后分享个小技巧：ChatChain的builder()方法支持addChatMemory(ChatMemory)，用TokenWindowChatMemory时，设置maxTokens = 2048，它会自动按token数清理旧消息，比按条数清理更精准。这个细节，文档里没写，但线上跑了三个月，零OOM。

版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
网站建设 2026/10/10 4:46:59

Python交互式环境IPython全面详解

前言 很多人第一次听说 IPython&#xff0c;会以为它是 Python 自带的那个交互式解释器换了个名字。不是。 python 命令进入的 REPL&#xff08;Read-Eval-Print Loop&#xff0c;读取-求值-打印循环&#xff09;是标准解释器内置 的&#xff1b;IPython 是一个第三方项目&…

作者头像 李华
网站建设 2026/10/10 4:45:36

Claude记忆增强实践：轻量级本地化记忆管理方法论

1. “claude-mem”不是官方产品&#xff0c;而是开发者社区自发构建的记忆增强实践体系最近在多个技术社区和开源讨论区里&#xff0c;“claude-mem”这个词频繁出现在高互动帖中——它既不是Anthropic官方发布的SDK、插件或API功能&#xff0c;也不是某个已上架的商业化工具名…

作者头像 李华
网站建设 2026/10/10 4:44:48

弱电网下LCL-VSC并网系统阻抗建模与稳定性分析全解析

1. 为什么弱电网才是LCL并网系统翻车的重灾区做并网控制的同行应该都有这种感觉&#xff1a;实验平台或者强电网仿真里调得好好的系统&#xff0c;一旦接到短路比&#xff08;SCR&#xff09;偏低的弱电网环境&#xff0c;波形就开始发毛&#xff0c;甚至直接发散。我自己第一次…

作者头像 李华
网站建设 2026/10/10 4:44:24

飞书CLI正式开源那天，全网开发者开始翻Agent原理书

飞书CLI正式开源那天&#xff0c;全网开发者开始翻Agent原理书 【免费下载链接】ai-agent-book 《深入理解 AI Agent&#xff1a;设计原理与工程实践》&#xff08;李博杰 著&#xff09;开源主仓库&#xff1a;全书正文、编译版 PDF 与按章配套代码 项目地址: https://gitco…

作者头像 李华