refactor(store): split gatewayStore into specialized domain stores
Major restructuring: - Split monolithic gatewayStore into 5 focused stores: - connectionStore: WebSocket connection and gateway lifecycle - configStore: quickConfig, workspaceInfo, MCP services - agentStore: clones, usage stats, agent management - handStore: hands, approvals, triggers, hand runs - workflowStore: workflows, workflow runs, execution - Update all components to use new stores with selector pattern - Remove
This commit is contained in:
277
docs/analysis/CODE-LEVEL-TODO.md
Normal file
277
docs/analysis/CODE-LEVEL-TODO.md
Normal file
@@ -0,0 +1,277 @@
|
||||
# ZCLAW 代码层面未完成工作分析
|
||||
|
||||
> 分析日期:2026-03-20
|
||||
> 基于 git diff 和代码审查
|
||||
|
||||
## 一、当前重构状态
|
||||
|
||||
### 1.1 已完成的重构
|
||||
|
||||
| 模块 | 原始状态 | 当前状态 | 说明 |
|
||||
|------|----------|----------|------|
|
||||
| gatewayStore.ts | 1800+ 行巨型文件 | ~100 行 facade | 已拆分为 7 个 domain stores |
|
||||
| gateway-client.ts | 65KB 单文件 | 模块化 | 拆分为 5 个文件 |
|
||||
| viking-*.ts | 5 个文件 | 已删除 | 移至 docs/archive/ |
|
||||
| vector-memory.ts | 385 行 | 已删除 | 功能移至 Rust 后端 |
|
||||
| context-builder.ts | 409 行 | 已删除 | 功能移至 Rust 后端 |
|
||||
| session-persistence.ts | 655 行 | 已删除 | 功能移至 Rust 后端 |
|
||||
|
||||
### 1.2 新增文件(未提交)
|
||||
|
||||
```
|
||||
desktop/src/lib/gateway-api.ts - REST API 方法实现
|
||||
desktop/src/lib/gateway-auth.ts - Ed25519 设备认证
|
||||
desktop/src/lib/gateway-storage.ts - URL/token 持久化
|
||||
desktop/src/lib/gateway-types.ts - 协议类型定义
|
||||
desktop/src/store/securityStore.ts - 安全状态管理
|
||||
desktop/src/store/sessionStore.ts - 会话状态管理
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 二、代码层面待完成工作
|
||||
|
||||
### 2.1 🔴 高优先级:Store 迁移
|
||||
|
||||
**问题**:App.tsx 和 34+ 个组件仍使用 `useGatewayStore` (兼容层),而非新的 domain-specific stores。
|
||||
|
||||
**待迁移组件清单**:
|
||||
|
||||
```bash
|
||||
# 查找所有使用 useGatewayStore 的文件
|
||||
desktop/src/App.tsx # 核心入口
|
||||
desktop/src/components/ChatArea.tsx
|
||||
desktop/src/components/Sidebar.tsx
|
||||
desktop/src/components/RightPanel.tsx
|
||||
desktop/src/components/HandsPanel.tsx
|
||||
desktop/src/components/HandApprovalModal.tsx
|
||||
# ... 更多组件
|
||||
```
|
||||
|
||||
**迁移策略**:
|
||||
|
||||
```typescript
|
||||
// 旧方式(兼容层,不推荐)
|
||||
const { hands, triggers, approvals } = useGatewayStore();
|
||||
|
||||
// 新方式(推荐,按需导入)
|
||||
import { useHandStore } from './store/handStore';
|
||||
const { hands, triggers, approvals } = useHandStore();
|
||||
```
|
||||
|
||||
**收益**:
|
||||
- 减少 re-render(当前 useCompositeStore 订阅 40+ 状态)
|
||||
- 更清晰的依赖关系
|
||||
- 更好的代码分割
|
||||
|
||||
---
|
||||
|
||||
### 2.2 🔴 高优先级:useCompositeStore 性能优化
|
||||
|
||||
**问题**:`store/index.ts` 中的 `useCompositeStore` 订阅了所有 store 的几乎所有状态。
|
||||
|
||||
```typescript
|
||||
// 当前实现(有问题)
|
||||
export function useCompositeStore() {
|
||||
// 订阅了 40+ 个状态
|
||||
const connectionState = useConnectionStore((s) => s.connectionState);
|
||||
const gatewayVersion = useConnectionStore((s) => s.gatewayVersion);
|
||||
// ... 40+ 个订阅
|
||||
}
|
||||
```
|
||||
|
||||
**建议**:
|
||||
1. 废弃 `useCompositeStore`
|
||||
2. 组件直接使用 domain-specific stores
|
||||
3. 仅在确实需要跨域状态的场景使用 selector 模式
|
||||
|
||||
---
|
||||
|
||||
### 2.3 🟡 中优先级:测试文件更新
|
||||
|
||||
**已删除测试文件**:
|
||||
```
|
||||
tests/desktop/session-persistence.test.ts (424 行)
|
||||
tests/desktop/vector-memory.test.ts (299 行)
|
||||
tests/desktop/viking-adapter.test.ts (446 行)
|
||||
```
|
||||
|
||||
**需更新测试文件**:
|
||||
```
|
||||
tests/desktop/gatewayStore.test.ts (190 行需更新)
|
||||
tests/desktop/swarm-skills.test.ts (6 行需更新)
|
||||
```
|
||||
|
||||
**缺失测试**:
|
||||
- `securityStore.test.ts` - 新 store 无测试
|
||||
- `sessionStore.test.ts` - 新 store 无测试
|
||||
- `gateway-api.test.ts` - 新模块无测试
|
||||
- `gateway-auth.test.ts` - 新模块无测试
|
||||
|
||||
---
|
||||
|
||||
### 2.4 🟡 中优先级:类型定义清理
|
||||
|
||||
**问题**:`gatewayStore.ts` 仍定义了一些类型,这些应该移到各自的 store 或 types 文件。
|
||||
|
||||
```typescript
|
||||
// gatewayStore.ts 中定义的类型(应迁移)
|
||||
export interface HandRunStore { ... }
|
||||
export interface ScheduledJob { ... }
|
||||
export interface EventTrigger { ... }
|
||||
export interface RunHistoryEntry { ... }
|
||||
```
|
||||
|
||||
**建议**:
|
||||
1. `HandRunStore` → `handStore.ts`
|
||||
2. `ScheduledJob`, `EventTrigger`, `RunHistoryEntry` → 新建 `types/automation.ts`
|
||||
|
||||
---
|
||||
|
||||
### 2.5 🟢 低优先级:组件集成度提升
|
||||
|
||||
**存在但集成度低的组件**:
|
||||
|
||||
| 组件 | 文件 | 问题 |
|
||||
|------|------|------|
|
||||
| HeartbeatConfig | `components/Settings/HeartbeatConfig.tsx` | 未在 Settings 页面使用 |
|
||||
| CreateTriggerModal | `components/Automation/CreateTriggerModal.tsx` | 未在 Automation 面板集成 |
|
||||
| PersonalitySelector | `components/Agent/PersonalitySelector.tsx` | 未在 Agent 创建流程使用 |
|
||||
| ScenarioTags | `components/Agent/ScenarioTags.tsx` | 未在 Agent 编辑使用 |
|
||||
| DevQALoop | `components/Dev/DevQALoop.tsx` | 开发调试组件,未集成 |
|
||||
|
||||
---
|
||||
|
||||
### 2.6 🟢 低优先级:文档与代码同步
|
||||
|
||||
**文档声称完成但代码未验证**:
|
||||
|
||||
| 功能 | 文档状态 | 代码状态 |
|
||||
|------|----------|----------|
|
||||
| 身份演化 | ✅ 完成 | ❓ 未验证与后端集成 |
|
||||
| 上下文压缩 | ✅ 完成 | ❓ 未验证触发条件 |
|
||||
| 心跳巡检 | ✅ 完成 | ❓ 未验证实际执行 |
|
||||
| 记忆持久化 | ✅ 完成 | ❓ 依赖 localStorage |
|
||||
|
||||
---
|
||||
|
||||
## 三、Tauri Rust 后端状态
|
||||
|
||||
### 3.1 已实现的 Rust 模块
|
||||
|
||||
| 模块 | 文件 | 功能 | 状态 |
|
||||
|------|------|------|------|
|
||||
| OpenFang 集成 | `lib.rs` | Gateway 生命周期管理 | ✅ 完整 |
|
||||
| Viking Server | `viking_server.rs` | 本地向量数据库 | ✅ 完整 |
|
||||
| Viking Commands | `viking_commands.rs` | Viking CLI 封装 | ✅ 完整 |
|
||||
| Browser Automation | `browser/*.rs` | Fantoccini 浏览器控制 | ✅ 完整 |
|
||||
| Memory Extraction | `memory/*.rs` | 记忆提取、上下文构建 | ✅ 完整 |
|
||||
| LLM Integration | `llm/mod.rs` | LLM 调用封装 | ✅ 完整 |
|
||||
| Secure Storage | `secure_storage.rs` | OS keyring/keychain | ✅ 完整 |
|
||||
|
||||
### 3.2 Rust 后端与前端对齐问题
|
||||
|
||||
**问题**:前端 `lib/` 下有大量智能逻辑(记忆、反思、心跳),与 Rust 后端功能重叠。
|
||||
|
||||
| 前端文件 | Rust 对应 | 建议 |
|
||||
|----------|-----------|------|
|
||||
| `agent-memory.ts` | `memory/extractor.rs` | 统一到 Rust 端 |
|
||||
| `context-compactor.ts` | `memory/context_builder.rs` | 统一到 Rust 端 |
|
||||
| `heartbeat-engine.ts` | 无 | 迁移到 Rust 端 |
|
||||
| `reflection-engine.ts` | 无 | 迁移到 Rust 端 |
|
||||
| `agent-identity.ts` | 无 | 迁移到 Rust 端 |
|
||||
|
||||
**收益**:
|
||||
- 后端持久运行(关闭浏览器不中断)
|
||||
- 多端共享 Agent 状态
|
||||
- 更可靠的数据持久化
|
||||
|
||||
---
|
||||
|
||||
## 四、技术债务清单
|
||||
|
||||
### 4.1 代码质量
|
||||
|
||||
| 问题 | 位置 | 严重度 |
|
||||
|------|------|--------|
|
||||
| 使用 `any` 类型 | 多处 | 中 |
|
||||
| 空 catch 块 | `sessionStore.ts:119` | 低 |
|
||||
| 硬编码字符串 | 多处 | 低 |
|
||||
| 重复的类型定义 | `gatewayStore.ts` vs 各 store | 中 |
|
||||
|
||||
### 4.2 架构问题
|
||||
|
||||
| 问题 | 说明 | 建议 |
|
||||
|------|------|------|
|
||||
| 前端承担后端职责 | 记忆/反思/心跳在前端 | 迁移到 Rust |
|
||||
| Store 过度订阅 | useCompositeStore 订阅 40+ 状态 | 按需订阅 |
|
||||
| 兼容层膨胀 | gatewayStore.ts 作为 facade | 逐步移除 |
|
||||
|
||||
---
|
||||
|
||||
## 五、行动建议
|
||||
|
||||
### 本周必做
|
||||
|
||||
1. **提交当前重构** - gateway-client 模块化、store 拆分已完成
|
||||
2. **更新测试** - 为新 store 和 gateway 模块添加测试
|
||||
3. **迁移 App.tsx** - 从 useGatewayStore 迁移到 domain stores
|
||||
|
||||
### 两周内
|
||||
|
||||
1. **移除 useCompositeStore** - 组件直接使用 domain stores
|
||||
2. **清理类型定义** - 统一到各自的 store 或 types 文件
|
||||
3. **集成低使用率组件** - HeartbeatConfig, CreateTriggerModal 等
|
||||
|
||||
### 一个月内
|
||||
|
||||
1. **前端智能层迁移** - 将记忆/反思/心跳迁移到 Rust 后端
|
||||
2. **端到端测试** - Playwright + Tauri driver 验证核心流程
|
||||
3. **性能优化** - 减少不必要的 re-render
|
||||
|
||||
---
|
||||
|
||||
## 六、代码变更统计
|
||||
|
||||
```
|
||||
当前未提交变更:
|
||||
21 files changed, 578 insertions(+), 7324 deletions(-)
|
||||
|
||||
删除的文件(已归档):
|
||||
- desktop/src/lib/context-builder.ts (409 行)
|
||||
- desktop/src/lib/session-persistence.ts (655 行)
|
||||
- desktop/src/lib/vector-memory.ts (385 行)
|
||||
- desktop/src/lib/viking-adapter.ts (734 行)
|
||||
- desktop/src/lib/viking-client.ts (353 行)
|
||||
- desktop/src/lib/viking-local.ts (144 行)
|
||||
- desktop/src/lib/viking-memory-adapter.ts (408 行)
|
||||
- desktop/src/lib/viking-server-manager.ts (231 行)
|
||||
|
||||
新增的文件:
|
||||
+ desktop/src/lib/gateway-api.ts (新建)
|
||||
+ desktop/src/lib/gateway-auth.ts (新建)
|
||||
+ desktop/src/lib/gateway-storage.ts (新建)
|
||||
+ desktop/src/lib/gateway-types.ts (新建)
|
||||
+ desktop/src/store/securityStore.ts (新建)
|
||||
+ desktop/src/store/sessionStore.ts (新建)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 七、总结
|
||||
|
||||
**重构进度**:约 70% 完成
|
||||
- ✅ Store 拆分完成
|
||||
- ✅ Gateway Client 模块化完成
|
||||
- ✅ Viking 相关代码清理完成
|
||||
- ⏳ 组件迁移进行中(仍使用兼容层)
|
||||
- ⏳ 测试更新待完成
|
||||
- ❌ 前端智能层迁移未开始
|
||||
|
||||
**最大风险**:
|
||||
1. useCompositeStore 性能问题(40+ 状态订阅)
|
||||
2. 前端智能逻辑(记忆/反思)依赖 localStorage,不可靠
|
||||
3. 缺少端到端测试验证
|
||||
|
||||
**建议策略**:
|
||||
先完成当前重构(提交、测试、组件迁移),再启动前端智能层向 Rust 迁移。
|
||||
304
docs/analysis/ZCLAW-DEEP-ANALYSIS.md
Normal file
304
docs/analysis/ZCLAW-DEEP-ANALYSIS.md
Normal file
@@ -0,0 +1,304 @@
|
||||
# ZCLAW 项目深度梳理分析与头脑风暴
|
||||
|
||||
> 分析日期:2026-03-20
|
||||
|
||||
## 一、项目全景概览
|
||||
|
||||
ZCLAW 是一个基于 OpenFang (类 OpenClaw) 定制化的中文优先 AI Agent 桌面客户端,采用 Tauri 2.0 (Rust + React 19) 架构,目标对标智谱 AutoClaw 和腾讯 QClaw。
|
||||
|
||||
### 1.1 技术栈全景
|
||||
|
||||
| 层级 | 技术选型 | 成熟度 |
|
||||
|------|----------|--------|
|
||||
| 桌面框架 | Tauri 2.0 (Rust + React 19) | ✅ 合理 |
|
||||
| 前端 | React 19 + TailwindCSS + Zustand + Framer Motion + Lucide | ✅ 现代 |
|
||||
| 后端通信 | WebSocket (Gateway Protocol v3) + Tauri Commands | ✅ 完整 |
|
||||
| 状态管理 | Zustand (13 个 Store 文件) + Composite Store | ⚠️ 过度拆分 |
|
||||
| 配置格式 | TOML (替代 JSON) | ✅ 用户友好 |
|
||||
| 测试 | Vitest + jsdom (317 tests) | ✅ 覆盖良好 |
|
||||
| 依赖 | 极精简 (ws + zod) | ✅ 轻量 |
|
||||
|
||||
### 1.2 规模数据
|
||||
|
||||
| 维度 | 数量 |
|
||||
|------|------|
|
||||
| 前端组件 | 50+ .tsx 文件 (88 个 components 目录项) |
|
||||
| Lib 工具 | 42 个 lib 文件 (~65KB gateway-client 最大) |
|
||||
| Store 文件 | 13 个 (gatewayStore 59KB 为最大单文件) |
|
||||
| 类型定义 | 13 个类型文件 |
|
||||
| Skills | 68 个 SKILL.md 技能定义 |
|
||||
| Hands | 7 个 HAND.toml 能力包 |
|
||||
| Plugins | 3 个 (chinese-models, feishu, ui) |
|
||||
| 测试 | 15 个测试文件, 317 tests |
|
||||
| 文档 | 84 个 docs 目录项 |
|
||||
|
||||
---
|
||||
|
||||
## 二、架构深度分析
|
||||
|
||||
### 2.1 数据流架构
|
||||
|
||||
```
|
||||
用户操作 → React UI → Zustand Store → GatewayClient (WS) → OpenFang Kernel
|
||||
↘ TauriGateway (IPC) → Rust Backend
|
||||
↘ VikingClient → OpenViking (向量DB)
|
||||
```
|
||||
|
||||
**优点:**
|
||||
- 清晰的分层设计,UI/Store/Client 职责明确
|
||||
- 统一的 Gateway Client 抽象层,禁止组件内直接创建 WS
|
||||
|
||||
**问题:**
|
||||
- gatewayStore.ts 59KB,是一个巨型 God Store,虽然已拆分出 connectionStore/agentStore/handStore 等,但旧的 gatewayStore 仍保留且被 App.tsx 直接引用
|
||||
- Store Coordinator (store/index.ts) 的 useCompositeStore 订阅了所有 store 的几乎全部状态,会导致任何状态变化触发全量 re-render
|
||||
|
||||
### 2.2 通信层分析
|
||||
|
||||
**Node.js 端 (src/gateway/):**
|
||||
- manager.ts — 子进程管理,有自动重启、健康检查,设计完整
|
||||
- ws-client.ts — 完整的 Protocol v3 握手、请求/响应、事件订阅、自动重连
|
||||
|
||||
**浏览器端 (desktop/src/lib/gateway-client.ts):**
|
||||
- 65KB 的单文件,职责过重,包含了连接管理、RPC 调用、事件监听、所有业务方法
|
||||
|
||||
### 2.3 智能层分析
|
||||
|
||||
这是 ZCLAW 最有价值的差异化层:
|
||||
|
||||
| 模块 | 文件 | 测试 | 集成 |
|
||||
|------|------|------|------|
|
||||
| Agent 记忆 | agent-memory.ts (14KB) | 42 tests | ✅ MemoryPanel |
|
||||
| 身份演化 | agent-identity.ts (10KB) | ✅ | ❓ 后端 |
|
||||
| 上下文压缩 | context-compactor.ts (14KB) | 23 tests | ✅ chatStore |
|
||||
| 自我反思 | reflection-engine.ts (21KB) | 28 tests | ✅ ReflectionLog |
|
||||
| 心跳引擎 | heartbeat-engine.ts (10KB) | ✅ | ❓ 未验证 |
|
||||
| 自主授权 | autonomy-manager.ts (15KB) | ✅ | ✅ AutonomyConfig |
|
||||
| 主动学习 | active-learning.ts (10KB) | ✅ | ✅ ActiveLearningPanel |
|
||||
| Agent 蜂群 | agent-swarm.ts (16KB) | 43 tests | ✅ SwarmDashboard |
|
||||
| 向量记忆 | vector-memory.ts (11KB) | 10 tests | ❌ 未集成到 UI |
|
||||
|
||||
### 2.4 前端组件分析
|
||||
|
||||
**已集成且工作正常:**
|
||||
ChatArea, RightPanel (多 tab), Sidebar, Settings (10 页), HandsPanel, HandApprovalModal, SwarmDashboard, TeamCollaborationView, SkillMarket, AgentOnboardingWizard, AutomationPanel
|
||||
|
||||
**存在但集成度低:**
|
||||
HeartbeatConfig, CreateTriggerModal, PersonalitySelector, ScenarioTags, DevQALoop
|
||||
|
||||
---
|
||||
|
||||
## 三、SWOT 分析
|
||||
|
||||
### 💪 优势 (Strengths)
|
||||
|
||||
1. **技术栈先进** — Tauri 2.0 比 Electron 体积小 10x+,性能好
|
||||
2. **智能层设计深刻** — 记忆系统、身份演化、自我反思、上下文压缩是真正的差异化能力
|
||||
3. **Skills 生态丰富** — 68 个 Skill 覆盖写作、数据分析、社媒运营、前端开发等
|
||||
4. **Hands 系统完整** — 7 个能力包 + 审批/触发/审计全链路
|
||||
5. **中文优先** — 中文模型 Provider (GLM/Qwen/Kimi/MiniMax) + 飞书集成
|
||||
6. **测试覆盖好** — 317 tests, 涵盖核心 lib 和 store
|
||||
7. **文档极其详尽** — 84 个文档文件,有架构图、偏离分析、审计报告、知识库
|
||||
|
||||
### 🔴 劣势 (Weaknesses)
|
||||
|
||||
1. **代码膨胀严重**
|
||||
- gatewayStore.ts 59KB, gateway-client.ts 65KB — 单文件过大
|
||||
- 42 个 lib 文件,部分职责重叠 (viking-*.ts 有 5 个文件)
|
||||
- 88 个 components,复杂度管理困难
|
||||
|
||||
2. **v1→v2 架构迁移未彻底**
|
||||
- src/core/ 归档代码仍保留,v1 的 multi-agent/memory/proactive 与 v2 的 desktop/src/lib 存在概念重叠
|
||||
- 新旧 store 并存 (gatewayStore vs connectionStore/agentStore/...)
|
||||
|
||||
3. **前后端耦合不清晰**
|
||||
- 大量智能逻辑 (记忆、反思、压缩) 在前端 lib 中实现
|
||||
- 这些应该是后端/Gateway 的职责,放在前端会导致:数据不持久、多端不同步、逻辑重复
|
||||
|
||||
4. **真实集成测试缺失**
|
||||
- PROGRESS.md 中 Phase 4 "真实集成测试"全部未完成
|
||||
- 没有端到端测试验证 Gateway 连接→消息收发→模型调用
|
||||
|
||||
5. **Tauri Rust 后端基本空白**
|
||||
- desktop/src-tauri/ 标记为 TODO
|
||||
- 安全存储、子进程管理等应由 Rust 端承担
|
||||
|
||||
6. **配置系统双重标准**
|
||||
- config.toml + chinese-providers.toml 是 TOML 格式
|
||||
- 但 README 提到 openclaw.default.json,plugins 使用 plugin.json
|
||||
- 配置格式不统一
|
||||
|
||||
### 🟡 机会 (Opportunities)
|
||||
|
||||
1. **中国 AI Agent 市场爆发** — 智谱/通义/月之暗面/DeepSeek 的中文模型生态成熟
|
||||
2. **本地优先隐私诉求增长** — 企业和个人对数据隐私要求越来越高
|
||||
3. **OpenFang 生态缺口** — 市场上没有优质的中文定制化 OpenFang 桌面客户端
|
||||
4. **飞书+企业微信整合** — 企业 IM 集成是刚需,特别是在中国市场
|
||||
5. **Skill 市场变现** — 74 个 Skills 可以发展成社区市场
|
||||
|
||||
### 🔵 威胁 (Threats)
|
||||
|
||||
1. **竞品迭代极快** — Cursor/Windsurf/AutoClaw/QClaw 都在快速迭代
|
||||
2. **OpenFang 上游变化** — Gateway Protocol 版本升级可能导致兼容性问题
|
||||
3. **LLM API 不稳定** — 中国模型厂商的 API 变更频繁
|
||||
4. **单人/小团队维护压力** — 50+ 组件、42 个 lib、13 个 store 的维护成本极高
|
||||
|
||||
---
|
||||
|
||||
## 四、关键问题深度诊断
|
||||
|
||||
### 4.1 🔴 最大风险:前端承担了后端职责
|
||||
|
||||
目前 desktop/src/lib/ 下有大量本应属于后端的逻辑:
|
||||
|
||||
```
|
||||
agent-memory.ts → 应在 Gateway/Rust 端
|
||||
agent-identity.ts → 应在 Gateway/Rust 端
|
||||
reflection-engine.ts → 应在 Gateway/Rust 端
|
||||
heartbeat-engine.ts → 应在 Gateway/Rust 端
|
||||
context-compactor.ts → 应在 Gateway/Rust 端
|
||||
agent-swarm.ts → 应在 Gateway/Rust 端
|
||||
vector-memory.ts → 应在 Gateway/Rust 端
|
||||
```
|
||||
|
||||
**后果:**
|
||||
- 关闭浏览器/桌面端后,心跳、反思、主动学习全部停止
|
||||
- 数据持久化依赖 localStorage,不可靠
|
||||
- 无法多端共享 Agent 状态
|
||||
|
||||
### 4.2 🔴 Store 架构需要统一
|
||||
|
||||
当前存在两套 store 体系:
|
||||
- 旧 gatewayStore.ts (59KB) — 被 App.tsx 直接使用
|
||||
- 新 拆分的 connectionStore/agentStore/handStore/workflowStore/configStore
|
||||
|
||||
store/index.ts 试图用 useCompositeStore 桥接,但依赖列表长达 40+ 项,任何状态变化都会触发 re-render。
|
||||
|
||||
### 4.3 🟡 文档 vs 现实的差距
|
||||
|
||||
虽然 FRONTEND_INTEGRATION_AUDIT.md 声称"所有组件已集成",但:
|
||||
- HeartbeatConfig, CreateTriggerModal, PersonalitySelector 仍未集成
|
||||
- 身份演化、上下文压缩、心跳巡检的 UI 集成标记为 "❓ 未验证"
|
||||
- Phase 4 真实集成测试 0% 完成
|
||||
|
||||
---
|
||||
|
||||
## 五、头脑风暴:未来方向
|
||||
|
||||
### 💡 方向一:架构收敛 — "做减法"(推荐优先级 P0)
|
||||
|
||||
**核心思想:** 项目已经膨胀过快,在增加新功能前应先收敛。
|
||||
|
||||
| 行动 | 效果 | 工作量 |
|
||||
|------|------|--------|
|
||||
| 将智能层 lib 迁移到 Tauri Rust 端或 Gateway 插件 | 后端持久运行,多端共享 | 大 |
|
||||
| 彻底删除旧 gatewayStore.ts,统一用拆分后的 stores | 消除重复、降低 re-render | 中 |
|
||||
| 合并 viking-*.ts (5 文件 → 1-2 文件) | 降低复杂度 | 小 |
|
||||
| 拆分 gateway-client.ts (65KB → 模块化) | 可维护性提升 | 中 |
|
||||
| 统一配置格式 (TOML 或 JSON,不混用) | 用户体验统一 | 小 |
|
||||
|
||||
### 💡 方向二:端到端可用性 — "跑通闭环"(推荐优先级 P0)
|
||||
|
||||
**核心思想:** 317 个单元测试通过不代表产品可用,需要真实跑通。
|
||||
|
||||
| 行动 | 验证点 |
|
||||
|------|--------|
|
||||
| 安装 OpenFang,验证 Gateway 连接 | 子进程启动 → WS 握手 → 心跳 |
|
||||
| 配置中文模型 API Key,测试对话 | 流式响应 → 模型切换 → 上下文管理 |
|
||||
| 测试飞书 Channel 收发消息 | OAuth → 消息接收 → Agent 处理 → 回复 |
|
||||
| 测试 Hands 触发完整流程 | 意图识别 → 参数收集 → 审批 → 执行 → 结果 |
|
||||
| 验证记忆持久化 | 重启后记忆保留 → 跨会话记忆命中 |
|
||||
|
||||
### 💡 方向三:Tauri Rust 后端落地 — "真正的桌面应用"
|
||||
|
||||
**现状:** desktop/src-tauri/ 基本空白,大量能力应由 Rust 端承担。
|
||||
|
||||
**设想:**
|
||||
```rust
|
||||
// Tauri Commands 愿景
|
||||
#[tauri::command]
|
||||
async fn start_gateway(config: GatewayConfig) -> Result<GatewayStatus>
|
||||
#[tauri::command]
|
||||
async fn memory_search(query: String) -> Result<Vec<MemoryEntry>>
|
||||
#[tauri::command]
|
||||
async fn heartbeat_tick() -> Result<HeartbeatResult>
|
||||
#[tauri::command]
|
||||
async fn secure_store_get(key: String) -> Result<String>
|
||||
```
|
||||
|
||||
**好处:**
|
||||
- Gateway 生命周期由 Rust 管理,稳定性↑
|
||||
- 记忆/反思/心跳在 Rust 后台持续运行
|
||||
- 安全存储用系统 Keychain,不再依赖 localStorage
|
||||
- 离线能力:Rust 端可以在无网络时缓存操作
|
||||
|
||||
### 💡 方向四:差异化功能深化 — "不做小 ChatGPT"
|
||||
|
||||
ZCLAW 不应与 ChatGPT/Claude Desktop 竞争"对话体验",而应聚焦:
|
||||
|
||||
| 差异化方向 | 竞品不具备 | 实现路径 |
|
||||
|------------|------------|----------|
|
||||
| "AI 分身"日常代理 | AutoClaw 有但不开放 | Clone 系统 + 飞书/微信 Channel → 让 AI 分身帮你回消息、整理日程 |
|
||||
| "本地知识库" Agent | ChatGPT/Claude 是云端 | 向量记忆 + 本地文件索引 → 跨项目知识积累 |
|
||||
| "自主工作流"引擎 | Cursor 只做代码辅助 | Hands + Scheduler + Workflow → 定时任务自动执行(如每日新闻摘要、竞品监控) |
|
||||
| "团队蜂群"协作 | 市场上极少 | SwarmDashboard 已有基础 → 多 Agent 分工合作解决复杂问题 |
|
||||
| "中文场景" Skills | 国际产品不覆盖 | 小红书运营、知乎策略、微信公众号、飞书文档操作 → 已有 Skill 定义 |
|
||||
|
||||
### 💡 方向五:开发者体验 (DX) 优化
|
||||
|
||||
| 改进 | 现状 | 目标 |
|
||||
|------|------|------|
|
||||
| 启动脚本 | 需要 start-all.ps1 + 多步操作 | pnpm dev 一键启动全栈 |
|
||||
| 热重载 | Vite HMR 可用 | 加上 Gateway 插件热重载 |
|
||||
| 类型安全 | 部分 any | 全量 strict TypeScript |
|
||||
| E2E 测试 | 无 | Playwright + Tauri driver |
|
||||
| CI/CD | 无 | GitHub Actions 自动测试+构建 |
|
||||
|
||||
### 💡 方向六:商业化路径探索
|
||||
|
||||
基于现有能力的最短变现路径:
|
||||
|
||||
```
|
||||
阶段 1 (Q2): "个人 AI 助手" — 免费开源
|
||||
→ 建立 GitHub 社区 → 收集种子用户反馈
|
||||
→ 核心卖点: 本地优先 + 中文模型 + 飞书集成
|
||||
|
||||
阶段 2 (Q3): "Pro 版" — 订阅制 ¥49/月
|
||||
→ 云端记忆同步
|
||||
→ 高级 Skills (如量化交易分析、SEO 自动优化)
|
||||
→ 优先技术支持
|
||||
|
||||
阶段 3 (Q4): "团队版" — ¥199/人/月
|
||||
→ 多 Agent 协作编排
|
||||
→ 企业级审计日志
|
||||
→ 私有部署选项
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 六、行动建议总结
|
||||
|
||||
### 🔥 立即要做 (本周)
|
||||
|
||||
1. **跑通 Gateway 连接 + 真实模型对话** — 验证产品核心价值
|
||||
2. **清理 gatewayStore.ts** — 统一到拆分后的 stores,消除 59KB 巨型文件
|
||||
3. **拆分 gateway-client.ts** — 65KB 按职责模块化
|
||||
|
||||
### 📌 短期 (2 周)
|
||||
|
||||
1. **将心跳/记忆/反思引擎迁到 Tauri Rust 端** — 解决前端承担后端职责的根本问题
|
||||
2. **添加 E2E 测试** — Playwright 验证核心流程
|
||||
3. **清理 v1 归档代码** — 移除 src/core/ 的旧系统,减少混淆
|
||||
|
||||
### 🎯 中期 (1-2 月)
|
||||
|
||||
1. **落地"AI 分身日常代理"场景** — Clone + 飞书 = 用户最容易感知的价值
|
||||
2. **技能市场 MVP** — 68 个 Skill 已就绪,缺的是发现/安装/评价 UI
|
||||
3. **本地知识库 + 向量搜索** — Viking 集成代码已有,需要打通到 UI
|
||||
|
||||
---
|
||||
|
||||
## 核心判断
|
||||
|
||||
ZCLAW 的设计远大于实现。智能层的 lib 代码、68 个 Skills、7 个 Hands 的架构设计都非常出色,但最大的短板是**端到端可用性未经验证**。
|
||||
|
||||
**建议的策略是:先收敛、跑通闭环、再扩展。**
|
||||
Reference in New Issue
Block a user