上一篇文章讨论了 Agent 和 Tool 的安全治理。

安全治理解决的是系统能不能在清晰边界内运行。

但一个 AI 应用要真正落地，只做安全设计还不够。

它最终要被部署到服务器、容器平台或企业内部环境中。

很多 AI 应用项目的问题，不是在本地开发阶段暴露的，而是在上线后暴露的。

例如：

• 本地.env能用，线上环境变量没有配置完整。
• 本地 SQLite 能跑，线上数据库连接失败。
• 本地日志打印在控制台，线上找不到错误链路。
• 本地模型调用正常，线上经常超时。
• 本地只跑一个用户，线上并发后 Token 成本快速上升。
• 本地 Tool 调用可控，线上外部接口不稳定。
• 本地 Workflow 失败可以手动重跑，线上任务失败没有记录。

所以部署不是最后一步的简单操作。

部署设计本身就是 AI 应用工程化的一部分。

一、本地跑通不等于可以上线

很多 AI 应用最开始都是这样运行的：

python main.py

或者：

python app.py

这种方式适合验证想法。

但它不适合直接进入生产环境。

因为生产环境至少需要回答这些问题：

• 服务如何启动？
• 配置从哪里来？
• API Key 怎么管理？
• 数据库连接怎么配置？
• 日志写到哪里？
• 服务是否还活着？
• 模型调用失败怎么处理？
• Tool 调用失败怎么追踪？
• Workflow 中断后怎么恢复？
• 新版本如何发布？
• 出问题后如何回滚？

如果这些问题没有提前设计，上线后就会变成临时补丁。

AI Scaffold 的价值之一，就是让项目从一开始就具备接近生产环境的结构。

不是等 Demo 写完之后再补部署能力。

二、AI 应用部署的特殊性

普通后端服务部署，通常关注接口、数据库、缓存、日志和监控。

AI 应用在这些基础上，还多了几类问题。

第一类是模型调用问题。

例如：

• LLM API 超时。
• 模型返回内容不稳定。
• 不同供应商限流策略不同。
• Token 消耗不可忽视。
• 流式输出中断。

第二类是 Agent 和 Tool 问题。

例如：

• Agent 执行链路更长。
• Tool 调用可能依赖外部系统。
• 一次用户请求可能触发多个步骤。
• 失败点比普通接口更多。

第三类是上下文和状态问题。

例如：

• Memory 如何保存。
• Workflow 状态如何记录。
• 文件上传后放在哪里。
• RAG 文档索引如何挂载。

所以 AI 应用部署不能只理解为“把 Python 项目放到服务器上”。

它需要一套面向 AI 场景的运行结构。

三、部署前应该先整理项目结构

一个适合部署的 AI Scaffold 项目，目录结构应该比较清晰。

例如：

app/ ├── agents/ ├── config/ ├── llms/ ├── memory/ ├── observability/ ├── repositories/ ├── security/ ├── tools/ ├── workflows/ └── main.py prompts/ tests/ .env.example Dockerfile docker-compose.yml requirements.txt README.md

这里有几个关键点。

app/main.py是统一入口。

config/负责加载配置。

observability/负责日志和追踪。

repositories/负责数据访问。

tools/负责外部能力调用。

workflows/负责任务编排。

.env.example提供配置样例。

Dockerfile提供镜像构建方式。

docker-compose.yml提供本地或小规模部署方式。

如果项目结构一开始就混乱，部署时会非常痛苦。

部署不是只看命令能不能跑。

部署首先要求项目边界清楚。

四、环境变量要作为部署核心

AI 应用通常会依赖很多配置。

例如：

APP_ENV=production APP_HOST=0.0.0.0 APP_PORT=8000 LOG_LEVEL=INFO LLM_PROVIDER=openai LLM_MODEL=gpt-4o-mini LLM_TIMEOUT_SECONDS=60 LLM_MAX_RETRIES=3 DATABASE_URL=postgresql://user:password@db:5432/ai_app REDIS_URL=redis://redis:6379/0 UPLOAD_DIR=/app/data/uploads LOG_DIR=/app/logs

真实项目里，API Key 也会通过环境变量或密钥管理系统注入。

但不要把真实密钥写入.env.example。

