如何解决 Function Calling 在多轮对话中频繁触发重复调用的问题

Function Calling 最大的痛点就是模型在多轮对话中容易陷入“死循环”：明明已经拿到了结果，但只要用户追问一句，它就习惯性地再次调用同一个函数，导致 Token 浪费且响应延迟。

我在实测 GPT-4o 和 Claude 3.5 Sonnet 时发现，两者的触发逻辑完全不同。GPT-4o 在上下文较长时，更容易因为之前的 Tool Call 记录而产生“路径依赖”，觉得这次还得调一次才稳妥；而 Claude 3.5 在处理复杂参数时更精准，但如果 System Prompt 约束不够，它在确认环节会反复调用。

要解决这个问题，不能只靠调 Temperature，得从上下文管理和 Prompt 策略上下手。

策略一：引入状态标记（State Tracking）
在将 Tool 的返回结果喂回给模型时，不要直接传原始数据，要在结果前加一个明确的状态标签。
例如，不要只传：

{"temperature": "25°C", "city": "Beijing"}

改为传：

[TOOL_RESULT_CACHED]: The current temperature in Beijing is 25°C. (Updated at 10:00 AM)

这样模型在检索上下文时，能通过 CACHED 这种强暗示意识到数据已存在，从而跳过调用。

策略二：在 System Prompt 中定义“调用阈值”
直接给模型下死命令，限制其重复行为。我测试了一组有效的约束词：

If the required information is already present in the conversation history, prioritize using the existing data over calling the tool again, unless the user explicitly requests a "refresh" or "update".

实测对比表现：
GPT-4o： 极其依赖 System Prompt。如果不加上述约束，在 5 轮对话后，重复调用率高达 40%；加上约束后，能有效识别历史记录，重复率降至 10% 左右。
Claude 3.5 Sonnet： 对上下文的理解力更强，即使不加约束，重复调用也较少，但它有个怪癖是喜欢在调用前进行冗长的自我分析，建议配合 Concise response 指令使用。
DeepSeek-V2.5： 在简单工具调用上很稳，但在多轮逻辑跳转时，偶尔会出现参数丢失导致重新调用的情况，稳定性略逊于前两者。

代码层面的拦截方案
如果不想依赖模型自觉，最稳妥的是在后端代码层加一个简单的缓存校验机制。

def tool_wrapper(tool_name, arguments):
    # 伪代码：校验最近 3 轮对话是否调用过相同函数且参数一致
    if conversation_history.has_recent_call(tool_name, arguments):
        return "Error: This information was already retrieved. Please use the existing context."
    return execute_real_tool(tool_name, arguments)

这种硬拦截能强行中断模型的死循环，逼它去阅读上下文。