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

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

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

docs/archive/openclaw-legacy/openclaw-deep-dive.md

@@ -1,13 +1,13 @@
-# OpenClaw 深度理解与 ZCLAW 设计映射
+# ZCLAW 深度理解与 ZCLAW 设计映射
 
 **日期**: 2026-03-12  
-**目的**: 先彻底理解 OpenClaw 的产品哲学、运行机制、配置模型与扩展边界，再据此反推 ZCLAW 每一个功能页和设置项为什么存在、应该达成什么效果。
+**目的**: 先彻底理解 ZCLAW 的产品哲学、运行机制、配置模型与扩展边界，再据此反推 ZCLAW 每一个功能页和设置项为什么存在、应该达成什么效果。
 
 ---
 
 ## 一、结论先行
 
-OpenClaw **不是一个“聊天 UI + 模型接入器”**，而是一个围绕本地执行、持续上下文、设备身份、消息路由、技能生态与主动服务组织起来的 **本地优先 Agent 操作系统**。
+ZCLAW **不是一个“聊天 UI + 模型接入器”**，而是一个围绕本地执行、持续上下文、设备身份、消息路由、技能生态与主动服务组织起来的 **本地优先 Agent 操作系统**。
 
 如果只把它理解成：
 
@@ -26,17 +26,17 @@ OpenClaw **不是一个“聊天 UI + 模型接入器”**，而是一个围绕
 对 ZCLAW 来说，这意味着：
 
 - 我们的“设置页”本质上不应该只是 UI 偏好页
-- 很多设置项的真实目标是 **配置 OpenClaw Runtime**，不是更新前端本地 state
+- 很多设置项的真实目标是 **配置 ZCLAW Runtime**，不是更新前端本地 state
 - “快速配置”不应被理解为普通表单，而应被理解为 **创建/配置一个新的 Agent 实例**
 - 右侧 `Agent` 区域不应只是展示文案，而应反映当前选中 Agent 的真实身份、边界、工作目录、用户上下文与运行约束
 
 ---
 
-## 二、OpenClaw 的本质：它到底是什么
+## 二、ZCLAW 的本质：它到底是什么
 
 ### 1. 它是 Agent Runtime，而不是聊天前端
 
-从官方文档与协议设计看，OpenClaw 的核心不是 UI，而是下面这些长期存在的运行对象：
+从官方文档与协议设计看，ZCLAW 的核心不是 UI，而是下面这些长期存在的运行对象：
 
 - **Gateway**
 - **Agent workspace**
@@ -51,7 +51,7 @@ OpenClaw **不是一个“聊天 UI + 模型接入器”**，而是一个围绕
 
 ### 2. 它的核心价值是“执行 + 持续性 + 可控性”
 
-OpenClaw 的设计哲学非常稳定，几乎所有模块都服务于下面三件事：
+ZCLAW 的设计哲学非常稳定，几乎所有模块都服务于下面三件事：
 
 - **执行**
   - 能真正读写文件、跑命令、控浏览器、发消息
@@ -60,18 +60,18 @@ OpenClaw 的设计哲学非常稳定，几乎所有模块都服务于下面三
 - **可控性**
   - 用户能看到配置、文本指令、工作区与约束，而不是黑盒
 
-这决定了 OpenClaw 与很多“AI 工作台”产品的根本不同：
+这决定了 ZCLAW 与很多“AI 工作台”产品的根本不同：
 
 - 它强调的是 **Agent 作为系统角色**
 - 不是把模型套上聊天框就结束
 
 ---
 
-## 三、OpenClaw 的系统骨架
+## 三、ZCLAW 的系统骨架
 
 ### 1. Gateway：系统中枢
 
-Gateway 是 OpenClaw 的真正控制面板。它负责：
+Gateway 是 ZCLAW 的真正控制面板。它负责：
 
 - WebSocket 协议握手与会话维持
 - Agent 运行时管理
@@ -84,7 +84,7 @@ Gateway 是 OpenClaw 的真正控制面板。它负责：
 所以对 ZCLAW 而言：
 
 - 前端不是系统中心
-- 前端只是 **OpenClaw Runtime 的一个控制界面**
+- 前端只是 **ZCLAW Runtime 的一个控制界面**
 
 ### 2. Workspace：每个 Agent 的“根目录”
 
@@ -99,7 +99,7 @@ Gateway 是 OpenClaw 的真正控制面板。它负责：
 - `memory.md`
 - `memory/YYYY-MM-DD.md`
 
-这说明 OpenClaw 的“Agent 配置”不仅是 JSON，还是 **文件系统上的可读可改上下文**。
+这说明 ZCLAW 的“Agent 配置”不仅是 JSON，还是 **文件系统上的可读可改上下文**。
 
 ### 3. 多 Agent：多个独立人格 / 工作空间 / 路由单元
 
