AI智能体服务生产部署指南：从准备到稳定运维

一、目标架构

本文描述如何把一个面向业务的AI智能体服务部署到生产环境。这类服务接收业务任务，调用模型推理接口、检索业务数据和外部工具，按步骤执行并返回结果。上线后应满足四项要求：外部请求可以正常访问；多步骤任务在中断后能从最近的检查点续跑；异常发生时触发告警，并能按预案回滚；资源用量和模型调用成本可以被持续观测。

系统由以下部分组成：

• 接入层：负载均衡终止TLS连接，把请求分发到API实例。
• API服务：无状态，负责鉴权、接收任务和查询状态，可以水平扩展。
• 任务执行器：有状态的工作进程。它从消息队列取任务，按步骤执行，并把每一步的结果写入任务状态存储。执行器不暴露公网，与API服务分开部署。
• 依赖服务：模型推理接口、关系型数据库（存放任务状态）、缓存、消息队列、对象存储。
• 密钥管理服务：保存模型访问密钥和数据库口令。

API服务与执行器拆分是最关键的设计决策。API的响应时间应保持在较短范围内，而单个执行器任务可能运行数分钟到数十分钟。两者若放在同一进程中，长任务会占满线程或连接，拖累所有请求。

二、资源、安全与环境清单

2.1 资源规划

资源规划应以压测结果为准，不要直接套用他人的经验值。API实例数可以按下面的思路估算：

实例数 = 峰值QPS × 单请求平均耗时 ÷ 单实例可并发处理数 × (1 + 冗余系数)

各参数的测量口径如下：

• 峰值QPS：取业务日志中连续5分钟内的最大请求速率，不取单秒峰值。
• 单请求平均耗时：压测时同一接口的平均响应时间，只统计成功请求。
• 单实例可并发处理数：在单实例压测中，CPU和内存使用率低于团队设定的安全水位（例如70%），且错误率在允许范围内时，能稳定维持的最大并发数。
• 冗余系数：用于应对单实例故障和流量突增。可用性目标越高，取值越大。该值由团队根据可用性目标和故障域数量确定。剩余实例必须能在一个故障域失效时仍承载峰值流量。

执行器资源按同时运行的任务数和单任务内存占用估算，并设置并发上限。并发上限应小于模型接口的配额，防止下游被打满。

存储容量按每日任务数、单条记录大小和保留天数估算，再加上日志和备份所需空间。网络带宽按调用量乘以平均报文大小计算出口流量，模型请求和响应的报文通常较大，不能忽略。

2.2 安全与权限

• API服务和执行器使用各自独立的服务身份，只授予它们访问所需数据库表和存储桶的权限。
• 模型访问密钥和数据库口令通过密钥管理服务注入运行时环境变量。它们不得写入镜像、配置文件或代码仓库。密钥定期轮换，每次读取都要留下审计日志。
• 安全组只开放必要端口。数据库、缓存和消息队列不允许公网访问。执行器的管理端口只允许API服务所在的安全组访问。
• 日志中屏蔽密钥、手机号等敏感字段。

2.3 网络与域名

• 域名解析指向负载均衡入口，TTL设为较短的值（例如60秒），便于切换。
• 证书由接入层统一管理，到期前配置告警，提前期由团队确定。
• 证书轮换前，先在测试环境演练一次：导入新证书，确认TLS握手正常，然后再切换生产环境。

2.4 环境一致性

• 开发、测试、生产使用同一基础镜像版本。依赖通过锁定文件固定，例如Python项目使用带哈希的requirements文件，Node.js项目使用package-lock.json。
• 同一版本的应用包只构建一次，逐环境晋升，不在每个环境重新构建。
• 配置中心的键名统一为 <服务名>.<环境>.<配置项> 格式，例如 task-api.prod.executor.max_concurrency，避免不同环境的配置串用。

#