如果你已经在本地把 AI coding agent 跑起来，下一个很快会遇到的问题通常不是“模型够不够强”，而是“怎么把同一个 agent 稳定地接到不同入口”。网页聊天、Slack、飞书、后台任务、权限控制、会话恢复、日志和诊断，这些问题一旦分散写在不同脚本里，系统很快就会变得难维护。

今天想推荐的 hrygo/hotplex，就是一层专门给 AI coding agent 准备的统一访问网关。它用 Go 实现，核心思路不是再造一个新的 agent，而是把不同 agent worker 包到同一个 WebSocket 协议后面，再把这个统一接口接到 Web、Slack 和飞书等入口。对于已经在试验 Claude Code、Codex CLI 或 ACP 兼容 agent 的团队来说，这种“中间层”思路很值得看。

发布时 GitHub 数据显示项目约 43 stars、11 forks，主要语言是 Go。仓库创建于 2026-03-30，最近一次公开更新时间是 2026-06-17，采用 Apache-2.0 许可。最新 GitHub release 为 v1.29.1，发布时间是 2026-06-16。

项目概览

属性详情
仓库hrygo/hotplex
定位AI coding agent 的统一接入网关
Stars约 43
Forks约 11
主要语言Go
协议AEP v1 WebSocket
许可Apache-2.0
最新版本v1.29.1

它解决的是 agent 接入层，而不是模型层

很多团队在试 AI coding agent 时，最先做通的是单机命令行。真正开始给别人用，问题才会集中冒出来。

同一个 agent 能不能同时服务网页端和聊天工具？不同入口的会话状态怎么维持？断线后是否能恢复？如果底层 agent 暂时不可用，是否有统一重试逻辑？如果一个团队同时试 Claude Code、Codex CLI 和其他 ACP 兼容实现，能不能避免每换一次后端就重写接入层？

HotPlex 的答案是先抽一层统一网关。README 里把它定义成一个高性能 Go gateway，通过单一 WebSocket 接口向前提供统一协议，向后连接不同 AI coding agent worker。它目前明确支持 Claude Code、OpenCode Server、ACP 兼容 agent，以及 Codex CLI。这点很关键，因为它的价值不在“替你生成代码”，而在“替你把多个 agent 能力以一致方式暴露出来”。

接入平台比我预期得更完整

这个项目不只是一个协议转发器。它把使用场景里最麻烦的外围部分也一起打包了。

首先是多入口支持。README 里写得很明确，HotPlex 可以把同一个 agent 暴露到 Web、Slack 和 Feishu。这意味着如果你的团队内部既有人习惯网页聊天，也有人希望直接在工作群里触发 agent，你不一定要维护两套完全不同的接入方案。

其次是它自带嵌入式 Web chat 和管理界面。项目不是只给一个 API 让你自己再配一层前端，而是把 AEP gateway、Next.js SPA chat UI 和 admin dashboard 放进同一个交付面里。对早期内部工具来说，这种“一套东西先跑起来”的设计很实用，因为你能先把链路打通，再决定哪些部分未来要拆开。

还有一个我觉得很有意思的点是它内置了 AI-native cron scheduler。不是简单的 Linux cron 包装，而是让 agent 可以从自然语言生成定时任务，并支持 cron、固定间隔和一次性调度，以及 max_runs、expires_at 这类生命周期控制。这个方向很适合把“提醒我半小时后继续这个调试会话”或“每天定时巡检一个仓库”这样的需求收进统一系统里。

统一后端抽象是它最值得关注的部分

HotPlex README 里提到它使用统一 worker interface，并支持五级配置回退。简单理解，就是前面入口不用强绑定某一个具体 agent，后端可以按 bot、platform、env、messaging、default 这些层次去决定实际调用哪个 worker。

这套抽象的意义很现实。团队在试 agent 基础设施时，经常会在不同运行时之间切换。今天想让 Slack bot 连 Claude Code，明天可能想把某些任务换成 Codex CLI，后天又可能想测试 ACP 兼容实现。如果这些切换都发生在业务接入层，系统就会越来越难改。统一网关至少能把这类变化尽量压到后端适配器里。

项目还强调 deterministic session、UUIDv5 session id、断线重连、SQLite/PostgreSQL 双持久化以及后台 GC。这些词本身不新鲜，但如果你真的做过聊天式 agent 服务，就会知道这类“会话脏活”迟早都要补。HotPlex 把它们作为默认能力给出来，比只展示一个演示聊天窗口更有工程味。

它也在试图补足安全和运维面

README 列出的安全和运维特性比我预期多。比如 timing-safe API key authentication、SSRF protection、command/tool/model allowlist、环境隔离、path traversal prevention，以及 Prometheus metrics、OpenTelemetry tracing、结构化 JSON 日志。

这不代表项目已经自动变成企业级成品，但至少说明作者不是只把它当成一个 demo。尤其是当 agent 真要接 Slack、飞书或 Web 入口时，外围系统的风险往往比模型回答本身更容易出问题。权限边界、可观测性和诊断工具如果从一开始就考虑进去，后面迁移到正式环境会顺很多。

CLI 设计也比较完整。README 提到它把 gateway、service、onboard、doctor、cron、config、update、status 等多个子命令放在一个二进制里，并支持 systemd、launchd 和 Windows SCM。对想做自托管部署的团队来说，这比“仓库里放几个不太连贯的脚本”更容易运维。

适合什么人看

我觉得 HotPlex 特别适合三类人。

第一类，是已经在内部测试 AI coding agent，但接入方式还比较散的人。你可能已经能在终端里跑一个 agent，但还没有把它稳定接到聊天工具和网页端。HotPlex 可以作为一层参考实现，看看一个“统一访问层”应该长什么样。

第二类，是想同时比较多个 agent runtime 的团队。HotPlex 支持 Claude Code、Codex CLI 和 ACP 兼容后端，这让它天然适合做一个切换层，而不是把上层体验绑死在单一 worker 上。

第三类，是对 agent 运维侧更感兴趣的人。它把 session、cron、admin、metrics、tracing、安全策略和配置热更新一起放在一个项目里，因此不仅能看“agent 怎么接”，还能看“接起来以后怎么管”。

需要注意的边界

这个项目的野心不小，所以阅读时最好分清哪些是已经能直接使用的工程能力，哪些还需要自己验证。

比如它支持的入口、worker、文档门户、管理界面和 cron 调度都很多，实际落地前仍然要看你自己的权限模型、消息平台限制、网络环境以及运维方式是否匹配。README 也明确把 Docker 标成 experimental，因此如果你更重视稳定部署，还是应该优先沿着项目推荐的安装和 service 方式去验证。

另外，它的核心协议是 AEP v1。如果你的现有系统已经围绕别的消息协议或自定义 SDK 构建，那么接入成本不一定低，但这恰恰也是它值得研究的地方: 这个项目试图把“AI coding agent 网关”做成一个相对独立的产品层，而不是某个单一 agent 的附属插件。

小结

hrygo/hotplex 不是另一个“会聊天的 agent demo”，而是更偏基础设施的一层: 用统一 WebSocket 协议、可插拔 worker、多入口接入、定时任务、管理界面和运维能力，把 AI coding agent 包成一个更容易交付和管理的系统。

如果你最近正在思考“怎么把终端里的 agent 变成团队里可访问的服务”，HotPlex 很值得放进观察列表。它不一定是最终答案，但它把问题拆解得足够完整，已经能给很多内部工具团队提供参考。