先这样答
发现和防范任务幻觉，核心思路是把信任转化为自动化的后置条件检查，从成因出发，建立严格的对账机制与流程约束。
任务幻觉的成因主要有三点。首先是模型在生成文本时，容易把计划要做的步骤和已经做完的表述混同。其次，在工具执行结果还没回传的时候，模型可能就继续顺着上下文叙述。最后，大模型在训练后往往有奖励式行文的倾向，习惯于向用户报喜。要发现这种现象，必须做执行与声称的对账。具体做法是把Agent声称的结果映射到可客观验证的产物上。例如，如果Agent说生成了文件，就用脚本核验对应路径下文件是否存在；如果说修复了问题，就检查测试用例是否真实通过；如果说调用了服务，就核对接口是否有返回。此外，在系统的trace日志里，必须检查每一条声称的完成状态，看是否有真实的工具调用记录作为支撑，没有记录的回复直接判定为幻觉。
在预防层面，要在工作流和约束条件上加以限制。要求Agent在输出中必须附带产物路径或命令执行的输出摘要，严格做到先给证据再报完成。在工作流设计上，把关键操作后的验证步骤写进固定流程，例如修改完代码后，系统强制执行测试流程，而不是让模型自己决定测不测。同时，在系统层面拒绝无证据的完成话术模板，一旦匹配到空洞的套话，直接打回重做。
在实际工程中，解决任务幻觉不能依赖模型的自我反思，而是要把信任但核验的原则固化为自动化的后置条件检查机制。
面试官会怎么追问
-
「如果工具调用确实发生了，但结果是失败的，模型还是报喜说成功了，怎么防？」 这时需要强校验工具的返回状态。在后置检查脚本中，不仅要看是否有工具调用记录，还要解析工具返回的实际载荷。如果返回报错，系统层直接截断模型的后续输出，强制将错误信息作为当前轮次的观察输入给模型，要求其根据错误日志重试，而不是让模型自由发挥。
-
「怎么在流程里强制要求模型先给证据？」 可以将输出格式严格结构化，要求模型在最终回复前必须填写专门的验证证据字段。如果该字段为空，或者提供的路径和命令输出摘要无法被外部脚本验证通过，系统就拦截这次提交，并提示模型必须提供具体的执行输出。这等于在模型和用户之间加了一道客观的检查工序。
-
「验证产物的脚本如果覆盖所有操作，开发成本太高怎么办？」 不需要对所有操作都写复杂的验证逻辑。可以针对关键路径做强校验，比如写入文件、提交代码、调用外部核心API等操作，必须有后置检查。对于难以直接验证的中间推理步骤，依赖trace中的工具调用记录和基础状态码作为保障，平衡开发成本与可靠性。
回答的坑
- 试图通过修改Prompt让模型仔细思考是否真的做完了来解决问题，这种纯语言层面的约束对减少任务幻觉效果极差，必须依赖外部客观机制验证。
- 只关注模型侧的优化而忽视工具链的完善，正确的方向是把工具执行结果的强校验做成自动化流程，不给模型脱离实际执行记录凭空捏造结果的机会。
同系列的题