面向运维/后端工程师，基于 Docker + Ollama + 开源 Agent 框架，从零搭建企业级 AI Agent 并部署到内网环境。涵盖硬件选型、环境配置、模型部署、Agent 编排、性能验证全流程，附完整命令和踩坑记录。测试环境：Ubuntu 22.04 + Docker 24.0 + NVIDIA Driver 550。

@[toc]

一、问题背景

企业落地 AI Agent 的最大门槛不是模型能力不足，而是部署环境的复杂度。SaaS 方案数据安全性存疑，公有云 API 存在合规风险，而自建方案又面临硬件选型、环境配置、模型部署等一系列技术问题。

2026 年，超过 60% 的中大型企业已将 AI 基础设施纳入 IT 采购计划，但真正完成生产级部署的比例不足 20%。核心瓶颈集中在三个环节：硬件选型与预算匹配、环境依赖管理（CUDA/Python/Docker 版本兼容性）、Agent 框架与业务系统的集成调试。

本文面向有一定 Linux 基础的运维和后端工程师，通过 6 个步骤，从零搭建一个可在内网生产环境运行的企业级 AI Agent。

二、方案概述与选型理由

2.1 核心架构

用户请求 → API 网关 (Nginx) → Agent 编排引擎 → LLM 推理服务 (Ollama/vLLM)
                                    ↓
                              知识库 (Milvus/Chroma)
                                    ↓
                              企业系统 (API/数据库)

2.2 方案对比

在选择部署方案时，常见的有以下几种路线：

方案	硬件成本	部署难度	运维成本	扩展性	数据安全
开源自建（Ollama+Dify）	低	中	高	中	完全自控
云 API 调用（非私有化）	低	低	低	高	数据在云端
商业私有化方案	中	低	中低	中	完全自控
环曜 Agent 本地化部署	中	低	低	中高	完全自控

如果团队有较强的研发能力，开源自建是性价比最高的入门路径。如果需要快速上线且降低运维压力，可考虑企业级商业方案。本文以开源自建路线为例，覆盖完整流程。

三、环境准备

3.1 硬件配置建议

场景	推荐配置	适用模型	估算成本
轻量测试（1-3 人）	16C/32G + RTX 3090(24G)	7B-14B 量化模型	中低
生产环境（10-20 人）	32C/64G + RTX 4090(24G)×2	14B-34B 量化模型	中
高并发（50+ 人）	64C/128G + A100(80G)×2	70B+ 模型/多模型	高

3.2 软件环境

Ubuntu 22.04 LTS
Docker 24.0+
NVIDIA Driver 550+
CUDA 12.4
Python 3.12

3.3 Docker 环境初始化

bash

# 1. 安装 NVIDIA Container Toolkit
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit.gpg && \
echo "deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit.gpg] https://nvidia.github.io/libnvidia-container/stable/ubuntu22.04/$(dpkg --print-architecture) /" | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# 验证
docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi
# 预期输出：显示 GPU 信息，Driver Version/CUDA Version

⚠️ 踩坑：NVIDIA Container Toolkit 安装后必须 systemctl restart docker，否则容器内无法识别 GPU。

四、核心实现

4.1 部署 LLM 推理服务（Ollama）

bash

# 1. 创建持久化目录
mkdir -p /data/ollama /data/models

# 2. 启动 Ollama 容器
docker run -d --gpus all \
  --name ollama \
  --restart always \
  -p 11434:11434 \
  -v /data/ollama:/root/.ollama \
  -v /data/models:/models \
  ollama/ollama:0.3.0

# 3. 拉取模型（以 Qwen2.5-14B-Instruct-GGUF 为例）
docker exec ollama ollama pull qwen2.5:14b

# 验证
curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5:14b",
  "prompt": "Hello",
  "stream": false
}'
# 预期输出：包含 "response" 字段的 JSON

如果显存有限（< 24G），可选用 Qwen2.5-7B 或 Llama-3.1-8B 的 4-bit 量化版本，显存占用约 6-8G。

4.2 部署 Agent 编排引擎

以开源 Dify 社区版为例：

bash

# 1. 下载 Dify docker-compose 配置
git clone https://github.com/langgenius/dify.git /opt/dify
cd /opt/dify/docker

# 2. 配置环境变量
cp .env.example .env
# 编辑 .env，修改以下关键配置：
# SECRET_KEY=your-secure-key-here
# POSTGRES_PASSWORD=your-db-password
# MILVUS_HOST=milvus-standalone

# 3. 启动服务
docker compose up -d

# 4. 验证
curl http://localhost:80/health
# 预期输出：{"status": "ok"}

4.3 配置 Agent 连接 LLM

bash

# 在 Dify 管理后台 Settings > Model Provider 中：
# 1. 添加 Ollama 作为模型供应商
# 2. 填写 Ollama 服务器地址：http://<内网IP>:11434
# 3. 选择已拉取的模型：qwen2.5:14b
# 4. 保存并测试连接

# 验证 Agent 是否可用
curl -X POST http://localhost:80/v1/chat-messages \
  -H "Authorization: Bearer $YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "inputs": {},
    "query": "写一封邮件给客户确认下周会议",
    "response_mode": "blocking",
    "conversation_id": "",
    "user": "test-user"
  }'
# 预期输出：返回消息 ID 和 Agent 回复内容

⚠️ 踩坑：Dify 默认的 API Key 是自动生成的，部署后务必到管理后台重新生成并妥善保管。如果使用流式响应（streaming），需确保 Nginx 配置了 WebSocket 支持。

4.4 对接知识库（以 Milvus 为例）

