本文记录了作者在售前报价客服场景下，利用大模型解决用户报价问题的三次技术尝试。首次尝试使用LangChain4j和Prompt进行多函数调用，但效果不佳，模型常出现跳步或直接输出结果。第二次尝试引入LangGraph，通过流程图显式建模，但仍存在流程刚性，模型应对变化能力不足的问题。第三次尝试应用ReAct框架，将决策权交给模型，虽然表现更灵活，但仍未能完全解决关键步骤遗漏和不可控行为。最终总结出，大模型在多步骤流程中的行为不可控性是核心难题，目前尚未找到彻底的解决方案。

⭐ **LangChain4j + Prompt 首次尝试：** 作者尝试通过 Prompt 指导大模型执行解析产品名、查询 SKU、计算价格等多个函数调用。然而，实际效果不理想，模型常跳过关键步骤，直接输出结果，或在未执行任何操作的情况下回应，显示出缺乏可控性。

⭐ **LangGraph 流程图优化：** 为了提高可控性，作者转而使用 LangGraph 显式建模报价流程，包括产品识别、获取 SKU、补齐字段和计算价格等环节。尽管理论上更具条理性，但实际应用中流程过于刚性，模型难以灵活应对用户输入的细微变化。

⭐ **ReAct 框架的灵活性尝试：** 第三次实验引入 ReAct 框架，赋予大模型“思考-行动-观察”的决策能力，允许其自主选择工具调用。虽然模型表现得更“聪明”，能够更灵活地处理问题，但依然存在跳过关键步骤的现象，并且需要频繁通过优化 Prompt 来“缝缝补补”，仍无法完全保证行为的确定性。

⭐ **核心挑战是模型行为的不可控性：** 经过三次技术迭代，作者发现无论是哪种方法，大模型在处理多步骤任务时，其行为的不可控性始终是核心痛点。模型容易出错、跳步，即使是 ReAct 框架也未能完全根治这一问题，目前仍未找到一个完全可靠的解决方案。

以下是我尝试分别用 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 框架，核心问题始终是：
大模型行为的不可控性，尤其是在多步骤流程中容易出错或跳步，目前仍未找到完全可靠的解决方案。