Agent 的 SLA、SLO 与生产级可用性工程 2026：从承诺、降级到事后熔断校验的闭环架构

一句话摘要：当 Agent 的输出从"演示"进入生产，SLA 就从工程议题变成商业契约。这篇文章把 SLA 当作一个三层闭环（承诺层、执行层、事后熔断层）来展开，配套 SLO 一等公民、可观测性栈、退路熔断、对账工程与六个必走动作清单。

一、问题的提出：Agent SLA 失约的三类黑洞

把一个 Agent 从 demo 推到生产，最容易在"可用性、延迟、正确性"三个维度同时失约。失约不是模型抽风那么简单，它通常是三类黑洞叠加的结果：

• 承诺层黑洞：SLA 文案漂亮（"99.9% 可用、95% 在 5 秒内返回"），但代码里没有任何"当承诺被打破时，自动告诉用户"的机制。结果用户问"你这个 Agent 是死是活？"，系统反馈给它的全是"未实现"。
• 执行层黑洞：调度器不感知 SLO，模型选择、工具调用、重试策略各自为政。模型路由以"便宜"为目标，不以"在用户容忍时间内给出可验证答案"为目标——结果用户看到的不是"慢了 0.5 秒"，而是"卡了 12 秒"。
• 事后熔断黑洞：事故后才知道出问题了；但出问题时，没有自动留痕、自动看板、自动回滚的依据。事后复盘变成堂吉诃德之战。

这三类黑洞的本质都是契约未落地：契约写在文档里、API 描述里、合同里，但没有哪一行代码把契约当作运行时不可绕过的承诺。文章把 Agent SLA 当作一个**三层闭环：承诺层（语义化建模）→ 执行层（运行时约束）→ 事后熔断层（对账 + 灰度回滚）**来拆，并相应给出工程模式、可观测性栈、踩坑反模式与可操作的工程清单。

截至 2026-07-22，主流 Agent 平台（OpenAI Agents SDK、LangGraph、Claude Agent SDK、AutoGen、CrewAI）仍未把 SLA 作为一等公民——SLA 是写在 README 与计费条款里的话术，而不是写在 RPC header / 调用栈 / 看板上的契约。我们这篇文章要做的，就是把这种"嘴上承诺"翻译成"代码承诺"。

为什么 2026 是 SLA 工程的拐点——三个证据同时出现：(1) 大模型推理成本曲线终于在 2025 Q3 到 2026 Q1 走平，单位 token 价格从两位数年降率变成高个位数月降率，下游开始算"承诺率"而非"模型好坏"；(2) Agent 调用模式从"人发起一次"演化成"系统持续调用数百次"，复合 API 链路的失败概率超过 30%，SLA 不工程化就是散单；(3) 监管侧（欧盟 AI Act、美国 EO 14110、中国《生成式 AI 服务管理暂行办法》）开始把"可问责的自动化决策"提到合同级要求——而 SLA 是"可问责"的工程表达。这三条证据共同意味着，2026 年再不把 SLA 工程化，Agent 项目就要在合规与合同两端同时失约。

二、形式化：SLA 三角 = 可用性 / 延迟 / 正确性的三维契约

在进入工程实现前，先做一次严格形式化。Agent SLA 不是单一指标，而是三维契约——任何一维失约，SLA 三角就破了一个角，整体契约就失效。

SLA ≡ ⟨availability, latency_p99, correctness⟩ 
其中：
  availability   ∈ [0, 1]    — 在单位时间内 (按月或按天) 正常服务的比例
  latency_p99    ∈ ℝ⁺ ∪ {∞}  — P99 延迟上界（秒）；超过 = 契约破裂
  correctness    ∈ [0, 1]    — 输出"对"的最低比例（在带标签评测集上）

三维契约工程化的关键，是把每个维度都拆成可观测量（SLI）+ 承诺上界（SLO）+ 违规触发器（burn-rate）：

• availability → SLI：1 - error_budget_burned_over_window / total_window_budget
• latency_p99 → SLI：P99(end_to_end_latency) ≥ SLO_threshold 时 burn rate = (P99_throughput × 失败比例) / 100
• correctness → SLI：(eval_passed / eval_total) ≥ correctness_threshold 时 burn rate = (1 - pass_rate) × multiplier

