Databricks 展示如何利用 Temporal 和 Lakebase 构建持久化 Agent，但演示也暴露了难点所在

Databricks 于 9 月 8 日发布了一项参考实现，展示即便面临工作进程崩溃、重试和持续数日的人工审核，如何利用 Temporal 和 Lakebase 构建持久化 Agent。该系统将这一架构应用于个人贷款承保场景，因为遗漏任何一项已完成的核查，都可能破坏决策链路。

关键变化并非又一个 Agent 框架或更大的模型。Databricks 和 Temporal 将 Agent 状态分配到两个职责不同的系统中：Temporal 保留控制流，Lakebase 则提供应用程序、审核人员和分析师可以查询的运营数据。

这种分工也带来了核心张力。持久化执行可以恢复已记录的工作，但无法让每项外部影响都恰好执行一次。应用仍需要稳定标识符、受保护的数据库写入、策略版本规则，以及在组件之间出现不一致时的对账机制。

Databricks 将 Agent 持久性变为可测试的系统

该参考实现将 Agent 视为长期运行的业务流程，而非临时聊天会话。

这项参考实现跟踪一笔贷款申请，从证据收集一直到人工决策。其 Agent 将信用、收入、债务收入比和承保策略核查作为独立操作执行。

该示例使用模拟的申请人和服务提供方，因此并不处理真实贷款申请。这一选择让实验聚焦于执行行为，而非贷款模型的表现。

一名示例申请人的信用评分为 665 分，并有一项非重大逾期标记。Agent 收集证据、评估针对特定用途的策略阈值，并生成建议，但无法作出最终贷款决定。

承保人员必须选择批准、拒绝或要求补充信息。最后一种选择会将同一案件延续至下一轮 Agent 处理，同时保留此前的证据和审核理由。

该场景刻意设计得比单次模型请求更复杂。多个核查完成后，工作进程仍可能停止。数据库写入可能在完成结果传达给 Temporal 之前提交。审核人员也可能让案件保持开放数日。

过期的浏览器还可能在案件已推进后提交旧命令。与此同时，承保策略可能发生变化，却没有相应的应用部署。

这些情况带来六项实际要求：恢复、受控重试、持久等待、运营可见性、运行时治理和审计历史。仅凭一份对话记录无法满足这些要求。

对话记录保存消息，但未必包含完整控制流。它不会自动显示哪项操作已完成、哪个结果被接受，或哪条命令推进了流程。

因此，该实现为每次贷款处理分配一个 Temporal Workflow。Workflow 是一种持久化控制流，其记录的历史使另一工作进程能够重建状态。

对模型、数据库和承保工具的调用则作为 Activities 运行。Activity 是一种可重试操作，其结果可以记录在 Workflow 的 Event History 中。

审核人员的回复以 Signals 的形式到达，即发送给开放 Workflow 的异步命令。Temporal 可以保留这种等待，而无需为期数日地占用一个工作进程。

React 和 FastAPI 负责面向用户的应用层：启动处理、展示证据、列出案件并提交审核决定。Temporal Cloud 存储执行历史并将任务分派给工作进程。

Lakebase Postgres 保存面向应用的投影。投影是当前工作流状态的可查询表示，由执行期间产生的更新构建而成。

Unity Catalog 仍是承保规则的来源。持续同步表会让这些规则可通过 Lakebase 获取，因此工作进程无需代码部署即可读取更新后的策略。

该架构使 Agent 的故障行为可见且可复现。它将持久性从笼统的承诺转化为一组具体的恢复和一致性契约。

不过，该演示并未将这些契约合并到同一个数据库中。Temporal 和 Lakebase 仍是独立系统，两者之间的间隙引出了更棘手的工程问题。

Agent 记忆并不等同于执行状态

持久化 Agent 需要关于控制流的已记录决策，而不只是已保存的消息或检索到的记忆。

许多 Agent 系统将持久化描述为记忆：保存对话、检索早期文档，或将中间结果放入数据库。这些能力有助于模型恢复上下文，但不能重建执行过程。

假设某个工作进程完成信用核查后退出。接替它的进程必须确定结果是否已记录、再次尝试是否安全，以及下一步应运行哪项操作。

