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

建议拆成子任务挨个调，每步强制带检索结果做前缀，比堆在一个Prompt里稳得多。

我个人经验是别太迷信“请逐步思考”这种万能咒语，模型在长上下文中很容易把指令当耳旁风。你提到ReAct风格，我觉得问题可能出在把推理步骤和工具调用混在同一个system prompt里，系统指令一旦长了，模型对中间状态的跟踪能力反而会下降。我最近的做法是，把每个推理步骤拆成独立的子Prompt，每次只让模型做一件事，比如先“提取A的指标”，再“提取B的指标”，最后“基于这两个结果对比”，每步都强制它输出一个JSON结构，里面带上“检索到的证据原文”和“基于证据的结论”两个字段，这样如果它编数据，字段里就会露馅。对于“必须基于检索结果”这种硬约束，我试过在每条子Prompt末尾加一句“如果检索结果中没有相关信息，请明确输出‘未找到’”，比单纯说“不要编造”有效得多。另外，你提到跳过推理直接给结论，这往往是模型觉得前面步骤“不够重要”或“太明显”导致的，我建议在子Prompt里故意增加一个“中间结论复核”环节，让它把前一步的输出复述一遍再继续，虽然会多花点token，但能显著减少幻觉。还有个坑是，如果你用ReAct，工具返回的结果本身格式要干净，别把大段原文塞进去，提前用摘要模型压缩成带编号的要点，模型更容易引用。你也可以试试把“多步推理”改成“多轮对话”，每轮把历史结论作为新输入的一部分，而不是全部塞进system prompt，这样上下文切换更清晰。最后想问下，你目前用的模型上下文窗口多大？如果太小，多步推理确实容易丢信息，可能得考虑换更长窗口的版本。

我个人经验是，把多步推理拆成几个独立子Prompt调用比硬塞一个超长Prompt稳得多，因为每步单独给工具结果做上下文，模型不容易在前面步骤里“自由发挥”。关于“必须基于检索结果”，我试过在每一步前面加一句“如果检索内容里没有，直接回答‘未找到’，不要推测”，比笼统的“请基于事实”有效。另外，你那个“逐步思考”不稳定的问题，可能跟推理链太长有关，试试在中间步骤强制输出一个“证据列表”再让模型下一步做判断，幻觉会明显少。

拆成子Prompt单独调吧，每步强制绑定检索结果再推理，幻觉能少一大半。

多步推理里硬塞一个system prompt确实容易崩，我试过把每个子任务拆成独立Prompt调用，中间结果用结构化输出存下来再传给下一步，幻觉少很多。至于“必须基于检索结果”这种，可以试试在每一步的prompt末尾加一句“如果当前信息不足以回答，直接输出‘信息不足’，不要推测”，比单纯说“请逐步思考”管用。另外，你可以把工具返回的数据格式固定成带来源标签的JSON，让模型必须引用标签，这样就算它想编也编不出来——不过代价是响应慢一点，看你能不能接受。

我之前也踩过这个坑，ReAct风格写进system prompt确实容易让模型“表演”推理。后来我改成把每个工具调用结果显式存进memory，并在下一步prompt里回填“上一步检索到的原文片段”，幻觉少了很多。你可以试试把“必须基于检索结果”改成“如果检索内容不包含所需数据，直接回答‘未找到’”，比单纯强调约束有效。至于拆分子Prompt，我建议对关键对比步骤单独调用一次，把结构化结果传回主链，比全塞一个prompt稳定。

我之前也踩过这个坑，多步推理一旦全塞进system prompt里，模型特别容易在中间环节“自圆其说”。后来我改成每个子步骤单独调一次LLM，把上一步的输出直接作为下一步的上下文，幻觉明显少了很多，虽然慢点但结果可控。至于“必须基于检索结果”，我试过在prompt末尾加一句“如果找不到证据，直接回答不知道”，比单纯强调“不要编造”管用。另外，你可以在每步推理前强制模型先引用原文片段，这样就算它想跳步也会被格式卡住。

我之前也踩过这个坑，后来发现把推理步骤拆成多个子Prompt反而比一口气塞给模型更稳，尤其是对比类任务，每步单独校验一次检索结果，幻觉少很多。至于“必须基于检索内容”，我试过在system里加“如果信息不在上下文中，直接说不知道”比反复强调“不要编造”管用，你可以试试。不过拆得太碎也有问题，上下文切换会丢信息，所以得看任务复杂度，你现在的工具调用是串行还是并行？

拆分多个子Prompt调用吧，每步强制绑定检索结果再推理，幻觉能少一大截。

硬性要求就写“若检索无依据，直接回答不知道”，比“请逐步思考”管用多了。

拆成子Prompt更稳，单轮塞太多步骤模型容易偷懒跳步，检索结果最好单独拎出来做约束。

试试把推理拆成几步独立调工具，每步都强制带上检索原文再继续，幻觉能少一大半。

