LangChain4j Agent 开发实践
Agent 是大模型的下一个进化——不只是回答问题，还能执行任务。用 LangChain4j 构建一个能查订单、能退款、能转人工的智能客服。
一、Agent 的核心组件
- 1.1 LLM——大脑，决策和生成
- 1.2 Tools——工具，与外部系统交互
- 1.3 Memory——记忆，记住对话历史
- 1.4 Planner——规划，拆解复杂任务
二、LangChain4j 介绍
- 2.1 Java 版的 LangChain
- 2.2 核心——
AiServices/Tool/ChatMemory - 2.3 与 Spring Boot 集成
三、定义 Tools
- 3.1
@Tool注解——定义工具 - 3.2
queryOrder——查订单 - 3.3
refund——退款 - 3.4
transferToHuman——转人工 - 3.5 工具的返回值——让 Agent 理解执行结果
四、配置 Agent
- 4.1
AiServices.builder()——构建 Agent - 4.2 绑定 Tools
- 4.3 设置 Memory——
MessageWindowChatMemory - 4.4 System Prompt——设定客服角色
五、完整的客服对话流程
- 5.1 用户：”我要查订单 O123456”
- 5.2 Agent 调用
queryOrder("O123456") - 5.3 返回订单状态
- 5.4 用户：”我要退款”
- 5.5 Agent 调用
refund("O123456") - 5.6 退款成功
六、人工兜底策略
- 6.1 Agent 无法处理时——自动转人工
- 6.2 用户主动要求转人工
- 6.3 敏感操作——必须人工确认
七、生产环境注意事项
- 7.1 Token 消耗控制——限制对话轮次
- 7.2 幻觉处理——关键操作二次确认
- 7.3 并发——Agent 调用的线程安全
八、总结
- Agent = LLM + Tools + Memory + Planner
- LangChain4j 让 Java 开发者也能轻松构建 Agent
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 谜思录！
相关推荐
2025-03-15
RAG 知识库问答系统实践
让 AI 回答公司内部文档的问题——RAG（检索增强生成）是当前最主流的方案，不需要微调模型。 一、RAG 的核心原理 1.1 为什么需要 RAG——大模型的训练数据截止日期问题 1.2 RAG 流程——检索 → 增强 → 生成 1.3 与微调的区别——RAG 是”查资料”，微调是”背下来” 二、文档处理——把文档变成向量 2.1 文档切片——太长会丢失上下文，太短会丢失连贯性 2.2 Chunk Size 的选择——500-1000 Token 2.3 Overlap——块之间的重叠，防止语义断裂 2.4 文档格式处理——PDF / Word / Markdo...
2017-03-11
DDD 在电商订单域的实践
DDD 不是银弹，但在复杂业务域中它确实能帮你理清边界。以电商订单域为例，从战略设计到战术设计完整落地。 一、DDD 核心概念速览 1.1 战略设计——限界上下文、上下文映射 1.2 战术设计——聚合、实体、值对象、领域服务、仓储 1.3 领域事件——事件驱动 二、战略设计——事件风暴 2.1 识别领域事件——“订单已创建”、”订单已支付”、”订单已发货” 2.2 识别命令——“创建订单”、”支付订单” 2.3 识别聚合——Order 聚合、Product 聚合 2.4 划定限界上下文——订单上下文、商品上下文、支付上下文、用户上下文 三、上下文映射 3.1 订单上下文 ↔ 商品...
2022-10-15
并发工具类对比与实践
一个接口需要调用 3 个微服务，串行 300ms。用 CompletableFuture 并行调用只需 120ms。 一、场景描述 1.1 商品详情页——需要商品信息、库存、评价、推荐 1.2 串行调用——逐个等待，时间累加 1.3 并行调用的收益——总时间 = max(每个调用的时间) 二、CountDownLatch 2.1 原理——计数器，主线程等待所有子任务完成 2.2 代码示例——3 个线程并行获取数据 2.3 缺点——无法获取返回值、只能使用一次 三、CyclicBarrier 3.1 原理——所有线程到达 barrier 后一起继续 3.2 与 Count...
2023-09-16
单元测试覆盖率推进策略
“没时间写测试” → 线上频繁出问题 → 更没时间写测试。如何打破这个恶性循环？ 一、为什么单元测试覆盖率低 1.1 历史债务——老代码没有测试 1.2 赶进度——测试被忽视 1.3 写测试难——依赖太多无法 Mock 二、覆盖率目标设定 2.1 不要追求 100%——80% 是合理的上限 2.2 核心链路优先——支付、下单等高价值链路 2.3 工具类优先——纯函数容易测试 三、增量策略 3.1 新增代码——覆盖率不低于 80%（CI 卡点） 3.2 修改代码——补充修改部分的测试 3.3 存量代码——按优先级逐步补充 3.4 JaCoCo 覆盖率报告集成 四、让测试更好写 4...
2022-07-16
高并发热点账户处理方案
平台补贴账户、商户收款账户——这些”热点账户”被大量并发更新，数据库行锁成为瓶颈。如何设计记账方案？ 一、热点账户问题的本质 1.1 什么是热点账户——频繁被更新的账户（如平台补贴账户） 1.2 数据库行锁的瓶颈——TPS 上限约 500-1000 1.3 业务特点——余额正确性要求极高 二、方案 1：汇总记账 2.1 流水明细实时写入 2.2 账户余额定时汇总——每小时/每天更新一次 2.3 优点——零并发冲突 2.4 缺点——余额不实时 三、方案 2：缓冲记账 3.1 多个缓冲账户——account_0、account_1、…、account_9 3.2 写入时分发...
2018-04-01
服务无状态化与 Token 方案
有状态的服务无法水平扩展。从 Session 到 JWT 到 OAuth2，Token 方案的演进背后是无状态化的设计哲学。 一、有状态 vs 无状态 1.1 有状态——服务器保存客户端信息，无法随意扩容 1.2 无状态——每个请求独立，可以随意扩容 1.3 为什么微服务要求无状态——弹性伸缩的前提 二、Session 时代的终结 2.1 Tomcat Session 的机制——JSESSIONID Cookie 2.2 分布式 Session 方案——Redis 集中存储 2.3 Spring Session——透明化 Session 共享 2.4 Session 方案的缺点——...