企业官网建设流程全解析

如果你在真实的Agent项目里待过一段时间，大概率见过这种让人血压飙升的画面：客服Agent信誓旦旦告诉用户“我们线下门店晚上十点关门”，实际上六点就下班了；代码生成Agent把编译器根本不认识的API写得有模有样；数据分析Agent拿着虚构的统计数据，给你出了一份看起来很专业的报告。这些问题背后，都指向同一个名词——Agent幻觉。

我这两年面试过不少做Agent的候选人，也帮团队搭过几套知识库问答和自动化办公系统，最大的感受是：单纯让模型“别胡说”是一句正确的废话，真正能落地的是把幻觉当成一个系统工程问题来治。所以这篇文章我会把实战中反复验证过的一套思路完整拆开，核心就是三层管控：边界划定、RAG链路优化、工具验证。这套东西既适合正在准备面试的工程师建立回答框架，也适合已经在做Agent项目、被幻觉问题折磨到想骂人的同学直接抄作业。

1. 先看清楚Agent幻觉到底是什么

1.1 幻觉不是一种病，而是好几类症状

很多人一提幻觉就是“模型编造事实”，但放到Agent场景里，幻觉的形态要比这复杂得多。网上有个说法叫“五类七特虚实迷域”，听起来玄乎，其实思路是对的——幻觉必须分类讨论，因为不同类型对应的解法完全不同。

以我的经验，Agent场景里至少要把幻觉分成这几类：

• 事实性幻觉：模型一本正经地输出与事实不符的内容。比如回答公司产品的价格时，把旧版本的价格报给用户。
• 指令忠实性幻觉：模型没有遵循用户的核心指令。用户明确说“只要列出三个要点”，它非要给你写一篇小作文。
• 逻辑一致性幻觉：模型前后回答自相矛盾，或者推理链条里出现了明显断裂。比如计划里说“先查A再查B”，实际执行却跳过了B。
• 上下文漂移幻觉：在多轮对话里，模型把早前已经纠正过的信息又拿出来用，或者把不同用户的信息混在一起。
• 工具调用幻觉：这一点是Agent独有的。模型调用了不存在的工具参数、虚构工具返回结果，或者在工具执行失败后“脑补”一个成功的结果继续往下走。

如果面试时你能把这个分类讲出来，基本已经胜过一大半只说“幻觉就是胡说八道”的候选人了。

1.2 为什么“彻底解决”是个伪命题，但必须管

先泼一盆冷水：在当前LLM的架构下，想100%消灭幻觉是不现实的。语言模型本质上是概率模型，它在生成每一个token时都在做“下一个词”的预测，遇到知识盲区或信息不足时，它的本能就是“填空”，而不是“承认不知道”。这个过程发生在模型内部，你很难在推理阶段通过某一个开关彻底关掉它。

那为什么我们还要追求“彻底解决”？因为业务视角和模型视角不一样。用户真正在乎的不是“模型脑子里有没有幻觉”，而是“Agent最终交付的结果是否正确、是否可追溯、是否安全”。所以三层方案的核心目标不是把幻觉概率降到0，而是做到三件事：

• 可控：让幻觉不发生在高风险的环节。
• 可观测：一旦发生，能快速发现、定位、追溯。
• 可兜底：即使发生了，也能在产生实际危害前拦下来。

这三个词是面试时非常加分的表达，也是工程落地时真正要花费心思的地方。

1.3 面试第一问的逻辑：先说清楚问题本质

我面试时如果问“你怎么解决Agent幻觉”，最怕听到的回答是直接背Prompt模板。因为如果连问题都没有定义清楚，方案一定是散的。

所以建议准备面试的同学先形成一个共识：所有幻觉管理方案，本质上都是在做“信息边界”和“行动约束”。模型不知道的东西，要么给它检索的通道去查，要么明确告诉它“不知道就说不”；模型不确定的行为，要么限定它只能走预设的流程，要么在执行后验证结果。这个认知框架，就是后面三层方案的底层逻辑。

