结论：没有发现“高星成熟且直接解决 agy ↔ Telegram”的项目；但有 3 类可借鉴架构。最值得借鉴的是 agy-bridge 的 quota/timeout/failover 子进程治理、kurniarahmattt 的 agy --print 会话映射、以及 v4-hub 的 CDP/IDE 驱动与审批按钮代理。
| 项目 | 成熟度 | 适配面 | 关键思路 | 对 TaroCub 的价值 |
|---|---|---|---|---|
| v4-hub/antigravity-telegram-bridge | 低星但方向直接 9 commits, Python | Antigravity IDE + Telegram，不是 agy CLI | CDP WebSocket 控制 Electron IDE：输入注入、DOM 轮询、审批按钮识别、Whisper 语音、smart launcher 强制 remote-debugging-port。 | 强：如果 agy --print 不稳定，可改走 IDE/CDP 控制面；特别适合解决审批/运行按钮和中文按钮识别。 |
| kurniarahmattt/antigravity-telegram | 极简原型 2 commits, Python | agy --print + Telegram | 每个 user/scope 维护 SQLite conversation 映射；通过读取 ~/.gemini/antigravity-cli/cli.log 提取 conversation id；repo 模式加 --add-dir 与 skip permissions。 | 中强：会话映射和 scope 设计可借鉴；但 README 明说无工具流、无中断、无附件、无 token/cost。 |
| daocoding/antigravity-bridge | 概念清晰 Bun/TS | agy live session + WuKongIM/Telegram sample | Dynamic Session Discovery：agy 启动写当前 session id 到状态文件，Bridge 每次消息读取最新 session，POST 到 live session/ConnectRPC。 | 强但需验证接口：比反复起 agy --print 更接近“活会话”；若 ConnectRPC/会话 POST 可用，值得替代当前 print-wrapper。 |
| sshahzaiib/agy-bridge | 工程性最好 Node/MCP | Claude Code → agy MCP，不是 Telegram | 模型路由、可用模型缓存、quota 429 检测、日志解析、进程组 kill、超时、failover、输出截断、session footer。 | 很强：直接借鉴子进程治理，解决 TaroCub 当前 Antigravity 卡死/空输出/429/timeout 不透明问题。 |
| nadimtuhin/antigravity-cli-mcp | MCP 包装层 32 commits, Bun/TS | agy MCP server | 并发限制、timeout、max output、workspace confinement、MCP progress notifications。 | 中：可借鉴 workspace 限制、并发队列、stdout 上限；Telegram 需另接一层。 |
| dasuntheekshanagit/GeminiCLI_Bot | 低星原型 9 commits, Python | agy subprocess + Telegram | agy --continue、实时输出流、inline Approve/Deny、git/OpenSpec 快捷命令。 | 中：可看 live streaming/approval 的交互设计，但成熟度低。 |
| 7Mo7med7/antigravity-telegram | 低星 IDE 自动化 | Antigravity IDE + Telegram + MCP | 任务文件 + auto-trigger daemon + MCP server；Telegram 管项目/截图/审批/artifact。 | 中：适合借鉴“任务队列文件 + MCP 回传”模式，弱化 Telegram 直接控制 CLI 的耦合。 |
| SeemSeam/claude_codex_bridge | 成熟多 Agent 工作台 3k stars, 780 commits | tmux 多 CLI agent，含 agy | 真实 TUI session、tmux pane、可见控制、多 agent 协作、恢复/通信。 | 间接强：不是 Telegram 方案，但证明“保持真实 TUI session + 外部通信”比 print-wrapper 更稳。 |
| 路线 | 优点 | 缺点 | 建议 |
|---|---|---|---|
| A. 继续 agy --print | 实现最简单；当前 TaroCub 已有基础。 | 无中途事件、无真正交互 slash command、无稳定审批、429/空输出/timeout 难处理。 | 短期保留，但引入 agy-bridge 式进程治理：日志监控、429 快速 kill、模型 failover、输出截断、严格 timeout。 |
| B. 驱动 Antigravity IDE/CDP | 能使用 IDE 原生交互能力；可代理审批按钮；更像手机远控桌面会话。 | 依赖 Electron DOM、remote debugging port、页面结构易变；服务器无 GUI 时成本高。 | 作为可选 backend：engineRuntime=antigravity-ide-cdp。适合个人桌面，不适合纯 VPS。 |
| C. live session / DSD / ConnectRPC | 理论上最稳：维持真实 agy 会话，Telegram 消息进入当前会话。 | 需要确认 Antigravity 当前版本是否暴露可用 session POST/ConnectRPC。 | 优先做 spike：复现 daocoding DSD 模式，验证是否能向活会话注入 turn。 |
| D. MCP/任务队列反向回传 | 让 Antigravity 主动通过 MCP/工具回传 Telegram，减少 Telegram 端轮询 stdout。 | 需要改 agent 指令和 MCP 配置，首轮启动仍要解决。 | 中期建议：Telegram 只负责投递任务/审批，进度与 artifact 由 MCP 工具回传。 |
--log-file 日志解析、RESOURCE_EXHAUSTED 检测、进程组 kill、timeout 分级、空输出错误化、模型 cooldown/failover。src/codex/antigravity/ 或 src/antigravity/，包含 model registry、conversation resolver、log parser、process runner。GitHub 上没有一个可以直接替换 TaroCub 的成熟 Antigravity Telegram 项目。最实用的借鉴不是复制某个 Telegram bot，而是组合三类能力：agy-bridge 的进程与 quota 治理、kurniarahmattt 的会话映射、daocoding 的 live session discovery。若要解决“Telegram 多次出现问题”，优先改 backend 稳定性与可观测性，而不是继续在 Telegram command handler 里堆兼容逻辑。