卸載龍蝦，把本地AI編程助手 Claude Code、Gemini、Codex 通通裝進飛書和企業微信

公司下了通知，禁止任何接入辦公網的電腦安裝龍蝦，個人電腦也不行

我一直比較謹慎，這玩意權限實在太大，項目也不過半年，幾十萬行代碼都是 AI 生成，甚至連review 都是 AI，馬斯克這個 meme 很好的說明了普通人接入 OpenClaw 的危險

大神 Karpathy 也質疑，把自己的私人數據交給有 40 萬行 “憑感覺編寫” 的龐然大物一點也不誘人??

工信部也發布OpenClaw安全風險預警：配置不當極易引發網絡攻擊和信息泄露

后來我們公司也要求卸載龍蝦，不得不說，上門裝龍蝦這一蝦三吃，真是好生意啊

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

介入了 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-connect
npm install -g @openai/codex

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

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

裝完以后，先確認命令在不在：

which cc-connect
which codex
cc-connect --version
codex --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=telegram
level=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. 幫我看看當前項目結構

一旦你確認鏈路是通的，再切后臺就很穩了。

官方文檔里推薦的命令是：

cc-connect daemon install --config ~/.cc-connect/config.toml
cc-connect daemon start
cc-connect daemon status
cc-connect daemon logs -f

停掉和重啟也很直接：

cc-connect daemon stop
cc-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，再發一句“幫我分析當前項目結構”，通常就能很快看到結果。

如果你準備在群里用，再額外確認兩件事：

• 機器人確實被加進群了

• 你知道自己想要“只響應 @提及”還是“響應全部群消息”

飛書的接入體驗也很好，核心原因是它支持 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 這類工具的人。

聊天軟件可以承擔“遠程入口”和“控制臺”的角色，很多輕交互任務完全沒必要等你坐回電腦前再做。

它也很適合團隊嘗試：飛書和企業微信一旦接通，群聊就會從“通知面板”變成“可執行的項目入口”，這件事對協作方式的影響其實不小

當然，它也有邊界：復雜長鏈路開發依舊更適合坐在電腦前做，聊天入口更擅長遙控、查閱、總結、輕量修改和定時任務。只要你用對場景，體驗會非常舒服。