生产环境的 LLM Agent 为什么会出错？
大多数人的回答是：模型不够好、prompt 没写好、工具调用有 bug。
这篇论文给了一个不同的视角：问题可能出在随机模型输出和确定性系统之间的边界上——而这个边界之前从未被当作一个正式的结构化对象来处理。
SDB：随机-确定性边界
作者给这个边界起了个名字：Stochastic-Deterministic Boundary（SDB）。
它是一个四部分契约：
- Proposer（提议者）：LLM 生成候选输出
- Verifier（验证者）：检查输出是否符合约束
- Commit step（提交步骤）：将验证通过的输出转为系统动作
- Reject signal（拒绝信号）：输出不通过时怎么处理
这四个部分定义了 LLM 输出如何变成系统行动。论文认为，SDB 是生产 Agent 运行时里最关键的原始构件。
六种运行时模式
围绕 SDB，作者把 Agent 运行时设计归纳为三个关注点：协调（Coordination）、状态（State）、控制（Control）。
然后从分布式系统中借来了六种模式，每一种对应不同场景：
- 层级委派（Hierarchical Delegation）：适合对话式 Agent
- Scatter-Gather + Saga：适合需要并行子任务再汇总的场景
- 事件驱动序列化（Event-Driven Sequencing）：适合异步任务流
- 共享状态机（Shared State Machine）：适合多 Agent 协作
- Supervisor + Gate：适合自主 Agent
- Human-in-the-Loop：适合关键决策需要人工审核的场景
每种模式都能追溯到经典分布式系统概念，但论文指出了当 worker 变成随机的（LLM）时，什么变了。
一个关键的失败模式：Replay Divergence
论文提出了一个我之前没见过的失败模式：Replay Divergence（回放分歧）。
场景是这样的：你用确定性事件日志记录 Agent 的所有输入输出。后来换了模型版本或改了 prompt，再用同样的事件日志回放——下游输出不一样了。
这在传统分布式系统里不会发生。但在 LLM Agent 里，这是必然的。因为 LLM 是随机的，同样的输入可能产生不同的输出。
论文把这个问题正式命名了，这对调试和审计很重要。
对实际开发的启示
如果你在生产环境中跑 Agent：
- 明确你的 SDB 长什么样。别把 LLM 输出直接塞进系统流程。定义清楚：谁提议、谁验证、通过怎么提交、不通过怎么回退。
- 模式选择比模型选择更重要。论文说得很直白——随着模型方差降低，模式选择和 SDB 强度会成为长期可靠性的更重要的杠杆。
- 做失败诊断时有框架可用。论文提供了一个五步方法论和诊断流程，可以把生产失败映射到对应的模式弱点。
这篇论文的价值在于它第一次把 Agent 运行时的架构问题从"经验主义"提升到了"方法论"的层面。不再靠"多试几次就知道怎么设计了"，而是有一个可以遵循的框架。
论文：A Methodology for Selecting and Composing Runtime Architecture Patterns for Production LLM Agents 代码：GitHub