> **场景**：在已经跑着 CodeBuddy CLI + open-im 的 Lighthouse 服务器上，再接入 **Cursor CLI**（通过 cc-connect 桥接到飞书），让两套 Agent 在同一台机器上并存协作。
>
> **难度**：中级 | **阅读时间**：约 10 分钟
>
> **关键词**：Cursor CLI、cc-connect、飞书机器人、Anthropic Messages、systemd、HOME 环境变量
>
> **前置阅读**：本文是《把 CodeBuddy CLI 接入飞书》的姊妹篇。如果你还没看过那篇，建议先了解 open-im 的整体桥接思路。

---

## 一、为什么再加一套 Cursor CLI

CodeBuddy 已经在飞书上能跑了，为什么还要再接 Cursor？

| 维度 | CodeBuddy CLI | Cursor CLI |
|------|--------------|-----------|
| 强项 | 国内生态、企业内联调、与腾讯云亲和 | 大模型推理、复杂重构、`@codebase` 全局理解 |
| 模型 | 多供应商可选 | 主力 Claude Opus / Sonnet |
| 生态 | 飞书/企微/钉钉 | 编辑器内集成深 |

实际工作里，**做小步迭代用 CodeBuddy，做架构级重构或长链路 Agent 任务用 Cursor**。两套在飞书上各占一个机器人，按需指挥，效率最高。

目标拓扑（在 CodeBuddy 那篇基础上扩展）：

```
飞书机器人 A（CodeBuddy）  飞书机器人 B（Cursor）
        ↓                       ↓
   open-im (3xxxxx)         cc-connect (1xxxx)
        ↓                       ↓
  CodeBuddy Gateway         Cursor agent
                                ↓
                       (可选) UA 改写代理
                                ↓
                        Anthropic API / 中转站
```

---

## 二、cc-connect 是什么

cc-connect 是把 **Cursor CLI 的 agent 二进制**（`/root/.local/bin/agent`）暴露成 HTTP 接口的薄桥接层，再由飞书机器人通过 webhook 调用。

它解决了 Cursor agent 的两个限制：

1. agent 默认是交互式 CLI，没有 HTTP server 模式
2. agent 严重依赖本地 `~/.cursor` 目录读写配置和缓存

cc-connect 用 `--serve --port` 启动 agent 的隐藏 server 模式，同时把外部 HTTP 请求翻译成 agent 协议。

---

## 三、安装与启动

### 3.1 装 Cursor CLI

```bash
curl -fsSL https://cursor.sh/install.sh | sh
ls /root/.local/bin/agent
agent --version
```

二进制装在 `/root/.local/bin/agent`，配置目录是 `~/.cursor`。

### 3.2 装 cc-connect

cc-connect 是 Node 包，npm 全局安装：

```bash
npm install -g cc-connect
cc-connect --version
```

裸启动测试：

```bash
cc-connect --port 1xxxx
```

正常会监听 `127.0.0.1:1xxxx`，接收 POST 请求转发给 Cursor agent。

---

## 四、第一关：systemd 启动失败 —— HOME 未定义

按 CodeBuddy 那套写好 unit 文件，结果 cc-connect 起不来：

```
journalctl -u cc-connect -n 50
---
Error: HOME environment variable is not set
agent: cannot resolve config path ~/.cursor
agent: failed to load credentials from ~/.cursor/credentials.json
```

**根因**：systemd 默认不传递 HOME 给 service。CodeBuddy 那边的 open-im 用相对路径 + cwd 兜底，所以没暴露这个问题；但 Cursor agent 严重依赖 `~/.cursor` 解析配置和缓存，HOME 缺了直接挂。

修复——在 service 文件里显式传 HOME：

```ini
# /etc/systemd/system/cc-connect.service
[Unit]
Description=cc-connect (Cursor CLI bridge for Feishu)
After=network-online.target

[Service]
Type=simple
User=root
WorkingDirectory=/root
Environment="HOME=/root"
Environment="PATH=/root/.local/bin:/root/.nvm/versions/node/v22.22.2/bin:/usr/bin:/bin"
Environment="NODE_ENV=production"
ExecStart=/root/.nvm/versions/node/v22.22.2/bin/cc-connect --port 19288
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
```

```bash
systemctl daemon-reload
systemctl enable --now cc-connect
systemctl status cc-connect
```

> **延伸建议**：以后所有依赖 `~/...` 的 systemd service，都默认加上 `Environment="HOME=/root"`（或对应用户的家目录）。

---

## 五、第二关：协议与 baseUrl 配置

