2025 年底以来，“在聊天软件里指挥跑在自己机器上的 AI"成为一个爆发式的品类：OpenClaw 一周冲到 14.5 万 star，cc-connect、Hermes、各类飞书桥接器密集出现。这些项目表面上做的是同一件事（把消息转给 agent、把结果发回聊天），但底层架构选择差异极大，直接决定了各自的能力天花板和维护成本。
先把场景说具体：你在飞书里对机器人说一句「把昨天那个支付 bug 修了」，家里书房的 Mac 上 Claude Code 开始干活，改完把 diff 发回聊天窗口等你确认。所有这类产品做的都是这一件事，分歧只在怎么做。本文以五个代表性项目为样本，把这个品类的技术路线整理成一个光谱，逐一分析各自的机制与得失。
一个光谱、三个问题
五条路线由三个问题决定：第一个问题划出两大阵营，后两个各自在阵营内部分档。
问题一：agent 能力从哪来？ 是复用现成编码 CLI（Claude Code、Codex）的完整能力，还是自己实现 agent 循环？所谓 agent 循环（业内叫 harness），就是那个不断「调一次模型 → 执行模型要的工具 → 把结果喂回去 → 再调模型」的驾驶程序，agent 的一切行为都由它驱动。复用现成 CLI 的是"桥接派”，自己写循环的是"重建派"。
问题二（桥接派内部）：CLI 进程怎么驻留？ 是保留完整交互式终端（CLI 以为自己面对真人，界面、审批框一样不少），还是走 headless 模式（无界面，CLI 变成一条只收发结构化数据的管道），还是每轮对话起一个用完即扔的一次性进程？
问题三（重建派内部）：harness 谁来写？ 是内嵌一个第三方开源 harness，还是从模型 API 开始完全自研？
按"复用现成 agent 的程度"从高到低排列，得到五档：
| # | 路线 | 代表项目 | 一句话机制 |
|---|---|---|---|
| 1 | tmux/PTY 桥接常驻交互进程 | botmux | 完整 CLI 跑在 tmux 里，IM 与终端双入口 |
| 2 | headless 常驻双向流 | cc-connect | stream-json 双向协议驱动常驻 CLI 进程 |
| 3 | headless 单发进程 | lark-channel-bridge | 每轮消息起一次 claude -p，靠 --resume 续上下文 |
| 4 | 内嵌第三方开源 harness | OpenClaw（引擎为 Pi） | 把开源 agent 循环当库用，自建上层平台 |
| 5 | 完全自研 harness | Hermes（Nous Research） | 自写 agent 循环，直调原始模型 API |
下面逐档展开。
路线一：tmux/PTY 桥接常驻交互进程 —— botmux
机制。tmux 是让终端会话脱离窗口、在后台长期存活的老牌工具（窗口关了会话还在跑）。botmux 把完整的、可交互的 Claude Code CLI 进程养在 tmux 会话里长期驻留。IM 消息注入 tmux 会话，输出解析后渲染成飞书卡片；同一个进程同时对人开放——可以终端直连、可以开 Web 终端旁观，三端（飞书/终端/Web）看到的是同一个会话。每个话题一个会话，配合 resume 与按角色分桶的记忆系统。
Pros
- CLI 能力零损耗：skills、hooks、subagent、checkpoint、交互式审批，CLI 有什么就有什么，CLI 升级零适配自动受益
- 唯一保留"人可以随时接管"的路线：出问题直接 attach 进终端操作，agent 干活过程可旁观
- 常驻进程支撑高级形态：多 bot 协作编排、DAG workflow、角色系统都建立在"会话是活的"之上
Cons
- 架构最重：依赖 tmux，进程常驻吃资源，会话生命周期管理复杂
- 输出解析走终端渲染层，对 CLI 界面变化敏感，解析层需要持续维护
- 深度绑定单一 IM（飞书），跨平台要重做接入层
路线二：headless 常驻双向流 —— cc-connect
机制。Go 编写的通用桥。对 Claude Code 的适配器用 stream-json 模式启动 CLI：进程不画界面，改在标准输入输出上收发一行一条的 JSON 消息，双向长连不断开。这正是官方 Agent SDK 底层用的同一条协议，只是不经 SDK 库、自己直接实现。中途的权限审批通过 stdio 代理转发到聊天里让用户点按钮。支持 10+ 种 agent（含 ACP 协议接入）和 13 个 IM 平台。
Pros
- CLI 能力基本全保：plugins、系统提示词、会话存储都是 CLI 自己的，且中途审批可以转发到 IM——这是它与路线三的关键差异
- 结构化 JSON 输出，解析稳定，不受终端 UI 变化影响
- 通用性最好：多 agent 可插拔、多平台，Go 单二进制部署极简；支持 OS 级用户隔离
Cons
- 没有终端：交互式 TUI、终端直连、旁观均不可能，输出全靠自己重新渲染成 IM 消息
- 只暴露 headless 协议开放的能力，CLI 仅在交互界面提供的特性无法触达
- 追求平台广度，单一平台的深度集成（如飞书云文档、多维表格生态）有限
路线三：headless 单发进程 —— lark-channel-bridge
机制。TypeScript 编写的飞书专用桥。每收到一条消息，spawn 一次 claude -p --output-format stream-json --resume <sessionId>，进程输出完即退出，上下文完全靠 Claude Code 自己的 session 存储与 --resume 接续。注意它没有 --input-format stream-json——进程存活期内没有双向通道。权限走预设三档（full/workspace/read-only 映射到 bypassPermissions/acceptEdits/plan）。
Pros
- 最简单、最好维护的架构：无常驻进程、无生命周期管理，天然无状态，跨 Win/mac/Linux
- 安装体验出色：扫码绑定飞书应用即用
- 有几个巧思：云文档评论区应答（在文档评论里@机器人干活）、每话题独立会话、profile 多开
Cons
- 审批只能预设：没有
--permission-prompt-tool，agent 干到一半需要授权时无法把审批推到飞书，要么提前放权（风险）要么直接卡死（体验） - 无常驻态导致天花板低：终端直连、任务旁观、中途插话引导、多 bot 编排在结构上都做不了
- 每轮冷启动进程，长对话下延迟与开销累积
路线四：内嵌第三方开源 harness —— OpenClaw（Pi 引擎）
机制。OpenClaw 不桥接任何编码 CLI，它的 agent 循环来自 Pi，即 Mario Zechner 的极简开源 harness（4 个内置工具 read/bash/edit/write，约 1000 token 系统提示词，“bash is all you need"哲学）。OpenClaw 把 Pi 当引擎库内嵌，在其上建平台层：20+ IM 接入、ClawHub 技能市场、语音唤醒、iOS/Android 节点、浏览器与设备操控、Docker/SSH 分级沙盒。
Pros
- 定位根本不同：不是"遥控编码 agent"而是通用个人 agent，能做的事远超写代码（管邮件、操控设备、跨端 Canvas）
- harness 层不用自己长期背：Pi 独立演进（7 万+ star、每日提交），OpenClaw 吃社区红利，还能按需深改
- 极简 harness 反而是优点：行为可预测、token 开销小、好审计
Cons
- Claude Code 级别的工程能力要在平台层重造：subagent、checkpoint、复杂权限、代码库级工作流，Pi 本体都没有
- 无法复用用户已有的 CLI 生态：你在 Claude Code 里积累的 skills/hooks/配置带不过去
- 平台面极大（设备、语音、20+ IM），安全面与运维面同步放大；单用户主会话默认全主机权限，需要认真配沙盒
路线五：完全自研 harness —— Hermes（Nous Research）
机制。重建派的极端形态：连第三方 harness 都不用，自己实现完整 agent 循环（model call → tool dispatch → result append → repeat），通过一层抹平各厂商 API 差异的转接适配器（transport adapter）直接对接多家原始 API——Anthropic Messages、chat-completions、Codex Responses、Bedrock。14+ IM 平台共享统一会话与记忆：Telegram 开始的任务可以在飞书接着聊。独有特性是自进化技能循环——agent 在日常使用中自己创建、修改、优化技能。
Pros
- 全栈可控：loop 本身的行为都能定义，“自进化技能"这种要改 harness 内核的特性只有这条路线做得出来
- 模型中立：不绑任何厂商 CLI，多供应商可插拔，规避单一依赖
- 统一记忆与跨平台会话续接是架构级设计，不是补丁
Cons
- 成本最高的路线：Claude Code 三年积累的每一项能力，等价物都要自己造、自己维护
- 模型厂商的 CLI 迭代速度（skills/hooks/subagent/checkpoint 层出不穷）对它是持续的军备竞赛压力
- 中立性有代价：直调原始 API 意味着享受不到厂商在自家 CLI 里做的隐性优化（缓存策略、上下文管理等），要自己重新发明
能力对比总表
| 能力 | botmux | cc-connect | lark-channel-bridge | OpenClaw | Hermes |
|---|---|---|---|---|---|
| CLI 能力继承 | 全量 | 基本全量 | 基本全量 | 无（Pi 自带） | 无（自研） |
| CLI 升级自动受益 | ✅ | ✅ 大部分 | ✅ 大部分 | ❌ | ❌ |
| 终端直连/旁观 | ✅ 独有 | ❌ | ❌ | ❌ | ❌ |
| 中途审批推到 IM | ✅ | ✅ | ❌ 仅预设 | 自有机制 | 自有机制 |
| 多 agent/CLI 支持 | 6+ | 10+ | 2 | 单引擎 | 多模型 API |
| IM 平台 | 飞书（深） | 13 | 飞书（深） | 20+ | 14+ |
| 多 bot 协作编排 | ✅ 深度 | 群内多 bot | profile 多开 | 多 agent 路由 | 子 agent 委派 |
| 沙盒/隔离 | 文件白名单三档 | OS 用户隔离 | 目录校验 | Docker/SSH 分级 | 自有 |
| 架构复杂度 | 高 | 中 | 低 | 高 | 最高 |
| 维护成本承担方 | 解析层自己背 | 协议层稳定 | 几乎不背 | harness 社区背 | 全部自己背 |
选型建议
先交代一个第一手事实：前四条路线，笔者已在生产环境并行使用数月——两台云服务器加五台 Mac Mini，它们至今仍在不知疲倦地工作。在笔者的工作场景（深度飞书协作）下，botmux 的份额在逐渐上升，有取代其他三种的趋势。这个场景恰好是路线一的主场，趋势未必适用于所有人，但下面的建议至少不是纸上谈兵。
- 团队深度用飞书 + 需要多 bot 分工协作、角色化、知识沉淀、人随时可接管 → 路线一（botmux）。终端直连和常驻会话是刚需时没有替代。
- 多平台、多种 coding agent 混用、要求部署简单 → 路线二（cc-connect）。通用桥里的能力/复杂度平衡点，审批转发保住了安全底线。
- 个人轻量使用，只想在飞书里随手指挥一下 Claude Code → 路线三（lark-channel-bridge）。十分钟上手，接受"权限要预设"即可。
- 想要的是数字生活全能助理，编码只是其中一项 → 路线四（OpenClaw）。注意认真配置沙盒。
- 组织级自建 agent 基础设施、强模型中立诉求、有长期投入的工程团队 → 路线五（Hermes）。
趋势判断
这五条路线背后是同一个赌注的两面。桥接派（1–3）赌的是：厂商 CLI 的能力迭代速度是护城河——Claude Code 的 skills/hooks/subagent/checkpoint 一直在高速演进，桥接者零成本坐享。重建派（4–5）赌的是：harness 会商品化——agent 循环本身没有秘密（Pi 用 4 个工具就证明了这点），长期价值在上层编排、记忆与生态。
短期看桥接派的赌注更稳：CLI 迭代仍是碾压级的，重建派每天都在追赶。但有两个变量值得关注：一是 ACP（Agent Client Protocol）这类标准若普及，桥接的形态会从"解析进程输出"升级为"标准协议对话”，路线一二三的差异会被压缩；二是若极简 harness + 自进化技能被验证够用，重建派的追赶成本会骤降。
对做桥接的团队，一个务实的结论是：路线选择不是排他的。cc-connect 已经同时内置 stream-json 主路线和 tmux 兜底适配器；桥接派完全可以按场景混合多档形态——常驻交互会话干重活，单发进程跑定时任务，这可能才是终局形态。
基于各项目公开源码与文档的分析，其中前四条路线均经笔者数月生产环境并行使用验证。写于 2026 年 7 月。项目版本快照：cc-connect（chenhg5/cc-connect，Go）、lark-channel-bridge 0.1.33（zarazhangrui/lark-coding-agent-bridge，TS）、OpenClaw（steipete/openclaw，引擎 Pi by badlogic）、Hermes Agent（Nous Research，2026 年 2 月开源）。