乐于分享
好东西不私藏
夜雨聆风 > > 办公文件 > 卸载龙虾,把本地AI编程助手 Claude Code、Gemini、Codex 通通装进飞书和企业微信

卸载龙虾,把本地AI编程助手 Claude Code、Gemini、Codex 通通装进飞书和企业微信

当前时间： 2026-03-16 13:05:52 分类：办公文件 评论(0)
卸载龙虾,把本地AI编程助手 Claude Code、Gemini、Codex 通通装进飞书和企业微信

公司下了通知，禁止任何接入办公网的电脑安装龙虾，个人电脑也不行

我一直比较谨慎，这玩意权限实在太大，项目也不过半年，几十万行代码都是 AI 生成，甚至连review 都是 AI，马斯克这个 meme 很好的说明了普通人接入 OpenClaw 的危险

大神 Karpathy 也质疑，把自己的私人数据交给有 40 万行 “凭感觉编写” 的庞然大物一点也不诱人⚠️

工信部也发布OpenClaw安全风险预警：配置不当极易引发网络攻击和信息泄露

后来我们公司也要求卸载龙虾，不得不说，上门装龙虾这一虾三吃，真是好生意啊

但是需求一直有的，较早之前，我基于 OpenCode 的 server 手工搓了一个

我用 Opencode 做了一个 FakeClawBot

介入了 Telegram 和 discord ，大模型用的是 Kimi-K2.5 ，运行一直良好，用它管理家里的电脑，处理异常，很方便

但是手搓的能力还是有限，OpenCode 还是不如 Claude Code

周末我又折腾了一下，把一个更强大的工具 cc-connect 对接了自己的 Claude Code、Codex，接入到了飞书和 Telegram

它就是 cc-connect，完成度明显更高，平台支持也更完整

cc-connect 官方架构图

先给结论

如果你已经在用 Codex、Claude Code、Gemini CLI、OpenCode 这类工具，又希望：

  • 出门时也能用手机给本地 Agent 发任务
  • 在飞书、Telegram、企业微信里管理会话和权限
  • 把定时任务、Provider 切换、多项目管理都搬进聊天界面

那 cc-connect 很值得认真研究

它吸引我的地方有三层：

第一层是上手快。飞书走 WebSocket 长连接，Telegram 走 Long Polling，企业微信也给了 WebSocket 智能机器人方案，很多场景都不用公网 IP。

第二层是能力完整。它接进来的，是你本地 Agent 的原生能力：会话、权限模式、模型切换、Provider、Cron、语音、Bridge 扩展都在。

第三层是后劲足。我继续往下看 usage、config.example.toml、management-api、bridge-protocol 和设计文档之后，明显能感觉到这个项目在朝“Agent 运行时平台”走。

真正重要的部分：先把第一条消息跑通

我建议你按下面这个顺序来：

  1. 安装 cc-connect
  2. 确认本地 Agent 本身能在终端独立工作
  3. 写一个最小可用 config.toml
  4. 先用前台模式跑通
  5. 聊天里发 /new
  6. 验证没问题再切后台 daemon

官方建议是直接用 Claude Code 来安装

最简单的方式 ： 把这段话发给 Claude Code 或其他 AI 编码 Agent，它会帮你完成整个安装和配置过程：

请参考 https://raw.githubusercontent.com/chenhg5/cc-connect/refs/heads/main/INSTALL.md 帮我安装和配置 cc-connect

第一次接触，感觉还是手工安装会好一些，对这个工具会有更深的了解

第一步：先装好 cc-connect 和本地 Agent

如果你用的是 npm 环境，最省事的安装方式就是：

npm install -g cc-connectnpm install -g @openai/codex

如果你用的是 Claude Code，那就把第二行换成：

npm install -g @anthropic-ai/claude-code

装完以后，先确认命令在不在：

which cc-connectwhich codexcc-connect --versioncodex --version

我这次在 macOS 上的实际路径是：

/opt/homebrew/bin/cc-connect/opt/homebrew/bin/codex

配置文件默认放在：

~/.cc-connect/config.toml

日志默认在：

~/.cc-connect/logs/cc-connect.log

这里有一个前置条件一定要明确：**先让你的本地 Agent 单独跑通。*

比如Claude Codecodex 至少要能在终端正常启动、能访问模型、能进入目标项目目录。否则后面你在飞书或者 Telegram 里看到的“机器人没回复”，很可能压根不是平台问题。

第二步：写一个最小可用的 config.toml

第一次配置时，我建议你先只接一个平台。最容易起步的是 Telegram，国内团队协作更顺手的是飞书。企业微信我建议放到第三步再加。

下面给你一个 Codex + Telegram 的最小配置模板：

