Codex和Gemini桌面版账号管理器，如何打造？

字数 2257，阅读大约需 12 分钟 我用 Codex 和 Gemini，做了一个本地桌面版的 Codex 账号管理器 最近这段时间，我一直在把一个项目慢慢做扎实。 它叫 CodexManager。 如果只用一句话来介绍它，我会这样说： 这是一个本地桌面端 + 服务进程的 Codex 账号池管理器，同时也提供本地网关转发能力。 说白一点，它不是“再做一个后台面板”，而是想把我自己平时最头疼的那一整条链路，真正收拢到一个能用、顺手、稳定的工具里。 而且这个项目的开发过程，本身也很有意思。 它基本是我来做方向和细节判断，AI 来参与实现，当前大概可以粗暴地理解成：Codex 98%，Gemini 2%。所以它对我来说，不只是一个工具项目，也是一种很现实的开发实验：当一个人带着明确目标，和 AI 协作，能不能把一个桌面工具真正做出来，而且不是 demo，而是能让别人装上去就开始用。 为什么我会做这个项目 我做这个项目的起点，其实很简单。 平时一旦账号多起来，问题就会立刻变得很碎： • 账号分散，谁还有量、谁已经低配额、谁已经不可用，要来回看 • 导入导出麻烦，文件一多就乱 • 浏览器授权和回调解析不顺的时候，人工处理特别烦 • 想给 CLI 或第三方工具提供统一入口，又得自己搭一层转发 • Key、聚合 API、上游配置、端口、代理、监听地址，全都散在不同地方 这些问题单看都不算大，但一旦串起来，你就会发现时间不是花在“用工具”上，而是花在“管理这些管理工具”上。 所以我想做一个东西，把这些事情一次性收回来。 不是为了做得多花哨，而是为了让自己和别人都能少折腾一点。 它到底是什么 CodexManager 现在是一个双形态项目。 一层是桌面端。它更像你真正每天会打开来用的主界面，用来做账号管理、用量查看、Key 绑定、聚合 API 配置、插件管理、设置调整这些事情。 另一层是service 进程。它负责提供本地服务能力，包括本地 OpenAI 兼容入口、服务监听、网关转发，以及更偏底层的运行支撑。 如果你只想把它理解成一个结论，也可以： 它不是单纯的可视化界面，而是一套“桌面管理 + 本地服务 + 网关转发”的完整链路。 下面这张图，基本就是它现在的主界面观感： 这也是我为什么一直不太愿意把它写成“某某管理后台”的原因。因为它真正想解决的，是链路问题，不是页面问题。 现在它已经能做什么 从当前 README 来看，CodexManager 已经不是一个只停留在“能打开”的项目了。 在账号这一层，它已经能做账号池管理，包括分组、标签、排序、备注、封禁识别与筛选。你可以批量导入，也可以按账号导出单文件。桌面端还支持文件夹递归导入 JSON，这一点对整理历史账号文件很有用。 在用量这一层，它已经不只是“显示一个数字”。现在能兼容 5 小时 + 7 日双窗口，也能处理只返回 7 日单窗口的账号，并展示对应窗口的重置时间。换句话说，你不是只知道“这个账号还能不能用”，而是能更清楚地知道“它现在处于什么状态”。 在授权这一层，它支持浏览器授权，也支持手动回调解析。这个能力看起来不显眼，但真遇到回调不顺、环境不标准、浏览器行为不一致的时候，它非常关键。 在接口和接入这一层，它已经有了平台 Key 管理、聚合 API 管理，以及本地 OpenAI 兼容网关。你可以创建、禁用、删除 Key，做模型绑定、推理等级和服务等级设置；也可以管理第三方最小转发上游，做连接测试、排序和分类展示。 在扩展这一层，它已经有了插件中心，路由是 /plugins/，支持内置精选、企业私有、自定义源三种市场模式，也有插件清单、任务、日志和 Rhai 对接接口。 如果再往下看，它连文档体系也在逐渐补齐。运行部署、环境变量、FAQ、插件中心最小接入、接口清单、内部接口总表、构建发布说明，现在都已经在仓库里整理出来了。 这也是我自己很在意的一点：一个真正能持续维护的项目，不只是功能上线，还要让别人知道怎么用、怎么接、怎么排障。 为什么这一版值得单独写一下 当前 README 里最新版本是 v0.1.14。 这一版我自己总结下来，其实就两件事：更稳的服务，和更好接入。 前者主要体现在入口层做了短队列等待和超载快速退化，设置页加了“系统推导”和“单账号并发上限”。这些不是表面上最显眼的功能，但它们会直接决定一个工具在真实环境下是不是“能顶住”。 后者主要体现在插件中心相关文档、接口清单、系统内部接口总表这些内容逐渐补齐，README 的预览和链接结构也一起整理过了。它不只是方便我自己维护，更重要的是，别人接入的时候终于不需要再靠猜。