企业官网建设流程全解析

上周刚帮一家制造集团完成“实在 Agent”的私有化部署，从网络规划到模型服务调通整整忙了一周。期间有不少朋友在问：像这种企业级 AI 智能助理，到底能不能装到自己机房？数据安不安全？算力要求是不是高得吓人？

今天就围绕“实在 Agent 支持本地化部署吗”这个话题，把这几年在私有化 AI 项目里摸出来的经验完整拆一遍。先说结论：支持，而且已经有了一套相当成熟的私有化交付体系。但这里有个关键认知要摆正——“支持本地部署”不代表“拿个安装包双击就能跑”。它需要企业具备一定的算力基础、网络规划和运维能力，交付形态也远不止一种。本文会从业务驱动、架构组件、模型选型、算力估算、实操步骤、问题排查六个层面展开，如果你是企业的技术决策者、运维负责人或解决方案架构师，这篇文章应该能帮你少踩几个大坑。

1. 为什么企业非要折腾私有化部署

先聊一个更底层的问题：为什么很多企业放着成熟的 SaaS 版不用，非得在本地机房或者专有云里再造一套？答案绕不开三个字——安全感。

1.1 数据资产不能出“门”

“实在 Agent”在使用过程中会接触大量企业内部数据：订单信息、客户名单、财务报表、生产工单、维修记录……这些数据在 SaaS 模式下会传输到第三方云服务器，即使合同里写明“数据加密”“用完即删”，很多企业的合规部门依然不放心。尤其是金融、政务、能源、医疗这几个行业，内部审查非常严格，属于典型的“数据不出域”场景。我接触过的一家银行客户，要求所有员工与 AI 助理的对话记录、知识检索日志、任务执行痕迹必须留在内网审计系统里，一条都不能外传。这种诉求只有私有化部署能满足。

第二个驱动因素是网络可靠性。制造业工厂的车间网络时不时会抖动，跨地域分支机构的专线带宽也有限。如果对话和推理都在云上完成，一旦上行链路拥堵，一线工人问设备故障处理办法时等上十几秒，体验会非常糟糕。私有化部署后，整个链路在企业内网闭环，不依赖公网链路，稳定性和响应速度都更有保障。

1.2 私有化不等于“只有一个选项”

很多人对“私有化部署”的理解是：买一台 GPU 服务器，装个环境，完事。真实的交付场景要复杂得多，也灵活得多。基于我实际的交付经验，“实在 Agent”的本地化部署至少存在三种常见形态：

这里要特别提醒一句：企业在和售前沟通时，一定要把自己的约束条件（网络状况、预算上限、数据合规要求、后期扩容计划）讲清楚，否则很容易出现“方案很美、落地很痛”的局面。

1.3 私有化的真正门槛不在软件在算力

软件层面，“实在 Agent”的私有化版本已经比较成熟，容器化打包、一键安装、可视化运维都做得不错。真正的门槛在硬件：你需要在机房或私有云环境里备齐 GPU 服务器，并根据并发量、知识库规模、模型参数量估算出合理的显存和内存配置。GPU 服务器采购周期长、价格高，这是无法回避的成本。所以，评估私有化是否可行，第一步不是谈功能，而是先盘算手里有多少算力预算。这部分我放到第 3 节详细拆。

2. 私有化版本的“实在 Agent”技术架构拆解

企业级 AI 智能助理不是一个大模型孤零零跑在那里就完事的。它要能听得懂问题、查得到资料、调得动系统、说得清结果。落到私有化环境里，这套系统至少由四个层次构成。

2.1 交互层与统一入口

用户在网页端、企业微信、钉钉或内部 OA 里打开“实在 Agent”，本质上是通过一个前端对话客户端在跟系统交互。私有化部署时，这个前端入口建议挂在企业内网域名下，并通过 SSO（单点登录）与内部账号体系打通。这样做有两个好处：一是账号权限可以沿用企业原有的组织架构，离职员工自动失去访问权限；二是所有访问行为都能记录到统一日志里，满足审计要求。我见过有些项目跳过 SSO 对接，单独维护一套用户体系，结果半年后账号管理一团糟，这个环节千万不要图省事。

2.2 认知层：意图理解与任务规划

