Qwen3.7 模型通过 OpenCode Go 与官方网页使用时为什么表现不同？

Qwen3.7 通过 OpenCode Go 与官方网页表现不同，不足以证明 OpenCode Go 修改了模型权重。更常见的原因是两条链路使用了不同的系统指令、代理角色、接口协议、采样参数、会话历史或服务配置。即使 OpenWebUI 页面中没有手动填写 system prompt，客户端、代理模板和兼容层仍可能在最终请求中加入指令。

先理解“同一个模型”缺少哪些条件

模型名称相同，只能说明请求选择了同一产品系列。一次输出还取决于具体模型 ID、服务商部署版本、消息角色、工具定义、上下文、温度、最大输出长度和推理开关。任何一项不同，都可能让身份回答、语气和任务策略发生变化。

OpenCode Go 官方将服务定位为面向 OpenCode 及相似编码智能体的模型入口，并要求客户端发送典型的编码 Agent 流量和稳定的会话标识。Qwen3.7 Max 与 Plus 在该服务中通过 Anthropic Messages 兼容端点提供。这种接入方式与官方聊天网页不是同一个产品界面，也不能默认拥有完全相同的提示模板和运行参数。

为什么会回答成 Kiro 或 Claude

模型说“我是 Kiro”或“我是 Claude”，首先说明输入上下文中可能存在相关身份线索，但不能仅凭一句自我介绍确定线索来自哪一层。常见来源包括 OpenWebUI 的模型模板、工作区规则、选中的 Agent、导入的预设、此前消息、代哩服务務器注入，以及把一种消息协议转换为另一种协议时添加的兼容提示。

“设置页没有 system prompt”只排除了一个可见输入框。很多客户端会分别维护全局提示、模型提示、用户提示、知识库提示和工具提示；服务端也可能根据接口类型加入运行指令。模型还可能因为训练数据中的产品身份模式而生成错误自述。因此，身份问答适合发现差异，却不适合单独证明模型经过定制。

按请求边界定位差异

1. 固定模型 ID。记录 OpenCode Go 请求使用的完整 ID，并在官方网页确认实际选择的是 Max、Plus 还是其他变体。不要只写“Qwen3.7”。
2. 创建全新会话。关闭记忆、知识库、工具和自定义 Agent，避免旧消息与插件说明进入上下文。
3. 抓取最终请求。在 OpenWebUI 后端日志或受控代理中检查实际发送的消息数组、角色顺序、工具定义和生成参数。不要只查看前端配置。
4. 直接调用端点。使用同一 API Key、模型 ID和用户消息发起最小请求，再与 OpenWebUI 的结果比较。若直接调用正常而界面异常，差异多半位于客户端配置或适配层。
5. 逐项加入配置。依次恢复系统指令、工具、历史和采样参数，每次只改变一个变量，直到身份或语气发生变化。

最小对照应记录什么

建议保存两组完整请求与响应，而不是只截取回答文本。至少记录时间、模型 ID、端点类型、消息数组、工具列表、温度、最大输出长度、推理设置、客户端版本、会话标识和响应中的服务元数据。对于随机采样模型，同一条件还应重复多次，以区分稳定配置差异与偶然输出。

测试 A：OpenWebUI 全新会话，关闭工具和知识库
测试 B：直接调用 OpenCode Go，同一模型、同一用户消息
测试 C：在 B 中加入 A 抓取到的完整消息与参数

判断：
A 与 B 不同，B 与 C 相同 -> 差异来自客户端请求
A 与 B 同条件仍稳定不同 -> 再核对路由、部署版本和服务元数据

不要用身份问题代替能力评测

“你叫什么名字”主要测试模型如何解释当前身份指令，不能代表代码生成、工具调用或长上下文能力。若真正关心 OpenCode Go 是否影响质量，应准备一组固定任务，包含代码修改、测试执行、错误修复和结果验收，并在两条链路使用相同上下文与评分标准。

如果差异只出现在自我介绍，而代码任务的通过率、工具调用和输出结构一致，通常没有必要推断模型能力被削弱。反之，如果固定请求后仍出现稳定的功能差异，才有理由把模型快照、服务商配置或协议适配列为进一步调查对象。

结论

OpenCode Go 与官方网页是不同的推理链路，输出不同是可预期现象，但现有证据不能证明模型权重被修改。最可靠的做法是抓取最终请求，固定模型与参数，通过直接 API 和客户端做单变量对照。只有排除隐藏指令、会话历史、协议转换和采样随机性后，才能继续判断差异是否来自服务端部署。