61 KiB

Raw Blame History

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 的目录读写文件——只要你知道路径。

设计上更好的做法：

公用内容放共享目录：/root/.openclaw/workspace/skills/ 已经存在，放这里所有 agent 都能用
每个 agent 有独立 workspace：wantsong-writer → /root/.openclaw/workspace/wantsong-writer/，wantsong-work → /root/.openclaw/workspace/wantsong-work/
如果需要深度共享：可以用 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"

{
  gateway: {
    auth: {
      mode: "password",
      password: "你的密码"
    }
  }
}

6. 语言设置

这个是 Control UI 的界面语言，不是 Agent 回复你用的语言。

UI 语言：设置后，Control UI 界面用你选的语言显示（en/zh-CN 等）
Agent 回复语言：取决于 Agent 的人设（SOUL.md）+ 对话上下文，AI 自己判断

还有其他想讨论的吗？

4

问题

Session Key

agent ，前缀这个不能改么，还是有其他场合？
wantsong ，这个我理解
main sessionKey，可以改成其他名字是什么意思；意思是可以和wantsong同时启动多个会话，通过会话key来切换是么？

关于工作的Agent
- 即便是工作，也会有细化的考虑，比如有些是我的公司的业务，有的是其他公司的业务
- 比如，我为医美服务，可以考虑为医美搭建1到多个不同的Agent；我为教育服务，也可以为教育搭建专属的不同Agent。然后将来我这里试验结束，需要的时候，可以把某个行业或者企业的Agent进行单独部署。
Agent的协同，与使用skill
- 我理解的Skill是共享会话上下文的，而Agent不一定
- 是建立Agent还是Skill，你有什么建议么？
- 比如我做了个医美销售助手Agent，可以帮医美的销售人员进行客户画像，对客户进行的面诊谈话录音转文字进行分析，并提供后续销售话术。我们现在已经开发这个智能体系统，由好几个智能体构成，如果是用openclaw搭建，我是把他们做成Skill还是不同Agent。参见参考资料中的四个智能体。
关于部署
- 我以为这个只是为个人电脑PC来做的，如果是我现在理解的，完全可以部署成一个智能体底层服务系统。
- 还是以医美销售助手Agent为例，我若基于OpenClaw重新搭建了，怎么在生产环境上部署，你有什么建议？

需要你一一回复我上面的问题。

参考资料

# 销售洞察智能体（教育、医美）系统核心设计文档 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 做健康检查

你想先从哪个开始？

先把 wantsong 拆成写作/工作两个 Agent？
规划医美销售系统的 Agent 架构？
搭建一个可复用的 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（推荐）

/subagents spawn <agentId> <task> --model <strong-model>

启动一个子 Agent 帮你干活
可以指定不同的模型
完成后自动汇报结果

方式2: sessions_send

sessions_send(sessionKey="agent:other-agent:main", message="帮我处理这个...")

发送消息到另一个 Agent 的会话
需要开启 tools.agentToAgent.enabled

问题2: 可以把 Dify Agent 封装进 OpenClaw Agent 么？

可以！ 两种思路：

思路A: 把 Dify API 封装成 Skill

# 在 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

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 支持指定模型：

/subagents spawn wantsong-deep "做深度分析" --model minimax-portal/MiniMax-M2.5