这一层是“实在 Agent”的大脑所在。用户的提问进来后，系统要做意图识别、实体抽取、任务拆解，并决定下一步是调用工具、检索知识库，还是直接生成回答。私有化部署时，这一层通常由一个 Agent 运行时框架承载，框架内部接入了大语言模型推理服务。推理服务的质量直接决定整个系统的智能化水平，所以模型选型和推理加速是本层的关键。关于模型怎么选、显存怎么算，我会在第三节重点展开。

2.3 执行层：工具调用与系统集成

智能助理不能只聊天，还得干活。所谓“干活”，是指调用内部系统完成具体动作，比如查询 ERP 里的库存、创建一条审批流程、在工单系统里派发任务、控制某个自动化脚本执行。私有化环境下，这些动作通过两种方式完成：一是 API 接口对接，企业内部系统提供 HTTP 接口供 Agent 调用；二是 RPA（机器人流程自动化）方式，对没有接口的老旧系统，通过模拟人工操作完成流程。执行层相当于 Agent 的手和脚。数据敏感度越高，执行层的权限管理就越要精细。我通常建议为每个工具设置独立的调用凭证，并且限定工具的可见范围——某些操作只开放给指定角色，而不是所有员工都能用“实在 Agent”调取财务数据。

2.4 数据层：私有知识库与向量检索

智能助理要回答企业专属问题（比如“XX型号设备的保养周期是多长”），依赖预先构建的企业知识库。私有化部署时，知识库的数据处理流程：文档解析 → 切片 → 向量化 → 存入向量数据库，全套在企业内部完成。原始文档不用传给任何外部服务，这正好呼应了第一节提到的数据安全诉求。向量数据库的选择很多，开源的如 Milvus、Qdrant、ChromaDB 都可以。如果知识库规模不大，几千条切片级别，单机版的 ChromaDB 或 Qdrant 完全够用；如果到了几十万条切片的规模，建议上分布式向量库，并且把索引和存储分离开来。

这四个层次之间不是孤立存在的，它们通过内部消息总线和服务调用链连接成一个整体。私有化部署和 SaaS 版的本质差异，从前端到后端、从模型到数据，每一个环节都部署在企业可控的网络边界之内，不依赖外部服务。这也是为什么私有化版本在合规审查时更容易通过——数据全程没出门。

3. 模型选型与算力评估：这一步决定项目成败

算力评估是私有化项目里最容易被低估的环节。模型选大了，卡不够用；选小了，效果不理想。我自己在项目初期就吃过亏，后来总结了一套评估流程，先看业务需求再反推硬件配置。

3.1 开源模型还是商用模型授权

“实在 Agent”的私有化版本在模型层一般有三种搭配方案：完全使用开源模型、购买商业模型私有化授权、开源模型加微调或 RAG 增强。从这几年的发展趋势看，大部分企业选择了第一种或第三种，因为开源模型迭代速度快，社区生态好，且无需按调用量付费。商业模型私有化授权的优势是开箱即用、中文能力通常更强，但授权费用不低，适合预算充足且对模型效果要求极高的企业。

这里插一句我对开源模型的实际感受：新一代开源大模型的通用能力已经很能打了，在垂直业务场景中，只要知识库构建到位、提示词工程做扎实，完全可以通过 RAG（检索增强生成）达到可用的水平，不一定非要微调。我做过一个制造企业的设备维护助手，直接用基座模型加 RAG，在回答设备故障排查类问题上，准确率完全能满足一线维修工的日常需求。

3.2 显存估算的实战公式

很多人问：部署一个模型到底需要多大显存？我给出一个简易估算方式：

权重显存 =（参数量 × 每个权重占用的字节数）÷ 1024³

• FP16（半精度）：每个权重占 2 字节
• INT8（8 位量化）：每个权重占 1 字节
• INT4（4 位量化）：每个权重占 0.5 字节

举例来看：一个 7B 模型，用 FP16 加载，权重约 14GB；用 INT8 量化后约 7GB；用 INT4 量化后约 3.5GB。但这只是权重部分。实际推理时还要算上 KV Cache（键值缓存）和中间激活值，这部分通常需要再预留 20% 到 40% 的显存。所以一个 7B 模型用 INT8 部署，建议至少配一张 16GB 显存的显卡；13B 模型 INT8 部署，建议 24GB 起步；72B 级别的大模型，即使 INT8 量化后权重约 72GB，加上缓存和激活值，单卡基本扛不住，需要多卡张量并行（比如 4 张 24GB 或 2 张 80GB）。

