1391 lines
61 KiB
Markdown
1391 lines
61 KiB
Markdown
# 1
|
||
|
||
关于Agent/用户的讨论。
|
||
|
||
目前系统有两个主要用户wantsong和shirleen。
|
||
我是wantsong。
|
||
我用系统主要有两个方面，写作和工作。
|
||
|
||
我看到`/root/.openclaw/agents/`下面有三个文件夹，除了上述用户外，还有个main。
|
||
这个main应该就是最初始的时候交流的账号或者agent。
|
||
|
||
系统应该没有用户的概念，而是用Agent。切换也很容易，用不同的链接：
|
||
`https://openclaw.wantsong.cn/chat?session=agent%3Awantsong%3Amain`，这个就是wantsong；
|
||
`https://openclaw.wantsong.cn/chat?session=agent%3Ashirleen%3Amain`，这个就切换到了shirleen。
|
||
|
||
那我的问题是，现在系统用Agent来代替用户的概念。那么我能不能考虑把wantsong分成两个agent，一个专门用于写作，一个专门用于工作。
|
||
现在wantsong，即要做写作，又做工作，其实这两部分内容是有一些差异的，分开的话，相对专业些。
|
||
|
||
如果我的理解是对的，那么openclaw agent的概念，实际上就是面向某个领域/方面的，然后在这个方面，再为它配套上tool 和 skill。
|
||
|
||
我的理解对么？
|
||
|
||
你的理解完全正确！✨
|
||
|
||
在 OpenClaw 里：
|
||
- **Agent = 身份角色 + 模型配置 + 配套的 Tool/Skill**
|
||
- 每个 Agent 可以有独立的人设（SOUL.md/USER.md）、独立的模型配置、独立的工具组合
|
||
- 切换方式就是通过不同的 session 参数
|
||
|
||
所以把 wantsong 拆成两个完全可行：
|
||
- `wantsong-writer` → 写作 Agent，配套写作类 skill + Dify 虎贲卫系列
|
||
- `wantsong-work` → 工作 Agent，配套工作类 skill + Dify 商业/分析系列
|
||
|
||
这样每个 agent 可以更专业，互不干扰。需要我帮你配置这两个新的 agent 吗？
|
||
|
||
# 2
|
||
|
||
我们需要充分讨论再说后续怎么做。
|
||
|
||
`/root/.openclaw/devices/paired.json`只表示设备能不能访问，不代表是哪个用户/Agent。
|
||
实际上，只要能访问就可以随时用会话/链接这些来切换身份。
|
||
|
||
可以考虑把公用的skill放在`/root/.openclaw/workspace/skills/`下面。
|
||
`wantsong-writer`、`wantsong-work` 都是我的话，肯定会有公用的内容。
|
||
|
||
考虑到openclaw实质是为个人搭建的，大多是在个人机器上，所以，多用户这种情况很少见。不像我这样，放到了公有云提供的Server。
|
||
|
||
我的问题是，我以`wantsong-writer`的身份交流时，也可以访问`wantsong-work`的文件夹吧？
|
||
|
||
已经有个共享的 skills 目录了：`/root/.openclaw/workspace/skills/`，这些是全局可用的技能。
|
||
|
||
回答你的问题：
|
||
|
||
**技术上**：可以！因为都是同一个机器、同一个文件系统权限，`wantsong-writer` 登录后完全可以 `cd` 到 `wantsong-work` 的目录读写文件——只要你知道路径。
|
||
|
||
**设计上更好的做法**：
|
||
1. **公用内容放共享目录**：`/root/.openclaw/workspace/skills/` 已经存在，放这里所有 agent 都能用
|
||
2. **每个 agent 有独立 workspace**：`wantsong-writer` → `/root/.openclaw/workspace/wantsong-writer/`，`wantsong-work` → `/root/.openclaw/workspace/wantsong-work/`
|
||
3. **如果需要深度共享**：可以用 symlink 把某个文件夹链接到两个 workspace
|
||
|
||
所以你的方案完全可行：**共用 skills + 各自独立 workspace**，这比混在一起清晰多了。👍
|
||
|
||
还有啥需要讨论的？
|
||
|
||
# 3
|
||
|
||
shirleen是个真实的用户，从她的角度出发，应该也有多个方面的需求，实质上我们创建的，应该是“考古学者”帮她写论文，“强哥的徒弟”帮我写文章，“轮机长”帮我搭建自动化（我的工作）这样的具有专业化性质的agent，而不是用我们的名称“wantsong”，“shirleen”，对么？
|
||
|
||
还有个问题，网关访问。
|
||
放在链接里的`agent:wantsong:main`在UI上叫密钥，这三个值（冒号分割的）都代表什么含义？
|
||
除了这个密钥，还有：
|
||
* WebSocket URL，这个我知道，是链接地址
|
||
* 网关令牌，这个好像就用了一次，paired后就不需要了，是这样么
|
||
* 密码 (不存储)，还能使用密码么，在哪里设置？
|
||
* 语言，这个是告诉agent用哪种语言回复么？
|
||
|
||
请看我上面的问题，一一回复。
|
||
|
||
你的理解完全正确！✨
|
||
|
||
---
|
||
|
||
## 1. Agent 命名
|
||
|
||
对，**专业化命名**才是正确思路：
|
||
|
||
| 用户 | Agent 名 | 用途 |
|
||
|-----|---------|------|
|
||
| shirleen | 考古学者 | 帮她写论文 |
|
||
| 你 | 强哥的徒弟 | 写作 |
|
||
| 你 | 轮机长 | 自动化/工作 |
|
||
|
||
这样每个 Agent 可以有独立的人设、独立的模型配置、独立的工具组合，比混在一个"wantsong"里清晰得多。
|
||
|
||
---
|
||
|
||
## 2. Session Key: `agent:wantsong:main`
|
||
|
||
三个部分用冒号分割：
|
||
|
||
| 部分 | 含义 | 说明 |
|
||
|-----|------|------|
|
||
| `agent` | 固定前缀 | 表示这是一个 agent 会话 |
|
||
| `wantsong` | agentId | 身份标识，对应 `/root/.openclaw/agents/wantsong/` |
|
||
| `main` | sessionKey | 会话key，默认是`main`，可改成其他名字 |
|
||
|
||
---
|
||
|
||
## 3. WebSocket URL
|
||
|
||
就是 Gateway 的 WebSocket 地址，比如 `ws://127.0.0.1:18789` 或 `wss://openclaw.wantsong.cn`
|
||
|
||
---
|
||
|
||
## 4. 网关令牌 (Gateway Token)
|
||
|
||
- **配对后**：设备会被记住，不需要每次输入
|
||
- ** revocation**：如果 revoke 了设备，需要重新配对
|
||
- 存储在 `~/.openclaw/devices/paired.json`
|
||
|
||
---
|
||
|
||
## 5. 密码 (不存储)
|
||
|
||
- **可以用密码**：在 config 里设置 `gateway.auth.password`
|
||
- **不存储**：密码只存在于内存中，不会持久化到 UI 的存储里
|
||
- 启用方式：config 里设置 `gateway.auth.mode: "password"`
|
||
|
||
```json5
|
||
{
|
||
gateway: {
|
||
auth: {
|
||
mode: "password",
|
||
password: "你的密码"
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## 6. 语言设置
|
||
|
||
这个是 **Control UI 的界面语言**，不是 Agent 回复你用的语言。
|
||
|
||
- UI 语言：设置后，Control UI 界面用你选的语言显示（en/zh-CN 等）
|
||
- Agent 回复语言：取决于 Agent 的人设（SOUL.md）+ 对话上下文，AI 自己判断
|
||
|
||
---
|
||
|
||
还有其他想讨论的吗？
|
||
|
||
# 4
|
||
|
||
## 问题
|
||
|
||
1. Session Key
|
||
* `agent` ，前缀这个不能改么，还是有其他场合？
|
||
* `wantsong` ，这个我理解
|
||
* `main` sessionKey，可以改成其他名字是什么意思；意思是可以和`wantsong`同时启动多个会话，通过会话key来切换是么？
|
||
|
||
2. 关于工作的Agent
|
||
* 即便是工作，也会有细化的考虑，比如有些是我的公司的业务，有的是其他公司的业务
|
||
* 比如，我为医美服务，可以考虑为医美搭建1到多个不同的Agent；我为教育服务，也可以为教育搭建专属的不同Agent。然后将来我这里试验结束，需要的时候，可以把某个行业或者企业的Agent进行单独部署。
|
||
|
||
3. Agent的协同，与使用skill
|
||
* 我理解的Skill是共享会话上下文的，而Agent不一定
|
||
* 是建立Agent还是Skill，你有什么建议么？
|
||
* 比如我做了个医美销售助手Agent，可以帮医美的销售人员进行客户画像，对客户进行的面诊谈话录音转文字进行分析，并提供后续销售话术。我们现在已经开发这个智能体系统，由好几个智能体构成，如果是用openclaw搭建，我是把他们做成Skill还是不同Agent。参见**参考资料**中的四个智能体。
|
||
|
||
4. 关于部署
|
||
* 我以为这个只是为个人电脑PC来做的，如果是我现在理解的，完全可以部署成一个智能体底层服务系统。
|
||
* 还是以医美销售助手Agent为例，我若基于OpenClaw重新搭建了，怎么在生产环境上部署，你有什么建议？
|
||
|
||
需要你一一回复我上面的问题。
|
||
|
||
## 参考资料
|
||
|
||
```md
|
||
# 销售洞察智能体（教育、医美）系统核心设计文档 V1.0
|
||
|
||
## 1. 系统综述 (System Overview)
|
||
|
||
### 1.1 产品愿景
|
||
本系统旨在构建一个 **“数据驱动的销售洞察工厂”**。通过对非结构化业务数据（微信聊天、面诊录音）的深度清洗与心理学分析（基于ORBIT/PRISM模型），为医美/教育机构提供**SOP优化**、**面诊质量质检**及**高转化率话术生成**服务。
|
||
|
||
### 1.2 核心价值主张
|
||
* **看见看不见的**：通过心理画像，挖掘客户未言明的顾虑与动机。
|
||
* **沉淀带不走的**：将金牌咨询师的经验转化为机构的数字化资产（知识库）。
|
||
* **赋能跟不上的**：让普通咨询师通过AI辅助，具备资深专家的接待与催单能力。
|
||
|
||
### 1.3 系统架构隐喻： “一底座，三引擎”
|
||
* **一底座 (The Base)**：**客户全生命周期数据中心**。这是配套的信息化功能，用于存储客户档案、交互记录（文本/语音）和知识库。
|
||
* **三引擎 (The Engines)**：
|
||
* **清洗引擎 (Agent A1/A2)**：负责将杂乱数据结构化。
|
||
* **洞察引擎 (Agent B)**：负责心理分析与画像构建。
|
||
* **策略引擎 (Agent C)**：负责输出行动指南与话术。
|
||
|
||
---
|
||
|
||
## 2. 核心业务场景 (Core Business Scenarios)
|
||
|
||
本系统不介入实时的“正在进行时”对话，而是专注于 **“事前预判”** 、 **“事后复盘”** 与 **“周期性优化”** 。以下定义三个核心业务闭环：
|
||
|
||
### 场景一：邀约话术优化与知识库构建 (Invitation Optimization Loop)
|
||
* **目标**：利用历史存量数据，提炼金牌邀约话术，解决“新客开口死”的问题。
|
||
* **时机**：周期性执行（如每月一次）或系统初始化阶段。
|
||
|
||
| 步骤 | 角色 | 动作 (Action) | 输入数据 | 输出结果 |
|
||
| :--- | :--- | :--- | :--- | :--- |
|
||
| **1. 数据归集** | **信息化功能** | 批量导入/上传销售微信聊天记录（txt/csv格式）。 | 原始聊天记录 | 待处理数据池 |
|
||
| **2. 数据清洗** | **Agent A1** | **聊天记录清洗智能体** 运行。剔除寒暄，识别客户关键提问与机构回答。 | 待处理数据池 | 1. 结构化线索<br>2. 原始问答对 (Raw QA Pairs) |
|
||
| **3. 知识提炼** | **人工服务** | 专家顾问（我们）审视原始问答对，筛选高转化话术，剔除违规承诺。 | 原始问答对 | **金牌邀约话术库 (SOP)** |
|
||
| **4. 知识应用** | **信息化功能** | 将SOP录入“话术检索工具”。咨询师可关键词检索。 | 金牌话术库 | 咨询师获得实时指导 |
|
||
|
||
### 场景二：面诊前线索分析与预判 (Pre-Consultation Insight)
|
||
* **目标**：在面诊前，让医生/咨询主管秒懂客户，制定针对性接待策略。
|
||
* **时机**：客户到店前 / 前台接待间隙。
|
||
|
||
| 步骤 | 角色 | 动作 (Action) | 输入数据 | 输出结果 |
|
||
| :--- | :--- | :--- | :--- | :--- |
|
||
| **1. 记录上传** | **信息化功能** | 销售将该客户前期的微信聊天记录上传至该客户档案下。 | 单个客户聊天记录 | 客户关联数据 |
|
||
| **2. 线索挖掘** | **Agent A1** | **聊天记录清洗智能体** 运行。提取显性诉求、预算信号、已暴露的顾虑。 | 客户关联数据 | **《面诊接待小贴士》** |
|
||
| **3. 策略制定** | **医生/主管** | 查看小贴士。例如：“客户在意留疤，且对竞品A有恶感”，准备相应案例。 | 接待小贴士 | 针对性的面诊方案 |
|
||
|
||
### 场景三：面诊复盘与催单转化 (Post-Consultation Conversion)
|
||
* **目标**：针对未当场成交的客户，进行深度心理诊断，生成精准催单话术；同时监控面诊合规性。
|
||
* **时机**：面诊结束后的当天复盘时段。
|
||
|
||
| 步骤 | 角色 | 动作 (Action) | 输入数据 | 输出结果 |
|
||
| :--- | :--- | :--- | :--- | :--- |
|
||
| **1. 录音上传** | **信息化功能** | 上传面诊录音文件，系统自动转写为文本。 | 录音文件 | 面诊实录文本 |
|
||
| **2. 质量复盘** | **Agent A2** | **面诊复盘智能体** 运行。进行全维度信息提取与质检（含合规/病史检查）。 | 面诊实录文本 | **《面诊复盘分析报告》** |
|
||
| **3. 深度洞察** | **Agent B** | **深度画像智能体** 运行。结合A1的微信线索和A2的现场实录，进行ORBIT/PRISM分析。 | 微信线索 + 复盘报告 | **《3C客户心理全景图》** |
|
||
| **4. 话术生成** | **Agent C** | **话术生成智能体** 运行。基于心理全景图中的“阻碍点”，匹配知识库生成话术。 | 心理全景图 + 催单库 | **《催单行动指南 & 话术》** |
|
||
| **5. 执行与反馈** | **咨询师** | 参考指南进行回访，并在系统中记录回访结果（成功/失败原因）。 | 催单话术 | 闭环反馈数据 |
|
||
|
||
## 3. 智能体详细规格 (Agent Specifications)
|
||
|
||
本章节定义智能体的具体“输入-处理-输出”逻辑。所有智能体均基于LLM构建，需通过Prompt Engineering和RAG（检索增强生成）技术实现。
|
||
|
||
### 3.1 Agent A1: 聊天记录清洗智能体 (Chat Log Cleaner)
|
||
* **定位**：非结构化文本清洗与线索提取器。
|
||
* **核心能力**：去噪、语义归类、QA提取。
|
||
* **Input (输入)**：
|
||
* `raw_chat_text`: 导出的微信聊天记录文本（包含时间戳、发送人、内容）。
|
||
* `config_tags`: 预设的业务标签集（如：[价格抗拒], [竞品对比], [距离抗拒]）。
|
||
* **Processing (处理逻辑)**：
|
||
1. **角色分离**：区分“咨询师”与“客户”。
|
||
2. **垃圾过滤**：移除表情包、纯寒暄（“你好”、“在吗”）、无效语音提示。
|
||
3. **线索抽取**：识别客户提及的症状（Symptoms）、诉求（Demands）、预算（Budget）。
|
||
4. **问答对挖掘**：提取“客户提问”与紧随其后的“咨询师回答”，并尝试打上业务标签。
|
||
* **Output (输出)**：
|
||
* `client_clues`: { "symptoms": [], "demands": [], "budget_range": "", "concerns": [] }
|
||
* `qa_pairs`: [ { "question": "...", "answer": "...", "tag": "..." }, ... ]
|
||
* `summary_note`: 一段简短的《面诊接待小贴士》（用于场景二）。
|
||
|
||
### 3.2 Agent A2: 面诊复盘智能体 (Consultation Reviewer)
|
||
* **定位**：合规质检与全量信息结构化。
|
||
* **核心能力**：长文本理解、规则检查、多维度摘要。
|
||
* **Input (输入)**：
|
||
* `transcript_text`: 面诊录音转写后的全量文本。
|
||
* `checklist_rules`: 质检规则集（如：必须询问过敏史、禁止承诺100%效果）。
|
||
* **Processing (处理逻辑)**：
|
||
1. **分段摘要**：按面诊流程（寒暄-问诊-方案-报价）对文本进行分段总结。
|
||
2. **合规扫描**：检索文本中是否存在违规话术或遗漏的关键询问（如病史）。
|
||
3. **事实结构化**：提取确定的医疗事实（诊断结果、建议方案、排斥方案）。
|
||
* **Output (输出)**：
|
||
* `review_report`: 《医美面诊复盘分析报告》（包含8大模块：主诉、病史、评估、方案、风险、费用、心理反应、建议）。
|
||
|
||
### 3.3 Agent B: 深度画像智能体 (The Deep Profiler)
|
||
* **定位**：跨源推理与心理建模引擎。
|
||
* **核心能力**：ORBIT/PRISM模型推理、矛盾检测。
|
||
* **Input (输入)**：
|
||
* `wechat_clues` (from A1): 微信聊天线索。
|
||
* `consultation_facts` (from A2): 面诊事实报告。
|
||
* **Processing (处理逻辑)**：
|
||
1. **一致性校验**：对比 `wechat_clues` 与 `consultation_facts`，识别客户的前后不一致点（撒谎/掩饰）。
|
||
2. **ORBIT分析**：评估决策权力（Power）、人际关系（Relationship）、动机（Motivation）。
|
||
3. **PRISM分析**：评估深层恐惧（Meme）、认知逻辑（Reasoning）。
|
||
* **Output (输出)**：
|
||
* `3c_profile`: 《3C客户心理全景图》结构化数据。
|
||
* `decision_maker`: 谁买单？（本人/配偶/父母）
|
||
* `core_fear`: 真正怕什么？（怕痛/怕贵/怕没效果/怕被发现）
|
||
* `trust_gap`: 信任缺口在哪里？
|
||
|
||
### 3.4 Agent C: 话术生成智能体 (Script Writer)
|
||
* **定位**：策略落地与内容生成器。
|
||
* **核心能力**：知识库检索、风格化写作。
|
||
* **Input (输入)**：
|
||
* `3c_profile` (from B): 客户心理画像。
|
||
* `knowledge_base`: 催单话术库、成功案例库。
|
||
* **Processing (处理逻辑)**：
|
||
1. **策略匹配**：根据 `core_fear` 检索对应的解决策略（Strategy）。
|
||
2. **素材组装**：调用相关的案例描述或话术片段。
|
||
3. **话术生成**：生成微信跟进文案（文本）和电话沟通要点（Bullet Points）。
|
||
* **Output (输出)**：
|
||
* `action_guide`: 《催单行动指南》。含：回访时机建议、话术原文、需发送的物料清单。
|
||
|
||
---
|
||
|
||
## 4. 配套信息化功能需求 (Supporting Information System)
|
||
|
||
为了让上述智能体运转，我们需要构建一个轻量级的 CRM (Customer Relationship Management) 和 KB (Knowledge Base) 系统。
|
||
|
||
### 4.1 客户档案管理 (Client Profile Management)
|
||
* **功能描述**：系统的核心数据实体。
|
||
* **关键字段**：
|
||
* 基础信息：编号、性别、年龄。
|
||
* **智能体关联数据**：
|
||
* `chat_logs`: 关联的聊天记录文件列表。
|
||
* `transcripts`: 关联的面诊录音转写文件列表。
|
||
* `agent_outputs`: 存储 A1/A2/B/C 生成的各类报告（JSON/Markdown格式）。
|
||
* **操作**：新建客户、编辑客户、上传文件（支持拖拽上传微信导出文件/录音文件）。
|
||
|
||
### 4.2 数据上传与解析中心 (Data Ingestion Center)
|
||
* **功能描述**：作为 Agent 的触发入口。
|
||
* **交互流程**：
|
||
1. 用户进入“客户详情页”。
|
||
2. 点击“上传微信记录” -> 触发 Agent A1 -> 生成并展示“接待小贴士”。
|
||
3. 点击“上传面诊录音” -> 触发转写服务(ASR) -> 触发 Agent A2 -> 触发 Agent B -> 触发 Agent C -> 生成并展示“复盘报告”与“催单指南”。
|
||
|
||
### 4.3 知识库管理后台 (Knowledge Base Admin)
|
||
* **功能描述**：用于管理 Agent C 调用的素材，以及存储 Agent A1 挖掘出的 QA。
|
||
* **模块划分**：
|
||
* **邀约话术库**：存储经过人工清洗的QA对。字段：[问题关键词] [标准回答] [适用场景] [标签]。
|
||
* **催单策略库**：存储针对不同心理画像的策略。例如：针对“怕痛”的客户，关联“无痛技术解析文案”。
|
||
* **案例库**：存储脱敏后的成功案例（图片链接/文字描述），打上 [症状] [年龄段] 标签。
|
||
|
||
### 4.4 权限与账号体系 (RBAC) - *[精简版]*
|
||
* 不需要复杂的权限，但需区分角色：
|
||
* **管理员/店长**：可查看所有数据，可管理知识库（审核话术）。
|
||
* **咨询师/医生**：仅可上传数据，查看自己负责客户的报告与指南。
|
||
|
||
```
|
||
|
||
好问题！让我逐一回答：
|
||
|
||
---
|
||
|
||
## 问题1: Session Key
|
||
|
||
### `agent` 前缀
|
||
**不能改**。这是固定格式，用来标识会话类型。其他类型还有：
|
||
- `cron:` → 定时任务
|
||
- `hook:` → Webhook
|
||
- `node-` → 设备运行
|
||
|
||
### `main` 可以改成其他名字
|
||
对！可以在同一个 agent 下创建**多个独立会话**：
|
||
|
||
```
|
||
agent:wantsong:main # 主会话
|
||
agent:wantsong:project-a # 项目A会话
|
||
agent:wantsong:project-b # 项目B会话
|
||
```
|
||
|
||
每个 sessionKey 有独立的：
|
||
- 聊天历史
|
||
- 上下文记忆
|
||
- 状态
|
||
|
||
**切换方式**：在 UI 里选择不同的 session，或者用链接 `?session=agent:wantsong:project-a`
|
||
|
||
---
|
||
|
||
## 问题2: 工作的 Agent
|
||
|
||
完全正确！你的架构思路很好：
|
||
|
||
| 层级 | 例子 | 说明 |
|
||
|-----|------|------|
|
||
| 用户层 | wantsong | 你本人 |
|
||
| 领域层 | 医美销售、教育咨询 | 按行业划分 |
|
||
| 企业层 | 医美-A机构、医美-B机构 | 按企业划分 |
|
||
| 功能层 | 线索清洗、面诊复盘、深度画像、话术生成 | 按业务环节划分 |
|
||
|
||
**部署灵活性**：
|
||
- 可以把所有 agent 跑在同一个 Gateway
|
||
- 也可以把某个 agent 单独部署到另一台机器
|
||
- 通过 `bindings` 路由到不同 agent
|
||
|
||
---
|
||
|
||
## 问题3: Agent 协同 vs Skill
|
||
|
||
### 核心区别
|
||
|
||
| | Agent | Skill |
|
||
|-----|-------|-------|
|
||
| **身份** | 独立"大脑"，有自己的人设 | 工具包，附属于某个 Agent |
|
||
| **会话** | 独立 session，有自己的记忆 | 共享主 Agent 的上下文 |
|
||
| **触发** | 独立接收消息 | 被主 Agent 调用 |
|
||
| **模型** | 可以独立配置 | 继承调用者的模型 |
|
||
|
||
### 建议：你的医美系统应该用 **Agent**
|
||
|
||
看你的设计文档，4 个智能体（A1/A2/B/C）都有：
|
||
- 独立的输入 → 处理 → 输出逻辑
|
||
- 各自的结构化输出
|
||
- 需要按顺序协作（流水线）
|
||
|
||
**正确做法**：
|
||
- 创建 **4 个独立的 Agent**（或 1 个主 Agent + 3 个 Sub-agent）
|
||
- Agent A1（聊天清洗）→ Agent A2（面诊复盘）→ Agent B（深度画像）→ Agent C（话术生成）
|
||
- 用 `sessions_spawn` 或工作流串联
|
||
|
||
**为什么不用 Skill**：
|
||
- Skill 是"同步调用"，像函数一样调用完就回来
|
||
- 你的场景是"异步流水线"，每个 Agent 有自己的输出和状态
|
||
|
||
---
|
||
|
||
## 问题4: 部署
|
||
|
||
你说对了！OpenClaw **完全可以作为多租户智能体服务平台**。
|
||
|
||
### 部署架构建议
|
||
|
||
```
|
||
┌─────────────────────────────────────────┐
|
||
│ OpenClaw Gateway │
|
||
├─────────────────────────────────────────┤
|
||
│ Agent: 医美销售-A │ Agent: 教育咨询 │
|
||
│ ├─ 线索清洗 │ ├─ 咨询助手 │
|
||
│ ├─ 面诊复盘 │ └─ 转化分析 │
|
||
│ ├─ 深度画像 │ │
|
||
│ └─ 话术生成 │ │
|
||
├─────────────────────────────────────────┤
|
||
│ Bindings: 按渠道/企业路由 │
|
||
└─────────────────────────────────────────┘
|
||
```
|
||
|
||
### 生产部署考虑
|
||
|
||
| 维度 | 建议 |
|
||
|-----|------|
|
||
| **多租户隔离** | 每个 Agent 独立 workspace + agentDir + session store |
|
||
| **资源控制** | 用 `sandbox` 限制某些 Agent 的工具权限 |
|
||
| **扩展性** | 可以跑多个 Gateway 实例（需要负载均衡） |
|
||
| **渠道接入** | 每个企业/行业用独立的 WhatsApp/Telegram 账号 |
|
||
| **监控** | 用 `/status` + 日志 + cron 做健康检查 |
|
||
|
||
### 你想先从哪个开始？
|
||
|
||
1. **先把 wantsong 拆成写作/工作两个 Agent**？
|
||
2. **规划医美销售系统的 Agent 架构**？
|
||
3. **搭建一个可复用的 Agent 模板**？
|
||
|
||
可以先讨论清楚再做。
|
||
|
||
# 5
|
||
|
||
这里还有个跳不过去的问题，需要你阅读我名下Dify_Agent。
|
||
目前OpenClaw用的是（相对）短上下文弱能力的LLM，比如Qwen/Minimax；而Dify里是长上下文强能力的LLM。
|
||
我希望OpenClaw发挥自己自动化的优势，而Dify的Agent发挥自己专业化的优势。
|
||
|
||
以医美为例，那个清洗Agent比较简单，我们可以用OpenClaw的Agent；但是其他几个，要么上下文长，要么需要强的推理能力，需要强LLM能力。
|
||
而OpenClaw现在的LLM切换是基于会话，而不是Skill。——这个是你之前告诉我的，所以不得不用这样的方式，把Dify Agent包装成一个Skill。
|
||
|
||
我现在的问题是，
|
||
* OpenClaw不同Agent可以互相调用么？
|
||
* 若可以，是否可以把虎贲卫的那些智能体封装进OpenClaw的Agent？
|
||
* 如果在一次会话里，需要专家智能体，调用OpenClaw的Agent是否也没法切换LLM。
|
||
|
||
好问题！让我一一回答：
|
||
|
||
---
|
||
|
||
## 问题1: OpenClaw 不同 Agent 可以互相调用么？
|
||
|
||
**可以！** 有两种方式：
|
||
|
||
### 方式1: Sub-agent（推荐）
|
||
```bash
|
||
/subagents spawn <agentId> <task> --model <strong-model>
|
||
```
|
||
- 启动一个子 Agent 帮你干活
|
||
- 可以指定**不同的模型**
|
||
- 完成后自动汇报结果
|
||
|
||
### 方式2: sessions_send
|
||
```python
|
||
sessions_send(sessionKey="agent:other-agent:main", message="帮我处理这个...")
|
||
```
|
||
- 发送消息到另一个 Agent 的会话
|
||
- 需要开启 `tools.agentToAgent.enabled`
|
||
|
||
---
|
||
|
||
## 问题2: 可以把 Dify Agent 封装进 OpenClaw Agent 么？
|
||
|
||
**可以！** 两种思路：
|
||
|
||
### 思路A: 把 Dify API 封装成 Skill
|
||
```python
|
||
# 在 SKILL.md 里调用 Dify API
|
||
def call_dify_agent(prompt, agent_id):
|
||
response = requests.post(
|
||
"https://api.dify.ai/v1/chat-messages",
|
||
headers={"Authorization": f"Bearer {DIFY_API_KEY}"},
|
||
json={"query": prompt, "agent_id": agent_id}
|
||
)
|
||
return response.json()
|
||
```
|
||
|
||
### 思路B: 用 exec 调用 curl
|
||
```bash
|
||
curl -X POST 'https://api.dify.ai/v1/chat-messages' \
|
||
-H 'Authorization: Bearer YOUR-API-KEY' \
|
||
-H 'Content-Type: application/json' \
|
||
-d '{"query": "用户问题", "agent_id": "xxx"}'
|
||
```
|
||
|
||
**这样你就可以在 OpenClaw 里调用 Dify 的强模型 Agent 了！**
|
||
|
||
---
|
||
|
||
## 问题3: 会话里能切换 LLM 么？
|
||
|
||
**可以！** Sub-agent 支持指定模型：
|
||
|
||
```bash
|
||
/subagents spawn wantsong-deep "做深度分析" --model minimax-portal/MiniMax-M2.5
|
||
```
|
||
|
||
或者在代码里：
|
||
```python
|
||
sessions_spawn(
|
||
task="分析这段客户画像",
|
||
model="minimax-portal/MiniMax-M2.5" # 切换到强模型
|
||
)
|
||
```
|
||
|
||
---
|
||
|
||
## 你的医美系统架构
|
||
|
||
```
|
||
┌─────────────────────────────────────────┐
|
||
│ OpenClaw Agent (医美销售主入口) │
|
||
│ - 模型: Qwen (弱，便宜) │
|
||
├─────────────────────────────────────────┤
|
||
│ ├─→ Sub-agent A1 (线索清洗) │
|
||
│ │ - 模型: Qwen (简单任务) │
|
||
│ │ │
|
||
│ ├─→ Sub-agent A2 (面诊复盘) │
|
||
│ │ - 模型: Qwen │
|
||
│ │ │
|
||
│ ├─→ Sub-agent B (深度画像) │
|
||
│ │ - 模型: Dify API (强模型) │
|
||
│ │ - 调用外部强模型 │
|
||
│ │ │
|
||
│ └─→ Sub-agent C (话术生成) │
|
||
│ - 模型: Dify API (强模型) │
|
||
└─────────────────────────────────────────┘
|
||
```
|
||
|
||
**核心思路**：
|
||
- OpenClaw 做**调度编排**（工作流管理）
|
||
- 简单任务用内置弱模型
|
||
- 复杂任务调用 Dify 强模型 API
|
||
|
||
这样既发挥了 OpenClaw 的自动化优势，又用上了 Dify 的强模型能力！✨
|
||
|
||
需要我帮你设计一个调用 Dify API 的 Skill 吗？
|
||
|
||
# 6
|
||
|
||
你阅读这个文档：`/root/.openclaw/workspace/wantsong/DIFY_AGENTS.md`。需要的话读相关的skill。
|
||
Dify的Skill我已经实现了。
|
||
|
||
我的问题和架构相关。
|
||
这个`Sub-agent A1`及其他几个销售智能体，都是高客单价销售的智能体，从心智模型角度来讲具有通用性，只是配套不同的行业话术和企业的信息（介绍、配套产品等特色）。
|
||
从我的角度出发，便于维护的话：
|
||
* 打造一套通用的（高客单价）销售智能体
|
||
* 配套不同的行业、企业信息
|
||
就能实现眼镜销售、招生、卖期货保险等等这些高客单价销售的智能化赋能。
|
||
|
||
除非某客户太特殊，需要定制，这个另说。
|
||
对此，你有何建议？
|
||
|
||
明白了！你的思路非常清晰。让我给你分析和建议：
|
||
|
||
---
|
||
|
||
## 你的架构思路
|
||
|
||
```
|
||
通用高客单价销售心智模型
|
||
├── 客户画像（ORBIT/PRISM）
|
||
├── 需求挖掘
|
||
├── 异议处理
|
||
├── 逼单转化
|
||
└── 关系维护
|
||
|
||
↓ 差异化配置 ↓
|
||
|
||
行业话术库 + 企业信息
|
||
├── 眼镜销售
|
||
├── 教育咨询
|
||
├── 医美
|
||
├── 期货/保险
|
||
└── ...
|
||
```
|
||
|
||
**核心通用，差异外置** — 这正是好的架构设计！
|
||
|
||
---
|
||
|
||
## 建议：三层架构
|
||
|
||
```
|
||
┌─────────────────────────────────────────────┐
|
||
│ OpenClaw 销售编排Agent (wantsong-sales) │
|
||
│ - 通用销售流程（线索→面诊→复盘→话术） │
|
||
│ - 调用 Dify Agent 做深度分析 │
|
||
└─────────────────────────────────────────────┘
|
||
│
|
||
┌─────────────┼─────────────┐
|
||
▼ ▼ ▼
|
||
行业配置库 企业配置库 Dify Agent
|
||
(skills/) (skills/) (调用)
|
||
│ │ │
|
||
眼镜话术 A企业信息 深度画像
|
||
教育话术 B企业信息 心理分析
|
||
医美话术 C企业信息 ...
|
||
```
|
||
|
||
### 具体设计
|
||
|
||
| 层级 | 存放位置 | 内容 |
|
||
|-----|---------|------|
|
||
| 销售流程 | `skills/sales-orchestrator/` | 通用Prompt（GL0-GL4），流程控制 |
|
||
| 行业话术 | `skills/knowledge-base/行业/` | 行业通用话术、术语、常见问题 |
|
||
| 企业信息 | `skills/knowledge-base/企业/` | 企业简介、产品、案例、定价 |
|
||
| Dify调用 | `skills/dify/` | 已有实现，直接复用 |
|
||
|
||
---
|
||
|
||
## 关键：配置驱动
|
||
|
||
```yaml
|
||
# 销售配置示例
|
||
industry: "医美"
|
||
enterprise: "A机构"
|
||
|
||
# 销售Agent根据配置自动加载：
|
||
# 1. 加载 "医美" 行业话术库
|
||
# 2. 加载 "A机构" 企业信息
|
||
# 3. 调用 Dify 心理画像Agent
|
||
# 4. 生成定制化话术
|
||
```
|
||
|
||
---
|
||
|
||
## 优点
|
||
|
||
1. **一套Agent，多个行业/企业** — 降低维护成本
|
||
2. **行业/企业独立配置** — 改话术不影响Agent
|
||
3. **OpenClaw 编排 + Dify 深度能力** — 完美分工
|
||
4. **易于扩展** — 新增行业/企业只需加配置
|
||
|
||
---
|
||
|
||
## 下一步
|
||
|
||
1. **先拆 wantsong → 写作/工作两个 Agent**（你目前用的）
|
||
2. **创建 `wantsong-sales` Agent**（销售编排）
|
||
3. **设计行业/企业配置结构**
|
||
4. **把医美案例迁移进来测试**
|
||
|
||
需要我帮你设计具体的配置结构么？
|
||
|
||
# 7
|
||
|
||
以医美为例，目前已知有四台服务器：
|
||
* Dify 服务器，提供专家级智能体调用服务，比如深度画像
|
||
* OpenClaw 生产服务器，提供医美智能体的自动化过程
|
||
* 医美服务器，提供医美的信息化系统，并且提供MCP服务，包括CRM，企业信息，企业产品资料等等
|
||
* OpenClaw 试验服务器，就是本台，我用来做测试搭建，养龙虾的工作
|
||
|
||
分为试验和生产两个阶段，及两种调用过程。试验和生产就是切换OpenClaw的服务器。
|
||
而调用过程，则是基于用户的使用方式
|
||
首先我在OpenClaw 服务器上构建好/部署好医美销售智能体，及子智能体。以清洗为例的过程：
|
||
* OpenClaw 生产/试验服务器发起
|
||
* 用户通过飞书/企业微信，传入客户的聊天资料文本，指定好客户的id这些信息，发起清洗指令
|
||
* openclaw调用清洗智能体，生成清洗结果（Json），调用医美服务器的MCP，发起`保存清洗结果服务`
|
||
* 保存无误的话，openclaw将清洗结果中的《面诊接待小贴士》返回给我
|
||
* 医美服务器发起
|
||
* 用户在医美系统上，上传客户的聊天资料文本，医美服务器向OpenClaw服务器发起清洗指令
|
||
* Openclaw服务器调用清洗智能体，回传清洗结果（Json）
|
||
* 医美服务器保存，并将《面诊接待小贴士》在医美系统上呈现给用户
|
||
|
||
其他的调用过程也不外乎这两种吧？
|
||
主要是用户的使用终端有差别，一个是飞书或者企业微信这样的IM，一个是在医美系统上。
|
||
这两种调用过程都能实现么？
|
||
|
||
你的架构完全可以实现！两种调用方式都支持：
|
||
|
||
---
|
||
|
||
## 调用方式对照
|
||
|
||
| 维度 | 场景1: IM发起 | 场景2: 系统API发起 |
|
||
|-----|--------------|-------------------|
|
||
| 入口 | 飞书/企业微信 | 医美系统 HTTP API |
|
||
| 触发 | 消息事件 | POST 请求 |
|
||
| 协议 | WebSocket (Gateway) | HTTP REST |
|
||
| OpenClaw 入口 | 飞书插件 | `/v1/chat/completions` |
|
||
|
||
---
|
||
|
||
## 场景1: IM发起（飞书/企业微信）
|
||
|
||
```
|
||
用户(飞书) → 飞书插件 → OpenClaw Gateway → 清洗Agent → Dify → OpenClaw → 飞书回复
|
||
↓
|
||
医美服务器 MCP
|
||
```
|
||
|
||
**已支持**：
|
||
- OpenClaw 有飞书插件 (`channels.feishu`)
|
||
- 配置 `webhook` 接收消息
|
||
- MCP 调用通过 `exec` 或 custom tool
|
||
|
||
---
|
||
|
||
## 场景2: 系统API发起
|
||
|
||
```
|
||
医美系统 → OpenClaw HTTP API → 清洗Agent → Dify → OpenClaw → HTTP Response → 医美系统
|
||
↓
|
||
医美服务器 MCP
|
||
```
|
||
|
||
**已支持**：
|
||
- OpenClaw 提供 **OpenAI 兼容 API**：`POST /v1/chat/completions`
|
||
- 认证：Bearer Token
|
||
- 指定 Agent：`model: "openclaw:wantsong-sales"`
|
||
|
||
### 调用示例
|
||
|
||
```bash
|
||
curl -X POST 'http://<openclaw-host>:18789/v1/chat/completions' \
|
||
-H 'Authorization: Bearer <gateway-token>' \
|
||
-H 'Content-Type: application/json' \
|
||
-d '{
|
||
"model": "openclaw:wantsong-sales",
|
||
"messages": [
|
||
{"role": "user", "content": "请清洗客户张三的聊天记录..."}
|
||
]
|
||
}'
|
||
```
|
||
|
||
---
|
||
|
||
## 四台服务器协作
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ 试验阶段 (本机) │
|
||
│ OpenClaw 试验 ──→ Dify ──→ MCP (模拟) │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
│
|
||
▼
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ 生产阶段 │
|
||
│ ┌──────────────┐ ┌──────────────┐ ┌─────────────┐ │
|
||
│ │ 医美系统 │───→│OpenClaw 生产 │───→│ Dify 服务器 │ │
|
||
│ │ (API/IM入口) │ │ (销售Agent) │ │ (深度分析) │ │
|
||
│ └──────────────┘ └──────────────┘ └─────────────┘ │
|
||
│ ▲ │ │
|
||
│ │ ┌──────────────┐ │ │
|
||
│ └───────────│ 医美服务器 │◀────────────┘ │
|
||
│ │ (CRM/MCP) │ │
|
||
│ └──────────────┘ │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 下一步
|
||
|
||
1. **先在试验机跑通流程**：
|
||
- 搭建 `wantsong-sales` Agent
|
||
- 实现清洗 + MCP 调用
|
||
- 测试 IM 触发（飞书）
|
||
|
||
2. **生产部署**：
|
||
- 复制到生产 OpenClaw 服务器
|
||
- 配置 API 访问
|
||
- 医美系统对接
|
||
|
||
需要我帮你搭建销售 Agent 的框架么？
|
||
|
||
# 8
|
||
|
||
我们讨论清楚了，接下来我需要你帮我将上述的讨论生成一个方案。我需要将方案发给我的开发（轮机长们），因为涉及到医美系统的调整。
|
||
|
||
首先你回顾一下我们之前讨论的全部内容，做一个内部思考以减少错误提升质量，生成这个方案的提纲，等我确认。
|
||
我确认后，再开始填充方案内容。
|
||
|
||
好的，让我回顾我们的讨论，生成方案提纲：
|
||
|
||
---
|
||
|
||
## 方案提纲
|
||
|
||
### 一、背景与目标
|
||
- 现有医美销售智能体系统（4个Agent：A1清洗、A2复盘、B画像、C话术）
|
||
- OpenClaw + Dify 混合架构
|
||
- 目标：标准化、可复制、部署到生产
|
||
|
||
### 二、系统架构
|
||
1. **四台服务器角色**
|
||
- Dify 服务器：专家级智能体（深度画像等）
|
||
- OpenClaw 生产服务器：自动化流程编排
|
||
- 医美服务器：信息化系统 + MCP 服务
|
||
- OpenClaw 试验服务器：测试验证
|
||
|
||
2. **混合架构设计**
|
||
- OpenClaw（弱模型）：调度编排、工作流控制
|
||
- Dify（强模型）：深度分析、专业推理
|
||
|
||
### 三、Agent 体系设计
|
||
1. **通用销售心智模型**
|
||
- 客户画像（ORBIT/PRISM）
|
||
- 需求挖掘 → 异议处理 → 逼单转化 → 关系维护
|
||
|
||
2. **三层配置结构**
|
||
- 销售流程层（通用Prompt）
|
||
- 行业话术层（眼镜/教育/医美/金融...）
|
||
- 企业信息层（产品、案例、定价）
|
||
|
||
### 四、两种调用方式
|
||
1. **IM 发起**（飞书/企业微信 → OpenClaw）
|
||
2. **系统 API 发起**（医美系统 → OpenClaw HTTP API）
|
||
|
||
### 五、技术实现
|
||
1. **OpenClaw Agent 配置**
|
||
- wantsong-sales：销售编排主Agent
|
||
- Sub-agent 调用 Dify API
|
||
- MCP 调用医美服务器
|
||
|
||
2. **部署方案**
|
||
- 试验阶段：本地测试
|
||
- 生产阶段：切换服务器
|
||
|
||
### 六、实施计划
|
||
1. 试验机验证流程
|
||
2. 销售Agent框架搭建
|
||
3. 行业/企业配置结构设计
|
||
4. 生产部署
|
||
|
||
---
|
||
|
||
**请确认提纲是否完整准确，我来填充详细内容。**
|
||
|
||
# 9
|
||
|
||
在`Agent 体系设计`上是否要考虑设计智能体和子智能体？
|
||
|
||
先输出第一章和第二章的内容，等我确认。
|
||
|
||
好的，我来输出第一章和第二章：
|
||
|
||
---
|
||
```
|
||
# 医美销售智能体系统部署方案
|
||
|
||
## 一、背景与目标
|
||
|
||
### 1.1 项目背景
|
||
|
||
现有医美销售智能体系统基于 Dify 平台构建，包含四个核心智能体：
|
||
|
||
| 智能体 | 功能 | 输入 | 输出 |
|
||
|-------|------|------|------|
|
||
| **Agent A1** | 聊天记录清洗 | 微信聊天文本 | 结构化线索、问答对、《面诊接待小贴士》 |
|
||
| **Agent A2** | 面诊复盘质检 | 录音转写文本 | 《医美面诊复盘分析报告》（8大模块） |
|
||
| **Agent B** | 深度心理画像 | 微信线索 + 面诊事实 | 《3C客户心理全景图》、决策人、核心恐惧、信任缺口 |
|
||
| **Agent C** | 话术生成 | 心理画像 + 知识库 | 《催单行动指南》+ 话术原文 |
|
||
|
||
### 1.2 核心挑战
|
||
|
||
- **模型能力差异**：OpenClaw 使用弱模型（Qwen/Minimax），Dify 使用强模型（Claude/GPT）
|
||
- **部署灵活性**：当前仅支持单一调用方式，需支持 IM 和系统 API 两种入口
|
||
- **可复制性**：医美案例成功后，需快速复用到其他行业（眼镜、教育、金融等）
|
||
|
||
### 1.3 项目目标
|
||
|
||
1. **标准化**：建立通用销售心智模型，一次开发多处复用
|
||
2. **自动化**：OpenClaw 负责流程编排，Dify 负责深度推理
|
||
3. **可部署**：试验环境验证 → 生产环境部署，标准化交付
|
||
|
||
---
|
||
|
||
## 二、系统架构
|
||
|
||
### 2.1 服务器角色分工
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────────────┐
|
||
│ 生产环境 │
|
||
│ ┌──────────────┐ ┌──────────────────┐ ┌──────────────────┐ │
|
||
│ │ 医美系统 │ │ OpenClaw 生产 │ │ Dify 服务器 │ │
|
||
│ │ (入口/展示) │───→│ (自动化编排) │───→│ (专家级智能体) │ │
|
||
│ │ - CRM │ │ - 销售Agent │ │ - 深度画像 │ │
|
||
│ │ - MCP服务 │ │ - 工作流控制 │ │ - 心理分析 │ │
|
||
│ └──────────────┘ └──────────────────┘ └──────────────────┘ │
|
||
│ ▲ │ │ │
|
||
│ │ ▼ │ │
|
||
│ │ ┌──────────────────┐ │ │
|
||
│ └──────────────│ 医美服务器 │◀─────────────┘ │
|
||
│ │ (CRM + MCP) │ │
|
||
│ │ - 客户档案 │ │
|
||
│ │ - 保存清洗结果 │ │
|
||
│ │ - 知识库检索 │ │
|
||
│ └──────────────────┘ │
|
||
└─────────────────────────────────────────────────────────────────────────┘
|
||
|
||
┌─────────────────────────────────────────────────────────────────────────┐
|
||
│ 试验环境 (本机) │
|
||
│ OpenClaw 试验 ──→ Dify ──→ MCP (本地模拟) │
|
||
└─────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
| 服务器 | 角色 | 主要职责 |
|
||
|-------|------|---------|
|
||
| **Dify 服务器** | 专家大脑 | 提供强模型能力：深度画像、心理分析、复杂推理 |
|
||
| **OpenClaw 生产** | 自动化引擎 | 流程编排、Agent调度、MCP 调用、工作流控制 |
|
||
| **医美服务器** | 信息化底座 | CRM客户管理、MCP服务（保存/查询）、知识库 |
|
||
| **OpenClaw 试验** | 测试验证 | 流程验证、Agent调试、功能测试 |
|
||
|
||
### 2.2 混合架构设计
|
||
|
||
**核心理念**：OpenClaw 做"调度员"，Dify 做"专家"
|
||
|
||
| 层级 | 能力 | 适用场景 |
|
||
|-----|------|---------|
|
||
| **OpenClaw** | 弱模型 + 自动化 | 流程控制、简单判断、API调用、任务编排 |
|
||
| **Dify** | 强模型 + 长上下文 | 深度分析、心理画像、复杂推理、专业输出 |
|
||
|
||
```
|
||
OpenClaw Agent (销售编排)
|
||
│
|
||
├──→ Sub-agent A1 (清洗) ──→ Dify 或 内置
|
||
│
|
||
├──→ Sub-agent A2 (复盘) ──→ Dify 或 内置
|
||
│
|
||
├──→ Sub-agent B (画像) ──→ Dify (强模型)
|
||
│
|
||
└──→ Sub-agent C (话术) ──→ Dify + 知识库
|
||
```
|
||
|
||
### 2.3 调用方式
|
||
|
||
#### 方式一：IM 发起（飞书/企业微信）
|
||
|
||
```
|
||
用户(飞书) ──→ 飞书消息 ──→ OpenClaw Gateway ──→ 销售Agent
|
||
│
|
||
┌─────────────────────────┤
|
||
▼ ▼
|
||
清洗Agent Dify Agent
|
||
│ │
|
||
▼ ▼
|
||
医美服务器MCP 医美服务器MCP
|
||
│ │
|
||
▼ ▼
|
||
返回"面诊接待小贴士" 返回分析结果
|
||
```
|
||
|
||
#### 方式二：系统 API 发起
|
||
|
||
```
|
||
医美系统 ──→ POST /v1/chat/completions ──→ OpenClaw Gateway
|
||
│
|
||
┌─────────────────┼─────────────────┐
|
||
▼ ▼ ▼
|
||
清洗Agent 画像Agent 话术Agent
|
||
│ │ │
|
||
▼ ▼ ▼
|
||
医美MCP 医美MCP 医美MCP
|
||
│ │ │
|
||
▼ ▼ ▼
|
||
HTTP Response ─────────────────────────→ 医美系统
|
||
```
|
||
|
||
**API 调用示例**：
|
||
|
||
```bash
|
||
curl -X POST 'http://<openclaw-host>:18789/v1/chat/completions' \
|
||
-H 'Authorization: Bearer <gateway-token>' \
|
||
-H 'Content-Type: application/json' \
|
||
-d '{
|
||
"model": "openclaw:sales",
|
||
"messages": [
|
||
{"role": "user", "content": "请清洗客户张三的聊天记录..."}
|
||
]
|
||
}'
|
||
```
|
||
|
||
---
|
||
|
||
**请确认以上内容是否准确，我来继续输出第三章和第四章。**
|
||
|
||
# 10
|
||
|
||
好的请继续输出第三和第四章，同时第三章需要补充智能体和子智能体的区别与设计。
|
||
|
||
好的，继续输出第三和第四章：
|
||
|
||
---
|
||
|
||
## 三、Agent 体系设计
|
||
|
||
### 3.1 Agent 与 Sub-agent 的区别
|
||
|
||
| 特性 | Agent（智能体） | Sub-agent（子智能体） |
|
||
|-----|----------------|---------------------|
|
||
| **身份** | 独立"大脑"，有自己的人设 | 从属于主Agent |
|
||
| **会话** | 独立session，有自己的记忆 | 共享主Agent上下文 |
|
||
| **模型** | 独立配置 | 可单独指定，覆盖主Agent |
|
||
| **触发** | 独立接收消息（通过bindings） | 被主Agent调用 |
|
||
| **调用方式** | `sessions_spawn` 或 bindings | 主Agent内部调度 |
|
||
| **适用场景** | 独立角色、不同渠道入口 | 同一业务流程的分工环节 |
|
||
|
||
**在本方案中的定位**：
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ wantsong-sales (主Agent) │
|
||
│ - 角色：销售流程编排 │
|
||
│ - 模型：弱模型 (Qwen/Minimax) │
|
||
│ - 职责：接收请求 → 调度Sub-agent → 整合结果 → 返回 │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
│
|
||
┌─────────────────────┼─────────────────────┐
|
||
▼ ▼ ▼
|
||
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
|
||
│ Sub-agent A1 │ │ Sub-agent A2 │ │ Sub-agent B │
|
||
│ 聊天记录清洗 │ │ 面诊复盘质检 │ │ 深度心理画像 │
|
||
│ 模型：弱模型 │ │ 模型：弱模型 │ │ 模型：Dify │
|
||
└───────────────┘ └───────────────┘ └───────────────┘
|
||
```
|
||
|
||
### 3.2 Agent 设计
|
||
|
||
#### 3.2.1 主Agent：wantsong-sales（销售编排）
|
||
|
||
| 属性 | 值 |
|
||
|-----|-----|
|
||
| **Agent ID** | `wantsong-sales` |
|
||
| **模型** | minimax-portal/MiniMax-M2.5（弱模型，便宜） |
|
||
| **人设** | 医美销售顾问，擅长流程控制 |
|
||
| **工具** | sessions_spawn、exec、read、write |
|
||
|
||
**核心 Prompt（GL0）**：
|
||
|
||
```
|
||
你是医美销售智能体编排中心。你的任务是根据用户需求，
|
||
调度相应的子智能体完成销售流程。
|
||
|
||
销售流程：
|
||
1. 线索清洗 (A1) → 2. 面诊复盘 (A2) → 3. 深度画像 (B) → 4. 话术生成 (C)
|
||
|
||
根据输入内容判断当前处于哪个环节，调用对应的Sub-agent。
|
||
简单任务可内置处理，复杂分析调用Dify强模型。
|
||
```
|
||
|
||
#### 3.2.2 Sub-agent 设计
|
||
|
||
| Sub-agent | 功能 | 模型选择 | 调用方式 |
|
||
|----------|------|---------|---------|
|
||
| **A1-清洗** | 聊天记录清洗、结构化 | 弱模型（内置） | 直接处理 |
|
||
| **A2-复盘** | 面诊录音质检、摘要 | 弱模型（内置） | 直接处理 |
|
||
| **B-画像** | ORBIT/PRISM心理分析 | **Dify 强模型** | 调用 Dify API |
|
||
| **C-话术** | 知识库检索 + 话术生成 | **Dify 强模型** | 调用 Dify API |
|
||
|
||
### 3.3 通用销售心智模型
|
||
|
||
**核心逻辑**（适用于高客单价销售）：
|
||
|
||
```
|
||
客户接触 ──→ 需求挖掘 ──→ 方案展示 ──→ 异议处理 ──→ 逼单转化 ──→ 关系维护
|
||
│ │ │ │ │ │
|
||
▼ ▼ ▼ ▼ ▼ ▼
|
||
渠道来源 痛点识别 个性化方案 价格/效果 成交信号 复购/转介绍
|
||
```
|
||
|
||
**心理分析框架**：
|
||
|
||
| 维度 | 维度 | 说明 |
|
||
|-----|------|-----|
|
||
| **ORBIT** | Power | 决策权力（本人/配偶/父母） |
|
||
| | Relationship | 人际关系（依赖/独立） |
|
||
| | Motivation | 动机（变美/自信/社交） |
|
||
| **PRISM** | Meme | 深层恐惧（怕痛/怕贵/怕没效果） |
|
||
| | Reasoning | 认知逻辑（纠结点） |
|
||
|
||
### 3.4 三层配置结构
|
||
|
||
**核心理念**：通用内核 + 差异化外置
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ 销售流程层（通用） │
|
||
│ SKILL.md / prompts/ │
|
||
│ - 销售流程Prompt（GL0-GL4） │
|
||
│ - 心理分析框架 │
|
||
│ - 工作流逻辑 │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
│
|
||
▼
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ 行业话术层（可切换） │
|
||
│ knowledge-base/行业/ │
|
||
│ ├── 医美/ │
|
||
│ │ ├── 话术库.md │
|
||
│ │ ├── 术语表.md │
|
||
│ │ └── 常见问题.md │
|
||
│ ├── 眼镜/ │
|
||
│ └── 教育/ │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
│
|
||
▼
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ 企业信息层（独立配置） │
|
||
│ knowledge-base/企业/ │
|
||
│ ├── 医美-A机构/ │
|
||
│ │ ├── 企业信息.md（简介、地址、联系方式） │
|
||
│ │ ├── 产品资料.md（项目、价格、优惠） │
|
||
│ │ └── 成功案例.md │
|
||
│ └── 医美-B机构/ │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
**配置示例**：
|
||
|
||
```yaml
|
||
# 销售Agent配置
|
||
industry: "医美"
|
||
enterprise: "A机构"
|
||
|
||
# 自动加载：
|
||
# 1. knowledge-base/行业/医美/话术库.md
|
||
# 2. knowledge-base/企业/医美-A机构/企业信息.md
|
||
# 3. knowledge-base/企业/医美-A机构/产品资料.md
|
||
```
|
||
|
||
---
|
||
|
||
## 四、技术实现
|
||
|
||
### 4.1 OpenClaw 配置
|
||
|
||
#### 4.1.1 Agent 注册
|
||
|
||
```json5
|
||
{
|
||
agents: {
|
||
list: [
|
||
{
|
||
id: "wantsong-sales",
|
||
name: "医美销售编排",
|
||
workspace: "/root/.openclaw/workspace/wantsong-sales",
|
||
model: "minimax-portal/MiniMax-M2.5"
|
||
}
|
||
]
|
||
}
|
||
}
|
||
```
|
||
|
||
#### 4.1.2 Sub-agent 调用（Dify API）
|
||
|
||
```bash
|
||
# 调用Dify深度画像Agent
|
||
curl -sL -X POST 'https://aiplatform.wantsong.life/v1/chat-messages' \
|
||
-H 'Authorization: Bearer {api_key}' \
|
||
-H 'Content-Type: application/json' \
|
||
-d '{
|
||
"inputs": {},
|
||
"query": "客户画像分析：{客户微信线索} + {面诊事实}",
|
||
"response_mode": "blocking",
|
||
"conversation_id": "",
|
||
"user": "openclaw-sales"
|
||
}'
|
||
```
|
||
|
||
#### 4.1.3 MCP 调用
|
||
|
||
```bash
|
||
# 调用医美服务器MCP服务
|
||
curl -X POST 'http://<yimei-server>:8080/mcp/save-clean-result' \
|
||
-H 'Content-Type: application/json' \
|
||
-d '{
|
||
"customer_id": "xxx",
|
||
"clean_result": {...}
|
||
}'
|
||
```
|
||
|
||
### 4.2 调用流程（完整示例）
|
||
|
||
#### 场景：用户通过飞书发起"清洗客户聊天记录"
|
||
|
||
```
|
||
1. 用户在飞书发送："清洗客户张三的聊天记录"
|
||
│
|
||
▼
|
||
2. 飞书 → OpenClaw Gateway (wantsong-sales)
|
||
│
|
||
▼
|
||
3. 主Agent 解析意图 → 调用 Sub-agent A1 (清洗)
|
||
│
|
||
▼
|
||
4. A1 处理 → 返回结构化线索 + 《面诊接待小贴士》
|
||
│
|
||
▼
|
||
5. 主Agent 调用医美MCP保存结果
|
||
│
|
||
▼
|
||
6. 返回结果给用户（飞书）
|
||
```
|
||
|
||
### 4.3 试验与生产切换
|
||
|
||
| 环境 | OpenClaw URL | Dify URL | MCP 地址 |
|
||
|-----|-------------|---------|---------|
|
||
| **试验** | 本机 :18789 | aiplatform.wantsong.life | 本地模拟 |
|
||
| **生产** | 生产服务器 | 同上 | 医美服务器真实地址 |
|
||
|
||
**切换方式**：
|
||
- 更换 `skills/dify/SKILL.md` 中的 API 地址
|
||
- 更换 MCP 调用地址配置
|
||
|
||
---
|
||
|
||
**请确认以上内容，我来继续输出第五章和第六章。**
|
||
|
||
# 11
|
||
|
||
继续输出最后两章。
|
||
|
||
好的，继续输出最后两章：
|
||
|
||
---
|
||
|
||
## 五、实施计划
|
||
|
||
### 5.1 阶段划分
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────────────┐
|
||
│ 实施路线图 │
|
||
├─────────────────────────────────────────────────────────────────────────┤
|
||
│ │
|
||
│ 阶段一：试验验证 (1-2周) │
|
||
│ ┌─────────────────────────────────────────────────────────────────┐ │
|
||
│ │ • 搭建 wantsong-sales 主Agent │ │
|
||
│ │ • 实现 A1 清洗 Sub-agent (内置弱模型) │ │
|
||
│ │ • 飞书渠道接入测试 │ │
|
||
│ │ • MCP 调用本地模拟 │ │
|
||
│ └─────────────────────────────────────────────────────────────────┘ │
|
||
│ ▼ │
|
||
│ 阶段二：能力扩展 (1周) │
|
||
│ ┌─────────────────────────────────────────────────────────────────┐ │
|
||
│ │ • 实现 A2 复盘 Sub-agent │ │
|
||
│ │ • 实现 B 画像 Sub-agent (调用Dify) │ │
|
||
│ │ • 实现 C 话术 Sub-agent │ │
|
||
│ │ • 行业话术库配置（医美） │ │
|
||
│ └─────────────────────────────────────────────────────────────────┘ │
|
||
│ ▼ │
|
||
│ 阶段三：生产部署 (1周) │
|
||
│ ┌─────────────────────────────────────────────────────────────────┐ │
|
||
│ │ • 部署到 OpenClaw 生产服务器 │ │
|
||
│ │ • 医美服务器 MCP 对接 │ │
|
||
│ │ • API 方式接入医美系统 │ │
|
||
│ │ • 监控与日志配置 │ │
|
||
│ └─────────────────────────────────────────────────────────────────┘ │
|
||
│ ▼ │
|
||
│ 阶段四：复制扩展 (持续) │
|
||
│ ┌─────────────────────────────────────────────────────────────────┐ │
|
||
│ │ • 复制到其他行业（眼镜、教育、金融） │ │
|
||
│ │ • 新增企业配置 │ │
|
||
│ │ • 优化迭代 │ │
|
||
│ └─────────────────────────────────────────────────────────────────┘ │
|
||
│ │
|
||
└─────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 5.2 里程碑
|
||
|
||
| 阶段 | 里程碑 | 验收标准 |
|
||
|-----|--------|---------|
|
||
| 阶段一 | 试验环境跑通 | 飞书发起 → 清洗 → 返回结果，全流程跑通 |
|
||
| 阶段二 | 完整流程上线 | A1→A2→B→C 全流程跑通，结果准确 |
|
||
| 阶段三 | 生产部署完成 | 医美系统API接入，稳定运行 |
|
||
| 阶段四 | 行业复制 | 第二个行业（眼镜/教育）配置完成 |
|
||
|
||
### 5.3 人员分工
|
||
|
||
| 角色 | 职责 |
|
||
|-----|------|
|
||
| **架构师（你）** | 方案设计、Agent配置、Prompt优化 |
|
||
| **轮机长（开发）** | MCP开发、API对接、医美系统改造 |
|
||
| **测试** | 功能测试、流程验证 |
|
||
|
||
---
|
||
|
||
## 六、附录
|
||
|
||
### 6.1 技术栈
|
||
|
||
| 组件 | 技术 | 说明 |
|
||
|-----|------|-----|
|
||
| **编排引擎** | OpenClaw | 流程控制、Agent调度 |
|
||
| **专家大脑** | Dify | 深度分析、强模型推理 |
|
||
| **信息化底座** | 医美服务器 | CRM、MCP、知识库 |
|
||
| **入口** | 飞书/企业微信/医美系统 | IM or HTTP API |
|
||
|
||
### 6.2 配置文件结构
|
||
|
||
```
|
||
wantsong-sales/
|
||
├── SKILL.md # 主Agent入口
|
||
├── prompts/
|
||
│ ├── sales-flow.md # 销售流程Prompt
|
||
│ └── psychology.md # 心理分析框架
|
||
├── knowledge-base/
|
||
│ ├── 行业/
|
||
│ │ ├── 医美/话术库.md
|
||
│ │ └── 眼镜/话术库.md
|
||
│ └── 企业/
|
||
│ ├── 医美-A机构/企业信息.md
|
||
│ └── 医美-A机构/产品资料.md
|
||
├── skills/
|
||
│ └── dify/ # Dify调用（已实现）
|
||
└── config.yaml # 环境配置
|
||
```
|
||
|
||
### 6.3 API 接口定义
|
||
|
||
#### 清洗接口
|
||
|
||
```yaml
|
||
POST /v1/chat/completions
|
||
Authorization: Bearer <token>
|
||
Content-Type: application/json
|
||
|
||
Request:
|
||
{
|
||
"model": "openclaw:sales",
|
||
"messages": [
|
||
{
|
||
"role": "user",
|
||
"content": "清洗客户聊天记录 | 客户ID: 12345 | 内容: <文本>"
|
||
}
|
||
]
|
||
}
|
||
|
||
Response:
|
||
{
|
||
"id": "...",
|
||
"choices": [
|
||
{
|
||
"message": {
|
||
"content": "{\"clues\": {...}, \"tips\": \"面诊接待小贴士...\"}"
|
||
}
|
||
}
|
||
]
|
||
}
|
||
```
|
||
|
||
### 6.4 风险与对策
|
||
|
||
| 风险 | 影响 | 对策 |
|
||
|-----|------|-----|
|
||
| Dify API 不稳定 | 画像/话术无法生成 | 增加重试机制 + 降级处理 |
|
||
| MCP 调用失败 | 数据无法保存 | 记录日志 + 告警 + 人工介入 |
|
||
| 强模型幻觉 | 画像分析不准确 | 增加人工审核环节 |
|
||
| 并发过高 | 响应延迟 | 限流 + 队列机制 |
|
||
|
||
---
|
||
|
||
## 方案完
|
||
|
||
---
|
||
|
||
**以上是完整方案。请确认是否需要修改或补充。** |