《FDE前沿部署工程师实战教程》11 - 企业Agent部署实战：Docker、API Gateway与生产环境

本章关键词：Docker、Docker Compose、API Gateway、Nginx、企业内网、环境隔离、配置管理、Secret、日志、Monitoring、Agent部署

前面的章节，我们已经完成了一个企业Agent项目从：

客户问题 → 业务调研 → 场景识别 → Agent设计 → RAG → Tool → API → Prototype → PoC

的完整过程。

但对于FDE来说，PoC成功并不意味着项目结束。

真正困难的问题往往从这里开始：

这个Agent怎么部署到客户环境？

客户可能没有公网环境。

可能只有内网服务器。

可能不能直接访问互联网。

可能要求所有数据留在企业内部。

可能需要接入已有的SSO、API Gateway、数据库和日志平台。

甚至还会提出：

"这个AI系统出了问题，谁能看到日志？"
"模型API的Key放在哪里？"
"不同部门能不能看到不同的数据？"
"Agent能不能直接操作WMS？"

这些问题，才是真正的企业级AI部署问题。

因此：

FDE不仅要会开发Agent，更要会把Agent安全、稳定地部署到客户现场。

一、从Prototype到Production

一个Agent项目通常经历：

复制代码

Prototype
   ↓
PoC
   ↓
Pilot
   ↓
Production

四个阶段。

Prototype

主要验证：

能不能跑？

例如：

复制代码

用户
 ↓
Agent
 ↓
Tool
 ↓
WMS

PoC

验证：

在真实业务数据下是否有效？

例如：

复制代码

真实用户
 ↓
Agent
 ↓
真实API
 ↓
真实WMS

Pilot

验证：

小范围真实用户能不能稳定使用？

例如：

复制代码

仓库主管
仓库管理员
计划员

先选择10～50名用户。

Production

最终进入：

企业正式生产环境。

这时必须考虑：

复制代码

安全
稳定
性能
权限
监控
日志
备份
升级
故障恢复

二、为什么企业Agent不能直接"跑起来就算部署完成"

个人开发环境可能是：

复制代码

Windows
 ↓
Python
 ↓
IDE
 ↓
启动Agent

但企业生产环境通常是：

复制代码

用户
 ↓
企业网络
 ↓
SSO
 ↓
API Gateway
 ↓
Agent Service
 ↓
RAG / Tools
 ↓
Enterprise API
 ↓
ERP / WMS / MES

同时还需要：

复制代码

Monitoring
Logging
Audit
Security

所以：

企业部署的核心不是"启动程序"，而是建立一个可管理的运行环境。

三、企业Agent生产架构

一个典型架构可以设计为：

这个架构已经从：

AI Demo

进入：

Enterprise AI Application。

四、为什么FDE需要掌握Docker

FDE经常需要把Agent部署到不同客户环境：

复制代码

客户A
Linux
Docker

客户B
Linux
Kubernetes

客户C
Windows Server
Docker

客户D
企业私有云

如果直接依赖本机环境：

复制代码

Python版本
Node版本
依赖库
系统环境
环境变量

很容易出现：

"我这里可以运行，客户那里不能运行。"

Docker解决的核心问题就是：

把应用及其运行环境进行标准化封装。

五、Agent Docker化

例如Agent项目：

复制代码

agent/
├── app/
├── tools/
├── rag/
├── requirements.txt
├── .env
└── Dockerfile

Dockerfile可以定义：

复制代码

FROM python:3.12

WORKDIR /app

COPY requirements.txt .

RUN pip install -r requirements.txt

COPY . .

CMD ["python", "app/main.py"]

然后：

复制代码

源代码
 ↓
Docker Build
 ↓
Docker Image
 ↓
Docker Container
 ↓
Agent Service

这样客户现场只需要准备：

复制代码

Docker
+
配置
+
网络

即可运行。

六、为什么Docker Compose非常适合FDE PoC

企业Agent通常不只有一个服务。

例如：

复制代码

Agent
RAG
Vector DB
Redis
API Gateway

可以组成：

复制代码

                    Agent
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
       RAG          Redis        Gateway
        │
        ↓
    Vector DB

Docker Compose可以统一管理：

复制代码

docker compose up -d

一次启动多个服务。

对于：

PoC
小型企业部署
客户现场验证
Demo环境

非常实用。

七、生产环境为什么需要API Gateway

Agent不能直接暴露给所有用户。

错误的方式：

复制代码

用户
 ↓
Agent
 ↓
WMS

更合理的是：

复制代码

用户
 ↓
API Gateway
 ↓
Authentication
 ↓
