> https://router.one/zh/blog/ai-agents-production-guide 的 Markdown 镜像，供 AI 助手与爬虫使用。Router One 是 OpenAI 兼容的统一 LLM API 网关。
> 发布：2026-04-09 · 修订：2026-08-22 · 作者：Router One Team

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

_通过可观测性追踪、预算护栏和自动故障恢复，在生产环境中安全运行 AI Agent。包含实用模式与代码示例。_

你的 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——每次请求都会记录模型、token、成本、延迟、fallback、状态等元数据，dashboard 直接展示聚合指标，不需要在应用代码里埋点。你的业务代码保持干净，运维团队从第一天就有足够的可见性。

关于 AI API 网关如何提供这一可观测性层，详见 [什么是 AI API 网关](https://router.one/zh/blog/what-is-ai-api-gateway)。

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

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

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

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

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

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

### 分层预算架构

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

正确的做法是分层：

```json
{
  "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 日限额**控制单个集成或开发者的敞口。**项目月限额**让团队支出不超预算。**组织限额**是最后一道防线。

这段分层 JSON 描述的是应用架构，不是一份 Router One 配置。Router One 在每把 API Key 上执行 maxSpend、rateLimit 和 tokenLimitTpm；per-run、项目、组织、审批和告警策略由你的应用或编排框架负责。需要隔离网关花费时，应为不同工作负载创建独立 Router One Key。

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

### 超限处理策略

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

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

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

Router One 会在转发计费请求前执行当前 API Key 的 maxSpend 上限；上述更高层级的限制和超限策略需要由你的应用或编排框架实现。

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

更多成本优化策略，详见 [降低 LLM API 成本的 5 种方法](https://router.one/zh/blog/reduce-llm-api-costs)。

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

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

### 自动故障转移模式

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

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

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

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

一个实用的 failover 配置如下：

```yaml
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 编排的常见模式](https://router.one/zh/blog/multi-agent-orchestration-patterns)这篇模式综述。

### 熔断器与重试预算

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

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

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

Router One 支持的候选路由会使用 EWMA 延迟与可靠性观测。精确模型请求在符合条件的失败后，可尝试该模型的其他健康 provider 线路；`model="auto"` 则在服务端候选集中重试。端到端 fallback 时长取决于失败尝试与下一个 provider，不承诺固定毫秒级切换。

关于 EWMA 路由的技术细节，详见 [AI 模型路由机制详解](https://router.one/zh/blog/ai-model-routing-explained)。

## 生产就绪检查清单

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

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

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

Router One 开箱提供的是这些支柱里的网关部分——每次调用的元数据 Trace、按 Key 的 maxSpend 执行和 provider fallback。聚合预算、告警、持久化 Run/Step 状态、工具执行和多步骤工作流恢复仍由你的应用或编排框架负责。工作流跑在 [n8n](https://router.one/zh/integrations/n8n) 这类工作流自动化工具里而不是你自己的代码里时，按 Key 记账的这本账同样适用。如果你正在构建生产级 agent，从 [router.one](https://router.one/zh) 开始。浏览可用模型请访问 [/models](https://router.one/zh/models)，了解团队如何与编程 agent 集成请查看 [/claude-code-china](https://router.one/zh/claude-code-china)。

## 常见问题

**为什么 AI agent 比传统 API 更难在生产环境运维？**
因为失败模式从根本上不一样。Agent 行为是非确定性的——同一个 prompt 每次可能走出不同的推理路径、消耗不同数量的 token；成本是复合的，一次请求可能触发 2 次、10 次甚至 50 次 LLM 调用。再叠加多 provider 依赖和有状态的多步骤工作流，传统的 API 运维套路基本不管用。

**生产级 AI agent 需要哪三根支柱？**
可观测性——通过 Run 级别 tracing 知道 agent 在干什么；成本控制——用分层预算护栏防止预算失控；故障恢复——靠 failover、状态持久化、熔断器和重试预算，在 provider 出问题时保持运行。

**如何防止 AI agent 花超预算？**
在多个层级设限：per-run 上限防止单次失控，API key 日限额控制单个集成的敞口，项目和组织月限额兜住整体开销，并在 80% 消耗时触发软告警、之后才是硬性截断。Router One 在每把 API Key 上执行 maxSpend、rateLimit 和 tokenLimitTpm；per-run、项目、组织和告警策略由你的应用或编排框架负责。更多成本优化策略见 [降低 LLM API 成本的 5 种方法](https://router.one/zh/blog/reduce-llm-api-costs)。

**LLM provider 劣化时，自动 failover 是怎么工作的？**
主流 provider 每月会经历 2 到 5 次性能劣化事件，所以每个主力模型都应配置至少一个备选。Router One 支持的候选路由使用 EWMA 延迟与可靠性观测：精确模型请求在符合条件的失败后，可尝试该模型的其他健康 provider 线路，`model="auto"` 则在服务端候选集中重试，不承诺固定毫秒级切换。

**Router One 为生产级 agent 覆盖哪些能力？哪些仍由应用负责？**
Router One 开箱提供网关部分：每次调用的元数据 Trace（模型、token、成本、延迟、fallback、状态）、按 Key 的 maxSpend 执行和 provider fallback。聚合预算、告警、持久化 Run/Step 状态、工具执行和多步骤工作流恢复仍由你的应用或编排框架负责。

## 结语

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

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

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

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

## 相关页面

- 本页规范地址：https://router.one/zh/blog/ai-agents-production-guide
- LLM API 网关与路由：https://router.one/zh/llm-api-gateway
- 全部博客文章：https://router.one/zh/blog
- 模型与每模型 token 价格：https://router.one/zh/models（markdown：https://router.one/zh/models.md）
- 定价：https://router.one/zh/pricing
- API 文档（markdown）：https://router.one/zh/docs.md
- 公司事实（markdown）：https://router.one/zh/facts/company.md