Databricks 简化 AI Agent 编排，但风险如今由 Postgres 承担
Databricks 通过一套生产级设计简化 AI agent 编排，用一个 Lakebase Postgres 数据库取代多项专用服务。7 月 22 日发布的内容介绍了一款由 CLA 构建的审计应用，它可在几分钟内而非数小时内处理文档。这一改进是公司自行报告的结果，但架构上的转变更具意义。
该系统将 Postgres 用于任务队列、重试、调度、成本归因和实时状态更新。Databricks 表示，CLA 不再需要 Kafka 或 Redis 等外部消息代理、Airflow 或 Temporal 等独立调度器，或专用缓存。
这种整合带来了明显的矛盾。专用编排系统通过职责分离来应对复杂故障。Databricks 则将更多这类职责置于一个熟悉的数据库中，在减少基础设施的同时，也让数据库设计成为 agent 可靠性的核心。
Databricks 围绕长时间运行的 Agent 简化技术栈
眼下的变化并非新模型或 agent 框架，而是一种将 Lakebase 视为 agent 工作控制中心的生产模式。
Databricks 与专业服务公司 CLA 为 agent 辅助审计构建了这一系统。审计通常要求员工审阅合同、发票、财务申报文件及支持性文档，然后再提取结构化信息。
该应用通过运行在 Databricks Apps 中的 FastAPI 接口接收 PDF 上传。它将这些文件存储在 Unity Catalog Volumes 中，并将每项提取请求写入 Lakebase。
Lakebase 是 Databricks 托管的 Postgres 服务。其 Postgres 文档介绍了自动扩缩容、数据库分支、只读副本、即时恢复及 Unity Catalog 集成。
两张关系型表构成了运行核心。tasks 表记录每个逻辑任务，包括状态、优先级、租约信息、agent 分配和最终输出。task_attempts 表记录单次执行，包括任务标识符、追踪标识符和成本元数据。
Lakeflow Jobs 执行文档处理工作。每个任务读取已存储的 PDF，调用文档处理组件和模型，然后将结果写回 Lakebase。MLflow 捕获模型调用、token 使用量、延迟和成本信息。
因此，该架构在不引入另一层基础设施的前提下划分了职责。Lakeflow 执行工作，Lakebase 则记录应运行什么、正在运行什么以及已完成什么。
Databricks 表示，这一设计将 CLA 的提取流程从数小时缩短至数分钟，且未降低质量。该公司尚未发布支持这一说法的独立基准测试、工作负载分布或实测错误率。
不过，这次发布并不止于一张宽泛的参考架构图。Databricks 明确指出了运行该设计所需的并发、恢复、限流、回调、可观测性和计费模式。
这些细节至关重要，因为数据库表不会自动成为安全的任务队列。一个基础查询可以选出待处理工作，但多个 worker 可能在任何 worker 更新状态前就选中了同一行。
该设计还必须在进程崩溃后恢复工作，防止重复回调生成重复结果，将模型请求控制在外部配额内，并允许紧急文档绕过批量任务。
编排设计借助事务和成熟的 Postgres 功能解决了这些问题。新闻点并非 Postgres 能够存储 agent 状态，开发者多年来一直在这么做。
更有力的主张是：托管 Postgres 可以成为生产级 agent 工作负载的编排骨干，而无需 Kafka、Redis、Temporal、Airflow 或其他调度器。
真正的压力落在专用基础设施上
Databricks 正在挑战这样一种假设：每个生产级 agent 应用都需要独立的消息代理、调度器、缓存和可观测性技术栈。
Agent 演示通常在单一进程内端到端运行一次请求。生产系统则不同，因为用户会并发提交工作、模型调用会失败，而且单个任务的持续时间难以预测。
Databricks 用两类文档说明这种差异。一张两页的发票可能在数秒内完成，而一份 200 页的合同则可能需要数分钟。Worker 不能假设任务会按提交顺序完成。
模型配额又增加了一项限制。一个端点可能限制每秒请求数、每分钟 token 数量，或同时限制两者。一次性分发数百份文档可能触发限流和反复重试。
应用还必须回答运行层面的问题。团队需要知道哪个任务失败、哪次模型调用消耗了 token、每次尝试花费多少，以及被遗弃的任务是否应再次运行。
传统架构往往将这些关注点交给不同产品。消息代理负责传输任务，工作流引擎管理持久化执行，缓存提供快速状态访问，监控平台汇总状态、延迟和成本。
这种分离能够支持复杂工作流和大型组织，但也引入了额外的凭据、部署流程、仪表盘、故障模式和集成代码。
Databricks 认为，对于彼此独立的长时间运行任务而言，这些开销并不成比例。文档提取符合这一描述，因为一份合同通常不依赖另一份合同的结果。
Lakebase 通过将事务状态放在 Databricks 应用的其他部分旁边，改变了这一计算。相同的平台提供接口、文件、任务、模型追踪、治理控制和计费记录。
这一方法给两类群体带来压力。平台团队必须证明其引入的每项额外服务是否合理，而编排供应商则必须说明，为何其专门保证优于经过良好设计的数据库队列。
这并不意味着专用系统已经过时。例如，Amazon 将 AgentCore Runtime定位为一个提供会话隔离、扩缩容、身份管理和长时间运行 agent 支持的托管环境。
这种方式要求团队采用面向 agent 的专用运行时。Databricks 则从运营数据库出发，将其连接到已用于数据和机器学习工作负载的服务。
因此，这场竞争关乎基础设施边界。Agent 执行应当存在于专用运行时中，还是应由数据库通过持久化关系状态协调常规任务？
Databricks 在现有客户中具备结构性优势。已经使用 Lakeflow、MLflow、Unity Catalog 和 Databricks Apps 的团队，无需引入新的供应商或安全模型即可进行整合。
同样的优势也会造成平台依赖。选择完整模式的公司，会将任务执行、存储、可观测性、治理和成本报告绑定到 Databricks 服务。
对买方而言，“更简单”不能只意味着产品名称更少。它还必须意味着更少的运维任务、更清晰的故障归属、可接受的恢复行为，以及可支持的退出策略。
四种 Postgres 模式让队列更可信
该架构之所以有效，是因为它将熟悉的数据库原语转化为关于并发、恢复、限流和重试的明确保证。
第一种模式是并发安全的出队。Worker 使用 FOR UPDATE SKIP LOCKED 选择符合条件的行，这会锁定已选行，同时允许其他 worker 跳过它们。
PostgreSQL 文档指出，SKIP LOCKED 有助于在多个消费者访问类似队列的表时避免争用。文档也警告，该选项会呈现不一致视图，因此不适用于通用查询。
这种区分体现了该设计的优势。任务表并非用于在出队期间进行任意报表查询。Worker 需要对可用任务获得排他性声明，而无需等待另一 worker 的锁。
查询按优先级降序和创建时间排序。优先级更高的任务先运行，而相同优先级内的任务则保持先进先出顺序。
第二种模式使用会过期的租约。当 worker 领取任务时，它记录的是租约到期时间，而非永久分配所有权。
定期运行的扫描器会将已过期任务重新放回队列。如果 worker 因驱逐、部署、内存错误或进程崩溃而消失，另一 worker 可在数分钟内恢复其任务。
租约解决了被遗弃的工作，但也带来一项要求。应用必须选择超过正常任务时长的过期时间，或在工作持续期间续租。
过早到期的租约会让健康运行的工作看似被遗弃。租约持续过久则会在真实故障发生后延长恢复时间。
第三种模式在分发前控制模型消耗。编排器支持并发任务上限、预估 token 预算，或两者结合。
并发上限会统计当前标记为处理中状态的行。由于数据库保存了这一计数，限制在 worker 重启和多个编排器副本之间仍然可见。
Token 预算会估计每个运行中任务的消耗量。只有在其预估 token 能够满足配置上限时，编排器才会分发另一个任务。
当两种控制同时启用时，更严格的约束优先。这适用于在大量小型发票与少数 token 密集型合同之间交替的工作负载。
第四种模式让回调具备幂等性。幂等性意味着重复同一请求会产生相同的有效结果，而不是重复应用变更。
网络中断和代理可能导致回调多次到达。Databricks 接受针对处理中或已重新入队任务的回调，同时将已完成状态视为无操作。
这种行为降低了重复处理或重复计费的风险。不过，它依赖于稳定的任务标识、谨慎的状态转换，以及包含结果更新的事务边界。
这四种模式结合起来，构成了可信的队列。事务防止并发领取，租约恢复被遗弃的工作，预算限制分发，幂等回调容忍重复投递。
这正是 Databricks 简化 agent 任务队列的方式，但它并未声称仅靠两张表就已足够。应用代码仍负责实现支配每次状态转换的策略。
该机制适合依赖结构相对简单的任务。当工作需要嵌套工作流、补偿操作、人工审批或长串定时事件时，其吸引力便会下降。
专用工作流引擎通常会直接表示这些关系。使用数据库队列时，开发者必须将它们建模为表、状态转换和应用逻辑。
这一权衡应当影响采用决策。团队应因其工作流足够简单而选择这种模式，而不是因为 Postgres 在理论上可以表示所有可能的工作流。
一个数据库连接状态、可见性与成本
该设计最具特色的部分并不是排队，而是决定从同一批任务记录中推导运行可见性和成本归因。
运营人员需要的不只是“已完成”或“失败”的标签。CLA 仪表板展示了已入队、处理中、已完成、失败和已取消任务的数量。
它还呈现输入与输出 token、模型成本、计算成本、中位响应时间，以及每份文档的置信度。筛选条件覆盖时间范围、任务状态和单个 agent。
中位延迟是这类工作负载的实用选择。重试退避和队列饱和可能造成极端延迟，从而扭曲简单平均值。
Postgres LISTEN/NOTIFY 提供实时更新机制。任务状态变化时，数据库触发器会发布事件，应用后端则维持一个监听连接。
后端通过 Server-Sent Events 将这些事件分发到浏览器。SSE 是一种单向 HTTP 流，允许服务器通过持久浏览器连接发送更新。
Databricks 表示，仪表板变更通常会在约一秒内显示。该设计在此路径中不需要 Redis、WebSocket 服务器或消息总线。
系统将轮询保留为永久性降级方案。流式传输不可用时，浏览器每十秒请求一次最新数据。
这一降级方案至关重要，因为云入口代理可能会中断流，而不会产生明确的浏览器错误。仅依赖推送事件的仪表板可能会在无声无息中变得过时。
仪表板整合了刷新速度不同的信息。根据 Databricks 的说法，Postgres 状态可即时更新，而 MLflow trace 数据会在不到一秒内到达。
计费查询可能需要数十秒。因此，应用会在常规刷新期间运行快速状态查询，并将较慢的计费查询留给用户操作触发。
成本归因还需要另一层过滤。Databricks 计费表包含账户范围内的活动，因此原始查询会混合无关作业和应用的支出。
编排器会记录分配给其任务的特定 Databricks Job 运行。计费查询随后会将账户活动过滤到这些标识符。
这使得一个 SQL warehouse 可以支持多个应用，同时每个仪表板只展示自身的工作负载。运营人员还可以按状态、agent 或日期进一步缩小结果范围。
该设计能够支持通用监控常常掩盖的实际问题。团队可以查看七天内失败任务的成本，或比较不同 agent 的中位支出。
任务身份与成本之间的这种关联，不仅与审计有关。AI 应用经常会丢失用户请求、其触发的尝试以及最终模型账单之间的关系。
持久的任务记录为团队提供了稳定的连接键。它将业务意图、执行历史、模型 trace、计算活动和最终输出联系起来。
知识密集型团队在执行后面临一个相关问题。他们需要在可搜索的上下文中保存围绕自动化工作产生的文档、决策和输出。
结构化的工程知识库可以通过保留事件和设计决策背后的人类上下文，补充运行时 trace。
因此，Lakebase 模式的价值不止于减少服务数量。它为每项任务创建了一条统一的运营叙事，从提交、重试到成本和结果。
更简单的基础设施将风险转移到数据库设计中
Databricks 降低了集成开销，但并未消除分布式系统的复杂性。它将这种复杂性转移到了 schema、事务、租约和应用代码中。
“无需外部基础设施”这一说法需要谨慎解读。该应用仍依赖多项 Databricks 服务，包括 Apps、Lakeflow Jobs、MLflow、Unity Catalog Volumes 和 Lakebase。
简化发生在同一个托管平台内部。它并未将架构缩减为一个进程或一项服务。
这种区别在故障期间尤为重要。Lakebase 队列可能在作业服务不可用时仍保持持久性，但应用仍需要针对延迟调度和恢复具备经过测试的行为。
团队还必须明确：当回调成功但周边操作失败时会发生什么。只有当每个副作用都使用一致的标识符和边界时，幂等性才能防止重复投递带来的问题。
速率限制控制同样包含不确定性。预估 token 预算依赖于在模型处理文档前估算其消耗量。
估算可能低估复杂文档，或高估简单文档。低估可能触发供应商限流，而高估则可能让可用模型容量闲置。
已发布的设计没有提供吞吐量结果、队列深度限制、失败率、数据库负载或对比运营数据。它也没有将该实现与专用工作流引擎直接比较。
Databricks 报告称，提取时间从数小时降至数分钟。然而，它未披露文档样本、人工审核流程、准确率指标、模型配置或基线工作流。
读者应将这一结果视为生产客户案例，而非受控基准测试。即使无法证明普适的性能提升，该架构仍可能有用。
Postgres 本身也可能成为争用点。频繁的出队、状态更新、token 预算计算、仪表板读取和计费连接查询，都源于相关的运营记录。
Lakebase 提供自动扩缩的计算能力和独立的持久化存储。这些特性可以减少容量规划工作，但自动扩缩并不能消除低效查询或锁争用。
队列表的增长方式也不同于普通应用表。尝试历史会不断积累，已完成记录对审计仍有价值，而索引必须同时支持实时调度和历史分析。
因此，保留与归档策略也是队列设计的一部分。缺少它们时，运营查询可能逐渐与报表工作负载竞争资源。
安全性同样值得重视。任务表可能包含文档位置、提取结果、置信度评分、agent 分配和执行标识符。
Databricks 表示 Unity Catalog 提供共享身份和权限管理。团队仍必须落实最小权限访问、保护 webhook 端点，并决定哪些运营人员可以查看敏感结果。
数据库分支可以帮助在隔离环境中复现缺陷。但它也可能复制敏感运营数据，因此需要与审计工作负载相匹配的脱敏和访问控制。
更广泛的竞争问题仍未解决。Google 的 AlloyDB AI 也将兼容 PostgreSQL 的基础设施定位为 AI 应用的基础，包括向量搜索和混合搜索。
AWS 则通过托管运行时、记忆、身份和编排服务采取更偏向 agent 的路径。专用工作流系统仍专注于跨复杂流程图的持久执行。
Databricks 已表明 Postgres 可以覆盖一个有意义的中间地带。它尚未证明，以数据库为中心的编排应在所有 agent 工作负载中取代这些系统。
最强的采用案例，是现有 Databricks 平台上的独立、长时间运行任务。最弱的案例，则是具有复杂依赖关系和严格可移植性要求的跨系统工作流。
三个信号将检验 Lakebase 编排方案
下一项检验是，CLA 架构能否成为可重复的生产模式，而非精心设计的客户实现。
第一个信号是文档提取之外的采用情况。Databricks 应发布涉及编码 agent、客户运营、数据修复或研究工作流的案例。
这些工作负载将检验不同的任务规模、依赖结构、工具权限和人工审批要求。类似的结果将强化 Lakebase 是通用 agent 状态存储的主张。
如果未来案例仍局限于独立文档作业，该设计依然会有用。只是其实际适用范围会比更广泛的编排表述所暗示的更窄。
第二个信号是对比性的运营数据。团队需要了解在持续负载下的队列吞吐量、恢复时间、数据库利用率、失败率和调度延迟。
与基于 Redis 的 worker 或持久工作流引擎进行比较将尤其有用。它可以显示，减少集成工作何时能够抵消应用内部额外的状态机逻辑。
透明的数据将强化 Databricks 的简化论点。缺少此类数据，则会让买家只能依赖架构描述和客户报告的结果。
第三个信号是产品化。如今，这一模式依赖应用代码来实现锁定、租约、限流、回调、仪表板流式传输和计费归因。
Databricks 可以将该设计的部分内容转化为模板、托管组件、参考库或内置 Lakebase 功能。这将减少每位客户需要维护的正确性关键代码量。
产品化还将揭示 Databricks 如何定义数据库功能与工作流功能之间的边界。更大的托管层将与 agent 运行时和编排平台展开更直接的竞争。
评估这一模式的团队应从自身的工作流形态开始。具有明确终止状态的独立任务与 CLA 设计高度契合。
随后，他们应在优化吞吐量之前测试故障行为。终止 worker、延迟回调、重复请求、耗尽模型配额，并中断仪表板流。
最后，将运营负担与一种专用替代方案进行比较。统计移除的服务数量，也要统计新增的自定义状态转换、恢复规则、测试和运行手册。
Databricks 简化了围绕 agent 编排的可见基础设施，而 Lakebase 为这一设计提供了可信的事务核心。悬而未决的问题是：你的应用是否足够简单，以至于这种整合能够继续保持简单。
如果是，以数据库为中心的队列可以缩短从原型到可观测生产系统的路径。如果不是，缺失的 broker 或工作流引擎将以应用代码的形式重新出现。正确的下一步是开展一项聚焦故障的试点，使用真实任务规模、真实配额和真实恢复目标。
