Moonshot K3: all tool calls fail with non-Responses compatibility-transport error

快速结论：该报错通常出现在 Open Interpreter 0.0.40 中，当使用非 Responses 传输协议的提供商（如 moonshotai、opencode-go）发起会话时，所有需要工具调用的请求都会在工具执行前失败。优先排查方式是确认当前版本是否为 0.0.40，若是则直接升级到 0.0.41 或回退到 0.0.39。

适用环境：Open Interpreter 0.0.40（macOS Apple Silicon standalone 安装及 Windows 11 x86_64 源码构建均有报告）；提供商包括 moonshotai / kimi-k3（wire_api = “chat”）以及 opencode-go / deepseek-v4-flash（wire_api = “chat”）；Harness 类型包括 kimi-code、native、minimal 及自定义 persona-external harness。

最快修复方案：升级到 Open Interpreter 0.0.41（已通过 #1891 恢复 Chat Completions 兼容传输层）。如暂时无法升级，可回退到 0.0.39 版本以恢复正常功能。此修复方案已在 Issue 讨论中明确验证。

注意事项：该问题影响所有非 Responses 传输协议的提供商，不仅限于 Moonshot。0.0.40 中即使不发起工具调用的简单请求（如仅发送 “hello”）也会触发该错误。直接恢复 0.0.39 的部分代码可能无法简单实现，因为相关内部字段已被移除。

问题场景

用户使用 Open Interpreter 0.0.40 连接 Moonshot K3（kimi-k3 模型，wire_api = “chat”）时，任何需要工具调用的提示都会立即失败。复现步骤包括：启动新会话后发送需要 shell 工具的提示（如执行 pwd），会话立即返回错误；请求浏览器 QA 工作流程同样失败，且不会执行任何命令或浏览器操作。

进一步测试表明，该问题不限于 Moonshot——使用 opencode-go 提供商（wire_api = “chat”）与 deepseek-v4-flash 模型、不同 harness 配置（native、minimal）甚至不发起工具调用仅发送 “hello” 同样会触发相同错误。

报错原文

unsupported operation: non-Responses wire APIs require the compatibility transport
ERROR: unsupported operation: non-Responses wire APIs require the compatibility transport

原因分析

该错误的根本原因是 0.0.40 版本同步了官方 Codex rust-v0.148.0 代码（commit f00e2e0dc），对 codex-rs/core/src/client.rs 进行了大规模重写（+262 / -1390 行）。重写后，ModelClientSession::stream() 方法仅处理 WireApi::Responses，对于 Chat 或 Messages 类型的 Wire API 直接返回该错误。

在 0.0.39 版本中，stream() 方法通过 stream_transport_route() 进行路由分发，支持 ChatCompletionsCompat、ChatHarness、MessagesHarness 等多种传输路径。但 0.0.40 重写后移除了这些分支，同时 core/src/harness/routing.rs 中的 resolve_stream_transport_route 和 core/src/harness/request.rs 中的 build_chat_harness_request 等 harness 机制虽然仍存在于代码树中且可通过编译，但已没有任何生产环境调用方。

由于该限制基于 WireApi 而非特定提供商或 harness，因此所有目录中的非 Responses 提供商都会受到影响，而非仅限 Moonshot。

环境排查

确认 Open Interpreter 版本：运行 interpreter --version 检查是否为 0.0.40（可通过 git log 确认 commit 是否为 5b07159c4 之后的版本）
确认提供商配置：检查 model_provider 设置及对应的 wire_api 类型（应为 “chat”）
确认模型名称及 harness 推断结果（如 kimi-code、native、minimal）
确认该问题在新会话中可稳定复现（排除环境状态干扰）
如从源码构建，可执行 cargo check --workspace 确认编译通过——该问题不会在编译阶段暴露，仅在运行时出现
对比测试：同一配置在 0.0.39 版本下是否正常工作

解决步骤

首选方案：升级到 0.0.41——该版本已通过 PR #1891 恢复了 Chat Completions 兼容传输层，稳定版可在 Open Interpreter 发布页面获取。
备选方案：回退到 0.0.39——如果暂时无法升级，降级到 0.0.39 可恢复正常功能。多个用户在 Issue 讨论中确认此方法有效。
如仍需在 0.0.40 上工作：可优先尝试检查是否有可用的 compatibility transport 配置项或环境变量；但根据 Issue 讨论，0.0.40 中未发现任何与此相关的配置开关（在 features/src/lib.rs 的 114 个功能项中均无 transport/compat/wire/harness 相关条目）。
高级用户（源码修改）：可在 codex-rs/core/src/client.rs 的 ModelClientSession::stream() 方法中添加对 WireApi::Chat 和 WireApi::Messages 的处理分支，调用仍存在于代码树中的 stream_chat_harness_api() 和 stream_messages_harness_api() 函数；但需要注意 0.0.39 中的 stream_transport_route() 读取了 self.state.harness 字段，而该字段在 0.0.40 中已被移除（ModelClientState 中原有的 harness: Harness 和 harness_guidance: bool 均已删除），因此不能简单还原旧的路由逻辑。

验证方法

升级或回退后，重新启动一个全新会话，使用与原 Issue 相同的提示测试：Run pwd using the shell and report the result. Do not modify files.，确认工具能够正常执行。同时建议用简单提示（如发送 “hello”）验证基础的非工具调用是否正常，因为 0.0.40 中非工具请求同样会触发该错误。若修复生效，所有此前失败的提供商（moonshotai、opencode-go 等）都应恢复正常工具调用。