Resonate Durable Execution 深度调研

Codex 核验（2026-10-09）：Resonate 仓库现为 Rust 主体、Apache-2.0，最近推送 2026-10-04。Durable execution 记录进度并恢复运行，不自动使多步骤及外部 API 副作用组成原子事务；重试操作仍需幂等或补偿。可执行形式规范不等于整个实现已形式化证明。Temporal 使用普通 SDK 代码，也可用开发服务器或云服务，不能笼统说必须自管集群/DSL。WSL兼容及本地性能未实测。

与 Eventide 架构整合可行性评估 调研时间: 2026-07-15

一、Resonate 是什么

Resonate 是一个 Durable Execution（持久化执行）框架，核心理念是 “Distributed Async Await”——一个函数可以运行几分钟、几小时甚至几天，即使进程重启也能从上次中断点继续执行。

1.1 核心抽象：Generator 函数模型

function* countdown(context: Context, count: number, delay: number) {
  for (let i = count; i > 0; i--) {
    // 执行一个步骤，持久化其结果
    yield* context.run((ctx: Context) => console.log(`Countdown: ${i}`));
    // 休眠——进程重启后自动恢复
    yield* context.sleep(delay * 1000);
  }
  console.log("Done!");
}

关键点：

• yield* context.run() — 执行一个不可中断的步骤，结果被 journaled
• yield* context.sleep() — 休眠，即使进程在此期间重启也不会丢失
• Generator 的 yield 点是天然的检查点（checkpoint）
• 重启后 Server 重放 journal，恢复执行到最新状态

1.2 架构组成

┌────────────────────────────────────────────────────┐
│                  Resonate Server                    │
│  单二进制 (Rust) — Supervisor + Orchestrator         │
│  ├─ HTTP 8001: SDK 注册 / 函数调用 / 状态查询         │
│  ├─ Metrics 9090: Prometheus 可观测性                 │
│  ├─ SQLite/PostgreSQL: 持久化 Promise 和 Task 状态    │
│  └─ 出站 Push: HTTP Callback 到 Worker              │
└────────────────────────┬───────────────────────────┘
                         │ HTTP/SSE Push
      ┌──────────────────┼──────────────────┐
      ▼                  ▼                  ▼
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│ TS SDK       │  │ Python SDK   │  │ Go SDK       │
│ (Worker)     │  │ (Worker)     │  │ (Worker)     │
│ 注册函数      │  │ 注册函数     │  │ 注册函数     │
│ 接收任务      │  │ 接收任务     │  │ 接收任务     │
│ 汇报结果      │  │ 汇报结果     │  │ 汇报结果     │
└──────────────┘  └──────────────┘  └──────────────┘

1.3 协议规范深度

Resonate 的独特之处：它不是简单的开源项目，而是有一份 形式化规范（Lean 4 可执行规格）。这意味着：

• 任何语言实现的 SDK 只要遵循协议就互操作
• 规范有机器可验证的正确性证明
• 三个参考实现（Rust/TS/Python/Go）共用同一规范

1.4 与 Temporal 的对比

二、Eventide 架构回顾

Eventide 三层架构（来自 ai-autonomy-sticky-note-design）：

Layer 1: 生理状态 (Eventide Python Package)
  ├─ 六大周期、七种数值、十八类身体事件
  ├─ 状态影响 Agent 的情绪和主动性
  ├─ 梦境后效联动
  └─ Token 开销 ~350-700/轮

Layer 2: 记忆与知识 (gbrain)
  ├─ 跨 session 持久化记忆
  ├─ 向量搜索 + 知识图谱
  ├─ 便签池 (sticky-notes)
  └─ 自主性决策循环

Layer 3: 主动执行 (Sticky Notes + Cron)
  ├─ 每30min cron 扫描便签池
  ├─ Manas 判断优先级并执行
  ├─ 完成后更新记忆
  └─ 护栏系统（Loop-Engineering 5 条规则）

目前 Phase 0 已完成（自循环验证通过 ✅），Phase 1 聚焦技术落地。

三、整合可行性分析

3.1 架构层匹配度

Resonate 和 Eventide 不是竞争关系。它们在自主性系统中扮演不同层级的角色：

3.2 三种整合场景

场景 A：Resonate 作为 Sticky Note 持久化执行引擎（🟢 最有价值）