这是一个控制流问题，其中包括已调度的 Activities、已完成结果、计时器、已接受的人工命令、重试次数以及当前审核轮次。

Temporal 将这些信息存储在有序的 Event History 中。重放时，工作流代码会消费这些已记录事件，并重建证据、Token 用量和审核状态等变量。

已记录的 Activity 结果会在重放期间返回，而不是再次执行。因此，已完成的信用核查或已记录的模型响应，在该工作流执行中保持固定。

未记录的完成则属于另一种情况。模型服务提供方可能在工作进程失去连接前刚好处理完请求。如果 Temporal 从未收到结果，它可以安排再次尝试。

这一限制很重要，因为模型调用既不一定没有副作用，也无法保证确定性。即使输入完全相同，第二次响应也可能与第一次不同。

该演示为不同操作类型设置了独立的重试策略。模型 Activities 在三分钟的 schedule-to-close 窗口内最多允许尝试四次。

工具 Activities 最多允许尝试三次，start-to-close 超时为 60 秒。Lakebase Activities 最多允许尝试五次，start-to-close 超时为 15 秒。

这些数字描述的是示例配置，而非通用的生产默认值。团队必须根据服务提供方行为、延迟目标、故障模式和下游影响设置重试限制。

Temporal 的持久化执行模型通过保留重放所需的历史记录来解决流程恢复问题。它不会自动让付款、电子邮件、数据库变更或模型请求可以安全地重复执行。

每项外部操作都需要幂等性契约。幂等性意味着重复尝试会收敛到一个预期结果，而不是产生重复影响。

贷款演示通过确定性标识符构建这一契约。一次处理、消息、工具调用、事件、审核轮次和审核决定，都会获得稳定的身份标识。

Postgres 主键和唯一约束可防止重试创建无限副本。Upsert 允许重复尝试定位到同一逻辑行。

受保护的更新再增加一层保障。它们只允许有效的状态转换，例如将待处理的工具调用推进至完成，而不会重新打开已终结的记录。

但即便是受保护的更新，也需要谨慎解读。当目标已进入终结状态时，PostgreSQL 可以影响零行而不抛出错误。

Databricks 的文章承认，当前的 Activity 包装器并不总会将这种零行结果转化为失败。生产代码应在将其视为无害前检查已存储的状态。

这一细节将一项有用的工程参考与成熟的生产模式区分开来。持久化编排提供恢复机制，但应用开发者仍需定义安全的业务语义。

同样的原则也适用于承保以外的领域。支付服务提供方需要幂等键，电子邮件系统需要稳定的消息标识符，不受支持的工具则需要对账记录。

构建内部 Agent 的团队还需要一个可搜索的证据层。结构化的工程知识库可帮助人们查阅这些工作流相关的文档、决策和技术上下文。

更大的教训很明确：记忆帮助模型记住，而持久化执行帮助系统持续运行。生产级 Agent 通常两者都需要，但二者不可互换。

通过职责分离，利用 Temporal 和 Lakebase 构建持久化 Agent

这一设计之所以有效，是因为 Temporal 和 Lakebase 为不同使用者承载了不同类型的事实。

Temporal 负责执行事实。其历史记录决定哪些任务已完成、哪些计时器已触发、哪些 Signals 已到达，以及重放中的工作进程下一步应做什么。

Lakebase 负责当前应用视图。它在关系表中存储处理状态、消息、工具证据、审核记录、运营事件、建议元数据和重试指标。

这种分工让用户界面能通过常规 SQL 模式查询当前案件。审核人员可以找到待处理案件、检查某一项建议，或比较不同执行过程中的运营指标。

证据会在 Workflow 结束前出现。策略查询完成后，结构化结果会连同阈值、实际值、规则结果、依据和策略来源一并提供。

这对人工审核系统至关重要。审核人员不应等到整个流程完成后，才能看到建议背后的证据。

该应用使用两个 Lakebase schema。agent_ops schema 保存运营记录，而 agent_policy 包含受治理承保策略的只读副本。

