@dair_ai: 如果你设计生产级代理系统,这一点很重要。大多数开发者无意中让框架默认值做出了关键的…

X AI KOLs Following 论文

摘要

本文介绍了生产级LLM代理的随机-确定性边界(SDB)概念,并提供了一种选择架构模式的方法,以提高可靠性和性能。

如果你设计生产级代理系统,这一点很重要。 大多数开发者无意中让框架默认值在没有深思熟虑的情况下做出了关键的架构决策。本文展示了如何有意识地选择。 为什么重要?你需要开始对你的架构做出更审慎的决策。 论文:https://arxiv.org/abs/2605.20173 在我们的学院学习构建有效的AI代理:https://academy.dair.ai
查看原文
查看缓存全文

缓存时间: 2026/05/21 15:44

如果你在设计生产环境中的智能体系统,这一点至关重要。

大多数开发者无意中让框架默认设置替他们做了关键的架构决策,而没有深思熟虑。这篇论文展示了如何有意识地做出选择。

为什么重要?你需要开始对你的架构做出更审慎的决定。

论文地址:https://arxiv.org/abs/2605.20173

在我们学院学习如何构建高效的AI智能体:https://academy.dair.ai


一种为生产级LLM智能体选择与组合运行时架构模式的方法论

来源:https://arxiv.org/html/2605.20173 Vasundra Srinivasan
AI架构师,独立研究者
《多模态AI数据工程》(O’Reilly)作者
斯坦福工程学院

(2026年5月)

摘要

生产级大型语言模型(LLM)智能体构建在随机核心之上,其周围是由确定性系统组成的复合体。这种组合是每个生产智能体承载工程负载的表面,但它至今没有一个正式名称。我们提议一个:随机-确定性边界(Stochastic-Deterministic Boundary,SDB),这是一个由提议者、验证者、提交步骤和拒绝信号四部分构成的契约,规定了LLM输出如何转化为系统动作。提议者是LLM。验证者是对提议的确定性检查。提交步骤是接受后的持久写入。拒绝信号是验证失败时返回给提议者的类型化响应。生产智能体框架已经以某种形式实例化SDB:对五个广泛使用的开源框架的审计发现,在21个LLM到动作的调用点中,有19个包含显式的验证者和提交逻辑;对21篇已发布的智能体故障事后分析进行分类,发现15篇(71%)将故障定位到边界的弱点,17篇(81%)中记录的修复措施强化了其四个部分中的一个。命名这个原语让实践者可以围绕它进行显式设计。

围绕SDB,我们组织了生产智能体运行时中三个正交的关注点(协调、状态、控制),以及一个包含六种模式的目录,这些模式在不同的运行时类别中以不同方式组装边界。对于每种模式,我们将其谱系追溯到特定的分布式系统成果(Actor、Saga、日志、工作流网、CAS、监督),指出当工作者变为随机时哪些可以迁移、哪些不能,并论证在其设计空间区域内该模式的必然性。我们提出一个包含决策谓词和书面验证产物的五步选择方法论,以及一个通过故障特征目录将观察到的生产故障映射到特定模式的诊断流程。我们命名了一种边界使其可读的故障模式:回放发散,即基于LLM的确定性事件日志消费者在模型版本变更下产生不同下游输出的情况。

一个风格化的可靠性模型 (y(t) = \mu t + \sigma \xi(t)) 将长期智能体可靠性的两个贡献分离开:(\sigma),来自随机提议者的单次调用方差,随每一代模型更新而压缩;以及 (\mu),架构动量,由模式选择和SDB强度决定,在结构上独立于单次调用的模型质量。随着 (\sigma) 缩小,(\mu) 成为主导杠杆。我们将该方法论端到端应用于五个工作负载,涵盖对话式、自主式和长周期运行时;其中一个工作负载在配套仓库中基于公开的IBM电信客户流失数据集构建为可运行的参考实现。我们最后指出了目录的发现流程准备接纳的下三种模式。

关键词。 LLM智能体,多智能体系统,软件架构方法论,随机-确定性边界,架构动量,回放发散。

1 引言

生产级LLM智能体的失败方式看起来像模型故障,但行为表现却像系统故障。一个工作流进入错误的状态,因为某个事件处理器对过时的提示做出了反应。一个90%的折扣达到了客户手中,因为在提议和写入之间没有策略门控。一个长周期进程丢失了它的位置,因为没人决定真相源是事件日志还是版本化的行。这些都不是模型缺陷。所有这些都是团队在LLM执行推理之前就已经做出的架构选择。

每次调用时模型的能力随着每一代更新大幅提升,单次调用的方差也相应压缩。随着这种压缩的持续,智能体运行时中承载工程负载的表面转向了模型周围的架构:状态如何在暂停期间保持,工作如何拆分和重组,谁在幻觉写入发出之前阻止它。这篇论文关注的就是该架构核心的原语以及围绕它组合起来的模式。