.env.example只放占位符：

LLM_API_KEY=your_api_key_here

部署时需要遵守一个原则：

配置属于环境，不属于代码。

代码仓库可以提交配置模板。

但不能提交真实密钥。

Docker 镜像里也不应该写死密钥。

五、配置加载要有默认值和校验

环境变量不是简单读取就结束。

上线时最常见的问题之一，就是配置缺失或配置错误。

所以配置系统应该做校验。

例如：

frompydanticimportBaseSettingsclassSettings(BaseSettings):app_env:str="development"app_host:str="0.0.0.0"app_port:int=8000log_level:str="INFO"llm_provider:strllm_model:strllm_api_key:strllm_timeout_seconds:int=60llm_max_retries:int=3database_url:strupload_dir:str="/app/data/uploads"log_dir:str="/app/logs"

项目启动时，如果关键配置缺失，应该直接失败。

不要等到用户请求进来后才报错。

更好的方式是启动阶段做一次配置检查：

defvalidate_startup_settings(settings:Settings)->None:required=[settings.llm_provider,settings.llm_model,settings.llm_api_key,settings.database_url,]ifnotall(required):raiseRuntimeError("Missing required production settings")

生产环境里，失败得早比失败得晚更好。

因为早失败可以阻止错误版本继续运行。

六、Dockerfile 应该保持简单明确

AI Scaffold 项目的 Dockerfile 不需要一开始就设计得非常复杂。

重点是稳定、可复现、容易排查。

例如：

FROM python:3.11-slim WORKDIR /app ENV PYTHONDONTWRITEBYTECODE=1 ENV PYTHONUNBUFFERED=1 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8000 CMD ["python", "-m", "app.main"]

这里有几个注意点。

第一，不要把.env复制进镜像。

第二，不要把本地缓存、日志、上传文件打进镜像。

第三，启动命令要统一。

第四，生产依赖要明确写在requirements.txt或其他依赖文件里。

如果以后项目变复杂，可以再引入多阶段构建。

但在脚手架阶段，先提供一个清晰可用的默认 Dockerfile 更重要。

七、docker-compose 适合本地集成和小规模部署

对于很多个人项目、教学项目和早期团队项目，docker-compose.yml很实用。

它可以把应用、数据库、缓存放在一起启动。

例如：

services:ai-app:build:.ports:-"8000:8000"env_file:-.envvolumes:-./data:/app/data-./logs:/app/logsdepends_on:-dbdb:image:postgres:16environment:POSTGRES_DB:ai_appPOSTGRES_USER:ai_userPOSTGRES_PASSWORD:change_mevolumes:-db_data:/var/lib/postgresql/datavolumes:db_data:

这里的重点不是让所有生产环境都使用 docker-compose。

而是让开发者理解：

• 应用容器和数据库容器要分开。
• 配置通过环境变量传入。
• 数据目录要挂载。
• 日志目录要挂载。
• 数据库数据要持久化。

这些习惯对后续迁移到云服务器、Kubernetes 或企业平台也有帮助。

八、日志目录必须可持久化

AI 应用上线后，日志非常重要。

尤其是：

• 请求日志。
• LLM 调用日志。
• Tool 调用日志。
• Workflow 执行日志。
• 错误日志。
• 审计日志。

如果日志只打印到控制台，而部署平台没有采集，就很难排查问题。

如果日志写在容器内部，但没有挂载目录，容器重启后日志可能丢失。

因此可以约定：

/app/logs

作为容器内日志目录。

然后在部署时挂载到宿主机或日志采集系统。

例如：

volumes:-./logs:/app/logs

AI Scaffold 可以在模板里默认生成日志目录配置。

这样用户不会等到上线后才发现日志没有地方存。

九、上传文件和索引数据要独立管理

很多 AI 应用会处理文件。

例如：

• 文档问答。
• 简历分析。
• 合同审查。
• 知识库导入。
• 报告生成。

这些文件不能随便放在代码目录里。

可以约定：

/app/data/uploads /app/data/indexes /app/data/reports

分别存放上传文件、索引文件和生成报告。

部署时，这些目录应该挂载：

volumes:-./data:/app/data