每个 Activity 都使用与 Workflow 对齐的标识符写入行记录。因此，重试可以更新同一逻辑记录，同时数据库投影逐步追上。

Lakebase 不会成为 Temporal 重放的一部分。这一边界可防止普通应用查询决定工作流执行，但也意味着更新无法跨两个系统实现原子性。

Temporal 事件可以在 Lakebase 投影暂时滞后时已被记录。数据库写入也可能在 Temporal 记录对应 Activity 完成之前提交。

该架构接受这一间隙，并采用最终一致性。最终一致性意味着不同视图可能短暂不一致，但会通过重试和确定性写入收敛。

这对于仪表盘和案件列表而言是合理的设计。当数据库视图被用于验证影响业务状态的命令时，则需要更加谨慎。

Lakebase 提供熟悉的 Postgres 访问方式和面向应用的索引。其运营数据库模型也支持 Agent 记忆、当前状态和特征服务工作负载。

其计算资源可以在设定限制内自动扩缩容。缩容至零可以暂停空闲计算资源，但在闲置后首次查询时可能出现激活延迟。

这些数据库特性有助于应对不均衡的 Agent 流量，但无法消除容量规划、连接限制、连接池配置或恢复测试的需求。

策略路径同样重要。Unity Catalog 存储特定用途的阈值，包括信用评分和债务收入比规则。持续同步的表会将这些值呈现在 Lakebase 中。

策略负责人可以更新源数据，而无需重新部署 worker 或 API。后续查询可以从 Postgres 读取已传播的规则。

这样可避免将每一项业务阈值硬编码进应用程序。与此同时，它也引入了一个编排层必须明确回答的策略时效问题。

进行中的案件应保留启动时适用的规则，还是应在后续轮次采用更新后的策略？两种选择都会影响一致性、可审计性和客户待遇。

该演示会将所应用的阈值及其来源与建议一并记录。这些证据让审查人员能够还原某个具体结果依据的是哪项策略。

当 Lakebase 不可用时，示例可以使用固定策略，并记录这一回退路径。文章正确指出，受监管的工作流可能会选择故障闭合。

这一选择不能交给重试库来决定。产品负责人、合规团队和工程师必须界定：过期或回退策略在法律和运营层面是否可以接受。

建议的数据回传路径使用 Lakebase Change Data Feed。启用后，它可以捕获数据库变更，并将其发布到由 Unity Catalog 管理的 Delta 历史表中。

Databricks 表示，该数据源大约每 15 秒批量处理一次变更。这一间隔适合回溯审计与分析，而应用程序则直接从 Lakebase 读取当前状态。

不过，该仓库仅为这一路径准备了架构。它并未包含目标环境中已实际观察到的端到端数据源运行结果。

因此，使用 Temporal 和 Lakebase 构建持久型智能体需要明确划分三条边界：执行事实、运营事实，以及受治理的分析历史。

当这些边界清晰明确时，这一模式就很有价值；当团队以为“持久”意味着每个组件始终保持一致时，它就会变得危险。

人工审核揭示了一致性权衡

承保人等待环节表明，持久性必须包括命令身份识别、过期状态拒绝，以及独立的工作流验证。

模型生成建议后，Workflow 会根据运行实例和当前轮次创建审核标识符。它会在 Lakebase 中记录待处理审核，并进入 AWAITING_REVIEW 状态。

随后，Temporal 会等待条件满足，而不会持续占用 worker。即使人工审核员需要较长时间响应，处于开放状态的 Workflow 也能在进程替换后继续存活。

API 接受批准、拒绝或要求补充信息的请求。它首先检查 Lakebase 是否仍将相关审核显示为待处理状态。

它还会将提交的审核标识符与当前审核轮次进行比较。不匹配时会产生冲突，而不是转发明显过期的决定。

这一数据库预检改善了用户体验，但它并不具备权威性。Lakebase 投影可能落后于 Temporal，尤其是在 Activity 重试期间。

因此，API 会将命令作为 Signal 发送，而 Workflow 会再次根据执行状态验证该命令。重复或过期的决定会在持久化控制流中被忽略。

