2e5f63be32
Some checks failed
CI / Lint & TypeCheck (push) Has been cancelled
CI / Unit Tests (push) Has been cancelled
CI / Build Frontend (push) Has been cancelled
CI / Rust Check (push) Has been cancelled
CI / Security Scan (push) Has been cancelled
CI / E2E Tests (push) Has been cancelled
- Create docs/brainstorming/ with 5 discussion records (Mar 16 - Apr 7) - Archive ~30 outdated audit reports (V5-V11) to docs/archive/old-audits/ - Archive superseded analysis docs to docs/archive/old-analysis/ - Archive completed session plans to docs/archive/old-plans/ - Archive old test reports/validations to respective archive folders - Remove empty directories left after moves - Keep current docs: TRUTH.md, feature docs, deployment, knowledge-base, superpowers
396 lines
15 KiB
Markdown
396 lines
15 KiB
Markdown
# 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 设计文档
|
||
- [ ] 可能产出：冷启动剧本模板设计
|