xiaobei 项目 sales-cs 客户数据库技能(customer-db)全解:SQLite 持久化、双标识符体系与 heartbeat 主动跟进机制

发布时间:2026/9/27 9:17:18
xiaobei 项目 sales-cs 客户数据库技能(customer-db)全解:SQLite 持久化、双标识符体系与 heartbeat 主动跟进机制 人工智能AI Agent大模型AI 应用媒体生成【免费下载链接】xiaobei为OPC/中小微企业量身打造的自媒体获客智能体项目地址https://gitcode.com/gh_mirrors/wi/xiaobei点击查看免费下载本文围绕 xiaobei 仓库中 sales-cs 的 customer-db 技能文档系统讲解销售客服智能体如何在其 workspace 内维护轻量级 SQLite 客户数据库两个极易混淆的客户标识符、cs_record与follow_up两张表的字段语义、全部具名脚本的用法与参数以及底层 hook 如何自动完成建档、状态流转与上下文注入。读完你既能直接照抄脚本组织自己的跟进流程也能理解其背后的插件级实现原理。一、技能定位跨会话保存客户商业推进状态customer-db是 sales-cs 专用技能目标非常聚焦让sales-cs在自身 workspace 的db/目录下维护一个轻量级 SQLite 数据库用于跨会话保存客户商业推进状态与基本画像。它解决的是对话型智能体最典型的痛点——每轮对话是无状态的而销售跟进天然需要长期记忆。按技能文档的约定数据库位置固定数据库文件./db/customer.dbschema 文件./db/schema.sql在仓库中schema 的规范定义位于 crews/sales-cs/db/schema.sql默认表为cs_record主键列为peer。技能文档特别强调了两条硬性约束路径固定数据库始终位于./db/customer.db默认表固定cs_record不提供原子 SQL 访问所有数据库操作必须通过文档列出的具名脚本完成禁止 agent 直接裸跑 SQL。此外初始化建表与默认记录创建由系统 hook 自动处理agent 无需手动初始化下文第五部分会从源码给出证据。二、两个重要标识符peer 与 user_id_external必读这是整个技能中最容易踩坑的部分。系统中一个客户有两个不同的标识符用途不同不可混用。peer来自 [CustomerDB] 块——数据库主键peer由系统 hook 从当前会话 sessionKey 中提取并注入是cs_record表的peer列的值。所有写库操作必须使用此值。它的本质是 awada sessionKey 中用户标识的安全过滤形式具体过滤规则见下文源码分析。user_id_external来自 Sender 块的 id 字段——awada 原始用户标识user_id_external由 awada-server 直接提供。每轮对话开始时openclaw 会在消息上下文中注入 Sender 信息块形如Sender (untrusted metadata): { label: ..., id: user_id_external, name: ... }需要与 awada 平台交互的技能如 exp-invite必须使用id字段即user_id_external而不是peer。也就是说peer是数据库内部的主键user_id_external是平台侧的原始用户标识二者在follow_up表中同时保存、各司其职见第四节。三、cs_record 字段含义与先更新再回复原则cs_record表保存客户基本画像与商业推进状态字段语义如下与 schema.sql 的 DDL 完全对应。字段含义取值/格式peer客户数据库主键等于 awada sessionKey 中的用户标识安全过滤后的形式TEXT PRIMARY KEYbusiness_status客户商业推进深度free未购买仍在了解/观望exp_invited已邀请体验未正式付费club已进入 vip club 会员阶段subs预留未来业务用现阶段未启用club_inclub加入日期建议格式YYYY-MM-DD用于后续跟进 club 一年有效期的过期管理purpose客户主要业务应用场景例如新媒体运营、客户寻找、信息搜集、单纯想尝试下 Agent、需要一个 AI 助理、寻求 OEM/代理合作prompt_source客户从哪里了解到我们例如GitHub、微信群、朋友推荐、公众号、视频号、小红书、知乎、atomgit、其他 AI 推荐created_at首次建档时间默认strftime(%Y-%m-%d %H:%M:%S,now,localtime)updated_at最近对话时间每次收到消息由 hook 自动更新同上值得注意subs在文档中标注为预留未来业务用现阶段未启用但从底层源码看下文第五节payment_success静默命令当前正是把business_status置为subs并写入club_in——两者并不矛盾文档描述的是业务语义约定源码描述的是当前实现。【重要】先更新记录再回复客户技能文档规定了一条铁律当本轮获得更明确的信息时先调用cs-update.sh更新purpose和/或prompt_source该 turn 不得包含任何面向客户的文本再在下一个 turn 输出对客户的回复。命令形式./skills/customer-db/scripts/cs-update.sh \ --peer [CustomerDB].peer \ --purpose 新媒体运营 \ --prompt-source GitHub参数规则所有参数均为可选只传有明确新值的字段脚本会自动忽略空值不覆盖已有记录源码层面对此有严格保证见下文。更新原则文档原文要点只在拿到更明确的信息时更新不要用空字符串覆盖已有值不要根据模糊猜测改写已有信息business_status由系统 hook 负责支付/入群事件不在此处更新。从 cs-update.sh 的实现可以印证这套约束脚本先校验--peer必填、数据库必须存在随后通过sql_quote()函数将单引号转义为两个单引号防止注入SET 子句只拼接非空字段——若purpose/prompt_source均为空脚本直接输出⚠️ Nothing to update ... skipping并以 0 退出码返回天然满足不覆盖已有值只要有任何更新末尾总会追加updated_atstrftime(%Y-%m-%d %H:%M:%S,now,localtime)保证最近对话时间始终准确。四、follow_up 表主动跟进任务的生命周期管理follow_up表记录客户延迟购买意向供 heartbeat 定时跟进。状态流转为pending → sent_once → completed对应已创建未发送 → 已发第一次等待回复 → 已完成。-- 摘自 crews/sales-cs/db/schema.sql CREATE TABLE IF NOT EXISTS follow_up ( id INTEGER PRIMARY KEY AUTOINCREMENT, peer TEXT NOT NULL, user_id_external TEXT NOT NULL, -- Sender 块的 id 字段awada 原始用户标识 follow_up_at TEXT NOT NULL, -- 计划跟进时间 YYYY-MM-DD HH:MM reason TEXT NOT NULL, -- 跟进原因供 agent 和 heartbeat 参考 context_summary TEXT, -- 对话摘要 推荐跟进话术方向 status TEXT DEFAULT pending, sent_text TEXT, -- 实际发送的跟进消息内容 retry_count INTEGER DEFAULT 0, created_at TEXT DEFAULT (strftime(%Y-%m-%d %H:%M:%S, now, localtime)), completed_at TEXT, FOREIGN KEY (peer) REFERENCES cs_record(peer) );这张表同时保存peer数据库主键与user_id_external平台原始标识正是第二节双标识符设计的落点跟进任务用peer关联客户档案用user_id_external在发送时定位平台用户。创建跟进任务技能文档要求若同一客户已有pending状态的旧任务先取消旧任务再创建新任务避免同客户堆积多条未决跟进。# 第一步取消同一客户的旧 pending 任务 ./skills/customer-db/scripts/follow-up-cancel-pending.sh \ --peer [CustomerDB].peer # 第二步创建新任务 ./skills/customer-db/scripts/follow-up-create.sh \ --peer [CustomerDB].peer \ --user-id-external Sender.id \ --follow-up-at YYYY-MM-DD HH:MM \ --reason 原因如客户说明天发工资再买 \ --context-summary 客户核心兴趣点和建议跟进角度从源码看follow-up-create.sh 强制校验--peer、--user-id-external、--follow-up-at、--reason四项必填context_summary可选并对所有值做单引号转义后插入follow-up-cancel-pending.sh 实际上是把该 peer 下所有pending任务置为completed并写入completed_at为新建任务腾出唯一的活动任务位。heartbeat 完整执行流程见 crews/sales-cs/HEARTBEAT.md。过期清理超过 48 小时仍为pending的任务视为客户失联自动标记完成./skills/customer-db/scripts/follow-up-expire.shfollow-up-expire.sh 的判定条件是datetime(follow_up_at, 48 hours) datetime(now,localtime)即计划跟进时刻 48 小时仍未发送则过期。注意当前 HEARTBEAT.md 中已明确不再清理过期任务不管隔了多少天该跟进还是跟进但原则仍是最多跟进两次pending → sent_once → completed。这与follow-up-expire.sh的保留并不冲突前者是 heartbeat 的运行约定后者是独立的兜底清理工具由谁在何时调用由部署方决定。查询到期任务./skills/customer-db/scripts/follow-up-due.shfollow-up-due.sh 使用sqlite3 -header -separator $\t输出 tab 分隔表格含 header字段依次为id / peer / user_id_external / follow_up_at / reason / context_summary / status且仅返回status IN (pending,sent_once)且follow_up_at 当前本地时间的任务按follow_up_at升序排列。标记首次已发送pending → sent_once./skills/customer-db/scripts/follow-up-mark-sent.sh \ --id id \ --sent-text 发送的消息内容follow-up-mark-sent.sh 要求--id与--sent-text均必填将状态置为sent_once、写入实际发送文案并执行retry_countretry_count1对应 heartbeat 中的第一次发送。标记完成sent_once → completed./skills/customer-db/scripts/follow-up-complete.sh \ --id id \ --sent-text 发送的消息内容follow-up-complete.sh 同样要求两个参数必填仅在statussent_once时生效写入最终文案与completed_at并递增retry_count对应 heartbeat 中的第二次发送发送后任务终结。heartbeat 如何驱动跟进来自 HEARTBEAT.md每次心跳触发时运行follow-up-due.sh查询到期任务若无到期任务仅 header 或空回复HEARTBEAT_OK结束对每条到期任务阅读context_summary生成自然的跟进话术简短、克制、不施压→ 调用 proactive-send 发送 → 按当前状态调用follow-up-mark-sent.sh或follow-up-complete.sh更新记录若发送失败exit 1跳过本条不更新状态下次心跳自动重试。话术原则基于context_summary中的客户兴趣点生成一句话开场不超过三句话不要催促。示例您好之前聊到加入 vip club 的事不知道今天方便看看吗五、底层实现awada 插件的 CustomerDB 钩子与静默命令技能文档中的系统 hook自动初始化等说法在仓库源码中有完整的落点——awada/src/customerdb.ts该特性原为独立插件customerdb-hook后合并进 awada-extension使 openclaw.json 中单个插件条目即可同时覆盖通道与 CRM。启用方式在 openclaw.json 中配置pluginConfig.customerdb.agentId即可激活plugins: [{ path: awada, config: { customerdb: { agentId: sales-cs, workspaceDir: /home/.../.openclaw/workspace-sales-cs } } }]配置项语义对应 CustomerDbConfigagentId附加客户上下文的 agent 标识默认sales-csworkspaceDir包含db/customer.db的 workspace 目录默认~/.openclaw/workspace-sales-cs数据库路径拼接为workspaceDir/db/customer.dbschema 路径为workspaceDir/db/schema.sql。peer 的安全归一化与解析normalizePeer() 按顺序执行三条规则去首尾空白 → 转小写openclaw 构建 sessionKey 时已小写化 peerId因此命令路径与 hook 路径保持一致→ 剔除 ASCII 控制字符\t会破坏 tab 分隔的 sqlite3 输出解析\n/\r破坏行式输出\0是 SQLite C 层的空字节隐患。这解释了文档中经过安全过滤后的形式的准确含义。resolvePeerFromSessionKey() 通过正则/^agent:[^:]:awada:direct:(.)$/失败时退化为容错版本/^agent:.*:awada:direct:(.)$/从 sessionKey 中提取 peer这正是hook 从 sessionKey 注入 peer的实现路径。幂等建库与自动迁移ensureDatabaseReady() 启动时执行若cs_record表不存在则优先读取schema.sql建表读取失败则回退到内置 DDLfollow_up表则始终以幂等方式确保存在还包含一次兼容迁移——若存在旧列awada_customer_id则重命名为user_id_externalSQLite 3.25 不支持 RENAME COLUMN 时静默跳过。这印证了文档中初始化与默认记录创建由系统 hook 自动处理。每轮上下文注入与先更新再回复的自动化保障before_prompt_build 钩子 是核心机制校验ctx.agentId与配置一致、解析出 peer调用ensurePeerRow()做 upsert——INSERT ... ON CONFLICT(peer) DO UPDATE SET updated_at...即每次收到消息自动建档并刷新updated_at对应字段语义表中的最近对话时间由 hook 自动更新查询客户行并注入STATIC_RULES系统上下文前置部分声明[CustomerDB].peer用于所有 SQL 操作、user_id_external用于 awada 交互、仅在信息更明确时更新字段等规则与动态[CustomerDB]上下文块后置部分含 peer/business_status/club_in/purpose/prompt_source/updated_at若存在sent_once状态的跟进还会追加[FollowUp]上下文提醒 agent之前主动跟进过该客户、客户本次是主动回复、跟进任务已自动完成并调用completeSentOnceFollowUps()将已发送的跟进自动置为 completedpending 任务不会被误杀因为尚未发送只能由 heartbeat/cancel/expire 推进。也就是说先更新记录再回复客户既靠技能文档的行为约定也靠 hook 每轮自动注入客户上下文来支撑 agent 做出正确决策。静默业务命令payment_success 与 club_join文档指出business_status由系统 hook 负责支付/入群事件。源码中对应两个注册在插件上的静默命令不经过 LLM直接返回NO_REPLYpayment_success实现见 customerdb.ts把该 peer 的business_status置为subs并写入当日club_inclub_join实现见 customerdb.ts把business_status置为club并写入当日club_in。二者均通过resolvePeerForCommand()从channel awada的 senderId 解析 peer与消息 hook 路径保持一致的归一化实现支付/入群事件自动改写商业状态无需 agent 干预。六、约束与注意事项使用清单最后技能文档的约束条款值得作为部署检查清单路径固定数据库始终位于./db/customer.db默认表固定cs_record不得向用户暴露内部表结构和内部状态字段agent 不得把 peer、status 等内部字段写入对外消息会话隔离必须遵守不同 peer 的数据不能混用初始化和默认记录创建由系统 hook 自动处理无需手动操作不提供原子 SQL 访问所有数据库操作必须通过具名脚本完成具体包括 cs-update.sh、follow-up-create.sh、follow-up-cancel-pending.sh、follow-up-due.sh、follow-up-expire.sh、follow-up-mark-sent.sh、follow-up-complete.sh。综上customer-db 技能 awada 插件钩子构成了 sales-cs 的完整客户记忆闭环hook 负责建档、状态事件与上下文注入具名脚本负责画像更新与跟进任务流转heartbeat 负责到点触达而peer/user_id_external的双标识符体系则保证了数据库内部与外部队列如 proactive-send、exp-invite之间始终使用正确的主键。赞分享人工智能AI Agent大模型AI 应用媒体生成【免费下载链接】xiaobei为OPC/中小微企业量身打造的自媒体获客智能体项目地址https://gitcode.com/gh_mirrors/wi/xiaobei点击查看免费下载相关推荐RuboCop v1.6.1 版本修复解读ConfigObsoletion::ExtractedCop 在 Bundler 未激活场景下的异常处理RuboCop v1.6.1 版本修复解读ConfigObsoletion::ExtractedCop 在 Bundler 未激活场景下的异常处理 导读 本文人工智能AI Agent大模型AI 应用媒体生成sales-cs 对外客服启用全流程解读 xiaobei 项目中的 sales-cs-enablement 编排型技能sales cs 对外客服启用全流程解读 xiaobei 项目中的 sales cs enablement 编排型技能 导读 本文以 sales cs en人工智能AI Agent大模型AI 应用媒体生成xiaobei sales-cs 主动发送技能proactive-send基于 relay 网关 outbound 端点实现客户消息主动触达xiaobei sales cs 主动发送技能proactive send基于 relay 网关 outbound 端点实现客户消息主动触达 导读 pro人工智能AI Agent大模型AI 应用媒体生成上一篇终极硬盘健康监控指南DiskInfo完全使用手册下一篇flutter_secure_storage高级配置自定义加密算法与安全选项详解创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询