# ZCLAW 发散式头脑风暴记录

> 日期: 2026-04-07
> 状态: 进行中
> 待归档至: docs/ 或 memory 系统

---

## 1. 项目起源与核心哲学

### 1.1 OpenClaw 的启发

ZCLAW 诞生的起点是 **OpenClaw 的人格系统**。其核心吸引力在于：

- AI 不只是工具，而是**伙伴** — 能一起成长
- 能**主动检讨**并学习，从而为用户解决问题
- 长期相处中建立信任感和默契

### 1.2 能力融合路径

在 OpenClaw 基础上，吸收了三个系统的特长：

| 来源 | 借鉴内容 |
|------|---------|
| **OpenFang** | Hands 自主能力体系 + 安全性设计 |
| **OpenMaic** | 教育类专项技能 |
| **DeerFlow 2.0** | 架构模式（clarification、渐进式加载、sub-agent） |

### 1.3 终极目标

**打造一个能解决用户任何问题的管家式系统。**

---

## 2. 产品定位：与市场差异化

### 2.1 核心差异

| 维度 | 市面 Claw 系统 | ZCLAW |
|------|---------------|-------|
| 用户画像 | 开发者、技术爱好者 | **非编程用户、不擅长用电脑的人** |
| 交互模型 | 选模型、配参数、写 Prompt | **只管说，我来理解和执行** |
| AI 角色 | 工具/助手 | **伙伴 — 会成长、会反思、会主动** |
| 能力边界 | 用户能描述清楚的范围内 | **用户说不清楚的，也要想办法解决** |

### 2.2 行业模板 + 潮汕特色产业

SaaS Admin 端预设了行业 Agent 模板，聚焦潮汕地区特色产业：

- **玩具** — 澄海"玩具之都"，全球供应
- **制衣** — 潮汕纺织服装集群
- **医疗** — 汕头医疗器械产业带
- **教育** — 潮汕教育传统

**目的**：不是给用户一个空白 AI，而是给一个"已经入行多年的学徒"。

---

## 3. 三层知识模型

```
┌─────────────────────────────────┐
│  Layer 3: 用户独有记忆            │  ← 对话、操作、偏好、习惯
│  （私有、不可共享、真正的差异点）    │     主要成长来源
├─────────────────────────────────┤
│  Layer 2: 行业知识库              │  ← 系统持续采集丰富
│  （共享、持续丰富、运营驱动）        │     同行业 Agent 共享
├─────────────────────────────────┤
│  Layer 1: 行业模板                │  ← 预装基础能力、工作流、话术
│  （共享、相对稳定、冷启动用）        │     冷启动起点
└─────────────────────────────────┘
```

**成长模型**：
- 模板是起点（Layer 1）
- 系统持续丰富行业知识库（Layer 2）
- **主要成长来自用户自己的对话和操作积累**（Layer 3）
- 每个用户的 Agent 最终长得不一样

---

## 4. "成长时刻"的定义

### 4.1 核心理念

> **产品的价值体现于它能为用户解决多大的问题。**

"成长时刻" = **Agent 主动发现行业痛点，制定解决方案并交付**。

### 4.2 四层能力模型

| 层次 | 表现 | 性质 | 示例 |
|------|------|------|------|
| L1 回答 | "CE 认证需要哪些材料？" | 百科全书 | 被动回答 |
| L2 提醒 | "下周五要做 CE 检测了" | 秘书 | 基于日历/规则 |
| L3 执行 | "我帮你填好了 CE 申请表" | 助理 | 代办事务 |
| **L4 管家** | **"分析了 3 批退货原因，核心是包装合规。拟了新规范 + 供应商方案"** | **伙伴** | **主动发现 + 方案制造** |

**ZCLAW 的目标是 L4。**

### 4.3 触发方式：静默分析 + 主动推送

- Agent 在后台**持续分析**用户数据和行业动态
- 发现问题后**主动推送**解决方案
- 不等用户提问，不等用户触发

### 4.4 信任建立：全开 + 透明日志

