先把结论放在前面LangGraph解决不了的它不是让你把幻觉消灭掉而是让你在幻觉发生的那一瞬间能及时发现、及时拦截、及时修正。本文就用一个真实场景把整套思路完整串一遍。我最早接触LangGraph时其实抱着一个很朴素的想法——能不能让Agent别乱编。但真正用下来才意识到模型层面的幻觉本质上是概率生成带来的谁都没法从根源上消除。LangGraph给出的解法是图式编排状态可控工具约束让模型在每一步都只做很小的决定而且每个决定都有被检查的机会。这篇文章会从幻觉的成因讲起然后用一套可复现代码搭建一个可控Agent覆盖状态设计、节点拆分、工具返回校验、人工审核节点、本地运行复盘这几个环节最后附上我自己实测的踩坑记录。适合已经会用LangChain、但对Agent可控性没什么头绪的开发者也适合正在做企业级AI应用的团队参考。1. LLM幻觉为什么根除不了只能可控1.1 幻觉的真正来源不是说错话而是不知道该把话说多大大多数人理解幻觉是模型编了个不存在的事实。但我在实际项目里体会到的更深层原因是模型不知道自己的能力边界在哪。举个例子你让模型从一段工单文本里抽取客户姓名。文本里明明只出现了张伟和李梅但由于工单末尾有句此单由王主管跟进模型可能就把王主管也当成客户抽出来。它不是故意瞎编而是它没法准确判断主管这个角色不在目标字段的语义范围内。这就是幻觉的第一层来源——意图漂移。模型猜不到你到底要什么粒度。第二层来源是信息补全。当文本中出现了空缺字段时人类会查资料模型却倾向于用概率填充。比如客户地区没写模型会优先猜北京或上海因为这两个词在训练语料里出现频次太高。这种补全会严重污染后续流程的数据质量。第三层是上下文遗忘。长对话中模型窗口被中间内容占满后容易把早前的关键约束丢掉尤其是当用户在中途改变了措辞但没有明确说取消之前的规则时。所以幻觉不是单一问题它是一个链条。1.2 提示词工程解决幻觉的边界在哪里我试过很多提示词方案在system里写请严格依据文本内容提取不得编造、在user里重复三次不要猜测、用few-shot给几个反例……确实有效果效果大概能把单次输出的幻觉率从15%压到8%左右。但再往下就压不动了。原因在于提示词是软约束。它只能影响模型生成概率的偏移没法在机制上阻止模型输出非法内容。模型可以理解不要猜但当它确实不知道、又被要求必须输出完整JSON时它会倾向于生成一个结构完整但内容错误的答案因为完整性在训练目标里优先级更高。提示词适合做方向的引导不适合做边界的强制。想要真正可控必须把让模型输出什么变成让整个系统决定模型能输出什么。1.3 可控的标准先想清楚你要控制什么很多团队的误区是一上来就追求模型完全不犯错。结果折腾一个月发现做不到于是放弃。我的建议是把可控拆成三个层次格式可控模型输出必须是合法JSON字段齐全类型正确。这靠结构化工具调用和校验器。边界可控模型只能从允许的范围内取值比如紧急级别只能是L1/L2/L3不能自由发挥。这靠工具定义里的枚举约束。动作可控模型每一步该不该调用工具、该不该结束由流程图规则决定而不是完全交给模型自己判断。这靠LangGraph的条件路由。当你把这三个层次做扎实了模型就算在中间步骤产生幻觉也会在进入下一层之前被拦截。这也正是LangGraph比普通Chain更适合作Agent编排的原因。2. 为什么说LangGraph这种图式流程天然克制幻觉2.1 从对话循环到有向状态图Agent底层的角色转变先看我最早做的Agent形态一个while循环里套LLM调用让模型自己决定下一步做什么、什么时候结束。这种自由度的好处是灵活坏处是出问题时你很难定位——因为每一步都是模型自由发挥的你没有固定轨道可查。LangGraph的思路完全反过来。它把Agent定义成一张有向状态图Node是固定功能的执行单元Edge是节点之间的跳转规则。模型只在一个或多个Node内部扮演决策者但整个流程的骨架由代码控制。这句话很关键**模型不再拥有对整个任务的主控权它只是流程中的一个组件。**这么一设计幻觉的影响范围就被框住了——模型在一个节点里产生的幻觉再离谱也只在当前节点内传递不会自动扩散到全流程。我实际感受最明显的一点以前用对话循环做Agent崩溃时根本不知道是模型理解错了还是逻辑写错了。换成状态图之后每一轮状态迁移都清清楚楚问题定位速度提升了数倍。2.2 状态机、检查点与工具调用三个关键机制如何压缩幻觉空间LangGraph里有三个机制我觉得对可控性帮助最大缺一不可。**状态机StateGraph**保证了数据流的明确性。所有信息都通过State在节点间传递节点之间不直接私下通信。这意味着你可以随时打印出整个State的中间值看到某一步模型到底把什么数据写进了状态。**检查点Checkpointer**让Agent在任意步骤暂停和恢复。配合人工审核节点你可以在关键节点前停住让人确认后再继续。这个能力对高价值场景特别重要。**工具调用tool calling**是压缩幻觉空间最直接的一环。不是让模型把答案写在自然语言里而是强制它通过调用一个已定义的函数来返回结果。由于函数的入参有严格schema模型只能在schema允许的范围内填写字段——枚举值乱编会被工具层直接拒绝。三个机制叠加起来效果是模型负责有限决策代码负责全局约束。幻觉不再是一个需要靠祈祷规避的黑盒问题而变成了一道道可检查的关卡。2.3 和传统Chain式编排的差异LangChain的Chain是线性管道数据沿着固定顺序流一遍就结束。它的问题在于当流程中出现分支、循环、人工介入时你没法优雅表达。Agent场景恰恰需要这些——可能要重试一次可能要等用户确认可能要调用工具后用结果再推理一次。Chain做这些会变得非常别扭而图结构天然支持。例如在Chain里如果你打算模型输出→格式化→校验→失败则重试你得手写重试逻辑。在LangGraph里这只是一条校验失败后回到模型节点的边而已清晰、可维护、可观测。3. 搭建一个可控Agent的完整实战流程3.1 环境准备与模拟场景设定工单信息抽取Agent我以一个虚构场景作为演示某客服团队需要把非结构化工单文本转成结构化数据再用这些数据自动分配处理人。原始工单长这样客户反馈昨天下午在门店买的咖啡机出水量异常 配件包装里少了一个滤网。客户希望尽快处理 最好本周内能换新机。店址在杭州西湖区。期望的输出是一份JSON{ customer_name: 未提供, product_category: 咖啡机, issue_type: 配件缺失, region: 杭州, priority: P1, handler: 售后二组 }在没有约束前模型经常编出根本不存在的客户姓名比如把门店店员名字当客户或者把希望本周内处理自动推断成priority: P0导致大量误派单。这个场景非常典型——文本信息缺失模型用概率补全数据被污染。环境准备方面我建议用Python 3.10以上版本安装LangGraph和相关依赖即可。实际跑通整个流程只需要三个核心库LangGraph本身、一个能支持结构化工具调用的LLM接入层、以及一个checkpoint存储本地开发用SQLite或内存版本就够。提示不要把checkpoint配置想得太复杂本地调试用内存存储足够。等上了生产环境再切换成数据库方案LangGraph的接口是统一的不会破坏业务代码。3.2 状态定义与节点拆分让每一步都有据可查这是整个项目里最需要花心思的地方。很多教程一上来就写图但我建议先把状态定义想明白。我的做法是定义Artifact状态包含四个字段from typing import TypedDict, Annotated, List import operator class AgentState(TypedDict): raw_text: str # 原始工单文本 extracted: dict # 提取结果 validation_errors: List[str] # 校验错误 approved: bool # 是否通过人工审核注意我用了extracted单独存提取结果没有把所有信息都堆在一起。原因是后续每个节点都要读写它如果和别的字段混在一起容易出现覆盖问题。节点拆分上我选了三个节点extract_node调用LLM做字段提取validate_node对提取结果做规则校验notify_human_node需要人工介入时暂停并发送通知节点的最小化原则是一个节点只做一件事。不要贪心把提取和校验写进同一个节点否则将来你想单独调整校验规则时必须连带触碰模型调用逻辑。3.3 工具编写与结构化输出把幻觉堵在入口LLM提取环节最怕的自由发挥我用一个工具函数来限制。可以让模型不是直接输出JSON而是去调用一个名为submit_extraction的函数函数的参数就是各字段要求。def submit_extraction( customer_name: str, product_category: str, issue_type: str, region: str, priority: str, ): 提交信息抽取结果。所有字段都是必填。 priority只能是P0/P1/P2之一。 return { customer_name: customer_name, product_category: product_category, issue_type: issue_type, region: region, priority: priority, }这种做法的核心好处是模型被强制走结构化输出通道而不是用自然语言附一段JSON。工具调用的schema天然就成了约束边界。这里还有一个技巧在字段描述里写明如果原文没有出现请填未提供不要推测。这句提示要放在工具描述里因为它比system提示更贴近模型生成参数的决策位置效果更直接。不过工具调用只约束了格式和枚举并不能保证客户名称这种开放字段一定正确。所以后面还需要校验节点。3.4 条件路由与人工审核节点设置安全出口LangGraph最有价值的一点是我可以在图上定义检查不过就往回走的边。比如校验失败时返回提取节点重试而不是让错误数据继续往下游走。from langgraph.graph import StateGraph, START, END def should_retry(state: AgentState) - str: if state[validation_errors]: return retry return approve graph StateGraph(AgentState) graph.add_node(extract, extract_node) graph.add_node(validate, validate_node) graph.add_node(human_review, human_review_node) graph.add_edge(START, extract) graph.add_edge(extract, validate) graph.add_conditional_edges( validate, should_retry, {retry: extract, approve: human_review}, ) graph.add_edge(human_review, END)这几个条件边设计好之后Agent的走上路就明确了提取 → 校验 → 失败则重提取 → 成功则人工确认 → 结束。human_review_node要配合interrupt使用。LangGraph的interrupt可以把图暂停在指定节点前等待外部输入再继续。我在实际项目中是把它和任务队列连在一起Agent暂停后自动向审核人员推送一条消息审核通过后发指令恢复流程。注意人工节点不是每单都必审。工单量大时这样会累死团队。我的做法是加一个skip_unless_risky的边当priority为P0或得分低于某一阈值时才进入人工节点其余自动放行。这样既保证了风险控制又不会拖慢整体效率。4. 实战中把幻觉率压下来的5个关键设计下面这几个设计是我在多次迭代里真正觉得有效抑制幻觉的实践不是从文档里抄来的。4.1 工具调用的schema约束工具不仅是入口还是保险丝。我给submit_extraction里每个字段都写清楚了取值范围。对于priority模型一旦试图传P3或高优先级工具层直接拒绝提示它只能在枚举里选。这种硬校验比提示词里的请严格按照枚举有效得多。4.2 返回校验循环验证器校验节点不能只是一个检查JSON合法的壳子。我写了一套规则包括customer_name不能是店员经理这些角色词region必须是已知城市列表里的issue_type必须是预设的10个分类之一priority必须和文本里的时间表述一致比如一周内处理最多P1不能给P0校验不通过就把错误信息写回状态让模型带着错误反馈重新提取。这种反馈式修正比静默通过好得多。模型看到上次你把这个字段猜错了请重新读原文之后第二次生成的准确率会显著上升。4.3 让模型明确说不出优先于猜一个这是我在实践中体会最深的一条。模型在信息缺失时天然倾向于补全你需要给它一个合法的不知道出口。我在工具描述里明确要求缺失字段填未提供并且校验时把它当作合法值。做出这个改动后客户的猜测型幻觉大幅下降。很多团队的代码没有给模型承认不知道的选项于是模型只能硬着头皮猜。这不是语意问题是产品设计问题。4.4 引入检查点做本地重放我觉得检查点的价值不止在于断点续跑还在于复盘。当线上出现一条错误工单时我用检查点把当时的运行过程完整重放一遍能看到每一步模型写入的状态值定位幻觉发生在哪个节点。没有检查点时错误数据只是一个孤立的结果有了检查点错误数据变成了一条可以追溯的路径。这一点对后期调优的意义非常大。4.5 用批量评估而不是感觉来调优改了一条提示词后觉得准确率变高了——这种体验最容易骗人。我建议做一个批量回归集至少准备50条不同难度的工单文本每次调整后都跑一遍对比准确率和幻觉率的变化。我自己的小评估脚本会用几个指标指标含义说明提取完整率非未提供字段是否都正确防止模型图省事全填未提供幻觉率模型填了原文没有的内容必填字段纯属虚构格式非法率JSON不合法、枚举超界工具层拦截的情况重试次数平均每单要重新提取几次越高说明流程效率越低在多数语言模型服务中批量调用可以用多线程或异步方式并行做很快就能出一份调整前后的对比。我明显感觉到开始按这套指标调优后Agent的行为稳定度提升了一个台阶。5. 一次完整的实测记录与踩坑复盘5.1 模拟场景实测数据和表现我用一个包含120条工单的测试集跑了一轮。测试集里的难度差异很大有些工单字段齐全有些故意省略客户名称或地区有些混入了店员名称主管名称这些干扰信息。第一版未加任何约束、直接让模型输出JSON的基线数据是**幻觉率约14%120条里有17条出现了虚构客户或错误推断紧急级别格式错误率约6%。**加了工具调用和校验循环之后幻觉率降到了3.5%格式错误率降到0。再把人工审核节点接入后剩下的3.5%幻觉几乎都被审核员拦下真正进入下游系统的错误数据变成了0。对比下来LangGraph这套边约束边校验的路线让幻觉问题从模型反复说谎变成了系统能兜底。5.2 踩过的两个典型坑超时与死循环第一个坑是工具调用超时。当时我以为模型会在几秒内返回结果某次流式调用时上下文过长直接跑了一分半钟导致整个节点卡住下游全部超时。踩过一次后才明白模型调用最好设定一个硬性超时时间超时就自动进入重试分支不要让它无限期占着流程。第二个坑是校验失败重试变成死循环。我的校验规则有一个Bug某类工单的客户名称在原文里确实出现了但被我错误判断为角色词于是反复重试了十几轮。这类问题最隐蔽的就是表面看是模型幻觉实际是规则写错。所以每次看到大量重试先查规则不要先骂模型。另外还有一个经验清单可以给到大家参考重试的轮次一定要设上限达到上限后强制转人工不要让Agent在循环里空转。每条工单记录一下重试原因如果某类错误特别多往往意味着节点规则或工具描述还有改进空间。5.3 后续还可以往哪里扩展目前这套流程已经解决了信息提取→结构化→分配的核心链路。如果未来要继续做有两个方向我觉得值得试一个是将LangGraph的图做深把质检反馈纳入流程图中。工单处理完成后客服的解决时长和客户满意度会作为反馈信号回到图里让Agent持续修正提取规则。另一个方向是把用户模拟历史中出现的特殊实体名比如区域经理名单做成外部记忆让模型在提取时先查询记忆库再生成结果。说回LangGraph本身我实际用下来最大的体会是它不是那种让你写完即忘的框架而是真真切切改变了Agent的构建方式。以前你敢不敢让模型直接输出决定全局的数据取决于你对它的信任现在你信任的不再是模型而是你搭建的这张图——哪一步有风险、哪一步检查、哪一步进人工都在你的掌控之内。如果你现在正被Agent的幻觉问题折磨先别急着继续堆提示词试着把任务拆成一张图让模型的每一次发挥都被限制在明确的格子里面。这个思维转换过来之后幻觉问题就不再是玄学了。
先把结论放在前面LangGraph解决不了的它不是让你把幻觉消灭掉而是让你在幻觉发生的那一瞬间能及时发现、及时拦截、及时修正。本文就用一个真实场景把整套思路完整串一遍。我最早接触LangGraph时其实抱着一个很朴素的想法——能不能让Agent别乱编。但真正用下来才意识到模型层面的幻觉本质上是概率生成带来的谁都没法从根源上消除。LangGraph给出的解法是图式编排状态可控工具约束让模型在每一步都只做很小的决定而且每个决定都有被检查的机会。这篇文章会从幻觉的成因讲起然后用一套可复现代码搭建一个可控Agent覆盖状态设计、节点拆分、工具返回校验、人工审核节点、本地运行复盘这几个环节最后附上我自己实测的踩坑记录。适合已经会用LangChain、但对Agent可控性没什么头绪的开发者也适合正在做企业级AI应用的团队参考。1. LLM幻觉为什么根除不了只能可控1.1 幻觉的真正来源不是说错话而是不知道该把话说多大大多数人理解幻觉是模型编了个不存在的事实。但我在实际项目里体会到的更深层原因是模型不知道自己的能力边界在哪。举个例子你让模型从一段工单文本里抽取客户姓名。文本里明明只出现了张伟和李梅但由于工单末尾有句此单由王主管跟进模型可能就把王主管也当成客户抽出来。它不是故意瞎编而是它没法准确判断主管这个角色不在目标字段的语义范围内。这就是幻觉的第一层来源——意图漂移。模型猜不到你到底要什么粒度。第二层来源是信息补全。当文本中出现了空缺字段时人类会查资料模型却倾向于用概率填充。比如客户地区没写模型会优先猜北京或上海因为这两个词在训练语料里出现频次太高。这种补全会严重污染后续流程的数据质量。第三层是上下文遗忘。长对话中模型窗口被中间内容占满后容易把早前的关键约束丢掉尤其是当用户在中途改变了措辞但没有明确说取消之前的规则时。所以幻觉不是单一问题它是一个链条。1.2 提示词工程解决幻觉的边界在哪里我试过很多提示词方案在system里写请严格依据文本内容提取不得编造、在user里重复三次不要猜测、用few-shot给几个反例……确实有效果效果大概能把单次输出的幻觉率从15%压到8%左右。但再往下就压不动了。原因在于提示词是软约束。它只能影响模型生成概率的偏移没法在机制上阻止模型输出非法内容。模型可以理解不要猜但当它确实不知道、又被要求必须输出完整JSON时它会倾向于生成一个结构完整但内容错误的答案因为完整性在训练目标里优先级更高。提示词适合做方向的引导不适合做边界的强制。想要真正可控必须把让模型输出什么变成让整个系统决定模型能输出什么。1.3 可控的标准先想清楚你要控制什么很多团队的误区是一上来就追求模型完全不犯错。结果折腾一个月发现做不到于是放弃。我的建议是把可控拆成三个层次格式可控模型输出必须是合法JSON字段齐全类型正确。这靠结构化工具调用和校验器。边界可控模型只能从允许的范围内取值比如紧急级别只能是L1/L2/L3不能自由发挥。这靠工具定义里的枚举约束。动作可控模型每一步该不该调用工具、该不该结束由流程图规则决定而不是完全交给模型自己判断。这靠LangGraph的条件路由。当你把这三个层次做扎实了模型就算在中间步骤产生幻觉也会在进入下一层之前被拦截。这也正是LangGraph比普通Chain更适合作Agent编排的原因。2. 为什么说LangGraph这种图式流程天然克制幻觉2.1 从对话循环到有向状态图Agent底层的角色转变先看我最早做的Agent形态一个while循环里套LLM调用让模型自己决定下一步做什么、什么时候结束。这种自由度的好处是灵活坏处是出问题时你很难定位——因为每一步都是模型自由发挥的你没有固定轨道可查。LangGraph的思路完全反过来。它把Agent定义成一张有向状态图Node是固定功能的执行单元Edge是节点之间的跳转规则。模型只在一个或多个Node内部扮演决策者但整个流程的骨架由代码控制。这句话很关键**模型不再拥有对整个任务的主控权它只是流程中的一个组件。**这么一设计幻觉的影响范围就被框住了——模型在一个节点里产生的幻觉再离谱也只在当前节点内传递不会自动扩散到全流程。我实际感受最明显的一点以前用对话循环做Agent崩溃时根本不知道是模型理解错了还是逻辑写错了。换成状态图之后每一轮状态迁移都清清楚楚问题定位速度提升了数倍。2.2 状态机、检查点与工具调用三个关键机制如何压缩幻觉空间LangGraph里有三个机制我觉得对可控性帮助最大缺一不可。**状态机StateGraph**保证了数据流的明确性。所有信息都通过State在节点间传递节点之间不直接私下通信。这意味着你可以随时打印出整个State的中间值看到某一步模型到底把什么数据写进了状态。**检查点Checkpointer**让Agent在任意步骤暂停和恢复。配合人工审核节点你可以在关键节点前停住让人确认后再继续。这个能力对高价值场景特别重要。**工具调用tool calling**是压缩幻觉空间最直接的一环。不是让模型把答案写在自然语言里而是强制它通过调用一个已定义的函数来返回结果。由于函数的入参有严格schema模型只能在schema允许的范围内填写字段——枚举值乱编会被工具层直接拒绝。三个机制叠加起来效果是模型负责有限决策代码负责全局约束。幻觉不再是一个需要靠祈祷规避的黑盒问题而变成了一道道可检查的关卡。2.3 和传统Chain式编排的差异LangChain的Chain是线性管道数据沿着固定顺序流一遍就结束。它的问题在于当流程中出现分支、循环、人工介入时你没法优雅表达。Agent场景恰恰需要这些——可能要重试一次可能要等用户确认可能要调用工具后用结果再推理一次。Chain做这些会变得非常别扭而图结构天然支持。例如在Chain里如果你打算模型输出→格式化→校验→失败则重试你得手写重试逻辑。在LangGraph里这只是一条校验失败后回到模型节点的边而已清晰、可维护、可观测。3. 搭建一个可控Agent的完整实战流程3.1 环境准备与模拟场景设定工单信息抽取Agent我以一个虚构场景作为演示某客服团队需要把非结构化工单文本转成结构化数据再用这些数据自动分配处理人。原始工单长这样客户反馈昨天下午在门店买的咖啡机出水量异常 配件包装里少了一个滤网。客户希望尽快处理 最好本周内能换新机。店址在杭州西湖区。期望的输出是一份JSON{ customer_name: 未提供, product_category: 咖啡机, issue_type: 配件缺失, region: 杭州, priority: P1, handler: 售后二组 }在没有约束前模型经常编出根本不存在的客户姓名比如把门店店员名字当客户或者把希望本周内处理自动推断成priority: P0导致大量误派单。这个场景非常典型——文本信息缺失模型用概率补全数据被污染。环境准备方面我建议用Python 3.10以上版本安装LangGraph和相关依赖即可。实际跑通整个流程只需要三个核心库LangGraph本身、一个能支持结构化工具调用的LLM接入层、以及一个checkpoint存储本地开发用SQLite或内存版本就够。提示不要把checkpoint配置想得太复杂本地调试用内存存储足够。等上了生产环境再切换成数据库方案LangGraph的接口是统一的不会破坏业务代码。3.2 状态定义与节点拆分让每一步都有据可查这是整个项目里最需要花心思的地方。很多教程一上来就写图但我建议先把状态定义想明白。我的做法是定义Artifact状态包含四个字段from typing import TypedDict, Annotated, List import operator class AgentState(TypedDict): raw_text: str # 原始工单文本 extracted: dict # 提取结果 validation_errors: List[str] # 校验错误 approved: bool # 是否通过人工审核注意我用了extracted单独存提取结果没有把所有信息都堆在一起。原因是后续每个节点都要读写它如果和别的字段混在一起容易出现覆盖问题。节点拆分上我选了三个节点extract_node调用LLM做字段提取validate_node对提取结果做规则校验notify_human_node需要人工介入时暂停并发送通知节点的最小化原则是一个节点只做一件事。不要贪心把提取和校验写进同一个节点否则将来你想单独调整校验规则时必须连带触碰模型调用逻辑。3.3 工具编写与结构化输出把幻觉堵在入口LLM提取环节最怕的自由发挥我用一个工具函数来限制。可以让模型不是直接输出JSON而是去调用一个名为submit_extraction的函数函数的参数就是各字段要求。def submit_extraction( customer_name: str, product_category: str, issue_type: str, region: str, priority: str, ): 提交信息抽取结果。所有字段都是必填。 priority只能是P0/P1/P2之一。 return { customer_name: customer_name, product_category: product_category, issue_type: issue_type, region: region, priority: priority, }这种做法的核心好处是模型被强制走结构化输出通道而不是用自然语言附一段JSON。工具调用的schema天然就成了约束边界。这里还有一个技巧在字段描述里写明如果原文没有出现请填未提供不要推测。这句提示要放在工具描述里因为它比system提示更贴近模型生成参数的决策位置效果更直接。不过工具调用只约束了格式和枚举并不能保证客户名称这种开放字段一定正确。所以后面还需要校验节点。3.4 条件路由与人工审核节点设置安全出口LangGraph最有价值的一点是我可以在图上定义检查不过就往回走的边。比如校验失败时返回提取节点重试而不是让错误数据继续往下游走。from langgraph.graph import StateGraph, START, END def should_retry(state: AgentState) - str: if state[validation_errors]: return retry return approve graph StateGraph(AgentState) graph.add_node(extract, extract_node) graph.add_node(validate, validate_node) graph.add_node(human_review, human_review_node) graph.add_edge(START, extract) graph.add_edge(extract, validate) graph.add_conditional_edges( validate, should_retry, {retry: extract, approve: human_review}, ) graph.add_edge(human_review, END)这几个条件边设计好之后Agent的走上路就明确了提取 → 校验 → 失败则重提取 → 成功则人工确认 → 结束。human_review_node要配合interrupt使用。LangGraph的interrupt可以把图暂停在指定节点前等待外部输入再继续。我在实际项目中是把它和任务队列连在一起Agent暂停后自动向审核人员推送一条消息审核通过后发指令恢复流程。注意人工节点不是每单都必审。工单量大时这样会累死团队。我的做法是加一个skip_unless_risky的边当priority为P0或得分低于某一阈值时才进入人工节点其余自动放行。这样既保证了风险控制又不会拖慢整体效率。4. 实战中把幻觉率压下来的5个关键设计下面这几个设计是我在多次迭代里真正觉得有效抑制幻觉的实践不是从文档里抄来的。4.1 工具调用的schema约束工具不仅是入口还是保险丝。我给submit_extraction里每个字段都写清楚了取值范围。对于priority模型一旦试图传P3或高优先级工具层直接拒绝提示它只能在枚举里选。这种硬校验比提示词里的请严格按照枚举有效得多。4.2 返回校验循环验证器校验节点不能只是一个检查JSON合法的壳子。我写了一套规则包括customer_name不能是店员经理这些角色词region必须是已知城市列表里的issue_type必须是预设的10个分类之一priority必须和文本里的时间表述一致比如一周内处理最多P1不能给P0校验不通过就把错误信息写回状态让模型带着错误反馈重新提取。这种反馈式修正比静默通过好得多。模型看到上次你把这个字段猜错了请重新读原文之后第二次生成的准确率会显著上升。4.3 让模型明确说不出优先于猜一个这是我在实践中体会最深的一条。模型在信息缺失时天然倾向于补全你需要给它一个合法的不知道出口。我在工具描述里明确要求缺失字段填未提供并且校验时把它当作合法值。做出这个改动后客户的猜测型幻觉大幅下降。很多团队的代码没有给模型承认不知道的选项于是模型只能硬着头皮猜。这不是语意问题是产品设计问题。4.4 引入检查点做本地重放我觉得检查点的价值不止在于断点续跑还在于复盘。当线上出现一条错误工单时我用检查点把当时的运行过程完整重放一遍能看到每一步模型写入的状态值定位幻觉发生在哪个节点。没有检查点时错误数据只是一个孤立的结果有了检查点错误数据变成了一条可以追溯的路径。这一点对后期调优的意义非常大。4.5 用批量评估而不是感觉来调优改了一条提示词后觉得准确率变高了——这种体验最容易骗人。我建议做一个批量回归集至少准备50条不同难度的工单文本每次调整后都跑一遍对比准确率和幻觉率的变化。我自己的小评估脚本会用几个指标指标含义说明提取完整率非未提供字段是否都正确防止模型图省事全填未提供幻觉率模型填了原文没有的内容必填字段纯属虚构格式非法率JSON不合法、枚举超界工具层拦截的情况重试次数平均每单要重新提取几次越高说明流程效率越低在多数语言模型服务中批量调用可以用多线程或异步方式并行做很快就能出一份调整前后的对比。我明显感觉到开始按这套指标调优后Agent的行为稳定度提升了一个台阶。5. 一次完整的实测记录与踩坑复盘5.1 模拟场景实测数据和表现我用一个包含120条工单的测试集跑了一轮。测试集里的难度差异很大有些工单字段齐全有些故意省略客户名称或地区有些混入了店员名称主管名称这些干扰信息。第一版未加任何约束、直接让模型输出JSON的基线数据是**幻觉率约14%120条里有17条出现了虚构客户或错误推断紧急级别格式错误率约6%。**加了工具调用和校验循环之后幻觉率降到了3.5%格式错误率降到0。再把人工审核节点接入后剩下的3.5%幻觉几乎都被审核员拦下真正进入下游系统的错误数据变成了0。对比下来LangGraph这套边约束边校验的路线让幻觉问题从模型反复说谎变成了系统能兜底。5.2 踩过的两个典型坑超时与死循环第一个坑是工具调用超时。当时我以为模型会在几秒内返回结果某次流式调用时上下文过长直接跑了一分半钟导致整个节点卡住下游全部超时。踩过一次后才明白模型调用最好设定一个硬性超时时间超时就自动进入重试分支不要让它无限期占着流程。第二个坑是校验失败重试变成死循环。我的校验规则有一个Bug某类工单的客户名称在原文里确实出现了但被我错误判断为角色词于是反复重试了十几轮。这类问题最隐蔽的就是表面看是模型幻觉实际是规则写错。所以每次看到大量重试先查规则不要先骂模型。另外还有一个经验清单可以给到大家参考重试的轮次一定要设上限达到上限后强制转人工不要让Agent在循环里空转。每条工单记录一下重试原因如果某类错误特别多往往意味着节点规则或工具描述还有改进空间。5.3 后续还可以往哪里扩展目前这套流程已经解决了信息提取→结构化→分配的核心链路。如果未来要继续做有两个方向我觉得值得试一个是将LangGraph的图做深把质检反馈纳入流程图中。工单处理完成后客服的解决时长和客户满意度会作为反馈信号回到图里让Agent持续修正提取规则。另一个方向是把用户模拟历史中出现的特殊实体名比如区域经理名单做成外部记忆让模型在提取时先查询记忆库再生成结果。说回LangGraph本身我实际用下来最大的体会是它不是那种让你写完即忘的框架而是真真切切改变了Agent的构建方式。以前你敢不敢让模型直接输出决定全局的数据取决于你对它的信任现在你信任的不再是模型而是你搭建的这张图——哪一步有风险、哪一步检查、哪一步进人工都在你的掌控之内。如果你现在正被Agent的幻觉问题折磨先别急着继续堆提示词试着把任务拆成一张图让模型的每一次发挥都被限制在明确的格子里面。这个思维转换过来之后幻觉问题就不再是玄学了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
