「能不能私有化部署」这句话，在项目立项会上出现的频率，几乎和「能不能接我们的系统」一样高。但真到了交付现场，大部分团队才发现这句话后面藏着一连串没想过的问题：模型怎么进去、外网不通怎么装、日志到底存在谁那儿、以后版本升级谁来动手。
这些问题的共同点是：它们都不在功能清单上，但每一个都能让项目在验收前一晚翻车。私有化部署从来不是一次技术搬运，它是一次交付形态的变更——把一个依赖外部服务的系统，改造成一个能在一间连不上外网的机房里稳定活好几年的东西。
先把这篇在站内的位置说清楚，避免和已有几篇混在一起：OpenClaw 怎么部署到服务器 讲的是你自己把 Agent 从本地搬到云上（单体部署、反向代理、公网访问）；OpenClaw 自建推理服务 讲的是把模型跑在自己的服务器上（显存、量化、并发）；多租户设计 讲的是一套系统怎么服务多个客户。这一篇讲的是另一件事：当交付对象是另一家单位的机房、而你的访问权限只有一只 U 盘和一次预约好的维护窗口时，这件事该怎么做。
一、先搞清楚：私有化到底在私有化什么
很多讨论会卡在「支持私有化吗」这种是非题上。把问题拆开更有用——私有化至少包含四件事，而且它们可以分别成立：
- 数据私有：业务数据、日志、会话记录不离开对方的网络。
- 模型私有：推理在这一侧发生，不调用外部 API。
- 网络私有：整套系统在隔离网内可运行，不需要连公网。
- 运维私有：出问题现场有人能处理，不依赖你的团队随时在线。
关键在于：这四件事的难度差得很远，需求方往往一起提，实现方不能一起答。有一类客户真正的诉求只是「数据不出我的机房」——那模型走外部 API、中间加一层出网代理和脱敏就够了；另一类客户的诉求是「线上物理隔离」，那就连依赖包和模型权重都要提前搬进去。先问清楚是哪一档，能省掉一半工作量。
二、第一道关：网络——最容易被低估的一关
做过一次隔离网部署的人都会记住一件事：所有「顺手在线装一下」的动作，在这里全部作废。
要提前确认清单：
- 有没有出网通道（哪怕是只能访问特定域名的白名单代理）。有代理和没有代理，是两种完全不同的交付方案。
- 内网有没有镜像仓库，或者允不允许你带离线镜像包进场。容器镜像、依赖包、字体、证书链，这些都要提前打进包里。
- DNS 和证书怎么处理。内网通常没有公网域名，证书要么用自签、要么用内部 CA，浏览器和 SDK 都可能对自签证书报警——这一点要在联调前就试通，不要留到验收当天。
- 能不能开固定端口。有些环境只允许在指定端口段开放，反向代理和回调地址都要按这个约束重新设计。
- 有没有安全审计策略会记录或拦截你的调试流量。上线前先申请调试窗口，别在现场临时申请权限。
这一关最常见的错误是：把「安装成功」当成「网络通了」。装完不代表回调能回来、不代表定时任务能执行、不代表模型下载能续传。核验方式是准备一份最小连通性检查脚本——逐个探测关键出口（模型端点、镜像仓库、外部通知渠道、时间同步），每条打印结果。这份脚本本身也是验收材料的附件，道理和 变更后验证清单 里说的一样：凡是改动过的东西，都要有一条能自动跑一遍的确认。
三、第二道关：模型——三条路线怎么选
「模型私有」在实践中通常落成三条路线，成本差一个数量级，选错了很难回头：
路线一：私有化通道内的外部 API
推理仍发生在厂商侧，但通过专线或代理接入，数据在传输和留存上做脱敏和约定。特点是落地最快、成本最低，本质上不是真正的模型私有，适合「数据不出域但可以出网」的场景。要谈的是数据处理条款，不是技术方案。
路线二：自建推理服务
把开源模型跑在客户提供的 GPU 或 CPU 上。显存怎么算、量化选哪一档、并发怎么限，这套方法在 自建推理服务那篇 里已经写得很细，这里只补私有化特有的三点：显卡型号和驱动版本要提前确认（内网换驱动很麻烦）；模型权重要提前搬进去（几十 GB 起步，走 U 盘要有心理准备）；要约定模型更新机制（否则这套系统三年后还在跑一个很旧的版本）。
路线三：软硬一体交付
整机或一体机形式进场，开箱即用。省掉所有环境适配的麻烦，代价是价格高、扩容不灵活。适合网络和运维能力都比较弱的现场，也适合「只允许买设备、不允许装软件」的采购约束。
选路线的判断顺序建议是：先问数据约束（能不能出网）→ 再问算力条件（有没有卡、什么卡）→ 最后问运维能力（现场有没有人）。三个答案基本就把路线框死了。
四、第三道关：数据——「不出域」要落到具体位置
「数据不出域」这句话如果在合同里，就必须在系统里能指出来。要逐项确认数据落在哪里：
- 会话与任务历史：存在哪台机器、哪个库、有没有异地备份。
- 日志：日志里天然会带凭证片段和用户数据，本地留痕的同时要做脱敏——这一点在 审计查询字段设计 里有详细讨论。
- 向量库与索引：知识库切片和向量通常被忽略，但它们同样是数据的副本，而且往往没做权限控制。
- 缓存：提示词缓存和结果缓存会临时保存大量内容，要确认缓存的落盘策略和过期时间，参考 缓存怎么用。
- 备份与迁移包：备份文件是数据最集中的形态，加密和保管责任要写清楚，流程可参考 备份与迁移。
另一件容易被漏掉的事是凭证。私有化环境里，Agent 往往要连的是对方内部的 OA、数据库、文件服务，这些凭证的存放、轮换和撤销要有安排，别做成一份写死在配置文件里的长期密钥——凭证轮换 和 权限与凭证管理 里讲的原则，在离线环境里同样适用，而且更重要，因为现场没人会随手帮你改配置。
五、第四道关：运维与升级——交付之后才是真正开始
私有化项目最容易烂尾的地方不是上线，是上线之后。三件事必须在合同里说清：
- 谁值班。是现场值班室按你的手册处理，还是通过带外通道远程支持，还是按次付费上门。没有约定，第一半夜告警就会变成一次扯皮。
- 补丁怎么进。安全补丁、模型版本、依赖漏洞修复，都需要一个能进隔离网的通道。实践上通常准备一个「离线更新包 + 校验清单」，并提前做通一次演练。
- 许可证与到期。如果涉及授权，要确认授权是绑定机器、绑定时间还是绑定并发，以及到期后的降级行为是「停止服务」还是「降到基础功能」。这一点一定要在验收材料里写清楚，别等到某个早上系统突然不响应。
此外，权限本身也要按最小化设计。私有化不等于内部就安全——权限管理 和 沙箱隔离 这两层在本地环境里同样要做，七道安全防线 里讲的思路，去掉公网暴露那一环之后其余全部保留。
六、八项验收清单
- 断网环境下完整重启一次，系统能自行恢复（这是最有说服力的一项）。
- 最小连通性检查脚本全绿，每条出口的探测结果留档。
- 模型切换或降级演练一次，确认兜底路径可用。
- 数据落点逐项指认：库、日志、向量、缓存、备份，分别在哪台机器。
- 日志脱敏抽样检查，确认凭证和手机号等敏感片段没有明文进日志。
- 权限清单核对，确认没有任何一个组件在用超出清单的权限。
- 离线更新包演练一次，从放入到生效全流程计时。
- 值班与升级响应流程书面化，包含第一响应人、升级条件、联系方式。
七、四个最容易踩的坑
坑一：把「能跑通」当验收标准。能跑通只说明路径对了，不说明能长期跑。验收要测的是重启、断电、磁盘满、网络抖动这些「不好看但一定会发生」的情况。
坑二：时间同步没做。内网没有 NTP 源时，几台机器的时间会慢慢飘。表现是定时任务莫名其妙不触发、日志顺序错乱、证书校验失败——很难查，但事前配一个内网时间源就能避免。
坑三：把密钥和口令写进配置文件。在离线环境里这几乎等于永久固化。至少要放进受控的密钥文件或本地密钥服务，并约定轮换方式。
坑四：没做容量余量。私有化现场通常不会再扩容。压测和容量结论必须按「三年后的数据量」来估，而不是按交付当天的量，评估方法可参考 Agent 压测与容量评估。
八、优缺点和适合人群
它能给你什么：数据、模型、网络三件事都握在自己手里；合规和审计上能交出材料；不依赖外部服务的可用性；以及一套可以长期演进、不会因为对方涨价或停服而中断的系统。
它的代价：成本显著高于 SaaS 形态（硬件、人力、运维都要自备）；版本更新慢，容易落后于公有云的能力；模型能力通常要退一档；故障处理依赖现场响应速度，问题排查周期被拉长。
适合谁：数据有明确合规要求、不能出网的行业；把 Agent 接进内部核心系统的单位；网络环境和运维能力都比较弱、需要开箱即用的现场；以及需要把交付物当作资产长期持有的采购方。
不适合谁：还在做概念验证的阶段——这个时候私有化会拖慢所有事情，先用公有云把价值验证清楚；以及没有运维人力、也没有预算买服务的小团队，私有化最后会变成一台没人维护的机器。
总结
- 先拆问题：数据私有、模型私有、网络私有、运维私有是四件不同难度的事，别一起答。
- 四道关：网络（有没有出网通道、内网镜像、证书怎么办）、模型（三条路线按约束选）、数据（落点逐项指认 + 凭证管理）、运维（谁值班、补丁怎么进、许可证到期怎么降级）。
- 八项验收：断电重启、连通性脚本、模型降级演练、数据落点、日志脱敏、权限核对、离线更新、值班流程。
- 四个坑：把能跑通当验收、时间不同步、密钥写进配置、没留容量余量。
- 底线：合同里写不出来的运维责任，最后都会变成一次扯皮。
最后一句：私有化交付的核心不是「装进去」，是「三年后现场的人还能自己把它管好」。凡是需要你的工程师持续在线才能活的私有化，其实只是把依赖从云厂商换成了你自己。