按照我的经验，真实企业场景里最多的是 7B 到 14B 这个区间。以 100 人规模的企业为例，同时在线并发如果控制在 10 到 20 人，一张 24GB 显存的卡部署 13B INT8 模型就能跑得比较平稳。这里说的“平稳”指单轮回答延迟在 3 到 5 秒以内，超过这个感知就会明显变差。

3.3 推理加速框架的搭配

模型加载好了，并发提升还要靠推理加速框架。裸用 Transformers 库做推理，显存利用率不高且并发能力有限。我的习惯是搭一套 vLLM 或 TensorRT-LLM 推理服务，然后通过 OpenAI 兼容的 API 接口供“实在 Agent”调用。

用 vLLM 启动一个模型的命令大致是这样：

python -m vllm.entrypoints.openai.api_server \ --model /data/models/llama-13b-chat \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 32 \ --port 8000

其中tensor-parallel-size在多卡环境里设置为卡数，gpu-memory-utilization表示允许框架使用 GPU 显存的比例，max-num-seqs决定并发序列数。这个组合下来，响应吞吐量比裸推理能提升好几倍。遇到显存不足的时候，把max-num-seqs调小，优先保证单请求的响应速度，这是一个很实用的止损手段。

3.4 CPU、内存和存储也不可忽视

GPU 是主角，但配角配置不够同样会拖后腿。CPU 建议至少 16 核，负责数据预处理、API 调用和调度逻辑；内存方面，跑 7B 到 13B 模型我建议 32GB 起步，如果知识库比较大、向量检索和文档解析也在同一台机器上运行，建议直接上 64GB。存储则建议用 NVMe SSD，因为模型文件动辄十几个 GB，知识库索引和日志的频繁写入对磁盘 IO 要求很高。项目部署时我习惯把模型文件、向量索引、日志目录放到不同分区，避免日志写满导致模型文件所在分区出问题。

4. 实操落地：从零开始部署一套私有化“实在 Agent”

前面讲了架构和算力，这部分落到实际操作。为了让过程更清晰，我把整个交付流程拆成六个阶段，每个阶段给出关键步骤和注意事项。

4.1 环境规划与网络隔离

先把网络拓扑定下来。“实在 Agent”相关组件建议部署在一个独立网段或单独的 Kubernetes 命名空间内，与业务生产环境之间通过防火墙策略控制访问关系。要梳理清楚：

• GPU 推理服务器放在哪个网段
• 应用服务器和数据库服务器放在哪个网段
• 员工访问 Agent 的入口域名解析到哪台负载均衡器
• 哪些端口需要对外部开放，哪些必须禁止

以实际项目为例，某制造企业的架构是：员工从办公网访问agent.internal.example.com，通过内部 Nginx 负载均衡转发到应用节点，应用节点再调用 GPU 推理服务器和知识库服务。整个过程没有一条公网出口，这就是数据安全的物理基础。

4.2 基础环境安装

私有化版本底层依赖 Docker 和容器编排平台。单机小规模部署时用 Docker Compose 就行，集群化部署则建议 Kubernetes。以下是单机版的最小准备步骤：

# 安装 Docker curl -fsSL https://get.docker.com | sh # 安装 NVIDIA Container Toolkit，让容器能用 GPU distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker

装完后先验证 GPU 可见性：

docker run --rm --gpus all nvidia/cuda:12.0-base nvidia-smi

能正常输出显卡信息，说明环境没问题。这套操作看似简单，但最容易在这里卡壳，尤其是 NVIDIA 驱动版本和 CUDA 版本的匹配问题。驱动装完一定要用nvidia-smi确认 CUDA 版本，再决定拉哪个 Tag 的 PyTorch 镜像。

4.3 模型服务部署

环境就绪后，开始部署推理服务。从官方仓库拉取模型文件，放到指定的模型目录。这里插一个重要提醒：模型下载建议提前做好，尤其是大尺寸模型，几十 GB 的文件在企业网络环境下可能要传数小时，务必预留足够时间。模型就位后，我通常直接写一个 systemd 服务或启动脚本拉起 vLLM 服务，并做一次最基本的推理连通测试：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "/data/models/llama-13b-chat", "messages": [{"role": "user", "content": "你好，请自我介绍一下"}] }'

