在本机放一层代理挡住一把聚合 key：让机器上所有工具共用同一个出口

为什么要在本机放一层代理

用聚合站的一个 API key 调多个模型很方便，但问题往往出在 key 的分发上：编辑器插件里存一份、命令行工具里 export 一份、临时脚本里又写死一份。key 越散，泄露面越大，更换 key 时改的地方也越多。

在本机跑一个薄代理，让所有工具都指向 http://127.0.0.1:端口，真正的 key 只存在于代理进程中。工具侧看到的只是一个本地地址，不接触密钥。

代理需要做哪三件事

一个够用的本地代理，职责可以收得很窄：

• 鉴权收拢：统一在向聚合站转发时注入 API key，工具请求里不带密钥。
• 按工具打标：给来自编辑器的请求、来自 CLI 的请求、来自脚本的请求加上不同标识，便于日后在聚合站侧区分用量来源。
• 基础限速：在本地做一层简单的请求节流，避免某个脚本失控刷爆额度。

这三件事都在本机完成，聚合站侧看到的仍然是一个普通的 API 调用方。

鉴权：key 只留在一个地方

代理读取环境变量或本地配置文件里的 key，转发时写入对应的鉴权头。上游工具不再需要自己配置 key，只需要把 base URL 指向本地地址。

这样做的直接收益：

• 更换 key 只改代理的一处配置，不用逐个工具去翻。
• 工具配置文件里不再出现明文密钥，误提交到仓库的风险下降。
• 可以按需给代理加一个本地访问限制，只监听回环地址。

打标：让不同工具留下可区分的痕迹

聚合站按工具区分用量，前提是请求本身带有可区分的信息。常见做法有两种：

一种是给每个工具分配一个固定的自定义请求头，代理在转发时保留或统一改写；另一种是在代理层按来源端口或来源进程做映射，再写入对应标识。

无论哪种方式，目的都是让后续的用量分析能回答“哪类工具消耗最多”，而不是把全部流量混成一团。打标逻辑集中在代理里，工具侧不需要各自实现。

限速：把失控挡在本地

本地限速不需要复杂。按时间窗口计数、超出就返回本地错误，已经能拦住大多数意外情况，比如循环调用、脚本重试风暴、忘记加休眠的批处理。

注意本地限速只是第一道闸，不能替代聚合站侧的配额。它的价值在于快速失败、及时暴露问题，而不是精确计费。

工具侧怎么接

大多数支持自定义 base URL 的工具都能直接接入：

• 编辑器插件：把 API 地址改为本地代理地址，清空原先填写的 key。
• 命令行工具：通过环境变量设置 base URL，不再导出密钥。
• 临时脚本：统一从同一个环境变量读取地址，避免手写硬编码。

接入后，工具的行为和直连聚合站基本一致，差别只是请求先经过本机。

部署与边界

代理本身可以是一个很小的本地进程，随开发环境启动。几点边界值得提前想清楚：

• 只监听回环地址，不要暴露到局域网。
• 代理进程的日志不要记录完整请求体，避免把敏感内容落盘。
• 本地限速阈值按实际使用习惯设定，过严会干扰正常批处理。

这层代理不改变聚合站的计费方式：使用者仍按官方价 ×1.3 扣费，贡献 key 的一方按 ×1.1 或 ×1.2 返 USDC。它解决的是 key 的管理边界问题，而不是价格问题。

什么时候值得加这一层

如果只有一两个工具、key 也不常换，直连更简单。当工具数量增加、多人共用一台机器、或者需要按工具看用量时，本地薄代理的收益就开始显现：密钥集中、标识统一、限速可控，且不需要改动上游服务。