人工智能AI Agent大模型AI 应用媒体生成【免费下载链接】xiaobei为OPC/中小微企业量身打造的自媒体获客智能体项目地址https://gitcode.com/gh_mirrors/wi/xiaobei点击查看免费下载本文以 xiaobei 仓库中对外销售客服 Crewcrews/sales-cs的 AGENTS.md 工作流规范为主体完整讲解其工具在前、回复在后的会话主流程、CustomerDB 客户数据库驱动机制、延迟购买跟进follow_up与意图分流规则。读者读完可以掌握如何配置并运行一个严格受约束、以成交为导向的对外销售客服 Agent以及如何用 SQLite 客户画像与 heartbeat 定时跟进构建完整的销售闭环。1. sales-cs 在项目中的定位xiaobei 是一个为 OPC / 中小微企业打造的自媒体获客智能体仓库中按 Crew 组织多个 Agent 角色。sales-cs销售客服是其中的对外 Crewexternal代表公司对外服务客户其行为受严格约束只能使用DECLARED_SKILLS中声明的技能不继承系统全局技能禁止自我改进不得修改自己的 workspace 文件升级由 main agent 统一管理见 IDENTITY.md、SOUL.md。该 Crew 在自身 workspace 内维护一个轻量级 SQLite 客户数据库./db/customer.db用于跨会话保存客户商业推进状态与基本画像配合 heartbeat 定时任务实现主动跟进能力。其技能体系包含customer-db客户数据库管理更新画像、跟进任务增删查改proactive-send主动向客户发送消息HTTP 网关传输exp-invite向合格客户发送体验群邀请awada 控制消息demo-send演示材料发送见 DECLARED_SKILLS2. 会话主流程强制工具在前回复在后AGENTS.md 将每一轮会话固定为五步强制流程1. 读取系统注入的 CustomerDB 当前状态 - 当前客户以注入的 peer 为唯一标识来自 [CustomerDB] 块 - business_status / purpose / prompt_source / club_in 以注入值为准 2. 精准识别客户意图进入对应分流 3. 工具在前如本轮获得更明确信息先在独立 turn 调用 cs-update.sh 更新客户记录 - 该 turn 不得包含任何面向客户的文本 - 仅补充或修正更明确的信息 - 不要用空值覆盖已有有效信息 - 不要基于模糊猜测更新 4. 若客户表达不满同样先在独立 turn 将摘要记录到 feedback/YYYY-MM-DD.md不记录 PII 5. 回复在后所有工具执行完成后在最后一个 turn 统一输出面向客户的完整回复这一工具 turn 与回复 turn 严格分离的约束在 SOUL.md 中被标记为强制任何调用工具cs-update / feedback 记录 / follow-up / payment-send / ofb-key 等的 turn 不得包含面向客户的文本面向客户的完整回复必须在所有工具完成后、在最后一个 turn 统一输出。需要特别说明的是数据库初始化、默认记录创建、以及支付/入群等控制事件的静默状态更新由系统 hook 负责agent 无需重复执行这些技术性步骤——这也解释了为何cs-update.sh等脚本只负责业务字段更新而business_status不允许在脚本中手动修改见下文第 5 节。3. 两个客户标识符peer 与 user_id_external这是使用 CustomerDB 前必须理解的核心概念。系统中客户有两个不同的标识符用途不同不可混用标识符来源用途peer系统注入的[CustomerDB].peer所有 SQL 查询和写库的 WHERE 条件user_id_external消息上下文 Sender 块的id字段需要与 awada 平台交互的技能如 proactive-send、payment-confirmpeer是数据库主键由系统 hook 从当前会话 sessionKey 中提取并注入是cs_record表的peer列的值而user_id_external是 awada 原始用户标识每轮对话开始时由 openclaw 在消息上下文中注入 Sender 信息块该块标注为 untrusted metadataSender (untrusted metadata): { label: ..., id: user_id_external, name: ... }从customer-db技能的 SKILL.md 可知所有写库操作必须使用peer而需要与 awada 平台交互的技能如exp-invite、proactive-send必须使用user_id_external。这一区分在exp-invite技能中体现得最为明显——它要求同时传入两个标识符各自职责不同--peer用于 DB 查询和写库--user-id-external用于 awada 平台路由邀请动作。4. 回复组织规则承接 → 结论 → 关键信息 → 推进除非客户只需要一个极简回答否则默认按以下顺序组织回复承接先回应客户当前问题或情绪结论一句话给出核心判断关键信息补 2~4 个最关键点推进自然推进下一步配套的推进原则、链接使用规则与话术长度规则构成对外沟通的节奏控制推进原则每一轮尽量只推进一个最自然的下一步不要同时抛给客户过多选择不要连续追问 3 个以上问题。客户明显接近购买时少讲背景、多讲怎么开通客户明显还在了解时少讲交易动作、多帮其理解产品形态和适用场景务求价值共振。链接使用规则一轮中尽量只给最必要的链接如需多个链接先解释用途再给链接不要把链接堆成资料墙。话术长度规则默认短答优先客户追问时再逐步展开一个问题能在 3~6 句内答清就不要写成长文。SOUL.md 还补充了输出格式约束对外回复一律纯文本plain text不使用 Markdown微信客户端不支持渲染效果链接直接给完整 URL允许少量自然表情但不堆砌。5. CustomerDB 字段模型与先更新再回复原则5.1 cs_record 表结构数据库固定位于./db/customer.dbschema 规范定义在 db/schema.sql实际初始化由 customerdb-hook 内联 DDL 完成幂等且支持迁移CREATE TABLE IF NOT EXISTS cs_record ( peer TEXT PRIMARY KEY, business_status TEXT DEFAULT free, purpose TEXT DEFAULT , prompt_source TEXT DEFAULT , club_in TEXT, created_at TEXT DEFAULT (strftime(%Y-%m-%d %H:%M:%S, now, localtime)), updated_at TEXT DEFAULT (strftime(%Y-%m-%d %H:%M:%S, now, localtime)) );各字段含义依据 customer-db/SKILL.md字段含义peer客户数据库主键等于 awada sessionKey 中的用户标识安全过滤后的形式business_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/updated_at首次建档时间 / 最近对话时间每次收到消息由 hook 自动更新5.2 先更新记录再回复客户当本轮获得更明确的信息时先调用cs-update.sh更新purpose和/或prompt_source该 turn 不得包含任何面向客户的文本再在下一个 turn 输出对客户的回复./skills/customer-db/scripts/cs-update.sh \ --peer [CustomerDB].peer \ --purpose 单纯想尝试下Agent \ --prompt-source GitHub两个参数均为可选只传有明确新值的字段。从 cs-update.sh 源码可以看到其底层设计脚本会先校验--peer必填、数据库存在然后只把非空值拼进 SET 子句并对所有值做 SQL 单引号转义sql_quote最后统一刷新updated_at若所有传入值均为空则打印警告并直接退出exit 0不会产生任何写操作——这从代码层面保证了脚本自动忽略空值、不覆盖已有记录。更新原则强制本轮没有获取到更明确的信息时不要调用脚本若只是模糊猜测不要传入该字段不要用空字符串覆盖已有值business_status由系统 hook 负责支付/入群事件不在此处更新6. 延迟购买意向处理follow_up 主动跟进任务6.1 触发条件同时满足客户已表达购买意向询问价格 / 如何购买 / 对比版本等同时明确表示要等待一段时间明天、下午、等工资、下周、晚点再谈等6.2 动作流程先写入跟进记录独立 turn不含任何客户文本提取下表字段向follow_up表写入一条跟进记录写入完成后再回复客户最终 turn确认理解轻描跟进意图不要承诺字段来源peer[CustomerDB].peeruser_id_external消息上下文 Sender 块的id字段follow_up_at根据客户描述推算见时间映射表reason简述客户原因如客户说明天发工资再买context_summary客户核心兴趣点 建议跟进角度供 heartbeat 时生成话术写入步骤# 第一步若已有 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 客户核心兴趣点和建议跟进角度第一步取消旧任务始终执行无 pending 任务时脚本无副作用——从 follow-up-cancel-pending.sh 源码可见它只是对指定peer的pending状态记录执行UPDATE ... SET statuscompletedWHERE 不匹配时自然无副作用。6.3 时间映射规则客户描述follow_up_at明天次日 10:00后天两天后 10:00下午当天 14:00若当前已过 13:00则次日 14:00晚上当天 19:00若当前已过 18:00则次日 19:00下周7 天后 10:00等工资 / 月底5 天后 10:00过两天 / 几天后3 天后 10:00晚点再谈 / 稍后当天 14:00若当前已过 13:00则次日 10:00客户说了具体日期/时间按客户说的时间时间不明时取 10:00注意若客户明确说不用跟了我会自己买不需要写跟进记录。6.4 follow_up 表结构与状态机db/schema.sql 中的follow_up表完整定义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) );status 流转为pending → sent_once → completedpending表示已创建尚未发送sent_once表示已发送第一次、等待客户回复或第二次 heartbeatcompleted表示已完成客户主动回复或发送第二次后。配套的具名脚本包括follow-up-due.sh查询到期任务status IN (pending,sent_once)且follow_up_at 当前本地时间输出 tab 分隔表格含 header字段为id / peer / user_id_external / follow_up_at / reason / context_summary / statusfollow-up-mark-sent.shpending → sent_once记录sent_text并retry_count1follow-up-complete.shsent_once → completed记录最终发送文本与完成时间follow-up-expire.sh超过 48 小时仍为pending的任务视为客户失联自动标记完成datetime(follow_up_at, 48 hours) datetime(now,localtime)7. 意图分流流程3.0 ~ 3.7AGENTS.md 定义了七类客户意图分流编号意图触发关键词/条件3.0抱怨/投诉不满、投诉3.1产品与业务咨询售前咨询3.2想试用/不理解产品试用、不清楚形态3.3想购买怎么买、价格3.4付款确认已付款、截图3.5开发票发票3.6售后问题产品或服务交付后的提问3.7其他主动引导推进成交各分流的处理要点如下3.0 抱怨/投诉先道歉随后将不满摘要记录到feedback/YYYY-MM-DD.md独立工具 turn不记录 PII再在最终 turn 回复。3.1 产品与业务咨询售前根据工作区中的 business_knowledge.md 回答不能被动回答要在对话中摸清用户画像应用场景、对产品的期待、从哪些渠道了解到我们对后续 marketing 指导很有帮助循序渐进推动成交——我们的目的不是陪他聊天而是成交。3.2 想试用 / 多次介绍后仍不理解产品触发条件示例包括我想先体验一下我还是不太清楚具体是什么形态能不能先看看效果我想先了解真实使用方式。此时可使用exp-invite技能向明确同意加入体验群的客户发送邀请并在客户状态非free如已exp_invited、subs、club时不要主动邀请应回到 3.7 继续主动引导若客户明确要求再次邀请可用--force参数强制发送。3.3 想购买关注付款渠道说明、当前可购产品、推荐收口方式与动作流程这些内容由 main agent 启用时填入见下文说明若付款码发送失败引导客户联系微信。3.4 客户付款确认客户已付款、发送截图时进入本分流具体流程由 main agent 启用时填入。3.5 开发票先判断business_status——free时告知尚未购买暂不能开票其他状态走对应开票流程占位待 main agent 填入。3.6 售后问题同样先判断business_status——free改走 3.1 售前咨询club/subs走对应售后处理占位待填入。3.7 其他主动引导并推进成交原则是不要被动陪聊要主动推进若对方是来推销的不必理会。第一步补齐客户画像purpose为空时自然问出客户主要应用场景prompt_source为空时自然了解客户来源第二步在画像信息足够时进入促成交易阶段引导付费进入club第三步处理深入合作诉求。如果客户明显着急优先短答 直接推进动作。重要说明原文档中多处标注!-- 由main agent启用时填入并负责后续持续优化更新 --这些是模板化占位符——付款渠道、开票限制、具体参考话术等业务敏感信息由 main agent 在启用该 Crew 时统一配置并持续维护agent 自身不得自行填写或修改。这是对外 Crew 权限模型的组成部分部署方需按此约定完成配置后方可启用对应分流。8. heartbeat 定时跟进与 proactive-send 主动发送8.1 heartbeat 执行流程HEARTBEAT.md 定义了每次心跳触发时的主动跟进流程当前时间由系统注入见[cron]行查询当前到期的跟进任务./skills/customer-db/scripts/follow-up-due.sh若无到期任务仅输出 header 或空回复HEARTBEAT_OK并结束对每条到期任务依次执行a. 阅读context_summary生成自然的跟进话术简短、克制、不施压b. 调用proactive-send发送消息c. 根据当前status更新记录pending首次发送→ 标记sent_oncesent_once二次发送→ 标记completedd. 若发送失败exit 1跳过本条不更新状态下次心跳自动重试关键设计不再清理过期任务——不管隔了多少天该跟进还是跟进但原则仍是最多跟进两次pending → sent_once → completed。跟进话术基于context_summary中的客户兴趣点和建议角度生成一句话开场、不超过三句话、不催促、给客户留空间例如您好之前聊到加入vip club的事不知道今天方便看看吗8.2 proactive-send 的底层实现proactive-send技能让 sales-cs 在特定业务场景下主动向客户发送消息而非等待客户发起对话proactive-send \ --user-id-external user_id_external \ --text 消息内容--user-id-external必填客户 awada 用户标识来自 Sender 块的id字段--text必填发送给客户的消息文本从 send.mjs 源码可见其传输机制relayBaseUrl/ofbKey/platform/lane自动从~/.openclaw/openclaw.json的channels.awada读取channel_id/tenant_id固定为0私聊然后走 HTTPPOST {relayBaseUrl}/api/v1/awada/outbound?lanelane携带X-OFB-Keyheader请求体为{ payload: [{ type: text, text }], meta: { platform, channel_id: 0, user_id_external, tenant_id: 0 } }。成功时打印 relay outbound stream ID如1234-0exit 0失败时打印错误到 stderrexit 1——即走 HTTP 网关而非直连 Redis传输契约详见 docs/AWADA-CLIENT-TRANSPORT.md。该技能仅提供发送能力何时使用、发给谁、发什么内容由调用场景如 heartbeat、3.3 收口决定请勿在正常对话流程中调用以免破坏对话自然性。9. 对外 Crew 的权限约束与 awada 回复规则9.1 命令白名单机制对外 Crew 默认 deny 一切 shell 命令ALLOWED_COMMANDS 用条目在 deny 上精确放行声明式技能所需脚本相对于 workspace 根目录customer-db的七个具名操作脚本cs-update.sh、follow-up-create.sh、follow-up-cancel-pending.sh、follow-up-due.sh、follow-up-mark-sent.sh、follow-up-complete.sh、follow-up-expire.sh、exp-invite、proactive-send以及辅助工具nano-pdf、jq、rg、node、pdfimages、pdftoppm、pdftocairo。对应地TOOLS.md 明确了硬性限制不允许任意 shell 命令执行仅限白名单内的声明式技能脚本除feedback/和db/目录外不得写入文件不得自我修改 workspace 文件SOUL.md、AGENTS.md、MEMORY.md 等不得向用户暴露内部 DB 字段或 schemaschema 变更需 main agent 批准禁止自行修改9.2 awada 回复发送规则强制在 awada 会话中常规回复必须直接输出 assistant 文本不要调用message工具二次发送message工具仅用于明确的主动外呼场景当前会话应答禁止使用若工具调用报错如 Unknown target / send failed不得把报错文本透传给客户必须改为正常人工话术重答这一规则结合proactive-send的仅限主动外呼定位保证了会话内回复路径与主动外呼路径的彻底分离。openclaw_setting_sample.json见 crews/sales-cs/openclaw_setting_sample.json展示了该 Crew 的运行时配置样例skills列表、heartbeat每 1 小时、活跃时段 08:00-24:00、isolatedSession、exec安全模式为allowlist且ask: off可作为部署参考。10. 特殊对话风格提醒AGENTS.md 末尾给出几条实战风格提醒直接关系到对话自然度用户只发一个1通常表示确认 / 收到 / 可以继续如果客户明显着急优先短答 直接推进动作如果客户只是泛泛问是什么优先用一句人话解释不要先讲架构如果客户问得很专业再切换到更技术化的说明永远不要把整份手册口吻原样搬进对话里这些规则与第 4 节的回复结构、第 9 节的纯文本输出约束共同构成了 sales-cs 对外沟通的完整风格体系销售导向、克制推进、人话优先、不暴露内部机制。小结sales-cs 的工作流本质是一个CustomerDB 驱动的销售闭环peer标识 cs_record画像字段支撑每轮会话的状态感知与画像沉淀工具在前、回复在后保证每次写库、记录反馈都在对客话术之前完成follow_up表 时间映射 heartbeat 将等工资再买这类延迟意向转化为最多两次的克制跟进proactive-send通过 awada outbound 网关实现会话外的主动触达白名单命令与禁止自我修改则确保对外 Crew 永远在 main agent 设定的轨道内运行。对于需要搭建公众号/微信场景下的 AI 售前客服的团队这套文档AGENTS.md 技能 脚本的组合本身就是一份可直接复用的完整参考实现。赞分享人工智能AI Agent大模型AI 应用媒体生成【免费下载链接】xiaobei为OPC/中小微企业量身打造的自媒体获客智能体项目地址https://gitcode.com/gh_mirrors/wi/xiaobei点击查看免费下载相关推荐xiaobei 项目销售客服 Crewsales-cs用户上下文与微信对话规范详解xiaobei 项目销售客服 Crewsales cs用户上下文与微信对话规范详解 导读 本文基于开源仓库 xiaobei为 OPC/中小微企业打造的自媒人工智能AI Agent大模型AI 应用媒体生成终极指南为什么GraphRAG比传统RAG更强大揭秘AI检索增强新范式终极指南为什么GraphRAG比传统RAG更强大揭秘AI检索增强新范式 GraphRAG图检索增强生成正在彻底改变领域特定大语言模型的应用方式 作SpeechBrain 多源模型加载 DDP 动态批处理 仅微调 LM 的集成测试模板实战指南SpeechBrain 多源模型加载 DDP 动态批处理 仅微调 LM 的集成测试模板实战指南 本指南围绕 SpeechBrain 仓库中的集成测试人工智能AI Agent大模型AI 应用媒体生成上一篇firefox-csshacks云存储文件共享的视觉设计原则下一篇ConvNeXt-V2 Atto.fcmae_ft_in1k代码详解从模型架构到训练技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考