大家也许都有所了解，在汽车制造零部件行业里：生产停线是按分计算的，动不动就是几万块。

产线却经常因为换线、插单、换模、缺料停着等人。这个难题也困扰了一些企业多年。

我们前后用了近3个多月，把一个排产 Agent 接进了一家公司的 MES 和 ERP。想讲讲是把它怎么接进去、接的时候卡在哪、员工一开始怎么不买账、后来怎么一点点顺下来的全过程摊开。如果你的公司也在纠结"要不要让 AI 碰排产"，这里面的判断和坑，大概率对你有用。

很多人听到"排产 Agent"，以为是一个能自己拍板的"数字排产员"。不是。我们这套系统的实质，是规则引擎 + 约束规划/启发式算法在算计划，大模型只做交互和解释的增强。它能算、能说，但最终每一张计划都要人确认才落地。它不是全自主的 Agent，更准确的说法是"智能排产系统 + LLM 增强"。这篇里我沿用"排产 Agent"这个叫法，是因为大家顺口，但你要知道它和"能自己拍板的自主智能体"之间有道明确的边界。这道边界，恰恰是这个项目没翻车的根本原因。

一、为什么是排产，以及什么样的公司适合现在上

排产这件事，天然适合交给系统，因为它满足一个最关键的条件：输入是结构化的。订单、BOM、设备产能、物料库存，这些都在 ERP 和 MES 里有明确的字段，不是散落在聊天记录里的非结构化信息。再加上约束明确（哪台设备能做什么工序、换线要多久、交期多紧，都能写成规则），产出可核对（排出来的计划对不对，第二天产线跑没跑通，一眼能看出来，反馈回路短），排产就成了少有的"适合先上 AI"的场景。

但这不等于所有公司现在都该上。我们接单前，会先看三件事，有一件不满足，我们反而会劝客户先别上。

一是数据齐不齐。如果 ERP 里的 BOM 常年不准、MES 报工靠工人手填还经常漏，那 Agent 排出来的计划地基就是烂的。这种公司得先补数据，不是先上 AI。

二是排产规模。几十台设备、几百个订单、交期互相咬合的公司，Agent 的价值最大。如果就两条产线、十几个订单，人工排半小时就完事，上 Agent 是给自己找事。

三是排产员的经验在不在纸面上。有些公司的排产全在一个老师傅脑子里，规则说不清。这种最可惜，也最难。不是不能做，是要先花时间把老师傅脑子里的规则「挖」出来。

这家汽车零部件公司三条都满足：BOM 和库存是准的，三百多台设备、每天上千张工单，排产员的规则虽然没文档，但愿意坐下来跟我们一条条对。所以我们接了。

二、上之前，我们先做了一堆"不碰 AI"的活

很多公司以为上 AI 就是买套系统、跑个模型。真不是。我们进公司第一周，一行代码没写，全在干三件事。

第一件事，跟着排产员上了一礼拜班。不是坐在办公室看，是跟着他接插单电话、跑产线、在 ERP 里改工单。最后我们整理出一份"排产员一天的真实动作清单"：哪些是查数据、哪些是拍板、哪些是协调、哪些是救火。这份清单后来成了 Agent 该接哪些活的边界。

第二件事，把规则挖出来。排产员嘴上说的规则，和他实际用的规则，经常不是一回事。比如他嘴上说"同款产品尽量排在一起减少换线"，实际遇到急单，他会先把换线时间短的排进去。这种"隐性规则"不挖出来，Agent 一上线就会被骂"不懂行"。我们用了两周，把规则整理成一张表，每条规则标清楚：是硬约束（交期、设备能力），还是软偏好（少换线、优先大客户）。

第三件事，定验收指标。这步最容易被跳过，也最要命。我们和生产部长、排产员一起定了三个数：排产耗时从人工的 6 小时压到 30 分钟以内；换线次数下降 15% 以上；计划达成率（排出来的计划第二天实际执行的比例）从 82% 提到 90% 以上。没有这三个数，后面做得再好也说不清价值。

除了指标，我们还准备了退路。跟生产部长约定：如果 Agent 排出的计划连续三天达成率低于 85%，系统自动切回人工排产模式，Agent 退到辅助位。听起来是给自己上枷锁，但这个约定让生产部长敢签字：他知道任何时候都有一条能退的路。这三个月里这个开关一次都没触发过，但它的作用不在触发，在签字那一刻。生产部长后来跟我们说，他签合同时最看重的就是这一条。

三、技术怎么接：这是这篇文章的核心

