AI 编程 Agent 与自定义 API Endpoint：Cursor vs Claude Code vs Devin Desktop——运维者到底能控制什么

2026 年中，主流编程 Agent 都宣称支持"自带 API Key"。但当你真正试图把所有编程流量收归一个网关——统一密钥轮换、模型治理、花费上限和审计链路——差异就暴露出来了。我们测试了六款工具的自定义端点配置，记录下运维者真正能控制的部分。

来源：Cursor 论坛——自定义 OpenAI 兼容 API，检索于 2026-07-30；Claude Code——LLM Gateway 文档，检索于 2026-07-30；Devin Desktop——AI Models，检索于 2026-07-30；Zed——Use API Access，检索于 2026-07-30；Codex CLI 配置指南 (ofox.ai)，检索于 2026-07-30；GitHub Copilot BYOK——agentgateway.dev，检索于 2026-07-30；Cursor Sub-Agent 模型 Bug 报告，检索于 2026-07-30；Devin Desktop FAQ——Windsurf 更名，检索于 2026-07-30。

OpenAI 兼容指供应商提供一个 chat-completions 接口，其请求与响应结构与 OpenAI API 契约足够接近——只需替换三个值（API key、base URL、模型名），原来的 OpenAI SDK 调用即可直接工作。最小实践面是POST /v1/chat/completions 带 messages、model， 并返回 OpenAI 形式的流式响应。

速览——运维者控制力对比

Cursor：Base URL 可覆盖，Sub-Agent 却丢了

Cursor 的自定义 API 端点配置在 Settings → Models → OpenAI API Key + Override OpenAI Base URL 中。填入网关 URL 和 API Key，Cursor 的主 agent 就会走你的网关。

问题在于：Cursor 的 sub-agent 运行器完全忽略自定义 base URL。当 Cursor 启动后台 agent 处理多步骤任务时，这些 sub-agent 会回退到 Cursor 的默认路由。截至 2026 年 7 月，这是一个已知且被积极上报的 bug。如果你的治理模型要求所有 LLM 流量必须经过网关，Cursor 目前无法保证这一点。

你能配置的：

• Override OpenAI Base URL——网关端点（例如 https://gateway.yourcompany.com/v1）
• OpenAI API Key——网关验证用的 key
• 模型下拉菜单中的自定义模型名称
• HTTP/1.1 兼容模式（部分网关需要——在 Settings → Network → HTTP Compatibility Mode 中设置）

你不能配置的：

• Sub-agent 路由——始终使用 Cursor 的内部端点
• 按模型路由规则——所有自定义模型共用一个 base URL
• 密钥轮换策略——只能在设置 UI 中手动更新
• 请求级审计 header——不支持自定义 header 注入

# Cursor 配置（设置 UI）
# Override OpenAI Base URL: https://your-gateway.example.com/v1
# OpenAI API Key: sk-your-gateway-key
# HTTP Compatibility Mode: HTTP/1.1（如果网关需要）

Claude Code：天生支持网关

Claude Code 的设计思路不同——它从一开始就考虑了网关路由。ANTHROPIC_BASE_URL 环境变量会重定向所有 API 调用，包括 sub-agent 和后台 agent 的调用，全部走你指定的端点。

你能配置的：

• ANTHROPIC_BASE_URL——完整的网关 URL（例如 https://gateway.yourcompany.com）
• ANTHROPIC_API_KEY——网关 key
• 通过 Claude Enterprise 的组织级设置（花费限制、SSO、审计）
• 权限模型——沙箱、允许的工具、网络限制

你不能配置的：

• 模型系列——Claude Code 只使用 Anthropic Messages API，你的网关必须支持该协议
• 按请求的模型覆盖——Claude Code 自行选择模型层级（企业管理员可以限制层级）

# Claude Code 网关配置
export ANTHROPIC_BASE_URL="https://your-gateway.example.com"
export ANTHROPIC_API_KEY="sk-your-gateway-key"

# Claude Code 的所有流量——主 agent、sub-agent、后台任务——
# 现在全部走你的网关，没有例外。
claude code

Claude Code 的企业版增加了组织级治理：SSO 强制、API Key 作用域、花费控制和审计日志集成。结合网关环境变量，这是我们测试中治理能力最强的编程 Agent。

Devin Desktop（原 Windsurf）：托管路由，无自定义端点

