背景引言
作为一名信贷行业的数据分析师，我日常需要同时兼顾资产、转化、团队三个维度的数据分析工作。每一个业务维度背后都对应着一套完整的指标体系——资产质量监控涉及入催率、利差、坏账率等核心指标；转化漏斗分析需要追踪从申请到放款的全链路转化；催收团队管理则关注催收效率、还款率、催回金额等。
在实际工作中，我每天早上需要打开三个大型 Excel 文件进行数据观测：每个文件包含约 10 个子页面，累计监测近三十张业务图表，数据观测一遍需要花费 1 到 2 小时。期间需要反复登录数据库、执行 SQL 查询、核对各维度数据，观测指标异动，整个过程不仅耗时且容易因人工疲劳而出错。
随着业务规模增长，数据量和指标复杂度持续上升，纯人工观测的方式已难以满足日常需求。我开始思考：能否将部分分析框架交给 AI 处理，让 AI 成为一个真正理解业务逻辑的数据分析搭档？
飞书是我所在公司唯一的协作交流平台，几乎所有的内部沟通、文件管理和知识沉淀都运行在飞书生态上。将 AI 助手接入飞书，意味着用户无需改变现有工作习惯——直接在飞书聊天窗口发起数据查询，AI 即可调用工具返回分析结果。这种「在飞书中对话，在飞书中出结果」的体验，是最符合实际业务场景的接入方式。
基于以上背景，我选择将 OpenClaw 作为 AI Agent 框架，部署至云服务器，并将其与飞书自建机器人进行集成。AI 助手负责理解业务需求、调用分析工具、返回结构化数据；飞书作为统一的交互入口，承接所有的查询和反馈。
本文完整记录了从环境准备、框架部署、飞书接入到业务 Skill 定制、记忆管理体系搭建的全过程，供有相同需求的开发者参考。
一、技术选型背景
为什么选 OpenClaw
在选择 AI Agent 框架时，我主要评估了三个维度：架构灵活性、扩展性和运维复杂度。
今年二月底，我花了一周时间对业界现有的 AI Agent 框架进行了广泛调研。当时在业务数据分析这个垂直场景下，OpenClaw 是我能找到的最成熟解决方案——它不仅具备多 Agent 架构和 Skill 扩展机制，而且官方提供了完整的飞书插件支持。横向对比下来，OpenClaw 是唯一能够满足「快速部署 + 飞书接入 + 业务 Skill 定制」三个核心需求统一的框架，没有其他替代选项。
OpenClaw 之所以进入我的候选列表，核心原因在于它采用了多 Agent 架构设计。不同于单 Agent 对话机器人只能处理简单的问答场景，OpenClaw 支持将一个复杂任务拆解为多个子 Agent 分别执行——例如将「分析昨天资产数据」这件事，可以由一个专门负责数据库查询的 Agent 和一个负责指标计算的 Agent 协作完成。这种架构在面对多条业务线、多维度数据分析时具有明显优势。
第二个关键因素是 Skill 扩展机制。OpenClaw 提供了一套标准化的 Skill 开发规范，我可以将自己编写的 Python 脚本、SQL 查询逻辑封装为可被 AI 调用的 Skill。这意味着 AI 并不是在做一个「通用问答」，而是在调用「具备业务能力的技术工具」。以资产分析为例，我将 SQL 查询脚本封装为 asset-metrics Skill，AI 在接收到「查询本周 D0 入催率」这类请求时，能够理解业务语义并调用对应的 Skill 执行查询，返回结构化的分析结果，而非空洞的文本回复。
第三个因素是 官方飞书插件的完整支持。OpenClaw 提供了经过实战验证的飞书接入方案，包括机器人创建、事件订阅、消息收发等完整能力，我无需从零研究飞书 API，官方 CLI 即可完成全流程接入。
为什么接飞书
这个问题的答案与公司技术栈密切相关。我所在公司的内部沟通、文件管理、知识沉淀几乎全部运行在飞书生态上——飞书云盘存储 Excel 数据文件，飞书云文档承载数据字典和分析规范，飞书群用于日常业务沟通。将 AI 助手接入飞书，是成本最低、体验最优的方案。
从我作为日常使用者角度看，无需改变现有工作习惯，无需安装任何额外软件，直接在飞书私聊窗口向 AI 机器人发起数据查询请求，AI 完成分析后直接将结构化的结果数据回传到对话中。这种「对话即服务」的体验，是其他接入方式（如网页控制台、独立 App）无法替代的。
从技术整合角度看，飞书云盘和云文档可以作为 AI 记忆管理的中转层——短期记忆以本地文件形式存储，长期记忆同步至飞书云文档，方便在手机端随时查阅。这种设计与飞书生态的深度整合，进一步提升了 AI 助手在实际业务场景中的可用性。
二、部署前准备
服务器配置
AI Agent 的 Gateway 服务运行在云服务器 ECS 上，配置如下：
| 配置项 | 规格 |
|---|---|
| 实例类型 | ecs.e-c1m2.large |
| CPU | 2 vCPU |
| 内存 | 4 GiB |
| 系统盘 | 40 GB SSD |
| 操作系统 | Ubuntu 20.04 LTS |
| 公网带宽 | 按流量计费 |
| 所属地域 | 马来西亚（亚太东南）节点 |
环境要求
服务器上提前安装了以下依赖：
Node.js
OpenClaw 要求 Node.js 18.x 及以上版本。我通过 nvm 安装：
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
nvm install 18
nvm use 18
node -v # 确认版本为 v18.x.x
网络
服务器可访问外网，安装过程中需要拉取 OpenClaw 安装包、调用火山引擎 Coding Plan API 以及与飞书开放平台建立 WebSocket 连接。以下域名均可正常访问：
npm官方源- 火山引擎 API 域名
- 飞书开放平台 API 域名
飞书开放平台账号准备
在 飞书开放平台 创建了企业自建应用，获得了以下凭证：
App ID：应用的唯一标识。
App Secret：应用密钥，用于换取接口调用凭证。
模型准备
我使用火山引擎的 Coding Plan 作为默认模型。火山引擎 Coding Plan 是字节跳动旗下的 AI 代码与推理模型服务。我已在火山引擎控制台开通了 Coding Plan 服务并获取了 API Key，留作后续配置使用。
三、OpenClaw 部署
火山引擎云服务器上已预装了 OpenClaw，无需手动部署。火山引擎 Coding Plan 是一个综合模型提供商，我通过火山引擎提供的接入脚本，在 Coding Plan 中选择了 MiniMax-2.5 作为 AI 模型，并将 Coding Plan 接入 OpenClaw：
curl -fsSL https://lf3-static.bytednsdoc.com/obj/eden-cn/ylwslo-yrh/ljhwZthlaukjlkulzlp/install.sh | sh
该脚本用于完成火山引擎 Coding Plan 与 OpenClaw 的模型接入配置，并非用于安装 OpenClaw 本身。
工作目录和文件结构在服务器初始化时已配置完成：
./workspace/
├── config.yaml # Gateway 配置文件
├── agents/ # Agent 角色定义目录
└── skills/ # Skill 目录（后续存放业务 Skill）
配置完成后，我通过以下命令启动 Gateway 服务：
openclaw gateway start
服务启动后，使用 openclaw status 确认各组件正常运行。
四、飞书接入
我参考了火山引擎官方文档（https://www.volcengine.com/docs/6396/2189942）来完成飞书接入。
飞书接入的关键步骤如下：
第一步：创建飞书应用
在 飞书开放平台 创建企业自建应用，填写应用名称和描述。进入应用后，添加应用能力并选择「机器人」。
第二步：配置权限
在「权限管理」中添加以下权限：
im:message- 获取与发送消息im:message:send_as_bot- 以机器人身份发送消息im:chat:readonly- 获取群列表contact:user.id:readonly- 获取用户 ID
第三步：配置事件订阅
在「事件与回调」中完成以下配置：
- 回调配置 → 订阅方式 → 选择「使用长连接接收回调」
- 添加事件 → 选择「接收消息（
im.message.receive_v1）」
选择长连接模式是整个接入的关键——OpenClaw 无需公网回调地址即可接收飞书消息，大幅降低了部署复杂度。
第四步：发布应用
点击「创建版本」，填写版本信息后提交发布，使应用在内可用。
第五步：配置 OpenClaw 飞书凭证
获取应用的 App ID 和 App Secret（在「凭证与基础信息」页面），通过 OpenClaw CLI 完成绑定：
openclaw config set channels.feishu.appId 'cli_xxxx'
openclaw config set channels.feishu.appSecret 'your_secret'
openclaw config set channels.feishu.enabled true
重启 Gateway 使配置生效：
openclaw gateway restart
第六步：验证连通性
启动后查看日志确认飞书连接状态：
tail -f ~/.openclaw/logs/*.log | grep -i feishu
看到 feishu connected 日志后，在飞书私聊窗口向机器人发送测试消息，确认消息收发正常。
飞书文档接入的补充说明
初次部署完成后，OpenClaw 虽然能够正常聊天，但在接入飞书文档时遇到了诸多问题：机器人频繁需要重新授权，且飞书文档的权限归属于 AI 机器人而非用户本身，导致用户无法直接对文档进行修改操作。
今年3月初，我在 OpenClaw 社区中找到了一个帖子，其中提到了飞书官方发布的 OpenClaw 官方插件，专门用于解决机器人权限过低的问题。我参考了该文档（https://bytedance.larkoffice.com/docx/MFK7dDFLFoVlOGxWCv5cTXKmnMh）重新进行了部署。
通过官方插件接入后，OpenClaw 可以完美接入飞书文档，且整个过程仅需一次初始化授权，即可在飞书文档中实现流畅的增、删、查、改操作，不再需要反复授权。
五、业务定制：从通用助手到行业助手
目标：把资产分析的分析框架教会 AI
完成基础接入后，AI 仍然是一个通用对话助手，不理解任何业务逻辑。我需要将资产分析的分析框架逐条教给 AI，使其能够理解业务语义、调用正确的 SQL 查询、返回格式化的指标结果。
整个定制过程分为五个步骤执行。
Step 1 · 建数据源
资产分析的数据存储在 MySQL 中。我首先创建了 nigeria_asset 数据库，将每日更新的资产数据导入其中，并建立了完整的数据字典。
数据字典是整个分析体系的基础文档，包含每个字段的命名规范、业务含义、口径定义和维度划分标准，以飞书云文档形式存储，便于维护和团队共享。
下表是资产数据表的核心字段说明：
维度字段
| 中文名 | 字段名 | 说明 |
|---|---|---|
| 放款日期 | lending_date |
订单实际放款日期 |
| 放款周 | week_date |
放款所在周 |
| 放款月 | month_date |
放款所在月 |
| 包体名称 | package_name |
具体包体名称 |
| 包体分类 | package_name_type |
投放包 / APK包 |
| 产品类型 | product_type |
单笔 / 多笔 |
| 多笔细分 | multi_type |
老客多笔-老客 / 老客多笔-新客 / 新客多笔 |
| 渠道 | media_source |
Facebook / Google / TikTok / Organic / 非投 |
| 产品定价 | product_info |
格式：期限_前置费率_后置费率，如 7_35_7 |
| 客户类型 | customer_type |
5=新客，10=老客 |
| 客户细分 | d_customer_type |
纯新 / 非纯新（仅对新客细分） |
| 前后置 | pf_type |
前置 / 后置 |
| 风控等级 | user_score_level |
RG等级，A→G，风险递增 |
| 短信权限 | sms_type |
有短信 / 历史短信 / 无短信 |
| 共债笔数 | multi_cases_in60D |
近60天放款且未结清的订单数，≥6笔标记为6+ |
| 轮次 | double_times |
用户借款轮次，0=新客，≥6轮标记为6+ |
指标字段
| 中文名 | 字段名 | 计算公式 | 说明 |
|---|---|---|---|
| 放款规模 | |||
| 订单数 | order_cnt |
— | 当期放款订单总数 |
| 合同金额 | principal |
— | 当期放款本金总额 |
| 件均 | principal, order_cnt |
principal ÷ order_cnt | 单笔订单平均金额 |
| 前置费率 | pf_amount, principal |
pf_amount ÷ principal | 前置产品手续费率 |
| 后置费率 | interest_amount, principal |
interest_amount ÷ principal | 后置产品手续费率 |
| 入催指标 | |||
| D-1订单入催 | dpd_1_repay, dpd_1_cnt |
(1 − dpd_1_repay ÷ dpd_1_cnt) × 100% | 到期前1天统计 |
| D-1金额入催 | dpd_1_repay_amount, dpd_1_cnt_amount |
(1 − dpd_1_repay_amount ÷ dpd_1_cnt_amount) × 100% | 到期前1天金额口径 |
| D0订单入催 | dpd0_repay, dpd0_cnt |
(1 − dpd0_repay ÷ dpd0_cnt) × 100% | 到期日当天统计 |
| D0金额入催 | dpd0_repay_amount, dpd0_cnt_amount |
(1 − dpd0_repay_amount ÷ dpd0_cnt_amount) × 100% | 到期日金额口径 |
| 利差指标 | |||
| D0利差 | D0_spread, principal |
D0_spread ÷ principal | 到期日当天利差 |
| D3利差 | D3_spread, principal |
D3_spread ÷ principal | D3节点利差 |
| D7利差 | D7_spread, principal |
D7_spread ÷ principal | D7节点利差 |
| D14利差 | D14_spread, principal |
D14_spread ÷ principal | D14节点利差 |
| D30利差 | D30_spread, principal |
D30_spread ÷ principal | D30节点利差 |
| 至今利差 | spread, principal |
spread ÷ principal | 当前全部利差 |
| 利差增长值 | |||
| D0-D3增长 | D0_spread, D3_spread, principal |
(D3_spread − D0_spread) ÷ principal | D0到D3利差增幅 |
| D3-D7增长 | D3_spread, D7_spread, principal |
(D7_spread − D3_spread) ÷ principal | D3到D7利差增幅 |
| D7-D14增长 | D7_spread, D14_spread, principal |
(D14_spread − D7_spread) ÷ principal | D7到D14利差增幅 |
| D14-D30增长 | D14_spread, D30_spread, principal |
(D30_spread − D14_spread) ÷ principal | D14到D30利差增幅 |
| D30+增长 | D30_spread, spread, principal |
(spread − D30_spread) ÷ principal | D30后利差增幅 |
| 坏账指标 | |||
| 订单坏账率 | outstanding_repay, outstanding_cnt |
(1 − outstanding_repay ÷ outstanding_cnt) × 100% | 全部到期后坏账率 |
| 金额坏账率 | outstanding_repay_amount, outstanding_cnt_amount |
(1 − outstanding_repay_amount ÷ outstanding_cnt_amount) × 100% | 全部到期后金额口径坏账率 |
Step 2 · 创建分析 Skill
根据数据字典，我将资产分析的核心指标转译为 SQL 查询逻辑，封装为 OpenClaw Skill。
Skill 的开发包含两个部分：
SKILL.md 编写
在 Skill 的 SKILL.md 中定义技能描述、适用场景、调用方式和输出格式。AI 通过读取 SKILL.md 理解该 Skill 的能力边界和使用方法。
SQL 脚本实现
在 scripts/ 目录下编写 Python 脚本，通过 SQL 查询 MySQL 获取原始数据，按指标口径计算后返回结构化结果。例如，针对 D0 入催率指标，SQL 逻辑如下：
SELECT
COUNT(*) AS order_cnt,
SUM(CASE WHEN dpd0_repay < dpd0_cnt THEN 1 ELSE 0 END) AS d0_overdue_cnt,
ROUND(SUM(CASE WHEN dpd0_repay < dpd0_cnt THEN 1 ELSE 0 END) * 1.0 / COUNT(*), 4) AS d0_rate
FROM asset_data
WHERE week_date = '{target_week}'
Step 3 · 指标计算测试
Skill 创建完成后，我进行了系统性的测试验证：
- 对同一指标在数据库中执行原始 SQL，将结果与 Skill 返回值逐一比对
- 测试边界情况，例如数据为空或特定维度无数据
- 验证不同日期和周维度的查询一致性
人工核对确认所有指标口径准确无误后，Skill 正式纳入 AI 的技能体系。
Step 4 · 场景化分析框架
在资产分析 Skill 的第一版本中，我先梳理出三个最常用的分析场景，分别对应新客、老客和利差预测三类核心需求。以下是三个场景的具体框架：
场景一：新客分析框架
| 拆分维度 | 具体分类 | 优先关注指标 |
|---|---|---|
| 产品类型 | 主策略、多笔 | 入催率、利差 |
| 渠道 | Facebook、Google、TikTok、Organic、非投 | 入催率、件均 |
| 包体 | 七个投放包 + APK包 | 入催率、利差 |
| RG等级 | A、B、C、D、E、F、G | 入催率、利差 |
场景二：老客分析框架
| 拆分维度 | 具体分类 | 优先关注指标 |
|---|---|---|
| 产品类型 | 主策略、多笔 | 入催率、利差 |
| 资产类型 | 前置、后置 | 入催率、利差 |
| 轮次 | 1~6+ 轮 | 入催率、坏账率 |
| 共债笔数 | 1~6+ 笔 | 入催率、利差 |
| RG等级 | A、B、C、D、E、F、G | 入催率、利差 |
| 包体 | 七个投放包 + APK包 | 入催率、利差 |
场景三：利差预测场景
| 切片节点 | 利差增长值 | 预测逻辑 |
|---|---|---|
| D0 | — | 当天利差基线 |
| D3 | D3 − D0 | 利差增长速率 |
| D7 | D7 − D3 | 利差增长速率 |
| D14 | D14 − D7 | 利差增长速率 |
| D30 | D30 − D14 | 利差增长速率 |
| 至今 | spread − D30 | 利差累计增速 |
Step 5 · 自动化数据更新
数据新鲜度是分析有效性的前提。我创建了定时任务（Cron Job），配置为每日自动执行：读取业务方提供的最新 Excel 数据文件，清理和转换数据格式后覆盖更新 MySQL 中对应日期的数据表。
定时任务执行时间设置为每日早六点，确保 AI 在每天工作开始前即可查询到最新数据。
后续扩展方向
资产分析 Skill 上线后，我按照相同的思路逐步构建转化分析 Skill 和催收分析 Skill，最终形成覆盖三大业务线的完整 AI 分析体系。
六、记忆管理
我通过定时任务实现了自动化的记忆管理体系。每天晚上 23:59，系统自动执行记忆管理流程，将当日对话记录归档并提取关键内容至长期记忆。
设计思路
记忆管理分为「短期记忆」和「长期记忆」两个层次，分别解决「上下文完整性」和「关键信息持续性」两个问题。
短期记忆
每天的对话内容和操作记录会自动写入当天的 .md 文件，例如 memory/2026-05-19.md。
这种设计的优势在于：
- 不依赖外部存储，本地文件即可保留完整上下文
- 按日期组织，回溯特定日期的对话极为方便
- 文件为 Markdown 格式，阅读体验良好
长期记忆
短期记忆文件会不断积累，如果全部作为长期记忆会导致文件过于臃肿。因此，我设计了每日一次的「记忆提取」流程：
- 每日结束时，从当天对话中抽取需要记住的关键内容
- 关键内容包括：业务决策、重要口径变更、用户偏好、系统架构调整
- 抽取后的内容写入
MEMORY.md文件，作为长期记忆的单一来源
MEMORY.md 采用结构化格式，按主题分类组织，便于后续快速检索。
飞书同步
为方便在手机端随时查看和管理长期记忆，我将 MEMORY.md 的内容配置为自动同步至飞书云文档。通过定时任务触发同步操作，将本地文件内容更新到飞书文档中。
这种设计的优势在于：
- 随时可在手机端查阅 AI 的长期记忆
- 飞书文档支持全文搜索，定位效率高
- 多端同步，不受设备限制
七、模型使用体验
我实际使用过以下模型，以下是各模型的使用感受汇总：
| 模型 | 使用场景 | 优点 | 缺点 | 个人体验 |
|---|---|---|---|---|
| MiniMax-2.5 | 日常对话、数据分析 | 对话理解稳定，业务语义解析准确，多轮对话上下文保持良好 | 复杂推理任务响应较慢 | 更擅长输出文章类文本，措辞专业，风格严谨，适合正式内容输出 |
| GLM-4.7 | 日常对话、数据分析 | 响应速度快，日常问答类任务表现均衡 | 长文本分析能力有限 | 适合非正式场景汇报，内容中会加入图表和表情，可读性强 |
| Doubao-Seed-2.0-Code | 代码生成、复杂推理 | 代码任务处理能力强 | 响应速度慢 | 较少使用 |
| Kimi-K2.5 | 日常对话、任务执行 | 对话理解与指令执行较均衡 | 响应速度慢 | 较少使用 |
| DeepSeek-V3.2 | 日常对话、复杂推理 | 复杂推理场景表现稳定 | 响应速度慢，主动解决问题的能力不强 | 不推荐使用 |
| GPT-5.4 | 日常对话、数据分析、任务执行 | 响应速度快，数据计算准确率极高 | — | 今年4月后开始使用，逐步替代 MiniMax 成为我的日常主力模型 |
八、总结
本文完整记录了从今年二月底调研到三月部署完成、再到四月切换主力模型的全过程。核心步骤可归纳为：
- 技术选型：二月底花一周时间调研，OpenClaw 是当时业务数据分析场景下最成熟的解决方案；火山引擎 Coding Plan 提供综合模型支持；飞书因公司生态成为唯一接入选择
- 环境准备：马来西亚节点云服务器（2 vCPU / 4 GiB / Ubuntu 20.04 LTS），Node.js 18.x 环境，飞书开放平台自建应用，Coding Plan API Key
- 部署接入：云服务器预装 OpenClaw，自动化助手完成 Coding Plan 模型接入，官方 CLI 完成飞书机器人创建和凭证绑定，参考火山引擎官方文档配置事件订阅和权限；三月通过 OpenClaw 社区帖子发现官方插件，解决飞书文档权限限制问题
- 业务定制：MySQL 建库导入数据 → 建立完整数据字典 → 封装资产分析 Skill → 构建场景化分析框架（新客 / 老客 / 利差预测）→ 定时任务每日自动更新数据
- 记忆管理：每天 23:59 自动执行记忆管理流程，短期记忆写入当日 .md 文件，关键内容提取至
MEMORY.md并同步至飞书云文档
经过三个月的使用，AI 助手已能够理解资产分析的业务逻辑，在飞书中提供实时数据查询和指标分析能力，大幅提升了日常数据观测效率。后续可按相同思路扩展转化分析和催收分析 Skill，形成完整的 AI 数据分析体系。
未来展望
接下来，我计划在以下几个方向继续扩展 AI 助手的能力：
- 转化分析 Skill：将申请→通过→放款全链路分析框架封装为 Skill，覆盖三大业务线中尚未接入的转化维度
- 催收分析 Skill：按照与资产分析相同的工作流，构建催收团队管理的分析 Skill，完善三条业务线的全覆盖
- 多 Agent 协作：探索将资产、转化、催收三个业务线拆分为独立 Agent，通过 OpenClaw 的多 Agent 架构实现更清晰的任务分工
- 指标异动告警：在现有定时任务基础上，增加指标异动检测逻辑，当核心指标出现异常波动时自动向飞书推送告警通知
参考文档
- 火山引擎官方文档：Coding Plan 接入 OpenClaw — https://www.volcengine.com/docs/82379/1928261?lang=zh
- 火山引擎官方文档：OpenClaw 接入飞书助手 — https://www.volcengine.com/docs/6396/2189942?lang=zh
- 飞书官方插件：OpenClaw 飞书接入配置 — https://bytedance.larkoffice.com/docx/MFK7dDFLFoVlOGxWCv5cTXKmnMh