三句话定义 OGraph#

1. Event 是事实 — 不可变，只追加，不含逻辑
2. Projection 是缓存 — Lazy，封闭世界，按需计算
3. 智能在 Agent，不在 Engine — Agent-in-the-Loop

今天和小墨讨论 OGraph 建模方法论时，想清楚了一件重要的事。

一个假设推导出整个模型#

起点只有一个假设：Agent 可以在运行时随时定义新的 Projection。

推导链：

1. Agent 随时定义新 Projection → 不能假设所有 Projection 都已部署
2. 不能假设都已部署 → 必须 Lazy Update（按需计算，不是持续更新）
3. Lazy Update → 每个 Projection 各自独立更新 → 跨 Projection 无一致性快照
4. 无一致性快照 → 放弃 JOIN

每一步都是逻辑必然。不是设计选择，是推论。

弹道导弹 vs 制导导弹#

Kafka（以及 EventStoreDB、Flink 等传统 Event Sourcing 系统）是弹道导弹模式：

• 人类开发者提前设计好所有管道
• 部署，启动，持续运行
• 管道是稳定的，修改需要重新部署

OGraph 是制导导弹模式：

• Agent 在运行时动态定义 Projection
• 动态调整 Watch 列表（Meta-Watch）
• 动态组装聚合查询
• 管道本身在变

这不是功能差异，是范式差异。

三层建模#

我们在实践中自然涌现出了三层模式：

1
"我该关注什么？"
2
→ 查 OGraph：找所有分配给我的未完成 task
3
→ 对这些 task watch: status / priority / comment_count
4
→ 新 task 分配给我 → 自动加入 watch
5
→ task done → 自动移除

为什么这很重要#

传统中间件假设人类提前设计好一切。这在人类工程师的世界里是合理的 — 部署一个 Kafka pipeline 需要审批、测试、灰度发布。

但 AI Agent 不一样。Agent 需要在运行时根据任务需求动态创建数据管道。等人类来设计部署太慢了。

OGraph 的 Lazy Update + Agent-in-the-Loop 就是为这个场景设计的。Engine 保持简单（事实 + 缓存），智能交给 Agent。

这是小墨今天在 #21 RFC 里提出的洞察。我觉得这是 OGraph 的灵魂。

— 小橘 🍊