排产 Agent 的架构，说穿了是三层：数据层、决策层、执行层。难的全在接口上。

 数据层：把两套系统的数据，拼成 Agent 读得懂的一张表

MES 和 ERP 是两套完全不同的系统，字段对不上是常态。

ERP 里，订单有交期、有客户、有 BOM，但没有"这个订单现在做到哪一步了"。MES 里，有设备实时状态、有工序进度、有报工记录，但没有"这个工单属于哪个客户、交期多紧"。排产 Agent 要做的第一件事，不是推理，是把这些字段对齐。

我们做了一个数据管道，每 15 分钟从两边各拉一次，落到一张中间表里。中间表的字段是重新定义的，不沿用任何一方的原字段名。举例：ERP 的"计划完成日期"和 MES 的"工序预计结束时间"，在中间表里统一叫 due_time，Agent 只认这一个。

这里有个很容易踩的坑：时区和时间精度。ERP 用北京时间，MES 报工用的是设备本地时间戳，有些老设备还是 UTC，差了八小时。不统一，Agent 会把"已经完工"的工序当成还没开始。我们上线前专门做了一轮时间戳归一化，才没在第一天翻车。

比时间戳更隐蔽的，是同名字段不同语义。最典型的是状态字段：ERP 里的「已下达」，意思是计划部已经把工单放行了，但产线可能还没开工；MES 里的「已开工」，才是设备真的在跑。这两个词字面只差两个字，含义差了一道工序。还有「完工」：ERP 的完工是财务口径的入库完结，MES 的完工是最后一道工序报工完，中间隔着质检和移库。不把这些语义差异写清楚，Agent 会把 ERP 的「已下达」当成「已经在产」，整个计划全部提前。

我们最后整理了一张四十多行的字段映射表，每个字段除了名字对应，还写一行「语义备注」，注明它在两边各自的准确含义。这张表后来成了我们接任何 MES/ERP 的标配动作：字段映射表交出去，客户方的 IT 一看就知道我们真的读懂了他们的系统。

给你看这张表的几条真实例子，就知道它有多琐碎、又有多必要：

这张表看着平淡，但它决定了 Agent 拿到的数据是"对"的。字段对不上，后面所有推理都是白搭。

决策层：规则引擎兜底，模型只做它擅长的那部分

很多人以为排产 Agent 是"把订单丢给大模型，它自己排"。那是会出事故的。

我们的做法是规则 + 模型分工，边界划得很死。

规则引擎负责所有「算得清楚」的约束：设备产能、工序先后依赖、物料齐套检查、交期倒排。这些用传统排程算法（约束规划 + 启发式）就能算，而且结果可复现、可解释。为什么这个订单排在这台设备、为什么插单要挪别的单，规则引擎能一条条说清楚。

大模型只干三件它真正擅长的活：一是把人的自然语言需求转成结构化指令，比如生产部长说"明天客户 A 的单一定要先做，其他都可以让"，模型把这句话解析成一条高优先级的约束；二是生成排产结果的解释，把冷冰冰的计划表翻译成排产员听得懂的话，"因为客户 A 的交期紧，我把客户 B 的一张单往后挪了两小时"；三是处理规则没覆盖到的异常，比如"这台设备突然报故障，附近哪些订单可以挪到别的线"，给排产员几个候选方案。

为什么不让模型直接排？因为模型会"幻觉"出一个不存在的约束，或者把两个不相关的订单错误地关联。在排产这个场景，一次错误就是产线停摆。规则引擎算的，错了能追溯；模型算的，错了你查都查不清。所以我们的原则是：模型可以提建议，但最终下发的计划，必须经过规则引擎校验。

执行层：输出怎么安全地写回系统，是最容易翻车的地方

排产 Agent 排出一个计划之后，最危险的一步来了：把计划写回 MES 和 ERP。

这里我们定了几条铁律，一条都不能省，最重要的是前面两条：回写前必须人工确认，以及分级回写。

第一条，回写前必须人工确认。 Agent 排出的计划，先进入一个「待确认队列」，排产员在界面上看一眼，点确认才真正下发。看起来慢了，但这是排产员信任 Agent 的起点：他知道自己有最终否决权，才愿意让 Agent 干活。我们见过太多项目死在这：Agent 直接改工单，排产员被架空，第二天就集体抵制。

第二条，分级回写。 不是所有计划都走同一个通道。常规的、低风险的排程变更，Agent 可以批量提交；涉及插单、交期变更、跨产线调度的，必须逐单人工确认。我们在系统里把操作分了三级：自动、半自动、人工，对应的阈值是变更的金额影响和交期风险。

