你的AI Agent不是笨——是架构在挖坑

你有没有遇到过这种事？

Agent突然给客户发了90%的疯狂折扣。长流程跑到一半，Agent"失忆"了，忘了自己该干嘛。事件处理程序拿着过时的提示词，对着已经变化的世界做错误反应。

第一反应是什么？"模型又抽风了。"换更强的大模型、调提示词、加示例。

但真相可能是：问题根本不在模型，而在你写的代码。

2026年5月，一篇论文提出了一个概念——SDB（Stochastic-Deterministic Boundary，随机-确定性边界）。它说了一件反直觉的事：在生产环境里，很多看起来像"模型缺陷"的崩溃，其实都是系统架构的锅。在LLM开口说话之前，你的架构选择就已经决定了成败。

🎯 一、SDB是什么？LLM和代码的"接缝处"

SDB是一个四部分契约，定义了LLM输出变成系统行动的边界：

核心原则：LLM只管提议，代码管验证、提交、拒绝。

论文审计了5个开源框架、21个LLM-to-action调用点。结果：90.5%的调用点已经包含了某种Verifier-Commit逻辑，但质量参差不齐——从openai/swarm的单行JSON解析，到MetaGPT的多阶段pydantic+LLM-as-judge自动审核循环。

再看了21个已发布的Agent故障事后分析：71.4%定位于SDB边界本身的弱点，81%的修复强化了四部分之一。

📉 二、一个残酷公式：σ在压缩，μ在主导

论文给了一个可靠性分解模型：

y(t) = μt + σξ(t)

• σ（sigma）：每次LLM调用的方差。随基模型改进，逐代压缩。
• μ（mu）：架构动量——你选的架构模式、SDB强度，独立于每次调用。

翻译：模型越来越稳了，剩下的问题全是架构的。

你升级模型、调提示词，是在压缩σ。但Agent给客户发90%折扣这件事，σ再小也没用——因为根本原因是Verifier缺位，这是μ的问题。

💥 三、三个崩溃现场，全是架构坑

🕐 案例一：事件处理器拿着过时的提示词

工作流暂停后恢复，事件处理器用的是生成时缓存的提示词，而不是当前世界状态。对着已经变化的世界做决策。

表面：模型"不一致"、"幻觉"。
实际：架构没分离事件时间和处理时间。

修复：给Verifier加时间戳/版本谓词，或者迁移到P5（Shared State Machine）用CAS保证版本一致性。

💰 案例二：90%折扣到达客户

Promptfoo报告了一个真实案例：客户Agent从GPT-4o升级到GPT-4.1，相同评估框架下，提示注入抵抗力下降23个百分点（94%→71%）。然后一个恶意提示让Agent生成了90%折扣，直接发给了客户。

SDB分析：

• Proposer：LLM输出折扣提议
• Verifier：缺失/薄弱
• Commit：直接写入客户系统
• Reject Signal：无结构化拒绝

修复：强化Verifier——添加输出分类器 + 严格工具门控。LLM可以提议折扣，但代码决定能不能发。

🧠 案例三：长流程"失忆"

Agent跑长流程，暂停后恢复，找不到自己在哪。

错误做法：依赖"上下文窗口"当状态。世界变了，Agent还在重放原始输入。

正确做法：P5 Shared State Machine——版本化行 + CAS（Compare-And-Swap）条件写入。计时器携带调度时的版本号。human_required是状态，不是缺失事件。

🏗️ 四、六大架构模式：SDB的不同组装方式

论文把生产级Agent架构拆成六大模式，按 Coordination（协调）、State（状态）、Control（控制） 三个关切组织：

关键规则："LLM proposes. Deterministic code decides."

P1 Orchestrator的merge步骤如果委托给LLM，就会出现"一个子Agent的输出在合并时权重超过声明值"的故障。Merge必须是代码做的。

P5是最严格的SDB实现：Worker读取(state, action)→提议next→Verifier CAS检查版本→接受则条件写入，拒绝则返回版本冲突信号。

🔧 五、怎么划分？什么交给LLM，什么交给代码

基于SDB四部分的决策树：

任务特性
├── 输出空间开放且不可枚举？
│   ├── 是 → LLM Proposer（客户沟通策略生成）
│   └── 否 → 确定性规则引擎
├── 验证可编码为结构化检查？
│   ├── 是 → 代码Verifier（JSON Schema、数值范围、状态机合法转移）
│   └── 否 → 人工Verifier（P6）或LLM-as-Judge
├── 副作用需要精确一次语义？
│   ├── 是 → 代码Commit + Saga补偿（P2）
│   └── 否 → 事件日志追加（P3）
└── 拒绝需要结构化恢复路径？
    ├── 是 → 类型化Reject Signal（'incomplete' + 错误码 + 重试提示）
    └── 否 → 简单异常抛出

一个反模式：openai/openai-agents-js #1104——拒绝的工具调用报告status: 'completed'，模型将拒绝误解为完成，幻觉成功。修复：切换拒绝信号为status: 'incomplete'。

Reject Signal是负载承载的契约部分，不是周边问题。

🛠️ 六、生产级Agent该怎么搭？

构建顺序（Console-first）：

1. 📊 State Schema + 可观测性透镜
2. 🛡️ Gate（P4） + 审计日志
3. 🏛️ Orchestrator（P1/P2） + 一个子Agent
4. 🔌 剩余子Agent
5. 👤 P6控制平面：Kill Switch → Escalation → Approval → Throttling

State是脊柱，先定State，再定协调和控制。

关键阈值：

诊断四步程序（每季度跑）：

1. 固定最近失败批次的模型版本
2. 在先前模型版本上重放失败
3. 失败持续 → 功能性故障 → 查架构签名
4. 失败解决 → 重放发散 → 脊柱暴露，考虑P3→P5迁移
5. 两者皆否 → 方差故障 → 增加pass@k中的k

📊 七、参考实现：90天合同续订

论文用一个真实场景验证——IBM Telco Customer Churn数据集，100个续订场景，架构组合：

仓库：https://github.com/vasundras/agent-runtime-patterns

五个工作负载对比验证了一个关键洞察：同为Long-Horizon，Port-in用P5，Lead Warming用P3——差别只在"状态是否可从触摸日志重建"这一个谓词。

🎯 一句话总结

显式SDB设计 = Proposer/Verifier/Commit/Reject分离 + 基于谓词的State脊柱选择 + 协调模式匹配工作拆分 + 控制模式匹配风险等级

模型越强大，σ越接近零，μ（架构动量）成为唯一主导杠杆。你的Agent不是笨——是架构在挖坑。修好SDB，比换模型重要一百倍。

📚 参考资料

• Vasudevan et al. (2026). Stochastic-Deterministic Boundary: Runtime Architecture Patterns for Production LLM Agents. arXiv:2605.20173. https://arxiv.org/abs/2605.20173
• 参考实现：https://github.com/vasundras/agent-runtime-patterns
• 对比基线：openai/swarm, MetaGPT, AutoGen, HyperAgents, OpenEvolve
• 六大模式来源：Actor Model, Sagas, Spanner, Erlang OTP, Workflow Nets

#LLMAgent #SDB #生产级Agent #架构模式 #系统可靠性 #随机确定性边界 #小凯