Codex + 自建中转站，用不完的token+GPT5.4 做成了一个AI机器人

Codex 自建中转站用不完的tokenGPT5.4 做成了一个AI机器人最近因为gemini实在太贵订阅了两个月后还是和团队一起搞了自建中转站这也正是高龄程序员的痛所以也想着给自己多搞个退路对于AI我的第一感受是如何让AI把一件真正麻烦的事做顺了做准确了于是我准备试一试codex和gpt全程AI没有古法编程。核心是企鹅登录态、NapCat / OneBot 消息协议、OpenAI 兼容网关、本地会话记忆、知识库召回、桌面化运维控制台串成了一个可运行、可排障、可交付的完整链路。如果你也有想独立开发的想法这个项目一定很有参考价值如果有需要使用的我的中转站的可以后台call我不是无偿但绝对最优惠。下面是一个开发的思路想把 企鹅号接到自己的 AI 能力上做私聊或群聊机器人想把 GPT-5.4 接到本地业务而不是只在网页里聊天想做一个“开发可用、交付也可用”的桌面客户端而不是只会在命令行里跑这篇文章我会按“核心功能 - 技术栈 - 架构设计 - 关键实现 - AI系统提示词”的顺序把这个项目拆开讲清楚。1. 项目一句话概括本质上是一个运行在 Windows 上的企鹅 AI 桥接控制台前端形态是Electron桌面客户端消息入口是NapCat / OneBot 11服务端核心是Node.js ExpressAI 能力通过OpenAI 兼容协议接入会话、日志、运行状态通过SQLite本地持久化还额外做了二维码登录辅助、QQ 绑定校验、多 Bot Profile、知识库召回2. 这个项目的核心功能先说结论这个项目最有价值的不是某一个单点而是下面这几块组合起来之后的完整性。2.1 企鹅号与目标 Bot 账号绑定校验很多同类项目只要OneBot / get_login_info能返回用户信息就认为系统可用了。但这个项目更严格它会校验当前 OneBot 登录的 企鹅是谁这个 企鹅 是否等于配置里的BOT_SELF_ID如果扫错号是否要重置登录流程并重新生成二维码这意味着它解决了一个很实际的问题不是“登录了某个 账号 就行”而是“必须登录到我指定的那个机器人 账号”才算成功。2.2 自动拉起 NapCat / 企鹅项目启动时不只是起一个 HTTP 服务而是会做完整的启动编排清理旧的桥接进程、NapCat 进程和冲突端口启动本地桥接服务检查 NapCat 是否已可用必要时自动拉起 NapCat必要时自动拉起 企鹅轮询 OneBot 登录状态这部分的价值在于它把“人工点来点去”的流程尽量程序化了。2.3 二维码登录链路可视化这个项目不是只等你自己去 NapCat 看日志而是主动从多个位置提取二维码信息从 NapCat 日志里提取二维码 URL解析二维码内容在终端直接打印字符二维码在 Electron 桌面端渲染二维码图像这对实际使用体验非常关键因为登录失败的第一现场通常就卡在二维码这一段。2.4 接收消息 - AI 回复 - 回发消息核心主链路非常标准但实现得比较完整NapCat 把消息事件POST到/onebot/event服务端判断是否要处理这条消息按私聊 / 群聊 用户维度构造会话 ID读取上一次response_id续接上下文召回知识库片段请求 OpenAI 兼容模型生成回答再通过 OneBot API 发回 企鹅自定义系统提示词给机器人赋予灵魂这里参考了龙虾的soul.md所以我定义了一个能安慰人的机器人它支持私聊自动回复群聊只在被时回复群聊全量回复模式/reset或中文重置命令清空当前上下文2.5 本地轻量知识库这个项目没有上向量数据库而是做了一个很轻的本地知识库方案支持.md.txt.json.pdf它的思路是先按段落切块对中文做单字和双字切分对英文做 token 抽取用词命中做打分取 TopK 片段拼进系统上下文这不是“最重”的 RAG但非常适合本地桥接项目成本低部署简单没有额外服务依赖对 FAQ、资料型问答已经足够实用2.6 桌面运维控制台Electron 客户端不是摆设它做了很多“可交付”层的事情图形化编辑.env启动 / 停止 / 重启桥接服务查看二维码查看运行状态查看最近对话查看日志跑配置诊断拉取可用模型列表多 Bot Profile 管理这说明项目定位不是 Demo而是希望把运维门槛压低。3. 技术栈一览层次技术栈作用桌面端Electron提供图形化控制台服务端Node.js Express接收 OneBot 事件、转发 AI 回复协议层NapCat OneBot 11打通 QQ 消息收发模型接入OpenAI-compatible API兼容官方接口或自建中转站持久化node:sqlite / SQLite存会话、消息、运行快照、诊断记录知识库pdf-parse 本地文件切块做轻量召回二维码jsqr pngjs qrcode-terminal qrcode二维码识别、终端打印、桌面显示打包electron-builder输出 Windows 便携版和安装版从依赖选择上看它整体遵循的是一个非常务实的原则优先保证本地可运行、可交付、可维护而不是为了“技术先进”引入一堆额外中间件。4. 架构怎么设计的整个系统我建议你把它理解为“两套状态机 一条消息链路”。4.1 一条消息链路QQ / 群聊 / 私聊NapCat / OneBot 11POST /onebot/event消息过滤与会话路由知识库召回OpenAI Compatible APIOneBot HTTP API4.2 两套状态机第一套状态机是应用登录态应用是否已启动NapCat 是否已启动OneBot 是否可达当前登录企鹅是否等于目标企鹅号是否需要二维码是否需要回收旧登录流程第二套状态机是AI 会话态当前消息属于哪个会话上次模型返回的response_id当前 Bot 配置是否变化当前知识库指纹是否变化是否需要重置上下文这两个状态机是拆开的这一点非常重要。因为登录态解决的是“这个机器人能不能工作”会话态解决的是“这个机器人说话是否连贯”。很多项目把这两件事混在一起导致一出问题就很难排障。5. 核心模块拆解5.1bootstrap.js先起服务再后台等登录这个项目有一个很不错的工程决策先把 HTTP 服务起起来再在后台等待 企鹅 / OneBot 登录完成。这样做的好处是healthz很早就可用Electron 能立刻拿到状态启动阶段不是黑盒用户知道系统卡在“服务未起”还是“未登录”很多桌面端程序会反过来做结果就是前面一长段时间界面没有状态只能等。5.2startup.js真正的启动编排中心这个模块是项目里最有“工程味”的部分基本承担了整套 Windows 侧自动化清理旧进程与端口写入 NapCat 的 OneBot 配置检查 OneBot 是否可达自动拉起 NapCat / 企鹅解析日志里的 WebUI 地址和二维码链接从 PNG 中识别二维码打印终端二维码校验当前登录 企鹅 是否匹配目标 Bot不匹配就回收并重启登录流程如果你以后也要做类似桥接项目这个模块的设计思路比“消息回复逻辑”更值得学。5.3server.js消息处理主入口server.js主要做五件事暴露/healthz接收/onebot/event根据self_id匹配当前 Bot Profile过滤无效事件和群聊触发模式调用知识库与模型生成回复这里还有几个细节值得注意支持OneBot Post Secret做签名校验群聊默认只在被时触发避免刷屏会话 ID 是按bot 私聊/群聊 用户粒度构建的日志不仅打印在控制台还会写入持久化层5.4openai-client.js兼容层做得很实用这是我个人比较喜欢的一块。它不是简单写死某一个接口而是做了两层兼容优先走/responses如果中转站不支持再回退到/chat/completions这非常适合“官方接口 第三方兼容网关 自建中转站”混用场景。另外它还做了这些增强自动规范化OPENAI_BASE_URL支持多个 base URL 候选支持拉取/models支持reasoning.effort支持不同 Bot 使用不同模型配置一句话评价这不是只为了“能用”而是为了“你换供应商时别改一堆代码”。5.5knowledge-base.js轻量 RAG 的正确打开方式这个模块非常适合中小项目抄作业。它没有上向量数据库Embedding 服务复杂召回链路而是用了一个更接地气的思路文件切块缓存基于文件大小和修改时间做缓存键中文单字 / 双字 英文 token 混合分词命中打分TopK 拼接如果你的目标是“给 机器人加一点本地知识”这种方案的性价比是很高的。5.6persistence.js把“能跑”升级成“能追踪”项目把很多运行时数据都落进了 SQLitesessionsmessagesruntime_snapshotsdiagnostics_runs这带来的价值非常直接程序重启后还能知道上次状态最近对话可回看诊断结果可留痕旧的sessions.json还能迁移进来同时它开启了WAL模式这对桌面本地数据库是一个比较合理的选择。5.7bot-profiles.js从单 Bot 走向多 Bot这个模块说明作者已经不满足于只服务一个账号。它支持多 Bot Profile激活某个 Bot每个 Bot 拥有独立的模型、System Prompt、群聊模式、知识库配置将活动 Bot 的关键配置镜像回.env这意味着项目后面很容易扩成实际上已经实现了多个 企鹅 号不同业务人格不同知识库不同模型策略6. 为什么这个实现思路是对的如果让我用工程视角总结这个项目的实现思路我会概括成下面 4 句话。6.1 把“消息服务”与“登录运维”分层聊天回复只是表面功能真正让系统稳定的是登录流程可视化绑定状态可确认异常流程可回收这类项目一旦没有这层线上运维会非常痛苦。6.2 把“OpenAI 官方接口”抽象成“兼容网关”项目没有把模型供应商写死而是统一收口到OPENAI_BASE_URLOPENAI_API_KEYOPENAI_MODEL这一步非常关键因为你后续无论接官方 OpenAIAzure 风格兼容层自建中转站第三方代理网关整体代码都不用大改。6.3 先解决交付问题再追求算法复杂度从轻量知识库、本地 SQLite、Electron 控制台这些点可以看出项目优先级是能装起来能跑起来能排障再逐步增强智能度这是很典型、也很正确的工程化思路。6.4 尽量把“状态”变成可观测对象项目里很多设计都围绕“状态透明”展开/healthz最近会话运行快照诊断报告QR 状态当前登录企鹅号这让桌面端不再只是个壳而是真正的运维面板。7. 那么其中大模型消耗的token从哪来当然是自建中转站啦当然有需要的后台call我很优惠这部分是我认为这篇文章最适合扩展的地方。因为这个项目天然就是一个OpenAI-compatible 接入层所以它非常适合接在“自建中转站”后面。7.1 一个推荐的角色分工我建议把三者这样分工Codex负责开发阶段写代码、补测试、改 Prompt、做运维脚本、生成知识库资料GPT-5.4负责线上问答阶段承担 应用 里的高质量回复自建中转站负责统一鉴权、路由转发、额度隔离、模型切换、日志审计这样做的好处是开发和生产用的 Token 不混用线上服务稳定性更高模型切换不需要改客户端逻辑不同 Bot 可以挂不同的模型策略7.2 这个项目为什么特别适合接中转站因为它本身就已经做了兼容层设计统一收口OPENAI_BASE_URL支持/models优先/responses失败回退/chat/completions每个 Bot 可以独立配置模型这意味着你完全可以把OPENAI_BASE_URLhttps://你的中转站域名/v1OPENAI_API_KEY你的中转站令牌OPENAI_MODELgpt-5.4作为项目主配置而不是把官方地址硬编码进项目。7.3 一个实用的 Token 搭配策略如果你真的要把它落地我建议按“开发 Token”和“生产 Token”拆开。方案 A最稳的搭法Codex 用一套专门的开发 Token应用桥接服务用一套专门的生产 Token中转站里给生产 Token 设置更严格的限流和额度适合自己开发机器人稳定跑在线上不希望开发调试把线上额度打爆方案 B多模型分流私聊高质量问答走gpt-5.4群聊高频消息走更便宜的兼容模型复杂场景再切回gpt-5.4适合群聊流量大成本敏感需要把高质量能力用在更有价值的消息上方案 C多 Bot Profile 分工Bot A客服 / FAQ挂知识库模型偏稳Bot B娱乐闲聊模型偏便宜Bot C开发群助手Prompt 更技术化这个项目的bot-profiles设计天然适合做这一层扩展。8. 项目最值得借鉴的 5 个点8.1 真正把“绑定正确”当成一等公民不是“能登录就行”而是“必须登录到目标 Bot 才行”。8.2 对第三方网关兼容做得很务实/responses不行就降级/chat/completions很适合国内复杂的中转环境。8.3 本地可交付性强Electron SQLite Electron Builder 的组合让它更像一个产品而不是脚本。8.4 轻量知识库方案非常接地气不依赖额外服务适合个人项目、小团队、内网环境。8.5 可观测性做得不错运行状态、二维码、消息记录、诊断报告都有对应落点不容易“黑盒化”。用 Electron 做控制台用 OneBot 做协议桥用 OpenAI-compatible 做模型抽象用 SQLite 做本地持久化再用 Codex GPT-5.4 自建中转站把开发效率和生产能力真正打通。AI是一个生产工具很多年前出现了新的生产工具淘汰了那些看不起它的人现在新的生成工具出现了