这样容器重启或重新部署时，数据不会直接丢失。

如果项目进入更正式的生产环境，可以把文件迁移到对象存储。

但脚手架阶段至少要提供本地持久化目录。

十、健康检查接口不能省略

生产环境需要知道服务是否还活着。

所以 AI Scaffold 项目最好默认提供健康检查接口。

例如：

GET /health

返回：

{"status":"ok","env":"production"}

更进一步，可以提供：

GET /ready

用于检查依赖是否可用。

例如：

• 数据库是否可连接。
• Redis 是否可连接。
• 日志目录是否可写。
• 模型供应商配置是否存在。

健康检查关注服务进程是否存活。

就绪检查关注服务是否真的可以处理请求。

这两个概念最好区分开。

十一、LLM 调用要有超时和重试

AI 应用上线后，LLM 调用是高频故障点。

常见问题包括：

• 请求超时。
• 供应商限流。
• 网络波动。
• 返回内容为空。
• 流式响应中断。

所以 LLM 抽象层必须支持超时和重试。

例如：

classLLMClient:def__init__(self,timeout_seconds:int,max_retries:int):self.timeout_seconds=timeout_seconds self.max_retries=max_retriesdefchat(self,messages:list[dict])->str:forattemptinrange(self.max_retries):try:returnself._call_model(messages)exceptTimeoutError:ifattempt==self.max_retries-1:raise

真实代码会更复杂。

但设计原则很明确：

业务代码不应该直接处理不同模型供应商的超时细节。

这些能力应该放在 LLM 抽象层。

部署时通过环境变量控制超时和重试参数。

十二、上线后要关注成本

AI 应用部署后，成本不是小问题。

尤其是 Token 成本。

如果没有记录 Token 使用情况，就很难知道：

• 哪个接口最耗 Token。
• 哪个 Agent 调用最多。
• 哪个 Workflow 成本最高。
• 哪类用户请求导致成本上升。
• Prompt 是否过长。
• Memory 是否召回过多。

所以部署时要把成本观测纳入日志或指标。

例如记录：

trace_id user_id model prompt_tokens completion_tokens total_tokens latency_ms cost_estimate

这些数据不是为了好看。

它们决定了 AI 应用能不能长期运行。

一个本地 Demo 可以不关心成本。

生产环境必须关心。

十三、发布流程要可重复

如果每次上线都靠手动执行一堆命令，风险会很高。

至少应该整理一个可重复流程。

例如：

gitpulldockercompose builddockercompose up-ddockercompose logs-fai-app

更完整一点，可以包括：

1. 拉取代码。 2. 检查环境变量。 3. 构建镜像。 4. 启动服务。 5. 检查健康接口。 6. 查看启动日志。 7. 执行基础测试。 8. 观察错误告警。

如果团队规模更大，可以接入 CI/CD。

但无论用什么工具，核心目标都是一样的：

发布流程要可重复、可检查、可回滚。

不要让上线依赖某个人的记忆。

十四、总结

AI Scaffold 项目从本地运行走向生产环境，不只是补一个 Dockerfile。

部署设计应该同时考虑：

• 项目结构是否清晰。
• 配置是否通过环境变量管理。
• API Key 是否脱离代码和镜像。
• 配置加载是否有校验。
• Dockerfile 是否稳定可复现。
• docker-compose 是否能支持本地集成。
• 日志目录是否持久化。
• 上传文件和索引数据是否独立管理。
• 健康检查和就绪检查是否存在。
• LLM 调用是否有超时和重试。
• Token 成本是否可观测。
• Tool 和 Workflow 失败是否可追踪。
• 发布流程是否可重复。
• 出问题后是否容易排查和回滚。

对于 AI 应用来说，部署不是工程链路的尾巴。

它应该从项目生成阶段就被纳入设计。

这也是 AI Scaffold 这类脚手架应该提供默认部署模板的原因。

一个好的脚手架，不只是帮开发者快速开始。

更重要的是，帮助项目从一开始就朝着可运行、可维护、可上线的方向组织。

下一篇文章可以进入实战部分：从 0 到 1 做一个文档分析 AI 应用，把前面讨论过的配置、LLM、Workflow、Repository、日志、安全和部署串起来。