f32216e1e0
添加了关于管家主动性与行业配置体系的发散探讨文档，包含现状诊断、关键讨论、架构设计等内容。同时添加了测试失败的截图和日志文件。
8.1 KiB
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 确认：全套一起做。 顺序：
- 4 个行业内置配置
- 学习循环基础
- Tauri 行业配置加载
- 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 批准计划，将在新会话中推进实施。