Agent Skills
返回列表
🤖

CLIProxyAPI 本地代理网关

AI Agent 更新于 2026.08.29

将以下提示词粘贴到你的 AI 对话框中：

请根据 https://skillhub.cn/install/skillhub.md，安装 @user_3c6cb52e/expose-cli-agent-accounts-through-api-compatible-local-proxy-with-cliproxyapi。

技能介绍

它解决什么问题

在团队内部，真正干活的往往是 CLI 形态的代理：它们带着各自的 OAuth 凭据，能调模型也能跑工具，却只能从终端里手工触发。任何想把这些代理接进既有流程的尝试，都会撞上一堵墙：上层系统要的是 OpenAI、Gemini、Claude、Codex、Grok 那一类 HTTP API，底层代理给的是命令行。协议对不上，集成就只能靠一次性脚本维持，难以复用。

这个技能的思路是别再造一套轮子，直接用现成的 CLIProxyAPI 充当中间层：把已经通过认证的 CLI 代理账户，包装成一个本地 HTTP 门面，让下游客户端像连普通模型服务一样连进来。

技能如何工作

核心能力分三块：

  • 协议转换：对外暴露与 OpenAI、Gemini、Claude、Codex、Grok 兼容的 API 形态，对内复用各 provider 已有的 CLI / OAuth 凭据，不需要为了集成额外申请一套密钥。
  • 凭据复用：代理侧只需维护一份本地已认证的账户，下游客户端接触不到原始凭据，减少了密钥在多个服务之间扩散的面。
  • 可重复集成：门面一旦跑起来，agent 与工具链就能按标准客户端方式接入，而不是每个调用方各写一套脚本。

关键步骤大致是：准备 CLIProxyAPI 的二进制或源码构建版本，确认待代理的各个 provider 已有可用的本地 CLI / OAuth 凭据，准备好兼容的客户端，然后启动本地代理服务。具体配置细节以项目文档为准。

适用边界与注意点

  • 这个技能不是一份新的 proxy 实现，它依赖 CLIProxyAPI 本身，行为、稳定性与上游保持一致。
  • 自动抽取阶段没能拿到可直接落地的安装与使用说明，敏感流程里建议先通读上游仓库再动手。
  • 凭据归属、调用配额与异常重试语义由 CLI 代理与上游 provider 决定，本地门面不会替你兜底。
  • 参考材料：https://help.router-for.me/、https://github.com/1991513ccie-png/skills。

使用场景

  • 需要把已认证的 Claude Code CLI 账户暴露给内部系统，使其以 OpenAI 兼容接口调用模型。
  • 团队希望复用 Gemini CLI 的 OAuth 凭据，避免为每套工具单独申请 API Key。
  • 将 Codex CLI 代理接入 CI 流水线中的自动代码评审工具，统一走本地 HTTP 入口。
  • 把多个 provider 的 CLI 账户聚合成一个本地 API 端点，供下游 agent 框架调用。

适合人员

  • 后端工程师：希望把团队已有的 CLI 代理账户复用给多个服务，避免维护多套密钥。
  • 平台集成工程师：负责把各类模型 CLI 接入内部工具链，需要标准 API 入口。
  • DevOps 工程师：要在 CI 环境里统一调用多个 provider 的 CLI 账户，且不想散落凭据。
  • Agent 应用开发者：构建下游 agent 工具，希望直接对接 OpenAI/Claude 兼容接口而非命令行。