)
1. 为什么要在 Amp 里接一层 CLIProxyAPIAmp 是近几年在 IDE 圈子里讨论度很高的 AI 编码工具它既能以 CLI 形式跑在终端里也能作为 VS Code、Cursor、Windsurf 的插件嵌进编辑器。默认情况下Amp 走的是官方托管通道模型调用和额度都绑在它的账号体系上。问题也随之而来当你想在同一个 IDE 里同时用 Codex、Claude、Gemini 这几家不同来源的模型时Amp 本身并不方便做统一 Key 管理每个工具一套配置、一套额度切来切去很折腾。CLIProxyAPI 解决的正是这个痛点。它是一个本地运行的代理层默认监听8317端口可以把 Amp 发出的模型请求转发到本地已经登录好的 Codex / Claude / Gemini 账号上同时把登录、账户这类控制面请求反向代理回官方地址。这样一来Amp 只需要认一个本地地址背后接哪家模型由 CLIProxyAPI 决定。再配合 TaoToken 的统一 Key 体系你就能在 IDE 内用一套凭证管理多模型调用不用在多个平台之间反复切换。这篇教程面向的是需要在 IDE 内统一管理多模型 Key 的开发者。我会给出可直接复制的settings.json配置骨架、CLIProxyAPI 的启动参数、验证连通性的具体命令以及我自己踩过的几个坑。整套流程走下来你应该能在十分钟内让 Amp 通过本地代理正常发消息。2. 前置准备TaoToken Key 与 CLIProxyAPI 环境在动 Amp 的配置之前先把两样东西准备好否则后面排查问题会分不清是代理没起来还是 Key 不对。第一样是 TaoToken 的 API Key。TaoToken 在这里扮演的是统一凭证入口的角色你可以在它的控制台里生成和管理 Key然后让 CLIProxyAPI 用这个 Key 去对接上游。生成入口在控制台的 API Keys 页面地址是https://taotoken.net/api-keys登录后新建一个 Key 并复制保存。注意这个 Key 和后面 Amp 网站上的 Access Token 是两个完全不同的东西别混用。第二样是 CLIProxyAPI 本体。它需要已经安装并能正常启动默认监听8317。启动之后你还要确保它至少登录了一个上游账号比如 Codex、Claude Code 或 Gemini CLI 中的任意一个。登录状态是 CLIProxyAPI 转发请求的基础如果本地一个账号都没登录代理起来也是空转。Amp CLI 本身也要装好终端里能执行amp命令。IDE 插件的话VS Code、Cursor、Windsurf 都支持装完先别急着配等 CLI 这边跑通了再同步过去因为 CLI 和插件的配置互不继承需要各自设置。提示TaoToken 的接入文档在https://taotoken.net/doc里面有针对不同客户端的配置示例遇到字段不确定时可以对照着看。3. 可复制配置config.yaml 与 settings.json这一节是全文的核心配置写对了后面基本就是验证的事。3.1 获取 Amp Access Token打开https://ampcode.com/settings找到 Access Token 区块点击 Copy Token。这个 Token 用于 CLIProxyAPI 反向代理 Amp 的控制面请求比如/api/auth、/api/user这些路径。它和 CLIProxyAPI 自己的api-keys是两套体系前者代表 Amp 账号身份后者代表本地代理的访问凭证。3.2 修改 CLIProxyAPI 的 config.yaml打开 CLIProxyAPI 的config.yaml添加或修改ampcode段。下面这份配置可以直接抄把upstream-api-key换成你刚才复制的 Amp Access Token 即可ampcode: upstream-url: https://ampcode.com # 第 1 步复制的 Amp Access Token upstream-api-key: ampcode-apikey restrict-management-to-localhost: false force-model-mappings: true model-mappings: - from: claude-opus-4-7 to: gpt-5.5 - from: claude-opus-4-6 to: gpt-5.5 - from: claude-opus-4-5-20251101 to: gpt-5.5 - from: claude-sonnet-4-5-20250929 to: gpt-5.5 - from: claude-haiku-4-5-20251001 to: gpt-5.5 - from: gpt-5.4 to: gpt-5.5字段含义对照如下字段作用upstream-urlAmp 控制面地址固定为https://ampcode.comupstream-api-key上一步复制的 Amp Access Tokenrestrict-management-to-localhost管理路由是否只允许本机访问本地使用设falseforce-model-mappings是否强制走映射表见 3.3 节model-mappings模型重定向规则保存后重启 CLIProxyAPI让配置生效。3.3 model-mappings 的工作机制Amp CLI 请求的模型名比如claude-opus-4-7未必和你本地登录账号提供的型号一致。CLIProxyAPI 的处理逻辑分三种情况本地有同名模型时直接用本地模型映射表不生效本地没有同名模型时报错但如果映射表里配了替身就改请求替身模型当force-model-mappings: true时无论本地有没有同名模型都先走映射表。上面这份配置开启了强制映射把所有 Amp 请求统一指向gpt-5.5。如果你本地实际可用的模型别名不是这个记得改to字段具体可用列表可以通过 CLIProxyAPI 自身的/v1/models接口确认。3.4 配置环境变量并启动 AmpCLI 侧通过环境变量接入在终端里执行export AMP_URLhttp://localhost:8317 export AMP_API_KEY123456这里的AMP_API_KEY必须和 CLIProxyAPI 配置顶部api-keys中的某一项匹配它不是 Amp 网站的 Access Token。配好之后启动amp3.5 IDE 插件的 settings.json 骨架VS Code、Cursor、Windsurf 这类编辑器需要在settings.json中追加下面这段{ amp.url: http://localhost:8317, amp.apiKey: 123456 }再次强调CLI 和 IDE 插件的配置互不继承两边都要各自设置一遍。amp.apiKey同样对应 CLIProxyAPI 的api-keys不是 Amp 的 Access Token。4. 验证请求从日志确认链路打通配置写完不代表接通得用实际请求验证。发送一条消息后观察 CLIProxyAPI 的日志输出满足以下三点才算接入成功请求路径包含/api/provider/...说明模型请求确实走了代理路由模型名按映射表被改写比如日志里出现的是gpt-5.5而不是原始的claude-opus-4-7上游返回200表示请求被正常处理。如果你想在发消息前先单独验证代理是否活着可以用 curl 打一下本地端口curl -s http://localhost:8317/v1/models \ -H Authorization: Bearer 123456返回模型列表就说明 CLIProxyAPI 本身工作正常123456换成你api-keys里的实际值。这一步能快速区分是代理没起来还是 Amp 配置写错了。另外如果你只是想先确认某个模型能不能正常对话可以直接用 TaoToken 的模型对话页面测一下地址是https://taotoken.net/chat不用每次都启动 Amp 来验证。5. 本篇常见错误排查接入过程中最容易卡在几个固定位置我把它们整理出来方便你对照日志定位。amp login返回 401。这是 CLIProxyAPI v6.6.15 到 v6.6.17 的一个已知 bug/auth/*路由被错误地套上了 API key 鉴权。解决办法是升级到更新版本或者回退到 v6.6.14。force-model-mappings: true不生效。先检查from字段拼写。Amp 的模型版本号更新比较频繁尤其是带日期戳的名字很容易抄错。最稳妥的做法是看 CLIProxyAPI 日志里实际收到的模型字符串照实抄进映射表。Amp 已登录但聊天超时。检查两点upstream-url是否写对Amp Access Token 是否还有效它有可能被 revoke 过。后者到https://ampcode.com/settings重新生成一个即可。模型映射后报上游模型不存在。to字段必须是 CLIProxyAPI 本地实际可用的模型别名不能凭空写。通过/v1/models接口确认本地模型列表再填进去。注意这套方案把订阅型 CLI 的额度转发给了非预期客户端使用是否符合各家服务的条款需要你自己评估。建议只用于个人本地开发不要用于团队协作、对外服务或商业产品。6. 长期编码场景下的 Key 管理建议如果你打算把 Amp 当作日常主力编码工具长期跑下去建议把 Key 管理这件事提前理顺。CLIProxyAPI 的api-keys可以配多个给 CLI 和 IDE 插件各用一个这样某一端出问题时不会互相影响。TaoToken 这边的统一 Key 也建议按用途拆分比如一个专门给本地代理用一个留给其他客户端方便后续做额度观察和轮换。对于需要长时间跑 Agent 任务、频繁调用模型的场景可以关注 TaoToken 的 Coding Plan地址是https://taotoken.net/coding-plan它更适合这种持续性的编码工作负载。配置层面把force-model-mappings和映射表维护好模型版本更新时只改一处Amp 那边不用动。整套流程跑通之后你在 IDE 里切换模型、管理多套 Key 的成本会明显下降。真正需要花心思的反而是映射表里那些带日期戳的模型名它们变化最快也最容易让请求悄悄走错模型。