# 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 调用失败 | 数据无法保存 | 记录日志 + 告警 + 人工介入 |
| 强模型幻觉 | 画像分析不准确 | 增加人工审核环节 |
| 并发过高 | 响应延迟 | 限流 + 队列机制 |

---

## 方案完

---

**以上是完整方案。请确认是否需要修改或补充。**