langchain4j function call 显式使用

一.背景

1.隐式函数调用的核心局限

        在 langchain4j 构建简单 AI 服务的初期，开发者常依赖隐式函数调用（即由 LLM 自主判断是否调用函数、调用哪个函数）—— 比如让 LLM 直接分析用户提问 “伦敦明天天气多少华氏度”，自主决定调用 “查询明日天气” 和 “摄氏度转华氏度” 函数。但在企业级场景落地中，隐式调用暴露出关键问题：

1. 决策不可控：LLM 可能因语义理解偏差，误调用无关函数（如用户问 “租车取消规则”，却错误调用 “天气查询” 函数），或漏调用必要函数（如仅查询摄氏温度，未调用转换函数返回华氏度），导致 AI 服务输出错误结果；
2. 流程不透明：隐式调用中，函数调用的触发条件、参数传递、执行顺序完全由 LLM 黑盒决策，出现问题时难以定位（如不知道是 “未调用函数” 还是 “函数参数错误” 导致结果异常）；
3. 场景适配差：面对有明确规则的业务场景（如 “必须先核对预订编号，再查询取消政策”），隐式调用无法强制执行 “先 A 后 B” 的函数调用顺序，易违反业务规则；
4. 性能与成本高：LLM 需额外消耗算力分析 “是否调用函数、调用哪个”，对于高频简单场景（如批量查询多个城市天气），隐式调用会增加响应耗时和 API 调用成本。

        这类问题的核心矛盾是：企业级 AI 服务需要 “可控、透明、可定制” 的函数调用逻辑，而隐式调用的黑盒特性无法满足这一核心诉求，这成为 langchain4j 引入显式函数调用的核心动因。

2.显式函数调用的核心价值

        显式函数调用，指开发者通过代码主动指定 “何时调用、调用哪个、按什么顺序调用” 函数，而非依赖 LLM 自主决策。在 langchain4j 中显式使用函数调用，核心价值体现在：

1. 调用逻辑可控：开发者可强制定义函数调用规则（如 “用户问天气必须先调用‘查询明日日期’，再调用‘查询天气’，最后调用‘温度转换’”），避免 LLM 的误判，保证 AI 服务的准确性；
2. 流程透明可追溯：函数调用的触发条件、参数、执行顺序均由代码明确定义，出现问题时可快速定位（如 “温度转换结果错误” 可直接排查是否传入了正确的摄氏温度参数），满足企业级服务的可运维要求；
3. 适配复杂业务规则：针对有严格流程的场景（如租车客服 “先核对预订编号→再查询预订信息→最后解答取消政策”），显式调用可按业务规则编排函数执行顺序，确保符合企业合规要求；
4. 性能与成本优化：跳过 LLM “判断是否调用函数” 的环节，直接触发目标函