RAG 聊天机器人为什么会在复杂请求面前停下?
企业级 RAG 聊天机器人收到问题后检索文档、生成回答。这种直线结构就是单线管道。像"找出去年第四季度的业绩数据,再把今年的战略提案初稿写出来"这样的请求,需要检索、提取数字、撰写文稿,而单线管道根本没有处理这种流程的路径。
便利店没有水时,人会打开地图找旁边那家便利店。单线管道只会说"没有"然后停下。检索没有结果,就换个关键词再试;还是不行,就改用网页搜索工具。受阻时折返的循环、依情况改道的分支——这两者是智能的核心,而设计它们的工作就是编排。
LangChain、LangGraph、LangSmith 各自负责什么?
LangChain 是与 LLM 对话的标准组件供应站。它提供提示词模板、让代码不随模型更换而改动的模型连接抽象,以及把任务按顺序串联的链式组合。但链仍然是从 A 到 B 的直线。
LangGraph 是控制流设计工具。节点是检索、判断、回答这样的工作单元,边是节点之间的路径,在边上设置条件就形成了循环和分支。LangSmith 是可观测性层。就像给 AI 系统装上监控摄像头,它记录每个节点检索了哪些文档、提示词如何输入、模型做了什么中间判断,既能回溯错误答案的原因,也为更换提示词或模型后的性能变化提供量化评估依据。三者齐备,才是一个完整的编排系统。
税务咨询自动化为什么需要循环和分支?
客户问"我想把楼赠与子女,税怎么算",经办人员就要查赠与税条款,还要核对该客户过去的赠与记录和累计赠与额。为了综合这两件事,一天花掉一两个小时是常事。一个 RAG 聊天机器人做不到:它需要在法条检索和记录查询之间往返、做出综合判断的分支。
流程图由问题分类、税法检索、客户记录查询、充分性判断、回答生成五个节点构成,依据不足时还有折返检索节点的循环。错误答案可能引发法律责任,所以可观测性也是必需的:系统必须自动留下审计日志——"检索了继承税及赠与税法第53条,参考了该客户2023年的事前赠与记录,据此作答"。
非开发者在这套设计中承担什么?
三件事。数据所有权——决定放入哪些税法文件、让 AI 看到客户记录中的哪些字段;把业务逻辑画成流程图;编写100道税务问题并附上标准答案,做成评估集。这些全是领域知识,而不是编程。垃圾数据进去,垃圾答案出来。只要会画流程图,把它变成代码的事交给 Vibe Coding 就行。
什么时候才该拿出编排?
对一次 API 调用就能完成的工作套上 LangGraph 是浪费。把复杂工具到处乱装,也成不了有实力的 Vibe Coder。当工作复杂到需要反复循环、需要按条件分岔时,才是拿出 LangChain、LangGraph、LangSmith 的时机。AX 的起点不是工具,而是能画出业务流程的领域知识。