我开发的 HAPI 开源了：随时随地访问 Claude CodeCodexGemini
- 内容介绍
- 文章标签
- 相关推荐
经过 9 天的 Agentic Coding，我基于 Happy 大幅魔改的 Coding Agent 远程访问应用：hapi（"哈皮"音译）正式开源了：GitHub - tiann/hapi: App for agentic coding - access coding agent anywhere
核心功能：
- 多 Agent 后端：支持 Claude Code、Codex、Gemini，通过 ACP 协议可拓展更多 Agent
- Claude Code / Codex 支持本地/远程无缝切换；支持 AskUserQuestion 等工具交互
- Telegram 集成：权限请求推送，Mini App 全功能操作，快捷按钮一键审批
- 实时多端同步：乐观并发控制，PWA 离线支持
通过 hapi，你可以随时随地访问后台运行的 Agent：手机上查看工作进度，随手完成权限审批，直接发送指令交互。Agent 干活的时候你可以去喝茶、散步、爬山；需要你介入时会收到 Telegram 通知，处理完继续 high，彻底从电脑面前解放出来。
极简部署：单文件二进制，cli/server/web all-in-one。 时间仓促，难免会有一些问题，欢迎一起共建~
为什么要重复造轮子？
Happy 已经很优秀了，我为什么还要重新造轮子？技术层面的根本原因在于：Happy 的架构基因与我心中的产品形态存在结构性冲突。我曾经给 Happy 提过 PR、修过 Bug，但那个过程让我意识到，我们在往两个方向走。
Happy 的设计是 “云端优先”
CLI(内网) ↔ Server{数据库｜对象存储}(公网) ↔ App
Happy 的设计预设是用户使用 Happy Cloud。为了解决把数据放在别人服务器上的信任问题，它引入了极度复杂的端对端加密（E2EE）+ 数据库加密。
- 公网依赖：大家都挤在公共服务器上，WebSocket 长连接开销巨大，导致 Happy Cloud 经常挂掉。
- 私有部署困难：如果你想 Self-Host，这套为公网设计的加密体系就变成了累赘——明明数据在自己手里，却还要跑一套复杂的加密流程，典型的“大炮打蚊子”，部署起来也极其痛苦。
HAPI 的解法是“本地优先”
HAPI 的逻辑非常简单：CLI + Server（内网） ↔ Relay Server ↔ App。
既然 CLI 是常驻后台的，为什么不直接把 Server 和数据跟它放在一起？
- 数据在自己手里：数据存在本地，通过 Cloudflare Tunnel 做中转，既解决了外网访问，又无需担心数据泄露。
- 架构极简：不需要服务海量用户的复杂数据库，一个 SQLite 就能搞定一切。
- 一行代码部署：因为架构简单，我直接用 Bun 把 CLI、App 和 Server 打包成了一个二进制文件。不需要 Docker，不需要配置数据库，运行 npx @twsxtd/hapi 就能跑。
架构设计的出发点不同，导致了最终实现的云泥之别。
1947×2048 124 KB
4947×2048 111 KB
3947×2048 62.1 KB
2947×2048 137 KB
--【壹】--：
支持老，后面有机会试试看
--【贰】--：
支持大佬呀！
--【叁】--：
介绍有点少，我真想当甩手掌柜呃
--【肆】--：
太强了大佬
--【伍】--：
感谢佬的分享~有时会试试
--【陆】--：
太厉害了， 支持
--【柒】--：
领导看不到员工，总会觉得员工在摸鱼
--【捌】--：
佬后面会更新把服务器作为中转的模式吗
--【玖】--：
强呀，感谢大佬
--【拾】--：
前排支持
--【拾壹】--：
好耶，这下在外面不用非得服务器写代码了
--【拾贰】--：
厉害了支持
--【拾叁】--：
可以容器部署嘛，多线程开搞
--【拾肆】--：
我也自己弄了一个，我主要是通关自己写网关挟持协议，实现一个网站管理多台电脑上的cli
image987×435 29.9 KB
--【拾伍】--：
前排支持
--【拾陆】--：
前排
研究下，看以后能不能不在工位上班
--【拾柒】--：
佬友貌似在x上首发的？昨晚还留言了
--【拾捌】--：
晚点试试。之前一直想试试happy,一直没有什么合适的项目做实验。
--【拾玖】--：
赶紧向weishu靠拢，感谢多年对android玩机的支持，在X也看到你发的帖子了
经过 9 天的 Agentic Coding，我基于 Happy 大幅魔改的 Coding Agent 远程访问应用：hapi（"哈皮"音译）正式开源了：GitHub - tiann/hapi: App for agentic coding - access coding agent anywhere
核心功能：
- 多 Agent 后端：支持 Claude Code、Codex、Gemini，通过 ACP 协议可拓展更多 Agent
- Claude Code / Codex 支持本地/远程无缝切换；支持 AskUserQuestion 等工具交互
- Telegram 集成：权限请求推送，Mini App 全功能操作，快捷按钮一键审批
- 实时多端同步：乐观并发控制，PWA 离线支持
通过 hapi，你可以随时随地访问后台运行的 Agent：手机上查看工作进度，随手完成权限审批，直接发送指令交互。Agent 干活的时候你可以去喝茶、散步、爬山；需要你介入时会收到 Telegram 通知，处理完继续 high，彻底从电脑面前解放出来。
极简部署：单文件二进制，cli/server/web all-in-one。 时间仓促，难免会有一些问题，欢迎一起共建~
为什么要重复造轮子？
Happy 已经很优秀了，我为什么还要重新造轮子？技术层面的根本原因在于：Happy 的架构基因与我心中的产品形态存在结构性冲突。我曾经给 Happy 提过 PR、修过 Bug，但那个过程让我意识到，我们在往两个方向走。
Happy 的设计是 “云端优先”
CLI(内网) ↔ Server{数据库｜对象存储}(公网) ↔ App
Happy 的设计预设是用户使用 Happy Cloud。为了解决把数据放在别人服务器上的信任问题，它引入了极度复杂的端对端加密（E2EE）+ 数据库加密。
- 公网依赖：大家都挤在公共服务器上，WebSocket 长连接开销巨大，导致 Happy Cloud 经常挂掉。
- 私有部署困难：如果你想 Self-Host，这套为公网设计的加密体系就变成了累赘——明明数据在自己手里，却还要跑一套复杂的加密流程，典型的“大炮打蚊子”，部署起来也极其痛苦。
HAPI 的解法是“本地优先”
HAPI 的逻辑非常简单：CLI + Server（内网） ↔ Relay Server ↔ App。
既然 CLI 是常驻后台的，为什么不直接把 Server 和数据跟它放在一起？
- 数据在自己手里：数据存在本地，通过 Cloudflare Tunnel 做中转，既解决了外网访问，又无需担心数据泄露。
- 架构极简：不需要服务海量用户的复杂数据库，一个 SQLite 就能搞定一切。
- 一行代码部署：因为架构简单，我直接用 Bun 把 CLI、App 和 Server 打包成了一个二进制文件。不需要 Docker，不需要配置数据库，运行 npx @twsxtd/hapi 就能跑。
架构设计的出发点不同，导致了最终实现的云泥之别。
1947×2048 124 KB
4947×2048 111 KB
3947×2048 62.1 KB
2947×2048 137 KB
--【壹】--：
支持老，后面有机会试试看
--【贰】--：
支持大佬呀！
--【叁】--：
介绍有点少，我真想当甩手掌柜呃
--【肆】--：
太强了大佬
--【伍】--：
感谢佬的分享~有时会试试
--【陆】--：
太厉害了， 支持
--【柒】--：
领导看不到员工，总会觉得员工在摸鱼
--【捌】--：
佬后面会更新把服务器作为中转的模式吗
--【玖】--：
强呀，感谢大佬
--【拾】--：
前排支持
--【拾壹】--：
好耶，这下在外面不用非得服务器写代码了
--【拾贰】--：
厉害了支持
--【拾叁】--：
可以容器部署嘛，多线程开搞
--【拾肆】--：
我也自己弄了一个，我主要是通关自己写网关挟持协议，实现一个网站管理多台电脑上的cli
image987×435 29.9 KB
--【拾伍】--：
前排支持
--【拾陆】--：
前排
研究下，看以后能不能不在工位上班
--【拾柒】--：
佬友貌似在x上首发的？昨晚还留言了
--【拾捌】--：
晚点试试。之前一直想试试happy,一直没有什么合适的项目做实验。
--【拾玖】--：
赶紧向weishu靠拢，感谢多年对android玩机的支持，在X也看到你发的帖子了