个人贷款承销是一个天然的持久化代理场景：同一运行流程既要收集征信、收入等证据，又要按政策评估，并在休息或外部系统等待时接受人工审核。由于云端工作节点随时可能重启，简单的请求-响应链路无法保证进度不丢失。Databricks 的参考实现借用 Temporal 负责执行控制流，Lakebase Postgres 承载面向应用的可查询状态，从而把“已完成的工作”和“接下来该做什么”分开保存。
Temporal 的核心是 Workflow 事件历史。Workflow 代表一次代理运行的确定性控制流；Activity 是对模型、工具或数据库的调用，调用结果记录在事件历史中并可重试；Signal 则向运行中的 Workflow 发送异步指令，例如审核人的决定。发生故障时，新的工作节点通过回放事件历史重建状态，已记录的 Activity 结果不会再次执行，而未完成记录的调用仍可能再次触发。因此，模型调用、工具调用与数据库写入分别设置了不同重试策略，避免副作用被无限放大。
Lakebase Postgres 不替代 Temporal，而是保存应用视图。agent_ops 中的表记录运行状态、消息、工具调用、审核意见、事件和指标；agent_policy 则是从 Unity Catalog 同步来的只读策略表。由于二者的写入不共享事务，活动代码需要定义“重复执行也安全”的契约。参考实现采用确定性 ID（run_id、message_id、tool_call_id、review_id 等）作为主键或唯一约束，并用 upsert 与守卫更新来确保重试落到同一逻辑行。例如把工具状态写回 started 时，只有当前状态非终态才允许更新；若该行已经 succeeded 或 failed，PostgreSQL 会更新零行而不是报错。不过生产者代码需要检查受影响行数，并把零行结果分类为预期 no-op 或冲突，这也是生产系统必须注意的边界。
架构上，React 与 FastAPI 负责 UI、API 和启动 Workflow，Temporal Cloud 保存事件历史并调度任务，工作人员执行回放与各类 Activity。承销政策以 Unity Catalog 为源，通过连续同步表进入 Lakebase；当写入 agent_ops 后，若开启 Lakebase Change Data Feed，还可把运行证据、推荐、审核决定与指标发布回 Unity Catalog 管理的 Delta 历史表，为审计和分析提供统一通道。
作者认为，这种组合最适用于需要跨工作节点存活、长时间等待人工输入、向应用暴露关系型状态并在运行期间应用治理数据的代理场景。Temporal 决定何时重试，而每个有副作用的工具或数据库必须自己定义如何处理同一个重试——这正是构建可靠云代理的关键。