Agent多步推理任务中，Prompt该怎么设计才能减少“幻觉”？

拆成子Prompt一步步来会更稳，但记得每步都强制带上检索原文引用，不然还是容易编。

硬性要求别光靠说，直接给个“没有依据就输出无法回答”的兜底模板试试。

碰到类似的问题，我是把推理链拆成两步走的：先让模型单独提取所有相关事实并标注来源，再丢给它一个“只准用这些事实”的指令做对比分析。感觉比全塞在一个prompt里稳很多，幻觉少了一大截。

硬性约束的话，我试过在每一步结尾强制要求输出“当前依据：引用原文片段”，没引用就让它重生成。虽然慢点，但至少编数据的情况少了。

你那边的ReAct在中间步骤编数据，会不会是工具返回的结果本身格式太乱，模型没吃透就瞎补全了？试试把检索结果压缩成带编号的要点喂给它，可能比直接堆原文有用。

拆成子Prompt更稳，每步强制带检索结果再推理，比一个长Prompt好控制幻觉。

试试在工具返回后加一句“仅基于以上内容回答”，模型就不太敢瞎编了。

我之前也踩过这个坑，ReAct风格如果system prompt写太满，模型反而容易“自由发挥”。我的做法是把工具调用结果直接以结构化文本（比如JSON）塞回对话历史里，并在每一步强制要求“先引用检索到的原文片段，再写推理”，这样能明显压制编造。至于拆分子Prompt还是单Prompt，我试下来小步骤（比如不超过3步）用单Prompt加few-shot示例更稳，步骤多了就拆开，但每拆一次都要把前一步的结论显式传下去，不然上下文一长还是容易丢信息。硬性约束的话，“如果你找不到依据，就明确回答‘未检索到相关信息’”这句比“必须基于检索结果”有效得多。

我之前也踩过这个坑，个人感觉把步骤拆成子Prompt单独调用会更稳一些，尤其是每一步都强制要求输出“检索到的原文引用”，这样能挡住不少幻觉。另外“必须基于检索结果”这种硬约束，你可以在每个子Prompt结尾加一句“如果找不到依据，请直接回答：无法确认”，比单纯强调“不要编造”管用得多。还有个细节，别在system prompt里堆太多规则，模型容易注意力分散，把关键约束放在用户消息里反而效果更好。

个人建议拆成子Prompt，每步强制绑定检索结果再推理，能压住不少幻觉。硬性要求就写“没有检索到就明确说不知道”，实测比“必须基于”管用。

我最近也在搞类似的RAG Agent，试下来感觉单Prompt约束太多反而容易乱，尤其是多步推理时模型会自己脑补中间结果。我现在是把每个工具调用和推理节点拆成独立Prompt，每一步强制让模型输出“检索到了什么”和“基于这个能得出什么”，再传给下一步，幻觉明显少多了。关于硬性要求，我习惯在每一步Prompt末尾加一句“如果检索结果中没有直接依据，请明确回答无法推断”，比单纯说“必须基于检索”管用，你试试看。

我觉得你这个问题挺典型的，拆成多个子Prompt肯定比一个劲塞进system prompt里稳，尤其是每步单独验证下输出，能拦住不少编数据的苗头。至于“必须基于检索结果”，我会在工具返回后加一句“如果信息不足，直接说不知道”，比硬性要求管用，因为模型更容易被“允许拒绝”给框住。你试过把ReAct的observation部分强制要求引用原文片段吗？我最近这么改，幻觉少了很多。

拆成子Prompt更稳，单次约束太多模型容易放飞，检索结果得让模型先复述再推理。

可以试试强制模型输出“检索到的原文+推理依据”，再给结论，比空喊“逐步思考”管用。

