客服记录查看器完整技术探索
（从"无路可走"到"柳暗花明"）
摘要：记录企微客服聊天记录review的完整探索过程——从发现"无历史可溯"的困境，到走错飞书表格的弯路，再到发现OpenClaw本地已有完整数据，最终自建微信风格查看器的全貌。包含技术选型决策、三次失败的尝试、关键顿悟时刻，以及可复用的经验。
引言：一个问题引发的连锁探索
2026年8月6日上午，老林提出了一个看似简单的问题：
"我想看看蟹蟹最近都和客户聊了什么，有什么规律可以总结。"
这个问题背后，是一个更深的焦虑：AI客服的聊天记录，有在记录吗？
当时我们刚刚完成双客服架构（蟹蟹青铜型 + 苏幕遮专业型）的部署，但却发现：
wecom-kf（微信客服）通道不提供历史记录查询功能。
这就像一家餐厅安装了收银机，却发现没有记账本——营收每天都在发生，但无从追溯。
第一节：无路可走的困境
发现：wecom-kf 是"实时流"
查阅 OpenClaw wecom-kf 插件源码后发现一个残酷的事实：
wecom-kf 是实时消息流，会话进行中可以看到消息内容，但会话结束后上下文不保留。
换句话说：
- ✅ 客户发来消息 → 蟹蟹能立即看到并回复
- ❌ 会话结束后 → 消息消失，无法回顾
这不像企业微信自建应用（wecom）有历史消息API可供查询，wecom-kf 的每一条消息都是过了这村没这店。
需求明确：我们需要什么？
老林对客服记录有三层需求：
| 层级 | 需求 | 用途 |
|---|---|---|
| 基础 | 全量记录每个会话 | 问题追溯、责任界定 |
| 进阶 | 客户维度的时间线 | 看单个客户的完整沟通史 |
| 价值 | 规律分析与话术沉淀 | 优化销售策略、制作营销素材 |
一句话：不是要看"有哪些消息"，而是要看"和谁聊了、聊了什么、聊得怎么样"。
第二节：第一次尝试——飞书表格（走错的路）
方案：企业微信API + 飞书多维表格
既然 wecom-kf 自身不存历史，那就从源头抓：
- 数据获取：通过企业微信
sync_msgAPI 拉取历史消息 - 数据存储：导入飞书多维表格，便于检索和分析
- 定时同步：Cron任务每天凌晨自动同步
执行：同步了274条消息
2026年8月6日中午，成功部署了同步脚本：
curl -X POST "https://qyapi.weixin.qq.com/cgi-bin/kf/sync_msg" \
-d '{"cursor": "'"$CURSOR"'", "token": "", "limit": 100}'同步结果：
- ✅ 成功拉取 274 条消息
- ✅ 识别 41 个独立客户
- ✅ 生成时间线格式
问题暴露：只有问题，没有答案
老林看了一眼飞书表格，指出两个致命问题：
问题1：数据结构错误
| 当前表格 | 应该是什么样 |
|---|---|
| 消息1：客户问"怎么买" | 客户A：14:30 问"怎么买" → 14:31 蟹蟹回复链接 |
| 消息2：客户问"多少钱" | 客户B：15:20 问"有优惠吗" → 15:21 蟹蟹回复活动 |
| ...（离散的消息堆） | ...（连续的对话流） |
问题2：只有客户提问，没有蟹蟹回复
sync_msg API 只返回客户发送给客服的消息，不返回蟹蟹的回复。
这意味着表格里有：
- ✅ "我要买蟹"
- ✅ "发海报看看"
- ❌ 蟹蟹的回复、海报、商品链接
"有效用的聊天记录都是按聊天对象存档的，客户一句问话，蟹蟹一句回复，组成了聊天记录。现在的表格只是客户留言列表。"
结论：飞书表格走不通
删除飞书表格，另寻他路。
第三节：峰回路转——OpenClaw早已记录一切
灵光一现：蟹蟹的回复去哪了？
如果 sync_msg API 拿不到蟹蟹的回复，那蟹蟹说的话去哪了？
回顾 OpenClaw 架构：
- 客户发消息 → wecom-kf 插件 → OpenClaw → 蟹蟹处理 → 蟹蟹回复
- 这个过程在 OpenClaw 内部是有记录的！
发现金矿：轨迹文件
OpenClaw 为每个会话都会生成轨迹文件（trajectory），记录了完整的输入输出：
~/.openclaw/agents/agent-8b978af6/sessions/
├── sessions.json # 会话索引
├── 055a4d6a-5944-4203-a278-77facfde0831.trajectory.jsonl
├── 07b3f2e1-...jsonl
└── ...顿悟：问题变成了"如何展示"
既然 OpenClaw 已经记录了完整对话，问题就从"如何捕获数据"变成了"如何展示数据"。
不再需要：
- ❌ 企业微信API定时同步
- ❌ 飞书表格存储
- ❌ 担心数据丢失
现在需要：
- ✅ 从轨迹文件提取对话
- ✅ 按客户ID组织
- ✅ 做一个仿微信的查看界面
第四节：自建方案——微信风格的聊天记录查看器
设计原则
"我需要一个跟看微信聊天记录一样的查看蟹蟹与客户的沟通记录。"
数据成果
提取结果：
- 45 个客户
- 486 条消息（包含客户问题和蟹蟹回复）
- 完整对话流：不再是离散的消息堆，而是连续的问答
第五节：UI改造——从"暗黑程序员风"到"微信原生风"
（本节详见第5期专栏）
三次迭代找到正确配色：
| 迭代 | 时间 | 配色方案 | 结果 |
|---|---|---|---|
| 第一次 | 22:35 | 左侧 #f7f7f7 | 对比不明显 |
| 第二次 | 22:40 | 左侧 #f2f2f2，右侧 #f5f5f5 | 还是不够对劲 |
| 第三次 | 22:45-23:00 | 左侧 #f2f2f2，右侧 #ffffff（微信原生） | ✅ 达成目标 |
第六节：方案对比与选择逻辑
| 方案 | 数据完整性 | 开发成本 | 用户体验 | 最终选择 |
|---|---|---|---|---|
| 飞书表格 | ❌ 只有客户消息 | 低 | ❌ 不是对话流 | ❌ 放弃 |
| WeCom API同步 | ❌ 只有客户消息 | 中 | ✅ 可做微信风 | ❌ 数据不全 |
| OpenClaw轨迹提取 | ✅ 双向完整 | 低 | ✅ 可做微信风 | ✅ 采用 |
第七节：可复用的经验
经验1：先找现有数据，再想办法捕获
这个项目的转折点在于发现：OpenClaw已经在记录一切。
经验2：选对数据存储形式
| 数据类型 | 适合形式 | 原因 |
|---|---|---|
| 结构化数据（客户信息、订单） | 表格/数据库 | 字段固定，适合查询 |
| 时序数据（聊天记录、日志） | 对话流/时间线 | 需要看连续性和上下文 |
经验3：用户心智模型优先
用户期待的是"看微信记录"——那就做成微信的样子。
经验4：数据与展示分离
轨迹文件 (JSONL) → 提取脚本 → chat_data.json → 网页渲染
↑ ↑
数据源 展示层结语：从"记录困境"到"记录自由"
2026年8月6日，从上午发现"无历史可溯"，到晚上自建查看器可用，不到12小时。
最终成果：
| 指标 | 数值 |
|---|---|
| 客户数 | 45 个 |
| 消息总数 | 486 条 |
| 数据完整度 | 100%（客户+蟹蟹双向） |
| 查看体验 | 微信原生风格 |
实现效果：系统已成功部署并投入日常使用。由于涉及真实客户沟通记录，演示环境仅限内部访问。