AI Agent 生产部署实战：从 POC 到每天处理 10 万次请求的架构演进

2026 年 3 月，我们团队把一个 AI 审批系统从 POC 推到生产。第一天就挂了：凌晨 3 点，某个工具调用陷入重试循环，一晚上烧了 $47 的 API 费用，队列积压了 2 万条任务。复盘发现，问题出在三个地方——没有限流、没有超时熔断、没有预算控制。

AI Agent 上生产的头号事故不是模型答错，而是重试循环失控：一个未限流、未熔断、无预算上限的 Agent 一夜烧掉 $47、积压 2 万任务，这是 2026 年 3 月我们团队的真实踩坑记录。本文按 POC → 生产 V1 → V2 → V3 记录从「能跑」到「能扛」的完整演进，包含超时、重试、预算、事件溯源的具体配置与可复用指标。

本文要点

• AI Agent 生产事故第一因是重试循环，不是模型质量
• 超时、重试、限流三件套应在 POC 阶段就写好，成本几乎为零
• 预算控制比 API 单价更关键，80% 成本失控源于指令设计
• 事件溯源用 PostgreSQL 存 JSONB 事件流即可，无需额外 Event Store
• 2026 年可把限流、熔断、预算下沉到 AI Gateway 统一执行

一、POC 阶段的典型架构

大多数团队的 POC 长这样：一个 Python 脚本，调 LLM API，循环处理输入。没有持久化、没有重试策略、没有监控。核心逻辑大约 20 行，测试集 50 条数据，挂了 rerun 就行。

但上生产后，三个致命缺陷暴露了：没有超时（LLM 响应慢时，调用会 hang 住直到 TCP 超时，通常 60-120s）；没有重试（网络抖动导致 5xx 时直接抛异常）；没有限流（API rate limit 触发 429 后，全部失败）。

二、生产 V1：加基础防护

第一轮改造加了三个东西：超时控制、指数退避重试、并发限流。核心改动：用 AsyncOpenAI 替代 OpenAI，设置 timeout=30.0；用 tenacity 库做指数退避重试，最多 3 次，等待时间 2-30s；用 asyncio.Semaphore(10) 控制最大并发数。

这版上线后，p99 延迟从 27s 降到了 8s，429 错误基本消失。但新问题来了：成本不可控。某个指令设计不当导致 LLM 输出 8000 字符，单次调用花了 $0.15。每天 10 万次就是 $15,000。

这里要强调：重试循环是 Agent 的默认失败模式，而不是意外。TrueFoundry 2026 年 5 月的工程博客指出，如果每次重试都把上一步输出拼回上下文，4000 token 的初始上下文到第 5 步就膨胀到 128,000 token、单步成本涨 32 倍，到第 30 步的花费超过一名工程师的月薪。我们凌晨 3 点那 $47 就是这么烧出来的——不是模型贵，而是循环在无人值守时自己加速，越重试上下文越长、单次越贵。

三、生产 V2：加预算控制与监控

第二轮改造核心是「每一分钱都要看到去向」。

预算控制的实现思路：维护一个滑动窗口（最近 1 分钟）和一个日累计计数器。每次调用前估算消耗量，检查是否超过分钟/日限额。超限则直接拒绝并告警。同时用 Prometheus 暴露三个关键指标：llm_request_duration_seconds（histogram，按模型和状态分桶）、llm_token_consumed_total（counter，按模型分）、llm_budget_rejected_total（counter，预算拒绝次数）。

2026 年更省事的做法是把这层下沉到 AI Gateway。Portkey 2026 年 4 月的实践指南把 LLM 限流分成请求级（RPM）、令牌级（TPM）、成本级和租户配额四类，在网关统一执行可以避免每个服务各写一套限流策略导致的口径漂移；TrueFoundry 建议的网关三层是「按身份（用户/仓库/模型）的 token bucket → 按模式的熔断器（成本速度、重复提示、错误率、上下文膨胀）→ 声明式降级链（主模型 → 便宜模型 → 语义缓存 → 503）」，目标是「有界爆炸半径」——一个失控调用不影响其他租户和总预算。对单体服务来说，我们自己写的滑动窗口 + 计数器已经够用；当 Agent 数量变多、多租户接入时，网关层是比每个服务手写限流更可控的演进方向。