@@ -111,7 +111,7 @@ Gateway 是 OpenClaw 的真正控制面板。它负责：
 - 多个渠道账号/电话号码/机器人身份
 - 多套独立人格、记忆、沙箱与工具权限
 
-这意味着 OpenClaw 的多 Agent，本质上更像：
+这意味着 ZCLAW 的多 Agent，本质上更像：
 
 - 多个长期助手
 - 多个角色实例
@@ -123,17 +123,17 @@ Gateway 是 OpenClaw 的真正控制面板。它负责：
 
 对 ZCLAW 的直接影响：
 
-- 我们左侧“分身”更接近 OpenClaw 的 `agents.list`
+- 我们左侧“分身”更接近 ZCLAW 的 `agents.list`
 - 不应把“分身”只做成前端标签或临时角色描述
 - 每个分身都应该最终映射到一个真实的 Agent 配置单元
 
 ---
 
-## 四、配置模型：OpenClaw 为什么“像操作系统”
+## 四、配置模型：ZCLAW 为什么“像操作系统”
 
-### 1. `~/.openclaw/openclaw.json` 是系统配置，不是普通偏好设置
+### 1. `~/.zclaw/zclaw.json` 是系统配置，不是普通偏好设置
 
-官方配置文档说明，`openclaw.json` 用来描述整个系统行为，例如：
+官方配置文档说明，`zclaw.json` 用来描述整个系统行为，例如：
 
 - `agents.defaults.*`
 - `agents.list[]`
@@ -148,8 +148,8 @@ Gateway 是 OpenClaw 的真正控制面板。它负责：
 
 并且支持：
 
-- `openclaw configure`
-- `openclaw config get/set/unset`
+- `zclaw configure`
+- `zclaw config get/set/unset`
 - `config.get`
 - `config.apply`
 - `config.patch`
@@ -157,12 +157,12 @@ Gateway 是 OpenClaw 的真正控制面板。它负责：
 
 这说明 ZCLAW 的很多设置页，理应围绕下面的目标设计：
 
-- 让用户理解自己正在配置 **哪个 OpenClaw 子系统**
+- 让用户理解自己正在配置 **哪个 ZCLAW 子系统**
 - 让前端变成一个对配置进行可视化编辑的控制台
 
 ### 2. 配置是有层级和优先级的
 
-OpenClaw 的很多能力都采用“默认值 + 局部覆盖”模型：
+ZCLAW 的很多能力都采用“默认值 + 局部覆盖”模型：
 
 - `agents.defaults.*` 作为全局默认
 - `agents.list[].*` 作为每个 Agent 的覆盖
@@ -184,7 +184,7 @@ OpenClaw 的很多能力都采用“默认值 + 局部覆盖”模型：
 
 ---
 
-## 五、Bootstrap 文件的职责：为什么 OpenClaw 不靠数据库隐藏一切
+## 五、Bootstrap 文件的职责：为什么 ZCLAW 不靠数据库隐藏一切
 
 ### 1. `AGENTS.md`：操作规范与行为准则
 
@@ -247,7 +247,7 @@ OpenClaw 的很多能力都采用“默认值 + 局部覆盖”模型：
 
 ---
 
-## 六、Agent 的真正含义：OpenClaw 里“一个 Agent”是什么
+## 六、Agent 的真正含义：ZCLAW 里“一个 Agent”是什么
 
 结合官方 `Multi-Agent Routing` 文档，可以把一个 Agent 理解成：
 
@@ -279,7 +279,7 @@ OpenClaw 的很多能力都采用“默认值 + 局部覆盖”模型：
 
 ---
 
-## 七、Routing：为什么 OpenClaw 的多 Agent 不只是“列表切换”
+## 七、Routing：为什么 ZCLAW 的多 Agent 不只是“列表切换”
 
 官方路由顺序大致是：
 
@@ -295,7 +295,7 @@ OpenClaw 的很多能力都采用“默认值 + 局部覆盖”模型：
 对 ZCLAW 的启发：
 
 - 左侧分身列表只是 **人能看懂的入口**
-- 真正完成 OpenClaw 化，还需要绑定路由语义
+- 真正完成 ZCLAW 化，还需要绑定路由语义
 - 后续应该把“分身”扩展为：
   - Agent 基本资料
   - 渠道路由绑定
@@ -322,7 +322,7 @@ OpenClaw 的很多能力都采用“默认值 + 局部覆盖”模型：
 
 对 ZCLAW 的直接含义：
 
-- “定时任务页”如果只展示 cron 表达式，会偏离 OpenClaw
+- “定时任务页”如果只展示 cron 表达式，会偏离 ZCLAW
 - 应该更多展示：
   - 哪些 Agent 开启了 heartbeat
   - Heartbeat 多久触发一次
