最近看到zara老师发的一个飞书连接claude code的视频，突然冒出一个念头——既然 Claude Code 都在我电脑上跑了，那能不能让它跑在云服务器上，然后我用飞书发消息就能让它干活？想到哪算哪，说改个 bug 就改 bug，说部个署就部署,整个云服务器变成我的数字打工仔。

我把整个折腾过程从头到尾走了一遍,里面踩了至少四个像样的坑——有官方文档里没说的、有 Claude Code 自身的安全限制、还有一个让我盯着日志看了二十分钟才反应过来的「环境变量幽灵」。这篇就是把所有踩坑沉淀下来,看完你能少走至少两小时弯路。

最终长这样:

• 服务器:京东云一台 Ubuntu 小机器
• AI 模型:DeepSeek V4 Pro(走 Anthropic 兼容协议)
• 触达方式:飞书 bot,私聊直接说话,群里 @bot 干活
• 使用场景:地铁上 / 床上 / 蹲坑时随时给服务器发指令,让 AI 帮我改代码、查日志、跑命令

整套架构画出来大概就是:

1

你的飞书 → 飞书开放平台长连接 → 云服务器上的 bridge → Claude Code CLI → DeepSeek API

下面开始正式上手,按顺序走一遍我趟过的所有坑。

第一步:让 Claude Code 跑在云服务器上

我用的是一台京东云的 Ubuntu 22.04,先 SSH 进去。

第一个小坑出现得很快。Ubuntu 自带的 apt 仓库里 Node.js 版本太老,Claude Code 要求 18+,直接 apt install nodejs 装出来的可能根本跑不动。

正确的姿势是用 NodeSource 的源装最新 LTS:

1
2
3
4
5
6

curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
apt-get install -y nodejs

# 验证一下
node -v   # 应该是 v22.x
npm -v

然后全局装 Claude Code:

1
2

npm install -g @anthropic-ai/claude-code
claude --version  # 验证

到这一步是顺的,没啥幺蛾子。

第二步:把官方账号换成 DeepSeek(省钱)

官方 Claude API 是按量付费的,跑久了肉疼。DeepSeek 出了一个 Anthropic 兼容协议,Claude Code 完全不用改,只需要改几个环境变量就能切换过去。

而且这玩意做日常服务器运维聊天完全绰绰有余,也能应付一些工程问题,主打的就是一个性价比——比官方便宜,而且不会有 Claude Code 官方订阅那种封号的风险。

按照官方文档,把下面这一坨写到 ~/.bashrc 里:

1
2
3
4
5
6
7
8
9

# DeepSeek API for Claude Code
export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
export ANTHROPIC_AUTH_TOKEN=sk-你的-key
export ANTHROPIC_MODEL=deepseek-v4-pro[1m]
export ANTHROPIC_DEFAULT_OPUS_MODEL=deepseek-v4-pro[1m]
export ANTHROPIC_DEFAULT_SONNET_MODEL=deepseek-v4-pro[1m]
export ANTHROPIC_DEFAULT_HAIKU_MODEL=deepseek-v4-flash
export CLAUDE_CODE_SUBAGENT_MODEL=deepseek-v4-flash
export CLAUDE_CODE_EFFORT_LEVEL=max

然后 source ~/.bashrc,claude 启动就走的是 DeepSeek 了。

为了再偷个懒,我加了个别名:

1
2

echo 'alias ccd="claude --dangerously-skip-permissions"' >> ~/.bashrc
source ~/.bashrc

以后输 ccd 直接进,不再每次问我要不要执行某个命令——开启这个之后,Claude 就跳过那些无关紧要的询问,直接执行任务。

可以看到非常顺利的完成了配置。

⚠️ 这里埋了一个雷,后面会引爆——--dangerously-skip-permissions 在 root 用户下是被 Claude Code 直接拒绝的。但如果你只是手动用,没关系;要是后面接了 bridge,就麻烦了。

第三步:装 lark-channel-bridge(飞书桥)

这个 GitHub 项目叫 feishu-claude-code-bridge,作者是 Zara 老师,npm 包名是 lark-channel-bridge。