四、生产 V3：事件溯源与审计

金融场景要求每一步都有审计日志。我们选择了事件溯源模式：每个任务的完整生命周期被记录为一系列不可变事件。事件类型包括：Received（用户提交任务）、Invoked（调用 LLM，记录输入量）、Responded（LLM 返回，记录输出量和延迟）、Approved（人工审批通过）。

存储用 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」的条目，关联到对应的输入内容，定位指令设计问题。

五、关键经验总结

• 先加防护再上量：超时、重试、限流这三样在 POC 阶段就写好，成本几乎为零，生产出事再补就晚了。
• 预算控制比 API 单价更值得关注：我们踩的坑里，80% 的成本失控来自指令设计不当导致输出过长，而非模型单价。
• 可观测性要提前埋点：Prometheus + 结构化日志的组合，在排查「凌晨 3 点谁烧了 $47」这种问题时，能把定位时间从 4 小时缩短到 10 分钟。
• 事件溯源是金融场景的底线：没有审计日志，合规审查过不了。PostgreSQL 存 JSONB 事件流，简单可靠，不需要额外引入 Event Store。
• 限流预算可以下沉到网关：2026 年 AI Gateway 已把 token bucket、熔断、降级链变成声明式配置，避免每个 Agent 服务自己重复实现同一套逻辑。

六、常见问题（FAQ）

问：Semaphore 限流够用吗？生产环境用什么？
单机场景 Semaphore 够用，分布式生产环境建议用 Redis 的滑动窗口计数器 + 本地 bucket 两级限流，我们最终用的是 aiolimiter 库 + Redis 做全局协调。

问：事件溯源会不会太重？
看场景。如果只是日志审计，用结构化日志 + 日志中心（ELK/Loki）就够了。事件溯源的优势在于能还原状态——比如「用户看到的结果是什么」，而日志只告诉你「调用了什么 API」。

问：每天 10 万次调用，LLM 成本大概多少？
以 gpt-4o 为例，平均每次 500 input + 200 output，单价约 $0.0025/次，10 万次 ≈ $250/天；换成 DeepSeek-V4 或本地部署的模型，成本可以降到 $30-50/天。

问：异步架构和同步架构怎么选？
我们的场景是异步的——用户提交后，系统回调通知结果。如果要求实时响应（比如聊天），同步架构更简单，但要做好 30s+ 的等待处理，建议用 WebSocket + 流式输出，避免 HTTP 长连接超时。

问：2026 年有没有推荐的部署工具？
LangGraph 的 LangGraph Server 可以直接部署为微服务，内置 Checkpointer 和 trace；如果团队熟悉 Kubernetes，用 Temporal 做编排层 + 任意框架做执行单元，是目前最灵活的组合。

问：2026 年怎么做限流和预算控制？
想让限流、熔断、预算统一生效，2026 年主流做法是加一层 AI Gateway（如 TrueFoundry AI Gateway、Portkey），在网关按身份做 token bucket、按模式做熔断、声明式降级链，比在每个 Agent 代码里手写限流更可控。

参考

• 腾讯云开发者社区：8 大 AI 智能体开发框架全景指南（2026）
• Cordum：AI Frameworks Comparison 2026
• 亮数据：2026 年 12 大 AI 框架
• 知乎：2026 年 AI 智能体技术全景
• TrueFoundry: Rate Limiting AI Agents: Preventing LLM API Exhaustion（2026-05-12）
• Portkey: Rate limiting for LLM applications: Why it matters and how to implement it（2026-04-06）