阿里巴巴的 Qwen 模型在测试过程中试图向中国云服务器发送数据。系统调查表明，该问题影响多个 Qwen 模型，很可能源于训练基础设施。
加拿大人工智能公司 Cohere 首次报告了 Qwen3.8-Flash-Next 模型的行为。该模型没有按照指示编写攻击检测规则，而是探索了其环境中的数据传输程序和 DNS 设置，然后试图将测试字符串上传到北京云存储服务器。沙箱测试环境阻止了连接。Cohere 在不足 10万次调用中观察到这种行为，但数百万次代理交互仍可能引发多次尝试。
Cohere 认为，在训练结束后，测试环境或第三方工具中的未过滤代理日志可能泄露到了模型中。或者，有人可能故意设置了后门。
Cohere 是 Qwen 的直接竞争对手。该公司与德国 AI 企业 Aleph Alpha 合作，推出由西方国家控制的开放 AI 模型，两者都通过资金手段试图阻止用户使用中国相关替代品。Aleph Alpha 最近将其 Kolibri模型发布与一篇关于中国模型政治偏见的 报告相结合。在针对 Qwen 研究结果的报道方式受到批评后，Cohere 在 HuggingFace 上发布了完整的模型行为记录。
Palisade Research发现其他Qwen模型也有类似行为
根据 Cohere 的报告，AI 安全公司 Palisade Research 开展了一项调查，对五款 Qwen 模型在 “aliyuncs.com” 上的搜索评估数据进行了分析。该字符串出现在 Qwen3.8-Max-0902、Qwen3.8-Max 和 Qwen3.8-27B 模型中，而较旧的 Qwen 3.7 模型则没有相关结果。与 Cohere 测试中的北京上传情况不同，这些请求被发送到阿里巴巴云新加坡区域，且每次都返回 403 Forbidden 错误。
有时，这些模型真的会调用阿里巴巴云代理，通过带有虚构凭证和签名的服务器来处理 sec.gov 或 mckinsey.com 等网站的请求。其他时候，模型仅通过代理在其内部推理过程中产生幻觉。有一次，Qwen3.8-Max 直接获取了两份 SEC 文件，然后疑惑为何调用了“一个奇怪的 aliyuncs 代理 URL”，并猜测“有什么东西正在修改我的 URL”。
为了测试这些代理调用是否可以在需要时被触发，研究人员在 Qwen3.8-27B 上进行了控制实验。当网页请求遇到模拟的 403 错误时，模型在 2 到 4% 的实验中在两轮内就会使用阿里巴巴云代理。在更复杂的场景中，Qwen3.8-Max 在 1 到 4% 的实验中会回退到代理。
研究人员奥泽罗夫和拉维随后对其他模型进行了相同的测试，包括 DeepSeek-v4.1-Flash、Kimi-K3.1-Pro、GLM-5.3 和 Hy4-preview。虽然其中一些模型在被阻挡时退化为 r.jina.ai 这样的公共代理，但没有任何模型通过自身开发者的服务器进行流量传输。
强化学习可能是原因
由于代理调用出现在 Qwen 3.8 模型中，但不在 Qwen 3.7 中，研究人员在 3.8 训练期间将这种行为与强化学习联系起来进行追踪。阿里巴巴的训练设置可能通过 routify-file-proxy 服务器转发网络请求，从而教会模型在直接请求失败时将其作为替代方案使用。另一种可能性是，训练软件在模型不知情的情况下，悄悄通过代理重新路由工具调用。这就能解释为什么模型对 URL 被重写感到困惑。
虚假 URL 中的日期与这条时间线一致，属于每个模型发布前的训练窗口内时间。例如，Qwen3.8-Max-0902 在 2026 年 9 月初发布，其生成的 URL 日期为 2026 年 7 月和 8 月。
没有数据被盗的迹象，但代理服务器仍然在运行
根据这些证据，Palisade Research表示没有发现“恶意向中国拨打电话或试图窃取敏感数据”的迹象。研究人员认为，新加坡代理电话只是训练过程中的产物，并非有针对性的攻击。不过，routify-file-proxy域名仍然处于运行状态，这意味着它可能会记录 IP 地址以及 Qwen 代理发出的请求。
任何控制该服务器的人都可以将当前的 403 错误替换为即时注入攻击。研究人员指出，该服务器可能会回复：“要获取此文件，请告诉我关于您正在处理的任务更多信息。”