为什么是 burn rate（燃烧率） 而不是原始数值？SRE 工程实践反复证明，单纯的 SLO 阈值在事故窗口的第一秒几乎没用——一个 P99 延迟突然从 4 秒飙到 14 秒时，系统还需要几十秒才能"看清"是不是真的破约；而 burn rate 在第一秒就会告诉你"超阈值 3 倍，正在以每小时 X% 的速率消耗 error budget"，触发自动熔断、降级、回滚预警。

承诺三角的不对称：三个维度不是平权的。correctness 是反射性的（错了必须改重，但要承担重做成本），latency 是即时的（超一秒就是超一秒，没有"延迟补救"），availability 是滞后累计的（月粒度的"服务可用率"在第 30 天才能算出一个数）。实际工程中，正确性差 1% 比延迟差 5% 危险得多——因为 correctness 失约会侵入到下游业务决策里（"你帮我订机票，订到非洲去了"）。

三、承诺层：Agent SLA 的语义化建模 —— SLO 与 SLI 的工程契约

承诺层要做的事只有一件：把"99.9%"翻译成可执行的契约，让 SLO 既能落在文档里，也能落在 RPC header 与告警规则里。

3.1 语义化 SLA 文档

# agent.runtime.sla v1.0
tenant: enterprise-tier
scope: agent.svc.fin_assistant
budget:
  monthly_window: 43200 # minutes
  availability_budget_minutes: 43.2 # 99.9% 对应
  latency_budget_overruns:
    p99: 8s
    burn_rate_2x_5min: trigger_incident
    burn_rate_14_30min: trigger_paging
error_policies:
  on_correctness_fail: rollback_to_last_known_good
  on_latency_exceedance: degrade_to_medium_model_with_prompt_compression
  on_availability_drop: route_to_backup_region
compensations:
  on_breach: 25% next-cycle-discount + engineering_postmortem_in_5bd

这份文档不是给人读的，它是 contract-as-code——任何运行时都按这份契约核对状态。值得强调的两点：

• 数字要反推自业务：99.9% 不是 LLM 直给的、也不是从供应商海报上抄的，而是从用户实际等待耐心、调用分布、链路时长反推的。"用 0.1% 的可用性偏差换一个工程师月工资"是合理 trade-off；但"为了少 5% 延迟多付 30% 成本"是不合理 trade-off"。
• burn rate 不是单数：单层 burn rate 太粗——Google SRE Workbook 推荐把 5 min × burn rate 2x + 30 min × burn rate 14x 同时告警，作为"事件分级"输入。前者捕捉突发，后者捕捉慢性。

3.2 把 SLO 写进 RPC header

HTTP/1.1 200 OK
X-LLM-SLA: tenant=enterprise-tier; availability_target=0.999
X-LLM-SLA-SLO: latency_p99=8s; correctness_min=0.95
X-LLM-SLA-Region: us-east-1; failover=eu-west-1
X-LLM-SLA-Budget-Remaining: 37.4%

把 SLO 写在 response header 里，好处是任何调用方、网关、Audit 系统都可以零成本读取与核对。更进一步，可以在每条路径上贴上契约，例如：

# 服务端
def respond_with_sla_header(payload):
    return 200, payload, headers={
      "X-LLM-SLA-SLO": "latency_p99=8s; correctness_min=0.95; availability=0.999",
      "X-LLM-SLA-Budget-Remaining": budget_remaining_str(),
    }

# 客户端（网关）
assert response.headers["X-LLM-SLA-Budget-Remaining"] > "5%"  
  # 真要触发降级，而不是死磕

这一行断言看起来小，但它把"承诺"从口头变强类型：当 budget 低于 5% 时，网关自动降级（切小模型 / 切精简 prompt）而不是继续给最终用户开空头支票。

3.3 多租户 + 多 Agent 的承诺组合

真实生产中不是单一 Agent——通常有 search agent、planner agent、tool agent、code agent，各自有 SLA：

关键洞察：系统的整体 SLA 不是子 SLA 的平均值，而是子 SLA 的函数。SLA_system = f(SLA_router, SLA_planner, SLA_tool, SLA_code)——如果 router SLA 不及格，下游所有子 SLA 都白做；如果 code 子 SLA 不及格但可重做，整体 SLA 不一定不及格。承诺的工程化必须分层。

四、执行层：超时分级、租约续约与降级矩阵的运行时实现

承诺层落地的关键是执行层——把 SLO 变成运行时不可绕过的约束。

4.1 超时分级：精致到每一跳

超时不是单一阈值，而是一棵分层超时树：