或者在代码里：

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/`	已有实现，直接复用

关键：配置驱动

# 销售配置示例
industry: "医美"
enterprise: "A机构"

# 销售Agent根据配置自动加载：
# 1. 加载 "医美" 行业话术库
# 2. 加载 "A机构" 企业信息
# 3. 调用 Dify 心理画像Agent
# 4. 生成定制化话术

优点

一套Agent，多个行业/企业 — 降低维护成本
行业/企业独立配置 — 改话术不影响Agent
OpenClaw 编排 + Dify 深度能力 — 完美分工
易于扩展 — 新增行业/企业只需加配置

下一步

先拆 wantsong → 写作/工作两个 Agent（你目前用的）
创建 wantsong-sales Agent（销售编排）
设计行业/企业配置结构
把医美案例迁移进来测试

需要我帮你设计具体的配置结构么？

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"

调用示例

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)    │                     │
│                     └──────────────┘                     │
└─────────────────────────────────────────────────────────────┘

下一步

先在试验机跑通流程：
- 搭建 wantsong-sales Agent
- 实现清洗 + MCP 调用
- 测试 IM 触发（飞书）
生产部署：
- 复制到生产 OpenClaw 服务器
- 配置 API 访问
- 医美系统对接

需要我帮你搭建销售 Agent 的框架么？

8

我们讨论清楚了，接下来我需要你帮我将上述的讨论生成一个方案。我需要将方案发给我的开发（轮机长们），因为涉及到医美系统的调整。

首先你回顾一下我们之前讨论的全部内容，做一个内部思考以减少错误提升质量，生成这个方案的提纲，等我确认。我确认后，再开始填充方案内容。

好的，让我回顾我们的讨论，生成方案提纲：

方案提纲

一、背景与目标

现有医美销售智能体系统（4个Agent：A1清洗、A2复盘、B画像、C话术）
OpenClaw + Dify 混合架构
目标：标准化、可复制、部署到生产

二、系统架构

四台服务器角色
- Dify 服务器：专家级智能体（深度画像等）
- OpenClaw 生产服务器：自动化流程编排
- 医美服务器：信息化系统 + MCP 服务
- OpenClaw 试验服务器：测试验证
混合架构设计
- OpenClaw（弱模型）：调度编排、工作流控制
- Dify（强模型）：深度分析、专业推理

三、Agent 体系设计

通用销售心智模型
- 客户画像（ORBIT/PRISM）
- 需求挖掘 → 异议处理 → 逼单转化 → 关系维护
三层配置结构
- 销售流程层（通用Prompt）
- 行业话术层（眼镜/教育/医美/金融...）
- 企业信息层（产品、案例、定价）

四、两种调用方式

IM 发起（飞书/企业微信 → OpenClaw）
系统 API 发起（医美系统 → OpenClaw HTTP API）

五、技术实现

OpenClaw Agent 配置
- wantsong-sales：销售编排主Agent
- Sub-agent 调用 Dify API
- MCP 调用医美服务器
部署方案
- 试验阶段：本地测试
- 生产阶段：切换服务器

六、实施计划

试验机验证流程
销售Agent框架搭建
行业/企业配置结构设计
生产部署

请确认提纲是否完整准确，我来填充详细内容。

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机构/                                            │
└─────────────────────────────────────────────────────────────┘

配置示例：

# 销售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 注册

{
  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）

# 调用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 调用

# 调用医美服务器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 接口定义

清洗接口

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

方案完

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

61 KiB Raw Blame History Unescape Escape

1

2

3

1. Agent 命名

2. Session Key: agent:wantsong:main

3. WebSocket URL

4. 网关令牌 (Gateway Token)

5. 密码 (不存储)

6. 语言设置

4

问题

参考资料

问题1: Session Key

agent 前缀

main 可以改成其他名字

问题2: 工作的 Agent

问题3: Agent 协同 vs Skill

核心区别

建议：你的医美系统应该用 Agent

问题4: 部署

部署架构建议

生产部署考虑

你想先从哪个开始？

5

问题1: OpenClaw 不同 Agent 可以互相调用么？

方式1: Sub-agent（推荐）

方式2: sessions_send

问题2: 可以把 Dify Agent 封装进 OpenClaw Agent 么？

思路A: 把 Dify API 封装成 Skill

思路B: 用 exec 调用 curl

问题3: 会话里能切换 LLM 么？

你的医美系统架构

6

你的架构思路

建议：三层架构

具体设计

关键：配置驱动

优点

下一步

7

调用方式对照

场景1: IM发起（飞书/企业微信）

场景2: 系统API发起

调用示例

四台服务器协作

下一步

8

方案提纲

一、背景与目标

二、系统架构

三、Agent 体系设计

四、两种调用方式

五、技术实现

六、实施计划

9

10

三、Agent 体系设计

3.1 Agent 与 Sub-agent 的区别

3.2 Agent 设计

3.2.1 主Agent：wantsong-sales（销售编排）

3.2.2 Sub-agent 设计

3.3 通用销售心智模型

3.4 三层配置结构

四、技术实现

4.1 OpenClaw 配置

4.1.1 Agent 注册

4.1.2 Sub-agent 调用（Dify API）

4.1.3 MCP 调用

4.2 调用流程（完整示例）

场景：用户通过飞书发起"清洗客户聊天记录"

4.3 试验与生产切换

11

五、实施计划

5.1 阶段划分

5.2 里程碑

5.3 人员分工

六、附录

6.1 技术栈

6.2 配置文件结构

61 KiB

Raw Blame History

2. Session Key: `agent:wantsong:main`

`agent` 前缀

`main` 可以改成其他名字