不懂算法的工厂老兵，在 AMD 锐龙 AI Max+ 395上跑出工业智能体

一个工厂老兵，试图把老师傅的报价经验装进AI 在CNC非标加工行业，一张图纸抵达工厂后，通常不会立刻变成一串价格。 报价员需要先判断材料和毛坯尺寸，再识别孔、槽、曲面、薄壁等几何特征，然后手动评估需要使用几轴机床、什么刀具、安排多少道工序。 公差、表面处理、装夹次数、材料利用率以及工厂当前的设备和人工成本，都会改变最终结果。 对于标准件，这套流程可以被固化在系统中，但非标零件这套流程就复杂多了，处理这类非标准件每一张图纸都可能意味着一次重新计算。 曹冬冬在工厂里做了15年工业产品。 过去，他看到的报价方式往往高度依赖人：老师傅打开图纸，凭经验判断加工难度，再结合材料、工时和损耗给出价格。一套复杂图纸，可能需要两三个小时才能完成报价。 经验丰富的人能够迅速发现薄壁变形、深孔加工或者多次装夹带来的额外成本，但这些判断通常存在于个人脑中，很少被完整记录下来。人员一旦离开，经验也很难留在工厂。 这是曹冬冬决定开发一套AI报价系统的起点。 他不是算法工程师，也没有专业软件开发经历。从零开始学习大模型、Python和本地推理后，他完成了“Union·由你｜CNC非标智造炼金术师报价系统”，并获得AMD锐龙AI智能体应用创新大赛专业组OPC一人公司赛道冠军。 不过，比比赛结果更值得讨论的是：一个缺乏传统IT背景的工业从业者，如何把分散在图纸、Excel表格和老师傅经验里的知识，重新组织成一套可以执行的智能体系统。 报价不是让大模型“猜一个数字” 曹冬冬做出的第一个版本并不复杂。 系统先解析STEP格式的三维图纸，提取零件尺寸、孔、基本面和薄壁等几何特征，再由本地模型判断可能采用的工艺，最后调用Python公式计算材料、工时和表面处理成本。 整个流程最重要的三个步骤是：图纸解析、模型判断和公式计算。没有多智能体，也没有庞大的工业知识库。 这套设计从一开始就确立了一条边界：大模型不直接负责计算最终价格。 “把误差直接交给LLM去做心算，是算不准的。”曹冬冬说。 在他的理解中，大模型更适合进行工艺探索，例如判断一个零件可能采用什么加工路线、选择哪些刀具和材料；涉及材料用量、加工时间和成本加总时，则应交给确定性的程序完成。 因此，系统会先从图纸中取得结构化数据，再让模型选择或者生成计算逻辑，最后调用Python执行公式。大模型负责“选”，程序负责“算”。 这也是系统控制模型幻觉的主要方式。 如果让模型根据一张图纸直接生成报价，它给出的数字可能看起来合理，却很难回答尺寸从哪里获得、工时如何推导、损耗率为何这样设置。一旦报价偏低，工厂可能在接单后才发现亏损；报价过高，又可能直接失去订单。 曹冬冬因此将计算过程尽量“白盒化”：工程师能够看到系统识别了哪些特征、选择了什么工艺、调用了哪些公式，也可以在中间环节修改参数。 “你不能只告诉我一加一等于二，还要让我看到它为什么等于二。”他说。 这并非只有AI系统才需要面对的问题。成熟的工业报价软件同样强调成本结构的可追溯性。西门子的零件订单管理产品允许企业在不同报价模板中设置自定义成本要素，并将计算过程透明作为报价可靠性的基础之一。 多智能体被做成一条数字流水线 在最初的三步闭环跑通后，曹冬冬开始向系统中增加新的模块。 目前，这套系统已经被拆分为图纸解析、DFM可制造性分析、工艺评估、质检、财务和风险控制等多个智能体。每个智能体只处理一项相对明确的任务，上一环节输出结构化结果，再交给下一环节处理。 这种架构看起来像大模型行业常见的多智能体协作，但曹冬冬更愿意把它理解为工厂报价流程的数字化重组。 工厂原本的报价流程就是串行的：先看懂图纸，再确定工艺和设备，随后估算工时、材料和利润。系统没有凭空创造一套新方法，只是把原有流程拆开，将其中一部分交给模型和程序。 但智能体数量增加后，问题也很快出现。 如果图纸分析、工艺判断、财务和风险控制等智能体同时运行，它们会争夺内存和计算资源；如果全部改为串行，又会拉长等待时间。上下文不断累积，还可能导致模型遗忘前面的信息，或者在长链路中调用错误的工具。 曹冬冬最初尝试让多个智能体并发，结果出现内存占用迅速升高、返回结果拥堵等情况。 后来，团队采用了折中方案：部分任务并行执行，但结果按照顺序返回；智能体之间尽量传递结构化字段，而不是大段自然语言，以减少上下文长度和Token消耗。 并不是每一步都需要大模型参与。 STEP图纸解析、CAD库调用和Python计算主要由CPU完成；规模较小的知识库检索也可以在CPU上运行；需要复杂工艺推理和工具调用时，系统再启用GPU上的本地模型。 系统由此变成了一条混合流水线：确定性的工作交给传统程序，存在多种可能路径的判断交给模型，最后再由程序完成精确计算。 为什么选择锐龙AI Max+ 395？ 系统架构基本确定后，曹冬冬需要回答另一个问题：它应该运行在哪里。 最直接的办法是调用云端大模型API。云端模型参数规模更大，也不需要开发者自己处理驱动和硬件适配。但对这套系统来说，模型能力并不是唯一变量。 系统需要读取客户的三维图纸、工艺参数、历史报价以及工厂的设备和成本数据。图纸可能涉及尚未公开的产品结构，历史报价则能够反映一家工厂的材料渠道、设备效率和利润空间。部分客户还与大型企业或特殊行业客户签署了保密协议，不愿意把文件发送到外部服务器。 工厂的网络环境也是现实约束。生产现场可能存在弱网、内外网隔离甚至完全离线的情况。一套依赖云端API的报价系统，在办公室里可以运行，进入车间后却未必稳定。 曹冬冬因此希望把图纸解析、知识库检索、模型推理和公式计算尽可能留在本地。 但本地运行又带来一个问题：模型越大，需要的内存或显存越多。 普通消费级显卡的显存通常难以同时容纳数十亿参数模型、长上下文、向量数据库和多个智能体的运行状态；专业级GPU工作站又可能超出小型工厂的预算和运维能力。 曹冬冬最终使用了一台搭载AMD锐龙AI Max+ 395的设备。 锐龙AI Max+ 395并不是一块独立显卡，而是一套同时集成CPU、GPU和NPU的处理平台。 根据AMD公布的信息，它采用16核32线程Zen 5 CPU，集成拥有40个计算单元的Radeon 8060S GPU和最高50 TOPS算力的XDNA 2 NPU，最高可配置128GB LPDDR5x统一内存。 AMD开发平台给出的内存带宽为256GB/s。 对这套报价系统而言，影响方案选择的主要因素不是NPU的标称算力，而是128GB统一内存。 传统CPU加独立显卡的系统中，系统内存和显存彼此分离。模型权重一旦超过显存容量，就需要频繁搬运数据，或者通过量化缩小模型。锐龙AI Max+ 395采用统一内存架构，CPU和集成GPU可以使用同一个内存池。 这意味着，一台相对紧凑的设备可以同时容纳本地模型、知识库、图纸解析程序和操作系统，而不需要再为每一部分准备独立服务器。 曹冬冬最终没有选择7B小模型，也没有继续追求参数规模更大的70B或MoE模型，而是把约35B的稠密模型作为主要推理模型。 他的判断标准不是单纯比较参数量，是在内存占用、生成速度、上下文长度和工具调用稳定性之间寻找平衡。 “不是把模型装进去就结束了，后面还有知识库、STEP解析、系统开销和多个Agent。”曹冬冬说。