Demo 阶段的 Agent 长这样：一个 Python 脚本，调 LLM API，循环执行，打印结果。

生产环境的 Agent 要面对的是另一组问题：并发上来了怎么办、模型服务挂了怎么办、Token 账单失控了怎么办、用户数据泄露了谁负责、上线一个新 Prompt 版本把老功能改崩了怎么办。

Demo 和生产之间差的不是"更强的模型"，是一整套部署架构。

生产级 Agent 的骨架

一个典型生产级 Agent 系统可以拆成五层，每层职责清晰：

┌─────────────────────────────────┐
│ 接入层  负载均衡 · 认证鉴权 · 路由 │
├─────────────────────────────────┤
│ 应用层  推理引擎 · 工具编排 · 状态管理│
├─────────────────────────────────┤
│ 服务层  LLM推理 · 向量库 · 缓存     │
├─────────────────────────────────┤
│ 数据层  对话历史 · 用户数据 · 知识库 │
├─────────────────────────────────┤
│ 监控层  全链路指标 · 告警           │
└─────────────────────────────────┘

应用层内部通常再拆微服务：

• Agent Service：核心推理
• Tool Service：工具调用管理（和核心解耦，工具单独扩缩容）
• Memory Service：记忆与知识
• Auth Service / Gateway：认证与网关

四个设计决策

决策 1：状态外置（无状态化） 把会话状态放到外部缓存或数据库，Agent 实例本身无状态——这是水平扩展的前提。有状态实例没法随意杀掉重启，K8s 的自动扩缩容就无从谈起。

决策 2：异步化长任务 Agent 任务动辄跑几十秒甚至几分钟。同步等待会把连接池拖垮。正确姿势是扔进消息队列，返回 task_id，客户端轮询或订阅结果。

决策 3：熔断与降级 LLM 推理是整个链路里最不稳定的一环（延迟波动大、偶发超时）。当下游故障时快速失败，而不是让请求无限排队——然后把请求降级到小模型或缓存应答。这套思路后端工程师在微服务时代早就练熟了，只是对象换成了模型服务。

决策 4：多级缓存 高频相似问题的缓存命中能砍掉大比例的 LLM 调用成本（L1 内存 + L2 分布式），这是 Agent 应用独有的成本杠杆——传统应用缓存的是计算结果，Agent 应用连"推理结果"都是可缓存对象。

Agent 比传统应用多出来的要求

传统 Web 安全那一套（TLS、WAF、RBAC）照搬之外，Agent 场景有三个新增要求：

1. 密钥管理：LLM API Key 是真金白银，必须集中管理、定期轮换，绝不能散落在配置文件里
2. 日志脱敏：对话日志里全是用户敏感信息，入库前脱敏是底线
3. 审计日志：每一次敏感操作（工具调用、数据访问）全量留痕——未来出问题回溯举证全靠它

CI/CD：Agent 应用独有的"评测关"

这是与传统应用发布流程差异最大的一环。Agent 的 CI/CD 流水线在单元测试、集成测试之后，必须多加一道"Agent 评测"：

push → 单元测试 → 集成测试 → Agent 评测 → 构建镜像 → 金丝雀发布 → 全量

为什么？因为 Prompt 是"逻辑"，改 Prompt 等于改代码。没有评测集把关，一次"看起来无害"的 Prompt 微调就可能让 10% 的 case 行为漂移——而且单元测试对此一无所知。

发布策略上，金丝雀（小流量验证）+ 特性开关（快速关闭新能力）+ 快速回滚三件套，一个都不能少。版本管理的对象不只是代码，还包括 Prompt 模板和模型版本。

监控体系：多了一层"LLM 指标"

传统监控盯 CPU/内存/QPS，Agent 生产系统要多盯三层：

• 基础设施层：常规资源指标
• 应用层：请求量、延迟、错误率
• LLM 层：Token 消耗（成本）、模型延迟分布、幻觉率/任务完成率（业务质量）

其中 LLM 层是 Agent 特有的——Token 消耗就是成本仪表盘。

给准备上线的团队一份检查清单

• 状态已外置，实例可水平扩展
• 长任务已走异步队列
• LLM 调用配了超时、熔断、降级路径
• 多级缓存策略已上线（先解决最贵的 20% 请求）
• 流式响应已开启（首字节延迟是体验生命线）
• CI/CD 里有评测集关卡，Prompt 纳入版本管理
• Token 消耗、审计日志接入监控