它的本质其实就是一个常驻的 WebSocket 长连接,每次我在飞书发的消息都会通过这个 bridge 转发给本地的 Claude Code,然后 Claude 处理完再把结果原路推回飞书。

为啥不用 OpenClaw?简单聊一下我的判断:Claude Code 对任务的执行力更扎实,Agent 机制比 OpenClaw 要优雅,而且更轻量——OpenClaw 塞进去的东西太多了。在执行任务方面,Claude Code 的调度更优雅,响应也快,而且你能看到全流程。

直接装:

1

npm i -g lark-channel-bridge

然后第一个坑来了。

我看 README 写「跑 lark-channel-bridge start 会自动弹出二维码」,于是兴冲冲地敲了下去:

1
2
3

$ lark-channel-bridge start
bot 还没配置 app 凭据。
请先运行 `run` 完成首次扫码向导,再回来 `start`。

???

翻了下 --help 才搞明白:start 是注册系统守护进程的命令,第一次扫码必须用 run。这个差异 README 里没明确说,旧版本用 start 命令应该是直接管扫码的,新版本拆成了两步,但文档没跟上。

正确流程:

1
2

# 第一次:用 run 跑前台,触发扫码向导
lark-channel-bridge run

终端会画一个二维码出来,飞书 App 扫码 → 选择或创建 PersonalAgent 应用 → 完成绑定。

绑定成功后凭据落到 ~/.lark-channel/config.json。这时候 Ctrl+C 退出,改用 daemon 模式:

1
2
3

lark-channel-bridge start    # 后台常驻,断 SSH 也不挂
lark-channel-bridge status   # 看状态
lark-channel-bridge stop     # 停掉

到这步我以为大功告成了,飞书里找到 bot 私聊,发了句「你好」。

bot 给我加了个表情回应 ✓ 然后……就一直 thinking,再没下文。

第四步:调试卡死的 thinking(这里坑最多)

被卡在 thinking 那一刻,我盯着飞书界面看了好几秒,心里冒出一连串问号——是网络问题?是 API key 没生效?还是模型太大跑不动?

不管怎样,先看日志。

1

tail -50 /root/.lark-channel/logs/daemon-stderr.log

第一行就给我看笑了:

1

⚠ [agent.stderr] line=--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

哦,原来是这事。

坑 1:bridge 默认用了 root 不能跑的权限模式

我翻了下 bridge 的源码(/usr/lib/node_modules/lark-channel-bridge/dist/cli.js),发现它调用 Claude Code 的时候是这么写的:

1
2
3
4
5
6
7

const args = [
  "-p", opts.prompt,
  "--output-format", "stream-json",
  "--verbose",
  "--permission-mode", opts.permissionMode ?? "bypassPermissions",
  // ...
];

bypassPermissions 这个权限模式 Claude Code 不允许在 root 下用——是 Anthropic 的安全设计,怕你以最高权限把自己服务器搞死。

合理的解决思路有两个:

1. 让 bridge 用别的权限模式
2. 让 bridge 调用 claude 时降权到普通用户

bridge 没暴露权限模式的配置项,只能走方案 2——新建一个普通用户,让 claude 跑在那个用户下。

1
2
3
4
5
6
7
8
9

# 建个新用户
useradd -m -s /bin/bash bridge

# 把 root 的 .bashrc(含 DeepSeek 环境变量)和 lark-channel 配置复制过去
cp /root/.bashrc /home/bridge/.bashrc
chown bridge:bridge /home/bridge/.bashrc

cp -r /root/.lark-channel /home/bridge/.lark-channel
chown -R bridge:bridge /home/bridge/.lark-channel

但试了一下直接 su - bridge -c "lark-channel-bridge start",又踩了第二个坑。

坑 2:bridge 的 secrets 加密绑定了用户

报错是这样的:

1
2

Error: Unsupported state or unable to authenticate data
    at Decipheriv.final (node:internal/crypto/cipher:184:29)

bridge 的 App Secret 是加密存的(~/.lark-channel/secrets.enc),加密密钥跟用户绑定,换个用户就解不开。

意味着不能简单地把 bridge 进程整个扔到普通用户下跑——bridge 主进程必须留在 root,但是它调用 claude 的子进程需要降权。