language = "zh"[[projects]]name = "my-project"admin_from = "123456789"[projects.agent]type = "codex"[projects.agent.options]work_dir = "/Users/you/Code/my-project"mode = "suggest"[[projects.platforms]]type = "telegram"[projects.platforms.options]token = "1234567890:ABCDEF_your_bot_token"allow_from = "123456789"

如果你想换成 Claude Code，只需要改两处：

[projects.agent]type = "claudecode"[projects.agent.options]work_dir = "/Users/you/Code/my-project"mode = "default"

如果你想让一个项目同时接多个平台，也很简单，继续往下挂多个 [[projects.platforms]] 就行。比如 Telegram 跑通以后，再加一个飞书：

[[projects.platforms]]type = "feishu"[projects.platforms.options]app_id = "cli_xxx"app_secret = "xxx"

第三步：搞懂配置里到底哪些字段必须改

config.toml 里看起来字段很多，真正第一次必须动手的其实就这么几个：

  • name：项目名，自己起，主要用于区分多个项目
  • type：你用的本地 Agent，常见是 codex、claudecode、gemini、opencode
  • work_dir：项目目录的绝对路径，这个一定要写对
  • mode：Agent 权限模式，Codex 常用 suggest，Claude Code 常用 default
  • 平台凭证：Telegram 用 token，飞书用 app_id/app_secret，企业微信按模式不同填写
  • allow_from：谁能和机器人对话
  • admin_from：谁能执行 /shell、/restart、/upgrade 这类高权限命令

这里最容易搞混的是最后两项。

allow_from 放在 平台配置 下面，控制“谁能和 bot 说话”。admin_from 放在 project 级别，控制“谁能碰主机和高权限命令”。

这两个字段建议你一开始就收紧测试阶段可以先写成你自己的用户 ID如果直接写 *，虽然配置最快，安全边界也会立刻放大

第一次配置时，我反而建议你先别动下面这些：

  • provider
  • speech
  • tts
  • bridge
  • management
  • multi-workspace

这些都很强，后面慢慢加完全来得及

先把“能发消息、能收到回复、能看日志”这一条主链路跑通，价值最高。

很多人会问：它能不能直接从 Codex 切到 Gemini

这个问题特别值得单独讲一下，因为很多人第一次看到 /provider、/mode、/bind 这些命令时，很容易把它们理解成同一件事。

先给结论：当前版本的 cc-connect，没有一个通用的运行时命令，让你在同一个 project 里把 codex 直接热切换成 gemini。

你可以先把这四层关系记住：

层级
它控制什么
常见例子
能不能聊天里直接切
project
一个完整工作单元
zhangAI-codex
、zhangAI-gemini
通常靠预先配置多个项目
agent
底层跑哪个 CLI
codex
、gemini、claudecode
当前版本没有通用热切换命令
provider
当前 Agent 连哪个模型服务
OpenAI、Vertex、兼容 OpenAI 的中转
可以，走 /provider
mode
Agent 的权限模式
suggest
、default、yolo
可以，走 /mode

所以：

/mode 改的是 权限模式/provider 改的是 当前 agent 使用哪个 API Provider真正的 Agent 类型，由配置文件里的 [projects.agent].type 决定。

也就是说，如果你当前项目写的是：

[projects.agent]type = "codex"

那它就会按 Codex 路线工作。如果你想切到 Gemini，最直接的做法就是把它改成：

[projects.agent]type = "gemini"[projects.agent.options]work_dir = "/path/to/project"mode = "default"cmd = "gemini"# model = "gemini-2.5-flash"

然后重启 cc-connect

以上步骤，都可以让 Agent 去处理，只要对接好了 IM ，重启后自动生效

如果你想把 Codex 和 Gemini 都保留下来，我更推荐另一种玩法：配两个 project。

比如：

[[projects]]name = "zhangAI-codex"[projects.agent]type = "codex"[[projects]]name = "zhangAI-gemini"[projects.agent]type = "gemini"

这样做的好处是很实际的：两个 Agent 各自保留自己的配置、模式和运行习惯，你不会为了临时试 Gemini，把正在稳定工作的 Codex 项目拆掉。

还有一个细节要讲清楚：文档里的 /bind gemini，更接近“把另一个项目或机器人挂进当前群聊协作”，它表达的是多机器人中继思路，不是把当前这个 project 的底层 Agent 原地替换掉。

第四步：第一次请一定前台启动

很多人一上来就装 daemon，结果平台权限、文件权限、系统弹窗、Agent 凭证问题全混在一起，查起来很痛苦。第一次联调时，前台启动的反馈最直观：

cc-connect

