夜雨聆风公司下了通知，禁止任何接入办公网的电脑安装龙虾，个人电脑也不行
我一直比较谨慎，这玩意权限实在太大，项目也不过半年，几十万行代码都是 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，完成度明显更高，平台支持也更完整
先给结论
如果你已经在用 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 运行时平台”走。
真正重要的部分：先把第一条消息跑通
我建议你按下面这个顺序来：
安装 cc-connect确认本地 Agent 本身能在终端独立工作 写一个最小可用 config.toml先用前台模式跑通 聊天里发 /new验证没问题再切后台 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、opencodework_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如果直接写 *，虽然配置最快，安全边界也会立刻放大
第一次配置时，我反而建议你先别动下面这些：
providerspeechttsbridgemanagementmulti-workspace
这些都很强，后面慢慢加完全来得及
先把“能发消息、能收到回复、能看日志”这一条主链路跑通，价值最高。
很多人会问：它能不能直接从 Codex 切到 Gemini
这个问题特别值得单独讲一下，因为很多人第一次看到 /provider、/mode、/bind 这些命令时，很容易把它们理解成同一件事。
先给结论：当前版本的 cc-connect，没有一个通用的运行时命令，让你在同一个 project 里把 codex 直接热切换成 gemini。
你可以先把这四层关系记住：
project | zhangAI-codexzhangAI-gemini | ||
agent | codexgemini、claudecode | ||
provider | /provider | ||
mode | suggestdefault、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然后到聊天软件里，按这个顺序发消息：
/new你是谁帮我看看当前项目结构
第五步：前台没问题，再切后台 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 这边你主要做三件事：
发送 /newbot取一个 bot 名字和用户名 拿到 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 长连接。你本机直接连飞书服务端，不需要公网回调，这一点会把部署难度拉低很多。
飞书开放平台里，你主要要做这些动作：
创建企业自建应用 开启 Bot 能力 在权限里加上消息接收和发送相关权限 在事件订阅里选择 WebSocket 长连接 添加事件 im.message.receive_v1发布版本
文档里提到的最小配置是：
[[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 把上下文切开，使用感会非常顺。
企业微信：先选对路线，再动手
企业微信这条线最容易让人误判的地方在于：它给了两套接入方式。
第一套是 智能机器人 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 这类工具的人。
聊天软件可以承担“远程入口”和“控制台”的角色，很多轻交互任务完全没必要等你坐回电脑前再做。
它也很适合团队尝试：飞书和企业微信一旦接通，群聊就会从“通知面板”变成“可执行的项目入口”，这件事对协作方式的影响其实不小
当然，它也有边界：复杂长链路开发依旧更适合坐在电脑前做，聊天入口更擅长遥控、查阅、总结、轻量修改和定时任务。只要你用对场景，体验会非常舒服。