- **从第一天就全部能力开启**
- 用户可以看到 Agent 在分析什么、怎么分析的
- 信任来源于**透明**，而非渐进式引导

**关键体验**：每个主动推送的洞察，都能追溯到用户自己的某次操作或对话：
- "这个想法来自：您 3/7 提到'这批货又迟了' + 3/15 问了广州仓库租金 + 近 3 个月物流费用明细"

### 4.5 痛点识别引擎：方案 A（LLM 自分析）

**选择理由**：方案 B（规则筛选）需要行业专家定义规则，无人能保证规则质量，会降低体验。

**流程设计**：

```
用户对话 → 对话结束 → LLM 自分析（Haiku，低成本）
  "刚才的对话里，用户有没有遇到反复出现的困难？"
    ↓ 有 → 存入 PainPoint 记忆
    ↓
  后台定期聚合同类 PainPoint，计次
    ↓ 累积到阈值 → Sonnet 生成方案 → 推送给用户
```

**成本控制**：
- 痛点分析用 Haiku（便宜 3x）
- 跨会话聚合用 Haiku
- 只在"生成方案"时用 Sonnet
- 整体成本与方案 B 相当，但无需人工维护规则

**行业模板的角色转变**：
- 不再是"预定义痛点规则"
- 而是"提供行业知识背景"，让 LLM 更懂这个行业的上下文

---

## 5. OpenViking：被忽视的 L4 基石

### 5.1 已有能力清单

OpenViking 记忆系统已经具备大量 L4 管家所需的基础能力：

| L4 需求 | OpenViking 模块 | 说明 |
|---------|----------------|------|
| 对话记忆提取 | `memory/extractor.rs` | LLM 驱动，自动从对话中提取关键信息 |
| 语义搜索 | `viking_find` + FTS5 + TF-IDF + embedding | 混合检索，70% embedding + 30% TF-IDF |
| 上下文分层 | `context_builder.rs` | L0 概览 / L1 摘要 / L2 全文，token 预算控制 |
| 记忆注入 | `injector.rs` + `viking_inject_prompt` | 将相关记忆注入 system prompt |
| 自我反思 | `intelligence/reflection.rs` | Agent 自我反思引擎 |
| 主动心跳 | `intelligence/heartbeat.rs` | 主动心跳引擎 |
| 上下文压缩 | `intelligence/compactor.rs` | 长对话压缩 + 记忆刷出 |
| 对话钩子 | `intelligence_hooks.rs` | 对话前后集成钩子 |
| UI | `VikingPanel.tsx` | 语义记忆浏览面板 |

URI 命名空间：`viking://user/memories/...` + `viking://agent/{id}/memories/...`
存储：SQLite + FTS5 + TF-IDF
记忆类型：Preference / Knowledge / Experience / Session

### 5.2 关键认知修正

之前的差距分析有误。L4 不是"从零建"，而是"激活已有基础 + 补最后公里"。

**真正的差距**：
- ~~痛点识别引擎~~ → reflection + extractor 已有，缺的是"痛点聚合 + 置信度评分"层
- ~~透明推理链~~ → viking:// URI 已有溯源能力，缺的是"面向用户的白话解释"UI
- ~~方案生成器~~ → Pipeline DSL + 技能路由已有，缺的是"痛点 → 方案"的自动编排
- ~~主动推送~~ → heartbeat 已有基础设施，缺的是"推送时机决策"逻辑

### 5.3 反思：为什么 OpenViking 没被充分利用

这个问题值得深入思考。可能的原因：
1. 模块存在但未被端到端打通
2. reflection/heartbeat 能力存在但使用场景不够具体
3. 记忆提取在运行但"提炼痛点"这一步没有闭环

---

## 6. 核心结论：L4 路径是"激活"而非"新建"

### 6.1 诊断

ZCLAW 的核心问题不是"缺什么模块"，而是"已有模块到底在不在工作"。

项目存在一个反复出现的模式：**代码写了、能力定义了，但"写完 → 跑通 → 用户能感知到"这条链路经常断在最后一截。**