Windsurf 于 2026 年 6 月 2 日更名为 Devin Desktop，Cognition AI 统一了产品线。模型接入方式发生了重大变化：Devin Desktop 使用托管模型路由器自动选择模型，定价以 credit 而非直接 API 费用表示。

你从 Devin 的目录中选择模型（Claude Sonnet 4、Claude Opus 4.5、GPT-4.1、GPT-5-Codex、SWE-1.7 等），Devin 负责路由、计费和基础设施。没有 base_url 覆盖，没有自定义端点配置，也没有办法接入你自己的网关。

你能配置的：

• Devin 目录内的模型选择
• 按团队成员分配 credit
• SOC 2 合规的工作区隔离
• 基于角色的访问控制

你不能配置的：

• 自定义 API 端点——所有流量走 Devin 的基础设施
• 直接使用 provider API Key——Devin 中间代理
• 网关集成——不支持
• 按请求的路由规则

这是最有主见的方案：Devin Desktop 优先考虑简洁性和默认安全性，而非运维者的路由灵活度。对于需要托管体验的团队，这很好用。对于需要流量走自有基础设施的团队，这行不通。

OpenAI Codex CLI：简单环境变量，完整网关支持

Codex CLI——OpenAI 的终端编程 agent——是最容易接入网关的。两个环境变量搞定一切：

# Codex CLI 网关配置
export OPENAI_BASE_URL="https://your-gateway.example.com/v1"
export OPENAI_API_KEY="sk-your-gateway-key"

# Codex CLI 现在所有请求都走你的网关
codex

因为 Codex CLI 是单进程 agent（不会生成 sub-agent），OPENAI_BASE_URL 覆盖是一致的——每个请求都命中你的网关。代价是与 Cursor 或 Claude Code 相比，agentic 能力更简单。

你能配置的：

• OPENAI_BASE_URL——完全控制端点
• OPENAI_API_KEY——网关 key
• 端点支持的任意模型名称
• 配置文件（~/.codex/config.yaml）持久化设置

你不能配置的：

• 内置治理——无；需委托给网关
• 审计链路——依赖网关侧日志
• 沙箱控制——仅 OS 级别（Codex 在 macOS/Linux 上使用沙箱）

GitHub Copilot：仅限 Enterprise 的自定义端点

GitHub Copilot 新增了自定义端点支持 (BYOK)——但仅限 Copilot Business 和 Enterprise 方案。个人版无法配置自定义代理。

企业管理员在 GitHub 组织设置中配置代理 URL。Copilot 将补全和聊天请求路由到代理，代理可以拦截、记录和重新路由请求。这是唯一一个端点配置在组织级而非用户级的编程 Agent——既是治理优势，也是灵活度限制。

你能配置的（仅限 Enterprise）：

• 组织级自定义代理端点
• GitHub 管理的模型列表
• 组织级策略（内容排除、审计日志、IP 限制）
• Copilot 在 VS Code、JetBrains、Neovim、CLI 中使用

你不能配置的：

• 用户级端点覆盖（个人版）
• 超出 GitHub 精选列表的模型选择
• 按请求路由——仅组织级代理
• 标准 Copilot 流程中直接使用 provider API Key

Zed：最灵活的逐 Provider 配置

Zed 对 API 配置采用了最细粒度的方式。每个 provider 可以有自己的 api_url、自定义 header 和 API Key——通过设置 UI、settings.json 或环境变量配置。

// Zed settings.json——OpenAI 兼容 provider 指向网关
{
  "language_models": {
    "openai": {
      "api_url": "https://your-gateway.example.com/v1",
      "custom_headers": {
        "X-Team-Id": "engineering",
        "X-Cost-Center": "platform"
      },
      "available_models": [
        { "name": "gpt-5.5-mini", "max_tokens": 131072 }
      ]
    }
  }
}

Zed 同时支持 OpenAI 兼容和 Anthropic 兼容的自定义端点，各自独立配置。Key 存储在系统钥匙串中（不是配置文件中的明文），设置了环境变量时环境变量优先。

你能配置的：

• 逐 provider 的 api_url——不同 provider 走不同网关
• 逐 provider 的自定义 HTTP header——用于成本归属和审计
• 自定义模型定义及 token 限制
• 系统钥匙串存储 API Key

你不能配置的：

• Key 管理之外的内置治理
• External agent 路由（Zed Agent 和 external agent 使用独立配置）
• 团队级策略执行（Zed 是单用户工具）

