旅游景点数据分析实战：从数据清洗到可视化与结论的完整方案
2026/11/6 2:10:36
AI 数字员工群搭建技术方案与踩坑记录（Qoder + cc-connect + 飞书）
整理时间：2026-09-16 ｜ 最后更新：2026-09-29（新增第 9 章；第 2/3/4/6/7 章按现状修订）｜ 证据来源：各工作区 .qoder/ 治理正本（协作协议 v5、数字员工身份注册表、任务登记表、changelog/trace）｜ 环境：Windows 10、Node.js v20.14.0、lark-cli 1.0.88、cc-connect 1.5.0、qodercli 1.1.58
背景与目标
Java微服务涉及多个服务：历史数据搬移与数据初始化由定时任务服务执行、对接服务消费上游业务快照、数据建模服务与图形解析服务提供相邻能力。评审期间发现一批跨服务契约问题（搬移事务边界、配置值口径不一致、压缩编码格式、初始化幂等性），这些问题分散在不同项目的代码库里，单个 Agent 无法独立确认。
因此搭建「AI项目-数字员工群」飞书群，作为各项目 Qoder 数字员工的跨服务知识共享中枢：某个 Agent 遇到不熟悉的服务时，在群里按统一协议提问，由熟悉该服务的 Agent 回答，全程可追踪。
总体架构
架构历经两个阶段：阶段一人工转发模式已随三服务全部接入而退役，当前为阶段二（cc-connect 桥接）单轨运行。
- 阶段一：人工转发模式（2026-09-15 起，09-18 退役）。各项目 Qoder Agent 通过 lark-cli 以 bot 身份把消息发到群里；用户本人作为中间人，把问题转发到对应项目的 Agent，再把回答转发回群里。
- 阶段二：cc-connect 桥接模式（2026-09-16 起，现行为唯一模式）。cc-connect 常驻进程监听飞书群消息，直接驱动本机 Qoder CLI Agent 执行并回复；2026-09-18 三服务全部接入后，人工转发模式退役。
消息链路（文字等价描述）：飞书群消息 → 飞书开放平台 → 三个独立数字员工应用（主将 / 时迁 / PM管理，各自 app_id 与长连接）→ cc-connect 常驻进程 → Qoder CLI Agent（各自项目 work_dir，yolo 模式）→ 执行结果以本人应用身份回群。另有旁路通道直调飞书 im/v1 API 绕开渲染层：send-pm.js / send-service.js（见 9.4）。
| 组件 | 标识 / 版本 | 说明与位置 |
|---|---|---|
| 飞书群 | AI项目-数字员工群，chat_id：oc_***（示例群） | 2026-09-15 创建。协议与身份正本见 .qoder/specs/90-协作治理/（协作协议v5.md、数字员工身份注册表.md） |
| 数字员工应用 ×3 | 主将 cli_（主将）；时迁 cli_（时迁）；PM管理 cli_***（PM管理） | 每服务独立飞书应用（09-18 起）；身份唯一正本=身份注册表；09-24 统一更名（见 9.1） |
| lark-cli 与工具 bot | @larksuite/cli（本机 1.0.88）；「群主的Lark-CLI」cli_***（工具应用） | npm 全局安装。user 身份负责建群 / 成员 / 管理员 / 文档操作；工具 bot 不代表任何数字员工，服务 agent 禁用其发群消息（规则 9 + allow_from 白名单强制） |
| cc-connect | 1.5.0（npm 全局安装） | 飞书 ↔ Qoder 桥接进程，单进程托管三个 project；C:\Users<user>\AppData\Roaming\npm\cc-connect.cmd |
| cc-connect 配置 | config.toml | C:\Users<user>\.cc-connect\config.toml：项目 → Agent → 飞书映射；含 allow_from 白名单、enable_feishu_card（服务侧 false）、model 档位、原生 node 参数数组 |
| 自启与守护 | HKCU Run 键 cc-connect-daemon → cc-connect-startup.cmd → cc-connect-daemon.ps1 | 守护循环 10 秒重拉 + 单实例 Mutex + QODER* 环境隔离 + 日志轮转；计划任务通道本机不可用（0x800706f7）已弃用；截至 09-29 自启键缺失待补（见 9.5、9.7） |
| 协作协议 | v5（正本 .qoder/specs/90-协作治理/协作协议v5.md） | 消息类型分则（触发=文本+原生 at / 展示=卡片）、任务 ID、三信号、直达路径、10 轮熔断；详见第 4 章与 9.2 |
| 旁路工具 | send-pm.js（PM）/ send-service.js（服务） | 直调飞书 im/v1 API 绕开 cc-connect 渲染层；服务不接触凭证；详见 9.4 |
| 只读查询 | mysql-ro MCP server | dev / test / uat 只读 SQL（单语句、默认 200 / 上限 1000 行、30 秒超时、生产库不开放）；详见 9.4 |
搭建步骤
- lark-cli 用户授权。user 身份是所有管理操作的前提，执行扫码授权（过程产物 auth-qrcode.png）。授权码会过期，过期需重新扫码。
- 创建飞书群。以 user 身份通过 lark-cli im 命令创建群，拿到 chat_id（即 oc_***（示例群））。bot 身份无法建群。
- 添加用户为群成员并设为群管理员。调用群成员接口，入参见 add-member.json（加入用户 ou_***（用户））与 add-manager.json（设为管理员 manager_ids）。管理员身份用于后续人工维护群配置。
- 创建飞书企业自建应用（bot）。在飞书开放平台创建应用「群主的飞书 CLI」，记录 app_id 与 app_secret，并为应用开通即时消息相关权限范围。
- 把 bot 加入群。bot 不会自行进群，必须调群成员添加接口且 member_id_type 传 app_id，请求体见 add-bot-member.json：id_list 传入 bot 的 app_id（cli_ 前缀）。
- 验证 bot 发消息。用以下命令以 bot 身份发送，返回 message_id 即链路打通：
- 各服务 Agent 接入（阶段一）。向每个服务的 Agent 下发接入说明：群 chat_id、专属服务标签、发消息命令格式、提问/回答格式。各 Agent 用 UpdateMemory 将以上信息持久化到记忆系统，并发一条带标签的进群报到消息。接入说明模板见 接入说明模板两份。
- 部署 cc-connect（阶段二）。npm 全局安装 cc-connect，编写 config.toml 后启动验证。关键配置：每个项目一个 [[projects]] 段，agent.type = “qoder”，options.work_dir 指向项目本地路径（Windows 路径注意双反斜杠转义），mode 必须为 “yolo”。
- 配置开机自启。现行方案：HKCU Run 键 cc-connect-daemon → cc-connect-startup.cmd → cc-connect-daemon.ps1 守护链（2026-09-18 daemon 化落地，见 8.4）。原计划任务方案（install-cc-connect-task.ps1）在本机结构性不可用（0x800706f7）已弃用；手动恢复=运行 .qoder/ops/cc-connect-startup.cmd（须在沙箱外执行，见 9.5）。
node"C:\Users\<user>\AppData\Roaming\npm\node_modules\@larksuite\cli\scripts\run.js"im+messages-send--chat-id oc_**