2. 第一层：边界划定，从源头收缩模型的“发挥空间”

2.1 系统提示词里的能力边界声明

很多人写System Prompt就写一两句话，比如“你是一个智能助手，请用中文回答”。这在Agent场景里远远不够。能力边界声明要做的是：告诉模型哪些事能做、哪些事绝对不能做、哪些事做了也必须先承认不确定性。

我常用的模板结构分四块，实测下来对幻觉有直接压制效果：

你是企业知识库问答助手。 能力范围： - 只能基于提供的知识库文档回答用户问题。 - 可以调用以下工具：文档检索、订单查询、工单创建。 禁止行为： - 禁止编造知识库中不存在的政策、价格、数据。 - 禁止猜测用户身份或订单信息。 - 禁止在没有检索结果的情况下直接回答专业问题。 不确定性处理： - 当检索结果不足或与问题无关时，必须明确回复“我无法从现有资料中找到答案”，不允许自行推测。 - 当问题涉及实时数据但工具未返回结果时，不得编造数值。

这段提示词看起来简单，但它把“模型自由发挥的空间”压缩到了最小。你不需要完全相信模型会遵守，但先划定边界，后面再配校验和兜底，就是一个递进的保险思路。

2.2 输出契约化：让模型别自由发挥

边界划定的第二个硬手段是输出契约化。通俗地说，就是用JSON Schema、枚举值、必填字段把模型的输出格式焊死。模型一旦被约束在结构化输出里，它“自由创作”的概率会显著下降。

以我最近做的订单查询Agent为例，我们要求所有回答先输出一个结构化结果，再渲染成自然语言。Schema大致长这样：

{ "type": "object", "properties": { "has_result": { "type": "boolean", "description": "是否找到明确结果" }, "answer": { "type": "string", "description": "对用户的最终回复" }, "confidence": { "type": "number", "minimum": 0, "maximum": 1, "description": "置信度" }, "references": { "type": "array", "items": { "type": "string" }, "description": "引用来源ID列表，可为空" } }, "required": ["has_result", "answer", "confidence", "references"] }

当has_result为false或者references为空数组时，上层服务可以根据策略直接拦截，不允许把这段回答发给用户。这比事后去判断“模型这句是不是在瞎说”要可靠得多。现在很多模型和框架都原生支持结构化输出，比如OpenAI的JSON mode、LangChain的with_structured_output，把它接入链路成本很低，强烈建议每一层都加。

2.3 拒答与置信度机制

有个很反直觉但很重要的观点：一个会承认自己不会的Agent，比一个永远自信的Agent更可靠。RAG场景里，检索不到内容时模型硬答，是最常见的幻觉来源之一。

工程上需要设计一条严格的拒答策略：

• 单路检索Top K结果的相关度得分低于阈值，直接触发拒答。
• 多路召回的交叉验证不一致，触发澄清式回答，而不是直接给结论。
• 结合置信度评分，低于0.6时在回答中带上“该结论可能不准确”的前缀。

你可能觉得拒答会损伤用户体验，但真实运营数据说话：用户对“对不起我没查到”的容忍度，远高于对错误答案的容忍度。一次错误答案可能让用户直接流失，而“没查到”至少保住了可信度。

2.4 状态机与工作流约束：用框架管住Agent

这部分是Agent区别于普通ChatBot的关键。ChatBot可以自由发挥，但Agent一旦要调用工具、查询数据库、创建工单，就必须被流程约束。如果模型可以“自由地”决定调用什么工具、按什么顺序调用，幻觉的出现概率会指数级上升。

我自己用的比较顺的方案是基于LangGraph做StateGraph状态机。设计上把Agent的流程拆成固定节点：意图识别 -> 检索 -> 工具调用 -> 答案生成 -> 自检。每个节点只允许访问特定的工具和状态字段，模型不能跳出这些节点自己乱跑。

这样做的好处很直接：模型被降级为“节点内的执行器”，而不是整个流程的决策者。它可以在检索节点决定要查哪些文档，可以在工具节点决定要不要调用查询接口，但它不能自己发明一个新的流程路径。这和“harness”约束模型行为、以及“skill”和“agent”之间的分工逻辑是一致的——“框架负责纪律，模型负责智能”。