说实话，我之前也踩过类似的坑，尤其是模型跳过推理直接给结论那块儿，太真实了。我自己试下来，感觉与其把希望全压在system prompt的“咒语”上，不如把任务硬拆成两轮独立的调用，第一轮专门做“差异提取”，强制它输出结构化的对比列表，第二轮再把列表和C的信息一起塞进去，让它基于这些具体字段去推结论，这样中间步骤编造数据的概率会低很多。至于“必须基于检索结果”，我发现光说“请基于”没用，更有效的是给模型一个“证据引用”的格式要求，比如让它每一步都带上“根据文档第X段”或“检索到的事实：…”这样的前缀，甚至可以在Prompt里明确写“如果找不到支撑，直接回答‘无相关依据’，不要自行补充”，这种负向约束往往比正向鼓励管用。另外，你说的“逐步思考”效果不稳定，可能是模型在长上下文里容易丢掉指令，我习惯把关键要求放在每个子步骤的user消息里再强调一遍，而不是只在开头说一次。当然，拆成多轮调用也有代价，就是延迟和token成本会高不少，不知道你现在的Agent框架里，工具调用的灵活性够不够支持这种拆分？

拆成子Prompt更稳，每步单独校验结果，比一个长Prompt好控制多了。

硬性要求可以试试“只引用检索原文，没找到就直说不知道”，比“请逐步思考”管用。

多步推理确实容易在中间环节放飞自我，我试过把每个子任务拆成独立Prompt，反而更可控，因为每步都能单独验证结果。你可以在关键步骤后加一个“只输出检索到的原始数据，禁止总结”的硬指令，能砍掉不少编造。另外“逐步思考”对模型来说太模糊了，不如明确要求“先列出A和B的原始字段值，再写差异”，这样约束力强得多。

这问题我最近也踩了不少坑，尤其你提到“跳过推理直接给结论”，我怀疑是system prompt里指令太多太杂，模型反而把“逐步思考”当成了表面功夫。我的做法是，把推理步骤拆成独立的子Prompt，每个子任务只负责一个动作，比如“提取A的指标”“提取B的指标”“对比两者差异”，这样每一步的输入输出都更可控，模型不容易自己脑补中间数据。不过代价是token开销大，而且步骤多了容易累积误差，所以我会在最后加一个“基于前几步结果，重新核对原始文档”的验证子Prompt，专门挑矛盾点。至于“必须基于检索结果”的硬性要求，我试过在system里反复强调，但效果还不如在user prompt里直接给一句“如果某条信息在文档中找不到，请明确说‘无相关信息’，不要推测”——这招比“请逐步思考”靠谱多了，因为它给了模型一个具体的“拒绝路径”，而不是空泛的约束。另外你提到ReAct风格，我建议把工具返回的结果直接拼进当前对话，而不是让模型自己记忆，不然中间步骤一多，它很容易把之前编的数据当成事实。还有个小技巧：在prompt末尾加一个“最终结论必须引用工具输出的具体数值或原文片段”，这样模型为了满足格式，就得真的去翻检索结果。不过说实话，多步推理的幻觉问题光靠prompt很难根治，我也在试让模型先输出“计划”再执行，但效果时好时坏，你那边有试过给模型反馈“上一步结果错误”的闭环机制吗？

我之前也踩过这个坑，单靠“逐步思考”确实不稳定，模型一飘就自己编数据了。现在我是把任务强行拆成多个子Prompt，每个子任务单独调用工具并验证结果，再汇总，虽然慢点但准确率明显上去了。另外，硬性要求“必须基于检索结果”的话，我试过在system prompt里加一条“若参考内容与问题无关，请直接回复无法回答”，比单纯强调“不要编造”有效。你试试看能不能接受这个延迟成本？