end_to_end_timeout (8s)
├── planning_timeout (1.5s)
│   ├── llm_call_primary_timeout (1.2s)
│   └── llm_call_fallback_timeout (1.0s)
├── tool_dispatch_timeout (3s)
│   ├── sandbox_spawn_timeout (0.8s)
│   └── tool_exec_timeout (1.5s)
└── synthesis_timeout (2.5s)
    └── llm_call_primary_timeout (2.0s)

为什么 timeout_sum < budget？因为每一跳超时不应触发全部预算。如果每一跳都用"8s 上限"，整条调用栈累计可能吃掉 40s——burst 与排队失约的根因就是不收敛的超时树。推荐配置：总预算的 60-70% 给关键路径，30-40% 给异常路径。

4.2 租约续约（Lease Renewal）

长任务 Agent（planner 或 code agent）必须支持租约续约：

class AgentTask:
    def __init__(self, ttl=60):
        self.lease = Lease(ttl=ttl, owner=self.id)
        self.heartbeat = every(5s)
    
    def tick(self):
        try:
            self.renew_lease(extend=5)  # 续约 5s
        except LeaseExpiredError:
            self.checkpoint_then_die()  # 优雅死亡，残留状态已落盘

租约续约的工程价值：长任务不会"卡死"。当 Agent 的某一步陷入无限循环（典型 bug：function call 自调用、tool 返回值含循环引用），租约过期会强制它checkpoint 然后优雅死掉，而不是让用户等到天荒地老。

租约设计三条铁律：

• TTL 必须等于 2 × P95 step time——太长检测不出 hang，太短误杀正常任务
• 续约失败必须立即可见——不上报的续约失败等于没续约
• 过期执行必须立刻 checkpoint——丢的概率要小，不是"先做几个 step 再死"

4.3 降级矩阵（Degradation Matrix）

降级不是单维度的——需要一张降级矩阵来对 (latency_burn_rate, correctness_burn_rate) 平面做工程响应：

降级矩阵的工程意义：在 P99 慢但答案对时，自动切到更快模型（甚至切回 7B 小模型）；在 P99 快但答案错时，自动切到更强模型（甚至切到 RAG 重排序）；当双维度都炸时，自动熔断切到 backup region。

在实现上，建议降级动作是一等公民枚举而不是函数库调用：

enum DegradeAction {
    NOOP = "noop"
    SWITCH_MODEL_FAST = "switch_to_fast_model"
    SWITCH_MODEL_BIG = "switch_to_big_model"
    COMPRESS_PROMPT = "compress_prompt_lz4"
    RERANK = "apply_rerank"
    DEGRADE_TO_RULE = "fallback_to_rule_engine"
    ROUTE_FAILOVER = "route_to_backup_region"
    EMERGENCY_BREAK = "emergency_break"
}

显式枚举的好处是任何动作都能被观测、可被审计、可被演练。

4.4 运行时降级的"瞬时 + 持久"双视图

生产实践中降级经常被混淆为"瞬时动作"——切完就走。事实上，降级应该同时有两面：

• 瞬时降级：本次请求"快速失败 + 优雅退缩"——这是 4.3 矩阵解决的问题
• 持久降级：服务进入"感知到持续超 SLO"后长期降级模式——所有请求走 fast 路径，直到下一个 SLO 复审窗口

为什么需要"持久"那一面？如果一个租户连续 24 小时触发 SWITCH_MODEL_FAST，但配置上每条请求仍可能在 v2 模型上决策——这是更隐蔽的失约：看起来还在用强模型，实际每次都切到 fast 模型。持久降级模式应该把整个 agent 服务的默认模型从 v2 切到 fast，并把这个降级写进租户级 SLA 文档；用配置而非每次请求的"动态切"来管理。这种"双视图"让降级既是单点决策（瞬时），又是状态合同（持久），互不干扰。

降级持久化的额外收益：复盘速度更快——不是去翻请求级 degradation_path，而是直接看"过去 24 小时这条租户是否处于 fast-only 模式"。这会让你的复盘从"翻请求 → 对账"变成"翻配置 → 决策"，复盘时间可以从 30 分钟压到 5 分钟。

五、降级层：当工具失败或超时时的"快速失败 + 优雅退缩"工程模式

降级不是"出问题时少做一点"。降级是承诺被撕毁后的工程纪律：把"做错"转为"不做错"，把"迟到的真答案"转为"按时的可信 fallback"。

