Router One
返回博客

如何在生产环境安全运行 AI Agent：可观测性、成本控制与故障恢复

|Router One Team
ai-agentsproductionobservabilitycost-controlreliabilitybest-practices

你的 AI agent 在开发环境跑得很顺。请求发出去，响应回来，agent 读文件、调 LLM、写代码，再调一次 LLM 做验证。一切看起来没问题。然后你部署到了生产环境。

第一周，三个问题就会接踵而至。第一，成本在暗处累积——某个 agent 实例陷入推理循环，还没人察觉就烧掉了 $200 的 token。第二，故障悄无声息——用户反馈 agent「没反应了」，你的团队却无从还原当时发生了什么，因为系统里只有零散的请求日志，没有 Run 级别的完整 trace。第三，级联宕机无法恢复——主力 LLM provider 性能劣化了 40 分钟，你系统里的每个 agent 都卡在那里，等一个永远不会来的响应。

这不是假设，而是规模化运行 AI agent 的日常。无论是编程 agent、客服机器人、内部自动化流程，还是任何让 LLM 自主决策的系统，都会碰到这些问题。

生产环境的 AI agent 需要三根支柱：可观测性，知道 agent 在干什么；成本控制，防止预算失控；故障恢复，在 provider 出问题时保持运行。这篇文章会逐一讲解具体的落地模式、配置示例和生产就绪检查清单。

为什么 AI Agent 比传统 API 更难运维

在讲解决方案之前，先搞清楚一件事：传统的 API 运维套路，对 AI agent 基本不管用。失败模式从根本上就不一样。

非确定性行为。 传统 API 是确定性的——相同输入、相同输出、相同成本。AI agent 不是。同一个用户 prompt，每次执行可能走出不同的推理路径、触发不同的工具调用序列、消耗不同数量的 token。容量规划、成本预测、异常检测的难度直接上了一个台阶。

复合成本。 传统 API 调用成本固定。而一个 agent 请求可能触发 2 次、10 次、甚至 50 次 LLM 调用，取决于任务复杂度、推理策略以及是否进入了自我纠错循环。用户说一句「重构认证模块」，背后可能是 15 次 LLM 调用——规划、生成代码、验证、修订。单次用户操作的成本事先无法预知，不同 Run 之间可能差出一个数量级。

多 provider 依赖。 多数生产级 agent 系统同时依赖多家 LLM 提供商——比如用 Claude 做复杂推理，GPT 做特定工具调用，小模型做分类。每个 provider 都是独立的故障域，有各自的可用性、延迟特征、速率限制和降级模式。每多接一个 provider，故障的组合空间就指数增长。

有状态工作流。 与无状态的 API 调用不同，agent 跨多个步骤维护上下文。一个编程 agent 可能正在执行 12 步重构任务的第 7 步时遇到 provider 宕机。简单重试整个请求行不通——你需要从最后一个成功的步骤恢复，而这意味着你必须事先持久化中间状态。大多数团队都是在第一次生产事故之后才意识到这个需求。

支柱一 — 可观测性：了解你的 Agent 在做什么

agent 部署到生产环境后，你最先失去的就是可见性。开发时你可以实时观察 agent 的每一步——每次 LLM 调用、每次工具执行、每个决策节点。到了生产环境，你只有日志。如果日志结构不对，那就什么都没有。

请求级 tracing 远远不够

传统 API 可观测性围绕单个请求展开：这个请求耗时 340ms，返回 200，消耗 1,247 token。对 agent 来说，这个粒度完全不够用，因为一次 agent 动作由多个有依赖关系和中间状态的请求组成。

你需要的是 Run 级别的 tracing——一棵层级化的追踪树，记录 agent 在一次用户发起的操作中的每个步骤，包括 LLM 调用、工具执行、token 消耗、成本和耗时：

