zclaw_openfang/docs/brainstorming/2026-04-07-第一轮发散探讨-产品愿景.md

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 设计文档
• 可能产出：冷启动剧本模板设计