Authorization
 ↓
Agent
 ↓
Tools
 ↓
Enterprise API

API Gateway承担：

身份认证
权限控制
流量控制
API路由
限流
日志
安全策略

因此：

Agent应该是企业应用的一部分，而不是一个裸奔的AI服务。

八、Nginx可以承担什么角色

在很多中小型企业部署中，可以使用Nginx作为入口层：

复制代码

Internet / Intranet
        ↓
      Nginx
        ↓
   Agent Service

例如：

复制代码

https://ai.company.local

由Nginx转发到：

复制代码

http://agent:8000

同时可以承担：

复制代码

HTTPS
反向代理
静态资源
基础限流
请求日志

九、企业内网部署

这是FDE非常常见的场景。

很多企业的数据不能直接暴露到公网。

例如：

这种模式的优势：

数据留在企业内部
降低数据外泄风险
更容易满足企业安全要求
方便访问内部业务系统

十、模型服务也可以采用不同模式

企业Agent不一定只有一种模型部署方式。

模式一：调用云端模型

复制代码

Agent
 ↓
Internet
 ↓
LLM API

优点：

部署简单
模型能力强
运维成本低

缺点：

存在数据出域问题
依赖网络
需要API Key管理

模式二：企业内部部署模型

复制代码

Agent
 ↓
Internal LLM API
 ↓
GPU Server
 ↓
LLM

优点：

数据可留在内网
可控性高

缺点：

GPU成本
模型运维
推理性能优化

模式三：混合架构

复制代码

                 Agent
                   │
           ┌───────┴───────┐
           ↓               ↓
      Internal Model    Cloud Model
           │               │
       敏感数据          通用任务

FDE需要根据客户：

数据安全
成本
网络
模型能力
延迟

进行选择。

十一、环境必须隔离

不要让开发环境直接连接生产环境。

至少应该：

复制代码

DEV
 ↓
TEST
 ↓
STAGING
 ↓
PRODUCTION

例如：

复制代码

开发环境
Agent Dev
WMS Test

测试环境
Agent Test
WMS Test

生产环境
Agent Prod
WMS Production

这样可以避免：

开发人员测试一个Tool，结果修改了真实库存。

这是非常严重的生产事故。

十二、配置管理

Agent通常需要大量配置：

复制代码

LLM_API_KEY
LLM_BASE_URL
DATABASE_URL
REDIS_URL
VECTOR_DB_URL
WMS_API_URL
ERP_API_URL

不要把这些信息直接写进代码。

错误方式：

复制代码

API_KEY = "xxxxxx"

正确方式应该使用：

复制代码

Environment Variables
Secret Manager
Configuration Service

例如：

复制代码

代码
 ↓
读取环境变量
 ↓
Secret
 ↓
运行

十三、为什么API Key不能写进代码

假设：

复制代码

Git Repository
      ↓
Source Code
      ↓
API Key

一旦代码泄露：

复制代码

攻击者
 ↓
获得API Key
 ↓
调用模型
 ↓
产生费用

甚至可能进一步访问：

复制代码

WMS
ERP
CRM

所以：

密钥必须与代码分离。

十四、企业Agent的权限设计

Agent进入生产环境之后，权限问题会变得更加重要。

例如：

复制代码

普通员工
 ↓
只能查询库存

仓库主管：

复制代码

查询库存
+
查询订单
+
生成补货建议

采购经理：

复制代码

查询
+
创建采购申请

管理员：

复制代码

完整权限

所以：

复制代码

User
 ↓
Role
 ↓
Permission
 ↓
Agent Tool
 ↓
API

十五、数据权限比功能权限更加重要

例如：

同一个Tool：

复制代码

get_inventory()

不同用户返回的数据可能不同。

A用户：

复制代码

华东仓

B用户：

复制代码

华南仓

总部用户：

复制代码

全国仓库

因此不能只判断：

"这个用户有没有库存查询权限？"

还需要判断：

"这个用户能查询哪些库存？"

这就是：

Data Permission。

十六、Agent不能绕过企业权限系统

一个危险架构：

复制代码

用户
 ↓
Agent
 ↓
直接访问数据库

更加合理：

复制代码

用户
 ↓
Agent
 ↓
Tool
 ↓
Authorization
 ↓
Enterprise API
 ↓
WMS

这样可以让企业原有：

身份体系
权限体系
数据权限
业务规则

继续发挥作用。

十七、Tool是生产环境的重要安全边界

例如：

复制代码

查询库存

风险较低。

但是：

复制代码

调整库存

风险很高。

因此可以设计：

复制代码

Tool
 ↓