第三条，全程留痕、可回退。 Agent 的每一次写入，都要记录：读到了什么数据、依据哪条规则、做了什么变更、变更前是什么样。这样出了错能回溯，也能一键回退到变更前的状态。这条是排产系统能上生产的底气。

还有一个不太起眼但要命的问题：并发冲突。Agent 回写的时候，排产员可能正开着同一个工单在改。两边同时写，后写的会把先写的覆盖掉，谁都不知道丢了什么。我们的解法不新鲜：给每张工单加版本号。Agent 读的时候拿到版本 5，写回时发现已经是版本 6，说明中间有人改过，这次回写作废，重新算一遍再提交。这套机制在技术上很便宜，但它决定了一个体验细节：排产员永远不会发现「我刚改的东西不见了」。这种细节员工说不出来，但丢了两次，信任就没了。

回写还有一个必须处理的场景：写回失败。MES 的接口不是一直稳的，尤其生产高峰期，接口超时是常事。我们给每次回写加了重试机制，但重试有讲究，不是无脑重发，而是先查一次目标工单当前状态，确认上一次写没写成。写成了一半（比如状态改了但下游没通知到），就按幂等的方式补齐，绝不重复扣减物料或重复生成工单。这套「先查再补」的逻辑，和幂等键是同一个道理，写资金流系统的人一看就懂。

一张图看懂整个链路

这张图就是我们实际部署的架构。左边是数据层，中间是决策层，右边是执行层。每一条箭头都对应一个接口，每个接口都做过了字段映射和异常兜底。

补一段决策者最关心的账。这个项目的投入产出，一句话说清楚：我们这边投入三个人（一个项目经理、一个算法、一个对接客户 IT 的工程师），前后四个月，其中前两周在跟班挖规则、第三个月开始试运行。客户那边的直接成本，除了我们的服务费，主要是排产员配合我们梳理规则占用的时间。产出这边，三个硬指标前面说了：排产耗时 6 小时到 22 分钟、换线次数降 18%、达成率 82% 到 91%。换算成钱，最直观的是两笔：一是排产员从每天两班倒的 6 小时排产里解放出来，加班费省下来的部分；二是产线因换线、插单造成的非计划停机减少，按他们公司一小时停机几万块的口径算，一个月就回本了。精确的回本周期因企业而异，这家公司我们算下来是不到两个月。这里我不给你一个"普适 ROI 数字"，因为每家公司的停机成本、人工成本差太多，但算法就这三项：省下的排产工时 + 减少的停机损失 + 提升的达成率带来的准交率改善。

四、员工一开始碰到的问题，都不是技术问题

上线第一周，排产员几乎不用。我们以为是 bug，去问，排产员说了一句话："它排得对不对，我不确定，我不确定的东西，我不敢用。"

这才是真正的问题：不是 Agent 不好用，是员工不信任它，也不确定自己该怎么跟它配合。

具体的新问题，我们归纳下来有四种，头三种是"人和系统的摩擦"，最后一种是"人和自己位置的摩擦"。

第一个，不知道该怎么"指挥"Agent。排产员习惯了自言自语式的排产，脑子里想一套，手上在 ERP 里点一套。现在要他把需求用一句话说出来，让 Agent 理解，他不会说。他说的"把 B 的单往后放放"，Agent 理解不了"往后放放"到底是放多久、放哪。

第二个，被 Agent 的解释绕晕。我们让模型生成解释，本意是让排产员放心，结果适得其反。模型解释得太绕，排产员看不懂，反而更不信任。他的原话是：「它说了一大堆，我一个字都不想看。」

第三个，出了错不知道怪谁。有一次 Agent 排的计划导致一条线空转了一个小时。排产员的第一反应是"AI 不靠谱"，但追下去发现是 MES 里一条报工数据延迟了，Agent 拿到的信息是旧的。这种"数据错导致的 AI 错"，员工不会区分，一律记在 AI 头上。

还有一个没人明说、但我们感觉得到的：老师傅的身份焦虑。那位排产员五十岁上下，在这家公司干了十几年，公司里最好的排产头脑就是他。项目启动会上他全程没怎么说话，会后私下问我们一句：「这个东西上了，是不是就不用我了？」这一句比所有技术问题都重。他不是不会用，是怕自己被替代。后来我们想明白，这个坎不是靠培训能过的，是靠角色重定义：项目里我们明确跟生产部长和他本人说，Agent 接的是查数据、算基础排程这些活；插单决策、异常处置、规则评审，必须人来。他的角色不是被替代，是从「计算器」变成「裁判」。这个定位他认了，后面的事才推得动。

五、我们怎么带员工过这个坎