思路立刻清晰了:写一个 wrapper 脚本,把 claude 命令替换掉,wrapper 内部用 sudo 切到 bridge 用户再调用真正的 claude。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# 把原版 claude 改名
mv /usr/bin/claude /usr/bin/claude-real

# wrapper 脚本
cat > /usr/local/bin/claude-run-as-bridge << 'EOF'
#!/bin/bash
exec sudo -u bridge -H \
  --preserve-env=ANTHROPIC_BASE_URL,ANTHROPIC_AUTH_TOKEN,ANTHROPIC_MODEL,ANTHROPIC_DEFAULT_OPUS_MODEL,ANTHROPIC_DEFAULT_SONNET_MODEL,ANTHROPIC_DEFAULT_HAIKU_MODEL,CLAUDE_CODE_SUBAGENT_MODEL,CLAUDE_CODE_EFFORT_LEVEL \
  /usr/bin/claude-real "$@"
EOF

chmod +x /usr/local/bin/claude-run-as-bridge

# 把 claude 软链到 wrapper
ln -s /usr/local/bin/claude-run-as-bridge /usr/bin/claude

# 让 root 可以无密码 sudo 切 bridge
echo "bridge ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/bridge
chmod 440 /etc/sudoers.d/bridge

跑 claude --version 验证一下:

1

2.1.150 (Claude Code)

通了!再发飞书消息试试……

还是 thinking 转圈。

坑 3:sudo 报错 “unable to resolve host”

再看日志,发现一堆这种:

1

sudo: unable to resolve host lavm-da9t63no6t: Name or service not known

这是云服务器一个常见的小问题——主机名在 /etc/hostname 里写了,但 /etc/hosts 里没对应条目。修:

1

echo '127.0.0.1 lavm-da9t63no6t' >> /etc/hosts

但这不是真正的卡点,最致命的坑还在后面。

坑 4:systemd daemon 不读 .bashrc(环境变量幽灵)

修完 hostname 重启 bridge,发消息,还是 thinking。

我手动跑 wrapper 验证:

1
2
3

