业务人员的需求在变，模型却在重来
运筹优化长期存在一个供需错配：懂业务约束的人往往不熟悉建模与求解器，而熟悉求解器的人不一定了解业务现场。基于大模型的优化智能体正是为了填这道缝——业务人员用自然语言描述需求，模型把它翻译成优化模型或求解程序，交给成熟工具去算。
但真实运营不是一次性的。需求会变，资源会变，优先级会变，这意味着数据、约束和目标函数都需要更新。问题在于，目前多数做法是围绕「孤立的一次请求」设计的：每次新请求到来，系统从头理解、从头建模、从头求解。上一轮已经确认过的决策、已经跑出来的候选解，往往不被保留，更谈不上复用。
2026 年 9 月 10 日提交到 arXiv 的一篇论文（编号 2609.11636）针对的正是这个断层。作者 Kesheng Chen、Yamin Hu 与 Wenjian Luo 提出了 MAPLE，全称 Memory-Augmented Planning with Language and Evolution，即「基于语言与进化的记忆增强规划」。
MAPLE 保留了什么
MAPLE 的定位是「在连续的自然语言请求中维护优化问题」的智能体。它的技术组合有三块：基于语言的问题构建、数学规划、进化搜索。
更值得注意的是它的记忆内容。按照论文描述，MAPLE 会保留四类状态：优化程序本身、已被接受的方案、先前的更新记录，以及候选解集合。这四类状态在后续请求中都可被调用。
这个设计选择对应着前面提到的痛点。保留优化程序，意味着新一轮不需要重新建模，只在既有结构上做增删改；保留已接受的方案，意味着新的解可以在历史决策的基础上演进，而不是把过去的决定全部推翻；保留更新记录，让系统知道哪些约束是被有意调整过的，避免把人的决策当成需要纠正的误差；保留候选解，则让搜索过程不必从零开始——上一轮接近可行但被淘汰的解，在约束放宽后可能立刻变得可用。
论文里有一句结论值得留意：对照实验表明，维护可执行状态能提升更新的有效性，并且在发生较大幅度的修订时，仍能保留有用的搜索信息。这句话的技术含义是，记忆的价值不在于「记得多」，而在于「记得的东西是可执行的」。这与把对话历史塞进上下文有本质区别——前者是可运行的模型与方案，后者只是文本。
NLDO：为「连续修改」这件事专门造的基准
论文同时提出了一个名为 NLDO 的基准。它的规模是 15 条轨迹、180 次更新，覆盖五类任务：选择、排程、值班（rostering）、路径（routing）与云资源放置。
这个基准的设计意图很清楚：它不是测「能不能解一个优化问题」，而是测「能不能在连续修改中保持一致性」。这正是现有优化智能体评测的空白。多数基准给的是一个静态问题，模型解出来就算完成；而真实运营中，问题会在一段时间里被反复调整，每次调整都建立在上一轮的结论上。
任务类型的选择也说明问题。排程、值班与路径都是典型的运营优化，特点是约束多、冲突频繁、且修改常常牵一发动全身；云资源放置则带有弹性与成本权衡。这些都是「改一处、动全身」的场景，最能暴露记忆断层带来的代价。
主评估的结果是，MAPLE 完成了全部轨迹，在线标量质量为 0.951，帕累托超体积比为 0.875。前者衡量的是解的绝对质量，后者衡量的是解集在多个目标之间的覆盖程度。两个指标一起看，说明它不仅能找到好解，还能在多目标权衡上给出分布合理的解集——这在真实决策里往往比单一最优解更有用，因为决策者需要看到取舍空间。
与相邻研究的分工
把 MAPLE 放进 2026 年 Agent 记忆与规划这条研究脉络里，它的位置会比较清楚。
一条相邻的线索是执行结构的自演化，例如把操作知识组织成有向图并让智能体根据执行轨迹改写图的拓扑与属性，代表是过程图类的工作。那条线关心的是「怎么做」这类流程性知识如何被结构化与修正。
另一条线索是记忆的代价核算，例如在工具调用型智能体上做成本敏感的长期记忆评估，追问「记住某件事到底有没有改变智能体的行为」。那条线关心的是记忆的效度与成本边界。
MAPLE 关心的是第三类问题：在连续的业务请求中，如何维护一个可执行的优化问题状态。它的记忆对象不是对话、不是流程，而是模型、约束、方案与候选解。这三条线索并不冲突，反而在构成同一个方向的不同切面——智能体的「记住」，正在从存储与检索的问题，变成状态维护与演进的问题。
中立思辨
需要辩证看待几件事。其一，0.951 与 0.875 是作者在自建基准 NLDO 上得到的结果。基准由提出者设计，任务分布与难度设置带有主观选择，这类数字在与其它方法横向对比前需要谨慎。此外，15 条轨迹与 180 次更新的规模属于中小体量，覆盖的任务类型虽然跨度不小，但每条轨迹的深度有限，尚不足以说明在长期、高频、跨月度的真实运营中是否稳定。
其二，维护可执行状态是有代价的。保存优化程序、历史方案与候选解，意味着状态会随时间增长，检索与复用都需要额外的管理策略。论文强调了收益，但对状态膨胀如何控制、何时该淘汰旧信息，摘要层面没有展开。
其三，进化搜索的引入会带来额外的求解成本。在排程与路径这类问题上，求解本身就不便宜，再叠加进化循环，单次请求的计算开销可能显著上升。它适合的场景更可能是「决策代价高、调整频率中等」的运营问题，而不是需要秒级响应的高频场景。
其四，本文引用的方法与数值来自论文摘要与二手整理，具体的基线对照、消融实验与失败案例分析需要查阅原文核对。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
对落地团队的三点启发
即便不直接采用这套方法，它指出的三个做法都可以借鉴。
一是把「上一次的结论」显式存下来，而不是留在对话历史里。优化类智能体的状态应该是结构化的模型、约束与方案，而不是一段文本。文本无法被执行，也无法被校验。
二是区分「人改过的」和「模型算错的」。在连续运营中，约束被调整往往是业务决策的结果，而不是数据误差。系统如果分不清这两者，下一轮就可能把人的有意决定纠正回去，这类错误在真实场景里代价很高。
三是保留被淘汰的候选解。在约束放松、资源增加或优先级变化之后，上一轮不可行的方案可能重新变得可行。丢弃它们等于每次都从零搜索，而搜索成本恰恰是这类系统最贵的部分。
优化智能体的价值，最终不在于它能不能解出题，而在于它能不能陪着一个持续变化的业务，把上一次的决定接着往下走。