refactor: 统一项目名称从OpenFang到ZCLAW

重构所有代码和文档中的项目名称，将OpenFang统一更新为ZCLAW。包括：
- 配置文件中的项目名称
- 代码注释和文档引用
- 环境变量和路径
- 类型定义和接口名称
- 测试用例和模拟数据

同时优化部分代码结构，移除未使用的模块，并更新相关依赖项。

docs/archive/ZCLAW_NEXT_EVOLUTION_STRATEGY.md

@@ -2,7 +2,7 @@
 
 > **文档日期**：2026-03-15  
 > **适用对象**：项目负责人、架构负责人、客户端/后端/平台研发、测试与产品团队  
-> **文档目的**：基于 OpenClaw / NanoClaw / ZeroClaw 等相关系统的公开资料与当前仓库现状，形成可执行的下一阶段演化决策依据  
+> **文档目的**：基于 ZCLAW / NanoClaw / ZeroClaw 等相关系统的公开资料与当前仓库现状，形成可执行的下一阶段演化决策依据  
 > **说明**：用户需求中提到 `zeraoclaw`。基于公开可验证资料，当前最接近且资料完备的目标项目为 `ZeroClaw`，本报告按 `ZeroClaw` 纳入对比。如后续确认另有特定项目，可在同一分析框架下快速替换。
 >
 > **关联文档**：本文档聚焦**架构层**的全景对比与演化方案。关于 **Agent 智能层**（记忆系统、主动引擎、自我演化、上下文治理等）的深度差距分析与实施方案，请参阅 [`ZCLAW_AGENT_INTELLIGENCE_EVOLUTION.md`](./ZCLAW_AGENT_INTELLIGENCE_EVOLUTION.md)。
@@ -16,7 +16,7 @@
 当前项目已经具备继续独立演化的基础，但从仓库现状看，仍存在三类关键问题：
 
 - **叙事未统一**
-  - 仓库内同时存在 `OpenClaw 定制化`、`OpenFang 迁移`、`独立系统演化` 三套表述。
+  - 仓库内同时存在 `ZCLAW 定制化`、`ZCLAW 迁移`、`独立系统演化` 三套表述。
   - 这说明产品定位和架构边界还没有形成统一的外部口径与内部治理口径。
 
 - **能力边界未完全内聚**
@@ -25,7 +25,7 @@
 
 - **下一阶段不宜继续做“上游壳层产品”**
   - 对比结果显示：
-    - `OpenClaw` 的优势在于生态广、能力全、社区强。
+    - `ZCLAW` 的优势在于生态广、能力全、社区强。
     - `NanoClaw` 的优势在于小而可控、容器隔离、极易定制。
     - `ZeroClaw` 的优势在于性能、可移植性、部署效率与 trait 化扩展。
   - 对 ZCLAW 最优的路径不是简单“选边站队”，而是**形成自己的产品控制面与领域模型，在运行时层通过适配器吸收上游优势**。
@@ -43,7 +43,7 @@
   - 插件市场、配置中心、审计与运营面板
 
 - **下层**：将具体运行时封装为可替换适配器
-  - `OpenClaw Adapter`
+  - `ZCLAW Adapter`
   - `ZeroClaw-style Adapter`
   - `NanoClaw-style Secure Sandbox Adapter`
   - 后续保留 `ZCLAW Native Runtime` 的演化空间
@@ -62,10 +62,10 @@
 
 从当前仓库文档可见：
 
-- `README.md` 仍以 **OpenClaw 定制版** 为主叙述。
-- `docs/architecture-v2.md` 描述的是 **OpenClaw + Tauri + 自定义插件** 的 v2 架构。
-- `docs/SYSTEM_ANALYSIS.md` 又显示项目已经大量引入 **OpenFang 风格能力与 API 面**。
-- 其他文档还包含对 OpenFang 迁移、ZeroClaw/NanoClaw/OpenClaw 生态分析等内容。
+- `README.md` 仍以 **ZCLAW 定制版** 为主叙述。
+- `docs/architecture-v2.md` 描述的是 **ZCLAW + Tauri + 自定义插件** 的 v2 架构。
+- `docs/SYSTEM_ANALYSIS.md` 又显示项目已经大量引入 **ZCLAW 风格能力与 API 面**。
+- 其他文档还包含对 ZCLAW 迁移、ZeroClaw/NanoClaw/ZCLAW 生态分析等内容。
 
 这说明项目技术上已经不再只是“某个上游的 UI 壳层”，而是在向一个更独立的产品系统演化；但**架构叙事、模块边界和对外定位还没有完全收敛**。
 