Run #r_abc123 — "Refactor auth module"
├─ Step 1: claude-4-sonnet → Plan (312 in / 1,847 out) $0.008 — 1.2s
├─ Step 2: tool:file_read → auth.ts (no LLM cost)
├─ Step 3: claude-4-sonnet → Generate code (4,102 in / 3,291 out) $0.031 — 3.4s
├─ Step 4: tool:file_write → auth.ts (no LLM cost)
├─ Step 5: claude-4-sonnet → Verify (2,847 in / 892 out) $0.014 — 1.1s
└─ Total: 7,261 in / 6,030 out — $0.053 — 5.7s

这棵 trace 树一目了然：agent 发起了三次 LLM 调用和两次工具调用，代码生成步骤最贵，总成本 $0.053，整个 Run 耗时 5.7 秒。没有这种结构，你就只能在散落的请求日志里拼凑，猜测哪些请求属于同一次 agent 操作。

关键指标

有了 Run 级别的 trace，才能衍生出真正对生产运维有意义的指标：

  • 每次 Run 的成本——不是每次请求的成本。一个 Run 发起 12 次 LLM 调用，每次 $0.01，总成本是 $0.12。如果你只看单次请求，看到的是 12 个「便宜调用」，漏掉了整体画面。
  • P95 Run 延迟——从 Run 开始到结束的端到端耗时。当用户在等一个 10 步的 agent 工作流时，单次请求延迟没什么参考价值。
  • 按 agent 类型的成功/失败率——不同 agent 的可靠性基线不一样。代码生成 agent 可能有 8% 的失败率，摘要 agent 只有 0.5%。分开跟踪才能设出有意义的告警阈值。
  • Token 消耗趋势——你的 agent 是不是在变贵？prompt 漂移或模型更新可能让 token 用量悄悄涨 30%，而你这边一行代码都没改。
  • 模型流量分布——实际在处理流量的是哪些模型？如果路由配了但 95% 的流量还在走最贵的模型，说明哪里出了问题。

Dashboard 与日志

把结构化日志输出到 stdout 是个合理的起点。但日志本身无法回答聚合性问题，比如「昨天 agent 总共花了多少钱？」或「这周哪个项目的 P95 Run 延迟最高？」——除非你在日志上层建一套查询体系。你需要聚合型 dashboard，按项目、API key、模型和时间窗口展示趋势、异常和明细。

Router One 这类平台在网关层自动捕获这些 trace——每次 llm.invoke 调用都带完整上下文记录，dashboard 直接展示聚合指标，不需要在应用代码里埋点。你的业务代码保持干净，运维团队从第一天就有足够的可见性。

关于 AI API 网关如何提供这一可观测性层，详见 什么是 AI API 网关。

支柱二 — 成本控制：为自治系统设置预算护栏

AI agent 天生就是半自治的。它自己决定调几次 LLM、用哪些工具、什么时候重试或自我修正。这种自治性让 agent 有用——也让它对预算构成威胁。

为什么 Agent 比传统 API 更需要预算限制

传统 API 调用成本有上界。你知道每次请求的价格，可以根据预估流量算出月度开支，就算 bug 导致请求量翻倍，成本也只是翻倍——痛但可控。

Agent 打破了这个模型。一个编程 agent 接到「重构整个代码库」的指令，可能循环 50+ 次迭代，每次都涉及多个 LLM 调用。一个调研 agent 找不到满意答案时，可能用越来越长的 context 反复重试，token 消耗指数级增长。一个客服 agent 遇到恶意用户，可能陷入澄清循环，产生数百个无意义 token。

单次 agent Run 的成本是无界的，除非你主动设界。没有预算护栏，一次失控的 Run 就能吃掉系统平时一整天的预算。

分层预算架构

有效的成本控制需要在多个层级设限。单一的全局预算太粗——只能保护组织层面，无法防止某个项目挤占其他项目的预算。单次请求限制又太细——会阻断那些合理的长时间运行的 agent 工作流。

正确的做法是分层：