cc-connect 通过 Cursor agent 调用大模型，agent 自己读 `~/.cursor/config.json`：

```json
{
  "providers": {
    "xxxx": {
      "baseUrl": "https://xxx.xxxxx.xxx",
      "protocol": "anthropic-messages",
      "apiKey": "sk-xxxxxxxxxxxxxxxx"
    }
  },
  "primary": "xxx/xxxx"
}
```

### 三个关键避坑点

**1. `baseUrl` 不带 `/v1` 后缀**

Anthropic Messages 协议会自动拼 `/v1/messages`，你额外加 `/v1` 会变成 `/v1/v1/messages` 直接 404。

```json
"baseUrl": "https://xxx.xxxx.xxx"          // ✅
"baseUrl": "https://xxx.xxxx.xxx/v1"       // ❌
```

**2. `protocol` 必须 `anthropic-messages`**

不要写 `claude` / `openai-completions` / `anthropic-v1`，agent 内部协议表只认 `anthropic-messages` 这一个名字。

**3. `primary` 必须 `provider/model_id` 格式**

```json
"primary": "xxx/xxxx"        // ✅
"primary": "xxxx"                     // ❌（缺 provider 前缀）
```

**Bonus：Windows 路径要双反斜杠转义**

如果你在 Windows 上调通 cc-connect，配置里所有路径都用 `C:\\Users\\...` 双反斜杠。Linux 上不存在这个问题。

---

## 六、第三关：与 CodeBuddy/open-im 共存

两套服务跑在同一台机器上，要避免端口冲突和资源争抢。

### 端口规划

| 服务 | 端口 | 用途 |
|------|------|------|
| codebuddy gateway | 1xxxx | 公网入口（飞书机器人 A） |
| open-im | 3xxxxx / 3xxxx | localhost 桥接 |
| cc-connect | 1xxxx` | localhost agent 转发 |
| ua-proxy（可选） | 1xxxx | localhost UA 改写 |

公网只暴露 1xxxx（CodeBuddy）和单独再起一个 cc-connect-gateway 端口（飞书机器人 B），其余全部 `127.0.0.1` 绑定。

### systemd 依赖顺序

```ini
# cc-connect.service
[Unit]
After=network-online.target ua-proxy.service
Requires=ua-proxy.service     # 如果用了 UA 代理
```

确保 cc-connect 启动时上游已就绪。

### 资源隔离

Lighthouse 2C4G 跑两套 Agent 没问题，但要防 OOM：

```ini
[Service]
MemoryMax=1500M
CPUQuota=80%
```

CodeBuddy 那边也加上类似限制，避免一个 Agent 跑满拖死另一个。

---

## 七、第四关：飞书机器人 B 的隔离配置

为 Cursor 单独开一个飞书机器人，避免与 CodeBuddy 互相干扰：

1. 飞书开发者后台新建一个 **应用机器人 B**
2. 配置 webhook URL → `http://公网IP:1xxxx/feishu/webhook`（cc-connect 暴露的入口）
3. 申请权限：`im:message`、`im:resource`
4. 拿到 `App ID` / `App Secret` / `Verification Token` 写进 cc-connect 配置

cc-connect 的飞书配置（示例）：

```json
{
  "feishu": {
    "appId": "cli_xxxx",
    "appSecret": "sk-xxxx",
    "verificationToken": "vt-xxxx",
    "encryptKey": "",
    "allowedOpenIds": ["ou_xxxx"]
  }
}
```

> **小技巧**：把两个机器人在飞书里设不同头像和名称（比如🛠CodeBuddy 助手、🧠Cursor 智囊），消息一来就能一眼区分。

---

## 八、端到端验证

```bash
# 终端 A
journalctl -u cc-connect -f

# 终端 B
journalctl -u open-im -f       # 确保 CodeBuddy 那套不受影响

# 飞书机器人 B 发：分析下 /root/projects/feedback 的代码结构
```

应当看到：

```
cc-connect: feishu webhook received
cc-connect: forwarding to agent at /root/.local/bin/agent
agent:      task started, model=claude-opus-4-7
agent:      streaming response back
cc-connect: reply delivered to feishu
```

平均响应时间 8-15 秒（Cursor 用 Opus 4.7 + 大上下文，比 CodeBuddy 慢一点，但推理质量更高）。

---

## 九、常见问题速查

### Q1：cc-connect 启动 OK 但飞书消息无响应

```bash
# 1. 看 cc-connect 是不是真的收到了 webhook
journalctl -u cc-connect | grep webhook

# 2. 看 agent 是否被正确调用
journalctl -u cc-connect | grep agent

# 3. 测试 Cursor agent 本身
HOME=/root /root/.local/bin/agent --version
```

