跳转至

Hermes / OpenClaw -> ECC 迁移

本文档是将 Hermes 或 OpenClaw 风格的操作员配置迁移到当前 ECC 模型的公开迁移指南。

目标不是逐字节复现一个私有操作员工作区。

目标是保留有用的工作流界面：

  • 可复用技能
  • 稳定的自动化入口
  • 跨框架可移植性
  • 调度器 / 提醒 / 调度
  • 持久上下文和操作员记忆

同时移除应保持私有的部分：

  • 机密
  • 个人数据集
  • 账户 Token
  • 仅限本地的业务产物

迁移主张

将 Hermes 和 OpenClaw 视为源系统，而不是最终运行时。

ECC 是持久的公开系统：

  • 技能
  • agent
  • 命令
  • hook
  • 安装入口
  • 会话适配器
  • ECC 2.0 控制平面工作

Hermes 和 OpenClaw 是有用的输入，因为它们包含可提炼为 ECC 原生界面的重复操作员工作流。

这意味着最短安全路径是：

  1. 提取可复用行为
  2. 将其转换为 ECC 原生技能、hook、文档或适配器工作
  3. 将机密和个人数据保留在仓库之外

当前工作区模型

始终一致地使用当前工作区分层：

  • 实时代码工作在 ~/GitHub 下的克隆仓库中进行
  • 仓库特定方向位于仓库 docs/ 下的规划文档中，已发布变更历史位于 CHANGELOG.md
  • 更广泛的非代码上下文可以放在 KB/归档层
  • 持久的跨机器事实应优先使用 GitHub、Linear 和知识库

不要在公开仓库内重建影子私有工作区。

转换映射

1. 调度器 / cron 层

源示例：

  • cron/scheduler.py
  • jobs.py
  • 周期性就绪或问责循环

转换为：

  • 在可用时采用 Claude 原生调度
  • 用于本地可重复性的 ECC hook / 命令自动化
  • issue #1050 下的 ECC 2.0 调度器工作

如今，仓库已经具备正确的公开框架：

  • 用于低延迟仓库本地自动化的 hook
  • 用于显式操作员操作的命令
  • ECC 2.0 作为未来长期运行的调度/控制平面

2. 网关 / 调度层

源示例：

  • Hermes 网关
  • 移动端调度 / 远程提醒
  • 活跃会话之间的操作员路由

转换为：

  • ECC 会话适配器和控制平面工作
  • 编排/会话检查命令
  • 以下 ECC 2.0 控制平面待办事项：
  • #1045
  • #1046
  • #1047
  • #1048

公开仓库应描述适配器边界和控制平面模型，而不是假装远程操作员 shell 已经完全 GA。

3. 记忆层

源示例：

  • memory_tool.py
  • 本地操作员记忆
  • 业务 / 运维上下文存储

转换为：

  • knowledge-ops
  • 位于 docs/ 和 CHANGELOG.md 下的仓库规划文档
  • 由 GitHub / Linear / KB 支持的持久上下文
  • #1049 下的未来深度记忆工作

重要区别是：

  • 仓库执行上下文应靠近仓库
  • 更广泛的非代码记忆应放在 KB/归档系统中
  • 公开仓库应记录边界，而不是存储私有记忆转储

4. 技能层

源示例：

  • Hermes 技能
  • OpenClaw 技能
  • 生成的操作员手册

转换为：

  • 当工作流可复用时，转换为 ECC 原生顶层技能
  • 当内容只是模板时，转换为文档/示例
  • 当行为是程序性而非知识型时，转换为 hook 或命令

近期已通过这种方式回收的示例：

  • knowledge-ops
  • github-ops
  • hookify-rules
  • automation-audit-ops
  • email-ops
  • finance-billing-ops
  • messages-ops
  • research-ops
  • terminal-ops
  • ecc-tools-cost-audit

5. 工具 / 服务层

源示例：

  • 自定义服务包装器
  • 基于 API-key 的本地工具
  • 浏览器自动化胶水代码

转换为：

  • 当存在连接器时，转换为 MCP 支持的界面
  • 当工作流逻辑才是真正资产时，转换为 ECC 原生操作员技能
  • 当缺失部分是会话/运行时协调时，进行适配器/控制平面工作

不要仅仅因为私有工作流依赖它们，就将不透明的第三方运行时导入 ECC。

如果工作流有价值：

  1. 理解其行为
  2. 重建最小 ECC 原生版本
  3. 记录本地所需的 auth/连接器

已公开存在的内容

当前仓库已经覆盖了迁移的有意义部分：

  • ECC 2.0 适配器/控制平面发现文档
  • 编排/会话检查基础层
  • 操作员工作流技能
  • 成本 / 计费 / 工作流审计技能
  • 跨框架安装入口
  • 用于配置和 agent 界面扫描的 AgentShield

这意味着迁移问题不再是“从零开始”。

它主要是：

  • 提炼缺失的私有工作流
  • 澄清公开文档
  • 继续构建 ECC 2.0 操作员/控制平面

ECC 2.0 现在提供了一个有边界的迁移审计入口：

  • ecc migrate audit --source ~/.hermes
  • ecc migrate plan --source ~/.hermes --output migration-plan.md
  • ecc migrate scaffold --source ~/.hermes --output-dir migration-artifacts
  • ecc migrate import-skills --source ~/.hermes --output-dir migration-artifacts/skills
  • ecc migrate import-tools --source ~/.hermes --output-dir migration-artifacts/tools
  • ecc migrate import-plugins --source ~/.hermes --output-dir migration-artifacts/plugins
  • ecc migrate import-schedules --source ~/.hermes --dry-run
  • ecc migrate import-remote --source ~/.hermes --dry-run
  • ecc migrate import-env --source ~/.hermes --dry-run
  • ecc migrate import-memory --source ~/.hermes

首先使用它来清点旧工作区，并将检测到的界面映射到当前 ECC2 调度器、远程调度、记忆图谱、模板和手动翻译通道。

仍属于待办事项的内容

其余大型迁移主题已被跟踪：

  • #1051 Hermes/OpenClaw 迁移
  • #1049 深度记忆层
  • #1050 自主调度
  • #1048 通用框架兼容层
  • #1046 agent 编排器
  • #1045 多会话 TUI 管理器
  • #1047 可视化 worktree 管理器

那是未解决的控制平面工作的正确位置。

不要仅因为公共文档已存在，就假装迁移已经“完成”。

  1. 将公共 ECC 仓库保留为规范的可复用层。
  2. 将可复用的 Hermes/OpenClaw 工作流逐个通道移植为 ECC 原生技能。
  3. 将私有认证和个人上下文保留在仓库之外。
  4. 使用 GitHub / Linear / KB 系统作为持久事实源。
  5. 将 ECC 2.0 视为通往原生操作员 shell 的路径，而不是一个成品。

决策规则

在审查 Hermes 或 OpenClaw 产物时，请询问：

  1. 这是可跨操作员复用，还是仅个人使用？
  2. 该资产主要是知识、流程，还是运行时行为？
  3. 它应该成为：
  4. 一个技能
  5. 一个命令
  6. 一个钩子
  7. 一个文档/示例
  8. 一个控制平面问题
  9. 公开发布它是否会泄露密钥、私有数据集或个人操作状态？

只发布可复用部分。

本页原文 Markdown：在 AtomGit 查看·内容源自开源项目 ev/ECC