决策矩阵：按路由需求选择 Agent

网关集成模式

对于运行路由网关的团队，各 agent 的连接方式如下：

模式 1：OpenAI 兼容网关（Cursor、Codex、Zed、Copilot）

网关暴露 /v1/chat/completions，使用 OpenAI 兼容的请求/响应格式。大多数 agent 通过 base URL 和 API Key 连接。

# 你的网关从 Cursor / Codex / Zed 收到的请求
# POST /v1/chat/completions
{
  "model": "claude-opus-4-8",  # 网关解析到上游 provider
  "messages": [...],
  "stream": true
}

网关处理模型到 provider 的映射、密钥轮换、花费限制和故障转移路由。Agent 不需要知道哪个上游 provider 提供服务。

模式 2：Anthropic 兼容网关（Claude Code）

Claude Code 使用 Anthropic Messages API，而非 OpenAI 兼容格式。网关必须接受 POST /v1/messages 的 Anthropic 格式请求。

# 你的网关从 Claude Code 收到的请求
# POST /v1/messages
{
  "model": "claude-sonnet-4-20250514",
  "max_tokens": 8192,
  "messages": [...],
  "stream": true
}

LiteLLM、Portkey 和 TheRouter 等网关可以在两种格式之间转换。如果你的网关只支持 OpenAI 兼容格式，需要一个 Anthropic 到 OpenAI 的转换层。

模式 3：无法接入网关（Devin Desktop）

Devin Desktop 不支持自定义端点。所有流量走 Devin 的托管基础设施。如果法规或合规要求 LLM 流量留在你的网络内，Devin Desktop 不可行。

尚未解决的问题

尽管进展迅速，六款 agent 在运维层面仍有几个共同的缺口：

1. 统一审计链路——没有 agent 原生导出结构化日志（请求 ID、模型、token 数、延迟、成本）到你的可观测性体系。你需要网关侧日志。

2. 跨 agent 策略执行——如果团队同时使用 Cursor 和 Claude Code，没有统一的模型治理面板。每个 agent 有自己的配置机制。

3. MCP 工具治理——Agent 越来越多使用 MCP 工具，但没有标准来限制 agent 可以调用哪些 MCP 服务器。Claude Code 的权限模型最接近，但它是 Claude 专属的。

4. 自动密钥轮换——只有 GitHub Copilot Enterprise 和 Claude Code Enterprise 提供管理员管理的密钥生命周期。其他工具由开发者自行管理密钥。

5. 按项目/团队的成本归属——Zed 的自定义 header 最接近成本归属的实现，但没有 agent 内置成本中心标签。

路由网关可以解决 (1)、(2) 和 (5)：集中流量后，网关可以打标签、记日志、执行策略，无论请求来自哪个编程 agent。TheRouter 通过配置的 provider 路由 OpenAI 兼容请求，支持统一端点模式，适用于支持自定义 base URL 的 agent。

常见问题

问：Cursor 能否通过网关使用非 OpenAI 的 provider？ 可以——把 Override OpenAI Base URL 设为你的网关，网关可以路由到 Anthropic、DashScope、DeepSeek 或任何 provider。限制是 Cursor 的 sub-agent 会绕过这个覆盖（截至 2026 年 7 月的已知 bug）。

问：Claude Code 能用 OpenAI 兼容网关吗？ 仅当你的网关同时支持 Anthropic Messages API 时可以。Claude Code 不发送 OpenAI 格式请求。LiteLLM 和 Portkey 等网关支持两种格式。

问：Windsurf 还能用吗？ Windsurf 于 2026 年 6 月 2 日更名为 Devin Desktop。已有的 Windsurf 设置会自动迁移。

问：哪款 agent 最适合隔离网络或本地部署？ Codex CLI 和 Claude Code 都支持指向本地端点。Zed 通过 Ollama 或 LM Studio 支持本地模型。Devin Desktop 和 GitHub Copilot 需要云连接。

问：能否在团队范围内强制模型白名单？ GitHub Copilot Enterprise 提供组织级模型列表控制。Claude Code Enterprise 允许限制层级。其他工具需要在网关层面执行——拒绝不在审批列表中的模型请求。

---

定价、功能可用性和 sub-agent 行为可能随厂商更新而变化。部署前请对照各工具官方文档核实当前配置。