Risk Level
 ↓
Permission
 ↓
Business Rule
 ↓
Risk Check
 ↓
Human Approval
 ↓
API

这就是上一章设计的安全链路在生产环境中的落地。

十八、日志系统

Agent上线后，一个非常现实的问题就是：

"刚才AI到底做了什么？"

传统应用通常记录：

复制代码

User
Request
Response
Error

但Agent还需要记录：

复制代码

User
 ↓
Prompt
 ↓
Agent Decision
 ↓
Tool Selection
 ↓
Tool Parameters
 ↓
Tool Result
 ↓
Final Answer

例如：

复制代码

用户：
"帮我找出库存不足的SKU。"

Agent：
调用 get_inventory

Tool：
返回1250条库存数据

Agent：
调用 get_safety_stock

Tool：
返回安全库存

Agent：
发现12个风险SKU

最终：
生成分析报告

这就是：

Agent Trace。

十九、Audit Log

普通日志主要用于：

排查问题。

Audit Log则用于：

追踪业务操作。

例如：

复制代码

谁
 ↓
什么时候
 ↓
通过什么Agent
 ↓
调用了什么Tool
 ↓
传递了什么参数
 ↓
执行了什么操作
 ↓
结果是什么

尤其是：

复制代码

库存调整
采购申请
订单取消
客户数据修改

必须保留审计记录。

二十、Agent Monitoring

生产环境需要监控：

基础指标

复制代码

CPU
Memory
Disk
Network

应用指标

复制代码

Request Count
Latency
Error Rate

AI指标

复制代码

Token Usage
LLM Latency
Tool Success Rate
Agent Task Success Rate
RAG Hit Rate

业务指标

复制代码

库存异常发现数量
补货建议数量
自动处理任务数量
人工介入数量

这样才能知道：

Agent到底运行得怎么样。

二十一、Agent性能问题

Agent和普通API最大的区别之一是：

一次用户请求可能产生多次模型调用。

例如：

复制代码

用户问题
 ↓
LLM
 ↓
Tool 1
 ↓
LLM
 ↓
Tool 2
 ↓
LLM
 ↓
Tool 3
 ↓
LLM
 ↓
最终答案

所以一次请求可能需要较长时间。

FDE需要关注：

复制代码

总耗时
LLM耗时
Tool耗时
API耗时
RAG耗时

最终找到：

到底慢在哪里。

二十二、Agent超时与重试

例如：

复制代码

Agent
 ↓
WMS API
 ↓
Timeout

不能无限重试。

可以设计：

复制代码

第一次失败
 ↓
Retry
 ↓
第二次失败
 ↓
Retry
 ↓
第三次失败
 ↓
Fallback

最终：

复制代码

Tool失败
 ↓
记录日志
 ↓
通知Agent
 ↓
Agent调整策略
 ↓
向用户说明

而不是让Agent陷入：

复制代码

调用
 ↓
失败
 ↓
调用
 ↓
失败
 ↓
调用
 ↓
失败

无限循环。

二十三、Agent的Fallback机制

例如模型服务不可用：

复制代码

Cloud LLM
    ↓
   Fail
    ↓
Internal Model

或者：

复制代码

Agent
 ↓
Tool失败
 ↓
读取缓存
 ↓
返回最近数据

也可以：

复制代码

AI无法执行
 ↓
人工处理

企业系统必须考虑：

AI失败以后怎么办？

二十四、升级策略

Agent上线以后一定会不断更新：

复制代码

Prompt
 ↓
Tool
 ↓
RAG
 ↓
Model
 ↓
Workflow

不能直接覆盖生产版本。

应该采用：

复制代码

Version 1.0
 ↓
Version 1.1
 ↓
Version 1.2

必要时：

复制代码

Production V1
        ↓
    Canary
        ↓
Production V2

出现问题时：

复制代码

V2
 ↓
Rollback
 ↓
V1

二十五、企业Agent发布流程

可以形成：

复制代码

代码开发
 ↓
自动测试
 ↓
Docker Build
 ↓
Image
 ↓
Security Scan
 ↓
Staging
 ↓
PoC验证
 ↓
Approval
 ↓
Production
 ↓
Monitoring

这实际上已经进入：

AI应用DevOps。

二十六、FDE现场部署流程

FDE来到客户现场后，可以按照以下步骤：

Step 1：确认基础环境

复制代码

CPU
Memory
Disk
GPU
OS
Docker
Network

Step 2：确认网络

复制代码

Agent → LLM
Agent → WMS
Agent → ERP
Agent → MES

Step 3：确认认证

复制代码

SSO
OAuth
JWT
API Key

