f32216e1e0
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
添加了关于管家主动性与行业配置体系的发散探讨文档，包含现状诊断、关键讨论、架构设计等内容。同时添加了测试失败的截图和日志文件。
205 lines
8.1 KiB
Markdown
205 lines
8.1 KiB
Markdown
# ZCLAW 发散式探讨 — 管家主动性与行业配置体系
|
||
|
||
> 日期: 2026-04-12
|
||
> 形式: 发散式互动探讨
|
||
> 参与者: iven + Claude
|
||
> 计划产出: `plans/fancy-kindling-karp.md`
|
||
|
||
---
|
||
|
||
## 议题：Agent 对话主动性 — 如何让管家主动解决问题？
|
||
|
||
### 抛砖
|
||
|
||
管家模式已有痛点检测、用户画像、人格检测、Heartbeat 等感知能力，但感知完之后什么都没做。用户提出讨论如何让 agent 主动去解决用户提出的问题，让用户觉得系统人性化、是合格管家。
|
||
|
||
---
|
||
|
||
## 一、现状诊断
|
||
|
||
### 感知层 vs 行动层
|
||
|
||
**核心发现：感知层齐了，行动层为零。**
|
||
|
||
| 已有能力 | 状态 | 核心局限 |
|
||
|----------|------|---------|
|
||
| ButlerRouter 关键词路由 (4域81词) | ✅ | 只注入 prompt，不改变行为模式 |
|
||
| 痛点检测+聚合 (18信号词) | ✅ | 检测后只存储，不触发行动 |
|
||
| 用户画像 (7维度) | ✅ | 只在 prompt 里一行摘要 |
|
||
| 人格检测 (含 proactiveness) | ✅ | 检测了但无行为差异 |
|
||
| Heartbeat (5项检查) | ✅ | 检查结果不推向用户 |
|
||
| 经验闭环 (痛点→方案→经验) | ✅ | 静默复用，用户无感 |
|
||
| 冷启动 (4阶段状态机) | ✅ | 只首次，固定问候语 |
|
||
|
||
**一句话：管家能"看到"用户的痛点、画像、情绪，但看完之后什么都没做。**
|
||
|
||
### Hermes 分析的关键启发
|
||
|
||
讨论前先读了 `wiki/hermes-analysis.md`（Hermes Agent 44.1K stars 竞品分析），核心洞察：
|
||
|
||
> **"大多数 Agent 记录了'发生了什么'，Hermes 提取了'什么有效'"**
|
||
|
||
ZCLAW 的痛点检测、画像积累、经验存储全是在**记录发生了什么**，但"什么有效"这一步断了。闭环没合上。
|
||
|
||
---
|
||
|
||
## 二、关键讨论与共识
|
||
|
||
### 2.1 主动性光谱
|
||
|
||
```
|
||
L0 被动响应 "你问我答" ← 当前位置
|
||
L1 主动理解 "你没说明白，我追问" ← 有痛点检测但不行动
|
||
L2 主动建议 "你问A，我顺便提醒B" ← 近期目标
|
||
L3 主动行动 "检测到问题，我先做了" ← 中期目标
|
||
L4 预见行动 "你还没说，我已经准备好了" ← 远期愿景
|
||
```
|
||
|
||
**共识：目标 L2-L3。**
|
||
|
||
L4 不应该是弹窗通知，而是**"用户下次来的时候，管家已经准备好了"**。这符合之前"建议不代理"原则，也避免打扰。
|
||
|
||
### 2.2 主动性由谁驱动？
|
||
|
||
**讨论：** System Prompt 注入 vs Heartbeat 调度 vs 中间件规则？
|
||
|
||
**共识（参考 Hermes）：混合驱动，Prompt 驱动为主。**
|
||
|
||
| 路径 | 占比 | 用途 |
|
||
|------|------|------|
|
||
| System Prompt 注入 | 80% | 对话内主动建议 |
|
||
| Heartbeat 调度 | 15% | 跨对话准备工作 |
|
||
| 中间件规则 | 5% | 安全兜底 |
|
||
|
||
**核心认知：主动性不是独立模块，是 prompt 质量的结果。** 当 system prompt 包含足够用户画像、痛点历史、过往经验时，LLM 自然会产生主动行为。
|
||
|
||
### 2.3 学习驱动方式
|
||
|
||
**讨论：** Hermes 核心是"Agent 自己决定什么值得学习"。ZCLAW 要走这条路还是规则驱动？
|
||
|
||
**iven 提出关键约束：** ZCLAW 不仅面向医疗，面向所有行业。
|
||
|
||
**论证过程：**
|
||
|
||
纯规则驱动走不通——4 行业 81 关键词已经暴露问题，每进入一个新行业就要写一套新规则。500 个关键词、20 个域，这不是产品是定制开发。
|
||
|
||
纯 LLM 驱动也不对——不可审计（企业客户问"Agent 学了什么"无法回答）、可能学错、隐私风险、成本问题。
|
||
|
||
**共识：混合模式 — LLM 做发动机，规则做刹车。**
|
||
|
||
```
|
||
规则管"不能做什么" → 安全边界、质量门控、触发信号
|
||
LLM 管"应该学什么" → 判断什么有效、提取经验、生成建议
|
||
```
|
||
|
||
**与 Hermes 的区别：** Hermes 无条件触发 Periodic Nudge，ZCLAW 采用**被动触发**：
|
||
- 对话结束后检查触发信号（纯规则，零 LLM 成本）
|
||
- 有信号才调 LLM 提取
|
||
- 触发信号：痛点阈值跨过 / 隐式正反馈 / 连续 3+ 工具调用 / 用户纠正
|
||
|
||
### 2.4 行业配置架构
|
||
|
||
**iven 提出架构方向：** 行业配置做到 SaaS Admin 端，Tauri 端初始化时选择行业，从 Admin 端获取配置。
|
||
|
||
**讨论重点：**
|
||
|
||
**Q: 行业配置粒度？**
|
||
- A: 模板化（空白表单）→ 灵活但质量低
|
||
- B: 预设+微调 → 快但不可扩展
|
||
- C: 分层（内置基础+Admin增强）→ **共识选择**
|
||
|
||
共识：C（分层），设计上预留向 A 演进。内置 4 行业基础配置保证质量，Admin 可覆盖/增强，后续迁移内置到 Admin DB。
|
||
|
||
**Q: 一个用户可以属于多个行业吗？**
|
||
**共识：多行业并行。** Admin 控制用户可用的行业列表。ButlerRouter 只扫描授权行业的关键词，多行业同时打分，LLM 做最终判断。
|
||
|
||
**Q: 数据源？**
|
||
**共识：Admin 管理为主。** SaaS Admin 是真相源，Tauri 拉取+本地缓存（离线可用），增量同步。
|
||
|
||
### 2.5 Admin 用户管理增强
|
||
|
||
**iven 衍生提出：** Admin 用户管理需要全面升级：
|
||
|
||
| 新增能力 | 说明 |
|
||
|----------|------|
|
||
| 行业授权 | 控制用户可使用的行业列表 |
|
||
| 页面权限 | 控制用户在 Tauri 端能看到哪些页面/功能 |
|
||
| 套餐关联 | 用户关联 BillingPlan |
|
||
| Agent 模板 | 初始 Agent 人格、预配技能、工作流 |
|
||
|
||
### 2.6 实施顺序
|
||
|
||
**iven 确认：全套一起做。** 顺序：
|
||
1. 4 个行业内置配置
|
||
2. 学习循环基础
|
||
3. Tauri 行业配置加载
|
||
4. Admin 行业管理 API+UI
|
||
|
||
---
|
||
|
||
## 三、Hermes 参考要点
|
||
|
||
| 维度 | Hermes 做法 | ZCLAW 借鉴 |
|
||
|------|------------|-----------|
|
||
| 学习循环 | Periodic Nudge + Skill 自动创建 | 被动触发 + 经验→技能补丁（成本更低） |
|
||
| 记忆分层 | 4 层（声明/情景/程序/用户建模） | 增强现有 3 层注入力度 + Prompt 冻结 |
|
||
| Prompt Cache | Frozen MEMORY.md，技能用 user message | 计划引入会话内冻结策略 |
|
||
| 上下文压缩 | 多级策略（剪裁→保护头尾→LLM摘要） | 计划增强 CompactionMiddleware |
|
||
| 技能进化 | 自动 patch 更新 | 计划引入（经验→技能补丁） |
|
||
| 用户建模 | Honcho 方言式建模 12 维度 | 增强 UserProfiler 的注入格式 |
|
||
|
||
---
|
||
|
||
## 四、主动性架构全貌
|
||
|
||
```
|
||
SaaS Admin（真相源）
|
||
├── 行业配置 (关键词/Prompt/技能优先级/痛点种子)
|
||
├── 用户权限 (页面可见/行业授权/套餐/Agent模板)
|
||
└── 管理 API
|
||
│
|
||
│ Tauri 初始化拉取 + 缓存
|
||
▼
|
||
Tauri 客户端
|
||
├── 感知层（已有，需增强注入力度）
|
||
│ ├── ButlerRouter → 多行业动态关键词
|
||
│ ├── PainDetector → 18信号词 + 触发信号
|
||
│ ├── UserProfiler → 7维度 + 行业偏好
|
||
│ └── PersonalityDetector → proactiveness 维度
|
||
│
|
||
├── 学习层（新增，混合驱动）
|
||
│ ├── 规则触发（低成本前置判断）
|
||
│ ├── LLM 提取（"什么有效"）
|
||
│ ├── 安全过滤（DataMasking + 格式校验）
|
||
│ └── 持久化（ExperienceStore + UserProfile）
|
||
│
|
||
├── 注入层（已有，需增强）
|
||
│ └── System Prompt 组装（会话开始时冻结）
|
||
│ ├── 行业上下文
|
||
│ ├── 用户画像摘要
|
||
│ ├── 活跃痛点
|
||
│ ├── 相关经验
|
||
│ └── 人格偏好
|
||
│
|
||
└── LLM → 自然产生主动行为
|
||
"我注意到..." / "顺便提醒..." / "上次您提到的..."
|
||
```
|
||
|
||
---
|
||
|
||
## 五、计划产出
|
||
|
||
完整实施计划：`plans/fancy-kindling-karp.md`
|
||
|
||
5 个 Phase、17 个 Task：
|
||
|
||
| Phase | 内容 | 依赖 |
|
||
|-------|------|------|
|
||
| Phase 1 | 行业配置基础（数据模型 + 4行业内置 + ButlerRouter改造） | 无 |
|
||
| Phase 2 | 学习循环基础（触发信号 + LLM提取 + 经验增强） | Phase 1.1 |
|
||
| Phase 3 | Tauri 行业配置加载（拉取缓存 + Rust注入 + Prompt组装 + 行业UI） | Phase 1+2 |
|
||
| Phase 4 | Admin 用户管理增强（行业管理页 + Accounts增强 + SaaS API + 页面可见性） | Phase 1，可与2/3并行 |
|
||
| Phase 5 | 主动行为激活（Prompt冻结 + 跨会话连续性 + Periodic Reflection + 注入格式） | Phase 1-4 |
|
||
|
||
**iven 批准计划，将在新会话中推进实施。**
|