2.5 边界划定的面试表达

如果在面试中被问到边界划定，不要只回答“写System Prompt”。你可以按照“声明边界 -> 输出契约 -> 拒答策略 -> 流程约束”这条线展开，每个环节举一个实际例子。这套表达既体现了你对Prompt工程的理解，又展示了工程架构能力，比单纯背一句“我们用了很详细的提示词”有说服力得多。

3. 第二层：RAG链路优化，让每个答案都有据可查

3.1 检索质量决定幻觉下限

边界划定能防住一部分幻觉，但解决不了“模型有答案但答案是错的”这个核心问题。要解决这个问题，必须上RAG。但注意：RAG不是万能药，如果检索链路做得粗糙，模型反而会因为“检索到了错误信息”制造更隐蔽的幻觉。

我做RAG项目第一件事永远是处理文档切片。切片策略直接影响检索效果，我踩过的坑包括：PDF直接按页切、超长文本一刀切、表格被切成碎片。

现在稳定使用的参数组合是：

• chunk_size：500到800字之间，太短则信息不完整，太长则引入噪声。
• overlap：80到120字，保证上下文衔接。
• 表格数据：转成Markdown后再切，保证行列结构完整。
• 代码类文档：按函数或类级别切，不要按行数硬切。

关于Embedding模型，我目前生产环境用得多的是bge-m3这类中英文兼顾的模型。如果你只需要处理中文业务文档，也可以考虑m3e或同规模的中文模型。不要盲目追求大参数模型，Embedding的维度、推理延迟、部署成本，在真实项目里比那零点几个点的Recall提升更重要。

另外，纯向量检索对关键词敏感的场景并不友好，比如查“合同编号：HT-2024-001”，向量召回经常不如BM25。所以我现在的检索链路都是混合检索：BM25稀疏检索 + Embedding稠密检索并行，再用RRF（Reciprocal Rank Fusion）合并排序。这个改动在业务上的效果立竿见影，属于投入产出比极高的一项优化。

3.2 重排序与上下文窗口管理

召回阶段一般会返回20到50条候选，但最终能塞进Prompt的只有3到5条。如果直接按向量相似度取Top K，很可能把最相关的内容漏掉，或者让无关内容混入上下文。解决这个问题要靠重排序模型。

我一般会把bge-reranker-base放在召回之后做精排。用法很简单：把用户问题和召回片段逐条拼接成pair，让reranker打分，再按分数重新排序，最后只取Top 3或Top 5。重排序这一步能让最终的检索精确度提高一大截，尤其适合大文档库场景。

上下文窗口管理同样关键。模型不是上下文越长越好，塞入的无关内容越多，注意力被稀释，幻觉概率反而会升高。所以我们要做的不是简单加长上下文，而是“精选+压缩”：

• 只保留与问题确实相关的片段。
• 压缩冗余的空白字符、导航文字、页眉页脚。
• 对长文档做摘要后再进Prompt，保证核心信息不丢，噪声被滤掉。

这一步之后，Prompt里塞给模型的每一段文字都是“有用的”，模型基于这些信息生成的答案，准确性会明显提升。

3.3 引用溯源：无引用不答

这是我认为对抗RAG幻觉最有效、也最容易被忽视的一环。做法很简单：要求模型在生成回答时，必须带上检索片段的来源ID，并且不允许输出没有引用支撑的断言。

我在企业知识库场景里会刻意在Prompt中强调引用规范：

回答要求： - 每一条核心结论后面，必须用方括号标注来源文档ID，例如[12]。 - 允许参考多个来源，但不得把不相关的来源混为同一依据。 - 如果检索材料不足以支撑结论，必须明确说明“资料不足”，不得强行作答。 - 禁止输出未出现在检索材料中的数据、日期、人名和数字。