@@ -88,7 +88,7 @@
 
 本次纳入对比的主要系统：
 
-- **OpenClaw**
+- **ZCLAW**
 - **NanoClaw**
 - **ZeroClaw**
 - **ZCLAW 当前系统**（作为被决策对象）
@@ -122,9 +122,9 @@
 
 | 系统 | 核心定位 | 技术路线 | 适合场景 | 主要优势 | 主要代价 |
 |------|----------|----------|----------|----------|----------|
-| **OpenClaw** | 功能完备的个人 AI 助手与 Gateway 控制平面 | Node.js + TypeScript + 多端/多渠道生态 | 多渠道接入、完整能力复用、社区协作 | 生态成熟、通道丰富、能力全 | 复杂度高、资源占用较高 |
+| **ZCLAW** | 功能完备的个人 AI 助手与 Gateway 控制平面 | Node.js + TypeScript + 多端/多渠道生态 | 多渠道接入、完整能力复用、社区协作 | 生态成熟、通道丰富、能力全 | 复杂度高、资源占用较高 |
 | **NanoClaw** | 轻量、可理解、容器隔离的个人 AI 助手 | 单 Node 进程 + Docker/Apple Container + Claude Agent SDK | 个人定制、快速 fork、强隔离 | 架构简单、容器隔离、改造门槛低 | 生态广度不足、对 Claude 体系依赖更强 |
-| **ZeroClaw** | Rust 单二进制、强调高性能与可替换组件的自主 Agent 运行时 | Rust + trait 化模块 + binary-first | 边缘部署、低资源环境、性能敏感场景 | 低内存、快启动、跨平台部署轻量 | 生态成熟度仍弱于 OpenClaw |
+| **ZeroClaw** | Rust 单二进制、强调高性能与可替换组件的自主 Agent 运行时 | Rust + trait 化模块 + binary-first | 边缘部署、低资源环境、性能敏感场景 | 低内存、快启动、跨平台部署轻量 | 生态成熟度仍弱于 ZCLAW |
 | **ZCLAW 当前系统** | 已形成自有产品控制面雏形的桌面 Agent 平台 | Tauri + React + Store + 上游运行时耦合能力 | 中文化产品、桌面交互、企业/团队可视化 | UI/产品层较完整、定制能力强 | 上下游边界仍混杂、叙事未统一 |
 
 ---
@@ -133,7 +133,7 @@
 
 ## 5.1 技术架构对比
 
-### OpenClaw
+### ZCLAW
 
 架构核心是 **Gateway 作为统一控制平面**：
 
@@ -169,7 +169,7 @@
 
 最适合 ZCLAW 的不是复制任何一方，而是组合三者优点：
 
-- 学 OpenClaw 的 **控制平面与生态广度**
+- 学 ZCLAW 的 **控制平面与生态广度**
 - 学 NanoClaw 的 **安全隔离与可理解性**
 - 学 ZeroClaw 的 **适配器化和低负载运行时设计**
 
@@ -177,7 +177,7 @@
 
 ## 5.2 核心功能对比
 
-| 维度 | OpenClaw | NanoClaw | ZeroClaw | 对 ZCLAW 的启示 |
+| 维度 | ZCLAW | NanoClaw | ZeroClaw | 对 ZCLAW 的启示 |
 |------|----------|----------|----------|------------------|
 | **多渠道接入** | 强，覆盖广 | 中，靠 skills 扩展 | 中，强调可插拔 | ZCLAW 应保留渠道抽象层，不把单一 IM 深绑在 UI 上 |
 | **会话与消息控制平面** | 强 | 中 | 中到强 | ZCLAW 要沉淀自己的 `Conversation/Session/Run` 模型 |
@@ -189,7 +189,7 @@
 
 ### 判断
 