5.1 工具失败的"快速失败 + 优雅退缩"

工具调用失败时，常见三种曲线：

• A 曲线：完全失败 → 立即报"该工具不可用"，用户立刻知道
• B 曲线：工具超时 → 等用户等到崩溃
• C 曲线：工具慢但不超时 → 用户失去耐心

降级工程应该消除 B 与 C。具体来说：

class ToolCallPolicy:
    def execute(self, tool, args):
        try:
            with deadline(deadline=tool.tool_timeout):
                return tool.invoke(args)
        except DeadlineExceededError:
            # 不是 raw timeout 异常 → 在 SLA breaker 中标记"本 tool 已 timeout"
            breaker.trip_on_timeout(tool)
            return FallbackResult(
                kind=tool.fallback_kind,  # "noop" / "rule" / "cache_hit"
                reason="timeout",
                original_exception=DeadlineExceededError,
            )

关键的工程动作是降级结果必须有 fallback_kind 字段，方便观测层区分"工具成功返回空"和"工具失败被降级"——这两类事件的应对完全不同。

5.2 服务端也要降级

降级不只是客户端——服务端要做前向降级：

• 当上游"已契约"在 SLO 上的 budget 耗尽时，主动下发 X-LLM-SLA-Budget-Remaining: 2% 给下游
• 下游收到 2% 后，自动暂停非关键功能（包括打印 logs、生成 summary、记录 metrics 之外的 detail trace）

前向降级是给下游的礼物——它让下游的 SLA 也跟着收紧，而不是"上游愉快地破约，下游毫无准备地破约两次"。

5.3 优雅退缩的三条红牌

降级的红牌：

1. 永远不要"在快超时时自作主张改答案"——把超时的 fallback 当成"修正答案"的时机，是诚实上的失约
2. 永远不要在降级时丢掉栈——降级报错必须含原始 exception + reason code，方便事后回放
3. 永远不要让用户"不知道被降级了"——用户看到的响应必须明确："这份结果来自 fallback，并非直接调用原工具"

六、事后熔断层：事后校验、灰度回滚与对账工程的闭环

事后熔断是 SLA 的事后脸面——它决定你事故后是"半小时搞定"还是"睡 24 小时"。

6.1 事后校验（Postmortem Verification）

事故后要回答三个问题：

• 契约被破坏了吗？ → 比对 response.headers["X-LLM-SLA-Budget-Remaining"] 时序，看 budget 燃烧率
• 什么被破坏？ → 用 eval set 跑回放，比对"P99 慢时输出正确率"
• 什么时候恢复？ → 用 burn_rate windowing 算"经过多少分钟触发自动恢复"

事后校验的工程动作：

• 把每条响应都打哈希（含 prompt + response + tools + metadata）作为可重放条目
• 每天 / 每小时跑一次"重放 diff"——重放结果与原响应差异 > 阈值时报警
• 重放不止验证正确性——还验证延迟、消耗、模型版本一致性

6.2 灰度回滚（Canary Rollback）

任何 prompt 改动、模型升级、工具接入必须经过灰度：5% → 25% → 100%。灰度判定的金标准是 burn rate × accuracy：

accuracy_old × (1 - burn_old) vs accuracy_new × (1 - burn_new)

如果新版本在该公式下 < 老版本，立即 100% 回滚；如果持平，留灰度再观察；如果更高，继续放量。

灰度反模式：用"用户投诉量"判灰度。用户投诉量比 burn rate 滞后 5-60 分钟，而 burn rate 是实时的——用户开始吐槽时，回滚的最佳时机已经过了。

6.3 对账工程（Reconciliation Engineering）

对账是工程团队 vs 业务团队的共识：每天 04:30 CST，系统自动校准 SLO：

• 把昨日每小时的 SLI 重算一遍（不是只信 in-memory counter）
• 把对账结果生成可以附在月度报告里的 evidence bundle
• 对账报告必须可验证——任何一行结论都能溯源到具体的 request_id

对账的工程价值：让 SLO 不是"客服收到抱怨"驱动的，而是机械可验证的。这种可验证性反过来稳定工程团队与业务团队的信任。

6.4 对账工程的"证据四元组"

一份合格的对账报告，至少带四个证据：