同时，服务端会做一层引用校验：检查模型输出的来源ID是否确实存在于本次召回的文档集合中。一旦发现模型引用了不存在的来源ID，直接整段拦截重答。这一步等于给模型戴上了“引用口罩”，逼它只能从给定材料里找依据。

3.4 Agentic RAG与Ontology RAG的进阶玩法

如果你做的不是简单的单轮问答，而是需要多跳推理的Agent场景，那么基础RAG是不够的。比如用户问“上季度退货率最高的三个SKU分别是什么颜色”，你需要先定位“退货率数据表”，再关联“SKU主数据表”，最后按“颜色维度”聚合。这种多步查询如果一股脑丢给RAG，召回结果一定是乱的。

这种场景要上Agentic RAG。思路是让Agent根据问题逐步决定检索策略：先检索有没有相关的表，再查询具体指标，然后根据前一步结果决定下一步动作。每一步的检索结果都会被验证和缓存，作为下一步决策的上下文。相当于模型不再“一次想好全部答案”，而是“边查边想”，幻觉的空间被大幅压缩。

再进一步，如果业务领域高度垂直，可以引入Ontology RAG，也就是用领域本体（Ontology）约束检索范围。比如在医疗问答系统里，定义疾病、症状、药物、检查之间的语义关系，让检索只能沿着本体图谱展开。这样模型很难“跨界”编造，因为每个结论都要落在本体定义的结构里。

3.5 RAG效果的量化评估体系

解决RAG幻觉不能只靠感觉。任何优化上线前，都必须有量化指标来验证是否有效。我现在的评估方案分成两层：

第一层是自动化指标，借助RAGAS这类框架，算四类分数：忠实度（Faithfulness）、答案相关性（Answer Relevance）、上下文相关性（Context Relevance）、上下文召回率（Context Recall）。其中忠实度是最接近“幻觉程度”的指标，它衡量的是“生成答案中有多少内容能从检索上下文中找到依据”。

第二层是人工评测集，准备大约100到200条真实业务问题和标准答案，每次链路改动后跑一遍回归测试，记录幻觉率、拒答率、准确率三个数字。注意，优化时很多时候“拒答率”上升反而是好事，因为这意味着系统学会了承认不知道。

面试时如果能说出“我们用RAGAS做自动化评估，忠实度从0.72提升到了0.89，人工评测幻觉率从18%降到了6%”，这个数据化表达比任何技术名词都更有说服力。

4. 第三层：工具验证，行动前检查与行动后兜底

4.1 工具参数Schema校验

Agent做事的核心动作是调用工具，而工具调用恰恰是幻觉的高发区。模型可能捏造不存在的参数、把字符串类型的值传给数字字段、或者在必填字段上缺斤少两。解决办法是在模型和真实工具之间加一道参数校验层。

所有工具定义必须写JSON Schema，并在执行前做严格校验。举个例子，一个订单查询工具的Schema：

{ "type": "object", "properties": { "order_id": { "type": "string", "pattern": "^ORD\\d{10}$" }, "query_type": { "type": "string", "enum": ["basic", "logistics", "payment"] } }, "required": ["order_id", "query_type"] }

如果模型生成参数时，order_id不符合正则格式，或者query_type不在枚举范围内，服务端直接拒绝并返回错误信息给模型：请重新生成。这一步看似简单，但它把“模型乱造参数”的路径彻底堵死了。

4.2 工具结果校验与反馈拟合

工具调用完成只是第一步，更关键的是校验工具返回的结果是否合理。我在项目中总结了几个常用校验规则：

• 空值校验：查询接口返回空列表时，不允许模型脑补“查无此人”或“订单不存在”以外的结论。
• 类型校验：返回的数值必须符合字段类型，出现负数的库存、非数字的价格直接标记异常。
• 时效校验：实时数据的返回时间超过阈值时，结果作废并重新查询。
• 逻辑校验：比如用户问“物流状态”，工具返回的是“退款记录”，很明显是工具选择错误，需要重新规划。

