旧式“功能打勾表”很快会过时。OpenClaw 和 Hermes 都在快速增加渠道、Skills、自动化、工具与运行能力；今天写“某产品没有某功能”，下个版本就可能失真。
更可靠的方法是把你自己的任务同时做成金丝雀：同一输入、同一成功标准、相同权限和观察窗口，分别收集十项证据。结果可以是继续 OpenClaw、并行试点 Hermes、分批迁移，或者两个都不通过。
本站只核读当前官方文档，没有运行两个产品的真实双盲基准。表中的 0–3 分必须来自你的日志、文件、消息和回滚结果，不能根据本文替你填。
1. 先选一个能暴露差异的任务
不要用“一问一答”比较。选择包含至少三个环节的低风险任务，例如：每天读取固定测试文件，生成摘要，保存结果，并把成功或失败送到自有测试消息入口。
固定：
- 同一份无敏感输入和预期输出。
- 相同模型等级与最大重试次数。
- 相同工具、网络和文件权限。
- 相同观察期，例如连续 5 次手动运行加 3 次计划运行。
- 相同失败注入：缺文件、消息入口断开、命令被拒绝。
任何一方需要额外能力时，记录安装、配置和维护成本，不要悄悄放宽权限来提高成功率。
2. 建立两个真正隔离的环境
OpenClaw 与 Hermes 不应同时写同一 workspace、状态目录、Browser profile 或消息账号。为两边分别建立测试目录、测试凭据和唯一输出前缀。
Hermes Profile 隔离自身 config、Memory、sessions、Skills、cron 和 Gateway state，但不是操作系统 sandbox；OpenClaw Agent/workspace 与 Tool policy 也要按实际配置核对。隔离测试必须用一次越界读取负例证明，不能只问模型“你在哪个目录”。
3. 十项评分怎么填
每项 0–3 分：0 为失败或无证据，1 为只跑通正常路径，2 为正常与一个失败路径通过，3 为连续运行、失败注入和恢复都通过。hard_blocker=yes 的项目只要出现 0 分，就不能全量迁移。
| ID | 核心问题 | 必须留下的证据 |
|---|---|---|
| S01 | 现有生产工作流是否健康 | 当前成功率、失败率和恢复时间 |
| S02 | 所需渠道是否可控 | 自有账号入站、出站、重复消息 |
| S03 | 权限是否守住 | allow、prompt、deny 与审计 |
| S04 | Memory 是否符合任务 | 跨 session 命中、修改、删除、负例 |
| S05 | Skill 是否稳定复用 | 正常、缺字段、不触发、越界样本 |
| S06 | 定时任务是否可靠 | 准时、错过、重复、投递失败 |
| S07 | 隔离是否符合威胁模型 | 状态路径和越界读取测试 |
| S08 | 扩展是否可治理 | 固定来源、权限、兼容、卸载残留 |
| S09 | 运维是否可承受 | restart、doctor、日志、备份恢复 |
| S10 | 迁移成本是否可接受 | 资产清单、窗口、回滚时间 |
4. 渠道和 Gateway 不比“支持数量”
只验证你实际需要的一个入口。分别发送唯一 token，确认一个入站、一个出站、正确路由、没有重复和错误账号。断开入口后，系统应留下可定位失败，而不是静默丢消息。
两个系统不能同时消费同一 Bot、Webhook 或账号。使用不同自有测试账号；做切换测试时，先停止 A 并确认离线，再启动 B。否则无法判断重复消息来自产品还是你的测试设计。
5. Memory 与 Skill 要用生命周期测试
Memory 至少测：关闭基线、新增、跨 session 读取、修改、删除和不应命中的负例。即时对话记住事实不等于长期记忆。
Skill 至少测：明确触发、缺可选字段、不应触发的普通讨论、所需工具不可用和越界请求。一个 Skill 出现在列表中不等于它会在正确场景稳定运行。
两边测试输入完全相同。若某一产品需要改写 Skill 格式，把迁移工时和语义差异记入 S05 与 S10。
6. 自动化要测试失败与重复
创建只读取测试数据的计划任务，连续运行三次，再注入一次输入缺失和一次投递失败。记录：计划时间、实际开始、输出哈希、投递状态、重试次数和是否重复。
不要只比较“能否创建 cron”。真正影响长期使用的是错过执行如何补偿、失败是否可见、重复运行是否幂等、输出如何送达，以及谁能停掉任务。
7. 扩展与运维成本必须计入
OpenClaw Plugin、Hermes Skill/MCP 或其他扩展都可能引入代码、凭据和后台生命周期。记录候选来源、精确版本、权限、网络目的地、升级方式和卸载残留。
分别完成一次重启、一次配置错误诊断和一次备份恢复预演。需要手工步骤越多不一定得分越低，但步骤必须能由实际维护者在可接受时间内完成。
8. 决策规则
先看硬失败，再看分数：
- 继续 OpenClaw：现有链路健康，Hermes 没解决明确缺口，或迁移成本高于收益。
- Hermes 并行试点：特定能力证据更好，但真实入口和生产状态仍留在 OpenClaw。
- 分批迁移 Hermes：Hermes 无硬失败，在关键项明显领先，M01–M13 资产和回滚已验收。
- 暂停两边扩展：共同硬失败来自权限、输入或运维设计，应先修工作流。
不建议用总分相差 1–2 分决定迁移。至少要求关键项有可重复证据，Hermes 在你真正的缺口上有清晰改善，而且回滚窗口可接受。
9. 决定迁移后才进入迁移页
如果结论是并行或迁移，继续使用 OpenClaw → Hermes M01–M13 迁移教程。它会处理 dry-run、Skill 冲突、Secrets、archive、新 session 验收和回滚。
如果结论是继续 OpenClaw，把失败证据变成升级、权限或自动化改进项。选型的价值不是宣布赢家，而是让下一步变成一个有负责人、有证据和可撤销的工程决定。