本文记录了作者在解决售前报价客服问题时，使用LangChain4j、LangGraph和ReAct三种不同技术方案的实验过程。作者旨在通过大模型自动解析用户需求，查询SKU信息并计算价格。然而，在实践中，无论是直接使用Prompt引导Function Call，还是通过LangGraph构建显式流程图，亦或是采用ReAct框架赋予模型决策权，都未能完全解决大模型行为的不可控性问题，如跳过步骤、直接输出答案或流程僵化等。作者总结认为，多步骤流程中大模型的行为稳定性仍是亟待解决的核心挑战。

💡 **技术方案探索**: 作者尝试了三种技术路径来构建售前报价客服系统：一是基于LangChain4j和Prompt引导Function Call，二是利用LangGraph构建显式流程图，三是采用ReAct框架赋予模型自主决策能力。这些尝试旨在通过大模型自动完成从用户语义解析、SKU查询到价格计算的完整流程。

📈 **早期方案的局限性**: 初期的LangChain4j+Prompt方案效果不佳，表现为大模型常跳过关键步骤、直接给出答案或未能执行函数调用，缺乏可控性。LangGraph方案虽然理论上更可控，但在实际应用中流程过于刚性，无法灵活应对用户输入的变动，稳定性仍是问题。

🧠 **ReAct框架的权衡**: ReAct框架通过Thought-Action-Observation的模式，将决策权交还给大模型，理论上更灵活。然而，实际效果并未能根本解决问题，大模型仍可能跳过关键步骤，且需要不断通过“缝缝补补”的方式优化Prompt，其行为的不可控性依然存在。

⚠️ **核心挑战**: 无论采用何种技术方案，当前面临的核心问题均在于大模型在多步骤流程中的行为不可控性。在处理复杂流程时，模型容易出现错误、跳步或给出不符合预期的结果，目前尚未找到完全可靠的解决方案。

以下是我尝试分别用 langchain, langgraph,以及 ReAct 的三次实验，请大家帮忙看看有没有更好的解决方案，多谢。整体排版让 ai 给我优化了一下

售前报价客服的需求与技术演进

需求概述

用户提出一个报价问题，例如：

iphone16pro max, 128g, 黑色 多少钱？

实际 SKU 要复杂得多，但不影响核心流程：

大模型解析用户语义中的产品名；我根据产品名从数据库中查询 SKU 信息；拿到完整 SKU 后计算价格。

---

技术尝试过程

第一次尝试：LangChain4j + Prompt

我在 prompt 中指定了多个 function call：

解析产品名 根据产品名获取 SKU 信息 根据完整 SKU 信息计算价格 如果缺失必要的字段，向用户确认

实际效果： 不理想，属于 demo 偶尔能跑通，但经常出问题：

大模型直接跳过第一步，调用第二步方法；有时甚至直接输出“好的，正在为你计算价格”，并未执行任何函数调用；缺乏可控性。

---

第二次尝试：LangGraph

尝试用流程图方式替代 prompt 中的 if-else 指令：

显式建模产品识别 → 获取 SKU → 补齐字段 → 计算价格等步骤；理论上更可控。

实际效果： 依然不稳定，部分场景下流程刚性，模型无法灵活应对用户输入的变化。

---

第三次尝试：ReAct 框架

在 prompt 中使用 ReAct 框架（ Thought → Action → Observation ）：

将“决策权”交还给大模型；允许其自行判断调用哪些工具；相比直接写死顺序，逻辑更灵活。

实际效果：

看起来更聪明，但问题依旧存在；可能跳过某些关键步骤；经常需要靠“缝缝补补”的方式不断优化 prompt ；仍然不确定是否能彻底杜绝不可控行为。

---

总结

无论是 prompt + function call 、LangGraph 流程图，还是 ReAct 框架，核心问题始终是：
大模型行为的不可控性，尤其是在多步骤流程中容易出错或跳步，目前仍未找到完全可靠的解决方案。