夜雨聆风你躺在沙发上，在飞书里发一句「把昨天那个 bug 修了」。
家里书房的电脑自己动了起来，改完代码，把结果发回你手机。
2025 年底以来，做这件事的工具成了一个爆发式品类：最出圈的 OpenClaw，一周涨了 14.5 万 star。cc-connect、Hermes、各种飞书桥接器也在密集冒头。
它们表面上做的是同一件事：把你的消息转给 AI，把结果发回聊天。但拆开看，底层是五条完全不同的技术路线，能力天花板差得很远。
先分清两大阵营
五条路线，其实由三个问题决定。
第一个问题：AI 的干活能力从哪来？是直接复用现成的编码工具（Claude Code、Codex 这类命令行程序，下文叫 CLI），还是自己从头实现一套？
这里得先解释一个词：agent 循环，业内叫 harness。它是那个不断「调一次模型 → 执行模型要的工具 → 把结果喂回去 → 再调模型」的驾驶程序，AI 干活的一切行为都由它驱动。
复用现成 CLI 的，是桥接派——人家的驾驶程序已经很好了，我只管接消息。
自己写循环的，是重建派——驾驶程序我自己造，不欠任何人的。
第二个问题（桥接派内部）：CLI进程怎么活着？是保留完整的交互式终端，还是无界面纯管道（headless 模式），还是每轮对话起一个用完即扔的进程？
第三个问题（重建派内部）：驾驶程序谁来写？是借一个开源的，还是彻底自研？
按「复用现成能力的程度」从高到低排，正好五档。
路线一：把完整的 CLI 整个搬进聊天（botmux）
做法最直接：把一个完整的、可交互的 Claude Code，养在 tmux 里长期驻留。tmux 是让终端会话脱离窗口、在后台一直活着的老牌工具，窗口关了会话还在跑。
飞书消息注入这个会话，输出解析后渲染成卡片。关键是：同一个进程，人也能直接连进去。
强在哪：CLI 有什么它就有什么，技能、钩子、子任务、检查点，一样不少，CLI 升级零成本跟着受益。而且它是五条路线里唯一保留「人可以随时接管」的——AI 干砸了，你直接进终端接手，全程还能旁观。
弱在哪：架构最重。进程常驻吃资源，输出解析走终端渲染层，CLI 界面一变就得跟着修。而且深度绑定飞书，换平台要重做接入层。
路线二：不要界面，只要管道（cc-connect）
Go 写的通用桥。它让 Claude Code 以无界面模式启动：进程不画界面，改在标准输入输出上收发一行一条的 JSON 消息，双向长连不断开。
这正是官方 Agent SDK 底层用的同一条协议，它只是不经 SDK、自己直接实现。
强在哪：结构化数据解析稳定，不怕界面改版。AI 干到一半需要授权时，审批请求能转发到聊天里让你点按钮——这是它和路线三的关键差别。通用性也最好：十多种 agent 可插拔、13 个聊天平台、单个二进制文件就能部署。
弱在哪：没有终端。想直连、想旁观、想接管，都不可能。CLI 只在交互界面提供的功能，它也摸不到。
路线三：一条消息，一个进程（lark-channel-bridge）
飞书专用桥。每收到一条消息，起一次 Claude Code 进程，输出完就退出。上下文靠 CLI 自己的会话存储来接续。
强在哪：最简单、最好维护。没有常驻进程，没有生命周期管理，天然无状态。安装体验也出色：扫码绑定就能用。还有些巧思，比如在云文档评论区里 @ 机器人干活。
弱在哪：进程活着的时候没有双向通道，AI 干到一半需要授权时，没法把审批推到飞书——要么提前放权（有风险），要么直接卡死（体验差）。权限只能预设三档。终端直连、中途插话、多机器人协作，结构上都做不了。
路线四：借来的引擎，自建的平台（OpenClaw）
从这里开始是重建派。OpenClaw 不桥接任何编码 CLI，它的驾驶程序来自开源项目 Pi：只有读文件、执行命令、编辑、写文件四个内置工具，信奉「一个命令行就够了」的极简哲学。
OpenClaw 把 Pi 当引擎内嵌，在上面盖平台：二十多个聊天平台接入、技能市场、语音唤醒、手机节点、浏览器和设备操控。
强在哪：定位根本不同——不是「遥控写代码」，而是通用个人助理，管邮件、控设备都行。引擎层不用自己长期维护，Pi 社区在演进，它吃红利。极简引擎还带来行为可预测、开销小、好审计。
弱在哪：Claude Code 那个级别的工程能力，得在平台层重造。你在 CLI 里积累的技能和配置带不过去。平台铺得太大，安全面和运维面也跟着放大，默认还是全主机权限，沙盒要认真配。
路线五：从零自己造（Hermes）
重建派的极端形态：连开源引擎都不借，自己实现完整的驾驶循环，通过一层抹平各厂商差异的转接适配器，直连 Anthropic、OpenAI 等多家原始接口。
14 个聊天平台共享同一份记忆：Telegram 上开始的任务，可以在飞书接着聊。还有一个独有特性——AI 在日常使用中自己创建、修改、优化技能。
强在哪：全栈可控，连循环本身的行为都能定义。「自我进化技能」这种要改引擎内核的特性，只有这条路做得出来。不绑任何厂商，多供应商随时切换。
弱在哪：成本最高。Claude Code 三年攒下的每一项能力，等价物都要自己造、自己养。厂商 CLI 的迭代速度对它是持续的军备竞赛。
一眼版对比
botmux：能力最全 + 人能接管，但架构最重、只深耕飞书
cc-connect：能力与简单的平衡点，审批不失守，但没有终端
lark-channel-bridge：十分钟上手最省心，但授权只能预设、天花板低
OpenClaw：全能个人助理，编码只是其中一项，沙盒要自己把好关
Hermes：组织级自建、彻底中立，代价是所有轮子自己造
怎么选
先交代一个第一手事实：前四条路线，我已经并行用了好几个月。两台云服务器，五台 Mac Mini，它们到今天还在不知疲倦地干活。
在我的场景下，botmux 的份额在逐渐上升，有取代其他三种的趋势。
我的场景是深度飞书协作，正好是它的主场，这个趋势不一定适用于你。但下面这些建议，至少都是用出来的，不是纸上谈兵。
团队深度用飞书，要多机器人分工、知识沉淀、人随时接管 → botmux。常驻会话和终端直连是刚需时，没有替代。
多平台、多种编码 agent 混用、部署要简单 → cc-connect。
个人轻量用，只想在飞书里随手指挥一下 → lark-channel-bridge。接受权限要预设就行。
想要的是数字生活全能助理 → OpenClaw。记得认真配沙盒。
组织级自建基础设施、强中立诉求、有长期工程投入 → Hermes。
两种赌注
五条路线背后，其实是同一个赌注的两面。
桥接派赌的是：厂商 CLI 的迭代速度就是护城河。Claude Code 的新能力一直在高速上新，桥接者零成本坐享。
重建派赌的是：驾驶程序终将不值钱。agent 循环本身没有秘密，Pi 用四个工具就证明了这点，长期价值在上层的编排、记忆与生态。
短期看，桥接派的赌注更稳：CLI 迭代仍是碾压级的，重建派每天都在追赶。
但路线选择并不排他。cc-connect 已经同时内置了管道主路线和终端兜底模式。常驻会话干重活，一次性进程跑定时任务，按场景混着用——这可能才是终局形态。
基于各项目公开源码与文档的分析，写于 2026 年 7 月。涉及项目：botmux、cc-connect、lark-channel-bridge、OpenClaw（引擎 Pi）、Hermes Agent（Nous Research）。完整技术版（含参数细节与能力对比总表）见博客原文。