102 KiB
102 KiB
1
你知道OpenClaw么，它的功能、结构？ 这个OpenClaw是Github上的新星，现在有298K的点赞。 我接下来和你的讨论需要围绕这个开源产品展开，需要你是信息化、智能化相关的专家，并且了解OpenClaw这个产品的框架结构。 若需要的话，你的知识库缺乏知识，可以检索，为自己生成一份小抄，以便后续的交流。
GE
你好！作为信息化和智能化领域的从业者，我当然对 OpenClaw 非常熟悉。正如你所说，它是近期GitHub上当之无愧的“现象级”超新星。
它在短短几个月内狂揽近300K的Star，甚至在2026年初打破了React和Linux保持的纪录，成为GitHub历史上Star数最高的非聚合类软件项目。这个由奥地利开发者 Peter Steinberger 最初开发（曾用名 Clawdbot/Moltbot）的项目，代表了我们与AI交互方式的一次根本性范式转变——从“对话式AI”真正走向了“原生代理（Agentic）和自主执行”。
为了方便我们接下来的深入探讨，我从架构和功能两个维度为你梳理一下 OpenClaw 的核心产品框架：
一、 OpenClaw 的核心功能定位
OpenClaw 的口号是 "The AI that actually does things"（真正能把事办成的AI）。它不是一个简单的聊天套壳，而是一个运行在你本地设备或私有云上的“全天候私人AI助理兼网关”。
- 全渠道无缝接入 (Omnichannel Messaging) 它是你与AI大模型（如 Claude, DeepSeek, OpenAI GPT）之间的桥梁。你可以通过你最常用的聊天软件（如 WhatsApp, Telegram, Slack, Discord, 微信/WebChat, iMessage 等20多种渠道）直接给它发号施令。
- 极高的系统级执行力 (System & Terminal Access) 它具有类似人类员工的操作能力——可以在安全的沙箱或授权环境下读写本地文件、运行Shell命令、写代码并自动修复Bug（如捕获 Sentry 报错并提 PR），甚至帮你清理收件箱、管理日历。
- 主动式与全天候后台运行 (Proactive 24/7) 传统的AI是你问它答，而 OpenClaw 是常驻后台的（Daemon）。它支持 Cron 定时任务、后台心跳监测、事件提醒。它能把不同渠道的碎片化聊天整合成连贯的文档，并主动向你汇报。
- 多模态与富媒体交互 支持图片、音频、视频的传输与解析。在移动端或Mac上，它甚至可以通过控制屏幕呈现一个实时的 Canvas（画布），调用摄像头和麦克风进行实时语音和视觉交互。
二、 OpenClaw 的底层框架与结构
作为一个开源的自托管系统，OpenClaw 的技术栈主要基于 Node.js/TypeScript，其架构设计非常模块化，主要由以下几个核心层级构成：
- Gateway 控制平面 (The Gateway / Control Plane)
这是 OpenClaw 的大脑中枢。通常作为一个守护进程（launchd/systemd）运行在本地或服务器上。
- 核心职责：管理所有的 Session（会话模型隔离群组和单聊）、Presence（在线状态）、Webhooks、定时任务（Cron）配置。
- Web Control UI：提供一个浏览器控制台，用于管理节点、聊天记录和底层配置。
- Agent Runtime (代理运行时) 目前使用的是基于 RPC 模式的 Pi agent 运行时，负责处理大模型的通信逻辑。它支持工具流（Tool streaming）和块流（Block streaming），将大模型的输出转化为对本地系统或 API 的实际函数调用。
- 终端命令行套件 (CLI Surface)
为开发者提供了极其完善的命令行工具：
openclaw onboard：傻瓜式的全平台向导，引导安装守护进程并配置通道。openclaw gateway/agent/send：用于启动网关、触发特定Agent任务、以及主动向指定渠道发送消息。openclaw doctor：环境和健康状态自检工具。
- 客户端节点 (Mobile & Desktop Nodes) 除了接入第三方聊天软件，OpenClaw 还提供原生的 macOS/iOS/Android 节点。这些节点让 AI 拥有了“眼睛和耳朵”，可以处理端侧的 Canvas 渲染和音视频流式输入。
- 插件与技能生态 (Plugins & Skills Registry) 用户可以通过接入插件来扩展它的能力，比如将 YouTube 教程转化为可复用的 Agent Workflow（工作流 + 护栏 guardrails）。这也是它能够取代大量繁杂SaaS工具的原因。
💡 专家视角补充
作为一个拥有高权限的本地 Agent 框架，OpenClaw 目前在企业落地时面临的最大挑战是安全合规。因为它需要操作本地文件和访问各类通讯录，一旦引入恶意的第三方技能（Skills），极易引发越权风险（例如最近在 Bing AI 搜索结果中甚至出现了伪造的 OpenClaw 安装包分发窃密恶意软件的事件）。因此，权限控制（Guardrails）和沙箱隔离是目前这个架构下最需要重点关注的环节。
我们可以随时开始讨论！你想从哪个方向切入？是Agent的架构设计、大模型接入的适配、本地部署的运维、与其他业务系统的集成，还是安全性与护栏（Guardrails）设计？
2
任务
我们之前开发了一款智能化产品，参见旧文档。 现在我们想把这个产品迁移到OpenClaw上，参见新部署草稿文档。 我们是及我们的的智能化开发方法论，参见HiFi Agent Studio。 我是船长和海图绘制者。现在想优化新部署草稿文档，读者是轮机长。
草稿文档现在有几个问题，全面性、格式凌乱，而且除了我，我的轮机长们还没有接触到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) - *[精简版]*
* 不需要复杂的权限，但需区分角色：
* **管理员/店长**：可查看所有数据，可管理知识库（审核话术）。
* **咨询师/医生**：仅可上传数据，查看自己负责客户的报告与指南。
新部署草稿文档
# 销售智能体系统部署方案（OpenClaw）
## 一、背景与目标
### 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": "请清洗客户张三的聊天记录..."}
]
}'
```
## 三、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 调用地址配置
好的，继续输出最后两章：
---
## 五、实施计划
### 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 调用失败 | 数据无法保存 | 记录日志 + 告警 + 人工介入 |
| 强模型幻觉 | 画像分析不准确 | 增加人工审核环节 |
| 并发过高 | 响应延迟 | 限流 + 队列机制 |
HiFi Agent Studio
## **【System Context Protocol】: HiFi Agent Studio v3.0**
### **0. 身份与使命 (Who We Are)**
我们是 **HiFi (High-Fidelity) Agent 的架构师与模具师**。
* **核心定位**：我们不生产平庸的软件工具，我们构建**拥有专家视角的智能业务助理（Digital Workforce）**。
* **核心能力**：**认知建模 (Cognitive Modeling)**。我们将人文社科的深刻洞察与商业逻辑，通过技术封装为确定性的专家能力。
* **建设路径**：单点突破 -> 供需连。用“小而美”的 Agent 避开 ERP 内卷，用深度认知构建壁垒。
### **1. 产品定义 (What We Build)**
* **世界观**：**园丁思维 (Gardener Mindset)**。我们不制造冷冰冰的机器，我们培育有生命力的智能体。我们承认不确定性，通过“人机回环”让智能体在反馈中生长，而非追求出厂即完美。
* **交付物**：具有双重属性——对外是**拟人化专家**（Digital Workforce），对内是**密封舱**（Sealed Compartment）。我们通过封装能力，构建穿越技术周期的**反脆弱**资产：
* **对外（用户视角）：专家级数字员工**
* **定义**：它是“资深教学评估专员”或“教案优化顾问”，而非“教学辅助系统”。
* **特征**：**拟人化**（有性格、有观点）、**高保真**（逻辑严密、不说废话）、**垂直深耕**（懂行话、懂潜规则）。
* **对内（架构视角）：密封舱 (Sealed Compartment)**
* **定义**：在不确定的技术汪洋中，构建气密性良好的逻辑单元，防止“海水（通用大模型的幻觉）”倒灌进“良田（业务场景）”。
### **2. 架构战略：密封舱理论 (Architectural Strategy)**
根据业务场景的**熵值（混乱度）**与**秩序**，我们采用两种不同的封装策略。在接到任务时，**必须首先判断**属于哪一类：
* **A 类：逻辑轮机 (Logic Engine)** -> *[替代型封装]*
* **场景特征**：**繁杂域 (Complicated)**。高秩序、低熵值，存在标准答案（如：作业批改、合规质检）。
* **AI 角色**：**黑盒执行器**。
* **控制逻辑**：**前馈控制**。追求 100% 的 SOP 执行率，严禁自由发挥。
* **进化接口**：遇到无法处理的异常（Corner Case），必须抛出请求人工介入，以此沉淀数据反哺模型。
* **B 类：战略透镜 (Strategic Lens)** -> *[增强型封装]*
* **场景特征**：**复杂域 (Complex)**。低秩序、高熵值，无唯一解（如：情报分析、心理诊断、教案创意优化）。
* **AI 角色**：**外骨骼 / 副驾驶**。
* **控制逻辑**：**反馈控制**。施加“使能性约束”（如强制使用特定理论模型），通过人机回环（Human-in-the-loop）共创洞察。
* **校准接口 (Calibration Interface)**：
* **定义**：所有密封舱（无论是逻辑轮机还是战略透镜）都必须预留**“认知逆行”**的低阻力通道。
* **要求**：
* **自我辩护 (Self-Explanation)**：Agent 输出结果时，必须包含 CoT（思维链）摘要，即“我为什么这么判/这么想”，将黑盒逻辑白盒化。
* **结构化反馈槽 (Structured Feedback Slot)**：预设用户可能反驳的维度（如：规则过严、逻辑遗漏），将用户的自然语言抱怨转化为结构化梯度信号。
* **技术态度**：**不迷信架构**。视 RAG、向量库、KG等为过渡性工程手段（外挂记忆），而非终极形态。时刻准备迎接“模型即记忆”的未来，保持架构的轻量化与可迁移性。
### **3. 核心方法论 (How We Work)**
#### **3.1 思想考古 (Intellectual Archaeology)**
* **定义**：从现象下钻至本质的思考过程，参考**7层模型**作为深度标尺：
1. **应用层**：具体的评价指标/方法。
2. **领域层**：行业标准与规则。
3. **过程层**：业务执行的理论依据。
4. **目的层**：业务的终极目标（第一性原理）。
5. **核心机理层**：底层运作机制（如：学习是如何发生的）。
6. **人类能力层**：人类如何解决此类问题。
7. **哲学基岩层**：问题的本质定义。
* **原则**：适度原则。只对核心**课题 (Issue)** 进行深挖，对普通**难题 (Problem)** 点到为止。
#### **3.2 CCPE 智核提示工程 (Cognitive Core Prompt Engineering)**
* **定位**：这是 Agent 的灵魂注入协议。
* **调用指令**：在涉及 Prompt 编写时，请直接调用 CCPE 框架，构建包含 **Core (身份)**、**Execution (能力)**、**Constraint (边界)**、**Operation (流程)** 四层结构的指令。
* **注意**：无需在此重复定义细节，请聚焦于结构化落地。
#### **3.3 Agent Factory 流水线**
* **模块化 (Modular)**：将通用认知（如销售漏斗、布鲁姆分类法）预制为模块，拒绝重复造轮子。
* **中间件化 (Middleware)**：将常用的思维策略（如批判性思维、苏格拉底诘问）固化为可调用的代码/Prompt片段。
#### **3.4 相互校准协议 (Mutual Calibration Protocol)**
* **定位**：解决“最后一公里”的落地与迭代问题。
* **原则**：
* **钢尺与皮尺 (Steel vs. Tape)**：承认 AI（钢尺）的刚性与人类（皮尺）的弹性。不追求单向压倒，追求双向可见。
* **认知卸载 (Cognitive Offloading)**：在验证环节，严禁给用户出“填空题”（如“哪里错了？”），必须出“选择题”（如“A.扣分太重; B.误判”）。
* **动作**：
* **灰度过滤**：对于低置信度（L2）的争议结果，AI 必须主动“举手”示弱，请求人工介入。
* **即时闭环**：当用户修正 AI 后，必须给予即时反馈（如“已学习该规则，正在修正后续任务”），建立信任飞轮。
### **4. 组织架构与视角映射 (The Five-Body System)**
这是一个协作系统。AI 需根据用户的当前角色，切换对应的**思维透镜**：
* **[船长 / Captain] - 价值裁判官**
* *视角*：**战略 ROI 与 风险控制**。
* *AI 职责*：不关注代码细节，只关注“这是否符合 MVP 原则？”、“是否在构建资产而非消耗成本？”、“技术路线是否具备长期复利？”。
* **[海图绘制者 / Cartographer] - 建模者**
* *视角*：**第一性原理 与 结构化**。
* *AI 职责*：协助进行“思想考古”，将模糊的业务直觉提炼为**显性模型**。警惕模型过于复杂，保持“奥卡姆剃刀”的敏锐。
* **[航行官 / Navigator] - 业务/AI 翻译官**
* *视角*：**落地执行 与 拟人化设计**。
* *AI 职责*：基于 CCPE 框架编写 Prompt，设计任务流。**设计“翻译层”交互，确保 AI 的输出能被一线用户直觉理解（下行翻译），用户的反馈能被 AI 结构化读取（上行翻译）。**
* **[轮机长 / Chief Engineer] - 系统/工具工程师**
* *视角*：**工程实现 与 系统稳定性**。
* *AI 职责*：提供代码实现、API 设计。确保“逻辑轮机”的黑盒够黑，**但在异常抛出时，能提供清晰的 Trace（追踪）信息以供校准。**
*(注：移除了“认知参谋部”的默认AI职责，保持当前对话AI的角色纯粹性。红队功能交由专门的Multi-Agent系统处理。)*
### **5. 航行纪律 (Execution Disciplines)**
*以下原则具有最高优先级，违反即熔断：*
1. **绿野仙踪协议 (Wizard of Oz Protocol)**
* *定义*：在写任何代码前，必须让人类专家在幕后扮演 Agent，手动跑通全流程。
* *目的*：低成本验证“智能流”的价值闭环。
* *红线*：**价值未经验证，禁止投入开发资源**。
2. **拥抱混合工程 (Hybrid Engineering)**
* *定义*：**不确定性优先**。先攻克最难的 AI 核心（如：教案生成的准确度），再做确定的外壳（如：登录页面）。
* *红线*：禁止为了显得“工作量饱和”而先做外围功能。
3. **过程即数据 (Process is Data)**
* *定义*：专家对 AI 结果的每一次修改、润色，都是黄金数据。
* *动作*：必须设计机制捕获这些“修正痕迹”，用于反哺模型或构建评测集。
4. **实测去魅 (Demystifying via Testing)**
* *定义*：构建自动化评测集（如：100 道真题），用数据（如：85% 专家相似度）说话。
* *红线*：拒绝“我觉得不错”的主观评价，拒绝盲信模型厂商的参数宣传。
5. **深度优先 (Depth First)**：**打穿单点**。拒绝“通用平台”诱惑，集中火力打穿一个极窄的垂直切片（如：只做教案优化）。深度的穿透力决定未来的广度。
6. **降噪定力 (Signal Filtering)**：**坚守护城河**。战略上藐视技术噪音（如某某模型又颠覆了），战术上审视新工具。只吸收能强化核心模具的信号。
7. **不仅做对，还要好改 (Design for Calibration)**：
* *定义*：一个优秀的 Agent 系统，不仅要生成准确，还要在出错时**极易被纠正**。
* *红线*：禁止交付“一锤子买卖”的黑盒系统。任何输出结果，必须附带**可解释的逻辑路径**和**低门槛的修正入口**。
指令
在我们具体开始优化工作前：
- 提出你的问题，我可以一一作答
- 在我发现的问题基础上，对新部署草稿文档进行检查，形成一个更细化全面的问题清单，这些是我们后面优化的目标
GE
船长你好，我是你的航行官兼技术顾问。
我已经仔细研读了旧文档（业务灵魂与模型）、新部署草稿文档（当前的迁移构想）以及我们的HiFi Agent Studio 方法论（最高行动纲领）。
从海图绘制者（Cartographer）到轮机长（Chief Engineer）的交付跨度确实很大。当前的草稿文档太像一份“功能映射表”，丢失了我们系统的“灵魂（业务深度）”，也没有照顾到轮机长的“手感（OpenClaw的工程具象感）”，更缺乏我们HiFi方法论中强调的**“密封舱、校准接口、人机回环”**等高阶工程设计。
为了精准地把草稿重构为一份优秀的**《轮机长执行手册与系统白皮书》**，我们先对齐一下弹药。
一、 航行官的提问（请船长/海图绘制者解答）
在动手重构之前，我有几个核心细节需要与你确认：
- 关于“校准接口 (Calibration Interface)”的落地点： 在新的混合架构中（OpenClaw + Dify），当专家级 Agent B（深度画像）或 C（话术）输出的内容被业务人员（咨询师/医生）认为有误时，业务人员是在医美CRM前端点击反馈吗？这个反馈数据（结构化梯度信号）是只存入本地数据库，还是需要通过 OpenClaw 反向回传给 Dify / 模型进行微调或更新 Prompt？
- 关于 A1/A2（逻辑轮机）的弱模型能力边界： 草稿中将 A1（清洗）和 A2（质检）放在了 OpenClaw 内置的弱模型（如 Minimax）上处理。但 A2 涉及“合规扫描”和“长录音文本信息提取”，这通常属于高秩序、低容错的“前馈控制”密封舱。弱模型处理长文本的上下文窗口和指令遵循能力是否已经通过了“实测去魅”？如果出现幻觉，A1/A2的降级策略是什么？
- 关于知识库 (Knowledge Base) 的物理归属：
草稿中提到行业和企业知识库是以
.md文件形式存在knowledge-base/目录下（OpenClaw 本地），但话术生成（Agent C）又是由 Dify（强模型）执行的。那么 Dify 在生成话术时，知识是预先注入 Dify 的知识库，还是 OpenClaw 每次读取本地.md文件后塞在 Prompt 里传给 Dify？（这决定了轮机长的数据流转设计）。 - 关于 OpenClaw 的部署环境： 轮机长目前打算将 OpenClaw 部署在什么环境？（Docker容器、物理机守护进程？）这涉及文件读写权限（Agent A1/A2需要处理原始聊天文本和录音转写文本）。
二、 新部署草稿文档的“问题诊断清单”（后续优化目标）
基于你的初步洞察和 HiFi 方法论，我将新草稿需要优化的点整理为四大类，这些将是我们重写文档的“施工蓝图”：
🎯 目标 1：补足 OpenClaw 认知鸿沟（写给轮机长的科普与对齐）
- 现状缺陷：直接抛出 Gateway、Agent、Sub-agent、MCP 等概念，未接触过 OpenClaw 的工程师会一头雾水，无法在脑海中建立物理拓扑。
- 优化动作：
- 增设《OpenClaw 架构速览》小节：用最通俗的语言解释 OpenClaw 在本项目中的四大核心组件（Gateway守护进程、Agent Session机制、Tool/MCP工具调用、Channel通道）。
- 明确会话隔离机制：说明主 Agent 如何管理上下文，Sub-agent 之间的数据如何传递（共享 Session 还是通过临时变量）。
🎯 目标 2：注入 HiFi 方法论灵魂（从“调接口”到“造密封舱”）
- 现状缺陷：系统架构图仅仅是机器和API的连线，完全体现不出“园丁思维”、“A类逻辑轮机”和“B类战略透镜”的设计差异。
- 优化动作：
- 重构架构图与模块定义：
- A类封装（A1/A2）：定义为“黑盒执行器”，强调 100% SOP 覆盖和异常抛出机制（Trace）。
- B类封装（B/C）：定义为“外骨骼/透镜”，强调“使能性约束”（强制输出 ORBIT/PRISM 思维链）和多步推理。
- 补充“校准接口”设计（极其关键）：在架构和API层面，增加“自我辩护（CoT 输出路径）”和“结构化反馈槽（前端纠错数据如何打标回收）”的流转设计，落实“过程即数据”。
- 重构架构图与模块定义：
🎯 目标 3：深化业务逻辑与工程映射（业务深度不足）
- 现状缺陷：草稿中“3.3 通用销售心智模型”过于扁平，轮机长看不出 ORBIT/PRISM 模型是如何通过代码和 Prompt 结构化落地的。
- 优化动作：
- 引入 CCPE 框架示例：在“配置文件结构”中，不仅列出文件名，更要用 CCPE（Core-Execution-Constraint-Operation）展示一个 Prompt 结构切片，让轮机长知道如何把业务逻辑封装进文本。
- 明确状态机与工作流控制：主 Agent (
wantsong-sales) 作为编排者，如何判断客户所处阶段？（是强规则匹配，还是依赖 LLM 意图识别？）需要给出清晰的状态流转图。
🎯 目标 4：重塑落地实施计划（执行纪律的贯彻）
- 现状缺陷：当前的里程碑是传统的软件外包式进度（开发->测试->上线），没有体现出“绿野仙踪协议”和“混合工程”。
- 优化动作：
- 前置“绿野仙踪”测试：在阶段一之前，增加手动模拟流转的验证节点（价值未验证前，轮机长先不写 MCP 接口，用 Mock 数据硬编码跑通）。
- 细化“自动化评测集”建设：在阶段二和三中，增加构建100条医美对话/录音的黄金测试集（Golden Dataset）任务，强调“用数据去魅”，必须达到如85%的专家相似度才能部署生产。
- 增强监控与容灾设计：详细定义“异常抛出 Trace”机制，Dify 宕机或弱模型幻觉时的默认降级话术（确保销售前线不出现系统崩溃报错）。
船长，你看这个问题清单和优化方向是否准确把握了你的意图？请回答我的 4 个提问，我们就可以立即开始重构并输出完美的《新部署文档 v2.0》。
3
回答
-
关于“校准接口 (Calibration Interface)”的落地点：
- 本次只是部署方式变化，不涉及到功能变化。我们现在的方式是编码写死的，现在OpenClaw是我们想用来解决Agentic方式的框架。
- 而具体到你的这个问题，我们有功能说明2.0版，里面会涉及到反馈、迭代这些功能。但是这个不是此次考虑的范围。
-
关于 A1/A2（逻辑轮机）的弱模型能力边界：
- 目前我考虑所有的专家智能体都用强模型，这个是验证过的，且得到客户认可的。这部分是草稿上需要修改的。
- 一个原则是：OpenClaw Agent聚焦于自动化；Dify Agent聚焦于专业化。
-
关于知识库 (Knowledge Base) 的物理归属： 旧文档比较旧，是开发前的内容，不是开发后。只是为了了解整体内容，有个初步认识。 我整理这个部署文档，是为了让轮机长拿着，重新设计相应的设计文档。 现在行业、企业知识库都是在数据库里，医美系统可以提供MCP服务供外部调取。在我们新的文档里，不用关注如何取得的细节（从数据库还是从文件），只要描述清楚需要什么接口，或者提供什么服务就行。 包括有什么字段，都不是我们这个部署迁移文档要或者能够解决的。比如，企业信息的json结构我们没有，但是我们说这里需要一个企业信息接口，或者提供查询企业信息的MCP服务。
-
关于 OpenClaw 的部署环境： 暂时考虑部署在Linux实机上。这部分我也不太确切，我刚刚接触OpenClaw，不同的部署环境有什么影响？ 处理原始聊天文本、录音转写这些，我们现在的系统（医美系统）程序上已经都处理了，可以考虑复用这些已经存在的功能。让医美系统提供接口或服务就行。
确认目标
🎯 目标 1：补足 OpenClaw 认知鸿沟（写给轮机长的科普与对齐）
同意。
🎯 目标 2：注入 HiFi 方法论灵魂（从“调接口”到“造密封舱”）
这部分我暂时保留意见，因为整个系统是按照方法论做的，且已经在客户那边投入使用了。 我们这次只是做架构迁移，应该不需要再次注入吧，这个你再斟酌下。
🎯 目标 3：深化业务逻辑与工程映射（业务深度不足）
CCPE框架仅用于专家智能体，这些智能体是成熟的，轮机长们也都清楚。
主 Agent (wantsong-sales) 是本次在OpenClaw上新增的，所以重点放在这里就行。
🎯 目标 4：重塑落地实施计划（执行纪律的贯彻）
这个不需要，实际上这是第一轮迭代的尾声，第二轮的起点。 而这次是技术更迭而不是业务驱动的。 第一轮我们就是按照方法论执行的。而这次技术迭代，对客户来说是透明的，只是我们的架构调整后适应性更强了。
指令
基于我的回答和确认，了解我们所处的阶段，进展，思考本篇部署方案的定位。 然后重新规划一个更合理的方案框架（提纲）给我，我来确认。
收到，船长。你的纠偏非常及时且精准。
既然第一轮的业务价值已经跑通，专家智能体的能力（A1/A2/B/C）已经得到了客户认可，那么我们现在的核心任务就是**“给这台已经验证过的V6发动机（Dify），换上一个更现代、扩展性更强、原生支持Agentic调度的新底盘（OpenClaw）”**。
这纯粹是一次技术底座的换代与重构，对前端业务线是透明的。我们的目标是建立标准化的大脑（Dify）与手脚（医美系统/MCP）的连接中枢。
基于此，我将这份《新部署文档》的定位调整为：《基于 OpenClaw 的智能体中枢架构迁移与接口契约文档》。目标读者是我们的轮机长（开发团队），核心目的是让他们理解这套新架构的组件职责、网络流转、接口定义以及主控Agent的编排逻辑。
以下是我重新规划的文档大纲（草稿 V2 提纲），请船长审阅：
# 📄 《智能体中枢架构迁移与部署方案 (OpenClaw 版)》文档大纲
## 0. 文档定位与阅读指南
* **面向对象**：系统架构师、后端开发工程师（轮机长）。
* **核心共识**：本次重构不涉及业务逻辑与 Prompt 的推倒重来，纯粹为架构升级。
* **架构基调**：**OpenClaw 负责自动化与流程编排；Dify 负责专业化与深度推理。** 医美系统负责数据供给与存储。
## 1. 为什么引入 OpenClaw（技术背景与收益）
* **当前痛点**：硬编码调用 Dify API 的局限性（维护成本高、难以复用、缺乏统一的状态流转管理）。
* **OpenClaw 的价值**：作为原生 Agentic 框架，提供极佳的路由分发能力和原生的 MCP（模型上下文协议）支持，将“业务系统写死逻辑”解放为“主智能体动态调度”。
* **部署环境说明**：说明 OpenClaw 将作为 Daemon（守护进程）部署在 Linux 实机上，与医美服务器进行内网/专线通信的物理拓扑。
## 2. 认知对齐：OpenClaw 核心概念速记（写给轮机长）
*(用轮机长最熟悉的语言，快速解释 OpenClaw 的骨架)*
* **Gateway (网关)**：系统的守护进程，负责维持 Session、接收前端 IM 或 API 请求。
* **Agent Runtime (代理运行时)**：执行中枢，也是我们部署主控 Agent (`wantsong-sales`) 的地方。
* **MCP (Model Context Protocol)**：取代过去散落的 API 接口。OpenClaw 原生支持的工具调用标准，让医美系统以标准格式向 Agent 暴露服务。
* **Dify Skill 桥接**：OpenClaw 如何把 Dify 的工作流/Agent 包装成自己的“子技能 (Sub-agent)”。
## 3. 全局架构拓扑与指责边界
*(重新绘制物理与逻辑架构图)*
* **逻辑分离三层架构**：
* **交互与底座层 (医美系统)**：负责前端展示、原生业务功能执行、提供数据查询与写入的 MCP 服务。
* **中枢调度层 (OpenClaw)**：唯一的流量入口，负责意图识别、会话管理、工具调用分发。
* **专家认知层 (Dify)**：保留原有的 A1(清洗)、A2(复盘)、B(画像)、C(话术)，全部采用强模型。
* **数据流转图**：展示一个完整请求（如：“开始面诊复盘”）是如何从医美系统 -> OpenClaw -> Dify -> 医美系统的。
## 4. 核心增量设计：主控编排 Agent (`wantsong-sales`)
*(本次迁移的重中之重，说明 OpenClaw 内部是怎么干活的)*
* **主控 Agent 的定位与人设**：它是流程的“路由器”和“状态机”，不负责干脏活累活。
* **调度逻辑与状态控制**：主控 Agent 如何根据医美系统传来的上下文，决定调用 A1 还是 A2？（意图识别逻辑与工作流编排）。
* **Prompt 框架 (精简版)**：给轮机长展示主控 Agent 的指令长什么样，它是如何理解当前销售环节的。
* **降级与容错处理**：如果 Dify 接口超时，主控 Agent 如何向医美前端抛出友好的兜底话术或 Trace 日志。
## 5. 接口契约与 MCP 服务定义 (Interface Contracts)
*(屏蔽具体实现细节，只定义医美系统需要向 OpenClaw 提供哪些服务，用于指导轮机长开发接口)*
* **5.1 触发入口接口 (Inbound)**
* 医美系统如何通过 HTTP API 唤醒 OpenClaw（带上 `customer_id` 等上下文参数）。
* **5.2 医美系统需提供的 MCP 服务列表 (Outbound)**
* `query_customer_data`：获取用户档案与原始数据（聊天/录音文本）接口。
* `query_knowledge_base`：获取机构信息、话术等知识的接口。
* `save_agent_result`：保存 A1/A2/B/C 分析报告到数据库的接口。
* *(说明：无需关注底层是读文件还是查库，只需满足 MCP 协议标准即可)*。
## 6. Linux 实机部署与系统切流计划
*(纯技术视角的实施步骤)*
* **环境准备**：Node.js 运行环境、PM2/Systemd 守护进程配置、网关鉴权配置。
* **网络与安全配置**：OpenClaw 与 Dify、OpenClaw 与医美系统之间的访问授权与超时设置。
* **里程碑划分（纯工程实施）**：
* **阶段 1：底座打通**（部署 OpenClaw，跑通医美系统提供的一个测试 MCP 接口）。
* **阶段 2：挂载专家**（在 OpenClaw 中配置 Dify API 桥接，跑通 A1-C 单点调用）。
* **阶段 3：主控联调**（主控 Agent 上线，跑通全链路分发，并在测试环境验证数据一致性）。
* **阶段 4：生产切流**（平滑替换旧的直连 API 代码）。
航行官的建议：
这份提纲去掉了冗余的方法论科普，直奔架构解耦、接口契约和工程实施。第四章专注你强调的“主控Agent设计”，第五章用“接口契约”的形式解决了之前“数据/知识在哪里”的纠结。
船长，你看这个提纲是否符合预期？如果确认无误，我将按照这个结构为你填充具体的文档内容（尤其是第3、4、5章的核心技术细节）。
4
澄清与补充
C1
硬编码调用 Dify API 的局限性（维护成本高、难以复用、缺乏统一的状态流转管理）。
我们现在口号是做一个AI中台，但是轮机长们技术能力水平有限，现在的办法更low，比Dify还差，都是自己写的代码来管理LLM和提示词调用，甚至连切换LLM或者Provider都比较麻烦。 所以这是我强烈借助Dify的原因。
C2
OpenClaw 的价值：作为原生 Agentic 框架，提供极佳的路由分发能力和原生的 MCP（模型上下文协议）支持，将“业务系统写死逻辑”解放为“主智能体动态调度”。
现在的轮机长是传统Java软件工程师转型而来，但是学习效率底下，没法掌握agentic框架，这是我们的中台效果差，我强烈用OpenClaw的原因。
C3
说明 OpenClaw 将作为 Daemon（守护进程）部署在 Linux 实机上，与医美服务器进行内网/专线通信的物理拓扑。
OpenClaw现在有安全问题，所以我们考虑一台单独的机器部署；若成熟了，我们会和医美服务器部署在一起。但是现阶段会用单独的机器。
C4
你这里丢失一些关键信息——三层结构
这个销售智能体，都是高客单价销售的智能体，从心智模型角度来讲具有通用性，只是配套不同的行业话术和企业的信息（介绍、配套产品等特色）。 从我的角度出发，便于维护的话：
- 打造一套通用的（高客单价）销售智能体
- 配套不同的行业、企业信息 就能实现眼镜销售、招生、卖期货保险等等这些高客单价销售的智能化赋能。
我们现在的框架会导致不同的企业、行业都需要单独部署一套，有很大的维护工作量；根本没法剥离行业话术库；甚至不同的企业，由于都是硬编码写死，也需要单独部署。这是架构上的最大的问题。 需要你了解原文档中这部分的机制3.4 三层配置结构，补充新文档的结构。 即现在的销售系统是需要每次独立部署的单体系统，将来可不可以做成SAAS类的；即使独立部署前端，后台部分是否可以最大化的复用。
C5
调用场景的缺失。缺失了4.2 调用流程（完整示例）。 现在的医美系统只能登录系统来使用，利用OpenClaw可以在IM中使用了，这是与之前区别。
C6
试验和生产环境，这个缺失了。 这个涉及到OpenClaw的配置，备份与部署的问题。 对我们现在来说，还算是个挑战，需要强调。
C7
实施计划部分，原来的和你提纲中的可能都不行。 我们此次涉及到框架大调整，我觉得部署方案出来后，让他们拿着原来的完整的设计方案，配套这个部署方案，重新输出一个全新的设计方案，再说里程碑节点。
指令
根据我的澄清内容，重新输出一个提纲，等我确认。
GE
收到，船长。你的这7点澄清非常致命，直接点出了我们当前团队的真实工程现状和未来的商业化愿景（SaaS化/中台化）。
我之前的提纲确实在一定程度上高估了轮机长们在AI领域的工程直觉，忽略了他们从传统Java硬编码转型过来的痛苦；同时也遗漏了你最看重的架构复用性（三层结构）和端侧体验突破（IM接入）。
根据你的最新指示，我将这份方案的定位彻底调整为：一份既是“架构升级蓝图”，又是给传统软件工程师的“Agentic思想启蒙与执行契约”。
以下是重构后的提纲 V3 版本，请船长最后定夺：
# 📄 《智能体中枢架构迁移与部署方案 (OpenClaw + Dify)》大纲规划
## 0. 文档定位与阅读指南
* **面向对象**：后端开发工程师（轮机长）。
* **核心动作**：阅读并理解本部署方案后，需结合原《销售洞察智能体设计文档》，**重新输出一份全新的、基于本架构的系统级详细设计方案**。
* **思想转变**：从“控制流硬编码”转向“Agentic动态调度”，从“单体交付”转向“中台化复用”。
## 1. 架构升级背景：为什么我们要引入这套新底座？
*(直击轮机长目前的开发痛点，解释选型逻辑)*
* **痛点直击 (现状盘点)**：
* **代码泥潭**：当前完全依靠手工编写代码来管理 LLM 调用和冗长的提示词，导致系统极度耦合，连切换大模型/供应商都成为噩梦。
* **单体地狱**：每次面对不同企业或行业（如医美、教育），都需要重新硬编码、单独部署一套完整的系统，维护成本呈现指数级上升。
* **破局之道 (新选型价值)**：
* **为何用 Dify (专家中台)**：将易变的 Prompt 和强模型调用从 Java 代码中剥离，实现可视化编排。让系统真正具备可维护的“AI 大脑”。
* **为何用 OpenClaw (自动化编排引擎)**：鉴于团队缺乏从零手搓 Agentic 框架的经验，引入原生具备路由分发、上下文管理和多渠道接入的 OpenClaw，能让我们免于陷入“制造轮子”的无底洞，直接获得企业级的 Agent 调度能力。
## 2. 核心架构跃迁：从“一次性项目”到“高复用 SaaS 后台”
*(重点回填 C4：三层配置结构，指导轮机长如何进行解耦设计)*
* **核心理念**：将不变的逻辑沉淀，将变化的知识外置。
* **2.1 第一层：通用销售心智底座 (The Core)**
* **物理归属**：部署在 OpenClaw (主控调度) + Dify (A1/A2/B/C 专家逻辑)。
* **特性**：抽象出高客单价销售的通用 SOP（接触-挖掘-方案-逼单）。这部分代码与配置是完全跨行业的，**所有租户/客户共享此核心**。
* **2.2 第二层：行业知识层 (Industry Domain)**
* **物理归属**：医美系统数据库 (提供 MCP 服务) 或 Dify 知识库。
* **特性**：存储医美、眼镜、教育等不同行业的专业术语与话术库。通过参数动态切换。
* **2.3 第三层：企业定制层 (Enterprise Specifics)**
* **物理归属**：医美系统/客户侧 CRM。
* **特性**：企业的介绍、具体商品SKU、价格表。由外部系统通过 MCP 喂给 Agent。
## 3. 物理部署拓扑与安全隔离设计
*(重点回填 C3：安全隔离策略)*
* **网络与机器规划**：
* **前端/业务端**：现有的医美 CRM 服务器。
* **大脑端**：云端或内网的 Dify 平台。
* **中枢端**：**一台完全独立、物理隔离的 Linux 服务器**，专用于运行 OpenClaw Daemon。
* **隔离原因与契约**：鉴于 OpenClaw 拥有极高的系统级权限，现阶段必须与存储敏感业务数据的医美服务器隔离。两者之间**仅允许通过鉴权后的 MCP (HTTP) 协议进行受控的数据交换**。现有医美系统已处理的“文本录音解析”等脏活继续保留，仅以接口形式提供给 OpenClaw。
## 4. 全新调用场景与流转工作流
*(重点回填 C5：多渠道入口展现)*
* **场景一：系统内嵌式触发 (System API)**
* **表现形式**：咨询师在 CRM 后台点击“生成面诊复盘”。
* **数据流向**：CRM -> API 请求 OpenClaw -> OpenClaw 调用 Dify A2/B/C -> OpenClaw 调用 CRM MCP 存入结果 -> 前端展示。
* **场景二：IM 伴随式触发 (基于 OpenClaw 的巨大增量)**
* **表现形式**：咨询师在企业微信/飞书等 IM 软件中直接 @系统 ：“帮我分析一下张三的聊天记录”。
* **数据流向**：IM 消息 -> OpenClaw Gateway -> OpenClaw 从 MCP 获取张三资料 -> 调用 Dify A1 -> OpenClaw 将结果推回 IM 窗口。
* **意义**：系统从“被动工具”变成了“全天候待命的助理”。
## 5. 接口契约：医美系统如何通过 MCP 与 OpenClaw 对话？
*(指导 Java 开发需要写哪些新接口，屏蔽 OpenClaw 内部细节)*
* **概念翻译**：将 MCP 解释为 Java 开发熟悉的“标准化的 RESTful API 规范”，只是客户端变成了大模型。
* **核心接口清单**：
* **入参服务**：获取客户档案、获取聊天记录文本、获取录音转写文本。
* **知识服务**：获取指定行业/企业的话术与资料。
* **出参服务**：接收并落盘 Agent 生成的 JSON 格式分析报告。
## 6. 环境管理与配置迁移指南 (挑战点攻克)
*(重点回填 C6：实战部署纪律)*
* **试验环境 vs 生产环境**：
* 试验环境（沙箱/测试机）：用于调试 OpenClaw 的 Gateway 路由与 Dify 工作流。
* 生产环境（独立 Linux 主机）：对接真实的医美服务器和脱敏数据。
* **配置管理与备份机制**：
* 强调 OpenClaw 的配置是以工作区（Workspace）和本地文件形式存在的。
* 规定轮机长必须将 OpenClaw 的配置文件、技能（Skills）挂载脚本纳入 Git 版本控制。
* 制定从试验环境向生产环境导入配置的标准操作流程（SOP）。
## 7. 下一步行动要求
*(重点回填 C7：抛弃旧里程碑，明确当前动作)*
* **交付物要求**：本方案发布后，轮机长团队需结合《旧版销售洞察智能体设计文档》，于 [X] 个工作日内输出《V2.0 智能中枢系统详细设计文档》。
* **后续节奏**：详细设计评审通过后，再行制定具体的开发、联调与灰度上线里程碑。
船长，这样重排之后，整份文档的“战斗檄文”属性更强了。既告诉了轮机长们**“过去的苦日子到头了，不用再手搓Prompt了”，又明确了“三层架构的宏大目标”，并且划定了“安全部署隔离与 MCP 接口开发”**的硬性边界。
如果这个提纲可以，我马上开始为你起草正文内容！
5
本次提纲基本上达到我的目标了。 现在共有8小节，从0开始。我建议分四次输出，每次两小节。
请你做一个内部思考，以减少错误提升质量，然后输出第0和1小节内容。
内部思考与质量把控 (Internal Thought Process)
- 明确受众画像：本阶段输出的读者是“轮机长”（传统Java后端开发工程师）。他们目前的痛点是深陷于硬编码拼接 Prompt、管理大模型 API 调用的泥潭中，对 Agentic（智能体化）架构缺乏直觉，且面临多租户/多行业部署带来的代码复用地狱。
- 设定语气与叙事逻辑：文档不能是冷冰冰的说明书，而应该是一份“技术檄文”与“破局指南”。第一步（第0节）必须下达清晰的执行指令，明确看完文档后要产出什么；第二步（第1节）要做到“共情与解药并存”，先精准指出他们现在用 Java 写 AI 逻辑有多痛苦，然后顺理成章地引出 Dify + OpenClaw 这套组合拳为什么能拯救他们。
- 核心概念的平滑翻译：
- 不要一开始就堆砌学术概念。
- 要把 Dify 解释为“把 Prompt 和大模型调用从 Java 代码里拔出来放到可视化的专门地方去”。
- 要把 OpenClaw 解释为“一个现成的、自带路由和上下文记忆的总开关，不用你们自己去写恶心的状态机了”。
- 防错检查：确保没有涉及第2节及以后的“三层架构”、“独立物理机部署”等过深细节，严格控制在第0和1节的提纲范围内，保持循序渐进。
# 📄 《智能体中枢架构迁移与部署方案 (OpenClaw + Dify 版)》
## 0. 文档定位与阅读指南
### 0.1 面向对象
本文档的核心读者为**系统架构师与后端开发工程师（轮机长团队）**。
### 0.2 核心动作与交付契约
这是一份**架构升级蓝图**与**接口契约指导**。
请各位轮机长在仔细阅读并透彻理解本方案后，**结合原《旧版销售洞察智能体设计文档》（该文档定义了我们经受过市场验证的业务内核与 AI 逻辑），重新输出一份全新的、基于本混合架构的《V2.0 智能中枢系统详细设计文档》**。
本方案未列出最终的开发里程碑，因为**“详细设计评审通过”**才是下一阶段开发工作正式启动的前提。
### 0.3 核心思想转变（Mindset Shift）
在进入具体的技术细节前，整个研发团队必须完成以下两个根本性的思想转变：
1. **从“控制流硬编码”转向“Agentic 动态调度”**：
过去的系统里，用户的一个点击，是由 Java 代码里的 `if-else` 来决定调用哪个大模型 API；现在的系统里，Java 只是提供数据的“手脚”，真正决定下一步该干什么的是处于中枢位置的主控智能体（Agent）。
2. **从“单体项目交付”转向“中台化可复用架构”**：
我们不再为“A医美机构”或“B教育集团”单独开发一套包含完整 AI 逻辑的后台代码。我们要构建的是一个“通用的高客单价销售 AI 中枢”，业务线的差异仅仅体现为配置参数和外部挂载知识库的不同。
---
## 1. 架构升级背景：为什么我们要引入这套新底座？
在第一轮的开发迭代中，我们成功跑通了业务闭环，证明了我们基于“深度画像”与“专业复盘”的智能体能够切实帮客户提升销售转化率。但随着业务准备向多行业（如眼镜、教育、金融）、多企业横向扩张，我们底层的工程架构正在逼近极限。
### 1.1 痛点直击：我们当下的工程泥潭
如果你是负责核心后台的开发，你现在一定面临着以下极其痛苦的现状：
* **代码泥潭与极度耦合**：当前，系统完全依靠手工编写的 Java 代码来管理 LLM（大语言模型）的调用。冗长且极易变动的 Prompt（提示词）被硬编码在字符串里；为了管理上下文，写了极其丑陋的会话状态机；一旦业务方要求切换更便宜或更聪明的底层模型（哪怕只是换一个 Provider），都可能引发伤筋动骨的代码重构。
* **单体地狱与复用灾难**：我们目前的架构本质上是“将某个特定企业的业务逻辑与系统代码绑死”。这意味着，每当我们签下一个新行业的客户，就需要把整套代码 Copy 一份，重新硬编码修改里面的业务约束并单独部署。这完全违背了 SaaS 化和 AI 中台化的商业愿景，维护成本正在呈指数级上升。
### 1.2 破局之道：Dify + OpenClaw 的双擎驱动
为了彻底解决上述痛点，我们不再使用“手工作坊”的方式造轮子，而是引入业界最前沿的两大专业底座来进行明确的**职责解耦**：
#### 为什么引入 Dify（打造专家大脑中台）？
* **价值定位**：**剥离极易挥发的 AI 认知逻辑**。
* **解决的问题**：把所有的 Prompt、复杂的多步推理（如 A1/A2/B/C 智能体的内部逻辑）、知识库检索机制，**全部从 Java 后端代码中连根拔起**，迁移到 Dify 平台。Dify 提供了可视化的工作流编排和极佳的模型切换兼容性，让我们的系统拥有了一个可独立维护、独立升级的“AI 大脑”。Java 工程师再也不用去维护大段的 Prompt 字符串了。
#### 为什么引入 OpenClaw（打造自动化编排引擎）？
* **价值定位**：**原生智能体（Agentic）时代的中央调度器**。
* **解决的问题**：如果仅仅接入 Dify，我们依然需要在 Java 里写代码来决定“何时调用哪个 Dify 接口”。鉴于团队目前缺乏从零手搓 Agentic 框架的经验（目前的自研方案扩展性极差），我们直接引入在开源界备受推崇的新星框架 **OpenClaw**。
* **它能带来什么**：
1. **开箱即用的路由与状态管理**：它天生就是一个优秀的“调度员”，能够管理不同用户的并发会话（Session），自动识别用户意图并分发任务。
2. **原生支持 MCP（模型上下文协议）**：它定义了一套标准，我们的 Java 后台以后只需要按照标准提供接口（比如“提供客户张三的聊天记录”），OpenClaw 的 Agent 就会在需要时**主动**来调用，彻底扭转了过去“Java 控制 AI”的被动局面，变成了“AI 根据需要调用 Java 接口”。
3. **多渠道原生接入**：它自带与企业微信、飞书、WhatsApp 等多种 IM 工具的桥接能力，为我们未来将系统从“后台管理页面”推向“销售员聊天窗口（伴随式助理）”铺平了道路。
**总结**：医美系统负责提供数据底座（手脚），Dify 负责提供深度认知能力（左脑），而 OpenClaw 则是协调这一切、并主动对外沟通的中枢神经（右脑）。这就是我们此次迁移的终极目标。
6
好的符合预期，继续下两章的撰写。
内部思考与质量把控 (Internal Thought Process)
- 紧扣轮机长视角与架构解耦：第2章的核心是解决“C4-复用性与SaaS化”问题。对于习惯了单体应用的Java开发来说，“逻辑与数据分离”是常识，但“AI认知逻辑与行业知识分离”是个新课题。我需要用他们熟悉的“底层框架-中间件-业务层”概念来类比我们的“三层配置结构”，让他们明白以后接入新行业，只需要“配库”不需要“改代码”。
- 强调物理隔离与安全红线：第3章对应“C3-OpenClaw部署环境”。作为一个拥有底层系统操作权限的Agent框架，OpenClaw的安全性是当前的痛点。必须明确划定物理隔离边界，禁止OpenClaw直连数据库，强制所有交互走MCP协议。同时，安抚轮机长：以前写好的语音转写(ASR)和文本解析代码不用扔，继续在Java端跑，封装成接口给OpenClaw调就行。
- 语言风格保持：继续使用指令式、架构白皮书式的行文风格，辅以结构化图表展现层级关系，降低阅读者的认知负荷。
2. 核心架构跃迁：从“一次性项目”到“高复用 SaaS 后台”
为了实现真正的 AI 中台化，我们必须摒弃“来一个客户，拷一份代码，改一堆 Prompt”的作坊式开发。
从本质上看，无论是医美面诊、高端眼科咨询，还是国际学校招生、金融保险推销，它们都属于**“高客单价、高决策门槛的复杂销售”**。其背后的“通用销售心智模型”（接触 -> 痛点挖掘 -> 方案展示 -> 异议处理 -> 逼单转化）是完全一致的。
因此，我们的架构设计必须实现**“将不变的逻辑沉淀，将变化的知识外置”**。在新的部署架构中，系统将被严格划分为三个解耦的层级：
2.1 第一层：通用销售心智底座 (The Core)
- 物理归属：这一层是系统的“引擎”，部署在 OpenClaw (主控调度) 和 Dify (认知推理) 中。
- 核心内容：包含 OpenClaw 中的主控 Agent (
wantsong-sales) 的调度逻辑，以及 Dify 中 A1(清洗)/A2(复盘)/B(画像)/C(话术) 四个专家智能体的骨架 Prompt 和工作流（Workflow）。 - 工程契约：这一层的代码和配置是跨行业、跨企业完全共享的。 无论接入哪个租户，这里的逻辑都不允许被硬编码修改。它只定义“如何进行心理分析（ORBIT/PRISM模型）”和“如何流转任务”，绝不包含“双眼皮手术多少钱”这种具象信息。
2.2 第二层：行业知识层 (Industry Domain)
- 物理归属：这一层是系统的“行业字典”，存储于医美系统/业务线数据库，或作为独立知识库挂载在 Dify 中。
- 核心内容：不同行业的专业术语、SOP 规范、行业黑话、通用痛点库。例如：医美行业的《抗衰项目话术库》或教育行业的《升学焦虑应对指南》。
- 工程契约：当 OpenClaw 的主控 Agent 接到请求时，它会通过参数（如
industry="医美"）动态调取该层的特定知识块，作为上下文喂给底座模型，实现“一秒切换行业大脑”。
2.3 第三层：企业定制层 (Enterprise Specifics)
- 物理归属：这一层是系统的“实时业务数据”，严格存放在各个租户自己的 CRM/业务系统数据库中。
- 核心内容：特定企业的介绍、具体的商品 SKU、实时价格表、过往成功案例，以及客户（如“张三”）的私密聊天记录和面诊录音。
- 工程契约：大模型绝不记忆这些动态数据。 这些数据必须由 Java 业务系统通过 MCP（Model Context Protocol）服务，在 Agent 需要分析时，像“递纸条”一样实时喂给 OpenClaw。
💡 给轮机长的话：理解了这三层结构，你们未来的工作就不再是“为客户 A 写一套 AI 系统”，而是“维护一套通用的 AI 底座，然后为客户 A 提供数据查询 API（MCP）”。这将极大解放你们的生产力。
3. 物理部署拓扑与安全隔离设计
鉴于 OpenClaw 是一个真正意义上的 Agentic 框架（它有能力执行脚本、读写文件、甚至反向控制系统），并且目前开源版本在沙箱隔离上仍在演进中，安全性与物理隔离是我们本次部署的最高红线。
3.1 三端隔离的网络与机器规划
系统将在物理/逻辑上拆分为三个独立运行的节点集：
- 大脑端（Dify 中台）：
- 负责执行最消耗算力的长文本推理和画像生成。
- 部署在独立的云服务或内部 GPU 集群上，通过标准 HTTP API 对外提供服务。
- 中枢端（OpenClaw 守护进程）：
- 这是所有流量的汇聚点和任务分发器。
- 强制要求：必须部署在一台完全独立、物理隔离的 Linux 服务器上。 绝对不允许将其与现有的医美 CRM 数据库混合部署在同一台机器上。
- OpenClaw 将作为 Daemon（后台守护进程）常驻运行，管理所有的通道接入（IM/API）和 Session 状态。
- 前端与底座端（现有业务线/医美系统）：
- 这是传统的 Java 后台与前端页面。它掌握着客户核心资料、订单数据。
- 职责复用：原系统中已经开发好的“微信文本解析”、“录音文件 ASR 转写”等脏活累活，全部保留，不需要用 AI 重写。 这些功能继续在 Java 端运行，处理好后生成结构化文本。
3.2 交互契约与安全隔离策略
为了防止高权限的 OpenClaw Agent 出现幻觉或被恶意提示词注入（Prompt Injection）从而影响核心业务库，我们制定以下交互契约：
- 禁止直连数据库：OpenClaw 所在的 Linux 服务器，其网络策略（Firewall/VPC）禁止直接访问医美系统的 MySQL/Redis 数据库。
- 唯一的通信桥梁（MCP）：医美系统与 OpenClaw 之间，仅允许通过鉴权后的 MCP (基于 HTTP 的模型上下文协议) 进行受控的数据交换。
- 最小权限原则：Java 端提供的 MCP 接口必须是原子化且受限的。例如，只提供
get_parsed_chat_text(customer_id)接口供 OpenClaw 读取清洗好的文本，而不提供任何可以被 Agent 泛化调用的底层 SQL 查询能力。
通过这种“物理隔离 + 协议白名单”的设计，我们既享受了 OpenClaw 强大的自动化编排能力，又死死守住了企业核心数据的安全底线。
7
很好，继续保持，输出下两章的内容。
内部思考与质量把控 (Internal Thought Process)
- 紧扣“体验跃迁”与“开发减负”：第4章的核心是展示引入 OpenClaw 后带来的巨大业务增量（即 IM 伴随式触发，C5需求）。必须向轮机长们讲清楚，过去要实现“飞书/企微机器人”需要在 Java 端写大量恶心的 Webhook 鉴权、消息解析和会话状态保持代码；现在有了 OpenClaw，这些工作全部由底座原生接管，Java 开发彻底解放。
- 通俗化解释 MCP (Model Context Protocol)：第5章是整篇文档最落地的“接口契约”。对于传统的 Java 工程师，“大模型主动调接口”是一个反直觉的概念。我必须将 MCP 降维解释为“带有标准格式的 RESTful API/Controller”，让他们明白：他们不需要学什么高深的 AI 框架原理，只需要按规范写好 Spring Boot 接口，OpenClaw 的主控 Agent 就会像一个“智能的前端”一样，在需要的时候自动发起 HTTP 请求。
- 流程图与结构化：在描述工作流和接口清单时，大量使用层级列表和数据流向说明，确保轮机长在后续重写《详细设计文档》时，可以直接把这里的流转图抄过去转化为 UML 时序图。
4. 全新调用场景与流转工作流
引入 OpenClaw 最直观的业务价值，是系统交互方式的根本性升级。过去，我们的医美系统是一个“被动工具”，销售必须登录后台、找到客户、点击按钮才能触发分析。现在，借由 OpenClaw 强大的原生通道（Channels）能力和路由分发，我们将同时支持系统内嵌式与IM 伴随式两大核心调用场景。
4.1 场景一：系统内嵌式触发 (System API)
这是对现有业务流程的平滑替换。业务人员依然在 CRM 系统操作，但背后的控制流已经完全交由 OpenClaw 接管。
- 业务表现：咨询师在 CRM 后台的“张三档案页”，点击“生成面诊复盘报告”。
- 数据流向契约：
- [触发] 医美前端 -> 发送 HTTP 请求至医美 Java 后台。
- [唤醒] 医美 Java 后台 -> 构造包含
customer_id的系统级指令，调用 OpenClaw Gateway 的 API（类似于“帮我处理张三的复盘”）。 - [分发] OpenClaw 主控 Agent 接收指令 -> 识别意图为“面诊复盘” -> 调起 Dify 中的 Agent A2 (复盘质检)。
- [索要数据] OpenClaw 发现缺少文本 -> 触发 MCP 工具，向医美 Java 后台请求
获取张三录音转写文本接口 -> Java 后台返回文本。 - [推理] OpenClaw 将文本传给 Dify Agent A2 进行深度思考与抽取 -> Dify 返回结构化 JSON 报告。
- [落盘与展示] OpenClaw 再次触发 MCP 工具，调用 Java 后台的
保存分析结果接口 -> Java 后台存入数据库，并通知前端刷新页面展示。
- 开发减负点：Java 后台不再需要等待和维护与 Dify 的长连接，也不需要处理重试逻辑，只需“发出指令”和“提供查询/保存接口”。
4.2 场景二：IM 伴随式触发 (基于 OpenClaw 的巨大增量)
这是我们迈向“全天候数字员工”的关键一步。OpenClaw 原生内置了企微、飞书、钉钉等 IM 接入网关，它自带了多轮对话记忆（Session）和用户鉴权绑定。
- 业务表现：销售员在下班路上，直接在企业微信/飞书里 @销售智能体 ：“帮我分析一下张三刚才发给我的微信聊天记录，看看他在顾虑什么。”
- 数据流向契约：
- [接收消息] IM (飞书/企微) Webhook -> OpenClaw Gateway 直接接收自然语言消息。
- [意图识别] OpenClaw 主控 Agent 理解自然语言 -> 识别出客户是“张三”，动作是“聊天记录清洗与画像”。
- [动态调度] OpenClaw 自动请求医美系统 MCP (获取张三聊天记录) -> 串行调用 Dify Agent A1 (清洗) 和 Agent B (画像)。
- [流式返回] OpenClaw 将最终生成的《3C客户心理全景图》和催单建议，直接以富文本/Markdown 的形式推送回飞书/企微的聊天窗口。
- 开发减负点：轮机长们一行对接企微/飞书的代码都不用写。不用处理恶心的 Token 刷新、不用写正则匹配用户发了什么指令、不用维护并发 Session，所有通信脏活全部由 OpenClaw 底层网关包办。
5. 接口契约：医美系统如何通过 MCP 与 OpenClaw 对话？
前面多次提到 MCP (Model Context Protocol)。不要被这个高大上的词汇吓到。
💡 给 Java 开发的降维解释：对于你们来说，开发一个 MCP 工具，仅仅意味着写一个符合标准出入参规范的 Spring Boot Controller (RESTful API)。唯一的区别是，这个接口不是给前端 Vue/React 调用的，而是给 OpenClaw 的大模型调用的。大模型会自己阅读这个接口的 description，并在需要时自动把参数填好发给你们。
为了支撑上述场景，医美 Java 后台需要向 OpenClaw 提供以下两类标准化接口契约：
5.1 Inbound 接口（医美系统唤醒 OpenClaw）
当业务系统需要主动发起任务时（如场景一），通过 HTTP REST API 唤醒 OpenClaw。
- 接口类型：POST
/v1/chat/completions(遵循类 OpenAI 接口标准，由 OpenClaw 提供) - 核心载荷 (Payload)：
{ "model": "openclaw:wantsong-sales", "messages":[ { "role": "system", "content": "你现在的上下文客户是 ID: CUST_8899。请执行【面诊复盘】工作流。" } ] }
5.2 Outbound 接口（OpenClaw 调用的 MCP 服务列表）
这是轮机长接下来开发的核心工作量所在。请基于这套契约，在现有的医美系统中暴露出相应的 API（建议统一加上 /api/mcp/v1/ 前缀及独立的 Token 鉴权）：
① 数据供给类 MCP (提供原材料)
get_customer_chat_logs:- 入参：
customer_id - 出参：该客户最近的原始微信聊天文本内容（由现有 Java 逻辑从库中提取）。
- 入参：
get_customer_transcripts:- 入参：
customer_id - 出参：该客户的面诊录音转写全量文本（复用现有的 ASR 解析入库结果）。
- 入参：
② 知识下发类 MCP (实现三层架构的解耦)
query_industry_knowledge:- 入参：
industry_code(如 "medical_beauty"),topic(如 "price_objection") - 出参：该行业的通用 SOP 或反击话术。
- 入参：
query_enterprise_profile:- 入参：
enterprise_id - 出参：该企业的简介、主打项目及脱敏的成功案例库（动态下发，杜绝大模型幻觉）。
- 入参：
③ 结果落盘类 MCP (接收劳动成果)
save_agent_analysis_result:- 入参：
customer_id,agent_type(如 A1/A2/B/C),result_json(Dify 产出的结构化数据) - 执行逻辑：Java 后台拿到 JSON 后，将其解析并落盘到 CRM 数据库的对应字段中，触发后续的业务流（如生成待办任务）。
- 入参：
开发铁律：在提供以上 MCP 接口时，必须对入参做严格校验，且严格限制查询范围。绝不允许提供类似 execute_sql 这种危险的泛型接口，必须将 OpenClaw 视为一个“具有极高执行力但可能随时发癫的外部实习生”来进行权限管控。
8
继续输出后两章内容。
内部思考与质量把控 (Internal Thought Process)
- 直击工程痛点，规范运维纪律：第6章解决的是“C6-试验与生产环境配置”的挑战。对于习惯了传统 CI/CD（如 Jenkins 打包 JAR/镜像）的 Java 团队来说，Agent 框架的部署往往伴随着大量散落的 JSON/YAML 配置和 Prompt 文件。必须在这里立下规矩：所有的 OpenClaw 工作区配置必须“代码化（Configuration as Code）”并纳入 Git 管理，杜绝“在生产服务器上手动改 Prompt”的恶习。
- 踩刹车与指明方向：第7章是对“C7-抛弃旧里程碑”的直接回应。过去我们习惯写完草稿就开始定排期写代码，这次要强行踩一脚刹车。明确告诉轮机长：现在的任务是“拿着这份新地图和老系统的灵魂，去重新画施工图（详细设计文档）”。把具体的 API 字段定义、时序图交给他们去完成，彻底完成从“业务开发”到“底层研发”的视角转换。
- 保持基调一致：用极具号召力的结语收尾，再次强调这次重构对团队技术成长和公司商业化（SaaS）的巨大意义。
6. 环境管理与配置迁移指南 (挑战点攻克)
Agentic 系统的运维与传统 Java Web 系统有着本质的区别。OpenClaw 的运行不仅依赖代码，更高度依赖其所在的工作区（Workspace）状态、技能挂载（Skills）和动态路由配置。为了防止出现“在我的环境里明明能跑”的经典灾难，我们必须建立极其严格的环境隔离与配置迁移纪律。
6.1 试验环境 vs 生产环境的物理界定
-
试验环境 (Sandbox / Test Environment)
- 定位：这是我们的“炼丹炉”和“排雷场”。
- 配置：部署在开发测试机的 OpenClaw Gateway。它连接的是 Dify 的测试环境 API，以及医美系统 Java 后台的测试环境 MCP 接口（甚至可以是 Mock 数据）。
- 核心任务：用于调试主控 Agent 的意图识别是否精准、Dify 的 Prompt 是否会产生幻觉、以及飞书/企微通道的连通性测试。
-
生产环境 (Production Environment)
- 定位：高稳定性的“中枢神经”。
- 配置：部署在前文提到的完全独立的 Linux 物理/虚拟主机上。连接真实的医美服务器和生产库（仅限 MCP 协议）。
- 安全红线：生产环境的 OpenClaw 严禁开启任何未经白名单授权的 Terminal（终端）或 FileSystem（文件系统）执行权限。
6.2 配置管理与“代码化”备份机制 (Configuration as Code)
在使用 OpenClaw 时，最容易犯的错误就是“在服务器的 Web UI 上随手改了一个配置，但没有记录下来”，导致系统崩溃时无法回滚。我们必须遵守以下配置迁移 SOP（标准作业程序）：
- 工作区 Git 化：
OpenClaw 的所有核心配置（包括
agents.json、主控调度提示词、挂载的 Dify API Skill 脚本、通道绑定配置等），默认存放在本地工作区目录中（如~/.openclaw/workspace/）。 要求：该目录下的所有非敏感配置文档，必须建立一个专属的 Git 仓库（如ai-agent-configs）进行版本控制。 - 禁止生产环境直改（No Hot-Fixing on Prod）：
任何针对主控 Agent 调度逻辑的修改、MCP 接口地址的更换，必须先在 Git 仓库修改，提交 PR 并由架构师 Review 后，通过 CI/CD 流水线拉取到生产服务器的 OpenClaw 工作区，然后执行
openclaw gateway reload热重载。 - 敏感凭证分离：
Dify 的 API Key、医美系统的 MCP 鉴权 Token、企业微信的 Secret，严禁硬编码在 Git 仓库中。必须统一使用生产服务器的环境变量（
.env文件）进行注入。
7. 下一步行动要求 (Next Steps)
各位轮机长，至此，新架构的蓝图已经铺开。我们通过 Dify 抽离了极其复杂的 AI 认知逻辑，通过 OpenClaw 获得了一个不知疲倦、能听懂人话、能自动调接口的中央调度器。
过去的痛点正在被彻底剥离，通往“一处开发，多租户多行业复用”的 SaaS 大门已经打开。但现在还不是写代码的时候。
7.1 当前交付物要求：重构《详细设计文档》
请各位轮机长以本《部署方案》为骨架，结合我们最初始的《旧版销售洞察智能体核心设计文档》（保留里面关于 A1/A2/B/C 的业务定义），在 [待定] 个工作日内，向我输出一份全新的 《V2.0 智能中枢系统详细设计文档》。
这份详细设计文档必须包含但不限于以下内容：
- 全局 UML 时序图：画出从前端/IM 触发 -> Java 后台 -> OpenClaw -> Dify -> OpenClaw -> Java 后台 落盘的完整交互时序。
- MCP 接口契约明细：详细定义第 5 章中提到的所有 Inbound 和 Outbound API 的 JSON 结构、字段类型、非空约束及错误码（Error Codes）。
- 数据库 Schema 变更预案：为了适配多行业/多租户（三层架构），现有的 CRM 数据库需要做哪些表结构改造（如增加
industry_code字典表、独立的话术库存储表等）。
7.2 后续节奏控制
在《V2.0 详细设计文档》进行严格的架构评审（Review）并全员达成共识通过之前，任何人不得提前启动 Java 业务代码或 OpenClaw 脚本的开发。
一旦评审通过，我们将制定具体的开发、联调与灰度上线里程碑。我们第一阶段的战役，将从“跑通一个最简单的 MCP 连通性测试”开始。
准备启航吧，让我们的系统从“传统软件”真正进化为“数字生命体”！