@@ -336,9 +336,9 @@ OpenClaw 的很多能力都采用“默认值 + 局部覆盖”模型：
 
 官方文档与命令表明：
 
-- `openclaw skills list`
-- `openclaw skills info <name>`
-- `openclaw skills check`
+- `zclaw skills list`
+- `zclaw skills info <name>`
+- `zclaw skills check`
 
 以及仓库中多处强调：
 
@@ -365,7 +365,7 @@ OpenClaw 的很多能力都采用“默认值 + 局部覆盖”模型：
 
 ## 十、Channels：为什么 IM 频道不是“集成列表”而是系统输入面
 
-OpenClaw 的渠道模型并不是简单“接一个 webhook”这么轻。
+ZCLAW 的渠道模型并不是简单“接一个 webhook”这么轻。
 
 它包含：
 
@@ -397,11 +397,11 @@ OpenClaw 的渠道模型并不是简单“接一个 webhook”这么轻。
 
 ---
 
-## 十一、MCP：在 OpenClaw 里意味着什么
+## 十一、MCP：在 ZCLAW 里意味着什么
 
-从现有资料可以确认，OpenClaw 原生支持 MCP / RPC adapters / 外部工具扩展。
+从现有资料可以确认，ZCLAW 原生支持 MCP / RPC adapters / 外部工具扩展。
 
-在 OpenClaw 语境下，MCP 的作用不是点缀，而是：
+在 ZCLAW 语境下，MCP 的作用不是点缀，而是：
 
 - 给 Agent 扩展新的上下文来源与工具面
 - 让技能可以调用标准化外部能力
@@ -431,7 +431,7 @@ OpenClaw 的渠道模型并不是简单“接一个 webhook”这么轻。
 这件事对 ZCLAW 很关键，因为它说明：
 
 - “连接 Gateway”不是 UI 层小问题
-- 它背后是 OpenClaw 的安全边界
+- 它背后是 ZCLAW 的安全边界
 - 前端任何“连接设置”都必须尊重设备身份与鉴权语义
 
 我们这次调试里已经验证：
@@ -447,7 +447,7 @@ OpenClaw 的渠道模型并不是简单“接一个 webhook”这么轻。
 
 ## 十三、ZCLAW 的功能设置为什么存在：逐页重解释
 
-下面用 OpenClaw 视角重写 ZCLAW 设置页目的。
+下面用 ZCLAW 视角重写 ZCLAW 设置页目的。
 
 ### 1. 通用
 
@@ -463,7 +463,7 @@ OpenClaw 的渠道模型并不是简单“接一个 webhook”这么轻。
 
 真实目标：
 
-- 管理 OpenClaw 的 provider / model defaults
+- 管理 ZCLAW 的 provider / model defaults
 - 决定 Agent 运行时使用的主模型与 fallback
 - 调试 Gateway 连接与鉴权
 
@@ -531,10 +531,10 @@ OpenClaw 的渠道模型并不是简单“接一个 webhook”这么轻。
 
 - 三栏桌面结构
 - 分身 / IM / 定时任务主界面骨架
-- 对 OpenClaw Gateway 的接入方向
+- 对 ZCLAW Gateway 的接入方向
 - 自定义插件模式
 - 使用 bootstrap 文件与默认配置模板
-- 将中文模型、飞书、UI RPC 作为 OpenClaw 上层定制
+- 将中文模型、飞书、UI RPC 作为 ZCLAW 上层定制
 
 ### 2. 当前最容易继续偏离的部分
 
@@ -549,7 +549,7 @@ OpenClaw 的渠道模型并不是简单“接一个 webhook”这么轻。
 
 后续所有功能实现都建议遵循下面这个判断标准：
 
-> 如果一个页面改动之后，没有改变 OpenClaw Runtime 的真实行为、真实配置、真实路由、真实工作区或真实 Agent 上下文，那它大概率还只是“演示 UI”，不是系统能力。
+> 如果一个页面改动之后，没有改变 ZCLAW Runtime 的真实行为、真实配置、真实路由、真实工作区或真实 Agent 上下文，那它大概率还只是“演示 UI”，不是系统能力。
 
 ---
 
@@ -576,7 +576,7 @@ OpenClaw 的渠道模型并不是简单“接一个 webhook”这么轻。
 
 结论：
 
-- 在 ZCLAW 语境里，它应该逐步收敛为 OpenClaw 的 Agent 实例
+- 在 ZCLAW 语境里，它应该逐步收敛为 ZCLAW 的 Agent 实例
 - 不是任务拆解型多智能体
 - 不是单纯聊天角色标签
 