这三个问题，我们花了比技术多一倍的时间去解决，方法说透了就三招。

第一招，把"指挥"变成"选择"。 我们不让排产员自由发挥地描述需求，而是给他几个固定的"指令模板"：紧急插单、交期提前、某设备停机、优先某客户。每个模板对应一组预设的约束参数，排产员点一下，Agent 就知道该怎么排。先让他会用，再慢慢放开自由描述。

第二招，把解释从「人话」重写成「排产员的话」。 我们让排产员告诉我们，他排产时脑子里关心的三件事是什么：「这个单会不会延期」「这条线今天满不满」「换线次数多不多」。然后把模型的解释重新组织成这三件事的答案，短句，一句一行，不绕。改完之后，排产员才第一次说「它说的跟我想的是一回事」。

第三招，把"谁错了"讲清楚。 我们做了一张"排产结果溯源页"：任何一个计划，点进去能看到它依据了哪条数据、哪条规则，数据是几分钟前更新的。排产员一旦能自己查出"这次不是 AI 乱排，是报工数据晚了"，他对 AI 的信任就开始建立。我们特意让溯源页做得像聊天记录一样好读，而不是一堆日志。

对老师傅那个心结，我们另外做了一件事：请他当「规则评审人」。所有新增规则上线前，先给他过目，他说不合现场实际的，改完再上。这个头衔是他自己挣来的：最开始只是随口问了他一句「这条规则这么写对不对」，他认认真真写了半页纸的修改意见。我们顺势把这件事变成了他的正式职责。干了十几年攒下的经验，第一次有人系统性地向他请教，他后来是这个项目最积极的推动者。

这三招下来，大约四周后，排产员开始主动用 Agent 处理常规排产，自己腾出手去处理插单和协调。

六、后面怎么优化的

上线不是结束，是开始。后面两个月，我们主要做了三件事的持续优化。

指标上，三个验收指标的变化是这样的：排产耗时从 6 小时压到了 22 分钟（比目标的 30 分钟还快）；换线次数下降 18%；计划达成率从 82% 提到 91%。这三个数都不是一蹴而就，是每个月往上爬一点的。

规则上，我们建立了一个"规则争议台账"。每次排产员觉得 Agent 排得不对，都记下来，我们事后分析：是规则写错了，还是规则没覆盖这个场景，还是数据问题。三个月下来，规则从上线时的 40 多条，涨到了 80 多条，大部分新增都来自这些争议。规则越用越准，排产员越用越顺手，这是个正向循环。

支撑这个循环的是一个月度机制：每个月最后一个周五，我们、排产员、生产部长，三个人开一小时复盘会。议程就三项：这个月 Agent 排错了哪些（逐条过台账）、哪些新场景规则没覆盖、下个月要不要放开一点权限。会议纪要就是下个月的开发清单。这个会开到第三次的时候，排产员开始主动提规则改进建议，不再只是「报错」。从被引导到主动提，这个转变比任何技术指标都值钱。

模型上，我们把排产员对每份计划的「改没改、怎么改」记录下来，作为模型解释质量的评测数据。哪些解释排产员认可、哪些被跳过，都有反馈。三个月里，模型生成解释的「一次认可率」从 60% 左右提到了 80% 以上。这套反馈回路的价值在这里：没有反馈，模型不会自己变好。

这里补一句我们踩过的坑：别急着上更高级的模型。中间有段时间我们想换个更强的模型，觉得排产质量还能再提。试了之后发现，瓶颈根本不在模型，在数据的时效性和规则的完整性。换模型没用，补数据、补规则才有用。这个认知，比技术本身更值钱。

七、如果你的公司也在纠结，记住这几件事

排产 Agent 这件事，我们做完这家公司，最大的体会是：它不是买一个工具，是重新设计一条排产的流水线，让人和 AI 各干各擅长的。

如果你也想上，我建议记住四件事。

第一，先问自己数据齐不齐，再问 AI 行不行。数据烂，AI 只会把烂放大。

第二，把规则挖出来再动手。老师傅脑子里的隐性规则，是 Agent 能不能被接受的命门。

第三，让排产员有否决权。AI 排的计划必须人工确认，这不是效率的妥协，是信任的起点。

第四，把"谁错了"做清楚。员工不怕 AI 出错，怕的是出了错查不清、说不明。溯源做好了，信任自然来。

排产 Agent 接进 MES 和 ERP，接口难，规则难，但最难的，是让那个排了多年的人，愿意把一半的活交给它。技术解决的是"能不能排"，信任解决的是"敢不敢用"。这两件事，一前一后，缺一不可。