AI Agent 工程实践（31）：Agent 如何部署

系列：AI Agent 工程实践

上一篇：第 30 篇《Agent 如何做测试》

下一篇：第 32 篇《Agent 如何上线》

一、开场：把 Agent 跑在笔记本上

一个团队做完 Demo，老板说"明天给客户演示"。工程师把服务 python app.py 跑在自己笔记本上，开着不关。演示到一半，系统自动更新重启，服务没了；客户想"能不能并发试试"，两个人同时发消息就 502。

这不是段子，是 Agent 项目的典型死亡方式：本地能跑 ≠ 生产能服务。

上篇（30）讲测试，保证"改了不崩"。这篇讲"怎么让它一直活着还能扛量"------部署。

二、问题背景：本地跑 vs 生产部署

本地跑：

# app.py 直接 python app.py
from fastapi import FastAPI
app = FastAPI()

@app.post("/chat")
async def chat(req): ...

# 终端里 python app.py，关掉就没了

生产部署要解决四件事： 环境可复现、进程可恢复、流量可承接、算力可调度。这四件事，靠 python app.py 一个都解决不了。

三、错误尝试：三种部署翻车

错误 1：nohup python app.py 裸跑

进程挂在登录 shell 下，退出登录就死；崩了没人拉起；端口直接暴露公网，没有 SSL、没有限流。

错误 2：推理和 API 混在一个进程，还硬要 GPU

Agent 服务本身是 CPU 密集（编排、IO、拼接 prompt），只有"自己部署模型推理"才需要 GPU。很多人不管用没用云 API，先买显卡堆机器，浪费钱也浪费运维。

错误 3：不容器化，环境靠手动同步

"我本地能跑"------因为依赖版本、系统库、环境变量全在工程师机器上。换台机器就飘，协作和回滚都成噩梦。

四、关键观察：部署 = 六个独立决策轴

部署不是"选一个方案"，而是六个正交的决策，每个都可以独立选：

1. 服务入口（FastAPI）：怎么把 Agent 暴露成 HTTP 接口。
2. 环境封装（Docker）：怎么让环境可复现、可迁移。
3. 流量入口（Nginx）：SSL、负载均衡、静态资源、限流。
4. 算力来源（GPU）：是否自托管推理------大多数情况不需要。
5. 编排调度（K8s）：多副本、自愈、扩缩容。
6. 弹性形态（Serverless）：不想管服务器、流量稀疏时。

关键：GPU 和 Serverless 是互斥的常见误用------自托管推理才要 GPU，事件驱动才要 Serverless，多数 Agent 走"云 API + Docker + Nginx"就够。

五、最终方案：六组件职责与适用边界

组件	负责什么	你必须用它当	可以不用的信号
FastAPI	异步 HTTP 服务、并发处理请求	要做 Web 服务	纯离线脚本
Docker	环境封装、可复现、隔离	任何要迁移/协作的场景	单文件脚本自用
Nginx	反向代理、SSL、负载均衡、限流	暴露公网、多副本	内网单实例
GPU	自托管模型推理的算力	自己部署开源大模型	调云 API（绝大多数）
K8s	多副本编排、自愈、弹性扩缩	高可用、规模化	一两台机器够用
Serverless	事件触发、按量计费、免运维	流量稀疏、突发	长连接/常驻服务

反直觉的一点：90% 的 Agent 项目不需要 GPU，也不需要 K8s。它们调的是云 API（如 DeepSeek、OpenAI），算力在对方机房；自己只跑编排逻辑，CPU 足够。GPU/K8s 是"自建推理 + 规模化"才需要的重型装备，过早引入只会拖慢你。

六、架构图（Mermaid）

请求全生命周期：

如果用 Serverless，FastAPI 容器换成函数实例，由平台接管扩缩；如果自托管推理，Provider 指向本地推理服务跑在 GPU 节点。

七、代码与配置示例

Dockerfile（最小可复现）：

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple
COPY . .
EXPOSE 8000
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

docker-compose（本地多容器）：

services:
  api:
    build: .
    ports: ["8000:8000"]
    environment:
      - PROVIDER_API_KEY=${PROVIDER_API_KEY}
    depends_on: [redis]
  redis:
    image: redis:7

Nginx 反向代理（SSL + 限流）：

server {
    listen 443 ssl;
    location /api/ {
        proxy_pass http://127.0.0.1:8000/;
        limit_req zone=one burst=20;
    }
}

八、设计权衡：自建推理 vs 云 API vs Serverless

维度	云 API	自托管推理(GPU)	Serverless
起步成本	低	高（显卡/机房）	极低
运维负担	无	重	无
数据出域	过第三方	不出域	视厂商
延迟可控	中	高	冷启动高
适用	绝大多数 Agent	合规/量大/私有模型	稀疏流量/事件

选型原则：默认云 API + Docker + Nginx；只有"数据不能出域"或"量足够大摊薄显卡成本"才上 GPU；只有"请求极稀疏、不想养服务器"才上 Serverless。不要反过来------先上重型装备再找理由。

九、总结

• ✅ 本地 python app.py ≠ 生产部署，差的是环境可复现 / 进程可恢复 / 流量可承接 / 算力可调度。
• ✅ 三种翻车：裸跑 nohup、推理 API 混进程硬堆 GPU、不容器化环境飘移。
• ✅ 部署 = 六决策轴：FastAPI / Docker / Nginx / GPU / K8s / Serverless，各自独立选。
• ✅ 反直觉：90% 的 Agent 不需要 GPU 也不需要 K8s------它们调云 API，自己只跑编排。
• ✅ 选型默认「云 API + Docker + Nginx」，重型装备按需上。

下一篇，部署完别急着全量------怎么上线才安全。（32）

---

参考资料（带用途说明）

• 本系列（30）Agent 如何做测试：部署前假设测试护栏已就绪，本文是上线前的倒数第二步。
• 本系列（22）Agent 项目应该如何分层：本文 FastAPI / Docker 落点都在（22）的分层目录里。
• 本系列（19）从 Demo 到生产环境 Checklist：部署是 Checklist 的关键一环，呼应上生产清单。
• 本系列（27）日志系统：容器化后日志收集方式会变化，部署需配合日志方案。
• FastAPI 文档（fastapi.tiangolo.com）：异步服务框架的实现参考。
• Docker 文档（docs.docker.com）：容器化与镜像构建实践参考。
• Nginx 文档（nginx.org）：反向代理与限流配置参考。

---

本文是 AI Agent 工程实践系列的第 31 篇（第四阶段第十一篇）。

---

系列导航

上一篇：第 30 篇《Agent 如何做测试》

下一篇：第 32 篇《Agent 如何上线》