我们的论点。

我们提出随机-确定性边界(Stochastic-Deterministic Boundary, SDB)作为生产智能体运行时中承载负载的原语。SDB是LLM提议成为系统动作的接缝。它是一个四部分契约:提议者(LLM)、验证者(对提议的确定性检查)、提交步骤(接受后的持久写入)以及拒绝信号(验证失败时返回给提议者的类型化响应)。该原语在实现上并不新鲜;生产框架已经在大多数LLM到动作的调用点中内建了验证者和提交逻辑。但该原语在命名和契约上是新的,命名它让从业者能够显式地围绕它设计,而不是通过失败重新发现它。围绕这个原语,我们组织了三个关注点(协调、状态、控制)和一个包含六种模式的目录,这些模式针对不同的运行时类别以不同方式组合边界。这些模式继承了特定的分布式系统成果(Hewitt的Actor模型[12]、Garcia-Molina和Salem的Saga[9]、Lamport的Paxos[18]、Armstrong的Erlang监督[2]、van der Aalst的工作流网[27]、Helland的分布式事务描述[11]以及Kreps的日志描述[17]),并对随机工作者进行了适配。我们精确地建立这些联系,作为SDB的支撑结构,而非核心主张。

为什么现在这很重要。

将生产智能体系统的长期可靠性建模为

(y(t) = \mu t + \sigma \xi(t)),(1)

其中 (y(t)) 是观测到的可靠性,(\sigma) 是来自随机提议者的单次调用方差振幅,(\xi(t)) 是均值为零的噪声,(\mu) 是周围系统的架构动量。动量系数 (\mu) 由模式选择和SDB强度决定(第3、4节),并且在结构上独立于单次调用的模型质量。基础模型改进每一代都会压缩 (\sigma);它们本身不会改变 (\mu)。随着 (\sigma) 缩小,(\mu) 成为聚合可靠性的主导杠杆。显式设计SDB是团队塑造 (\mu) 的方式。

贡献。

本文做出五点贡献。

  1. 提出随机-确定性边界(SDB)作为命名原语,包含四部分契约(提议者、验证者、提交、拒绝),并对五个广泛使用的开源智能体框架如何在21个LLM到动作的调用点实例化它进行了实证编目,以及基于该契约对21篇已发布的智能体故障事后分析进行分类(第2.3节)。
  2. 提出三个正交关注点(协调、状态、控制)的分类法,以及一个包含六种在生产智能体运行时中重复出现的模式的开放目录。对于每种模式,我们将其谱系追溯到特定的分布式系统成果,确定当工作者变为随机时哪些可以迁移、哪些不能,并给出在其设计空间区域内该模式必然性的简短论证(第3节)。
  3. 提出一个五步选择方法论,决策谓词编码为良好建立的系统权衡(事件时间vs处理时间语义、真相源问题、可观测性vs控制权衡)在智能体环境中的投影。输出是一个六行架构决策记录(第4节)。
  4. 提出一个诊断流程,通过故障特征目录将观察到的生产故障映射到特定模式。我们命名了一种边界使其可读的故障模式:回放发散,即基于LLM的确定性事件日志消费者在模型版本变更下产生不同下游输出的情况(第5节)。
  5. 提出一个可靠性分解((\mu t + \sigma \xi(t))),将单次调用方差 (\sigma) 从架构动量 (\mu) 中分离出来,并支持这样一个主张:随着模型压缩 (\sigma),SDB强度和模式选择取代模型选择,成为长期可靠性的主导杠杆(第5.1节)。

我们通过将该方法论端到端应用于五个跨越三种运行时类别的工作负载来验证。其中一个工作负载在配套仓库中基于公开的IBM电信客户流失数据集构建为可运行的参考实现(第6节)。另外四个工作应用(第7节)展示了该方法论对合理不同的工作负载会给出合理不同的答案,其中两个长周期工作负载由于其状态谓词触发方式不同而选择了不同的骨架。最后,我们根据框架本身的发现流程,对领域未来将发现的模式做出三个预测(第8节)。

范围。

本文不涉及检索增强生成、评估框架、模型选择或提示管理。这些都是运行时上游的内容。它们是必要的,但不是本文的主题。本文中的模式是运行时架构性的;它们管的是模型输出与世界状态之间发生的事情。

2 基础:三类运行时、三个关注点、一个原语

该框架建立在一个组织轴和一个实质性原语之上。组织轴是工作负载的运行时类别(一个工作单元持续多久,以及世界在其间是否变化)以及任何生产运行时必须回答的关注点集合(如何拆分和组合工作、如何记住、谁阻止它)。原语是第2.3节定义的随机-确定性边界:LLM提议变为系统动作接缝处的四部分契约。三个关注点位于原语之上。第3节中的模式是生产运行时如何组装它的方式。

