4.4 部署与扩展

4.4 部署与扩展

本节摘要：开发完成，上线才是开始。本节讲清智能体应用的部署形态（服务化、无服务器）、上线检查清单、扩展策略（水平扩展、按场景拆分），以及上线后的监控与迭代闭环。

本节导读

阅读完本节，你应当能够：

1. 选择部署形态
2. 完成上线检查
3. 设计扩展策略
4. 建立上线后监控
5. 跑通迭代闭环

一、问题与直觉

"代码写好了，怎么让它服务用户？"——智能体应用本质是"API 调用 + 状态管理"的服务。部署要考虑的不只是"跑起来"，还有并发、状态、监控、迭代。本节给出一条从"本地跑通"到"线上服务"的完整路径。

智能体应用部署和传统 Web 服务有一个关键区别：它的"计算"主要在外部（模型 API），你的服务只是编排层。这意味着两件事：第一，你的服务实例本身很轻，瓶颈在模型配额而不是 CPU；第二，请求会跨服务调用，延迟和失败都受外部影响，所以监控和兜底比传统服务更重要。

二、核心原理

部署的完整链路：

2.1 部署形态对比

三种形态不是互斥的：很多团队"容器化打包 + 无服务器运行"。选择的核心依据是团队运维能力和流量模型——流量平稳选容器，流量脉冲式波动选无服务器更省成本。

2.2 上线检查清单

密钥管理：走环境变量/密钥服务
错误兜底：三层策略已配
限流保护：防滥用
监控告警：延迟/错误/成本
日志追踪：可回溯
​

💡 关键直觉：上线的核心不是"能跑"，是"可控"——出问题能发现（监控）、能定位（日志）、能止血（兜底）。三个"能"齐了，才算上线。

三、工程实践要点

3.1 一个最小部署示例（概念）

# 概念：把智能体封装成 API 服务
from fastapi import FastAPI
from agents import Agent, Runner

app = FastAPI()
agent = Agent(name="线上助手", instructions="用中文回答。")

@app.post("/chat")
async def chat(message: str, session_id: str | None = None):
    result = await Runner.run(agent, message, session_id=session_id)
    return {"reply": result.final_output, "trace_id": result.trace_id}
​

服务化之后，前端、IM、语音管道都可以通过这一个接口接入。注意：服务进程要复用 Agent 定义（不要每次请求都重建），异步处理请求（不要阻塞事件循环），会话 ID 由调用方传入。

3.2 扩展策略

水平扩展的前提是"无状态"：实例之间不共享内存态，会话状态存外部存储，这样加实例才能真正分担流量。如果会话状态存在进程内存里，扩到 10 个实例，每个实例的"记忆"都是残缺的。

3.3 上线后监控指标

业务指标：成功率、满意度
技术指标：延迟、错误率、成本
模型指标：工具调用率、兜底率
​

⚠️ 常见坑：上线后只看"没崩"。智能体应用"没崩"不等于"答得好"——监控兜底率与转人工率，它们反映质量，不反映"是否活着"。

3.4 迭代闭环

上线 → 监控数据 → 发现问题 → 改进（指令/工具/模型）→ 灰度 → 全量
​

智能体应用上线不是终点，是"数据驱动迭代"的起点。每轮迭代都该有数据依据：转人工率高了，看 Trace 找原因；工具调用率低了，检查工具说明书；成本超了，调模型路由。

3.5 灰度发布

先小流量（10%）验证
观察指标无异常再全量
异常即时回滚
​

灰度对智能体应用尤其重要：模型行为有不确定性，新指令在 10% 流量上跑一天，比全量上线后"炸了"再回滚安全得多。灰度期间重点看质量指标（兜底率、转人工率），而不只是错误率。

3.6 上线后的常见风险清单

风险一 密钥泄露：上线前检查密钥是否写进代码或日志
风险二 状态丢失：重启后会话全没 → 确认会话存储在外置服务
风险三 成本失控：没有成本告警 → 设置单日成本上限
风险四 模型升级漂移：官方模型行为变化 → 用测试用例定期回归
​

四类风险对应四个"上线后必查项"，建议把检查清单贴在发布流程里，每次上线都过一遍。

本节速览

• 要点一：部署形态——服务、无服务器、容器
• 要点二：上线的核心是"可控"，三个"能"（发现、定位、止血）
• 要点三：扩展——水平、拆分、缓存，先无状态
• 要点四：监控三组指标——业务、技术、模型
• 要点五：没崩不等于答得好，看质量指标
• 要点六：迭代闭环——监控、改进、灰度、全量

工程链路全走通，第 5 章看生态与最佳实践——把前面的经验沉淀成"套路"。