Claude Code 接入 Qwen 实战

AI 编程工具正在从“辅助写几行代码”进入“参与完整工程流程”的阶段。过去开发者更多是在 ChatGPT、Claude、Gemini 等对话窗口里复制代码片段，现在越来越多团队开始使用 Claude Code、Qwen Code、Cursor、Continue 等终端或 IDE 型工具，让模型直接读取项目、理解目录结构、生成补丁、执行命令、补充测试甚至参与代码审查。

在这个背景下，一个非常现实的问题出现了：很多开发者已经习惯 Claude Code 的项目级交互体验，但企业又希望接入 Qwen3-Coder、Qwen-Plus、Qwen-Max 等国产模型，降低调用成本，提升国内环境下的可用性，并让团队拥有更统一的模型管理能力。因此，“Claude Code 如何接入 Qwen Code”本质上不是一个简单的工具安装问题，而是一个国产编程模型统一调用架构问题。

一、先澄清：不是把 Qwen Code 装进 Claude Code

很多人会把“Claude Code 接入 Qwen Code”理解成在 Claude Code 内部直接运行 Qwen Code，这其实并不准确。Claude Code 和 Qwen Code 都是面向开发者的 AI 编程 Agent，它们本身都包含终端交互、上下文管理、文件读取、代码修改和命令执行等能力。二者更像是两套上层工具，而不是“一个工具调用另一个工具”的插件关系。

更准确的理解应该是：在上层，开发者可以继续使用 Claude Code 或 Qwen Code；在下层，通过统一的模型调用入口，把 Claude、Qwen、DeepSeek、GLM 等模型集中管理。这样一来，工具层和模型层就可以解耦。开发者不必每次切换模型都重新配置工具，企业也不需要让每个成员单独维护 API Key、Base URL 和模型名称。

从工程角度看，Claude Code 接入 Qwen 模型通常有两条路径：第一条是让 Claude Code 通过 Anthropic 兼容网关转发请求，后端再调用 Qwen 模型；第二条是直接使用 Qwen Code，通过 OpenAI 兼容接口调用 Qwen3-Coder。这两条路径适合不同团队，不能混为一谈。

二、为什么要做国产编程模型统一调用？

如果只是个人尝鲜，直接安装一个工具、填一个 API Key 就够了。但企业团队真正落地 AI 编程时，会遇到更多工程问题。

首先是密钥分散。每个开发者本地都配置不同平台的 Key，一旦有人离职、密钥泄露或权限变更，很难统一回收和审计。其次是模型切换混乱。有人用 Claude，有人用 Qwen，有人用 DeepSeek，同一个项目中的 AI 生成代码风格、错误处理方式、上下文理解能力都会不一致。第三是成本不可控。复杂重构、简单注释、单测生成、接口文档编写本来应该使用不同成本层级的模型，但如果没有统一入口，很容易出现小任务调用高价模型的情况。第四是协议不一致。Claude Code 更偏 Anthropic 协议，Qwen 模型通常通过 OpenAI 兼容接口调用，如果没有中间适配层，直接替换地址并不一定能正常工作。

所以，国产编程模型统一调用的核心价值，不是“让所有模型看起来一样”，而是让开发者在工具层保持顺手，让企业在底层拥有统一配置、统一鉴权、统一监控和统一成本管理能力。

三、方案一：Claude Code 通过网关调用 Qwen 模型

如果团队已经深度使用 Claude Code，最自然的方式是保留 Claude Code 的使用习惯，只改变底层请求入口。Claude Code 支持通过环境变量控制模型、鉴权和请求路由，因此可以将请求发送到一个 Anthropic-compatible 的内部网关。

示例配置如下：

export ANTHROPIC_BASE_URL="https://your-gateway.example.com/anthropic/v1"
export ANTHROPIC_API_KEY="your-gateway-key"
export ANTHROPIC_MODEL="code-agent-cn"

claude

这里的关键不是 ANTHROPIC_BASE_URL 这个变量本身，而是它背后的网关能力。如果后端只是一个普通 OpenAI 兼容接口，直接把地址改成 Qwen 的 OpenAI-compatible endpoint，往往会因为请求格式不匹配而失败。Claude Code 发出的消息结构、工具调用格式、流式响应格式，与 OpenAI Chat Completions 并不完全一致。因此，中间层至少需要完成三件事：接收 Claude Code 的 Anthropic 格式请求，转换为 Qwen 模型可识别的 OpenAI 兼容格式，再把 Qwen 的输出重新封装为 Claude Code 能理解的响应。

在企业内部，建议不要让开发者直接写死真实模型名，而是使用模型别名。例如 code-agent-cn 可以在网关侧映射到 qwen3-coder 或其他国产编程模型。以后模型升级时，只需要调整网关映射关系，不需要让所有开发者修改本地配置。

如果团队希望统一分发配置，也可以将环境变量写入 Claude Code 的 settings 配置中：

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://your-gateway.example.com/anthropic/v1",
    "ANTHROPIC_API_KEY": "your-gateway-key",
    "ANTHROPIC_MODEL": "code-agent-cn"
  }
}

需要注意的是，项目级配置文件可以保存通用参数，但不要把真实密钥提交到 Git 仓库。更安全的方式是通过本地环境变量、密钥管理系统或 CI Secret 注入。

四、方案二：直接使用 Qwen Code 调用 Qwen3-Coder

如果团队的目标是更原生地使用国产编程模型，那么直接使用 Qwen Code 会更简单。Qwen Code 本身就是围绕 Qwen 编程模型设计的终端 Agent，适合做项目理解、代码生成、命令执行、单测补全和代码解释等任务。

