企业官网建设流程全解析

LangChain4j 进阶实战：第 9 篇，动态 Agent 设计：提示词、模型参数和工具后台可配置

前言

前面几篇已经讲了 LangChain4j 的核心能力：

• ChatModel：调用大模型。
• AiServices：把模型能力封装成 Java 接口。
• ChatMemory：保存会话上下文。
• ContentRetriever：接入 RAG 检索。
• @Tool和 MCP：让模型调用工具。

如果只是写一个 Demo，把这些能力写死在代码里完全可以。但只要进入真实业务系统，很快会遇到一个问题：Agent 不能总靠开发改代码。

比如智能衣橱里可能会有多个 Agent：

• 穿搭推荐 Agent。
• 场景分析 Agent。
• 服装匹配 Agent。
• 用户偏好分析 Agent。
• 客服问答 Agent。
• 运营文案 Agent。

这些 Agent 的提示词、模型、温度、最大 token、工具权限都可能不一样。如果每次新增或调整 Agent 都要发版，后期迭代会非常慢。

所以这一篇讲一个更进阶的话题：如何把 LangChain4j 的能力做成“动态 Agent 平台”。

1. 静态 Agent 的问题

很多人一开始会这样写：

@AiServicepublicinterfaceOutfitAssistant{@SystemMessage(""" 你是一个专业穿搭顾问。 请根据用户需求推荐合适的衣服。 """)Stringchat(Stringmessage);}

这种写法简单、清晰，非常适合学习 LangChain4j。但它有几个明显问题：

• SystemMessage写死在代码里。
• 模型名称写死在配置里。
• temperature、maxTokens 不能按 Agent 调整。
• 是否启用 Memory、RAG、MCP 工具不够灵活。
• 工具权限无法后台控制。
• Prompt 调整需要开发改代码并重新部署。

真实项目里，Prompt 是会不断迭代的。业务人员可能今天觉得穿搭推荐太保守，明天觉得回复太长，后天又希望输出 ID 数组而不是自然语言。如果这些都依赖发版，AI 应用迭代效率会很低。

我的建议是：学习阶段可以静态写，生产阶段应该把 Agent 配置化。

2. 动态 Agent 的核心思想

动态 Agent 的核心思想很简单：

不要把 Agent 写死成一个 Java 类，而是把 Agent 看成一份运行时配置。

一份 Agent 配置至少包含：

工具配置也要独立出来：

这样做以后，Agent 的创建流程就从“写代码”变成了“读取配置并装配运行时能力”。

3. 推荐的表结构设计

动态 Agent 最常见的是两张表：Agent 表和 Agent 工具表。

Agent 表可以这样设计：

CREATETABLEt_ai_agent(idVARCHAR(64)PRIMARYKEY,codeVARCHAR(100)NOTNULL,nameVARCHAR(100)NOTNULL,descriptionVARCHAR(500),system_promptTEXTNOTNULL,model_nameVARCHAR(100),temperatureDECIMAL(3,2),max_tokensINT,statusVARCHAR(30)NOTNULL,created_atDATETIME,updated_atDATETIME);

Agent 工具表：

CREATETABLEt_ai_agent_tool(idVARCHAR(64)PRIMARYKEY,agent_idVARCHAR(64)NOTNULL,tool_codeVARCHAR(100)NOTNULL,tool_nameVARCHAR(100)NOTNULL,tool_typeVARCHAR(50)NOTNULL,tool_config JSON,created_atDATETIME,updated_atDATETIME);

tool_config用 JSON 是比较实用的，因为不同工具配置结构不一样。

比如记忆工具：

{"enabled":true,"maxMessages":20}

向量检索工具：

{"enabled":true,"topK":5,"minScore":0.6,"filterByUserId":true}

MCP 工具：

{"enabled":true,"baseUri":"http://localhost:9021","endpoint":"/sse",