现状问题: 如果 sticky note 任务（如本文调研）耗时 >5 分钟且 WSL 进程意外终止，全部工作丢失。

Resonate 方案:

sticky note 触发
  → Resonate durable function 开始执行
  → yield* context.run() 在每个里程碑步骤后保存状态
  → 如果进程崩溃 → 重启后自动从最后一个 yield 点恢复
  → yield* context.sleep() 支持跨重启休眠

收益:

• 长耗时研究任务（30min+）不再怕崩溃
• 可恢复的跨 session 执行
• 每一步都有持久化记录

成本:

• 需要安装 Resonate Server（~10MB binary）
• 需要将任务代码包装为 Generator 函数
• 对于 <5min 的简单任务，不值得用

场景 B：NATS + Resonate 构建多 Agent 可靠工作流（🟡 有价值）

现状: NATS 提供 Agent 间消息传递，但不提供执行耐久性。

方案:

NATS 消息 (比如 `manas:research:topic`)
  → Resonate 工作流函数执行
  → 过程中 yield* 跨多个工具调用
  → 失败时自动重试
  → 完成后通过 NATS 回复结果

收益:

• Agent 崩溃后工作流自动恢复
• 多步骤 Agent 工作流的持久恢复；外部副作用原子性需另行设计
• 与现有 NATS 基础设施互补

场景 C：Resonate Server 替代部分 cron 功能（🟡 有价值）

方案:

• Resonate Schedule（内置调度器）替代部分 cron 定时任务
• 定时触发 durable functions
• 内置 retry policy

收益:

• 定时任务带耐久性
• 自动重试 vs cron 单次执行
• 但功能重叠度高，ROI 不高

3.3 整合局限性

3.4 替代方案：Hatchet

Hatchet（⭐7,373, Postgres-based）是 Resonate 的成熟替代：

• Postgres 后端（我们已有 gbrain PG 实例）
• 功能更全（DAG workflows、cron、visibility）
• 但更重（需要额外进程）
• 参考: 2026-06-17]]

四、架构对比表

五、整合建议路线图

短期（Phase 1 — 不做整合，专注现有能力）

🚫 当前不需要 Resonate。 理由：

1. Phase 0 已验证 cron + sticky notes 循环可工作
2. 当前 sticky note 任务类型简单（调研、阅读、笔记）
3. 引入新基础设施的成本 > 收益

中期（Phase 2 — 按需引入，松耦合）

条件触发:
  当 sticky note 类型 = "调研" 且 预计耗时 > 15min:
    动作:
      1. 如果 Resonate Server 未运行 → 跳过（用现有方式执行）
      2. 如果 Resonate Server 已运行 → 包装为 durable function
      3. 第一个 yield 点放在 "资料收集完成" 后
      4. 第二个 yield 点放在 "分析完成" 后

长期（Phase 3 — 深度融合）

Eventide 状态变化
  → gbrain 知识更新
    → Resonate 触发工作流
      └─ yield* 持久化工具调用
      └─ yield* 持久化等待
      └─ yield* 持久化研究
      └─ 完成 → NATS 通知结果

六、具体技术选型建议

七、关键结论

1. Resonate 和 Eventide 是互补层 — Resonate 提供可恢复的执行骨架，Eventide 提供有感知的决策躯体。没有直接竞争关系。

2. 当前不需要引入 Resonate — Phase 1 专注在已有基础设施上推进。cron + sticky notes + gbrain 对于当前任务类型足够。

3. Resonate 的 killer feature 是持久化 Generator — yield* 点作为天然 checkpoint。这在长耗时调研任务中最有价值。

4. WSL 是个未知数 — Resonate 在 WSL2 上的表现需要实际测试。Rust 二进制理论可以工作，但需要验证。

5. 值得关注但不必急于引入 — 留意 Resonate 的生态发展（目前 ⭐623，早期阶段）。当需要长耗时任务耐久性时，它是合理选择。

关联页面

• resonate-durable-execution — 原始 Resonate 笔记 stub
• ai-autonomy-sticky-note-design — Eventide 三层架构设计
• autonomy-system-build-plan — 自主性系统构建计划
• pippin-digital-being-framework-analysis — Pippin 框架分析（同类参考）
• 2026-06-17]] — Hatchet 调研（替代方案）