本文记录了作者在售前客服报价场景下，利用大模型解决用户复杂需求的三次技术实践。作者分别尝试了LangChain4j+Prompt、LangGraph流程图以及ReAct框架，旨在解决用户输入的产品信息不完整、模型行为不可控等问题。尽管引入了函数调用、流程图建模和ReAct框架，但大模型在多步骤流程中的行为依然存在不可控性，容易出现跳步或遗漏关键环节，作者总结认为，目前尚未找到完全可靠的解决方案，大模型行为的稳定性和可控性仍是关键挑战。

💡 **LangChain4j + Prompt 方案的局限性**：首次尝试通过Prompt指定多个函数调用（解析产品名、获取SKU、计算价格、字段确认），但实际效果不佳，模型常跳过关键步骤，直接计算或宣称正在计算，缺乏可控性。

🗺️ **LangGraph 流程图的挑战**：为提升可控性，采用LangGraph显式建模了产品识别、获取SKU、补齐字段、计算价格等步骤，虽然理论上更易于管理，但实际运行中流程过于刚性，模型难以灵活应对用户输入的变化，稳定性仍未达标。

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