校验通过后，工具结果必须原样拼接进Prompt，作为下一步生成答案的依据。这里有一个常见的错误：模型调用完工具后，直接把原始输出扔了，只凭“记忆”继续回答——这等于工具白调了。正确的做法是把工具返回的文本和结构化数据一并塞入上下文，再让模型基于这些内容做最终生成。我在工程上通常会把工具结果做成“system message”的一部分，排在用户问题之后，让模型在生成时明确看到参考数据。

4.3 失败处理：超时、重试与异常兜底

工具调用一定会失败，而失败时的表现，是区分优秀Agent和玩具Agent的分水岭。我最开始做Agent时，模型调用查询接口超时，它自己在回答里写“查询成功，订单已发货”，把所有人都看笑了。后来我把每条工具调用都套了一层统一的异常处理：

def safe_call_tool(tool_func, **kwargs): try: result = tool_func(**kwargs) if result is None or result == "": return {"status": "empty", "data": None} return {"status": "ok", "data": result} except TimeoutError: return {"status": "timeout", "data": None} except ValidationError as e: return {"status": "invalid_params", "data": str(e)} except Exception as e: return {"status": "error", "data": str(e)}

所有工具返回统一成{status, data}结构，模型只能看到status=ok的真实数据，其他状态会触发预设的兜底话术，比如“系统暂时无法获取该信息，请稍后重试”。这样模型根本没有机会在失败后“编造一个成功结果”。

同时还要设计重试机制：对于超时类错误，最多重试2次，间隔1秒和3秒；对于校验类错误，把错误信息反馈给模型，让它修正参数后重新调用，最多2次。重试仍失败，就进入人工兜底流程或友好拒绝。

4.4 自我反思与Human-in-the-loop

再往上走一层，是让Agent具备自我反思能力。我目前用过最有效的方式是Reflexion模式：Agent生成答案后，不直接交付，而是先进入一个Critique节点，用一份自检清单逐项检查自己的输出。

自检清单的典型内容：

• 回答中的每一个关键数值，是否都能对应到工具返回结果或检索片段？
• 是否引用了不存在的来源ID？
• 是否回答了用户真正的问题，还是答非所问？
• 是否存在前后矛盾的陈述？

如果自检不通过，Agent必须重新生成答案，或者向用户发起澄清。这套机制在复杂多轮任务里尤其必要，因为它相当于让模型“扮演自己的审查员”，从PM视角重新审视一遍自己的输出。

对于高风险的Agent动作，比如自动发送邮件、执行转账、提交工单，我坚持加入Human-in-the-loop节点。流程是：Agent先生成拟执行的操作和理由 -> 推送给人工审批 -> 人工确认后，才真正执行。虽然这会让自动化程度打折扣，但在高风险场景里，这是最后一道不可妥协的防线。面试时能主动谈到“哪些环节必须保留人工介入”，会显得你对工程边界有成熟判断。

4.5 工具层的面试回答武器

工具验证这部分最大的价值在于，它体现了一个候选人对Agent“行动闭环”的理解。不少候选人讲RAG讲得头头是道，但一追问“工具调用失败怎么办”就沉默了。如果能完整地把参数校验、结果校验、异常兜底、反思机制、人工审批这条链路讲清楚，你已经不是在背面试题，而是在分享一套真实可用的工程方案。

5. 面试实战：从“方案”到“话术”

5.1 面试官最爱的5个追问与参考回答

追问1：RAG都上了，为什么还会幻觉？

参考回答思路：RAG缓解的是知识缺失问题，但幻觉还来自三个地方——检索不准导致模型拿到无关资料；检索结果被模型忽略，模型更信任自己的参数记忆；上下文过长导致注意力稀释。所以只加RAG不优化链路，幻觉照样存在。

追问2：怎么量化评估幻觉有没有减少？

参考回答思路：自动化指标用RAGAS的忠实度，人工指标用标准测试集统计幻觉率和拒答率。还要按业务场景拆指标，比如客服场景重点看“政策条款回答的准确率”，数据分析场景重点看“数值引用错误率”。

追问3：如果检索结果和模型参数记忆里的内容冲突了，谁说了算？