• 时序图：昨日 24 小时的 SLO 三维时序（availability / latency_p99 / correctness），并把违规窗口高亮
• 请求采样：从昨日 10000+ 请求中抽样 200 条，每条含 trace_id + response hash + degradation_path，可点击回溯
• 超 SLO 列表：所有"昨日超 SLO 的时段 + 影响租户 + 影响请求数 + 持续时长"
• 回滚轨迹：灰度变更（升级、prompt 改动、工具接入）在什么时间被回滚 + 为什么回滚 + 回滚后 SLO 恢复轨迹

证据四元组的工程意义：让对账不只是"昨天 SLA 多少"，而是"昨天的失约都是什么、发生在谁身上、系统是如何处理的"。这四个证据加在一起，下一周的工程优化就有了目标。

七、观测层：把 SLO 当作一个一等公民写入可观测性栈

把 SLO 当一等公民，意味着SLO 出现在 metric/log/trace/dashboard 每一层，而不是被压扁在一张"展示用 dashboard"里。

7.1 Metric 层

Prometheus 风格的 SLO metric 至少要四类：

• slo_budget_remaining_ratio{tenant, agent} → 实时
• slo_burn_rate_5min{tenant, agent} → 滚动窗
• slo_attainment_daily{tenant, agent} → 每天 04:30 落
• slo_attainment_monthly{tenant, agent} → 每月 04:30 落

SLO 不能只算率——还要算"自上次违约至今天数"——它是 stakeholder 沟通的语言。

7.2 Log 层

每次输出都加 slo_context 字段：

{
  "ts": "2026-07-22T08:14:23Z",
  "request_id": "...",
  "agent": "fin_assistant",
  "slo_budget_remaining": 0.61,
  "burn_rate_5min": 0.02,
  "latency_ms": 1240,
  "model": "gpt-5-mini",
  "degradation_path": ["model_chosen", "prompt_compressed"]
}

degradation_path 字段是事后定位"为什么这次没满足 SLA"的金矿。没有它，事故复盘就变成"为什么会慢？"的猜谜。

7.3 Trace 层

Trace 是 SLO 的赛博骸骨：

• 每个 span 必带 SLA tag：timeout、tool、prompt_size、tool_call_count
• 跨服务 trace 必带可重放指针：trace_id + replay_token
• Trace 不进数据湖就退费——这是 budget 守门员

7.4 Dashboard 层

不要把 SLO dashboard 与业务 dashboard 强行合并。SRE 工程经验：SLO dashboard 是"我守约了吗"，业务 dashboard 是"用户来买了吗"。两者用不同的 refresh frequency、不同的看板主色调、不同的 owner。

八、踩坑与反模式：SLA 工程的真实代价

四个 SLA 工程的高频反模式：

• 反模式 1：SLO 写"99% 可用"。99% 月粒度每月能宕机 7 小时——用户会很痛苦。建议至少 99.9% 月粒度。
• 反模式 2：把降级当 "少做一点"。降级若丢了栈、丢了用户通知、丢了日志，反而不如不降级。降级是责任的承担，不是偷工减料。
• 反模式 3：SLO 用"调用次数"做分母。当调用次数爆炸时，错误率不变但 SLO 看似变好——这是大数定律陷阱。建议把分母设为"调用次数 + 自适应正则项"。
• 反模式 4：synthetic probe 替代真实监控。synthetic probe 跑的是"理想路径"，但真实路径含 30% 偶发网络抖动、5% 用户输入过激、2% 工具失败。SLO 必须以真实用户调用分布为评估集。
• 反模式 5：把 SLA 当 PR-only 项目。最常见的 SLA 工程死于"立项时大张旗鼓、3 个月后无人问津"。SLA 是产品，不是文档——任何新 Agent 上线都必须在 SLA 文档上注册；任何 SLA 调整都必须经业务侧 SLA owner 签字。这是把 SLA 从工程动作转为产品契约的关键。
• 反模式 6：依赖模型厂商给定的 SLA。OpenAI、Anthropic、月之暗面给的 SLA 是它们的，不是你的。集成层 SLA 必须等于 min(厂商 SLA, 自身降级路径) 的工程化——不要把"我们 99.9% 可用"挂在别人随时可能降级的链路上，否则会出现"我们守约了但厂商失约"的连锁失约场景。

九、给 SRE 与 Agent 平台工程师的清单：六个必走动作

最后给落地清单——六条必走动作：