$ claude -p "say hi"
{"type":"system","subtype":"init",..."model":"deepseek-v4-pro[1m]"...}
{"type":"assistant","message":{...,"content":[{"type":"text","text":"Hi! How can I help you today?"}]...}

完全正常!DeepSeek API 都返回了。

但是 bridge 调用就 1 秒退出,code 1。这下就玄乎了——同样的命令,手动跑成功,bridge 跑失败,差别在哪?

我开始翻进程的环境变量:

1
2

$ cat /proc/$(pgrep -f 'lark-channel-bridge run')/environ | tr '\0' '\n' | grep ANTHROPIC
# (什么都没有)

恍然大悟。

lark-channel-bridge start 把服务注册成了 systemd 用户服务,service 文件长这样:

1
2
3

[Service]
ExecStart="/usr/bin/node" "/usr/bin/lark-channel-bridge" run
Environment="PATH=/usr/local/sbin:/usr/local/bin:..."

只设了 PATH,没有 ANTHROPIC 环境变量。systemd 启动的 daemon 跟交互式 shell 完全隔离,根本不会 source .bashrc。

所以 daemon 里没有 ANTHROPIC 变量 → wrapper 用 --preserve-env 也只是「保留空值」给 sudo → claude 启动后没 API 配置 → 直接走「未登录」分支退出。

这事看着简单,但当时坑了我快二十分钟。它狡猾的地方在于:

• 你 echo $ANTHROPIC_BASE_URL 看自己的 shell 是有的
• 你手动 claude --version 也是好的
• 但 daemon 里偏偏没有,因为它根本不在你的 shell 上下文里

真正的修复是改 systemd service 文件,把环境变量写进去:

1

vim ~/.config/systemd/user/lark-channel-bridge.bot.service

在 [Service] 段加上:

1
2
3
4
5
6
7
8

Environment="ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic"
Environment="ANTHROPIC_AUTH_TOKEN=sk-你的-key"
Environment="ANTHROPIC_MODEL=deepseek-v4-pro[1m]"
Environment="ANTHROPIC_DEFAULT_OPUS_MODEL=deepseek-v4-pro[1m]"
Environment="ANTHROPIC_DEFAULT_SONNET_MODEL=deepseek-v4-pro[1m]"
Environment="ANTHROPIC_DEFAULT_HAIKU_MODEL=deepseek-v4-flash"
Environment="CLAUDE_CODE_SUBAGENT_MODEL=deepseek-v4-flash"
Environment="CLAUDE_CODE_EFFORT_LEVEL=max"

然后 reload + restart:

1
2

systemctl --user daemon-reload
systemctl --user restart lark-channel-bridge.bot.service

回飞书发条消息——

bot 终于回话了。日志里能看到:

1
2
3
4

phase=session event=resume sessionId=2a996ab8...
phase=card event=streaming → done
phase=agent event=exit code=0   ✓
costUsd=0.0145

成本一毛钱不到,跑完整个对话。搞定。

一眼避坑指南

按踩坑顺序整理一遍,给你抄作业:

整套架构最终长什么样

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

飞书 App
    │
    │ 发消息 / @bot
    ▼
飞书开放平台
    │ WebSocket 长连接
    ▼
云服务器(Ubuntu)
    │
    └─ systemd user service: lark-channel-bridge.bot
         │  环境变量: ANTHROPIC_*  (写在 service 文件里)
         │  以 root 跑,bridge 主进程
         │
         └─ spawn(claude, args)   ← 实际是 wrapper
              │
              └─ sudo -u bridge --preserve-env=...
                   │
                   └─ /usr/bin/claude-real
                        │ 用 DeepSeek API
                        ▼
                   DeepSeek V4 Pro

这套结构跑起来之后,每次飞书消息进来,daemon 起一个新的 claude 进程(带正确的环境变量、降权到 bridge 用户、跳过权限确认),跑完把结果流式推回飞书卡片,整个链路不到 2 秒。

一些用起来才发现的体感

1. 流式卡片真的好用。Claude 的工具调用、文件读写、命令执行全都实时刷在同一张飞书卡片上,不用等。我有时候开会的时候在群里 @bot 让它查个东西,开会结束打开一看已经搞定了。

2. 会话延续是按 chat 隔离的。每个私聊或每个群是独立 session,互不串。这个设计很对——不会出现「我私聊它问的事被群友看见了」的尴尬。

3. /cd <path> 切工作目录。bot 默认在 /root 工作,但你可以发 /cd /path/to/your/project 让它切到具体项目里干活。配合 /ws save myproj / /ws use myproj 还能给常用项目命名,下次直接 /ws use 就回去。

4. /stop 能中断它。如果 Claude 跑歪了,发 /stop 立马停。

5. DeepSeek V4 Pro 跑得不慢。我以为国内 API 会比官方慢,实测下来响应时间差不多,3-5 秒能给出第一个 token,长任务也跟得上。

写在最后

整个流程跑下来,感觉这玩意比我想象的实用得多。

之前 Claude Code 只能在我电脑上用,意味着我打开电脑、连上 VPN、进项目目录,才能开始干活。现在我躺床上、坐地铁、开会摸鱼,飞书发条消息,服务器那头就开干了——而且因为它跑在云上,下载文件、跑后端、连数据库这些事都比本地方便。

但你要明白这是个双刃剑——--dangerously-skip-permissions 真的就是「dangerous」的意思。我跑在一台没什么重要数据的小机器上,万一 Claude 瞎搞最多就是重装。如果你要把这套接到生产服务器,至少把跑 Claude 的那个用户的权限收紧:限制 sudo 能干啥、限制能访问哪些目录、不要让它能 rm 关键文件。

折腾的过程比结果更有意思。每个坑都让我更理解这套东西的运作方式——为什么 Claude Code 拒绝 root、为什么 systemd 不读 bashrc、为什么 sudo 要 preserve-env,这些细节平时不接到一起根本不会想。

回头看,这种「把分散的工具接成自己的链路」的能力,其实比单独学某个工具有意思得多。Claude Code 能跑、飞书能收消息、bridge 能桥接,三件事谁都不复杂,但拼起来就是一个能用的东西。

下次再有什么离谱的想法,比如把 ChatGPT 接到我家路由器,我估计也会试试。