借着微信 ClawBot 接入 Coding Agent 的机会，聊聊最近在开发的这个项目

项目一览

桌面端

微信接入

项目地址：VibeAround

小红书视频：微信直连 Coding Agent

背景 TL;DR

最初是为了解决自己的需求——不方便开电脑的时候，可以用手机指挥 Coding Agent 干活。

时至今日，Claude Code 、Gemini CLI 、Codex 这种 Coding Agent 已经承担了我非常大的一部分代码工作。内心对这些 AI 工具的态度，早已从每生成一段代码就必须读一遍的怀疑态度，到现在只要能跑通测试就不再看的放任。

只不过很多时候，还是必须得守在电脑旁边去校验 AI 的结果，并布置新的任务。尤其春节期间走亲访友时，不能把电脑带在身边，但心里却始终惦记着不能让 AI 牛马闲着。

于是乎，能否远程控制 Coding Agent 就成为了刚需，便有了这个项目。

自己在立项之初的规划有这么几条：

• 足够轻快，不需要安装大量依赖，开箱即用
• 尽量保留原生 CLI 体验，不考虑远程桌面因为太笨重，不考虑代理服务因为配置操作复杂
• 提供 Web Chat 能力，并接入 IM BOT

最后选定的技术路线是 bun 作为 bundler ，Rust 作为开发语言，Tauri 打包 Axum Web 服务，UI 用 AI 最擅长的 React+Shadcn+Tailwindcss 。

应用架构

先上图

+--------------------------------------------------------------+
|                         Usage Layer                          |
|--------------------------------------------------------------|
|  Mobile / PC Browser          |  WeChat / Feishu / Telegram  |
+-------------------------------+------------------------------+
                |                                  |
                v                                  v
+--------------------------------------------------------------+
|                        Access Layer                          |
|--------------------------------------------------------------|
|  Tunnel                       |  Plugins                     |
|  Cloudflare / ngrok /         |  Telegram / Feishu /         |
|  localtunnel                  |  WeChat                      |
+-------------------------------+------------------------------+
                |                                  |
                v                                  v
+--------------------------------------------------------------+
|                         Entry Layer                          |
|--------------------------------------------------------------|
|  Web Server                   |  Channel Manager             |
|                               |            |                 |
|  +-------------------------+  |            v                 |
|  |  Web Interaction Block  |  |  Session Hub                 |
|  |-------------------------|  |                              |
|  |  xterm.js               |  |                              |
|  |  Web Channel            |  |                              |
|  +-------------------------+  |                              |
+-------------------------------+------------------------------+
                |                                  |
                v                                  v
+--------------------------------------------------------------+
|                      Management Layer                        |
|--------------------------------------------------------------|
|  PTY Manager                  |  Agent Manager               |
+-------------------------------+------------------------------+
                |                                  |
                v                                  v
+--------------------------------------------------------------+
|                      Execution Layer                         |
|--------------------------------------------------------------|
|  tmux Persistence             |  ACP SDK                     |
|                               |------------------------------|
|                               |  Claude Code                 |
|                               |  Gemini CLI                  |
|                               |  Codex                       |
|                               |  OpenCode                    |
+--------------------------------------------------------------+

具体模块 TL;DR

1. Usage Layer：使用层

最顶层是用户真正接触到的使用层，也就是各种实际使用 VibeAround 的终端。

这里主要分成两类：

• Mobile / PC Browser：通过手机或电脑浏览器进入 Web 界面
• WeChat / Feishu / Telegram：通过不同 IM 平台直接和 agent 交互

这层代表的是“用户从哪里使用系统”。

2. Access Layer：接入层

使用层之下，是把外部访问真正接进本地系统的接入层，这里主要包括两类能力：

• Tunnel：通过 Cloudflare 、ngrok 、localtunnel ，把本地运行的 Web 服务暴露给外部访问
• Plugins：负责接入 Telegram 、飞书、微信这类 IM 平台，把不同 channel 的消息和鉴权方式带进系统。

重点说一下 Plugins，最开始我直接用 Rust 去写 IM 接入层，但这样做的问题很明显：一方面 Rust 接入平台的现成生态并不丰富，另一方面宿主会变得越来越臃肿。后来受 OpenClaw 的启发，我改成了让 plugin 作为独立进程运行，通过 stdio 与 Channel Manager 交换 JSON-RPC 消息。这样宿主只负责统一调度和协议边界，具体平台接入则可以交给更适合对应生态的实现去完成。

3. Entry Layer：统一入口层，Management Layer：管理层，Execution Layer：执行层

这三层可以一起看，它们描述了整个系统里的两条并行链路。

terminal runtime 链路

xterm.js -> PTY Manager -> tmux

Web 前端用了 xterm.js 来提供终端界面的渲染和交互，PTY Manager 负责提供伪终端运行环境并承接 CLI 进程，而 tmux 则负责 session persistence ，让终端状态和上下文可以持续存在。这样用户在 Web 里拿到的不是一个“像终端”的壳，而是真实的命令行操作能力。

agent runtime 链路

Channel Manager -> Session Hub -> Agent Manager -> ACP SDK -> Coding Agent

Channel Manager 统一管理所有 channel 的接入和消息分发，包括 Web chat 和 IM plugins 。

Session Hub 负责把不同入口上的上下文、生命周期事件和 session 语义统一起来。

Agent Manager 负责管理和调度 Coding Agent 的生命周期；再往下，我为不同 Coding Agent 做了一层 ACP SDK 适配，用来尽量把它们收敛到同一套交互语义里。

我选择 ACP 的主要原因，是希望能用尽量统一的方式去应对不同 Coding Agent ，便于做统一管理，而不需要针对每个 agent 单独维护一套消息流和调度逻辑。不过目前看起来，这样做的代价也很明确：某些 agent 的差异化能力不一定能被完整暴露出来，多少会牺牲一部分原生体验，未来可能会把 Coding Agent SDK 也插件化，以此实现他们的原生能力。

4. 这套架构想解决什么问题

如果只看表面，这个项目像是在做“把微信或 Web 接到 Coding Agent 上”。

但如果按这套分层来看，我更想解决的其实是另一个问题：

当 Coding Agent 不再只存在于本地 terminal 里，而要同时服务浏览器和多个 IM 入口时，中间应该有什么样的一层宿主系统？

所以这套架构本质上是在做三件事：

1. 把不同使用入口接进来：例如手机 / PC 浏览器、Telegram 、飞书、微信。
2. 把 Web 、IM 、terminal 几种交互能力拆开建模：入口统一，session 统一，终端能力独立。
3. 把不同 Coding Agent 统一调度起来：通过 Agent Manager 和配置层，把 Claude Code 、Gemini CLI 、Codex 、OpenCode 接到同一个宿主体系里。

如果要再压缩成一句话，那就是：

VibeAround 想做的不是某一个 agent 的外壳，而是一层连接不同入口、保留原生 CLI 能力、并能统一调度多种 Coding Agent 的宿主系统。

写在最后

目前这个项目还刚起步，大家对这个方向有兴趣的话，欢迎直接试用看看。无论是对功能设计、具体实现，还是整体架构有什么想法，非常欢迎大家多多提供意见和思路；如果觉得项目还有点意思，也欢迎去 GitHub 点个 star 支持一下。