博客从 POC 到每天 10 万次请求的 AI Agent 生产部署实战记录，包含超时控制、指数退避重试、Token 预算管理、事件溯源审计等具体实现与踩坑经验。
2026 年 3 月，我们团队把一个 AI 审批系统从 POC 推到生产。第一天就挂了：凌晨 3 点，某个工具调用陷入重试循环，一晚上烧了 $47 的 API 费用，队列积压了 2 万条任务。复盘发现，问题出在三个地方——没有限流、没有超时熔断、没有预算控制。
这篇文章记录了我们从"能跑"到"能扛"的架构演进过程，包含具体的配置和踩坑记录。
大多数团队的 POC 长这样：一个 Python 脚本，调 LLM API，循环处理输入。没有持久化、没有重试策略、没有监控。核心逻辑大约 20 行，测试集 50 条数据，挂了 rerun 就行。
但上生产后，三个致命缺陷暴露了：
第一轮改造加了三个东西：超时控制、指数退避重试、并发限流。核心改动：
这版上线后，p99 延迟从 27s 降到了 8s，429 错误基本消失。但新问题来了：成本不可控。某个指令设计不当导致 LLM 输出 8000 字符，单次调用花了 $0.15。每天 10 万次就是 $15,000。
第二轮改造核心是"每一分钱都要看到去向"。
| 维度 | POC 阶段 | 生产 V1 | 生产 V2 |
|---|---|---|---|
| 超时控制 | 无 | 30s 客户端超时 | 分模型超时（gpt-4o: 30s, 快模型: 15s） |
| 重试策略 | 手动 rerun | 指数退避 3 次 | 按错误类型差异化重试 |
| 并发控制 | 无 | Semaphore(10) | 动态限流（根据 API quota 实时调整） |
| 预算控制 | 无 | 无 | 每次调用前预算检查 + 事后审计 |
| 可观测性 | print() | 结构化日志 | Prometheus + 自定义 metrics |
| 持久化 | 无 | SQLite | PostgreSQL + 事件溯源 |
预算控制的实现思路：维护一个滑动窗口（最近 1 分钟）和一个日累计计数器。每次调用前估算消耗量，检查是否超过分钟/日限额。超限则直接拒绝并告警。同时用 Prometheus 暴露三个关键指标：
llm_request_duration_seconds（histogram，按模型和状态分桶）llm_token_consumed_total（counter，按模型分）llm_budget_rejected_total（counter，预算拒绝次数）金融场景要求每一步都有审计日志。我们选择了事件溯源模式：每个任务的完整生命周期被记录为一系列不可变事件。事件类型包括：
存储用 PostgreSQL 的一张 events 表，payload 字段用 JSONB。建表语句：
CREATE TABLE events (
id BIGSERIAL PRIMARY KEY,
trace_id UUID NOT NULL,
event_type VARCHAR(50) NOT NULL,
payload JSONB NOT NULL,
created_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE INDEX idx_trace ON events(trace_id);
这套设计让排查问题变得简单：给定 trace_id，直接 SQL 查询就能还原完整链路。比如找出所有"LLM 响应时间 > 10s"的条目，关联到对应的输入内容，定位指令设计问题。
单机场景 Semaphore 够用。分布式场景建议用 Redis 的滑动窗口计数器 + 本地 bucket 两级限流。我们最终用的是 aiolimiter 库 + Redis 做全局协调。
看场景。如果只是日志审计，用结构化日志 + 日志中心（ELK/Loki）就够了。事件溯源的优势在于能还原状态——比如"用户看到的结果是什么"，而日志只告诉你"调用了什么 API"。
以 gpt-4o 为例，平均每次 500 input + 200 output，单价约 $0.0025/次。10 万次 ≈ $250/天。如果换成 DeepSeek-V4 或本地部署的模型，成本可以降到 $30-50/天。
我们的场景是异步的——用户提交后，系统回调通知结果。如果要求实时响应（比如聊天），同步架构更简单，但要做好 30s+ 的等待处理。建议用 WebSocket + 流式输出，避免 HTTP 长连接超时。
LangGraph 的 LangGraph Server 可以直接部署为微服务，内置 Checkpointer 和 trace。如果团队熟悉 Kubernetes，用 Temporal 做编排层 + 任意框架做执行单元，是目前最灵活的组合。