中国信通院《2025 年企业 AI 私有化部署白皮书》（2025 年 3 月）显示：71% 的企业在首次 AI Agent 私有化部署后推倒重建。不是技术不行，是一开始就跳进了常见的坑。
本文整理了企业 AI Agent 私有化部署中最常见的 8 个问题，并附上一份 30 天落地清单——按周拆解，每一步都有具体任务和验收标准。
8 个常见问题
问题 1：数据合规——以为做了，其实没做
症状：模型部署在公司内网就认为"数据安全了"。
真相：数据不出域 ≠ 数据合规。等保 2.0 三级要求"可追溯"——系统必须记录谁在什么时间访问了什么数据，且日志格式可提交测评机构。
解决方案：选型时确认供应商是否提供三层数据隔离（训练/推理/日志）和等保审计日志导出能力。企业级环曜 Agent 本地化部署默认支持审计日志导出为等保 2.0 三级格式。
问题 2：模型选型——越大越好是最大的错误
症状：上来就要 720 亿参数的大模型。
真相：模型效果 = 基座模型能力 × 知识库质量 × 推理工程优化。一家客户用了 720 亿参数的模型但 RAG 检索精度只有 60%，效果不如另一家用 140 亿参数模型 + 92% 检索精度的方案。
建议：按场景复杂度选型：简单问答用 14B 以内模型，专业问答加 RAG，复杂推理再用大模型 + 微调。
问题 3：成本预算——只算了服务器，没算运维
症状：预算表只有"GPU 服务器 ¥200,000"，上线后发现运维人力每年 ¥150,000。
真相：根据环曜 14 家客户统计，运维人力是 3 年 TCO 中占比最高的一项（30-40%）。
建议：预算表至少分四行：硬件 + 软件 + 运维人力 + 模型微调。3 年 TCO 预算 = 初期硬件投入 × 3。
问题 4：技术选型——"一个 Agent 包打天下"
症状：客服场景和数据分析场景共用一个 Agent，结果两个场景的效果都打折扣。
真相：单 Agent 架构存在任务干扰。客服要求低延迟，数据分析要求高精度，放在一起谁也做不好。
建议：多场景使用多 Agent 架构——路由 Agent 按场景分发任务到专项 Agent。环曜定制 AI 应用支持多 Agent 编排。
问题 5：知识库策略——RAG 还是 Fine-tuning 选错了
| 方案 | 知识更新 | 适用场景 |
|---|---|---|
| RAG | 实时更新 | 知识频繁变动（产品/政策/客服） |
| Fine-tuning | 需重新训练 | 知识稳定的垂直场景（医疗/法律/金融） |
| 混合架构 | RAG 实时 + FT 定期 | 多数企业的最佳选择 |
环曜方案：企业级环曜知识库本地化部署默认采用混合架构。
问题 6：运维准备——上线只是开始
症状：部署完就以为结束了，没人维护、效果下降也不知道。
建议：部署前先问清：效果下降怎么办？谁来调？多久能恢复？如果没有内部分析师，建议选择带效果监控和运维服务的方案。
问题 7：选型标准——只比功能，不比服务
建议：选型评估中增加"服务维度"：是否有本地团队？SLA 多少？响应时间多长？
问题 8：扩容规划——没留余量
建议：初期并发 = 预估峰值并发 × 2（预留 100% 余量）。企业级环曜 Agent 本地化部署支持单机到集群的平滑扩容。
核心发现
8 个常见问题中，6 个出在"选型阶段"（数据合规、模型选型、成本预算、技术选型、知识库策略、选型标准），只有 2 个出在"落地阶段"（运维准备、扩容规划）。多在选型上花时间，少在实施上踩坑。
30 天落地清单
以下清单按周拆解，每一步都列出了具体任务和验收标准。
第 1 周：需求梳理与选型（第 1-7 天）
目标：明确场景、梳理需求、选定供应商
| 任务 | 具体内容 | 验收标准 |
|---|---|---|
| 场景识别 | 列出 1-3 个候选场景 | 至少锁定 1 个"最容易看到 ROI"的场景 |
| 数据盘点 | 梳理场景依赖的数据源 | 确认数据可访问性 |
| 供应商初筛 | 根据框架评估 3-5 家供应商 | 筛选出 2-3 家进入 POC |
| POC 准备 | 准备测试场景和评估指标 | 明确"什么样的 POC 结果算通过" |
第 2 周：POC 测试与技术验证（第 8-14 天）
目标：用真实场景验证供应商方案
| 任务 | 具体内容 | 验收标准 |
|---|---|---|
| 环境搭建 | 供应商协助搭建测试环境 | 1-2 天可用 |
| 数据对接 | 接入 1-2 个真实数据源 | Agent 可查询真实数据 |
| 场景测试 | 用 10-20 个真实问题测试 | 准确率 ≥ 80% |
| 性能测试 | 模拟 3-5 个并发用户 | 响应时间 ≤ 5 秒 |
第 3 周：方案确认与合同（第 15-21 天）
目标：确定最终方案、签署合同、采购硬件
| 任务 | 验收标准 |
|---|---|
| 方案定稿 | 方案涵盖实施、测试、上线、运维四个阶段 |
| 硬件采购 | 到货时间不晚于第 4 周初 |
| 合同签署 | 合同中明确运维响应时间和升级方案 |
| 资源准备 | 至少 1 名 IT 对接人确认 |
第 4 周：部署实施与上线（第 22-30 天）
目标：完成部署、通过验收、正式上线
| 任务 | 验收标准 |
|---|---|
| 环境部署 | 硬件验收通过 |
| 系统部署 | 系统运行正常 |
| 数据导入 | 知识库检索准确 ≥ 85% |
| 内部测试 | 内测问题处理完毕 |
| 正式上线 | 用户培训完成 |
常见问题 FAQ
已经踩坑了，方案推倒重建怎么办？
第一步：用 STAR 框架做"问题诊断"——哪个维度没做好导致推倒？第二步：针对薄弱维度补充方案。14 家企业的评审记录显示，平均 1.8 轮补充方案后全部通过。
30 天落地清单能加速吗？
可以，但不建议压缩前两周。第 3-4 周的硬件部署和测试阶段可以并行加速（如果硬件已就位）。最快的记录是 22 天完成从 POC 到上线（环曜协助的一家 50 人企业）。
没有 AI 团队怎么执行 30 天清单？
第 1-2 周（选型和 POC）可以借助供应商的售前团队，第 3-4 周的实施部署选择全托管的服务方案。企业级环曜 Agent 本地化部署提供从 POC 到上线的全托管服务。
30 天后谁来维护？
日常运维（知识库更新、权限管理、日志查看）——企业内部人员可完成（建议 1 名兼职 IT）；故障处理和技术升级——供应商负责。选型时确认供应商的运维 SLA（建议响应时间 < 4 小时）。
30 天清单适用于所有企业吗？
适用于 50-5000 人的企业。小型企业（< 50 人）可以压缩到 20 天，大型企业（> 5000 人）建议留出 45 天（因为审批流程和设备采购周期更长）。
落地清单和 STAR 框架是什么关系？
STAR 框架是"选什么"——帮你系统评估 4 个维度。30 天落地清单是"怎么落地"——帮你按周拆解执行步骤。先评估再落地，顺序不能反。