@@ -618,7 +618,7 @@ OpenClaw 的渠道模型并不是简单“接一个 webhook”这么轻。
 - 工具/文件限制
 - heartbeat / skills / channels 初始策略
 
-### P3：把设置页升级为 OpenClaw Runtime 配置面板
+### P3：把设置页升级为 ZCLAW Runtime 配置面板
 
 包括：
 
@@ -642,13 +642,13 @@ OpenClaw 的渠道模型并不是简单“接一个 webhook”这么轻。
 
 后续写代码时，建议每次先问自己：
 
-- 这个功能对应的是 OpenClaw 的哪个子系统？
+- 这个功能对应的是 ZCLAW 的哪个子系统？
 - 它改的是系统级、Agent 级，还是渠道/账号级？
 - 它落地到哪里：JSON 配置、workspace 文件、bindings、channel account，还是 runtime state？
 - 它改变的是 UI 表象，还是 Agent 的真实行为？
 - 它是否应该反映在右侧 Agent 面板 / 左侧分身列表 / 渠道路由 / heartbeat 行为中？
 
-如果这些问题答不清，通常说明实现路径还没对齐 OpenClaw。
+如果这些问题答不清，通常说明实现路径还没对齐 ZCLAW。
 
 ---
 
@@ -656,37 +656,37 @@ OpenClaw 的渠道模型并不是简单“接一个 webhook”这么轻。
 
 ### 官方公开资料
 
-1. OpenClaw Gateway Protocol  
-   https://docs.openclaw.ai/gateway/protocol
-2. OpenClaw Gateway Troubleshooting  
-   https://docs.openclaw.ai/gateway/troubleshooting
-3. OpenClaw Configuration  
-   https://docs.openclaw.ai/gateway/configuration
-4. OpenClaw Multi-Agent Routing  
-   https://docs.openclaw.ai/concepts/multi-agent
-5. OpenClaw Heartbeat  
-   https://docs.openclaw.ai/gateway/heartbeat
-6. OpenClaw Skills CLI  
-   https://docs.openclaw.ai/cli/skills
-7. OpenClaw Default AGENTS.md  
-   https://docs.openclaw.ai/reference/AGENTS.default
-8. OpenClaw SOUL.md Template  
-   https://docs.openclaw.ai/reference/templates/SOUL
-9. OpenClaw USER Template  
-   https://docs.openclaw.ai/reference/templates/USER
-10. OpenClaw IDENTITY Template  
-    https://docs.openclaw.ai/reference/templates/IDENTITY
+1. ZCLAW Gateway Protocol  
+   https://docs.zclaw.ai/gateway/protocol
+2. ZCLAW Gateway Troubleshooting  
+   https://docs.zclaw.ai/gateway/troubleshooting
+3. ZCLAW Configuration  
+   https://docs.zclaw.ai/gateway/configuration
+4. ZCLAW Multi-Agent Routing  
+   https://docs.zclaw.ai/concepts/multi-agent
+5. ZCLAW Heartbeat  
+   https://docs.zclaw.ai/gateway/heartbeat
+6. ZCLAW Skills CLI  
+   https://docs.zclaw.ai/cli/skills
+7. ZCLAW Default AGENTS.md  
+   https://docs.zclaw.ai/reference/AGENTS.default
+8. ZCLAW SOUL.md Template  
+   https://docs.zclaw.ai/reference/templates/SOUL
+9. ZCLAW USER Template  
+   https://docs.zclaw.ai/reference/templates/USER
+10. ZCLAW IDENTITY Template  
+    https://docs.zclaw.ai/reference/templates/IDENTITY
 11. Third-party client authentication guide issue  
-    https://github.com/openclaw/openclaw/issues/17571
+    https://github.com/zclaw/zclaw/issues/17571
 12. Device signature mismatch issue  
-    https://github.com/openclaw/openclaw/issues/39667
+    https://github.com/zclaw/zclaw/issues/39667
 
 ### 仓库内现有文档
 
 1. `docs/deviation-analysis.md`
 2. `docs/architecture-v2.md`
 3. `README.md`
-4. `config/openclaw.default.json`
+4. `config/zclaw.default.json`
 5. `config/AGENTS.md`
 6. `config/SOUL.md`
 7. `config/USER.md`
@@ -706,4 +706,4 @@ OpenClaw 的渠道模型并不是简单“接一个 webhook”这么轻。
 
 一句话总结：
 
-> ZCLAW 不是要“做一个像 AutoClaw 的前端”，而是要“在真正理解 OpenClaw 运行模型之后，做一个面向中文场景的 Tauri 封装层”。
+> ZCLAW 不是要“做一个像 AutoClaw 的前端”，而是要“在真正理解 ZCLAW 运行模型之后，做一个面向中文场景的 Tauri 封装层”。