如果你把配置放在默认位置 ~/.cc-connect/config.toml，它会自动读取。成功后你通常能看到类似日志：

level=INFO msg="platform started" project=my-project platform=telegramlevel=INFO msg="cc-connect is running" projects=1

飞书一般还会多一条 WebSocket 连接日志：

[Info] connected to wss://msg-frontier.feishu.cn/ws/v2?...

企业微信 WebSocket 模式会看到：

level=INFO msg="wecom-ws: subscribed successfully" bot_id=your-bot-id

然后到聊天软件里，按这个顺序发消息：

  1. /new
  2. 你是谁
  3. 帮我看看当前项目结构

第五步：前台没问题，再切后台 daemon

一旦你确认链路是通的，再切后台就很稳了。

官方文档里推荐的命令是：

cc-connect daemon install --config ~/.cc-connect/config.tomlcc-connect daemon startcc-connect daemon statuscc-connect daemon logs -f

停掉和重启也很直接：

cc-connect daemon stopcc-connect daemon restart

如果你也像我一样，把项目放在 iCloud Drive 目录里，这里要额外小心。macOS 对后台进程访问云文稿目录的权限控制更敏感，前台能过，后台有机会报：

Operation not permitted (os error 1)

我这次就是靠“先前台运行一次，再从聊天工具里触发请求”，把权限弹窗和目录访问这件事理顺的。

所以老板们如果也遇到这个报错，先别急着怀疑平台配置，先看目录权限和前后台行为差异。

Telegram：最快跑起来的一条路

如果你只想今天就把手机遥控本地 Agent 这件事做出来，我会优先推荐 Telegram。

原因很简单：它用的是 Long Polling。你不用配公网 IP，不用域名，不用反向代理，只要去 @BotFather 创建一个 bot，拿到 token，填到配置里就能跑。

BotFather 这边你主要做三件事：

  1. 发送 /newbot
  2. 取一个 bot 名字和用户名
  3. 拿到 token

如果你想把权限收紧，再额外做一件事：去 @userinfobot 查自己的 Telegram 用户 ID。

一个更稳妥的 Telegram 配置长这样：

[[projects]]name = "my-project"admin_from = "123456789"[projects.agent]type = "codex"[projects.agent.options]work_dir = "/Users/you/Code/my-project"mode = "suggest"[[projects.platforms]]type = "telegram"[projects.platforms.options]token = "1234567890:ABCDEF_your_bot_token"allow_from = "123456789"

这里我想专门提醒一句：admin_from 写在 [[projects]] 下面，别塞进 [projects.platforms.options]。这个位置一旦写错，配置不会报错，但权限控制会失效。

Telegram 这条路的体验特别适合个人开发者。私聊里先发 /new，再发一句“帮我分析当前项目结构”，通常就能很快看到结果。

如果你准备在群里用，再额外确认两件事：

  • 机器人确实被加进群了
  • 你知道自己想要“只响应 @提及”还是“响应全部群消息”
cc-connect Telegram 官方截图

飞书：国内团队协作最顺手的一条路

飞书的接入体验也很好，核心原因是它支持 WebSocket 长连接。你本机直接连飞书服务端，不需要公网回调，这一点会把部署难度拉低很多。

飞书开放平台里，你主要要做这些动作：

  1. 创建企业自建应用
  2. 开启 Bot 能力
  3. 在权限里加上消息接收和发送相关权限
  4. 在事件订阅里选择 WebSocket 长连接
  5. 添加事件 im.message.receive_v1
  6. 发布版本

文档里提到的最小配置是：

[[projects.platforms]]type = "feishu"[projects.platforms.options]app_id = "cli_xxx"app_secret = "xxx"

如果你希望群聊里的每个 thread 都有独立会话，可以再加：

thread_isolation = true

如果你发现机器人回消息有问题，或者交互卡片没显示出来，可以先把这个开关关掉：

enable_feishu_card = false

这样所有回复都会退回到纯文本路径，排障时会省心很多。

飞书这条路线我很喜欢的一点是，它很适合团队协作。一个群里挂一个项目，大家在群里直接给 Agent 下任务，必要时再用 thread_isolation 把上下文切开，使用感会非常顺。

cc-connect 飞书官方截图

企业微信：先选对路线，再动手

企业微信这条线最容易让人误判的地方在于：它给了两套接入方式。

第一套是 智能机器人 WebSocket 长连接第二套是 Webhook 回调模式

如果你的目标是先把链路跑通，我建议先选 WebSocket 智能机器人。这条路不需要公网 URL，不需要消息加解密，也不用配置可信 IP。

最小配置长这样：

[[projects.platforms]]type = "wecom"[projects.platforms.options]mode = "websocket"bot_id = "your-bot-id"bot_secret = "your-bot-secret"allow_from = "*"