我之前也踩过这个坑，ReAct风格写太满反而容易让模型在中间步骤“脑补”。后来我把推理拆成两轮：第一轮只让模型列证据和差异，第二轮才让它基于这些证据下结论，幻觉明显少多了。硬性约束的话，我会在system里加一句“如果检索结果里没有对应数据，必须明确回答‘未找到’，禁止推测”，比单纯说“请基于事实”管用。你可以试试把“逐步思考”换成“先输出你引用的原文片段，再写推理”，模型会更老实。

多步推理里硬塞一个prompt确实容易翻车，我试过把每个推理节点拆成独立的子任务，每步都让模型输出“依据原文哪句话”再进入下一步，幻觉率明显降了。你那个“必须基于检索结果”的硬约束，可以试试在关键步骤前加一句“如果找不到直接证据，就明确回答证据不足，禁止补全”，比单纯说“请基于事实”管用。另外“逐步思考”有时候反而让模型编得更自信，不如改成“每做出一个结论，必须引用一条检索到的原文片段”。

说实话你这个情况我太熟了，之前做类似Agent的时候也栽在“中间步骤编数据”上。我自己的经验是，ReAct风格里的“思考”部分其实特别容易放飞，因为模型会把推理和生成混在一起，尤其是当检索结果不够直接时，它就会自己脑补。后来我改成把每一步工具调用做成独立的子Prompt，每个子Prompt里只放当前这一步需要的上下文和明确指令，比如“只根据以下检索内容回答，不得补充任何外部知识”，这样确实稳很多。

但子Prompt多了也有问题，就是上下文衔接容易断，特别是涉及对比和跨步骤引用时，模型经常忘了前面拿到的数据。所以我现在是混合着来：主Prompt里只写任务目标和最终输出格式，把“逐步推理”拆到每次工具调用后的临时Prompt里，这样既限制了它跳步，又不会让它在一个超长Prompt里迷失。关于“必须基于检索结果”，我觉得别用“必须”这种词，效果反而差，你可以试一下“如果检索内容中没有明确信息，请直接回答‘未找到’，不要尝试推断或举例”，这种否定式约束比肯定式要求管用得多。

另外你提到“请逐步思考”效果不稳定，我怀疑是因为它有时候会把“思考”当成可以自由发挥的区域。我试过把“思考”改成“计算过程”或者“证据链”，让模型把每一步都写成“根据文档X的Y段，得到Z”，这样它就没那么容易跳出检索结果了。还有个坑是，如果任务里C和A/B的关联不是特别明确，模型很容易在最后一步强行给结论，这时候可以加一个“如果C与A/B的差异无直接关联，请分别阐述并说明不确定性”，至少它能诚实地承认逻辑缺口。你现在用的工具返回结果是结构化数据还是纯文本？如果是纯文本，可能还得在子Prompt里强制它先提取出关键字段，不然中间步骤的“编造”其实是在压缩信息时发生的。

碰到过类似的情况，单靠“逐步思考”确实容易翻车，尤其当模型自己脑补出中间数据的时候。我个人感觉把大任务拆成几个独立子调用会稳很多，比如先单独检索A和B，再做对比，最后结合C，每一步都强制带上检索结果原文，这样它就没啥空间自己编了。至于硬性约束，我试过在system里写“如果找不到对应内容，就明确说不知道”，比单纯说“必须基于检索”管用，你可以试试看。

另外你提到的ReAct风格，我觉得别把工具调用和推理步骤全堆在system里，太长了反而容易让模型迷路，不如把当前步骤和已有结论动态拼进user prompt里，让它基于上下文来决策。不过想问下，你用的模型是API还是开源部署的？不同模型对这类约束的敏感度差别还挺大的。

我最近也在搞类似的Agent，感觉多步推理里“幻觉”八成出在状态管理上——模型一旦把中间结果记岔了，后面全崩。与其硬塞一个超长system prompt，不如把每个推理步骤做成独立工具调用，强制它把上一步输出作为下一步输入，这样至少数据链是清晰的。至于“必须基于检索结果”，我试过在prompt里加一句“如果找不到直接证据，就输出‘无依据’并终止”，比单纯说“不要编造”管用得多，你也可以试试。

拆成子Prompt单独调用更稳，每步强制带检索原文再推理，幻觉能少一半。硬性要求就写“没检索到就明说不知道”。

拆成子Prompt单独调用会更稳，每步强制带检索结果再推理，幻觉能少一大半。

硬性要求就写“若检索无依据，直接回答不知道”，比“必须基于”管用。

我之前也踩过这个坑，单靠“逐步思考”确实不稳定，后来改成把每一步的输入输出都明确写进prompt里，比如强制要求“先输出对比结果，再根据结果做下一步”，模型就没那么爱跳了。多步拆成子Prompt我觉得更可控，但每步都要把上下文带全，不然容易丢信息。至于硬性约束，我试过在system里加“如果检索结果里没有，就回答无法判断”，比单纯说“必须基于检索”管用很多，你可以试试。

硬拆子Prompt效果更稳，但得设计好中间结果的传递格式，不然容易丢上下文。