典型配置文件位于：

~/.qwen/settings.json

可以采用类似下面的配置方式：

{
  "env": {
    "BAILIAN_API_KEY": "YOUR_API_KEY"
  },
  "modelProviders": {
    "openai": [
      {
        "id": "qwen3-coder",
        "name": "Qwen3 Coder",
        "baseUrl": "https://dashscope.aliyuncs.com/compatible-mode/v1",
        "envKey": "BAILIAN_API_KEY"
      }
    ]
  },
  "security": {
    "auth": {
      "selectedType": "openai"
    }
  },
  "model": {
    "name": "qwen3-coder"
  }
}

配置完成后，在项目根目录执行：

qwen

进入交互界面后，可以先让模型分析项目结构，例如：

/init

然后再输入具体任务：

帮我分析这个项目的登录鉴权流程，并指出可能存在的安全风险。

对于批处理或自动化场景，也可以使用命令行方式：

qwen -p "检查 src 目录下的异常处理逻辑，并给出可落地的重构建议"

这种方式的优势是链路更短，协议适配更少，适合希望直接验证 Qwen 编程模型能力的团队。但如果团队已经形成 Claude Code 工作流，例如使用固定的 Claude.md、权限策略、项目命令规范和代码审查流程，那么直接切换到 Qwen Code 可能需要一定迁移成本。

五、统一调用层应该怎么设计？

无论选择 Claude Code 还是 Qwen Code，真正决定企业可用性的不是某一个客户端，而是中间的统一调用层。一个成熟的 AI 编程调用架构，至少应该包含模型别名、协议适配、密钥管理、调用监控和成本控制等能力。例如在多模型 API 聚合场景中，团队可以通过 koalaapi 这类统一接入平台，把不同模型的调用地址、鉴权方式和模型名称集中管理，避免每个开发者在本地反复维护多套 API 配置。这样上层工具可以继续使用 Claude Code、Qwen Code 或其他 AI 编程终端，下层模型则通过统一入口完成切换和调度。

模型别名层解决的是“开发者不直接感知具体模型”的问题。例如团队可以定义 code-fast、code-review、code-deep、doc-gen 等任务型模型，而不是让开发者记住一堆模型版本号。协议适配层解决的是 Anthropic、OpenAI-compatible、Google GenAI 等接口差异。密钥管理层解决的是权限回收、团队共享和安全审计问题。调用监控层用于记录 token 消耗、失败率、延迟和模型使用分布。成本控制层则可以根据任务类型选择不同模型，避免所有任务都调用最高成本模型。

这套架构的重点不是复杂，而是标准化。AI 编程工具越多，模型越多，越需要把分散配置收敛到一个统一入口。

六、真实开发场景中的模型分工

在实际工程中，不同任务对模型能力的要求并不一样。简单任务包括生成工具函数、补充注释、解释报错、生成 README、补单测模板等，这类任务通常更适合使用成本更低、响应更快的国产编程模型。中等复杂任务包括接口迁移、局部模块重构、SQL 优化、前端组件改造等，可以使用 Qwen Code 或通过 Claude Code 网关调用 Qwen 模型完成。高复杂任务包括跨模块架构调整、历史代码债务梳理、复杂系统设计和多服务联调计划，这类任务更适合先用强推理模型做方案设计，再交给编程模型执行局部改造。

因此，统一调用实践的核心不是“Qwen 替代 Claude”，也不是“Claude 包住 Qwen”，而是建立模型分工。Claude Code 的优势在成熟的 Agent 工作流，Qwen Code 的优势在国产模型生态和本地化调用便利性。真正高效的团队，会把不同工具和模型放到合适的位置，而不是用单一工具解决所有问题。

七、接入时最容易踩的坑

第一个坑是协议不匹配。OpenAI-compatible 不等于 Anthropic-compatible，Claude Code 需要的网关必须能理解 Anthropic 请求格式，否则只改 Base URL 很可能无法正常工作。

第二个坑是工具调用不稳定。AI 编程 Agent 不只是聊天，它还涉及文件读取、代码修改、命令执行和上下文压缩。如果后端模型对工具调用格式支持不稳定，就可能出现补丁生成失败、命令调用异常或上下文遗漏。

第三个坑是上下文长度配置不一致。客户端、网关和模型侧如果对最大上下文窗口的理解不同，长项目分析时就可能提前截断，导致模型漏读关键文件。

第四个坑是权限过宽。AI 编程工具具备执行 shell 命令的能力，企业必须限制危险命令、敏感目录、生产密钥和线上配置文件读取权限。

第五个坑是只看演示效果，不看长期维护。真正有价值的 AI 编程，不是一次生成代码看起来能跑，而是代码能否通过测试、能否被团队 review、能否遵守项目规范、能否在几周后继续维护。

结语

Claude Code 如何接入 Qwen Code，表面上是一个工具配置问题，实际上是 AI 编程工程化的问题。个人开发者可以直接使用 Qwen Code 调用 Qwen3-Coder，快速体验国产编程模型的项目级能力；已经习惯 Claude Code 的团队，可以通过 Anthropic-compatible 网关接入 Qwen 模型，在保留原有交互体验的同时降低模型切换成本；企业级研发团队则更适合建设统一调用层，把模型协议、密钥管理、成本统计、权限控制和效果评测全部纳入同一套体系。

未来 AI 编程不会只有一个工具，也不会只有一个模型。更现实的趋势是：上层工具多样化，下层模型统一化，团队通过标准化调用入口管理不同模型能力。谁能更早完成这套工程化改造，谁就能更早把 AI 编程从个人效率工具，变成真正可复制、可管理、可度量的团队生产力基础设施。