第二次检查至关重要。一个浏览器标签页可能在另一位审核员推进案件时仍保持打开状态，或者较早发出的请求可能在新一轮审核开始后才到达。

HTTP 202 响应只确认 Temporal 已收到 Signal，并不代表 Workflow 已接受该业务决定。

客户端必须刷新 Lakebase 视图，才能观察到最终状态。这一区别避免将传输确认误认为贷款获批。

当 Workflow 接受某项决定后，一个具备幂等性的 Lakebase Activity 会将其持久化。批准或拒绝会结束本次运行。

要求补充信息则会恢复执行。审核员的理由会成为新的用户消息，轮次随之推进，下一项建议会获得新的审核标识符。

这一机制为每轮审核提供了稳定边界。它也让核心权衡变得清晰：响应迅速的应用状态与权威执行状态是彼此分离的。

团队必须针对临时性不一致进行设计。界面应清晰传达待处理命令、冲突、投影延迟和被拒绝的过期操作。

运营仪表板也需要区分有意等待与故障。等待承保人的案件是健康的，而在重试中卡住的 Activity 则需要干预。

该演示在 Workflow、轮次和 Activity 尝试级别公开指标。运营人员可以分别检查 Temporal 历史记录、查询 Lakebase 状态，并查看 worker 环境。

这种分离有助于诊断延迟究竟来自人工审核、模型可用性、数据库认证，还是工具调用失败。

但它也增加了运营复杂度。团队必须监控 Temporal、Lakebase、worker 部署、连接池、同步作业，以及将它们连接起来的各项契约。

认证带来了另一项长期运行的关注点。Lakebase 客户端使用机器对机器 OAuth，并会在临时数据库凭据过期前刷新连接池。

如果没有凭据轮换，即使 Workflow 本身可恢复，worker 仍可能按可预测的时间表发生故障。持久化控制流并不能让已过期的连接重新可用。

因此，比较持久型智能体框架的开发者不应只关注检查点支持。他们还应了解命令如何被识别、副作用如何去重，以及权威状态存放在哪里。

他们还应有意测试过期交互。打开两个审核会话，推进其中一个，然后再提交较早的决定。

正确的实现应拒绝该命令，或安全地忽略它。之后，它还应保留足够证据来解释结果。

贷款示例之所以有用，是因为它将这些细节与一项具有重大影响的决定联系起来。人工批准并不是模型调用之间装饰性的暂停。

它是一项包含身份、授权、策略上下文和审计要求的状态转换。与对话助手在错误后重启相比，这使其成为更严格的持久性测试。

该演示并未证明已具备生产就绪性

Databricks 展示了一种可信的架构，但其自身证据仍未解决贷款合规性、规模化以及完整数据闭环验证问题。

该仓库报告有 21 项通过的测试，覆盖工作流时序、审核行为、OAuth 构造、幂等持久化、指标契约、API 启动和 worker 设置。

一项崩溃恢复测试使用确定性 provider。它停止 worker 执行，并验证进程恢复后已记录的进度仍然存在。

这些测试支持了较为狭义的持久性主张。它们表明，该示例的控制流和持久化契约在特定故障下会按预期运行。

但它们并未将该智能体验证为贷款系统。申请人记录和 provider 响应均为固定数据，而默认的脚本化 provider 避免了对实时模型的依赖。

该仓库并未证明贷款模型质量、监管合规性、生产安全性、区域可用性或大规模性能。Databricks 直接说明了这些限制。

本地崩溃测试同样是在禁用 Lakebase 的情况下运行。它隔离了 Temporal 恢复能力，但并未验证完整集成数据路径上的恢复能力。

同样，Change Data Feed 路径仍是一项启用和部署工作。示例准备了相关表，但没有展示端到端实际到达的历史记录。

文章发布时，Change Data Feed 仍处于 Public Preview。对于需要成熟支持承诺或经验证区域覆盖的团队而言，预览状态至关重要。

数据库和 Workflow 并不共享事务。稳定标识符和重试机制可实现收敛，但团队仍需要针对长期或意外分歧进行对账。

生产级对账流程应定位没有对应投影的 Workflows。它还应检测已提交的数据库影响，但其 Activity 结果从未进入 Event History 的情况。