Step 4：部署服务

复制代码

Docker
 ↓
Agent
 ↓
RAG
 ↓
Vector DB

Step 5：配置Tools

复制代码

WMS API
ERP API
MES API

Step 6：进行安全测试

复制代码

权限
数据权限
Tool风险
审计

Step 7：业务验收

复制代码

真实用户
 ↓
真实场景
 ↓
真实数据

二十七、企业Agent上线检查清单

FDE可以使用以下Checklist：

项目	检查内容
网络	Agent是否能访问必要系统
模型	LLM服务是否正常
RAG	知识库是否可用
Tool	Tool是否全部测试
API	API认证是否正常
权限	RBAC是否配置
数据权限	数据范围是否正确
安全	是否存在越权
日志	是否记录Agent Trace
审计	高风险操作是否留痕
监控	CPU/Memory/API是否监控
备份	配置和数据是否备份
回滚	是否存在旧版本
培训	用户是否完成培训

二十八、一次完整的生产请求

最终，一个真实请求可能经历：

同时：

复制代码

              ┌───────────────┐
              │   Audit Log   │
              └───────┬───────┘
                      ↑
                      │
User → Agent → Tool → API → System
                      │
                      ↓
                Monitoring

这才是一套真正可以进入企业生产环境的Agent。

二十九、FDE需要建立"部署思维"

开发人员经常关注：

复制代码

代码能不能运行？

FDE需要进一步关注：

复制代码

客户环境能不能运行？

然后继续问：

复制代码

网络通不通？
权限对不对？
数据安全吗？
出了问题怎么办？
日志在哪里？
怎么升级？
怎么回滚？
谁负责维护？

因此：

部署不是项目最后一步，而应该从方案设计阶段就开始考虑。

三十、从"AI项目"到"AI产品"

一个Agent如果只是：

复制代码

Python程序
+
Prompt
+
LLM

它更像一个：

AI Demo。

如果增加：

复制代码

Docker
API Gateway
Authentication
Authorization
RAG
Tools
Monitoring
Audit
Deployment

它才逐渐成为：

企业AI应用。

如果进一步增加：

复制代码

Multi-Agent
Tool Registry
MCP
Evaluation
Observability
Workflow
Agent Governance

最终就可以形成：

Enterprise AI Platform。

三十一、FDE完整技术能力地图

经过前11章，我们可以重新整理FDE技术能力：

这就是FDE真正的能力闭环。

三十二、FDE与传统AI开发的区别

传统AI开发：

复制代码

需求
 ↓
模型
 ↓
代码
 ↓
测试
 ↓
上线

FDE：

复制代码

客户现场
 ↓
业务问题
 ↓
场景判断
 ↓
Solution
 ↓
Prototype
 ↓
PoC
 ↓
Agent
 ↓
Integration
 ↓
Deployment
 ↓
Training
 ↓
Business
 ↓
ROI
 ↓
Continuous Optimization

所以：

FDE的核心能力，是把AI从实验室带到真实业务现场。

三十三、本章总结

本章重点解决了一个非常现实的问题：

Agent开发完成之后，如何真正进入企业生产环境？

我们从：

Docker
Docker Compose
API Gateway
Nginx
企业内网
云端模型
私有模型
环境隔离
配置管理
Secret
Authentication
Authorization
Data Permission
Tool安全
Logging
Audit
Monitoring
Fallback
Rollback

等多个方面，建立了一套完整的企业Agent部署思维。

完整架构可以浓缩为：

最终可以总结为一句话：

FDE不仅要让Agent"能运行"，更要让Agent"能安全运行、稳定运行、可监控运行，并持续产生业务价值"。

三十四、下一篇预告

下一篇将继续进入企业Agent更重要的一层：

《FDE前沿部署工程师实战教程》12 - 企业Agent安全体系：权限、数据、Tool与Human-in-the-loop

重点解决：

复制代码

谁可以使用Agent？
谁可以调用Tool？
Agent可以看到哪些数据？
哪些操作可以自动执行？
哪些操作必须人工审批？
如何防止Prompt Injection？
如何防止越权？
如何进行Audit？

最终建立：

复制代码

User
 ↓
Authentication
 ↓
Agent
 ↓
Tool Selection
 ↓
Tool Schema Validation
 ↓
Authorization
 ↓
Data Permission
 ↓
Business Rule
 ↓
Risk Check
 ↓
Human Approval
 ↓
API
 ↓
Enterprise System
 ↓
Audit Log

从而把FDE能力从：

"会部署Agent"

进一步提升到：

"会建设安全、可控、可审计的企业Agent"。