1. 为什么供应链预测卡在了最后一公里而不是模型精度做供应链预测的朋友应该都有过类似经历手上模型的效果明明已经跑到了不错的MAPE但业务部门拿着预测结果问你的问题永远是——你这个数怎么来的为什么这周突然涨了30%下周的大促叠加缺货你能看到吗我在某制造供应链的数据团队里接手需求预测模块时最初的直觉也是模型不够强换个更强的。当时我们在用的是一套以统计方法为主的基线模型配合几个时序模型做候选池按验证集表现选最优。整体效果不算差但有两个问题始终绕不开。第一个是外部信息进不来。模型看到的是历史销量、库存、价格这类数值但业务里真正驱动需求变化的往往是促销安排、竞对动作、节假日迁移、甚至某天的舆情事件。这些信息不是没有而是散落在业务系统的各个角落传统时序建模很难把它们的信号及时吃进去。第二个是结果没法对话。预测出来一个数业务想理解为什么模型给不出解释。他们只能再去翻活动日历、看库存记录、问运营同事相当于预测系统只管发数字说服工作全由人来扛。后来我们试过直接把历史序列和外部事件描述灌给语言模型让它看着办。结果更不靠谱幻觉、数字不稳定、跨批次复现性差连最基本的过去12周的销量呈上升趋势这种话不同轮次跑出来措辞都不一样更别提让它输出可信的预测值了。真正改变思路的是我们开始把问题从预测得更准转向如何组织好一堆预测工具和业务信息让它们协同工作。这个中间编排层业界叫 Agent Harness Engineering——不追求某一个模型无所不能而是让一个具备推理能力的 Agent 去调度时序模型、规则引擎、业务知识库和外部数据源共同产出预测结果并解释逻辑。这套思路落地之后团队内部的价值感完全不一样了预测模型负责给数字基准Agent 负责补业务上下文和推理过程最终输出的不只是一个值而是一份有依据、可追问的预测结论。这篇文章就围绕这个方案展开重点讲清楚我们在落地过程中踩过的坑、想明白的取舍以及一套可以直接参考复现的最小架构。2. 先拆解多变量时序与LLM各自的边界再谈结合2.1 传统模型擅长从历史推未来但擅长不了理解世界时序模型不管多复杂本质上做的是同一件事从历史序列中提模式然后外推。这在相对稳定的需求场景里屡试不爽。比如某类标准工业件的备件需求季节性稳定、生命周期长、外部扰动少ARIMA、ETS甚至移动平均都能给出不错的预测。但供应链里大量场景并不满足稳定假设。举个我们实际遇到的情况某品类在电商渠道有一波大规模直播推广单日销量冲到平日的8倍之后回落。时序模型看到这个点后会把它学进季节性或者趋势成分里导致接下来几周的预测都被抬高。模型不理解这是偶发推广事件不是新常态因为它没有渠道去知道直播推广那天发生了什么。这类问题的本质是信息的模态鸿沟数值序列能表达结果但表达不了原因。而原因恰恰藏在非结构化的信息里——活动排期表、运营周报、竞品动态、天气预警。2.2 直接用LLM裸测预测会栽在四个地方一开始我们认为既然LLM能理解自然语言那就把历史数据转成文字喂给它让它直接输出预测值。实验下来失败得非常稳定基本有四种典型问题数值敏感度低。语言模型是按token说话的它并不是真正在做数值运算。让它判断序列整体上行还是下行它做得不错但让它输出具体到个位的预测数字经常出现对细微变化的无感。比如过去三周销量分别是980、1020、1010它可能直接给你预测个1250完全没有意识到序列已经进入平台期。输出不稳定。同一个Prompt、同样的数据跑两次结果不一样。这在工程上非常致命预测系统需要可复现性。业务追问昨天你预测980今天怎么变成1050了数据没变啊你没法解释。缺乏约束力。LLM没有内置的合理区间概念它可能预测出一个负数或者一个比历史峰值高十倍的数字并且一本正经地给出理由。供应链预测一旦出现这种离群输出下游计划系统直接乱套。无法确保使用正确的数据。你给它12周的历史数据它可能只看到了最近4周或者把周同比当成环比来理解而且你很难知道它到底用了哪些数字。这种不可控性让它在生产环境里完全没有安全感。但这些失败反而帮我们明确了一点LLM真正的价值不在于数值外推而在于语境理解和多步推理。它可以解释为什么某个信号重要可以判断当前场景该调用哪个模型可以把外部事件的因果逻辑串成一条可验证的链。关键是不要让LLM硬算而是让它编排调度——这就是Agent Harness的核心思想。2.3 Agent Harness到底管什么如果用一句话概括Agent Harness 是给LLM装上一套工具约束记忆的外骨骼让它在供应链预测场景里能稳定地完成多步任务。具体到我们这个项目它主要管四件事工具注册与路由系统里挂了多个预测引擎——Prophet、XGBoost、ETS、简单基线以及一个规则计算器。Agent根据数据特征和业务场景决定调用哪个工具、调用几个工具、以什么顺序调用。上下文装配把历史销量、库存状态、促销日历、外部事件浓缩成结构化的上下文块按相关性和时间窗口排列控制token开销不让Agent一次性接触过多噪声信息。推理轨迹管理要求Agent按步骤输出——先判断状态再选择工具再解释理由最后给出预测建议。每一步都留痕业务可以回溯整个预测是怎么来的。输出约束与校验Agent的输出必须是预定义的JSON结构或选项集合还要经过规则校验器检查比如是否在合理范围内、是否与长期趋势矛盾。不合规直接打回重做。这套设计本质上是个质量护栏允许LLM有灵活性但决定性步骤必须落在程序可控的轨道上。3. 多变量时序特征工程决定Agent看到什么的翻译层这里想重点聊聊这个方案里最容易被低估的环节——怎么把多变量时序数据翻译成LLM能高效消费的形式。前面说过LLM对数字的敏感度远低于对模式和关系的敏感度。所以特征工程的目标不是尽可能多地把数字喂给它而是让它以最小代价捕捉到关键模式。我们从几个层面做了处理。3.1 特征选择别把整个历史序列都扔给Agent供应链预测相关的变量很多但Agent的上下文窗口是有限资源。我们最终保留了以下几类高价值信息特征维度具体内容为什么重要需求历史最近8-12周周销量、4周移动平均判断短期趋势和波动基线同比基准去年同期的销量、增长率捕捉季节性迁移和年同比变化业务事件未来4周内的促销日、上新日、库存限制外部驱动因素的核心来源库存状态当前库存水位、在途量、可售天数直接限制可达成销量价格变化近期调价幅度、折扣力度价格弹性对需求的即时影响外部宏观节假日前后的班次调整、出行结构变化特殊时段需求的规律性偏移值得注意的是不是变量越多越好。我们把所有可选特征喂给Agent做过实验发现它在信息过载时反而容易忽略关键事件。后来改成按品类预配置特征模板每个品类只暴露与之最相关的一组变量效果明显提升。比如生鲜品类重视保供天数和气温耐用消费品品类重视促销周期和库存深度。3.2 把序列转成模式语言而不是数字流早期我们尝试过直接把12周的销量数据用逗号分隔拼成一段文字喂给Agent比如1200, 1250, 1180, 1340,...。效果很差它根本抓不住序列的形态特征。后来我们换了一种方式先程序化提取模式描述再让Agent在这个基础上推理。比如- 最近4周平均销量1280前4周平均1150环比上升约11.3% - 最近8周趋势整体上行但第6周有明显回落对应促销空档期 - 去年同期同4周1040同比上升约23% - 未来2周事件B类促销活动预计折扣幅度15% - 库存状态当前可售7天低于安全水位这样Agent看到的是一份高度凝练的状况简报而不是一堆需要它自己解析的原始数字。它能够在此基础上做推理趋势上行 即将促销 库存偏低 需要警惕供不应求建议预测值考虑供应上限约束。这个设计背后有个原则计算模式的活交给程序解读含义的活交给LLM。不要强迫LLM去做数值计算那是Python的强项要让LLM做它擅长的部分——基于模式理解做出判断。3.3 窗口设计与事件对齐的细节特征窗口的长短直接决定Agent的时间视野。我们试验下来推荐这样的窗口组合短期窗口最近8周密度按周计用来判断即时趋势季节性窗口去年同4-6周用来捕捉年同比模式事件窗口未来2-4周的活动与限制用来前视判断窗口太长噪声和无用信息会稀释关键信号太短季节性模式看不到。8周是我们对不同品类做敏感性测试后的折中值。事件对齐需要特别注意一点促销日期、上新日期在落地时经常延期或调整所以事件窗口的数据必须是动态拉取的不能靠离线快照。我们做过一次事故某次大促因为物流原因推迟了一周Agent的预测还按原日期外推结果高估了那一周的销量。后来把所有外部事件改为API实时拉取并让Agent每一步推理前先确认当期事件列表问题才解决。4. Agent工作流设计从一个模型预测到一次预测推理4.1 整体流程骨架我们落地的工作流不只是调用LLM一次出结果而是设计成了多步流水线每一步都有明确的输入、输出和校验点状态识别Agent先读取压缩后的状况简报输出对当前需求状态的判断——快速增长期、平台期、下行期、波动异常期。模型选择基于状态判断Agent从候选模型池里选择主模型和辅助模型并说明理由。比如数据上有明显趋势和季节性建议以Prophet的预测为基础最近4周波动较大XGBoost可能更敏感作为交叉参考。基础预测获取程序调用选定模型生成预测值这一步不经过LLM保证数值的可靠性和可复现性。事件叠加修正把基础预测交给Agent结合业务事件判断是否需要修正。比如基础预测为1250但下周有15%折扣的促销根据历史同类活动平均提升25%-35%建议修正区间为1560-1690。合理性校验Agent输出修正结果后经过规则引擎校验。如果预测值超过历史合理区间、或者出现了方向性冲突比如库存严重不足却预测高增长则标记为异常并交给人工复核。解释生成最终输出预测值、区间、依据和风险提示。这个流程很有意思的一点是LLM在其中的角色更像是一个项目负责人而不是计算员。它负责理解目标、分派任务、汇总判断、解释结果实际数值计算由专业的时序工具完成。下面是一个极度简化但能表达核心思想的伪代码def run_forecast_agent(context, available_models): # 步骤1状态识别 state agent.identify_state(context.status_brief) # 步骤2模型选择 selection agent.select_models(statestate, candidatesavailable_models) if not validate_selection(selection): raise ForecastError(模型选择不合理) # 步骤3基础预测程序执行不经过LLM base_forecast run_forecast_model(selection.primary_model) if selection.secondary_model: ref_forecast run_forecast_model(selection.secondary_model) # 步骤4事件修正LLM推理 adjustment agent.adjust_with_events( basebase_forecast, eventscontext.upcoming_events, event_historycontext.similar_event_records ) # 步骤5规则校验 final_prediction rule_validator(adjustment, boundscontext.reasonable_bounds) # 步骤6解释生成 explanation agent.explain( final_predictionfinal_prediction, base_forecastbase_forecast, reasoning_stepsadjustment.reasoning ) return final_prediction, explanation这段代码不是可以直接上生产的级别但可以看出分工边界Agent负责判断和解释程序负责数值计算和规则校验两者各司其职。4.2 让Agent知道该信谁是模型选择的关键在多模型环境里Agent面临的核心挑战不是哪个模型平均更准而是在当前数据特征下哪个模型更可信。这两个问题完全不同。我们构造了一个简单的模型画像表给Agent做参考模型擅长场景弱项适用的数据特征ETS稳定的趋势季节性对突变不敏感周度数据、低噪声Prophet多季节周期、缺失值容忍度对非线性事件反应迟钝月度/周度混合周期XGBoost特征丰富、非线性模式数据量小时容易过拟合有外部特征的场景简单基线极度稳定的品类无法捕捉复杂变化低波动、长生命周期产品Agent选择模型时我们要求它不仅给出选择结果还要给出一个可信度打分比如此品类数据量偏少且波动大XGBoost容易过拟合我倾向选择Prophet可信度0.72建议辅助参考简单基线。这个打分并不直接用于加权计算但它会写入预测日志帮助团队后期审计Agent的决策质量。4.3 事件修正中的记忆检索与相似案例大多数供应链事件不是第一次发生。每次大促、调价、上新事后都会有实际销量数据回填。我们把这些历史事件和对应的需求变化系数沉淀成一个事件知识表Agent做修正时先去检索最相似的3个历史事件用它们的实际效果来支撑推理。举个例子某品类下周四有个满减活动Agent检索到去年同品类类似力度的满减活动在当时创造了约28%的销量提升并且活动结束后一周销量回落约15%。它据此给出的修正预测就比凭空猜一个涨幅要可靠得多。这个机制本质上是给Agent装了一个经验记忆系统而记忆的来源正是组织里长期积累但未被有效利用的运营记录。做这个表的时候要注意清洗数据只收录有明确开始结束时间、有明确影响口径的事件并且同类事件至少要有3次以上才纳入参考避免用单次特殊情况误导Agent。5. 最终验收环节不只问准不准还要问替谁省了什么5.1 拿什么指标考核这套体系单纯对比MAPE或WAPE很容易陷入一种误区Agent方案在某几个品类上表现突出在另一些品类上跟传统模型打平甚至略差那到底算成功还是失败我们后来把评估体系分成三层第一层数值精度。还是看MAPE、覆盖率、偏差方向这是最基础的底线不能比传统模型差太多。第二层业务决策价值。采购和计划是否愿意采纳这套系统的预测采纳后动销率/库存周转是否有改善这个维度比纯误差数字更重要。团队里后来约定预测可以说偏了但如果预测帮助业务多抓住了两个热销SKU的备货机会那体系就是有价值的。第三层解释与审计成本。业务问为什么这么预测时团队需要花多久回答出来传统模型往往需要半天甚至更久去翻数据、猜原因Agent方案因为有推理留痕几分钟就能给出解释链条。这个成本的下降是以前没预料到的最大红利。5.2 对比实验怎么设计才不骗自己我们做对照实验时把同一批历史数据切成三类来测纯时序模型用最佳单项模型预测不做事件修正。LLM裸预测把序列和事件描述直接交给语言模型输出数值。Agent Harness方案完整流程含工具调用、事件检索、规则校验。结果在意料之中Agent方案在MAPE上没有碾压纯模型但在业务事件密集的时间段内误差明显更低LLM裸预测在数字稳定性上惨不忍睹直接出局。这个结论很关键——Agent的收益集中在有外部事件扰动的场景而这类场景恰恰是传统模型最薄弱的地方。5.3 方案框架评估成本和时延不划算怎么办必须诚实地说Agent方案不是免费的。每次预测调用会涉及多次LLM推理单SKU的预测耗时从毫秒级涨到秒级成本也更高。如果你的场景是每天凌晨跑一次全量预测完全可以接受如果业务要求实时的自动补货决策那可能需要先做一轮模型压缩和结果缓存。我们做了一个分级策略对波动小、历史稳定的SKU直接用传统模型跑不进Agent链路只有达到一定波动阈值、或者未来两周内存在事件的SKU才走完整流程。这让整体成本下降了约6成而预测质量基本没受影响。这是我认为整个落地过程中最值得做的工程优化——让Agent去处理它最能增值的边界场景而不是大包大揽。6. 实际运行中的故障清单与调优手记6.1 上下文窗口不够用怎么压缩不丢信息供应链场景的上下文可能包含12周周度数据、未来4周事件、库存水位、价格变化、相似案例记录全部展开很容易超过上下文长度限制。试过几轮以后我们确定了压缩原则是先算好再简述最后只留结论和关键数字。程序先把所有数据预处理成上面说的状况简报再把相似案例只保留Top3的摘要事件描述控制在每条约20-30个字。最终每次预测的上下文控制在1-2K token以内效果和全量信息几乎一致。6.2 模型看不到的盲区Agent也看不见——除非你教它看这是一个容易让人产生错觉的地方你以为加了Agent它就能自动发现所有影响因素。但实际上如果某个信息源没有接进来Agent根本不知道它的存在。有一次某品类的销量突然飙升Agent给的解释是趋势上行动能增强听起来合理但完全没说到点上。后来分析发现真正原因是某大客户提前下了一个大单。这个信息存在CRM系统里根本没有进入预测链路。你没法指望Agent主动去查一个自己不知道存在的系统——所以数据接入清单比Prompt调优更优先。每季度盘一遍哪些业务动作会影响需求它们的数据在哪接进来了没有是维持体系有效的日常工作。6.3 数字描述方式的颗粒度影响推理质量同一个信息有两种写法写法A第6周销量为980写法B第5周销量为1020第6周为980环比下降3.9%Agent在处理写法A时容易把所有数字都当成独立点看不出趋势写法B直接把关系和变化量给出来了它的判断就准确得多。我们最后的规则是凡是涉及比较的信息一律按对比差值比例描述绝不只扔绝对数值。这里涉及语言模型的词元切分机制LLM数值感知能力弱一个细微差异要花很多 token 才能看到而相对变化是现成的叙述直接给它结果比让它自己算可靠得多。这条经验放到任何数据结合LLM的场景都适用先把变化算出来再让模型去解释变化。6.4 输出结构化让Agent说人话但按代码格式说最后一条是工程上的关键约束Agent的输出一定要限定结构化格式。我们使用的Schema大概是这样{ state: growth, selected_models: [{name: prophet, confidence: 0.72}], base_forecast: {point: 1250, interval: [1120, 1380]}, adjustment: {value: 350, reason: 促销活动预计提升25%-30%}, final_forecast: {point: 1600, interval: [1440, 1760]}, explanation: 趋势上行叠加下周B类促销活动预测区间上调, risk_flags: [库存可售天数低于8天可能限制实际销量] }如果Agent返回的JSON缺字段、或者区间上下界写反了直接被规则引擎拦下来重跑。强迫结构化的另一好处是可以做回归测试每次更新模型或Prompt后在历史数据上回放一遍看有几条输出变了、变化方向是否合理。这套回归机制几乎是我们在生产环境里敢持续迭代API的底气。把Agent Harness这套思路落地到供应链预测我们走了一条从追求更准的模型到设计更聪明的协作流程的转折。如果你现在面对的问题也是模型够强但业务仍旧不买账我的建议是别急着换算法先画一张图你的预测链路里外部信息从哪里来谁来解释结果的合理性和风险如果这两个问题答不上来那大概率缺的不是更强的模型而是一个能把模型、数据和业务语境编织到一起的Agent编排层。可以先从最小闭环试起把一个品类的预测流程跑通再逐步扩品类、补工具这条路会比你想象中走得稳得多。