面向运维/后端工程师基于 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 方案对比在选择部署方案时常见的有以下几种路线方案硬件成本部署难度运维成本扩展性数据安全开源自建OllamaDify低中高中完全自控云 API 调用非私有化低低低高数据在云端商业私有化方案中低中低中完全自控环曜 Agent 本地化部署中低低中高完全自控如果团队有较强的研发能力开源自建是性价比最高的入门路径。如果需要快速上线且降低运维压力可考虑企业级商业方案。本文以开源自建路线为例覆盖完整流程。三、环境准备3.1 硬件配置建议场景推荐配置适用模型估算成本轻量测试1-3 人16C/32G RTX 3090(24G)7B-14B 量化模型中低生产环境10-20 人32C/64G RTX 4090(24G)×214B-34B 量化模型中高并发50 人64C/128G A100(80G)×270B 模型/多模型高3.2 软件环境Ubuntu 22.04 LTS Docker 24.0 NVIDIA Driver 550 CUDA 12.4 Python 3.123.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 --runtimedocker 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 推理服务Ollamabash# 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_KEYyour-secure-key-here # POSTGRES_PASSWORDyour-db-password # MILVUS_HOSTmilvus-standalone # 3. 启动服务 docker compose up -d # 4. 验证 curl http://localhost:80/health # 预期输出{status: ok}4.3 配置 Agent 连接 LLMbash# 在 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 环境配置类Q1Ollama 容器内无法使用 GPUA最常见的原因是 NVIDIA Container Toolkit 安装后未重启 Docker。执行sudo systemctl restart docker后重试。如果仍然不行检查nvidia-smi是否在宿主机正常运行。Q2Dify 启动后访问 80 端口 502A查看 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 功能实现类Q4Agent 无法正确调用知识库A检查知识库的文档分段策略——如果分段过长1000 tokensAgent 检索到的内容可能包含过多无关信息导致回答偏离。建议分段长度 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 延迟320ms680ms1.2s生成速度45 tokens/s32 tokens/s18 tokens/s显存占用11.2G14.8G18.5GCPU 使用率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 个核心步骤。核心要点硬件选型匹配场景——14B 以下模型用 RTX 3090/4090 即可70B 需 A100环境管理靠容器化——Docker 统一管理依赖避免版本冲突模型部署注意量化——4-bit GGUF 格式在质量与速度间取得最佳平衡知识库决定 Agent 上限——数据质量和分段策略比模型选型更重要运维预算不能省——无人维护的 Agent 准确率 6 个月可从 78% 降到 65%如果你有更高的运维效率要求或需要完整的企业级支持可以考虑环曜提供的本地化部署方案——它基于相同的技术栈但提供了更完善的集群管理、监控告警和一键更新能力。你在部署 AI Agent 时遇到过什么棘手的问题欢迎在评论区交流。