私有化 AI Agent 的算力规划，最常见的错误是把预算全部压在显卡上。制造企业的场景里，数据不出厂是硬约束，但在这个约束之下，真正决定系统能否跑稳的，往往不是模型参数有多大，而是算力结构有没有分层想清楚。
本地 Agent 运行时和聊天机器人不是一回事。聊天机器人接一次输入、生成一次输出就结束；Agent 运行时是持续在线的，它要接收消息、调用工具、读写文件、维护任务状态。这意味着算力需求天然分成三层：模型推理层承担大模型前向计算，决定并发能力和响应速度，以 GPU 显存和算力为主，是成本大头；编排与调度层负责 Agent 逻辑、任务分解、状态管理和请求路由，现代 8 核 CPU 通常可以胜任；工具与数据层处理数据预处理、文件读写、向量检索和数据库访问，吃的是内存和高速 NVMe 存储，容量随知识库规模增长。
这个分层带来一个对制造企业特别关键的判断：如果 Agent 主要做 RAG 检索加多工具调用，而不是长上下文推理，瓶颈常常落在向量库查询和存储 IO 上，而不是 GPU。选型前先测清楚自己的任务画像，比盲目堆显卡更省钱。CPU 侧的角色也容易被低估——从 8 核升到 16 核带来的收益，通常远小于在 GPU 或存储上的同等投入。
现场环境又给这件事加了一层约束。粉尘、振动、温度波动、供电稳定性都是变量，数据中心服务器不能简单搬进车间，这也是工业级 AI 算力服务器存在的理由。合理的做法是分层而非二选一：中心侧放在厂区机房或企业私有云，部署较大参数量的模型，承担知识库问答、文档理解、复杂分析，同时作为模型仓库和统一管理节点；边缘侧靠近产线和设备，部署量化后的小模型或专用推理服务，承担低延迟、高频次、数据就地处理的判断类任务，比如实时异常识别、工单分类、设备日志摘要。量化、剪枝这类优化技术在私有部署下比在云端更关键，因为本地扩容不像云上那样随时可加。
分层还有一个现实好处：负载出现峰值时，可以把非敏感、非实时的溢出任务放到公有云，涉密数据始终留在本地。混合路径的价值不在于省钱，而在于让本地容量规划不必按峰值设计，降低一次性投入。
判断一个场景该不该先做，可以看几条依据。数据边界是否清晰——需要访问的数据源是否已经明确、可枚举、有稳定接口，如果数据还散落在互不相通的系统里，先做治理而不是先做 Agent。输出是否可复核——试点阶段应由人确认后再进入业务流程，要求 Agent 直接触发生产动作的场景放到第二阶段。任务频次是否足够高——低频偶发任务摊不平本地算力的固定投入。失败成本是否可控——回答错了是人工返工还是产线停线，前者适合试点。算力是否可增量扩展——本地扩容不像云上即时，业务预期半年内翻倍就要预留余量或提前设计溢出通道。
上线路径上，比较稳妥的是先在一个车间或一条产线做封闭试点，用真实数据跑通数据接入、推理、人工复核、反馈修正的闭环，再扩展到同类场景。验收指标要同时看技术侧和业务侧：响应延迟、并发承载、检索准确率是一面，人工处理时长下降幅度、返工率变化、跨系统切换是否真正减少是另一面。只有技术指标达标而业务指标没动，通常说明场景选错了，而不是系统不行。
反过来，有几类条件不具备时应当延后：没有稳定的内网与机房环境，或车间供电散热撑不住工业级设备；核心数据尚未完成目录化与权限梳理，Agent 拿不到可信输入；缺少至少一名能维护推理服务、模型更新和边缘节点的技术人员；业务侧没有流程负责人，只有 IT 部门在推。这些不是永久门槛，而是顺序问题。先把数据、网络和人配齐，再谈模型和算力，成功率会明显不同。