用 6 张图看懂 lark-channel-bridge开源项目

`lark-channel-bridge` 的核心思想很简单：它不是另一个云端 Agent，而是一座把飞书 / Lark 聊天入口接到你本机 Coding Agent 的桥。飞书负责收发消息，本地 bridge 负责调度、排队、权限和会话，本机的 Claude Code 或 Codex CLI 才是真正执行代码任务的一方。

这篇只讲架构和思想，不先进入具体代码细节。适合想快速判断“这个项目解决什么问题、为什么这样设计、我是否需要它”的读者。

https://github.com/zarazhangrui/lark-coding-agent-bridge

1. 这是什么：把聊天接到本机 CLI

这张图先纠正一个常见误解：项目本身不是云端 Agent，而是本机桥接进程。用户在飞书里发需求，bridge 接住消息，再启动本机 Claude Code 或 Codex CLI 去看项目、改代码、跑工具，结果再回到飞书。它的价值不是替代 Agent，而是把熟悉的聊天入口变成远程控制本机开发环境的通道。

2. 主运行链路：先过闸门再启动进程

一条普通消息不会直接冲进 CLI。bridge 会先收消息，合并短时间内的连续输入，再检查访问权限、工作目录、附件策略和权限模式。只有这些条件通过，才会真正启动本机 agent 进程；不通过就给出拒绝或提示。这说明项目的主链路不是“转发消息”这么简单，而是“聊天输入 -> 运行策略 -> 本地执行 -> 结果回传”。

3. 会话和上下文：每个场景有自己的记忆

项目把私聊、群话题、文档评论都当成不同的上下文范围。每个范围会绑定自己的工作目录和会话记录，Claude 用 session 续聊，Codex 用 thread 续聊。这样不同项目、不同话题不会互相串上下文。对用户来说，这意味着你可以在不同聊天场景里持续推进不同任务，而不用每次重新解释全部背景。

4. 队列和控制命令：普通消息合并，命令快跑

bridge 有一个按上下文分组的静默窗口，用来把连续发来的消息合成一轮任务。运行中再来的普通消息会排到下一轮，避免同一个聊天里同时启动多个互相打架的 agent。但 `/stop`、`/cd`、`/new` 这类命令会绕过普通队列，及时改变当前运行。这是项目体验里很重要的一点：普通输入要稳，控制动作要快。

5. 权限和工作目录：边界先收窄

这个项目很在意“谁能让本机 agent 干活”。默认只有 app 创建者可用，管理员和群白名单可以扩展访问。运行前还会检查工作目录，拒绝 home 根目录、系统目录、临时目录这类过宽范围，再映射到 Claude 或 Codex 的权限模式。它不是把安全问题全交给 CLI，而是在聊天入口和本机执行入口之间先做一层实用边界。

6. 飞书卡片回显：事件流收敛成一张卡

本机 CLI 输出的是文本、思考、工具调用、错误、完成等事件。bridge 把这些事件归一成运行状态，再渲染成飞书卡片或 markdown。用户看到的是一张持续刷新的运行卡，还能在卡片上终止当前任务。也就是说，飞书不是只显示最终答案，而是成为观察本机 Agent 运行过程的窗口。

`lark-channel-bridge` 的架构思想是：把飞书变成本机 Coding Agent 的入口，同时用会话、队列、权限和卡片回显，把远程聊天控制本机开发环境这件事做得可持续、可观察、可管理。