2.1 三类运行时

对话式。 工作单元是一个会话。用户在另一端等待。持续时间为秒级。上下文窗口包含整个世界。延迟主导设计。

自主式。 工作单元是一个任务。智能体由某事物触发(webhook、定时运行、队列消息)。持续时间为分钟级。智能体在任务期间无人值守运行。一个队列在运行之间保持状态。

长周期。 工作单元是一个流程。持续时间为小时到天级。多个智能体参与。流程会暂停、恢复,并能容忍重启。世界在流程进行中发生变化。价格变动。产品达到生命周期终点。交易对手在智能体未运行时发信号。

一个生产系统可以同时承载这三种类型。第4节中的方法论针对正在设计的工作负载中占主导地位的类型运行。

2.2 三个关注点及其来源

这三个关注点并非我们的设计选择;它们是从一个随时间运行的系统本质中推导出来的。我们将每个关注点与其正式前身联系起来。

协调。 工作如何拆分和组合。这个关注点由Hewitt的Actor模型[12]命名并形式化,该模型提出计算可以分解为仅通过消息传递通信的自主Actor。Hewitt表明任何并发计算都可以用这种方式表达,并且如何分解、寻址和重组消息的选择是并发系统设计的实质。我们分类法中的协调关注点是将Actor模型分解问题应用于LLM工作者:如何将智能体任务拆分为多个LLM调用,以及如何将答案重新组合起来。

状态。 系统如何记住。这个关注点受CAP定理[4,10]支配:在发生分区的系统中,无法同时拥有完全的一致性和完全的可用性。每个在暂停期间记忆的系统都必须选择其权衡。Stonebraker和Hellerstein在事件时间vs处理时间文献[1]中指出了该选择的第二个轴:状态可以从事件派生(CQRS、事件溯源),也可以作为版本化的行持有(数据库CRUD + CAS)。我们分类法中的状态关注点是其后果:工作负载位于哪个轴上,真相源是什么,以及该真相源如何在变化中存活。

控制。 谁决定运行什么,以及何时停止。这个关注点来源于控制理论:一个在没有外部监督的情况下随时间运行的系统必须满足可观测性(我们可以从输出推断内部状态)和可控性(我们可以通过输入将系统驱动到期望状态)[15]。在非LLM系统中,监督者是代码。在LLM系统中,监督者必须位于LLM的输出与世界之间,因为LLM本身在卡尔曼意义上不可控;其输出是从由训练塑造的分布中采样的样本。Erlang的一对一监督[2]是一个经典实例。策略即代码的门控是另一个。我们分类法中的控制关注点是监督者位于何处及拥有何种权限的选择。

2.3 随机-确定性边界

上述三个关注点并非新问题。每个都在分布式系统工作中有一个成熟的答案,早于LLM,但有一个修改:工作者现在是一个随机组件(LLM),而非确定性组件(函数或服务)。这一单个修改迫使发生结构性变化。确定性组件(门控、状态机谓词、Saga补偿步骤)必须与随机组件(LLM的提议、分类或内容生成)清晰分离。第3节中的模式就是显式指定了这种分离的分布式系统模式。

我们给这种分离一个名称:随机-确定性边界,以下简称SDB。SDB是智能体运行时中LLM提议变为系统动作的接缝。它有四个部分。提议者是LLM的输出,从以上下文为条件的分布中采样。验证者是对提议的确定性检查,表示为模式、策略规则、状态机转换谓词或约束。提交步骤是验证通过后的持久写入(数据库行、事件日志条目、对外部API的调用)。拒绝信号是验证失败时返回给提议者的结构化响应,提供类型化的原因(“方案无效:条款三未满足”、“实体不存在”、“约束违反”),允许LLM调整并重新提议。

我们在五种开源框架(LangGraph、CrewAI、AutoGen、Semantic Kernel、Dify;附录A)中对SDB进行了实证评估。在21个LLM到动作的调用点中,19个包含显式的验证者和提交逻辑结构。剩余的两个——都由LangGraph实现——依赖隐式结构:验证发生在图的遍历规则中,提交发生在节点输出写入聊

相似文章

@djfarrelly: https://x.com/djfarrelly/status/2052779234234380479

X AI KOLs Timeline

本文主张,AI Agent 的开发应基于稳定的执行原语,而非会随新兴编排模式频繁更迭的僵化框架。文章强调,采用持久化步骤、持久状态、并行协调、事件驱动流程以及可观测性设计,可有效避免因最佳实践不断演进而付出的高昂重写代价。

AI Agent开发

Reddit r/AI_Agents

一位开发者讨论了3个Agent的SDR系统中的级联故障,其中幻觉在Agent之间传播,并寻求关于通过人类参与循环或框架切换来提高可靠性的建议。