feat: complete Phase 1-3 architecture optimization
Phase 1 - Security: - Add AES-GCM encryption for localStorage fallback - Enforce WSS protocol for non-localhost WebSocket connections - Add URL sanitization to prevent XSS in markdown links Phase 2 - Domain Reorganization: - Create Intelligence Domain with Valtio store and caching - Add unified intelligence-client for Rust backend integration - Migrate from legacy agent-memory, heartbeat, reflection modules Phase 3 - Core Optimization: - Add virtual scrolling for ChatArea with react-window - Implement LRU cache with TTL for intelligence operations - Add message virtualization utilities Additional: - Add OpenFang compatibility test suite - Update E2E test fixtures - Add audit logging infrastructure - Update project documentation and plans Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
387
docs/analysis/BRAINSTORMING-SESSION-v2.md
Normal file
387
docs/analysis/BRAINSTORMING-SESSION-v2.md
Normal file
@@ -0,0 +1,387 @@
|
||||
# ZCLAW 项目头脑风暴会议纪要 v2
|
||||
|
||||
> **会议日期:** 2026-03-21
|
||||
> **基于:** 系统性深度分析报告
|
||||
> **目标:** 针对分析结果进行深入探讨,提出建设性意见和可行性方案
|
||||
|
||||
---
|
||||
|
||||
## 参会专家角色
|
||||
|
||||
| 角色 | 职责 | 输入领域 |
|
||||
|------|------|----------|
|
||||
| 系统架构师 | 整体架构评估 | 代码结构、模块划分 |
|
||||
| 前端技术专家 | 前端架构优化 | React、性能优化 |
|
||||
| 后端技术专家 | 后端架构优化 | Rust、智能层 |
|
||||
| 安全专家 | 安全合规评估 | 数据保护、认证授权 |
|
||||
| 产品专家 | 功能规划 | 用户价值、优先级 |
|
||||
|
||||
---
|
||||
|
||||
## 议题一:架构优化方向
|
||||
|
||||
### 1.1 前后端职责再划分
|
||||
|
||||
**现状分析:**
|
||||
- 智能层已成功迁移到 Rust 后端(heartbeat、compactor、reflection、identity)
|
||||
- 但 intelligence-client.ts 仍包含 localStorage 降级逻辑
|
||||
- 部分业务逻辑仍在前端(agent-swarm、active-learning)
|
||||
|
||||
**方案讨论:**
|
||||
|
||||
| 方案 | 优点 | 缺点 | 推荐度 |
|
||||
|------|------|------|--------|
|
||||
| A. 全部迁移到 Rust | 统一、持久化、多端共享 | 工作量大 | ⭐⭐⭐ |
|
||||
| B. 保持现状,前端做桥接 | 渐进迁移 | 双实现维护成本 | ⭐⭐⭐⭐ |
|
||||
| C. 只迁移核心模块 | 平衡工作量和收益 | 边界不清 | ⭐⭐⭐ |
|
||||
|
||||
**结论:** 采用 **方案 B**,渐进式迁移
|
||||
- 核心模块(记忆、反思、心跳)已迁移 ✅
|
||||
- 非核心模块(agent-swarm、active-learning)可评估后决定
|
||||
|
||||
### 1.2 gateway-client.ts 拆分
|
||||
|
||||
**现状:** 65KB 单文件,包含 WebSocket、REST、认证、心跳、流式处理
|
||||
|
||||
**拆分方案:**
|
||||
```
|
||||
gateway/
|
||||
├── index.ts # 统一导出
|
||||
├── client.ts # 核心类(状态、事件)
|
||||
├── websocket.ts # WebSocket 连接管理
|
||||
├── rest.ts # REST API 封装
|
||||
├── auth.ts # 认证逻辑
|
||||
├── stream.ts # 流式响应处理
|
||||
└── types.ts # 类型定义
|
||||
```
|
||||
|
||||
**实施计划:**
|
||||
- **优先级:** P1
|
||||
- **工作量:** 2-3 人天
|
||||
- **风险:** 低(已有模块边界)
|
||||
|
||||
**结论:** ✅ 同意拆分
|
||||
|
||||
---
|
||||
|
||||
## 议题二:技术升级方向
|
||||
|
||||
### 2.1 React 19 新特性采用
|
||||
|
||||
**现状:** 使用 React 19,但未充分利用新特性
|
||||
|
||||
**可采用的新特性:**
|
||||
|
||||
| 特性 | 适用场景 | 收益 | 优先级 |
|
||||
|------|----------|------|--------|
|
||||
| use() Hook | Store 读取 | 简化代码 | 中 |
|
||||
| React Compiler | 全局 | 性能优化 | 高 |
|
||||
| Document Metadata | SEO/Head | 简化元数据管理 | 低 |
|
||||
| Third-party Hooks | 库集成 | 更好的兼容性 | 中 |
|
||||
|
||||
**结论:** 评估 React Compiler,优先在性能敏感组件试用
|
||||
|
||||
### 2.2 状态管理评估
|
||||
|
||||
**现状:** Zustand 5
|
||||
|
||||
**评估:**
|
||||
- Zustand 5 已支持更多中间件
|
||||
- 考虑迁移到 @preact/signals 或 Jotai?
|
||||
|
||||
**结论:** 保持 Zustand 5,聚焦功能开发
|
||||
|
||||
### 2.3 测试框架增强
|
||||
|
||||
**现状:** Vitest + Playwright,但 E2E 不稳定 (~80% 通过率)
|
||||
|
||||
**改进方案:**
|
||||
|
||||
| 改进项 | 方案 | 优先级 |
|
||||
|--------|------|--------|
|
||||
| E2E 稳定性 | 增加等待逻辑、使用 `waitForFunction` | P0 |
|
||||
| 单元测试覆盖率 | 增加边界测试、错误场景测试 | P1 |
|
||||
| Mock 策略 | 使用 MSW (Mock Service Worker) | P2 |
|
||||
| 视觉回归测试 | 集成 Playwright 截图对比 | P3 |
|
||||
|
||||
**结论:** 优先解决 E2E 稳定性问题 (P0)
|
||||
|
||||
---
|
||||
|
||||
## 议题三:性能提升方向
|
||||
|
||||
### 3.1 渲染性能优化
|
||||
|
||||
**问题:** 大量消息时可能 re-render
|
||||
|
||||
**方案:**
|
||||
|
||||
| 方案 | 实施难度 | 收益 | 推荐度 |
|
||||
|------|----------|------|--------|
|
||||
| A. Zustand shallow 比较 | 低 | 中 | ⭐⭐⭐⭐ |
|
||||
| B. React.memo 优化组件 | 中 | 高 | ⭐⭐⭐⭐⭐ |
|
||||
| C. 虚拟列表优化 | 中 | 高 | ⭐⭐⭐⭐ |
|
||||
| D. 减少 Context 使用 | 低 | 中 | ⭐⭐⭐ |
|
||||
|
||||
**结论:** 组合实施 A + B + D,重点优化 ChatArea 和 MessageList
|
||||
|
||||
### 3.2 网络性能优化
|
||||
|
||||
**问题:** 单 WebSocket 连接
|
||||
|
||||
**方案:**
|
||||
|
||||
| 方案 | 优点 | 缺点 | 推荐度 |
|
||||
|------|------|------|--------|
|
||||
| A. WebSocket 连接池 | 并发请求 | 实现复杂度高 | ⭐⭐ |
|
||||
| B. HTTP/2 多路复用 | 标准方案 | 需要后端支持 | ⭐⭐⭐ |
|
||||
| C. 请求合并 | 减少请求数 | 增加延迟 | ⭐⭐⭐ |
|
||||
| D. 保持现状 | 简单 | - | ⭐⭐⭐⭐⭐ |
|
||||
|
||||
**结论:** 保持现状,当前连接数不是瓶颈
|
||||
|
||||
### 3.3 大文件/长文本处理
|
||||
|
||||
**现状:** Token 估算和压缩已迁移到 Rust 后端
|
||||
|
||||
**可优化点:**
|
||||
- 流式 token 计数
|
||||
- 增量压缩
|
||||
- 智能摘要生成
|
||||
|
||||
**结论:** 当前实现已满足需求,持续观察
|
||||
|
||||
---
|
||||
|
||||
## 议题四:功能扩展方向
|
||||
|
||||
### 4.1 移动端支持
|
||||
|
||||
**评估:**
|
||||
|
||||
| 方案 | 技术选型 | 工作量 | 推荐度 |
|
||||
|------|----------|--------|--------|
|
||||
| A. React Native | 跨平台 | 大 | ⭐⭐ |
|
||||
| B. Tauri Mobile | Tauri 生态 | 中 | ⭐⭐⭐⭐ |
|
||||
| C. Flutter | 独立生态 | 大 | ⭐⭐ |
|
||||
| D. 暂不开发 | - | - | ⭐⭐⭐⭐⭐ |
|
||||
|
||||
**结论:** 评估 Tauri Mobile,但优先级低于核心功能
|
||||
|
||||
### 4.2 国际化 (i18n)
|
||||
|
||||
**现状:** 中文优先,但硬编码字符串存在
|
||||
|
||||
**方案:**
|
||||
```typescript
|
||||
// 使用 react-i18next
|
||||
i18n.t('chat.placeholder')
|
||||
i18n.t('hand.trigger', { name })
|
||||
```
|
||||
|
||||
**工作量:** 约 1-2 周
|
||||
|
||||
**结论:** 建议在下一版本规划中纳入
|
||||
|
||||
### 4.3 更多 Channel 集成
|
||||
|
||||
**当前:** 飞书 (Feishu)
|
||||
|
||||
**可扩展:**
|
||||
|
||||
| Channel | 需求度 | 技术难度 | 优先级 |
|
||||
|---------|--------|----------|--------|
|
||||
| 企业微信 | 高 | 高 | 中 |
|
||||
| 钉钉 | 中 | 高 | 低 |
|
||||
| Discord | 中 | 中 | 中 |
|
||||
| Telegram | 低 | 低 | 中 |
|
||||
|
||||
**结论:** 优先完善飞书集成,评估 Discord
|
||||
|
||||
### 4.4 插件市场
|
||||
|
||||
**现状:** 3 个插件 (chinese-models, feishu, ui)
|
||||
|
||||
**方案:**
|
||||
|
||||
| 阶段 | 内容 | 工作量 |
|
||||
|------|------|--------|
|
||||
| Phase 1 | 插件市场 UI + 基础 API | 1 周 |
|
||||
| Phase 2 | 插件审核机制 | 1 周 |
|
||||
| Phase 3 | 付费插件支持 | 2 周 |
|
||||
|
||||
**结论:** 作为差异化竞争力,纳入中期规划
|
||||
|
||||
---
|
||||
|
||||
## 议题五:风险规避方向
|
||||
|
||||
### 5.1 OpenFang 兼容性维护
|
||||
|
||||
**风险:** OpenFang 版本升级可能导致兼容性问题
|
||||
|
||||
**方案:**
|
||||
|
||||
| 方案 | 实施难度 | 保护程度 |
|
||||
|------|----------|----------|
|
||||
| A. 版本锁定 | 低 | 弱 |
|
||||
| B. 兼容层抽象 | 中 | 中 |
|
||||
| C. 自动化兼容性测试 | 高 | 强 |
|
||||
| D. 参与 OpenFang 开发 | 高 | 最强 |
|
||||
|
||||
**结论:** 实施 B + C,建立兼容性测试套件
|
||||
|
||||
### 5.2 敏感数据保护
|
||||
|
||||
**现状:** API Key 使用 OS Keyring,但聊天记录未加密
|
||||
|
||||
**改进方案:**
|
||||
|
||||
| 敏感数据 | 当前存储 | 建议存储 | 优先级 |
|
||||
|----------|----------|----------|--------|
|
||||
| API Key | OS Keyring ✅ | 保持 | - |
|
||||
| Gateway Token | OS Keyring ✅ | 保持 | - |
|
||||
| 聊天记录 | SQLite | 加密存储 | P1 |
|
||||
| Theme | localStorage | 保持 | 低 |
|
||||
|
||||
**结论:** 聊天记录加密纳入安全增强计划
|
||||
|
||||
### 5.3 灰度发布机制
|
||||
|
||||
**现状:** 无灰度发布
|
||||
|
||||
**方案:**
|
||||
|
||||
| 方案 | 工具 | 工作量 |
|
||||
|------|------|--------|
|
||||
| A. Tauri 内置更新 | tauri-plugin-updater | 1 天 |
|
||||
| B. 手动版本管理 | - | 0 |
|
||||
| C. 自动化灰度 | 定制开发 | 1 周 |
|
||||
|
||||
**结论:** 集成 Tauri 内置更新机制
|
||||
|
||||
---
|
||||
|
||||
## 议题六:创新解决方案
|
||||
|
||||
### 6.1 AI Native 特性增强
|
||||
|
||||
**想法:**
|
||||
|
||||
| 特性 | 描述 | 创新度 |
|
||||
|------|------|--------|
|
||||
| 自适应上下文 | 根据任务类型自动调整上下文长度 | ⭐⭐⭐ |
|
||||
| 智能缓存 | 预测用户意图,预加载资源 | ⭐⭐⭐ |
|
||||
| 多模态交互 | 支持图片、语音输入 | ⭐⭐ |
|
||||
| 主动建议 | 基于上下文主动提供建议 | ⭐⭐⭐⭐ |
|
||||
|
||||
**结论:** 优先实现"主动建议"作为差异化功能
|
||||
|
||||
### 6.2 本地知识图谱构建
|
||||
|
||||
**想法:**
|
||||
- 将记忆系统升级为知识图谱
|
||||
- 实体关系挖掘
|
||||
- 语义推理能力
|
||||
|
||||
**技术路径:**
|
||||
```rust
|
||||
// 实体提取
|
||||
struct Entity {
|
||||
name: String,
|
||||
type: EntityType,
|
||||
properties: HashMap<String, Value>,
|
||||
}
|
||||
|
||||
// 关系链接
|
||||
struct Relation {
|
||||
from: EntityId,
|
||||
to: EntityId,
|
||||
relation_type: String,
|
||||
confidence: f32,
|
||||
}
|
||||
```
|
||||
|
||||
**结论:** 长期规划,与 OpenViking 深度集成
|
||||
|
||||
### 6.3 跨设备状态同步
|
||||
|
||||
**问题:** 当前数据仅本地存储
|
||||
|
||||
**方案:**
|
||||
|
||||
| 方案 | 复杂度 | 隐私性 | 推荐度 |
|
||||
|------|--------|--------|--------|
|
||||
| A. 云端同步 | 高 | 低 | ⭐⭐ |
|
||||
| B. 端到端加密同步 | 高 | 高 | ⭐⭐⭐⭐ |
|
||||
| C. 文件导入/导出 | 低 | 最高 | ⭐⭐⭐⭐ |
|
||||
| D. 保持本地优先 | - | - | ⭐⭐⭐⭐⭐ |
|
||||
|
||||
**结论:** 提供端到端加密同步作为 Pro 功能
|
||||
|
||||
### 6.4 隐私计算集成
|
||||
|
||||
**想法:**
|
||||
- 本地模型推理(Llama.cpp 集成)
|
||||
- 联邦学习支持
|
||||
- 数据不出本机
|
||||
|
||||
**结论:** 长期愿景,需要大量研发投入
|
||||
|
||||
---
|
||||
|
||||
## 行动建议总结
|
||||
|
||||
### 短期行动(1-2 周)
|
||||
|
||||
| # | 行动 | 优先级 | 负责人 | 工作量 |
|
||||
|---|------|--------|--------|--------|
|
||||
| 1 | E2E 测试稳定性修复 | P0 | 测试团队 | 2-3 人天 |
|
||||
| 2 | gateway-client.ts 拆分 | P1 | 前端团队 | 2-3 人天 |
|
||||
| 3 | Rust unwrap() 替换 | P1 | 后端团队 | 0.5 人天 |
|
||||
|
||||
### 中期行动(1-2 月)
|
||||
|
||||
| # | 行动 | 优先级 | 工作量 |
|
||||
|---|------|--------|--------|
|
||||
| 4 | 聊天记录加密 | P1 | 1 周 |
|
||||
| 5 | 插件市场 MVP | P2 | 1 周 |
|
||||
| 6 | i18n 支持 | P2 | 1-2 周 |
|
||||
| 7 | 兼容性测试套件 | P1 | 1 周 |
|
||||
| 8 | 性能优化 (re-render) | P2 | 2-3 人天 |
|
||||
|
||||
### 长期愿景(6 月+)
|
||||
|
||||
| # | 行动 | 优先级 |
|
||||
|---|------|--------|
|
||||
| 9 | 本地知识图谱 | P3 |
|
||||
| 10 | 端到端加密同步 | P3 |
|
||||
| 11 | Tauri Mobile 支持 | P3 |
|
||||
| 12 | 主动建议能力 | P2 |
|
||||
|
||||
---
|
||||
|
||||
## 会议结论
|
||||
|
||||
1. **架构优化优先** - gateway-client.ts 拆分是短期最高优先级
|
||||
2. **稳定性优先** - E2E 测试修复和兼容性测试是 P0
|
||||
3. **保持专注** - 不追求功能数量,聚焦核心体验
|
||||
4. **隐私优先** - 本地优先策略,用户数据不强制上云
|
||||
5. **渐进改进** - 避免大规模重构,采用渐进式优化
|
||||
|
||||
---
|
||||
|
||||
## 关键决策记录
|
||||
|
||||
| 决策项 | 决策结果 | 理由 |
|
||||
|--------|----------|------|
|
||||
| 前后端职责划分 | 渐进迁移 | 平衡工作量和收益 |
|
||||
| 状态管理 | 保持 Zustand 5 | 聚焦功能开发 |
|
||||
| 移动端 | 暂不开发 | 优先级低于核心功能 |
|
||||
| 国际化 | 下一版本纳入 | 1-2 周工作量 |
|
||||
| 聊天记录 | 加密存储 | 保护用户隐私 |
|
||||
| 跨设备同步 | Pro 功能 | 端到端加密 |
|
||||
|
||||
---
|
||||
|
||||
*会议纪要完成*
|
||||
643
docs/analysis/PROJECT-SYSTEMATIC-ANALYSIS-REPORT.md
Normal file
643
docs/analysis/PROJECT-SYSTEMATIC-ANALYSIS-REPORT.md
Normal file
@@ -0,0 +1,643 @@
|
||||
# ZCLAW 项目系统性深度分析报告
|
||||
|
||||
> **报告日期:** 2026-03-21
|
||||
> **分析范围:** 代码结构、架构设计、技术栈、业务逻辑、数据流、性能安全
|
||||
> **报告版本:** v1.0
|
||||
|
||||
---
|
||||
|
||||
## 执行摘要
|
||||
|
||||
### 项目概览
|
||||
|
||||
ZCLAW 是一个基于 **OpenFang** 的中文优先 AI Agent 桌面客户端,采用 **Tauri 2.0 (Rust + React 19)** 架构,目标对标智谱 AutoClaw 和腾讯 QClaw。
|
||||
|
||||
### 核心数据
|
||||
|
||||
| 维度 | 数量 | 评价 |
|
||||
|------|------|------|
|
||||
| 前端组件 | 88 个 .tsx 文件 | ✅ 职责划分清晰 |
|
||||
| Store 文件 | 15 个 (13 活跃 + 2 门面) | ✅ 架构已统一 |
|
||||
| Lib 工具 | 36 个工具文件 | ⚠️ 部分需拆分 |
|
||||
| 类型定义 | 13 个类型文件 | ✅ 类型安全 |
|
||||
| Skills | 68 个 SKILL.md | ✅ 生态丰富 |
|
||||
| Hands | 7 个 HAND.toml | ✅ 自主能力完整 |
|
||||
| Rust 模块 | 8 个主要模块 | ✅ 后端充实 |
|
||||
| Tauri Commands | 70+ | ✅ 接口完整 |
|
||||
| 测试文件 | 15+ | ✅ 覆盖良好 |
|
||||
| 文档文件 | 84+ | ✅ 文档详尽 |
|
||||
|
||||
### 综合评分
|
||||
|
||||
| 维度 | 评分 | 说明 |
|
||||
|------|------|------|
|
||||
| 代码结构 | 4/5 | 组件划分清晰,文件组织合理 |
|
||||
| 架构设计 | 4/5 | 分层清晰,模块职责明确 |
|
||||
| 技术选型 | 4/5 | 框架选择合理,依赖精简 |
|
||||
| 业务实现 | 4/5 | 核心流程完整,异常处理充分 |
|
||||
| 数据流设计 | 4/5 | 流向清晰,同步机制完善 |
|
||||
| 接口设计 | 4/5 | Tauri Commands 粒度合理 |
|
||||
| 性能表现 | 3/5 | 存在优化空间 |
|
||||
| 安全合规 | 4/5 | 认证机制完善 |
|
||||
| 测试覆盖 | 3/5 | 核心逻辑有覆盖 |
|
||||
| 文档质量 | 4/5 | 文档详尽 |
|
||||
| **综合** | **3.8/5** | **良好,有改进空间** |
|
||||
|
||||
---
|
||||
|
||||
## 一、代码结构分析
|
||||
|
||||
### 1.1 项目整体结构
|
||||
|
||||
```
|
||||
ZCLAW/
|
||||
├── desktop/ # Tauri 桌面应用 (React + Rust)
|
||||
│ ├── src/
|
||||
│ │ ├── components/ # 88 个 React 组件
|
||||
│ │ ├── store/ # 15 个 Zustand stores
|
||||
│ │ ├── lib/ # 36 个工具文件
|
||||
│ │ ├── types/ # 13 个类型定义
|
||||
│ │ ├── hooks/ # 自定义 hooks
|
||||
│ │ └── assets/ # 静态资源
|
||||
│ └── src-tauri/ # Rust 后端
|
||||
│ └── src/
|
||||
│ ├── browser/ # 浏览器自动化
|
||||
│ ├── intelligence/ # 智能层 (心跳/反思/压缩)
|
||||
│ ├── memory/ # 记忆系统
|
||||
│ ├── llm/ # LLM 接口
|
||||
│ └── *.rs # Commands 实现
|
||||
├── skills/ # 68 个 SKILL.md
|
||||
├── hands/ # 7 个 HAND.toml
|
||||
├── config/ # TOML 配置文件
|
||||
├── docs/ # 84+ 文档文件
|
||||
├── src/gateway/ # Node.js Gateway 层
|
||||
└── tests/ # 测试文件
|
||||
```
|
||||
|
||||
### 1.2 前端组件层分析
|
||||
|
||||
**组件分类统计:**
|
||||
|
||||
| 类别 | 组件数 | 代表组件 |
|
||||
|------|--------|----------|
|
||||
| 聊天/对话 | 8 | ChatArea, ConversationList, MessageSearch |
|
||||
| Agent/Clone | 6 | CloneManager, AgentOnboardingWizard |
|
||||
| 自动化 Hands | 10 | HandsPanel, HandList, HandApprovalModal |
|
||||
| 工作流 | 4 | WorkflowList, WorkflowEditor |
|
||||
| 团队协作 | 5 | TeamList, TeamCollaborationView |
|
||||
| 记忆/智能 | 6 | MemoryPanel, MemoryGraph, ReflectionLog |
|
||||
| 安全/审计 | 5 | SecurityLayersPanel, SecurityStatus |
|
||||
| 浏览器自动化 | 8 | BrowserHandCard, ScreenshotPreview |
|
||||
| 设置 | 12 | SettingsLayout, General, ModelsAPI... |
|
||||
| UI 基础组件 | 15 | Button, Card, Input, Badge... |
|
||||
|
||||
**评价:** ✅ 组件职责划分清晰,分类合理
|
||||
|
||||
### 1.3 Store 层分析
|
||||
|
||||
**13 个活跃 Zustand Stores:**
|
||||
|
||||
| Store | 职责 | 状态 |
|
||||
|-------|------|------|
|
||||
| chatStore | 聊天消息、会话管理 | ✅ 活跃 |
|
||||
| connectionStore | Gateway 连接状态 | ✅ 活跃 |
|
||||
| agentStore | Clone/Agent 管理 | ✅ 活跃 |
|
||||
| handStore | Hands/Triggers/Approvals | ✅ 活跃 |
|
||||
| workflowStore | 工作流管理 | ✅ 活跃 |
|
||||
| configStore | 配置/渠道/技能/模型 | ✅ 活跃 |
|
||||
| securityStore | 安全状态/审计日志 | ✅ 活跃 |
|
||||
| sessionStore | 会话管理 | ✅ 活跃 |
|
||||
| teamStore | 团队协作 | ✅ 活跃 |
|
||||
| skillMarketStore | 技能市场 | ✅ 活跃 |
|
||||
| memoryGraphStore | 记忆图谱 | ✅ 活跃 |
|
||||
| activeLearningStore | 主动学习 | ✅ 活跃 |
|
||||
| browserHandStore | 浏览器自动化 | ✅ 活跃 |
|
||||
|
||||
**gatewayStore.ts 门面模式:**
|
||||
- 从 1800+ 行缩减到 352 行
|
||||
- 作为向后兼容的 facade 层
|
||||
- 标记为 `@deprecated`
|
||||
|
||||
**评价:** ✅ Store 架构已统一,拆分合理
|
||||
|
||||
### 1.4 Rust 后端结构
|
||||
|
||||
```
|
||||
desktop/src-tauri/src/
|
||||
├── lib.rs # 入口,OpenFang 集成
|
||||
├── main.rs # 主程序
|
||||
├── viking_commands.rs # OpenViking CLI sidecar
|
||||
├── viking_server.rs # OpenViking 本地服务器
|
||||
├── secure_storage.rs # OS Keyring/Keychain
|
||||
├── memory_commands.rs # 持久化内存命令
|
||||
├── memory/ # 内存提取和上下文构建
|
||||
│ ├── extractor.rs # LLM 驱动的记忆提取
|
||||
│ ├── context_builder.rs # L0/L1/L2 分层上下文
|
||||
│ └── persistent.rs # SQLite 持久化
|
||||
├── llm/ # LLM 接口
|
||||
├── browser/ # 浏览器自动化 (Fantoccini)
|
||||
│ ├── actions.rs
|
||||
│ ├── client.rs
|
||||
│ ├── commands.rs
|
||||
│ ├── error.rs
|
||||
│ ├── mod.rs
|
||||
│ └── session.rs
|
||||
└── intelligence/ # 智能层 (已从前端迁移)
|
||||
├── heartbeat.rs # 心跳引擎
|
||||
├── compactor.rs # 上下文压缩
|
||||
├── reflection.rs # 反思引擎
|
||||
├── identity.rs # Agent 身份管理
|
||||
└── mod.rs
|
||||
```
|
||||
|
||||
**评价:** ✅ 模块组织清晰,职责分明
|
||||
|
||||
### 1.5 代码规模与大型文件
|
||||
|
||||
**大型文件识别:**
|
||||
|
||||
| 文件 | 规模 | 问题 | 建议 |
|
||||
|------|------|------|------|
|
||||
| gateway-client.ts | ~65KB | 职责过重 | 拆分为多模块 |
|
||||
| gatewayStore.ts | 352行 | 已是 facade | 逐步迁移引用 |
|
||||
| intelligence-client.ts | ~15KB | 功能集中 | 保持现状 |
|
||||
| autonomy-manager.ts | ~15KB | 授权逻辑 | 保持现状 |
|
||||
|
||||
**评价:** ⚠️ gateway-client.ts 需要拆分
|
||||
|
||||
---
|
||||
|
||||
## 二、架构设计分析
|
||||
|
||||
### 2.1 整体架构
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ React UI Layer │
|
||||
│ ChatArea, Sidebar, HandsPanel, WorkflowEditor... │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Zustand State Layer │
|
||||
│ chatStore, connectionStore, agentStore, handStore... │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Client Layer │
|
||||
│ GatewayClient │ IntelligenceClient │ TeamClient │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Tauri IPC / WebSocket │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Rust Backend │
|
||||
│ browser │ intelligence │ memory │ llm │ secure_storage │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
↕
|
||||
OpenFang Kernel / OpenViking
|
||||
```
|
||||
|
||||
### 2.2 数据流架构
|
||||
|
||||
**用户操作流程:**
|
||||
```
|
||||
用户操作 → React UI → Zustand Store → GatewayClient
|
||||
↓
|
||||
WebSocket / REST
|
||||
↓
|
||||
OpenFang Kernel
|
||||
↓
|
||||
Skills / Hands 执行
|
||||
```
|
||||
|
||||
**状态更新流程:**
|
||||
```
|
||||
Backend Event → GatewayClient → Store Update → React Re-render
|
||||
```
|
||||
|
||||
**评价:** ✅ 数据流清晰,分层合理
|
||||
|
||||
### 2.3 通信层设计
|
||||
|
||||
**Gateway Protocol v3:**
|
||||
- 消息类型:req/res/event/stream
|
||||
- 认证:Ed25519 设备签名
|
||||
- 心跳:30秒间隔,3次超时断开
|
||||
- 自动重连:指数退避策略
|
||||
|
||||
**Tauri Commands (70+):**
|
||||
|
||||
| 类别 | 命令数 | 示例 |
|
||||
|------|--------|------|
|
||||
| Browser | 18 | browser_navigate, browser_click |
|
||||
| Memory | 12 | memory_store, memory_search |
|
||||
| Intelligence | 15 | heartbeat_*, reflection_* |
|
||||
| Viking | 9 | viking_status, viking_find |
|
||||
| Gateway | 8 | gateway_start, gateway_stop |
|
||||
| LLM | 3 | llm_complete |
|
||||
|
||||
**评价:** ✅ 通信层设计完整
|
||||
|
||||
### 2.4 分层架构评估
|
||||
|
||||
| 层级 | 技术 | 职责 | 评价 |
|
||||
|------|------|------|------|
|
||||
| 表现层 | React 19 | UI 渲染、用户交互 | ✅ 合理 |
|
||||
| 状态层 | Zustand | 状态管理、流程编排 | ✅ 合理 |
|
||||
| 通信层 | GatewayClient | 网络通信、协议处理 | ✅ 合理 |
|
||||
| 服务层 | Rust | 业务逻辑、智能层 | ✅ 合理 |
|
||||
| 数据层 | SQLite | 本地持久化 | ✅ 合理 |
|
||||
|
||||
---
|
||||
|
||||
## 三、技术栈分析
|
||||
|
||||
### 3.1 前端技术栈
|
||||
|
||||
| 技术 | 版本 | 选型理由 | 评估 |
|
||||
|------|------|----------|------|
|
||||
| React | 19.1.0 | 最新特性,Concurrent 模式 | ✅ 合理 |
|
||||
| Zustand | 5.0.11 | 轻量、类型安全 | ✅ 合理 |
|
||||
| TailwindCSS | 4.2.1 | 原子化样式 | ✅ 合理 |
|
||||
| Framer Motion | 12.36.0 | 声明式动画 | ✅ 合理 |
|
||||
| Lucide React | 0.577.0 | 图标库 | ✅ 合理 |
|
||||
| Tauri | 2.0 | 体积小 (~10MB) | ✅ 合理 |
|
||||
|
||||
### 3.2 后端技术栈
|
||||
|
||||
| 技术 | 用途 | 评估 |
|
||||
|------|------|------|
|
||||
| Rust + Tokio | 异步运行时 | ✅ 高性能 |
|
||||
| SQLite + SQLx | 本地持久化 | ✅ 轻量 |
|
||||
| Fantoccini | 浏览器自动化 | ✅ 成熟 |
|
||||
| Keyring | 安全存储 | ✅ 安全 |
|
||||
| Ed25519 | 设备认证 | ✅ 安全 |
|
||||
|
||||
### 3.3 依赖管理
|
||||
|
||||
**前端依赖 (package.json):**
|
||||
```json
|
||||
{
|
||||
"@tauri-apps/api": "^2",
|
||||
"react": "^19.1.0",
|
||||
"zustand": "^5.0.11",
|
||||
"framer-motion": "^12.36.0",
|
||||
"lucide-react": "^0.577.0"
|
||||
}
|
||||
```
|
||||
|
||||
**后端依赖 (Cargo.toml):**
|
||||
```toml
|
||||
[dependencies]
|
||||
tauri = { version = "2", features = [] }
|
||||
tokio = { version = "1", features = ["full"] }
|
||||
sqlx = { version = "0.7", features = ["runtime-tokio", "sqlite"] }
|
||||
fantoccini = "0.21"
|
||||
keyring = "3"
|
||||
```
|
||||
|
||||
**评价:** ✅ 依赖精简,版本稳定
|
||||
|
||||
---
|
||||
|
||||
## 四、业务逻辑实现分析
|
||||
|
||||
### 4.1 聊天功能
|
||||
|
||||
**消息流程:**
|
||||
```
|
||||
用户输入 → sendMessage()
|
||||
→ 上下文压缩检查 (compactor.checkThreshold)
|
||||
→ 记忆增强 (intelligenceClient.memory.search)
|
||||
→ 添加用户消息
|
||||
→ 创建流式占位消息
|
||||
→ gatewayClient.chatStream()
|
||||
→ 收集 tool/hand/workflow 事件
|
||||
→ 流结束 → 提取记忆 (memory-extractor)
|
||||
→ 触发反思 (intelligenceClient.reflection)
|
||||
```
|
||||
|
||||
**评价:** ✅ 流程完整,异常处理充分
|
||||
|
||||
### 4.2 记忆系统
|
||||
|
||||
**记忆提取模式:**
|
||||
1. **LLM 提取** - 使用 `llmExtract()` 语义提取
|
||||
2. **规则提取** - 正则匹配模式
|
||||
|
||||
**记忆分类:**
|
||||
- fact: 用户事实
|
||||
- preference: 用户偏好
|
||||
- lesson: 经验教训
|
||||
- context: 上下文
|
||||
- task: 任务
|
||||
|
||||
**分层上下文加载(L0/L1/L2):**
|
||||
```
|
||||
L0 (Quick Scan): 向量相似度搜索,返回概览
|
||||
L1 (Standard): 加载 top 候选的 overview
|
||||
L2 (Deep): 加载最相关项的完整内容
|
||||
```
|
||||
|
||||
**评价:** ✅ 设计完善,已迁移到 Rust 后端
|
||||
|
||||
### 4.3 自主能力系统 (Hands)
|
||||
|
||||
**L4 分层授权:**
|
||||
|
||||
| 级别 | 自动内存保存 | 自动压缩 | 自动反思 |
|
||||
|------|-------------|---------|---------|
|
||||
| supervised | ❌ | ❌ | ❌ |
|
||||
| assisted | ✅ | ✅ | ✅ |
|
||||
| autonomous | ✅ | ✅ | ✅ |
|
||||
|
||||
**风险评估:**
|
||||
- ACTION_RISK_MAP 定义每种操作的风险等级
|
||||
- importanceMax + riskMax 双重判断
|
||||
- 所有操作记录审计日志
|
||||
|
||||
**7 个内置 Hands:**
|
||||
|
||||
| Hand | 功能 | 状态 |
|
||||
|------|------|------|
|
||||
| Browser | 网页自动化 | ✅ 可用 |
|
||||
| Researcher | 深度研究 | ✅ 可用 |
|
||||
| Collector | 情报监控 | ✅ 可用 |
|
||||
| Predictor | 趋势预测 | ✅ 可用 |
|
||||
| Lead | 线索挖掘 | ✅ 可用 |
|
||||
| Clip | 视频处理 | ⚠️ 需 FFmpeg |
|
||||
| Twitter | 社媒管理 | ⚠️ 需 API Key |
|
||||
|
||||
**评价:** ✅ 授权机制完善,Hands 系统完整
|
||||
|
||||
### 4.4 智能层实现
|
||||
|
||||
| 模块 | 文件 | 测试 | 集成 |
|
||||
|------|------|------|------|
|
||||
| Agent 记忆 | Rust backend | ✅ | ✅ MemoryPanel |
|
||||
| 身份演化 | Rust backend | ✅ | ✅ Settings |
|
||||
| 上下文压缩 | Rust backend | ✅ | ✅ chatStore |
|
||||
| 自我反思 | Rust backend | ✅ | ✅ ReflectionLog |
|
||||
| 心跳引擎 | Rust backend | ✅ | ✅ HeartbeatConfig |
|
||||
| 主动学习 | TypeScript | ✅ | ✅ ActiveLearningPanel |
|
||||
| Agent 蜂群 | TypeScript | ✅ | ✅ SwarmDashboard |
|
||||
|
||||
**评价:** ✅ 智能层设计深刻,大部分已迁移到 Rust
|
||||
|
||||
### 4.5 功能完成度评估
|
||||
|
||||
| 功能 | 状态 | 完成度 |
|
||||
|------|------|--------|
|
||||
| 聊天界面 | ✅ 完成 | 95% |
|
||||
| 分身管理 | ✅ 完成 | 90% |
|
||||
| 自动化面板 | ✅ 完成 | 85% |
|
||||
| 技能市场 | 🚧 进行中 | 70% |
|
||||
| 工作流编辑 | 📋 计划中 | 50% |
|
||||
| 团队协作 | ✅ 完成 | 80% |
|
||||
| 记忆系统 | ✅ 完成 | 90% |
|
||||
| 安全审计 | ✅ 完成 | 85% |
|
||||
|
||||
---
|
||||
|
||||
## 五、数据流向分析
|
||||
|
||||
### 5.1 状态管理
|
||||
|
||||
**Store 间关系:**
|
||||
```
|
||||
chatStore (核心)
|
||||
↓ 使用
|
||||
connectionStore (连接)
|
||||
↓ 使用
|
||||
gateway-client.ts (通信)
|
||||
|
||||
agentStore, handStore, workflowStore (并行)
|
||||
↓ 各自使用
|
||||
configStore (配置)
|
||||
```
|
||||
|
||||
**持久化策略:**
|
||||
- **SQLite**: 聊天记录、记忆、审计日志
|
||||
- **OS Keyring**: API Key、Token
|
||||
- **localStorage**: 主题、部分配置 (⚠️ 需评估)
|
||||
|
||||
### 5.2 数据持久化
|
||||
|
||||
**SQLite 数据库设计:**
|
||||
```sql
|
||||
CREATE TABLE memories (
|
||||
id TEXT PRIMARY KEY,
|
||||
agent_id TEXT NOT NULL,
|
||||
memory_type TEXT NOT NULL,
|
||||
content TEXT NOT NULL,
|
||||
importance INTEGER DEFAULT 5,
|
||||
source TEXT DEFAULT 'auto',
|
||||
tags TEXT DEFAULT '[]',
|
||||
conversation_id TEXT,
|
||||
created_at TEXT NOT NULL,
|
||||
last_accessed_at TEXT NOT NULL,
|
||||
access_count INTEGER DEFAULT 0,
|
||||
embedding BLOB
|
||||
);
|
||||
```
|
||||
|
||||
**评价:** ✅ 结构清晰,有索引优化
|
||||
|
||||
---
|
||||
|
||||
## 六、接口设计分析
|
||||
|
||||
### 6.1 Tauri Commands 设计
|
||||
|
||||
**命令组织:**
|
||||
- 按功能模块分组
|
||||
- 统一返回 `Result<T, String>`
|
||||
- 使用 Tauri State 管理共享状态
|
||||
|
||||
**示例:**
|
||||
```rust
|
||||
#[tauri::command]
|
||||
async fn memory_search(
|
||||
state: State<'_, MemoryState>,
|
||||
query: String,
|
||||
limit: Option<usize>,
|
||||
) -> Result<Vec<MemoryEntry>, String>
|
||||
```
|
||||
|
||||
### 6.2 Gateway Protocol v3
|
||||
|
||||
**消息格式:**
|
||||
```typescript
|
||||
interface GatewayFrame {
|
||||
id?: string;
|
||||
type: 'req' | 'res' | 'event' | 'stream';
|
||||
method?: string;
|
||||
payload?: unknown;
|
||||
error?: GatewayError;
|
||||
}
|
||||
```
|
||||
|
||||
**评价:** ✅ 接口粒度合理,类型安全
|
||||
|
||||
---
|
||||
|
||||
## 七、性能分析
|
||||
|
||||
### 7.1 渲染性能
|
||||
|
||||
**优化措施:**
|
||||
- ✅ 虚拟滚动 (react-window)
|
||||
- ⚠️ Store selector 可优化 (shallow 比较)
|
||||
- ⚠️ 大型组件可拆分
|
||||
|
||||
### 7.2 网络性能
|
||||
|
||||
**WebSocket 配置:**
|
||||
- 心跳间隔:30 秒
|
||||
- 超时:10 秒
|
||||
- 最大丢失:3 次
|
||||
- 自动重连:指数退避
|
||||
|
||||
**评价:** ✅ 配置合理
|
||||
|
||||
### 7.3 计算性能
|
||||
|
||||
**Token 估算:**
|
||||
```rust
|
||||
// CJK: ~1.5 tokens/字符
|
||||
// ASCII: ~0.3 tokens/字符
|
||||
```
|
||||
|
||||
**评价:** ✅ 算法合理
|
||||
|
||||
---
|
||||
|
||||
## 八、安全分析
|
||||
|
||||
### 8.1 认证授权
|
||||
|
||||
- ✅ Ed25519 设备认证
|
||||
- ✅ L4 分层授权
|
||||
- ✅ 操作审计日志
|
||||
|
||||
### 8.2 数据安全
|
||||
|
||||
| 数据类型 | 存储方式 | 评价 |
|
||||
|----------|----------|------|
|
||||
| API Key | OS Keyring | ✅ 安全 |
|
||||
| Token | OS Keyring | ✅ 安全 |
|
||||
| 聊天记录 | SQLite (未加密) | ⚠️ 需加密 |
|
||||
| 主题配置 | localStorage | ✅ 可接受 |
|
||||
|
||||
### 8.3 输入验证
|
||||
|
||||
- ✅ SQL 注入防护 (参数化查询)
|
||||
- ⚠️ XSS 防护需确认
|
||||
|
||||
---
|
||||
|
||||
## 九、测试覆盖分析
|
||||
|
||||
### 9.1 单元测试
|
||||
|
||||
**测试文件分布:**
|
||||
|
||||
| 测试文件 | 覆盖范围 |
|
||||
|----------|----------|
|
||||
| autonomy-manager.test.ts | L4 授权逻辑 |
|
||||
| agent-memory.test.ts | 记忆系统 |
|
||||
| context-compactor.test.ts | 上下文压缩 |
|
||||
| heartbeat-reflection.test.ts | 心跳和反思 |
|
||||
| gatewayStore.test.ts | Store 状态 |
|
||||
| chatStore.test.ts | 聊天逻辑 |
|
||||
| teamStore.test.ts | 团队协作 |
|
||||
| browserHandStore.test.ts | 浏览器手 |
|
||||
| ws-client.test.ts | WebSocket 客户端 |
|
||||
|
||||
**评价:** ✅ 核心逻辑有覆盖
|
||||
|
||||
### 9.2 E2E 测试
|
||||
|
||||
- ✅ Playwright 已配置
|
||||
- ⚠️ 测试稳定性需提升 (当前 ~80% 通过率)
|
||||
|
||||
---
|
||||
|
||||
## 十、风险识别
|
||||
|
||||
### 10.1 技术风险
|
||||
|
||||
| 风险 | 概率 | 影响 | 缓解措施 |
|
||||
|------|------|------|----------|
|
||||
| OpenFang 版本不兼容 | 中 | 高 | 兼容性测试套件 |
|
||||
| LLM API 变更 | 中 | 高 | 抽象层隔离 |
|
||||
| 性能瓶颈 | 中 | 中 | 监控和优化 |
|
||||
|
||||
### 10.2 代码质量风险
|
||||
|
||||
| 问题 | 影响 | 优先级 |
|
||||
|------|------|--------|
|
||||
| gateway-client.ts 65KB | 维护困难 | P1 |
|
||||
| Rust unwrap() 使用 | 可能 panic | P1 |
|
||||
| localStorage 降级 | 数据不一致 | P1 |
|
||||
|
||||
### 10.3 维护风险
|
||||
|
||||
- 单人/小团队维护压力
|
||||
- 50+ 组件、36 个 lib、15 个 store 的维护成本
|
||||
|
||||
---
|
||||
|
||||
## 十一、关键发现总结
|
||||
|
||||
### 优势 (Strengths)
|
||||
|
||||
1. **技术栈先进** — Tauri 2.0 比 Electron 体积小 10x+
|
||||
2. **智能层设计深刻** — 记忆、反思、压缩是真正的差异化能力
|
||||
3. **Skills 生态丰富** — 68 个 Skill 覆盖多领域
|
||||
4. **Hands 系统完整** — 7 个能力包 + 审批/触发/审计全链路
|
||||
5. **中文优先** — 中文模型 Provider + 飞书集成
|
||||
6. **测试覆盖好** — 核心逻辑有单元测试
|
||||
7. **文档详尽** — 84+ 文档文件
|
||||
|
||||
### 劣势 (Weaknesses)
|
||||
|
||||
1. **gateway-client.ts 过大** (65KB) — 需拆分
|
||||
2. **E2E 测试不稳定** — 需修复
|
||||
3. **聊天记录未加密** — 需增强安全
|
||||
4. **部分 localStorage 使用** — 需评估
|
||||
|
||||
### 机会 (Opportunities)
|
||||
|
||||
1. 中国 AI Agent 市场爆发
|
||||
2. 本地优先隐私诉求增长
|
||||
3. OpenFang 生态缺口
|
||||
4. 飞书+企业微信整合需求
|
||||
5. Skill 市场变现潜力
|
||||
|
||||
### 威胁 (Threats)
|
||||
|
||||
1. 竞品迭代极快 (Cursor/Windsurf/AutoClaw)
|
||||
2. OpenFang 上游变化
|
||||
3. LLM API 不稳定
|
||||
4. 维护成本高
|
||||
|
||||
---
|
||||
|
||||
## 附录
|
||||
|
||||
### A. 关键文件索引
|
||||
|
||||
| 文件 | 位置 | 说明 |
|
||||
|------|------|------|
|
||||
| gateway-client.ts | desktop/src/lib/ | 核心通信客户端 |
|
||||
| intelligence-client.ts | desktop/src/lib/ | 智能层统一 API |
|
||||
| chatStore.ts | desktop/src/store/ | 聊天状态管理 |
|
||||
| lib.rs | desktop/src-tauri/src/ | Rust 后端入口 |
|
||||
| intelligence/ | desktop/src-tauri/src/ | 智能层 Rust 实现 |
|
||||
|
||||
### B. 参考文档
|
||||
|
||||
- [ZCLAW-DEEP-ANALYSIS.md](ZCLAW-DEEP-ANALYSIS.md)
|
||||
- [ZCLAW-DEEP-ANALYSIS-v2.md](ZCLAW-DEEP-ANALYSIS-v2.md)
|
||||
- [BRAINSTORMING-SESSION.md](BRAINSTORMING-SESSION.md)
|
||||
- [OPTIMIZATION-ROADMAP.md](OPTIMIZATION-ROADMAP.md)
|
||||
- [ISSUE-TRACKER.md](ISSUE-TRACKER.md)
|
||||
|
||||
---
|
||||
|
||||
*报告完成*
|
||||
@@ -273,6 +273,27 @@ cat config/chinese-providers.toml
|
||||
|
||||
## 测试结果汇总
|
||||
|
||||
> 最后更新: 2026-03-21
|
||||
|
||||
### 单元测试状态 (Vitest)
|
||||
|
||||
| 测试文件 | 测试数 | 状态 |
|
||||
|----------|--------|------|
|
||||
| workflowStore.test.ts | 32 | ✅ 通过 |
|
||||
| teamStore.test.ts | 20 | ✅ 通过 |
|
||||
| openfang-api.test.ts | 30 | ✅ 通过 |
|
||||
| swarm-skills.test.ts | 15 | ✅ 通过 |
|
||||
| heartbeat-reflection.test.ts | 25 | ✅ 通过 |
|
||||
| **总计** | **312** | **✅ 全部通过** |
|
||||
|
||||
### E2E 测试状态 (Playwright)
|
||||
|
||||
| 状态 | 说明 |
|
||||
|------|------|
|
||||
| ⚠️ 需修复 | 测试代码存在语法错误(重复声明、字符串未闭合) |
|
||||
|
||||
### 集成测试清单
|
||||
|
||||
| 类别 | 总数 | 通过 | 失败 | 待验证 |
|
||||
|------|------|------|------|--------|
|
||||
| Gateway 连接 | 4 | 0 | 0 | 4 |
|
||||
@@ -283,6 +304,15 @@ cat config/chinese-providers.toml
|
||||
| 端到端 | 2 | 0 | 0 | 2 |
|
||||
| **总计** | **22** | **0** | **0** | **22** |
|
||||
|
||||
### 环境验证 (2026-03-21)
|
||||
|
||||
| 项目 | 状态 | 说明 |
|
||||
|------|------|------|
|
||||
| pnpm | ✅ | v10.30.2 |
|
||||
| OpenFang Runtime | ✅ | v0.4.0 (57MB) |
|
||||
| Playwright | ✅ | v1.58.2 |
|
||||
| 配置文件 | ✅ | config.toml, chinese-providers.toml |
|
||||
|
||||
---
|
||||
|
||||
## 测试脚本模板
|
||||
|
||||
Reference in New Issue
Block a user