如果第 3 步报 HOME 错误，回到第四章修 systemd unit。

### Q2：返回 403

参考姊妹文章《OpenClaw 接入 100xlabs 中转站被 Cloudflare WAF 403 的完整排查记录》——大概率是中转站把 Anthropic SDK 的 User-Agent 拉黑了，需要在前面加一层 UA 改写代理（监听 1xxxx，把 `Anthropic/JS X.X.X` 替换成 Chrome UA）。

### Q3：Cursor agent 报 "credentials not found"

`~/.cursor/credentials.json` 没生成。手动登录一次：

```bash
HOME=/root /root/.local/bin/agent login
```

然后重启 cc-connect。

### Q4：双机器人消息串台

`allowedOpenIds` 没区分。可以让两个机器人都允许同一个 open_id（你自己），但通过**不同 appId** 区分来源——cc-connect 只处理它自己 appId 的事件。

---

## 十、踩坑总结

| 坑 | 表现 | 修复 |
|----|------|------|
| HOME 未定义 | agent 找不到 ~/.cursor | systemd 加 `Environment="HOME=/root"` |
| baseUrl 多余 /v1 | 404 | 去掉后缀 |
| protocol 写错 | 协议不识别 | 必须 `anthropic-messages` |
| primary 缺前缀 | 模型加载失败 | 写 `provider/model_id` |
| 中转站 UA 被封 | 403 | 前置 UA 改写代理 |
| 端口冲突 | 起不来 | 规划 cc-connect = 1xxxx，与 open-im 错开 |
| credentials 缺失 | agent 报错 | 手动 `agent login` 一次 |

---

## 十一、写在最后

cc-connect 比 open-im 简单不少（不用改源码，主要是 systemd + 配置），但 **HOME 这一坑几乎所有人都会踩**——这是 systemd 默认行为，不是 Cursor 的锅。

把 CodeBuddy 和 Cursor 都接到飞书后，我的工作流变成：

- **小步快跑** → CodeBuddy（响应快、本地集成好）
- **架构思考、重构、长链路任务** → Cursor（推理强、上下文大）
- **行业资讯日报** → 单独的 cron 脚本推送

一台 2C4G 的 Lighthouse 跑这三套绰绰有余，月成本不到 50 块。

下一篇打算写《飞书机器人卡片化回复 + 多用户协作 ACL 配置》，把现在的纯文本回复升级成富文本卡片，并支持团队多人共用。如果对某个环节想看更细的拆解，欢迎评论区点题。

---

**姊妹篇**：《把 CodeBuddy CLI 接入飞书：一台 Lighthouse 上的 AI Agent 远程办公实录》、《OpenClaw 接入 API 中转站被 Cloudflare WAF 403 的完整排查记录》


场景：在已经跑着 CodeBuddy CLI + open-im 的 Lighthouse 服务器上，再接入 Cursor CLI（通过 cc-connect 桥接到飞书），让两套 Agent 在同一台机器上并存协作。

把 Cursor CLI 接入飞书：cc-connect 集成实录与避坑指南

数据库

本文详细讲解在已部署CodeBuddyCLI的服务器上集成CursorCLI，通过cc-connect桥接飞书实现双Agent协作。内容涵盖cc-connect原理、systemd服务配置（重点解决HOME环境变量问题）、AnthropicMessages协议配置要点、端口规划与资源隔离方案。提供飞书机器人隔离配置、端到端验证方法及常见问题排查指南，帮助用户在同一台Lighthouse服务器上高效部署两套AI助手，实现CodeBuddy快速迭代与Cursor深度推理的互补工作流。

服务器

OpenClaw

Windows

Linux

Agent

4核4G3M云服务器 新用户低至38元/年！

lighthouse

2026年中大促 | AI 领航 智绘未来

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

本文详细讲解在已部署CodeBuddyCLI的服务器上集成CursorCLI，通过cc-connect桥接飞书实现双Agent协作。内容涵盖cc-connect原理、systemd服务配置（重点解决HOME环境变量问题）、AnthropicMessages协议配置要点、端口规划与资源隔离方案。提供飞书机器人隔离配置、端...

把 Cursor CLI 接入飞书：cc-connect 集成实录与避坑指南-腾讯云开发者社区-腾讯云

把 Cursor CLI 接入飞书：cc-connect 集成实录与避坑指南

把 Cursor CLI 接入飞书：cc-connect 集成实录与避坑指南

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