返回正常就说明模型服务跑通了。这一步我建议把 timeout 设置得长一点，模型首次加载需要预热，前几秒没有响应是正常的。

4.4 知识库构建与检索调优

知识库的质量直接决定问答效果。文档处理流程通常是：先解析各类格式（Word、PDF、Excel、Markdown），再做文本切片。切片是个技术活，我踩过不少坑后总结出几个参数参考：

向量化用的 Embedding 模型也要选对。国内业务场景建议选择中文 Embedding 模型，它们在中文语义上的表现比通用模型好不少。知识库建好后，一定要做一轮实测验证，拿真实业务问题挨个问一遍，看检索内容是否命中。我做过的一个项目里，第一批知识库上线后答非所问，仔细排查才发现是切片重叠设置得太小，设备名称被截断成两半，导致检索永远匹配不上。这类问题靠人工测试很难全覆盖，最好是设计一套标准测试集，每次调整完都跑一遍回归。

4.5 Agent 运行时与工具集成

“实在 Agent”的核心能力是调用工具。工具对接时，每个工具都要定义清晰的名称、描述、入参 schema。这里讲究很大：工具描述写得越精确，大模型决策调用的准确率越高。比如一个查询库存的工具，描述可以写“根据商品编码或名称查询实时库存数量，入参 item_code 为商品编码”，而不是笼统地写“库存查询”。工具权限要绑定角色：普通员工只能调只读工具，审批、付款、删除类操作要限定给特定角色，并且建议在 Agent 执行敏感操作时增加二次确认机制。

数据库选型上，会话历史我用 PostgreSQL 存储，热数据用 Redis 做缓存。PostgreSQL 在事务和数据一致性上的表现远比 SQLite 可靠，尤其当多个 Agent 实例共享会话状态时。

4.6 备份、监控与上线验收

私有化部署最容易忽略的就是备份和监控。建议至少覆盖三层：模型文件层（模型是一个大文件，改动频率低，定期打包备份即可）、数据库层（会话记录、知识库索引、用户权限数据，每日全量备份）、日志层（对话日志和调用日志，用于排查问题和合规审计）。监控方面，重点关注 GPU 利用率、显存占用、推理服务延迟、知识库检索耗时、工具调用成功率这五个指标，配置好告警。

上线前严格做一轮验收测试，清单大概是：

• 核心业务问题问答准确率是否达标
• 工具调用是否按预期触发，权限是否生效
• 连续 100 条对话无异常中断
• 并发测试下 P95 响应延迟是否在可接受范围
• 断网环境下系统是否完全可用
• 敏感操作是否有审计记录

5. 常见问题与排查实录

这一节整理几个我实际项目中高频出现的问题，做成速查表，方便大家直接对照排查。

排查技巧方面，最常用的手段是看三段日志：Agent 运行时日志（看决策链路和报错）、模型推理服务日志（看生成内容和延迟）、数据库查询日志（看知识库检索命中了什么内容）。把三个时间线对齐，大多数问题都能快速定位。

6. 项目后续扩展的几个方向

私有化“实在 Agent”上线只是第一步，后续迭代空间其实很大。我特别想提醒的是模型升级这件事。开源社区每几个月就会发布新版本模型，虽然效果更好，但每次升级都要重新评估效果、跑回归测试。建议把模型版本管理和回退机制从一开始就做好——比如用固定的镜像 Tag 记录模型版本，升级前先在测试环境跑完整个测试集，确认没有问题再切生产。我在实操中见过不少团队因为“模型效果好像更好”就草率升级，结果两天后发现问题五花八门，又急着回滚，来回折腾浪费了大量时间。

另一个值得投入的方向是知识库的持续运营。知识库不是建一次就完事的，企业文档、流程、产品资料都在持续更新。要建立一个固定的知识更新机制，比如每周由业务人员提交新增内容，运维统一处理后更新到知识库。这样“实在 Agent”的知识保鲜度才能跟得上业务变化。

从小规模试点开始，以业务闭环为单位逐步放开，是我个人最推崇的落地节奏。先让一个部门、几条业务链路跑顺，积累足够的使用数据和反馈，再铺开到全公司。AI 项目的效果优化是个循环迭代的过程，一开始就在全公司铺开，一旦体验不好很难收场。选好第一个业务场景，打透它，比什么都重要。