每天同时折腾 Claude Code、Codex CLI、Gemini CLI，最烦的不是模型不够多，而是入口越来越乱：环境变量到处填、账号和 API Key 分散、日志和用量看不全，工具一多就开始失控。

我最近把这件事收拢成了一个本地方案：CliGate。它不是再造一个聊天壳，而是把常驻 Assistant 和模型代理合成一套本地控制平面，让不同 AI CLI 走同一个入口、共用同一层路由与治理。

为什么 AI 工具越多，反而越难用

很多人一开始只是装一个 CLI，后面很快就会变成：

• Claude Code 走一套配置
• Codex CLI 走另一套配置
• Gemini CLI 还要单独接一层
• 不同 provider 的 API Key 和账号分散保存
• 日志、计费、请求链路几乎看不到全貌

工具看起来是变多了，但真正的问题其实是：没有统一入口，也没有统一控制面。

CliGate 想解决的，不只是“代理转发”

CliGate 的核心不是单纯把请求转一下，而是把两层能力放到本地：

层	作用
Assistant	作为常驻私人助手，负责理解任务、记忆上下文、调工具、跑定时任务、接入钉钉/飞书/Telegram 等渠道
Model Proxy	给 Claude Code、Codex CLI、Gemini CLI、OpenClaw 以及 API 兼容客户端提供统一入口，集中做模型路由、凭据管理、日志与用量观测

换句话说，它更像一个本地 AI 控制平面：前面接助手和各种 CLI，后面统一接不同 provider 与本地运行时。

真正有价值的地方，在“统一治理”

如果你只是偶尔调一个模型，可能感受不到差别；但一旦进入多工具并行的状态，统一治理会立刻变得重要。

1. 一个本地入口，少掉一堆重复配置

CliGate 默认跑在 localhost:8081，你不需要让每个工具分别直连不同上游。像 Claude Code、Codex CLI、Gemini CLI，都可以被收敛到这一个入口后面。

这样做最直接的收益有三个：

• 配置收口：不用在多个工具里反复维护不同地址和凭据
• 路由统一：免费模型、账号池、API Key 池都能在一层里做选择
• 问题好查：请求日志、用量、价格视角更集中，不会排障时满地找配置

2. 账号池和 API Key 池终于不再“各管各的”

很多团队不是没有模型资源，而是资源分散到不同账号、不同 key、不同工具配置里，结果谁也不知道当前到底走了哪条路。

CliGate 把这些东西集中到一个代理层里：

• ChatGPT / Claude / Antigravity 账号池
• OpenAI、Anthropic、Gemini、Vertex AI 等 API Key 池
• 应用级绑定
• 模型映射
• 路由优先级

你可以把它理解成：不是多给你几个模型，而是让已有模型资源终于能被像“系统能力”一样调度。

3. Assistant 不只是聊天，而是能真正执行任务

很多人对“本地 AI 助手”的期待，其实不是能多会聊，而是能不能真的把事情做掉。

CliGate 里这层 Assistant，重点不是陪聊，而是执行：

• 能记住上下文和任务历史
• 能调 skills、MCP、Shell / 文件工具
• 能安排定时任务
• 能接入钉钉、飞书、Telegram 渠道
• 需要时还能委派给 Codex / Claude Code runtime

这意味着它不是一次性对话，而更像一个常驻的本地任务执行者。

一个很容易被低估的点：本地优先

现在很多 AI 工作流一复杂，就很容易把敏感配置、工具链路和操作痕迹散到远端 SaaS 里。CliGate 的一个重要选择是：尽量把控制面留在本地。

这件事带来的好处很实际：

• 本地仪表盘统一看路由、日志、用量和设置
• 本地绑定 localhost，更适合个人和小团队内网环境
• Assistant、渠道、技能和模型代理可以围绕同一套本地状态工作

它不是“绝对安全”的神话，但它至少把最关键的控制权尽量留在你自己的机器上。

适合什么人现在就开始用

如果你满足下面任意一种情况，CliGate 会比“继续堆脚本”更省事：

• 你同时在用 2 个以上 AI CLI
• 你已经有多个 provider 账号或 API Key，管理开始混乱
• 你希望把私人助手、定时任务、渠道机器人、模型代理整合到一处
• 你想让一部分 AI 自动化能力长期驻留在本地，而不是每次从零拼接

最后一句

当 AI 工具越来越多时，真正稀缺的不是“再加一个模型”，而是把入口、路由、凭据和执行能力收拢成一个稳定的本地控制面。

如果你已经开始同时使用 Claude Code、Codex CLI、Gemini CLI，这一步越早做，后面越不容易失控。