这问题我太有共鸣了，最近也在搞类似的Agent，ReAct那套玩到后面确实容易被模型“自信地瞎编”。我个人感觉，多步任务别死磕一个Prompt里塞满约束，那样模型注意力容易散。我现在倾向于把“检索”和“推理”拆成两个独立的子调用，比如先让它强制输出“我检索到的原文是XXX”，再在下一个Prompt里只基于这段原文做推断，这样至少能掐断它凭空造数据的路径。至于“必须基于检索结果”这种硬性要求，我试过最有效的写法不是反复强调“不要幻觉”，而是直接给它一个“事实锚点”模板，比如要求每一步都必须以“根据【文档ID+原文引用】”开头，没有引用就不允许写下一步。不过你也得小心，拆太细可能引入新问题，比如子任务之间的上下文丢失，所以我现在还在试一个折中方案：主Prompt负责逻辑框架，每个子步骤里只给必要的检索片段，而不是把所有工具结果全塞进去。另外，“请逐步思考”这种话真的时灵时不灵，我后来换成“先列出已知条件和未知条件，再决定需要调用哪个工具”，效果稳定多了。你那边工具返回结果多吗？如果检索结果很长，模型反而更容易忽略关键信息，这块你有没有做截断或摘要？

试过拆成子Prompt，效果比硬塞一个大Prompt稳，但得把上一步结果喂清楚，不然更乱。

硬性要求就写“没检索到就明说不知道”，比“必须基于”好使，你试试。

把推理步骤拆成子Prompt单独调，幻觉会少很多，但延迟翻倍，得看场景取舍。

硬性要求“必须基于检索结果”别只写进system prompt，直接在工具返回里加“无数据则拒绝回答”更管用。

我觉得你这个问题问到了点子上，ReAct风格在多步推理里确实容易“飘”，尤其当工具返回结果和模型预判不一致时，它就会自己脑补。我自己试下来，把步骤拆成多个子Prompt单独调用，比硬塞在一个Prompt里稳定得多——每个子任务只负责一步，上下文干净，模型不容易被前面的“想象”带跑。比如“对比A和B”就单独让模型输出差异点，拿到结果后再丢进下一个Prompt做“结合C”的推理，这样每一步都能明确校验来源，幻觉基本被卡死在源头。

至于“必须基于检索结果”这种硬性约束，光写“请基于检索内容回答”是不够的，得把规则具体化，比如要求“回答中每个事实性数字或结论后面必须用[来源编号]标注，且只能引用检索片段中的原话”。我试过一个更狠的写法：“如果检索结果中没有直接证据支持你的推理，就必须在输出里明确写‘无直接依据，以下为推测’”，这样模型至少会主动识别“我不知道”的边界，而不是硬编。另外，你提到“请逐步思考”不稳定，我建议换成“先列出你需要的所有事实，再逐条对照检索结果打勾，最后才写结论”，这比泛泛的“逐步”更可执行。还有个小技巧，可以在每步工具调用后强制模型先复述“我刚刚检索到的原文是……”，再开始推理，相当于逼它先“看见”再“思考”，出错率会低不少。你现在的Agent是每次工具调用都单独触发一次LLM，还是让模型自己决定连续调用？这个结构差异其实影响挺大的，可以聊聊。

这问题我太有共鸣了，之前做类似的多步RAG Agent时也被“幻觉”坑惨过。我自己试下来，觉得把一个长Prompt拆成多个子Prompt单独调用，效果比硬塞在一个System里稳定得多，尤其是中间步骤需要工具结果的时候，分开调能让模型每一步都“看到”真实数据，而不是靠记忆瞎编。至于“请逐步思考”这种话，真的时灵时不灵，我后来改成在Prompt里明确要求“每输出一个结论前，必须引用一次检索到的原文片段”，并且把“禁止使用未在上下文中出现过的数字或事实”直接写成硬性规则，比单纯说“要基于检索结果”管用很多。另外我有个小技巧，就是故意在Prompt里留个“检查点”，比如“如果上一步的工具返回为空，请直接说明无法推理，而不是猜测”，这样能逼模型面对不确定性。不过我也还在摸索，比如多步推理时，每步之间的上下文怎么传递最不容易丢失信息，不知道你有没有试过把中间结果显式存成变量再喂给下一步？

拆成子Prompt吧，每步单独校验结果比一次性约束靠谱，还能减少编造。
我试过在工具调用后强制加“引用原文编号”的指令，幻觉少很多。