别教大模型认错：直接改写它的上下文记忆

当大模型在调用工具（Tool Call）时传错了参数，大多数工程师的直觉反应通常只有两种：

这两种做法看似合理，其实都埋了坑。

第一种做法，等于在模型的记忆里刻下了一次失败痕迹。上下文里多了一轮“出错—道歉—重试”的无意义对话，白白消耗 Token 不说，模型还经常在后续逻辑里陷入过敏式的自我怀疑。

第二种做法看似优雅，但模型的上下文里依然写着那条错误的初始请求。对于大模型来说，上下文就是它眼中的全部物理世界。它看到自己刚才传了个脏数据，系统却莫名其妙跑通了，这种逻辑不一致很快就会污染它接下来的推理。

面对既不像死板机器、又不像真正人类的大语言模型，其实存在第三种完全反常识的解法：发动“时间旅行”，直接篡改历史。

人类被篡改记忆会感到错乱，但大模型不会。

大模型没有连续的心智，也没有后台状态机。每一次推理，它都只是基于当前送入上下文的完整 Prompt 进行概率预测。

这意味着：只要你在收到模型错误的工具调用后，不把错误记入消息历史，而是把参数修正后的正确版本直接替换回去，再把工具执行结果拼回给模型——

模型完全不会意识到时间曾经回拨。在它的认知里，自己第一遍就精准拿捏了格式，调用毫无瑕疵，结果水到渠成。

最精彩的部分不是模型“没发现被改了记忆”，而是它在后续多轮交互中的行为变化。

在复杂的连续工具调用场景中（比如猜词游戏、多步数据库查询或复杂 API 编排），模型往往会参考前序步骤的格式和思维链：

干净的范例效应：模型在生成新步骤时，最强的前验参考就是自己刚才生成的上下文。如果前文是一次干净完美的工具调用，它在第二步、第三步延续高水准输出的概率会直线上升。
彻底消除幻觉级联：大模型有一种致命倾向——为自己之前的错误合理化。一旦上下文中出现过格式违规，模型潜意识里会认为“这个格式是被允许的”，后续步骤中反复踩坑。
省去防御性上下文消耗：不用再维护冗长的错误重试记录，整条调用链路清晰紧凑，直接帮上下文窗口减负。

要实现这种机制，关键在于解耦实际交互流与送入模型的历史消息数组（Message History）：

拦截调用：当模型的 tool_calls 返回时，第一道防线做严格的 Schema 校验。
静默修剪：如果发现模型参数格式有细微偏差（例如该传枚举值却传了同义词，或日期格式少了个横杠），先由后台代码完成语义兜底。
替换历史节点：重点来了——不要在末尾追加“调用失败，请重试”的消息，而是直接在消息数组中，将上一轮模型生成的脏 tool_calls 载荷原地替换为修正后的干净载荷。
回填结果触发下一轮：带上修正后的调用记录与成功的工具响应，请求下一轮推理。

这种技巧打破了传统的对话状态处理思维。别把大模型当成需要耐心教育的学生，非要让它在错误中吸取教训；在上下文驱动的世界里，直接给它一个完美的过去，它就能还你一个完美的结果。