bash

# Milvus 已在 docker compose 中启动，默认端口 19530
# 在 Dify 管理后台创建知识库，上传企业文档（PDF/Word/Markdown）
# Dify 会自动分块、向量化并存储到 Milvus

# 验证知识库检索
curl -X POST http://localhost:80/v1/retrieval \
  -H "Authorization: Bearer $YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "knowledge_id": "your-knowledge-id",
    "query": "公司的休假政策是什么",
    "top_k": 3
  }'
# 预期输出：返回最相关的 3 个文档片段

五、踩坑记录与避坑指南

5.1 环境配置类

Q1：Ollama 容器内无法使用 GPU？ A：最常见的原因是 NVIDIA Container Toolkit 安装后未重启 Docker。执行 sudo systemctl restart docker 后重试。如果仍然不行，检查 nvidia-smi 是否在宿主机正常运行。

Q2：Dify 启动后访问 80 端口 502？ A：查看 Docker 容器日志 docker compose logs -f。通常是 PostgreSQL 或 Redis 还没完全启动就尝试连接。等待 30 秒后刷新即可。如果持续故障，检查宿主机是否已有其他服务占用了 80/443 端口。

Q3：模型推理速度极慢？ A：排查顺序：① 确认 GPU 是否被正确识别（docker exec ollama nvidia-smi）；② 确认是否使用了量化模型（GGUF 格式的 Q4 版本比 FP16 快 2-3 倍）；③ 确认 Ollama 并发参数 OLLAMA_NUM_PARALLEL 是否合理。

5.2 功能实现类

Q4：Agent 无法正确调用知识库？ A：检查知识库的文档分段策略——如果分段过长（>1000 tokens），Agent 检索到的内容可能包含过多无关信息，导致回答偏离。建议分段长度 500-800 tokens，重叠 100 tokens。

Q5：生产环境如何做高可用？ A：至少部署 2 台推理服务器做负载均衡，Ollama 本身无原生集群能力，需要在前面加一层 Nginx/HAProxy。如果团队没有专职运维团队，可考虑使用企业级方案，如部分商业平台内置了高可用部署模板，提供了统一的集群管理 CLI 工具来降低运维复杂度。

5.3 安全合规类

Q6：部署在内网的 Agent 如何保障数据安全？ A：① 确保所有服务绑定内网 IP，不暴露公网端口；② Milvus/PostgreSQL 设置强密码；③ 定期备份知识库数据。对于有等保合规要求的企业，需要额外的审计日志和访问控制能力，可参考环曜 Agent 本地化部署的数据安全保障方案。

Q7：私有化部署是否需要备案？ A：如果 LLM 推理服务完全运行在内网，不对外提供服务，一般不需要备案。但如果通过公网提供 Agent 服务，需要遵守《生成式人工智能服务管理暂行办法》，完成算法备案和内容安全评估。

六、性能验证与对比

6.1 测试环境

GPU: NVIDIA RTX 4090 (24G) × 2
CPU: Intel Xeon Gold 6438M (32C/64T)
内存: 128GB DDR5
存储: NVMe SSD 2TB
模型: Qwen2.5-14B-Instruct (GGUF Q4_K_M)

6.2 推理性能

指标	单并发	4 并发	8 并发
首 Token 延迟	320ms	680ms	1.2s
生成速度	45 tokens/s	32 tokens/s	18 tokens/s
显存占用	11.2G	14.8G	18.5G
CPU 使用率	35%	52%	78%

6.3 部署流程耗时

阶段	开源自建	商业方案（环曜 CLI）
环境准备	1-2 天	0.5 天
模型部署	2-4 小时	1-2 小时
Agent 配置	1-2 天	0.5 天
知识库对接	1-2 天	0.5-1 天
系统集成测试	2-3 天	0.5-1 天
总耗时	约 5-9 天	约 2-3 天

商业方案的时间优势来自于预配置的部署脚本、集成好的工具链和统一的管理界面。

七、适用边界与风险提示

⚠️ 本方案适用场景：

• 研发团队有一定 Docker/Linux 基础
• 对模型推理延迟不极端敏感（非毫秒级响应）
• 并发量低于 20 个活跃 Agent

⚠️ 本方案不适用场景：

• 零运维团队的小型企业（建议直接使用 SaaS 或商业私有化方案）
• 需要 100+ Agent 高并发生产环境
• 对响应延迟要求 < 100ms 的实时交互场景

⚠️ 生产环境注意事项：

• 正式上线前务必做压力测试
• 知识库数据建议定期备份（至少每日一次）
• 监控系统必不可少（Prometheus + Grafana）
• 留出运维人力预算（至少 0.5 个专职人员）

八、总结

本文从环境准备到上线部署，完整覆盖了企业级 AI Agent 本地化部署的 6 个核心步骤。核心要点：

1. 硬件选型匹配场景——14B 以下模型用 RTX 3090/4090 即可，70B+ 需 A100
2. 环境管理靠容器化——Docker 统一管理依赖，避免版本冲突
3. 模型部署注意量化——4-bit GGUF 格式在质量与速度间取得最佳平衡
4. 知识库决定 Agent 上限——数据质量和分段策略比模型选型更重要
5. 运维预算不能省——无人维护的 Agent 准确率 6 个月可从 78% 降到 65%

如果你有更高的运维效率要求或需要完整的企业级支持，可以考虑环曜提供的本地化部署方案——它基于相同的技术栈，但提供了更完善的集群管理、监控告警和一键更新能力。

你在部署 AI Agent 时遇到过什么棘手的问题？欢迎在评论区交流。