-- 如果目标是**尽快做全功能产品**，OpenClaw 价值最高。
+- 如果目标是**尽快做全功能产品**，ZCLAW 价值最高。
 - 如果目标是**单人/小团队快速安全定制**，NanoClaw 的方法更高效。
 - 如果目标是**高性能、可替换、长期独立演化**，ZeroClaw 的路线更先进。
 
@@ -201,10 +201,10 @@ ZCLAW 应把自己的主轴明确为：**产品化桌面控制面 + 中文场景
 
 ### 可验证的公开信息
 
-- **OpenClaw**
+- **ZCLAW**
   - 运行依赖 `Node.js >= 22`
   - 社区规模极大，功能体系最重
-  - 从 ZeroClaw 官方 benchmark 描述中可见，OpenClaw 需要额外 Node 运行时开销，内存画像明显高于 Rust 单二进制方案
+  - 从 ZeroClaw 官方 benchmark 描述中可见，ZCLAW 需要额外 Node 运行时开销，内存画像明显高于 Rust 单二进制方案
 
 - **ZeroClaw**
   - 官方 benchmark 示例给出：
@@ -243,7 +243,7 @@ ZCLAW 若继续强化桌面端与 7x24 运行能力，必须尽快解决两个
 
 ## 5.4 扩展性对比
 
-### OpenClaw
+### ZCLAW
 
 扩展生态最强，适合“接入更多能力”；但产品二开时要承担：
 
@@ -282,7 +282,7 @@ ZCLAW 的扩展性应该分三层设计：
 
 ## 5.5 兼容性对比
 
-| 维度 | OpenClaw | NanoClaw | ZeroClaw | 对 ZCLAW 的建议 |
+| 维度 | ZCLAW | NanoClaw | ZeroClaw | 对 ZCLAW 的建议 |
 |------|----------|----------|----------|------------------|
 | **与现有 ZCLAW 文档/代码语义贴近度** | 高 | 中 | 中 | 短期最适合作为兼容基线 |
 | **桌面端交互兼容性** | 高 | 中 | 中 | 通过中间协议层抽象 |
@@ -302,7 +302,7 @@ ZCLAW 的扩展性应该分三层设计：
 
 ## 5.6 安全与治理对比
 
-### OpenClaw
+### ZCLAW
 
 安全模型强调：
 
@@ -349,7 +349,7 @@ ZCLAW 必须形成自己的安全治理分层：
 
 ## 5.7 社区支持对比
 
-### OpenClaw
+### ZCLAW
 
 依据官方 GitHub 页面：
 
@@ -369,7 +369,7 @@ ZCLAW 必须形成自己的安全治理分层：
 - Releases/Tags：公开可见较少
 - 社区组织方式更偏 Discord + 个人定制 fork 模式
 
-说明其讨论热度不低，但工程治理和生态标准化程度相对弱于 OpenClaw。
+说明其讨论热度不低，但工程治理和生态标准化程度相对弱于 ZCLAW。
 
 ### ZeroClaw
 
@@ -397,7 +397,7 @@ ZCLAW 必须形成自己的安全治理分层：
 
 ## 6.1 应该吸收的能力
 
-### 来自 OpenClaw
+### 来自 ZCLAW
 
 - 多渠道控制平面理念
 - 会话/消息/工具事件统一流模型
@@ -482,7 +482,7 @@ ZCLAW 必须形成自己的安全治理分层：
 
 讨论三种备选路线：
 
-- **路线 A：继续深度绑定 OpenClaw 生态**
+- **路线 A：继续深度绑定 ZCLAW 生态**
 - **路线 B：向 ZeroClaw/NanoClaw 风格的轻量内核迁移**
 - **路线 C：构建 ZCLAW Core + Adapter 的独立架构**
 
@@ -564,7 +564,7 @@ ZCLAW 必须形成自己的安全治理分层：
 
 ## 8.1 备选技术路线
 
-### 路线 A：继续以 OpenClaw 为单一主干
+### 路线 A：继续以 ZCLAW 为单一主干
 
 **优点**：
 
@@ -635,7 +635,7 @@ ZCLAW 必须形成自己的安全治理分层：
 
 负责：
 