参考回答思路：以检索结果为准，同时Prompt里显式声明“优先参考提供的资料，不要使用你记忆中的信息”。如果冲突严重，可以在服务端做一致性检测，发现答非所问就拦截重答。这个冲突检测本身也是幻觉观测的手段。

追问4：团队资源有限，先做哪一层？

参考回答思路：先做边界划定里的拒答和输出契约，这个成本最低，见效最快。再上RAG的引用溯源，要求模型必须标明依据。这两步做完，大部分幻觉就已经可控了。工具验证可以随Agent功能逐步完善，不必一次性铺满。

追问5：有没有不存在幻觉的Agent架构？

参考回答思路：严格说没有。但从工程角度看，如果Agent的每个动作都能被约束在“检索、计算、校验”的闭环里，并且每个输出都有引用和工具结果作为依据，幻觉就被压缩到了可接受的范围。追求“彻底”不如追求“结果正确且可追溯”。

5.2 最容易丢分的三个坑

第一个坑：一上来就说Prompt，把幻觉问题当Prompt问题处理。幻觉是系统性问题，Prompt只是边界划定的一部分，只讲Prompt会让面试官觉得你项目经验浅。

第二个坑：把RAG描述成银弹。如果你回答“我们用RAG解决了幻觉”，却没有讲检索质量怎么保证、重排序怎么做、评估指标是什么，面试官几乎一定会反问细节然后把你问倒。

第三个坑：混淆训练期幻觉和推理期幻觉。微调可以缓解一部分训练期固有知识错误，但推理期的上下文冲突、工具编造，微调是管不了的。把这两类分开讲，才能体现出你理解模型的底层机制。

5.3 一条可背诵的30秒回答主线

如果你需要一个稳的开场表达，可以用这条主线：

“我会把Agent幻觉当成系统问题来做三层管控。第一层是边界划定，通过系统提示词、JSON Schema和状态机约束Agent的能力和输出形式，让它知道哪些事不能做；第二层是RAG链路优化，通过混合检索、重排序、上下文精调和引用溯源，保证每一个答案都有依据可查，我用RAGAS评估过，忠实度从0.72提升到了0.89；第三层是工具验证，所有工具调用都要过参数校验和结果校验，失败时有异常兜底，高风险操作再叠加反思机制或者人工审批。这套方案不能把幻觉概率降到零，但能让幻觉不影响最终结果的正确性和可追溯性。”

这段话不华丽，但信息密度高，能展示你的工程视野和实操经验。

6. 落地顺序与个人体会

方案讲完，最后聊聊我自己落地时的顺序和感受。如果团队刚起步，资源有限，我的建议是别一上来就铺满三层。先做第一层的拒答策略和输出契约，这一步基本不依赖额外资源，把系统提示词和JSON Schema写好，就能消灭掉很大一部分“瞎编”的问题。

然后是RAG的引用溯源。给你的Prompt加上“每条结论必须标注来源”的规则，并且做来源ID校验。这个改动通常一到两天就能上线，效果立竿见影。之后再逐步上混合检索、重排序，充实知识库的召回质量。每一步改动后，记得跑一次回归测试，把幻觉率、拒答率、准确率记下来，用数据驱动下一轮迭代。

工具验证可以等Agent开始接真实业务系统时再完善。先接一个工具，把参数校验、结果校验、异常兜底跑通，形成一套可复用的工具封装模板，后面再接入更多工具时成本就很低了。

我个人在实际操作中有一个体会：很多幻觉问题其实是产品设计问题，而不是模型能力问题。用户问的问题过于开放、工具的边界过于模糊、评估标准不明确，都会放大幻觉的影响。与其指望模型每次都判断准确，不如把产品流程设计得“窄”一点，让Agent只能在特定范围内做决策，风险自然就小了。

这个领域发展很快，但三层管控的思路短期内不会过时——因为无论模型底层怎么升级，业务系统对“答案正确、可追溯、可兜底”的要求不会变。希望这篇文章能帮你在面试中多一份从容，也帮你在真实项目里少踩几个坑。