{
  "budgets": {
    "organization": { "monthly_limit_usd": 5000 },
    "project": { "monthly_limit_usd": 1000 },
    "api_key": { "daily_limit_usd": 50 },
    "per_run": { "max_cost_usd": 10 }
  },
  "alerts": {
    "soft_warning": 0.8,
    "hard_cutoff": 1.0
  }
}

每一层防的是不同类别的问题。per_run 限制防止单次 agent 失控。API key 日限额控制单个集成或开发者的敞口。项目月限额让团队支出不超预算。组织限额是最后一道防线。

80% 的软告警给团队留出调查和调整的时间，在硬性截断生效之前。当硬限额被触发时，你有几种应对策略。

超限处理策略

具体的应对方式取决于 agent 类型和业务场景：

  • 直接阻断——最安全的选项，适用于非关键负载。Agent 收到预算超限错误并停止运行。
  • 降级到更便宜的模型——适用于「完成比质量更重要」的场景。路由到成本低 10-20 倍的小模型，让 agent 完成任务。
  • 告警但继续——适用于营收关键型 agent，停止运行的代价比超支更大。向运维团队发告警，允许 Run 完成。
  • 排队等人工审批——适用于高价值、高成本的操作。暂停 agent，通知负责人，只有得到明确批准后才恢复执行。

多数生产系统会组合使用：per-run 限制做阻断，日限额做降级，月限额做告警。

Router One 在网关层实时执行这些预算检查——请求转发给 provider 之前就会校验预算，从物理上杜绝超支，而不是事后才发现。

更多成本优化策略，详见 降低 LLM API 成本的 5 种方法。

支柱三 — 故障恢复：当问题发生时（而且一定会发生）

LLM provider 的可靠性远不及传统云基础设施。主流 provider 每月都会经历 2 到 5 次性能劣化事件，从延迟升高到完全宕机，持续几分钟到几个小时不等。如果你的 agent 系统只依赖单一 provider 且没有故障转移，你就得接受每月多次事故作为常态。

自动故障转移模式

常见的 provider failover 有三种模式，各有权衡：

热备（Hot Standby）。 指定一个主力模型和一个或多个备选模型。正常情况下所有流量走主力模型。当主力劣化时，流量切换到第一个备选。实现简单，但备选模型在正常运行期间不承载生产流量，你对它们在负载下的表现信心不足。

双活（Active-Active）。 流量按路由权重同时分配给多个 provider。当某个 provider 劣化时，其权重下降，其他 provider 吸收流量。比热备更有韧性，因为所有 provider 都在持续承接真实流量，但管理更复杂。

优雅降级（Graceful Degradation）。 当主力模型不可用时，不是 failover 到另一个同等规格的模型，而是退回到一个更简单、更快、更便宜的模型，处理 agent 能力的一个子集。Agent 继续运行但功能受限——就像汽车的跛行模式。

一个实用的 failover 配置如下：

routing:
  primary: claude-4-sonnet
  fallback:
    - gpt-4.1
    - gemini-2.5-pro
  failover_trigger:
    error_rate_threshold: 0.1
    latency_threshold_ms: 5000
  recovery:
    probe_interval_seconds: 30
    min_healthy_probes: 3

failover_trigger 定义了切换时机：错误率超过 10% 或延迟超过 5 秒。recovery 定义了恢复机制：每 30 秒发一次健康探测，只有连续 3 次正常响应后才重新引入主力模型。这样可以防止系统在间歇性故障期间在 provider 之间反复切换。

多步骤 Agent 的状态恢复

Failover 解决的是 provider 端的问题，但 agent 工作流还面临另一个恢复挑战：一个多步骤 Run 在中途失败了怎么办？

设想一个编程 agent 正在执行 12 步重构任务的第 7 步。前 6 步已经成功完成——文件已读取、计划已制定、代码已生成。然后第 7 步的 LLM 调用失败了。如果没有状态持久化，你只有两个烂选项：从头重跑整个 12 步工作流（浪费时间和钱），或者直接判定整个 Run 失败（浪费已完成的工作）。