- OpenViking 有 extractor/reflection/heartbeat/compactor — 不确定实际运行状态
- 131 个 SaaS API — 前端未全部接通
- 177 个 Tauri 命令 — 16 个 reserved
- 75 个 SKILL.md — 大部分未做执行验证

### 6.2 优先级修正

之前的差距分析 → 修正后的优先级：

| 之前以为的 | 修正后 |
|-----------|--------|
| 新建痛点识别引擎 | **验证 reflection.rs 是否在跑** |
| 新建透明推理链 UI | **验证 extractor 输出是否能被用户看到** |
| 新建方案生成器 | **验证 heartbeat 是否能触发推送** |
| 新建主动推送基础设施 | **验证现有 heartbeat → inject → prompt 链路** |

**第一步：端到端跑通 OpenViking 已有能力，确认哪些是活的、哪些是壳。**

### 6.3 与稳定化阶段的一脉相承

这个判断与已完成的稳定化工作完全一致：
- Sprint 1-2：P0 修复 + 断链接通
- Batch 5：GrowthIntegration 桥接
- V12 审计：模块化审计 + @reserved 标注
- 死代码清理：Automation/SkillMarket 删除

L4 激活是这个方向的延续 — 不是新的建设阶段，而是**对已有投资的兑现**。

---

## 7. 技能市场悖论 — 结论

**技能完全隐式。** SkillMarket 删除是正确决定。

- 75 个 SKILL.md 定位为 AI 的内部能力图，不是用户的商品目录
- 用户只感知"我说了需求 → 管家帮我搞定了"
- 技能选择由 AI 语义路由自动完成
- 管家面板不展示"技能列表"，而是展示"我帮你做了什么"

## 8. Multi-agent — 结论

**管家调度专家模式，尽快接通。**

- 主 Agent（管家）是用户唯一对话的入口
- 管家拆解复杂任务，分派给专家 Agent 并行执行
- 专家 Agent 可以有独立的上下文窗口，深入各自领域
- 用户感知不到 Multi-agent 的存在，只感知到"管家帮我搞定了"

已有多 agent 资产：
- 912 行 Director 代码（feature-gated）
- sub-agent ID 匹配（已修复）
- 行业 Agent 模板 → 可作为专家 Agent 的基础
- OpenViking → 每个专家可以有独立记忆上下文

## 9. 桌面端 vs SaaS — 结论

**后勤部模式：三层服务架构。**

```
Layer 1: 运营层 (SaaS + Admin)
  → 运营团队使用，管理行业知识库、模板、用户账户
Layer 2: 管家层 (桌面端 Agent)
  → 用户的私人管家，对话交互，技能隐式路由，Multi-agent 调度
Layer 3: 用户层 (对话界面)
  → 零门槛，零配置，只有聊天
```

SaaS 的 131 API 不需要全部被桌面端接通。
桌面端只需接通：获取行业知识、同步模板、上报使用数据等关键接口。

## 10. 非技术用户交互 — 结论

**聊天窗口 + 管家面板。**

聊天窗口是用户的主世界，管家面板是透明日志的 UI 化：

管家面板内容：
- 🧠 我最近在关注（主动发现的痛点 + 推理链）
- 💡 我提出的方案（方案追踪、采纳状态）
- 📝 我记得关于您（用户偏好、习惯、事实）

管家面板不是设置页面，是"管家的工作台公开给用户看"。

---

## 11. 综合产品蓝图

将所有讨论串成一个完整画面：

```
用户视角（非技术用户）:
  打开 ZCLAW → 跟管家聊天 → 管家帮我搞定一切
  偶尔打开管家面板 → 看看管家在关注什么、记住了什么

管家内部（用户看不到）:
  接收用户消息
    → LLM 理解意图
    → 语义路由到 75 个技能中的合适能力
    → 复杂任务拆解 → 调度多个专家 Agent 并行
    → OpenViking 记忆系统持续提取、反思、聚合
    → 发现痛点 → 生成方案 → 推送给用户

运营层（运营团队）:
  Admin 后台更新行业知识库和模板
    → SaaS 存储 → 同步到桌面端
    → 管家获得新知识，不中断用户使用
```