-- OpenClaw Adapter
+- ZCLAW Adapter
 - ZeroClaw-style Adapter
 - NanoClaw-style Sandbox Adapter
 - 后续 Native Runtime Adapter
@@ -702,7 +702,7 @@ ZCLAW 必须形成自己的安全治理分层：
 ### 关键任务
 
 - 建立 `RuntimeAdapter` 接口
-- 首先实现 `OpenClawAdapter`
+- 首先实现 `ZCLAWAdapter`
 - 将当前 gateway client / store 中的协议特化逻辑迁出
 - 建立 adapter contract tests
 - 对连接、流式输出、工具调用、配置读写、会话管理做统一抽象
@@ -875,7 +875,7 @@ ZCLAW 必须形成自己的安全治理分层：
 |--------|------|----------|
 | 第 1-2 周 | 统一叙事与边界 | ADR、系统边界图、耦合点清单 |
 | 第 3-5 周 | 统一领域模型 | Canonical schema、配置模型、事件模型 |
-| 第 6-9 周 | Adapter 层落地 | RuntimeAdapter、OpenClawAdapter、合同测试 |
+| 第 6-9 周 | Adapter 层落地 | RuntimeAdapter、ZCLAWAdapter、合同测试 |
 | 第 10-13 周 | 平台能力增强 | Workflow/Approval/Team 等独立能力强化 |
 | 第 14-16 周 | 安全与产品化 | 安全策略、基准测试、插件规范、发布策略 |
 
@@ -951,7 +951,7 @@ ZCLAW 下一阶段最重要的工作，不是继续在某个上游上“加功
 - **战略上**：选择 `ZCLAW Core + Runtime Adapter` 作为主路线。
 - **组织上**：通过专题头脑风暴会议统一路线与边界。
 - **实施上**：优先做叙事统一、领域模型统一、适配器收口三件事。
-- **价值上**：把 OpenClaw 的生态、NanoClaw 的隔离思路、ZeroClaw 的轻量架构，吸收到 ZCLAW 自己的产品体系中。
+- **价值上**：把 ZCLAW 的生态、NanoClaw 的隔离思路、ZeroClaw 的轻量架构，吸收到 ZCLAW 自己的产品体系中。
 
 如果这一轮推进顺利，ZCLAW 将不再只是“基于某个框架的定制版”，而会成为一个**能够独立定义产品、独立定义扩展模型、独立定义演化节奏**的系统。
 
@@ -964,16 +964,16 @@ ZCLAW 下一阶段最重要的工作，不是继续在某个上游上“加功
 - `README.md`
 - `docs/architecture-v2.md`
 - `docs/SYSTEM_ANALYSIS.md`
-- `docs/openclaw-to-openfang-migration-brainstorm.md`
+- `docs/zclaw-to-zclaw-migration-brainstorm.md`
 - `docs/claw-ecosystem-deep-dive-report.md`
 
 ### 公开资料（本次已核验部分）
 
-- OpenClaw 官方仓库：`https://github.com/openclaw/openclaw`
-- OpenClaw 官方文档入口：`https://docs.openclaw.ai`
+- ZCLAW 官方仓库：`https://github.com/zclaw/zclaw`
+- ZCLAW 官方文档入口：`https://docs.zclaw.ai`
 - NanoClaw 官方站点：`https://nanoclaw.dev/`
 - NanoClaw 官方仓库：`https://github.com/qwibitai/nanoclaw`
 - ZeroClaw 官方站点：`https://zeroclaw.bot/`
 - ZeroClaw 官方仓库：`https://github.com/zeroclaw-labs/zeroclaw`
 
-> 注：部分官方文档页在本次抓取过程中存在超时，因此文中对 OpenClaw 官方文档细节的引用，优先采用其官方 GitHub README 与可稳定访问的官方摘要信息，不对未成功直读页面做超出摘要范围的延展解释。
+> 注：部分官方文档页在本次抓取过程中存在超时，因此文中对 ZCLAW 官方文档细节的引用，优先采用其官方 GitHub README 与可稳定访问的官方摘要信息，不对未成功直读页面做超出摘要范围的延展解释。