ClawCraft 架构确认

背景与挑战

Dad 希望把整个 OpenClaw 系统可视化成 RTS（帝国时代）式界面，但初期面临核心架构选择：是否要侵入式改造 OpenClaw 核心代码？

关键决策：Plugin 扩展方案

决策者：bot（基于 GPT-5.4 辩论与源码核实）
时间：2026-03-12 凌晨

决策过程

1. 源码调研：深入分析 OpenClaw 官方文档与源码结构
2. 架构辩论：使用 github-copilot/gpt-5.4 进行高思考量架构评估
3. 技术验证：确认 Plugin SDK TypeScript 类型定义和 PluginRuntime 类型

最终方案

选择 Plugin 扩展架构，通过以下方式实现： - Gateway 事件流：获取系统实时状态 - RPC/API 调用：执行配置和管理操作 - 独立可视化层：前端作为独立层，不破坏 OpenClaw 原有逻辑

选型理由

1. 升级风险低：与 OpenClaw 原生能力对齐，兼容性好
2. 渐进演进：从只读监控逐步演进到可操作控制台
3. 测试安全：便于在测试机做 E2E，不影响主环境

技术实证方法

基于源码而非猜测

bot 强调通过实际查看来确定技术方案： - Gateway 事件列表 - RPC 方法签名 - Plugin SDK TypeScript 类型定义 - PluginRuntime 类型结构

这种"实证"方法确保 ClawCraft 的"世界状态"与 OpenClaw 实际概念一一映射。

模型配置经验

在研究过程中积累了重要的模型使用经验： - research agent 只能 spawn main 子代理 - 可通过 model override 指定 github-copilot/gpt-5.4 - Gemini 正确模型名：github-copilot/gemini-3.1-pro-preview

这为后续"多模型协作审查 PRD/架构"奠定了基础。

架构影响

这个决策直接影响了后续所有开发： 1. 开发方式：所有功能基于 Plugin Hook 机制 2. 数据获取：通过 Gateway 事件而非直接访问内部状态 3. 部署策略：可以独立部署和升级，不依赖 OpenClaw 版本 4. 测试策略：支持 Mock 和真实环境双轨验证

长期价值

Plugin 架构选择为 OpenClaw 生态扩展奠定了重要基础： - 其他第三方工具也可以采用相同模式 - 为 OpenClaw 商业化和社区生态发展提供了标准化接入方式 - 证明了非侵入式扩展的技术可行性