三层知识模型 + 四层能力模型 + 三层服务架构，构成 ZCLAW 的完整产品 DNA。

### 补充：LLM 供给架构

**桌面端用户不使用本地 LLM，而是通过 SaaS 的 Token 池获取大模型能力。**

```
用户订阅 Plan（如 coding plan）
  → SaaS 后端分配 Token 额度 + 配置可用模型
    → 桌面端通过 SaaS API 调用大模型
      → 不同厂家（OpenAI/Anthropic/Doubao/...）的模型统一通过 SaaS 路由

用户端：零配置，打开就能用
运营端：通过 Admin 管理 Token 池、模型配额、定价方案
```

这意味着：
1. 用户不需要知道"模型"是什么概念 — 管家自动选择最合适的模型
2. SaaS 后端承担模型路由、Token 计费、配额管理的职责
3. 桌面端的"模型配置"UI 对普通用户应该隐藏，只对高级/开发者用户可见
4. Token 池是核心商业模式 — 用户为"管家能力"付费，不是为"模型调用量"付费

---

## 12. 冷启动体验 — 结论

**行业剧本预设：Admin 后台配置每个行业模板的冷启动流程。**

- 管家开场白（行业定制）
- 引导问题列表（快速了解用户具体业务）
- 行业热点话题（展示"我懂你的行业"）
- 用户回答存入 OpenViking → 即时个性化
- 冷启动质量可运营：运营团队持续迭代剧本

## 13. 管家人格 + 反馈闭环 — 结论

**可配置人格：运营定基线，用户通过自然对话塑造。**

Admin 配置：tone（语气）、proactiveness（主动性）、formality（正式度）、humor（幽默度）
用户微调：通过对话自然发生（"别叫我王总了"→ formality 自动降低）

反馈闭环设计：

| 用户反应 | 管家行为 | 存入 OpenViking |
|---------|---------|----------------|
| "你说得不对" | 承认错误 + 请用户纠正 | lessons_learned |
| "我不是这个意思" | 重新理解 + 确认 | patterns（修正偏好） |
| "别再提这个了" | 立即停止 | preferences（排除项） |
| "上次那个方案很好" | 强化权重 | lessons_learned（正向） |

关键：管家的学习要"说出来" — "我记下来了，以后不会搞混了"。
强化伙伴感：用户知道管家在听、在学、在改。

## 14. 数据安全 + 离线 — 结论

**强化安全路线，核心能力：数据脱敏令牌化（Data Tokenization）。**

### 14.1 数据脱敏

在中间件链中新增 `DataMaskingMiddleware`：

```
用户消息 → 脱敏（本地） → LLM（脱敏数据） → 还原（本地） → 用户看到
例: "A公司" → "company_00234" → LLM 处理 → "A公司"
```

- 令牌映射表存在本地 OpenViking，永远不上传
- SaaS 和 LLM 提供商只能看到脱敏后的数据
- 产品承诺："你的商业数据永远不会离开你的电脑"
- **这是核心产品差异化**

### 14.2 离线模式

- 离线时管家不可用（不能调用 LLM）
- 所有本地数据可查看：历史对话、管家面板、记忆、方案
- OpenViking 本地数据加密存储

### 14.3 安全架构总结

| 数据类型 | 存储位置 | 安全措施 |
|---------|---------|---------|
| 对话内容 | SaaS 中转 | 脱敏后传输，不留存原文 |
| OpenViking 记忆 | 本地 SQLite | 加密存储，不上传 |
| PainPoint 洞察 | 本地 OpenViking | 最敏感，脱敏 + 加密 |
| 令牌映射表 | 本地 OpenViking | 永远不上传 |
| 行业知识库 | SaaS PostgreSQL | 运营数据，正常管理 |

---

## 15. 后续行动

- [ ] 归档讨论成果至 memory 系统
- [ ] 可能产出：OpenViking 端到端验证计划
- [ ] 可能产出：L4 激活路线图
- [ ] 可能产出：DataMaskingMiddleware 设计文档
- [ ] 可能产出：冷启动剧本模板设计