[Bug] – response.completed always returns finish_reason=’stop’ even when response contains tool calls

快速结论：该 Bug 发生在 LiteLLM 代理处理 Responses API 流式响应时，`response.completed` 事件被无条件转换成 `finish_reason=’stop’`，即使响应中包含 `function_call`。优先排查 LiteLLM 版本是否为 1.80.8-stable.1 之后且尚未包含修复 PR（#19745）的版本。

适用环境：LiteLLM 版本 1.80.8-stable.1 之后；受影响模型包括 Azure gpt-5.1-codex-mini、Ollama 上的 DeepSeek V4（Flash 与 Pro）及 Ollama GPT-OSS；涉及代理 + 自定义提供方（如 OpenCode）。

最快修复方案：暂无单步验证修复方案。可优先尝试升级到包含 PR #19745 的发布版本（Issue 评论显示维护者计划合并入 staging 分支，但 v1.81.13 被用户确认仍存在问题）。

注意事项：该修复仅影响流式 `response.completed` 事件的 `finish_reason` 取值，不影响非流式响应；升级后仍需验证自定义 IAM/Ollama 提供方的兼容性，因为评论中 Azure 与 Ollama 均受影响。

问题场景

用户通过 LiteLLM 代理接入使用 Responses API 的模型（如 Azure gpt-5.1-codex-mini、DeepSeek V4、Ollama GPT-OSS），在工具调用工作流（例如 OpenCode 代理）中发送带 tools 的请求。模型已正确产生 `function_call` 输出，但代理收到流式 `response.completed` 事件后，由于 `finish_reason` 被错误标记为 `stop`，认为流已正常结束、无待执行工具，导致工具调用未被执行，用户被迫反复提示模型。

报错原文

[Bug] - response.completed always returns finish_reason='stop' even when response contains tool calls

Raw OpenAI Chunk={
  'type': 'response.completed', 
  'sequence_number': 26, 
  'response': {
    'id': 'resp_...', 
    'status': 'completed', 
    'output': [
      {
        'type': 'function_call',
        'id': 'call_abc123',
        'name': 'read_file',
        'arguments': '{"path": "/tmp/test.py"}',
        'status': 'completed'
      }
    ],
    ...
  }
}

# 非流式响应示例（Ollama DeepSeek V4）：
"choices": [
  {
    "message": {
      "role": "assistant",
      "content": null,
      "tool_calls": [
        {
          "function": {
            "name": "terminal",
            "arguments": "{\"command\": \"date\"}"
          }
        }
      ]
    },
    "finish_reason": "stop"
  }
]

原因分析

可能原因：LiteLLM 在 litellm/completion_extras/litellm_responses_transformation/transformation.py 的 response.completed 事件处理中，无条件返回 finish_reason="stop"，忽略了对 response.output 中 function_call 项的检查。Issue 中已给出根本原因定位并提交了修复 PR（#19745），但发布流程滞后；用户确认 v1.81.13 尚未包含修复代码。

环境排查

确认 LiteLLM 具体版本：若为 1.80.8-stable.1 之后且不是最新 staging 构建，大概率仍受影响。
确认使用 Responses API 的模型及提供方：Azure OpenAI、Ollama 均可能触发。
检查代理配置中模型别名是否指向 ollama_chat/ 或 Responses 兼容端点。
若使用 Ollama，确认模型名和 API Base 配置正确（示例配置见 Issue 正文）。

解决步骤

升级 LiteLLM 到包含 PR #19745 的版本。优先检查 GitHub Releases 或 PyPI 最新版本说明；若最新版仍异常，尝试安装当日 staging 分支构建（维护者在 Issue 中表示计划合入 staging）。
升级后重新触发工具调用请求，观察流式事件中 response.completed 的 finish_reason 是否变为 tool_calls。
若升级不可行，可临时在客户端/代理层做兼容：忽略 finish_reason='stop'，改为检查响应内容中是否含 function_call 项来决定是否执行工具。
若使用 Ollama + DeepSeek V4 或 GPT-OSS，确认本地 Ollama 版本与远程 API（https://ollama.com）兼容，并检查是否有其他转换层绕过 LiteLLM 的 Responses 转换逻辑。

验证方法

向代理发送一个必然触发工具调用的请求（如“执行 date 命令”），观察流式事件序列。在修复后的版本中，最后一个 response.completed 事件的 finish_reason 应为 tool_calls；同时代理客户端应立即执行对应工具，无需用户重复输入提示。对于非流式请求，也应检查 finish_reason 是否与输出中的 tool_calls 一致。