更好的做法是在每个检查点持久化 Run/Step 状态。当故障发生时，agent 可以从最后一个成功的步骤恢复。持久化的状态包括 Run 的当前状态、每个已完成步骤的输出以及累积的上下文。这和分布式计算中的 checkpoint 是同一个概念——对生产级 agent 同样不可或缺。

熔断器与重试预算

朴素的重试逻辑是 agent 成本爆炸最常见的原因之一。Agent 遇到一个瞬时错误，用指数退避重试，重试本身又触发更多错误——或者重试成功了，但因为每次重试都带了更长的 context window，token 成本已经飙上天。

熔断器（Circuit Breaker） 阻止这种级联效应。在设定的时间窗口内累积到一定数量的失败后，熔断器断开，后续对该 provider 的所有请求直接快速失败而不实际发送。这既保护了你的预算，也保护了已经劣化的 provider 免受重试风暴。

重试预算（Retry Budget） 是熔断器的补充，它限制的是重试的总成本。与其限制重试次数（无法反映不同尝试之间的成本差异），不如为每个 Run 的重试设置一个最大金额。重试预算耗尽后，Run 干净地失败并返回清晰的错误信息。

Router One 使用基于 EWMA（指数加权移动平均）的延迟评分检测 provider 劣化，在毫秒级将流量重新路由——无需修改你的应用代码。评分算法持续适应实时状况，瞬时波动会被平滑处理，而真正的劣化则立即触发切换。

关于 EWMA 路由的技术细节，详见 AI 模型路由机制详解。

生产就绪检查清单

在将 agent 部署到生产环境之前，逐项验证以下清单。大致按优先级排列——前五项是底线，后五项强烈建议做到。

  • 每次 LLM 调用都有 trace，记录 token 输入/输出、成本、延迟和模型名称
  • Trace 按 Run/Session 聚合，而不仅仅是单次请求——你能看到一次 agent 操作的完整生命周期
  • 成本 dashboard 展示消费明细，可按项目、API key、模型和时间窗口筛选
  • 预算限制在多层级实时执行，覆盖组织、项目和 API key 层面
  • 80% 预算消耗时触发软告警，给团队在硬截断之前留出调查时间
  • 每个主力模型都配置了至少一个备选模型/provider
  • Failover 经过实际测试，而不仅仅是配了——跑一次模拟 provider 故障的混沌测试，验证流量确实正确切换
  • 多步骤 agent 持久化状态以支持断点恢复——第 7 步失败不需要从第 1 步重来
  • 重试逻辑有预算上限——重试消耗不超过每个 Run 的配置金额
  • 你能在 30 秒内回答「agent X 昨天花了多少钱？」——通过 dashboard 而不是翻日志

十项全部达标，你的 agent 系统就可以上生产了。前五项如果有任何一项缺失，就意味着在规模化运行时存在严重的盲区。

Router One 开箱即用地提供了这三大支柱——可观测性、成本控制和故障恢复。如果你正在构建生产级 agent，从 router.one 开始。浏览可用模型请访问 /models，了解团队如何与编程 agent 集成请查看 /use-cases/claude-code。

结语

demo agent 和生产 agent 之间的差距，不在 prompt 设计或模型选择——而在它周围的运维基础设施。demo agent 调一次 LLM，返回一个结果。生产 agent 通过一套体系调 LLM——这套体系追踪每一步操作、在多层级执行预算限制、在 provider 故障时自动恢复。

直接调 LLM = 黑盒。 你拿到了响应，但没有发生了什么的账本，没有 agent 如何推理的轨迹，也没有它花了多少钱的管控。通过基础设施运行 agent，你就有了账本、轨迹和管控——和你对其他任何生产系统的要求一样。

随着 agent 变得更加自治——做更多决策、调用更多工具、运行更长的工作流——这三根支柱只会更重要，不会更轻。今天跑 5 次 LLM 调用的 agent，明天能力扩展后可能跑 50 次。支撑它的基础设施需要同步扩展。

现在就打好运维地基。你的 agent——还有你的预算——都会感谢你。