平台后台里对应的动作也很明确：去企业微信管理后台创建“智能机器人”，拿到 BotID 和 Secret，填进去，前台启动 cc-connect，然后在企业微信里给机器人发消息测试。

如果你准备走得更深，比如：

  • 需要图片、语音、Markdown 消息
  • 想挂到企业自建应用体系里
  • 接个人微信插件
  • 愿意处理公网 URL、消息加解密和可信 IP

那就看 Webhook 回调模式。这时候你需要补齐这些字段：

corp_id = "wwxxxxxxxxxxxxxx"corp_secret = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"agent_id = "1000002"callback_token = "your-callback-token"callback_aes_key = "your-43-char-aes-key"port = "8081"callback_path = "/wecom/callback"enable_markdown = false

这条路线能力更大，操作成本也明显更高。我的建议很简单：先快跑，再扩展。先用 WebSocket 版本验证价值，后面再决定要不要上 Webhook。

跑通之后，真正会让你上头的是这些命令

很多人把这类工具装完，就停在“它能回消息了”这一步。真正决定你会不会长期用的，其实是聊天里这些控制能力。

/new 和 /switch 让你能把“修 bug”“写文档”“改脚本”拆成不同会话。手机上做这件事时，体验会特别明显。

/mode 会直接改变 Agent 的行为边界。Codex 常见的是 suggest、auto-edit、full-auto、yolo；Claude Code 则有 default、acceptEdits、plan、bypassPermissions。你在聊天软件里切这个开关，本质上是在远程控制 Agent 的工作方式。

/provider 非常适合重度用户。你可以运行时切换 API Provider，不用停服务，也不用重启整套链路。对于同时用官方接口、中转、兼容 OpenAI 协议模型的人来说，这个能力非常值钱。

/cron 则是我个人特别喜欢的一部分。当你在聊天里直接写：

/cron add 0 6 * * * 帮我收集 GitHub trending 并总结

工作流的味道一下子就出来了。你不再只是“远程发个消息”，而是在给本地 Agent 配长期任务。

为什么我会高看这个项目

最让我有感觉的一点，是它已经有了“平台层”的雏形。

Management API 的存在，意味着后面完全可以长出 Web 管理面板、TUI、GUI、Mac 托盘应用。

聊天工具只是当前最顺手的一个入口，后续可以扩成更多入口。

Bridge Protocol 则给了它生态扩展的可能性。作者已经把外部适配器抽象成 WebSocket 协议，只要按协议说话，理论上你就能用任意语言接新平台。公众号、网页聊天端、内部 IM、桌面端，这些想象空间都打开了。

还有一点我挺看重：它对会话一致性考虑得比很多项目更细。路径归一化、session resume 失败自动回退、结构化日志、状态恢复，这些内容平时不显山不露水，但它们直接决定一个“远程控制本地 Agent”的工具能不能长期稳定地跑。

我实操里遇到的几个真实坑

这里我建议一定保留，因为这部分最能拉开文章和“文档整理稿”的差距。

第一个坑，就是前面提过的 macOS + iCloud Drive + daemon。只要 work_dir 指向 iCloud 目录，后台进程访问权限就有机会出幺蛾子。最稳的处理方式，就是第一次用前台模式触发真实消息，让系统权限先落下来。

第二个坑，是飞书的“后台都配了，聊天还是没反应”。这时候优先查三件事：应用有没有发布版本、权限有没有生效、机器人有没有真的加进会话。很多问题都卡在这里。

第三个坑，是 Telegram 里“能连上”和“配置安全”是两回事。allow_from 和 admin_from 这两个字段建议你一开始就认真配。尤其 /shell、/restart 这类命令，一旦开放过大，风险是直接落到主机层面的。

第四个坑，是企业微信一开始就追求“大而全”。如果你上来就搞 Webhook、消息加解密、可信 IP、微信插件，一小时很快就过去了。对于大部分第一次接触的人来说，先跑 WebSocket 智能机器人，体验和理解都会更顺。

我的判断

我对 cc-connect 的整体评价挺高。

它很适合已经在重度使用 Codex、Claude Code 这类工具的人。

聊天软件可以承担“远程入口”和“控制台”的角色，很多轻交互任务完全没必要等你坐回电脑前再做。

它也很适合团队尝试：飞书和企业微信一旦接通，群聊就会从“通知面板”变成“可执行的项目入口”，这件事对协作方式的影响其实不小

当然，它也有边界：复杂长链路开发依旧更适合坐在电脑前做，聊天入口更擅长遥控、查阅、总结、轻量修改和定时任务。只要你用对场景，体验会非常舒服。