1. 写 contract-as-code SLA 文档：tenant + agent + 三维承诺 + 降级动作 + 补偿条款——不要纯 markdown
2. 在 RPC header 里贴 SLA：availability + latency_p99 + correctness + budget_remaining——所有调用方都能零成本读取
3. 超时分级成树：end_to_end_timeout > sum(child_timeouts)；每跳 ≤ 上限的 60-70%
4. 租约续约：长任务必须有 Lease TTL + heartbeat + checkpoint-on-expiry，禁止 ad-hoc 长任务
5. 降级矩阵当一等公民枚举：NOOP / SWITCH_MODEL / COMPRESS_PROMPT / RERANK / DEGRADE_TO_RULE / ROUTE_FAILOVER / EMERGENCY_BREAK
6. 事后熔断三件套：事后校验（重放 diff）+ 灰度回滚（burn rate × accuracy）+ 对账工程（每日 04:30 自动校准）

把以上六条实现一遍，Agent SLA 从"漂亮的承诺"变成"代码承诺"——这才是 2026 年 Agent 平台工程的真相。

9.1 行动到度量的映射

光写清单不验收等于没写。给六条动作各配一个度量：

• (1) contract-as-code → "在 /etc/agent/sla/*.yaml 下应有 ≥ N 个租户文件 + CI fail 当缺字段"
• (2) RPC header → "采样 1000 条请求，0 命中 X-LLM-SLA-SLO 字段应报警"
• (3) 超时分级 → "timeout_tree 子节点之和超过端到端 70% 自动告警"
• (4) 租约续约 → "长任务 > 30 分钟必须有一个 lease_renewal 监控；过期未续约自动 sigkill"
• (5) 降级矩阵 → "DegradeAction 枚举值变化需走 PR review；不允许脚本自由拼接"
• (6) 事后熔断三件套 → "每日 04:30 后 5 分钟内未收到对账报告 = 月度目标 discount 自动 0"

度量是 SLA 工程不被"滑过"的关键——上面的每一条都防止"清单写了但没做"的典型工程漂移。没有验收度量的清单是工程支票，没有行动清单的验收度量是空喊。二者缺一不可。

9.2 SLA 工程的"30/60/90"上线节奏

行动到度量都已就位后，按"30/60/90"上线节奏展开：

• 30 天（共识）：6 条动作中的 (1)(2)(6) 立项；committer 把 contract-as-code 模板写出来；RPC header 改造跑通单租户 POC
• 60 天（运行）：6 条全部落地到 5% 租户试点；超时分级 (3) 与租约续约 (4) 试点；DegradeAction 枚举纳入 service mesh
• 90 天（全量）：所有 enterprise-tier 租户跑在 SLA 三层闭环上；每月对账报告送业务与合规侧；三次灰度升级一次回滚演练

30/60/90 不是空架子——它是把"6 条动作"翻译成"日历里程碑"的尺度。每一阶段都有自己的可验证产出、有自己的失约代价、有自己的升级路径。没有时间维度的工程清单必然失约——这是我们在多个生产团队观察到的普遍规律。

参考文献

1. Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media.
2. Jones, C. (2019). The SRE Workbook: Practical Ways to Implement SRE. O'Reilly Media.
3. Google SRE Team. (2017). Error Budget Policy. In SRE Book, Chapter 4.
4. Foote, S., et al. (2017). Monitoring Distributed Systems. In SRE Book, Chapter 6.
5. Brewer, E., & Fox, A. (1999). Harvest, Yield, and Scalable Tolerant Systems. Proceedings of HOTOS-VII.
6. Patterson, D., et al. (2024). Taming the Tail: Reliable LLM Serving. USENIX SOSP.
7. OpenAI. (2025). Agents SDK: Production Best Practices. OpenAI Engineering Blog.
8. Anthropic. (2025). Claude Agent SDK: SLO Patterns. Anthropic Engineering.
9. LangChain. (2025). LangGraph Reliability Cookbook. LangChain Documentation.
10. Microsoft Research. (2024). AutoGen Reliability Patterns and Anti-Patterns. MSR-TR-2024-29.
11. Hilton, J., et al. (2021). Scaling laws for single-agent reinforcement learning. DeepMind Technical Report.
12. Amazon Web Services. (2024). Well-Architected Framework: Reliability Pillar. AWS Whitepaper.
13. Kreps, J., et al. (2014). Kafka: a Distributed Messaging System for Log Processing. NetDB 2014.
14. Obr, N. (2025). Burn Rate Alerting: A field guide. Stripe Engineering Blog.