策略同步同样值得严格审查。后续运行可以在无需部署的情况下使用更新后的策略，但进行中的运行需要一项已记录的策略版本规则。

回退行为带来另一项风险。当 Lakebase 被禁用或策略行不可用时，演示可以替换为固定策略。

这种行为有助于本地开发，但静默回退在许多受监管环境中不可接受。系统会记录该回退，但策略负责人必须决定执行是否应继续。

已发布证据尚未测试性能。智能体工作负载可能产生突发写入、冗长历史记录、大型转录文本和不均衡的审核队列。

Temporal 历史保留、重试量、模型延迟、worker 并发性、数据库连接限制和投影更新都会影响系统行为。

Lakebase 自动扩缩容可以响应需求，但新连接和预热数据仍然重要。缩容至零也可能以唤醒延迟为代价换取闲置效率。

安全要求远不止 TLS 和临时凭据。真实的承保平台需要严格授权、敏感数据控制、保留规则和审计访问边界。

模型的建议同样需要独立治理。记录证据和策略能提升可追溯性，但并不能证明建议公平或准确。

完整评估应测试不利行动推理、缺失证据、相互冲突的 provider 数据、策略变化，以及操纵工具输入的尝试。

它还应测试跨越组件边界的运营事故，例如策略同步不可用、投影延迟、部分凭据轮换和外部 provider 不可用。

因此，这一架构应被理解为具备生产形态，而非已经获得生产认证。这一区别增强了该参考架构的价值，因为它使剩余工作清晰可见。

Databricks 展示了如何在编排、运营存储和受治理数据之间分配责任，但并未消除在真实负载下验证每一项契约的必要性。

三项信号将表明这一模式能否经受考验

接下来的证据应测试集成恢复、策略一致性，以及在受控承保演示之外的采用情况。

第一个信号是一次已观察到的端到端 Change Data Feed 部署。已发布的系统准备了运营表，但尚未完成数据源激活和目标端验证。

成功的验证应追踪一次运行，从工具证据、人工审核一直到由 Unity Catalog 管理的历史记录。它还应记录延迟、重复数据、架构变更，以及中断后的恢复情况。

这一结果将强化运营活动能够回流至受治理分析历史的主张。持续依赖未经验证的路径则会削弱完整数据闭环的叙事。

第二个信号是一次在整个恢复测试中均使用 Lakebase 的公开负载与故障研究。它应涵盖 worker 崩溃、数据库重试、凭据轮换和投影滞后。

有价值的结果应报告完成行为、重试分布、过期命令拒绝情况，以及应用状态实现收敛所需的时间。

这将把架构作为组合系统进行测试，而非孤立验证 Temporal 的恢复能力。它还将揭示扩展限制或运营瓶颈出现的位置。

第三个信号是在真实的人工审核工作流中获得采用。贷款只是一个演示，但理赔处理、采购、安全响应和受监管审批中也存在类似要求。

可信的部署方案应说明如何对策略进行版本管理、协调状态、控制回退行为，并审计人工干预。这些实践比具体采用哪家模型提供商更重要。

此类部署所提供的证据将支持本文的核心判断：可靠的智能体是分布式应用，其故障必须被明确建模。

如果某个部署将持久性简化为对话检查点，则会得出相反的结论。它会将副作用、长时间等待和持续变化的策略排除在恢复契约之外。

对开发者而言，眼下的问题并不是每个智能体是否都需要 Temporal 和 Lakebase。许多短时、只读任务并不值得引入两个托管系统和一层投影层。

真正的问题是：智能体能否在其 worker 终止后继续存活、改变外部状态、等待人员响应，或应用独立变化的策略。这些特征决定了是否需要持久化执行。

如果这正是你的系统，请审视其智能体架构，复现其崩溃测试，并质疑每一个可重试的副作用。随后测试当执行事实与运营事实暂时不一致时会发生什么。

这正是团队尝试使用 Temporal 和 Lakebase 构建可靠智能体时应遵循的实际标准。先从一个影响重大的工作流开始，明确每个系统的权责，并将恢复证据纳入产品评审。