考察点
这道题出自阿里巴巴 Agent 开发校招一面（2026 年牛客面经），两问其实是递进关系：第一问看你是不是徒手搓循环还是真用过编排框架，以及选型理由是否清醒；第二问"怎么解决幻觉"是 agent 落地的经典拦路题，面试官想听的是体系化的防线而不是"用 RAG"三个字——幻觉在 agent 场景比 chatbot 场景危险得多，因为幻觉的输出不只是错误文字，还可能触发错误动作。高分答案会把幻觉按来源分类，再对症下药。追问常往"LangGraph 和 LangChain 的关系""结构化输出失败怎么兜底""校验逻辑本身也是模型，套娃怎么办"上走。
参考答案
编排框架：我们用了什么、为什么
项目里流程编排用的是 LangGraph，但要说清楚的是：我们只用它的一小部分——状态图和 checkpoint，没用全家桶。选型时对比过三条路线。
一是纯代码 agent loop（while 循环 + 工具分发），优点是零依赖、行为完全可控，缺点是流程一复杂（多分支、人工介入、失败恢复）状态管理就手搓得很难看。二是LangChain 的 Chain/Agent 抽象，链路抽象在简单场景快，但隐式行为多，调试时黑盒感重，我们早期版本用过，后来逐步退掉了。三是LangGraph：把流程建模成显式状态图——节点是函数（模型调用、工具执行、人工审批），边是转移条件，全局共享一个状态对象。选它的核心理由是可控性和可恢复性：每一步的输入输出都在状态里，配合 checkpointer（我们用的 SQLite 后端做持久化）可以断点续跑，人工审批节点天然支持"暂停-等待-注入结果-继续"。对于要上生产的 agent，这两点比开发速度重要。
也评估过 AutoGen、CrewAI 这类多 agent 框架，当时的判断是它们对"多角色对话式协作"抽象得好，但对我们要的"确定性流程 + 局部自主"场景反而束手束脚，所以多 agent 部分是在 LangGraph 之上自己实现的节点级子图。
幻觉治理：先分类，再下药
幻觉不是一个问题，是好几个问题的统称，混在一起谈方案必然空泛。我按来源分三类，对应五道防线。
事实性幻觉——模型凭记忆编造不存在的事实（接口、参数、政策条文）。防线是grounding：规定模型只能用本轮工具返回和检索到的内容作为事实依据，prompt 里明确"不知道就调工具查，查不到就说不知道"；知识密集型场景配 RAG，且要求引用来源，评审时只采信带来源的论断。关键工程细节：工具返回要在消息里明确标记为"观测事实"，与模型的推断区分开，下游校验只信前者。
执行性幻觉——模型幻觉出工具执行的结果，典型如"文件已修改""测试已通过"但实际没调工具。防线是结构化输出 + 状态校验：工具调用走 function calling 的强 schema 而不是自由文本，执行结果只能来自工具真实返回；agent 汇报进展时要求附"证据指针"（diff 摘要、测试输出末尾 N 行），编排层对关键节点做程序化核对——比如"声称测试通过"的节点，由代码去查测试进程的真实退出码，不信模型自述。
逻辑性幻觉——推理链中间步骤出错，后面一本正经地错下去。防线是分而治之与关键路径确定性化：长链条任务在编排层拆成短节点，节点间传递结构化中间产物而不是一大段推理散文，错误被隔离在单节点内容易发现；更重要的是能用代码算的就别用模型算——金额计算、日期比较、配置合并这类确定性逻辑直接写成代码节点，模型只负责它擅长的判断和生成，这是幻觉治理里 ROI 最高的一条，也常被忽视。
最后是兜底：高风险动作人工审批。删除、发布、对外发送这类不可逆操作，不管前面防线多厚，都必须人在回路。agent 系统的可信度是设计出来的，不是模型赏的。
可能的追问
校验节点也用模型，模型校验模型不是套娃吗？ 两个原则破局：校验任务比生成任务简单得多（判断"这段代码能不能编译"比写出能编译的代码容易），用小模型做校验性价比和准确率都够；能程序化校验的（编译、测试、schema）坚决用程序，模型校验只用于没有程序化手段的判断题。
LangGraph 有什么让你不爽的地方？ 概念学习曲线陡，图抽象对简单流程是杀鸡用牛刀；调试时状态在图里流转，trace 不如纯代码直白。我们的原则是流程少于三四个节点就用纯代码 loop，复杂度真上来了才进图。
幻觉能做到零吗？ 不能，目标是把幻觉的"发现成本"降到最低：让幻觉要么在生成时被防线拦住，要么留下可检测的痕迹（无引用、无证据）。承认残余风险存在，用审批和回滚机制管理它，比宣称"解决了幻觉"专业得多。