個人貸款承銷是一個天然的持久化代理場景：同一運行流程既要收集徵信、收入等證據，又要按政策評估，並在休息或外部系統等待時接受人工審核。由於雲端工作節點隨時可能重啓，簡單的請求-響應鏈路無法保證進度不丟失。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 決定何時重試，而每個有副作用的工具或數據庫必須自己定義如何處理同一個重試——這正是構建可靠雲代理的關鍵。