#AI
Databricks 用 Temporal 与 Lakebase 拆解长跑 Agent 的状态
Databricks 放出一份可运行的参考实现，把「长跑 agent 的状态」拆成两套系统：**Temporal Cloud 管持久化控制流，Lakebase Postgres 管面向应用的运行态**。
示例选的是个人贷款核保 agent:它要采集征信与收入证据、套用政策、给出建议，然后等核保人拍板 —— 这一等可能就是几天，期间 worker 会重启、工具调用会失败。
💡 为什么值得看长跑 agent 的恢复、重试与审计如何分工，这份参考实现可直接参考。
重试与写入安全
- **确定性与守卫**：每条 Lakebase 记录用稳定标识锚定（run_id / message_id / tool_call_id / review_id 等）,主键与唯一约束 + 守卫式 upsert 让重试命中同一逻辑行，已终态的行写入影响 0 行且不报
- **作者自陈的缺口**：文章明说当前 Activity 包装层没有把「0 行」判为失败，生产代码应先确认终态再决定是当作预期空操作还是抛冲突。
- **重试预算**：模型调用类 Activity 最多 4 次尝试、3 分钟调度超时；工具调用 3 次、60 秒；Lakebase 写入 5 次、15 秒。
示例带具体数字：边界申请人 665 信用分、年收入 7.6 万美元、月债 2400 美元；模型只能建议，批准 / 拒绝 / 补充材料由核保人决定。完整 schema 与代码见原文。
查证
来源档案
Databricks Blog
厂商官方工程博客，发布一份带完整代码与架构图的参考实现（含 React + FastAPI + Temporal Cloud + Lakebase + Unity Catalog）
一手官方来源，架构描述与参数可信；但这是厂商自家技术栈的示范实现，文中也自陈部分生产化处理尚未完成（零行结果未判失败）,不宜当作已上线的生产方案。
延伸阅读
文章把「Temporal 决定何时重试、Activity 决定外部系统如何处理重试」写成一般规则，对要给支付 / 邮件 / 数据库写接重试的人直接可抄。
想评估要不要引入 durable execution 的团队，可看它是怎幺划 Event History 与可查询运行态的边界、以及为此多付了哪些运维成本。