该方案让Agent在工作节点崩溃、长时间等待审核时保留执行进度并维持策略一致性，官方测试套件含21个通过用例。
AI解读：为什么这条新闻重要？构建需要等待人工审核的长期运行Agent时，最大的问题是工作进程崩溃后如何恢复已完成的工具调用和模型输出，同时让外部副作用（如数据库写入）在重试时不重复。Databricks这篇博客给出的是一个可直接运行的参考实现：Temporal负责保存每个Agent运行的控制流历史，使新工作节点能从最后一步继续；Lakebase Postgres则存储面向应用的当前状态、证据和审核记录，供界面查询。对在实际项目中实现此类Agent的开发者来说，最直接的收益是明确了分工——Temporal管执行恢复，Lakebase管状态查询，Unity Catalog管策略，三者通过确定性ID和幂等写入衔接。但这是参考架构而非生产方案，测试仅在禁用Lakebase的本地崩溃练习中验证了Temporal恢复，Change Data Feed仍需在目标环境启用和验证，贷款审核用例也使用模拟数据。想参考的团队应先把这套模式映射到自身业务场景，再评估21个测试能否覆盖自己的故障模式。
Databricks发布一篇技术博客，介绍一个可运行的个人贷款审批Agent参考实现，名为Temporal Lakebase AgentWorkflow。它结合Temporal的持久执行与Lakebase Postgres的可查询运行状态，解决云端Agent生命周期超过发起它的请求或进程、需要在工作节点替换后继续运行并保留已完成工作的问题。文中给出的实现背景是：一个贷款审批Agent需要收集证据、应用策略并等待人工审核员，审核可能等待数天，期间可能出现工作节点重启或工具调用失败。
架构分工与数据流
该实现将三种存储用于不同目的：Temporal的Event History驱动重放，Lakebase Postgres存储面向应用的视图（运行状态、消息、证据、审核状态和指标），Unity Catalog作为策略源，通过连续同步表将策略提供给运行中的Agent，Change Data Feed则可将运行历史发布回Unity Catalog托管的Delta历史表。博客强调，这两个系统不共享事务，Lakebase写入以Temporal Activity形式在至少一次执行语义下运行，通过确定性标识符、约束和Postgres upsert确保重试指向同一逻辑记录。
- Agent运行流程：FastAPI启动Workflow，Worker调度Activities并记录结果，Agent进入AWAITING_REVIEW状态后等待审核员通过Signal发送决定；批准或拒绝则关闭运行，请求更多信息则继续Agent循环。
- Lakebase包含两个模式：agent_ops存运行状态等应用数据，agent_policy存只读同步策略。
- Unity Catalog是审核阈值的源头，阈值更新后通过同步管道传播，运行中的Agent可在不重新部署代码的情况下读到新策略。
故障恢复与幂等性测试结果
文中测试套件包含21个通过测试，覆盖Workflow顺序、审核行为、OAuth连接构造、幂等持久化、指标契约、API Workflow启动和Worker设置。本地崩溃恢复脚本在Lakebase禁用的情况下运行，以隔离验证Temporal的恢复能力。此外，Change Data Feed功能目前处于Public Preview，每约15秒刷新一次变更，但博客明确说明，仓库配置了源schema但并未包含端到端的Change Data Feed运行，启用和验证仍是部署步骤。
- 申请人数据为模拟数据，用例不验证贷款模型、合规性、生产安全控制、区域可用性或规模性能。
- 测试针对的场景包括：工具调用完成后Worker崩溃、已提交的Lakebase写入丢失Activity完成、审核开放数天、过时浏览器决定以及执行期间策略变更。