一家小卖部的老板是 LLM 智能体。第一天它很聪明记住了顾客口味给滞销品定了促销价第二天它却像换了个人把昨天的承诺忘得一干二净。单看每轮对话它都答得有理有据放进连续经营场景却撑不过几天。MerchantBench 这类评测要抓的正是这个越来越常见的尴尬LLM 智能体单轮很强长期经营却缺乏连贯性。我对这个方向有一个明确判断LLM 智能体从“能完成任务”走向“能长期经营业务”中间最大的分水岭不是单次任务成功率而是长期连贯性。单步能力强只能说明模型在某一个瞬间能做出合理反应长期经营场景里它还要能在几十轮甚至几百轮的决策中始终记得自己说过什么、做过什么、承诺过什么并且不让后面的行动推翻前面的判断。MerchantBench 这个名字背后的价值不只是一个新榜单而是把“连贯性”这种以前只能靠人工体感判断的缺陷变成一套可观察、可度量、可复盘的评测命题。1. 一个能答对题却守不住店的智能体问题出在哪1.1 单轮很强连续经营却容易露馅最近测试了不少 LLM 智能体应用一个很典型的现象是单轮任务的成功率看起来不差一问一答、调用工具、生成结果都像模像样。但一旦把任务拉长让它连续处理一个店铺的经营事务问题就接二连三地冒出来。比如智能体在前一天给某位老顾客承诺了会员折扣第二天顾客回购时它完全不记得这回事再比如它上午刚制定了一个“清库存优先”的促销策略下午却因为一条临时消息转头给库存充足的高利润商品做了更大力度的折扣。从单个决策看每一个选择都说得通但放在一起看这个智能体就像在帮倒忙。它不是在经营而是在不断制造前后矛盾。这让我想到一个场景你招了一个很聪明的新员工反应快、表达好但没有任何长期记忆也不遵守自己前一天定下的规则。你愿意让他独立看店吗显然不愿意。因为真实经营不是一道道独立的判断题而是一条连续的时间线。今天的行为会变成明天的约束昨天的承诺会变成今天的责任。如果智能体在时间线上不能保持连贯那它的单点能力再强也很难真正承担经营任务。1.2 长期连贯性是一条独立的评价维度很多人会把“长期连贯性”理解成“准确率更高一点”。其实不是。准确率衡量的是“单次回答是否正确”连贯性衡量的是“一系列决策在时间轴上是否彼此一致”。这两件事可以完全分离。一个 LLM 可以在每一次任务里都答得正确却在整体上表现得像一个失忆的病人。比如它每次都能算对库存但每次算完都不更新状态导致第二次的结论建立在一个已经失效的基础上它每次都能生成合理的定价但每次生成的定价逻辑都不一样导致顾客面对一个毫无规律的商家。所以评价一个 LLM 智能体能不能长期经营不能只看“这个动作对不对”还要看“这个动作和之前所有动作加起来构成了一个什么样的故事”。MerchantBench 这类基准的切入点正是把这条时间线上的连贯性单独拎出来作为核心评测对象。这个视角本身比具体榜单排名更值得关注。2. 为什么过去的主流评测很难发现这类问题2.1 短任务评测的隐含假设过去常见的 LLM 评测大多建立在“短任务”假设上给一个指令模型输出答案裁判打分。这类评测适合衡量知识问答、代码生成、单次工具调用等场景因为任务之间互相独立上一题的答案不会影响下一题的判断。但这种评测设计隐含了一个前提每一轮任务都是“无状态”的。模型不需要记得上一轮发生过什么也不需要维护一个跨步骤的业务状态。于是评测结果只能回答“这个模型能不能做对这件事”回答不了“这个模型能不能连续做对一百件事”。长期经营场景恰恰是反过来的。在这里状态才是主角。库存、现金流、顾客等级、供应商账期、历史促销记录这些信息不会被重置而是不断累积。每一次决策都在改变后续决策的输入。如果一个智能体连“当前库存还剩多少”都追踪不准那它在后续所有关于补货、定价、承诺交付时间的决策上都会跟着出错。2.2 经营场景里“状态”才是主角用更直白的话说经营类任务的核心不是一个文本生成问题而是一个“状态维护”问题。你开一家店本质上是在维护一组事实仓库里有什么、货架上缺什么、钱够不够周转、哪些顾客答应过什么折扣、哪些供应商承诺什么时候到货。LLM 智能体要做的不是“想出一些漂亮的经营建议”而是让这些事实始终保持正确并基于正确的事实做下一轮决策。这正好是传统评测最容易遗漏的部分。传统评测里输入和输出都是一段文本模型不需要理解“当前世界处在什么状态”。而 MerchantBench 这类评测如果要成立就必须建立一个可以持续切换、持续更新的模拟环境。环境里有一个“客观事实”智能体自己的“认知”以及两者之间的偏差。评测的很大一部分工作就是在测量这个偏差什么时候会被拉大以及拉大之后智能体会不会及时发现并修正。2.3 连贯性问题的三层表现记忆、决策、目标从实际观察看长期经营中的连贯性问题通常会体现在三个层面这三个层面也基本构成了一致性评测的分层框架。第一层是记忆层。智能体忘了自己说过的话、做过的事。典型表现是顾客已经收到过退款它又处理了一次退款供应商已经答应延期它还在按原计划催货。第二层是决策层。智能体面对相同情境时给出彼此冲突的策略。比如促销规则朝令夕改优惠力度没有稳定依据导致整体行为像是随机游走。第三层是目标层。智能体在做短期决策时丢掉了长期目标。比如为了冲一单交易量把利润压到不可持续甚至破坏了已在执行的清库存计划。这三层问题单靠“单轮任务正确率”是测不出来的因为每一轮单独看都可能是合理的。只有把时间拉长把状态变量加进来才能看到记忆的丢失、决策的漂移和目标的偏移。MerchantBench 这类基准要做的就是把这些时间相关的问题变成显式测试项。3. MerchantBench 的评测重心把“长期经营连贯性”拆成可观察的维度3.1 核心命题从“这一步对不对”转向“一路走来合不合理”从项目标题能看出MerchantBench 把场景定在了“商户经营”上核心评测对象是 LLM 智能体在长期经营中的连贯性。这种评测的核心命题不再问“这一步做得好不好”而是问“把整个经营过程连起来看它讲不讲逻辑”。单个动作合理不代表整条经营路径合理。这就像看一部连续剧每一集单独拍都不差但连起来看人物感情线前后矛盾时间线对不上观众就会弃剧。LLM 智能体的长期经营也一样裁判不应该只看“每一集”的质量还要看“整季”的叙事是否成立。因此评测过程大概率会围绕一个多智能体或单人经营模拟场景展开让智能体扮演经营者连续处理多轮业务事件比如接待客户、制定价格、管理库存、处理供应商问题、应对市场波动。评测者不再只给它一个标准答案而是看它在整个过程中是否始终维护着一套自洽的经营行为。3.2 维度设计目标保持、状态追踪、决策一致、记忆连贯、抗扰动恢复如果要设计一份“长期经营连贯性”的评测观测表至少应该覆盖以下几个维度。这些维度不是官方指标更像是从工程视角出发的通用拆解。维度要回答的问题典型翻车表现目标保持是否始终服务于设定的经营目标为了短期成交破坏长期利润或清库存计划状态追踪是否准确维护库存、资金、时间等状态把已售出的商品继续当库存来卖决策一致对相同情境是否给出不冲突的决策促销价定了半天又无理由改回原价记忆连贯是否复用之前的承诺、偏好和结论忘记老顾客的折扣忘记自己的补货安排长程规划计划与实际执行是否对得上前面承诺的交付时间后面根本无法兑现抗扰动恢复出现意外后能否不破坏已有承诺供应商断货后随意改价引发连锁矛盾其中抗扰动恢复可能是最容易被低估的一项。现实经营里意外是常态供应商延迟、顾客投诉、价格波动、竞争对手突然促销。智能体面对的从来不是一条顺滑的业务流而是一个不断被打断、需要重新规划的世界。真正连贯的经营者不是永远不变而是知道哪些东西必须保持不变哪些可以调整以及调整之后如何向相关方交代。3.3 评测环境的隐藏设计状态真值、时间推进、事件注入要支撑以上维度的评测光有题目和答案是不够的评测环境本身的设计会决定结果的有效性。这三点在 MerchantBench 这类基准里通常很关键。第一环境要有“状态真值”。也就是说系统内部要维护一份客观、权威的经营状态包括库存、资金、顾客记录、历史承诺。智能体的输出必须落在真值之上而不是自己构造一个虚构世界。第二环境要能推进时间。经营是跨天的、跨周的不是一次性问答。如果没有时间推进就无法测试“记住昨天”和“规划明天”。第三环境要能注入事件。随机波动、突发消息、顾客异常行为这类事件是经营连贯性的压力测试工具。没有事件注入智能体只要按固定模板回答就很容易表现得很“连贯”但那种连贯只是死板不是真正的稳定。4. 这类基准真正难在设计状态、度量和成本三关4.1 第一关状态空间怎么建模如果只看表面你会觉得评测一个 LLM 智能体“连不连贯”很简单给它一个模拟店铺跑几天看它表现如何。但真正动手设计之后第一个麻烦就来了状态空间怎么建模。经营状态不是一两个字段而是一组相互关联的变量库存数量、资金余额、订单状态、顾客偏好、供应商条款、历史价格、未完成承诺。更麻烦的是这些变量之间还有约束关系库存减少是因为卖出了订单资金增加是因为收到了回款顾客折扣会影响收入供应商延期会影响库存。如果环境不能精确模拟这些联动关系那评测就失去了意义。因此评测环境通常需要把经营过程抽象成一组“状态转移规则”。智能体的每个动作都必须能被解释成对状态的一次修改。这个抽象过程非常考验设计者对经营业务的理解规则太简单评测失真规则太复杂环境维护成本极高而且很难定位失败原因。4.2 第二关连贯性怎么打分另一个难点是打分。传统评测的分数很好算答对了给一分答错了不给分。但“连贯性”是一个跨步骤的、相对性的概念很难用“一步一分”来量化。从常见评测设计思路看连贯性度量可以朝几个方向拆。一个是“状态偏差率”也就是智能体认知中的状态与客观真值不一致的次数占总交互轮次的比例。一个是“承诺违反率”也就是智能体之前做出的承诺在后续行动中被打破的比例。一个是“策略漂移度”也就是在面对相同或高度类似情境时决策发生无依据变化的幅度。还有一个是“经营结果指标”比如累计利润、顾客满意度、库存周转率这些指标本身就能间接反映整体的经营质量。要注意的是这些度量方法各有偏重。状态偏差率适合抓低层错误承诺违反率适合抓信用问题策略漂移度适合抓决策稳定性。单一指标很难覆盖全局。更稳妥的方式是多个指标并行观察最后再看经营结果这个“结果变量”是否被拖累。4.3 第三关长程评测的代价和方差长程评测还有一个绕不开的现实问题成本。一次评测要跑很多轮交互每一轮都要调用 LLM都会消耗 token。评测的规模稍大一些成本就会快速上升。更麻烦的是长程任务本身带有随机性。经营模拟里通常会有随机事件市场波动、顾客随机到访、供应商随机延迟。这些随机因素意味着两次跑同一套评测智能体面临的环境并不完全一样。如果它第一轮生意好可能是因为运气好而不是因为决策连贯。要区分“运气”和“能力”就必须做多轮次、多样本重复实验。但重复实验又意味着成本成倍上升。这是一个需要平衡的问题。设计评测时通常的做法是先控制随机事件的频率和幅度让环境在“有波动但可复现”之间找到一个中间点同时对不同随机种子跑多次实验用平均结果作为参考而不是只看一次运行。4.4 一个常见误判评测分数高不等于经营能力强任何评测都会有边界MerchantBench 这类基准也不例外。一个智能体在长期经营连贯性评测里拿到高分只能说明它在当前这套模拟环境里能保持目标、记忆、决策的一致性。这并不能直接等同于它能经营好一家真实店铺。原因很简单真实经营的变量远多于模拟环境。真实世界里有真实的合同、真实的人际信任、真实的物理交付、真实的法律责任。这些都不是一个小型模拟器能完整建模的。更微妙的是过度追求“连贯”也可能带来反效果。一个永远不改变策略的智能体会显得非常一致但它实质上变成了僵化。真正的经营连贯性应该是在“保持核心目标稳定”和“根据新信息调整执行方式”之间取得平衡。所以我对这类评测的态度是它是很好的必要不充分条件。如果智能体在模拟环境里都连不连贯那放到真实场景大概率更难控制但如果它在模拟环境里连贯只能说具备了进入真实经营场景的必要前提离真正独当一面还有距离。5. 从评测到落地自家 Agent 怎么验证长期一致性5.1 先定义“不能破坏的事实”对大多数开发者和技术团队来说不一定有机会复现 MerchantBench 的完整环境但可以借鉴它的思路验证自己正在开发的 Agent 是否具备长期一致性。最直接的做法是从业务中抽取一组“不能破坏的事实”。这些事实是 Agent 在做决策时绝对不能搞错的约束。比如某个订单的支付状态、某个用户约定的交付时间、某一商品的当前库存、某条促销规则的生效区间、已经向客户作出的价格承诺。把这些事实列成一张清单本质上就是在为你的 Agent 画一条“经营的底线”。这一步看起来简单但很关键。因为长期连贯性问题往往不是因为模型不够聪明而是因为它们根本不知道哪些信息属于“不可触碰的约束”。如果你不把这些约束显式写下来就没法在后续测试中判断 Agent 有没有违规。5.2 用断言而不是感受来抓连贯性在工程上验证连贯性不应该靠“读 Agent 的输出凭感受判断”而应该靠断言。也就是说把“不能破坏的事实”翻译成可执行的检查规则Agent 的每次输出都要经过这些规则检查。一个简单的示意结构是这样的# 示意结构一致性断言检查器需要按业务字段改写 def check_actions(action, history, state): violations [] # 检查1本次动作是否与未过期的历史承诺冲突 for commit in history.active_commitments: if action.conflicts(commit): violations.append(commit) # 检查2本次动作引用的状态是否与外部客观状态一致 if action.references(inventory) and action.inventory_value ! state.inventory: violations.append(state_mismatch) # 检查3策略变更是否包含明确触发条件 if action.is_policy_change and not action.has_trigger_reason: violations.append(unexplained_policy_change) return violations这类断言不一定需要很复杂。关键是把它变成一条自动化的检查链路Agent 每执行一步就把它的输入、输出、当时的历史承诺、当前的客观状态记录到日志里然后跑一组断言输出一份“违规点报告”。坚持跑下来你很快会发现很多在单轮演示中看不见的问题会在第几步、哪个环节第一次崩坏全部变得清晰。5.3 一套最小可复用的三步验证法如果你现在还没有系统化的评测环境可以从一个最小验证流程开始。这个流程足够轻能让你在两三天内对你的 Agent 长期一致性有一个基本判断。第一步跑一条长 trace。选一个需要多轮决策的业务流程比如“从一个老客户咨询到报价、下单、库存扣减、后续回访”的完整链路。让它跨多个轮次、多个状态完成。第二步回放关键决策点。把 Agent 在每个决策点的输入和输出打印出来重点检查它有没有引用已经过期的状态、有没有推翻之前的结论。第三步用断言清单批量扫违规点。把 5.2 里的断言脚本跑一遍生成一张违规点清单然后按“记忆层、决策层、目标层”分类看看问题集中在哪一层。这套方法的价值不是一次性告诉你 Agent 有多好而是帮你建立一个可复用的回归检查流程。以后每换一次模型、每改一次提示词、每接一个新工具都能用同一套断言重新验证避免“改好了一个 bug破坏了另一个承诺”。5.4 排查链路当 Agent 行为开始“漂移”当 Agent 在长流程里出现前后矛盾、遗忘承诺、策略漂移、状态错乱时不要急着去调提示词。更稳妥的排查顺序是从输入到环境再到模型一层一层定位。先看输入层历史上下文有没有被截断系统提示里有没有放进过期信息。再看记忆层长期记忆模块有没有被错误覆盖检索时是不是召回了一段语义相似但内容错误的历史记录。然后看状态层外部状态有没有及时更新Agent 拿到的是不是最新版数据。接着看规划层Agent 是否在每一轮重新生成完整计划时把上一轮的计划和承诺一并丢弃。再看工具层调用外部系统时写入是否成功、失败后有没有重试、权限是否足够。最后才回到模型层温度设置是否太高导致同样的输入每次输出都不一样系统提示是否明确要求了“当你需要修改先前决策时必须说明原因”。这个排查顺序的核心逻辑是先排除外部信息错误再看 Agent 内部机制最后才怀疑模型本身的表达能力。大多数长期连贯性问题其实出在状态没有更新、历史上下文被截断、记忆模块召回错误而不是模型听不懂指令。6. 长期经营评测给 LLM 智能体工程化留下了什么6.1 时间成为一等公民长期经营评测提出的最大工程启示是把“时间”从边缘变量变成了核心变量。过去设计 Agent 时我们关心的是“输入一段话得到一段合理输出”现在要关心的则是“这个 Agent 站在时间线的哪一点它需要记住哪些历史它此刻做出的决策会怎样限制未来的选择”。这也解释了为什么现在很多智能体框架、数据库、状态机设计越来越强调记忆模块、会话级历史、外部状态存储和审计日志。本质上这些设计不是锦上添花而是在为“时间连贯性”兜底。如果没有一个外部系统专门记录“发生过什么”和“当前什么状态”单靠 LLM 自己记住一切长期经营场景很快就会崩盘。6.2 评测推动记忆、状态和审计设计MerchantBench 这类评测的另一个价值是间接给 Agent 工程化提了一组需求你要有可查询的状态层要有可回放的历史日志要有可断言的一致性规则。这些需求在真实生产中一样重要。试想一下一个经营类 Agent 在真实业务里出了错你首先要做的不是训模型而是查它当时看到了什么状态、参考了什么历史、为什么做这个决策。如果没有状态快照和决策日志排查会变得非常困难。评测驱动的 Agent 设计天然会把这些问题暴露出来逼着开发者在早期就做好审计能力。现在常见的做法比如搭建 RAG 检索库、给 Agent 接入工具调用、通过 MCP 连接外部业务系统、用专门的记忆模块管理长期偏好本质都在解决同一个问题让 Agent 在长流程中不要“失忆”不要“自相矛盾”。评测基准只是把这些工程要求从“感觉应该这样做”变成了“必须这样做”。6.3 边界别把基准当成经营能力的全部也要说清楚长期经营连贯性评测不是万能钥匙。它适合回答“智能体能不能在规则清晰的模拟世界里保持一致”不适合回答“智能体能不能处理好真实世界的复杂人情和不确定性”。真实经营里的信任、沟通、博弈、意外风险很多是模拟环境难以刻画的。所以我的建议是把这类基准当成一个“入场资格测试”而不是“经营能力终测”。用它来筛掉那些单轮看起来很强、但一放长线就自相矛盾的 Agent再用真实场景里的小规模试点来验证剩下的 Agent 是否真的能承担业务。两手都要有没有连续性评测你很难发现长期隐患只信评测你又容易忽略真实世界的复杂约束。回到最初那个守不住店的智能体。MerchantBench 这类工作真正提醒我们的不是哪家模型排名更高而是LLM 智能体要想真正进入经营类场景就要把“长期连贯”当成和“单步正确率”同等重要的工程指标。下一步你不妨先不做复杂评测而是把你业务里那些“不能破坏的事实”写下来作为断言检查跑一遍自己的 trace。哪怕只有十几个关键节点你也会很快看清楚Agent 是在替你做决策还是在陪你说胡话。
LLM智能体长期经营连贯性评测：MerchantBench的启示
一家小卖部的老板是 LLM 智能体。第一天它很聪明记住了顾客口味给滞销品定了促销价第二天它却像换了个人把昨天的承诺忘得一干二净。单看每轮对话它都答得有理有据放进连续经营场景却撑不过几天。MerchantBench 这类评测要抓的正是这个越来越常见的尴尬LLM 智能体单轮很强长期经营却缺乏连贯性。我对这个方向有一个明确判断LLM 智能体从“能完成任务”走向“能长期经营业务”中间最大的分水岭不是单次任务成功率而是长期连贯性。单步能力强只能说明模型在某一个瞬间能做出合理反应长期经营场景里它还要能在几十轮甚至几百轮的决策中始终记得自己说过什么、做过什么、承诺过什么并且不让后面的行动推翻前面的判断。MerchantBench 这个名字背后的价值不只是一个新榜单而是把“连贯性”这种以前只能靠人工体感判断的缺陷变成一套可观察、可度量、可复盘的评测命题。1. 一个能答对题却守不住店的智能体问题出在哪1.1 单轮很强连续经营却容易露馅最近测试了不少 LLM 智能体应用一个很典型的现象是单轮任务的成功率看起来不差一问一答、调用工具、生成结果都像模像样。但一旦把任务拉长让它连续处理一个店铺的经营事务问题就接二连三地冒出来。比如智能体在前一天给某位老顾客承诺了会员折扣第二天顾客回购时它完全不记得这回事再比如它上午刚制定了一个“清库存优先”的促销策略下午却因为一条临时消息转头给库存充足的高利润商品做了更大力度的折扣。从单个决策看每一个选择都说得通但放在一起看这个智能体就像在帮倒忙。它不是在经营而是在不断制造前后矛盾。这让我想到一个场景你招了一个很聪明的新员工反应快、表达好但没有任何长期记忆也不遵守自己前一天定下的规则。你愿意让他独立看店吗显然不愿意。因为真实经营不是一道道独立的判断题而是一条连续的时间线。今天的行为会变成明天的约束昨天的承诺会变成今天的责任。如果智能体在时间线上不能保持连贯那它的单点能力再强也很难真正承担经营任务。1.2 长期连贯性是一条独立的评价维度很多人会把“长期连贯性”理解成“准确率更高一点”。其实不是。准确率衡量的是“单次回答是否正确”连贯性衡量的是“一系列决策在时间轴上是否彼此一致”。这两件事可以完全分离。一个 LLM 可以在每一次任务里都答得正确却在整体上表现得像一个失忆的病人。比如它每次都能算对库存但每次算完都不更新状态导致第二次的结论建立在一个已经失效的基础上它每次都能生成合理的定价但每次生成的定价逻辑都不一样导致顾客面对一个毫无规律的商家。所以评价一个 LLM 智能体能不能长期经营不能只看“这个动作对不对”还要看“这个动作和之前所有动作加起来构成了一个什么样的故事”。MerchantBench 这类基准的切入点正是把这条时间线上的连贯性单独拎出来作为核心评测对象。这个视角本身比具体榜单排名更值得关注。2. 为什么过去的主流评测很难发现这类问题2.1 短任务评测的隐含假设过去常见的 LLM 评测大多建立在“短任务”假设上给一个指令模型输出答案裁判打分。这类评测适合衡量知识问答、代码生成、单次工具调用等场景因为任务之间互相独立上一题的答案不会影响下一题的判断。但这种评测设计隐含了一个前提每一轮任务都是“无状态”的。模型不需要记得上一轮发生过什么也不需要维护一个跨步骤的业务状态。于是评测结果只能回答“这个模型能不能做对这件事”回答不了“这个模型能不能连续做对一百件事”。长期经营场景恰恰是反过来的。在这里状态才是主角。库存、现金流、顾客等级、供应商账期、历史促销记录这些信息不会被重置而是不断累积。每一次决策都在改变后续决策的输入。如果一个智能体连“当前库存还剩多少”都追踪不准那它在后续所有关于补货、定价、承诺交付时间的决策上都会跟着出错。2.2 经营场景里“状态”才是主角用更直白的话说经营类任务的核心不是一个文本生成问题而是一个“状态维护”问题。你开一家店本质上是在维护一组事实仓库里有什么、货架上缺什么、钱够不够周转、哪些顾客答应过什么折扣、哪些供应商承诺什么时候到货。LLM 智能体要做的不是“想出一些漂亮的经营建议”而是让这些事实始终保持正确并基于正确的事实做下一轮决策。这正好是传统评测最容易遗漏的部分。传统评测里输入和输出都是一段文本模型不需要理解“当前世界处在什么状态”。而 MerchantBench 这类评测如果要成立就必须建立一个可以持续切换、持续更新的模拟环境。环境里有一个“客观事实”智能体自己的“认知”以及两者之间的偏差。评测的很大一部分工作就是在测量这个偏差什么时候会被拉大以及拉大之后智能体会不会及时发现并修正。2.3 连贯性问题的三层表现记忆、决策、目标从实际观察看长期经营中的连贯性问题通常会体现在三个层面这三个层面也基本构成了一致性评测的分层框架。第一层是记忆层。智能体忘了自己说过的话、做过的事。典型表现是顾客已经收到过退款它又处理了一次退款供应商已经答应延期它还在按原计划催货。第二层是决策层。智能体面对相同情境时给出彼此冲突的策略。比如促销规则朝令夕改优惠力度没有稳定依据导致整体行为像是随机游走。第三层是目标层。智能体在做短期决策时丢掉了长期目标。比如为了冲一单交易量把利润压到不可持续甚至破坏了已在执行的清库存计划。这三层问题单靠“单轮任务正确率”是测不出来的因为每一轮单独看都可能是合理的。只有把时间拉长把状态变量加进来才能看到记忆的丢失、决策的漂移和目标的偏移。MerchantBench 这类基准要做的就是把这些时间相关的问题变成显式测试项。3. MerchantBench 的评测重心把“长期经营连贯性”拆成可观察的维度3.1 核心命题从“这一步对不对”转向“一路走来合不合理”从项目标题能看出MerchantBench 把场景定在了“商户经营”上核心评测对象是 LLM 智能体在长期经营中的连贯性。这种评测的核心命题不再问“这一步做得好不好”而是问“把整个经营过程连起来看它讲不讲逻辑”。单个动作合理不代表整条经营路径合理。这就像看一部连续剧每一集单独拍都不差但连起来看人物感情线前后矛盾时间线对不上观众就会弃剧。LLM 智能体的长期经营也一样裁判不应该只看“每一集”的质量还要看“整季”的叙事是否成立。因此评测过程大概率会围绕一个多智能体或单人经营模拟场景展开让智能体扮演经营者连续处理多轮业务事件比如接待客户、制定价格、管理库存、处理供应商问题、应对市场波动。评测者不再只给它一个标准答案而是看它在整个过程中是否始终维护着一套自洽的经营行为。3.2 维度设计目标保持、状态追踪、决策一致、记忆连贯、抗扰动恢复如果要设计一份“长期经营连贯性”的评测观测表至少应该覆盖以下几个维度。这些维度不是官方指标更像是从工程视角出发的通用拆解。维度要回答的问题典型翻车表现目标保持是否始终服务于设定的经营目标为了短期成交破坏长期利润或清库存计划状态追踪是否准确维护库存、资金、时间等状态把已售出的商品继续当库存来卖决策一致对相同情境是否给出不冲突的决策促销价定了半天又无理由改回原价记忆连贯是否复用之前的承诺、偏好和结论忘记老顾客的折扣忘记自己的补货安排长程规划计划与实际执行是否对得上前面承诺的交付时间后面根本无法兑现抗扰动恢复出现意外后能否不破坏已有承诺供应商断货后随意改价引发连锁矛盾其中抗扰动恢复可能是最容易被低估的一项。现实经营里意外是常态供应商延迟、顾客投诉、价格波动、竞争对手突然促销。智能体面对的从来不是一条顺滑的业务流而是一个不断被打断、需要重新规划的世界。真正连贯的经营者不是永远不变而是知道哪些东西必须保持不变哪些可以调整以及调整之后如何向相关方交代。3.3 评测环境的隐藏设计状态真值、时间推进、事件注入要支撑以上维度的评测光有题目和答案是不够的评测环境本身的设计会决定结果的有效性。这三点在 MerchantBench 这类基准里通常很关键。第一环境要有“状态真值”。也就是说系统内部要维护一份客观、权威的经营状态包括库存、资金、顾客记录、历史承诺。智能体的输出必须落在真值之上而不是自己构造一个虚构世界。第二环境要能推进时间。经营是跨天的、跨周的不是一次性问答。如果没有时间推进就无法测试“记住昨天”和“规划明天”。第三环境要能注入事件。随机波动、突发消息、顾客异常行为这类事件是经营连贯性的压力测试工具。没有事件注入智能体只要按固定模板回答就很容易表现得很“连贯”但那种连贯只是死板不是真正的稳定。4. 这类基准真正难在设计状态、度量和成本三关4.1 第一关状态空间怎么建模如果只看表面你会觉得评测一个 LLM 智能体“连不连贯”很简单给它一个模拟店铺跑几天看它表现如何。但真正动手设计之后第一个麻烦就来了状态空间怎么建模。经营状态不是一两个字段而是一组相互关联的变量库存数量、资金余额、订单状态、顾客偏好、供应商条款、历史价格、未完成承诺。更麻烦的是这些变量之间还有约束关系库存减少是因为卖出了订单资金增加是因为收到了回款顾客折扣会影响收入供应商延期会影响库存。如果环境不能精确模拟这些联动关系那评测就失去了意义。因此评测环境通常需要把经营过程抽象成一组“状态转移规则”。智能体的每个动作都必须能被解释成对状态的一次修改。这个抽象过程非常考验设计者对经营业务的理解规则太简单评测失真规则太复杂环境维护成本极高而且很难定位失败原因。4.2 第二关连贯性怎么打分另一个难点是打分。传统评测的分数很好算答对了给一分答错了不给分。但“连贯性”是一个跨步骤的、相对性的概念很难用“一步一分”来量化。从常见评测设计思路看连贯性度量可以朝几个方向拆。一个是“状态偏差率”也就是智能体认知中的状态与客观真值不一致的次数占总交互轮次的比例。一个是“承诺违反率”也就是智能体之前做出的承诺在后续行动中被打破的比例。一个是“策略漂移度”也就是在面对相同或高度类似情境时决策发生无依据变化的幅度。还有一个是“经营结果指标”比如累计利润、顾客满意度、库存周转率这些指标本身就能间接反映整体的经营质量。要注意的是这些度量方法各有偏重。状态偏差率适合抓低层错误承诺违反率适合抓信用问题策略漂移度适合抓决策稳定性。单一指标很难覆盖全局。更稳妥的方式是多个指标并行观察最后再看经营结果这个“结果变量”是否被拖累。4.3 第三关长程评测的代价和方差长程评测还有一个绕不开的现实问题成本。一次评测要跑很多轮交互每一轮都要调用 LLM都会消耗 token。评测的规模稍大一些成本就会快速上升。更麻烦的是长程任务本身带有随机性。经营模拟里通常会有随机事件市场波动、顾客随机到访、供应商随机延迟。这些随机因素意味着两次跑同一套评测智能体面临的环境并不完全一样。如果它第一轮生意好可能是因为运气好而不是因为决策连贯。要区分“运气”和“能力”就必须做多轮次、多样本重复实验。但重复实验又意味着成本成倍上升。这是一个需要平衡的问题。设计评测时通常的做法是先控制随机事件的频率和幅度让环境在“有波动但可复现”之间找到一个中间点同时对不同随机种子跑多次实验用平均结果作为参考而不是只看一次运行。4.4 一个常见误判评测分数高不等于经营能力强任何评测都会有边界MerchantBench 这类基准也不例外。一个智能体在长期经营连贯性评测里拿到高分只能说明它在当前这套模拟环境里能保持目标、记忆、决策的一致性。这并不能直接等同于它能经营好一家真实店铺。原因很简单真实经营的变量远多于模拟环境。真实世界里有真实的合同、真实的人际信任、真实的物理交付、真实的法律责任。这些都不是一个小型模拟器能完整建模的。更微妙的是过度追求“连贯”也可能带来反效果。一个永远不改变策略的智能体会显得非常一致但它实质上变成了僵化。真正的经营连贯性应该是在“保持核心目标稳定”和“根据新信息调整执行方式”之间取得平衡。所以我对这类评测的态度是它是很好的必要不充分条件。如果智能体在模拟环境里都连不连贯那放到真实场景大概率更难控制但如果它在模拟环境里连贯只能说具备了进入真实经营场景的必要前提离真正独当一面还有距离。5. 从评测到落地自家 Agent 怎么验证长期一致性5.1 先定义“不能破坏的事实”对大多数开发者和技术团队来说不一定有机会复现 MerchantBench 的完整环境但可以借鉴它的思路验证自己正在开发的 Agent 是否具备长期一致性。最直接的做法是从业务中抽取一组“不能破坏的事实”。这些事实是 Agent 在做决策时绝对不能搞错的约束。比如某个订单的支付状态、某个用户约定的交付时间、某一商品的当前库存、某条促销规则的生效区间、已经向客户作出的价格承诺。把这些事实列成一张清单本质上就是在为你的 Agent 画一条“经营的底线”。这一步看起来简单但很关键。因为长期连贯性问题往往不是因为模型不够聪明而是因为它们根本不知道哪些信息属于“不可触碰的约束”。如果你不把这些约束显式写下来就没法在后续测试中判断 Agent 有没有违规。5.2 用断言而不是感受来抓连贯性在工程上验证连贯性不应该靠“读 Agent 的输出凭感受判断”而应该靠断言。也就是说把“不能破坏的事实”翻译成可执行的检查规则Agent 的每次输出都要经过这些规则检查。一个简单的示意结构是这样的# 示意结构一致性断言检查器需要按业务字段改写 def check_actions(action, history, state): violations [] # 检查1本次动作是否与未过期的历史承诺冲突 for commit in history.active_commitments: if action.conflicts(commit): violations.append(commit) # 检查2本次动作引用的状态是否与外部客观状态一致 if action.references(inventory) and action.inventory_value ! state.inventory: violations.append(state_mismatch) # 检查3策略变更是否包含明确触发条件 if action.is_policy_change and not action.has_trigger_reason: violations.append(unexplained_policy_change) return violations这类断言不一定需要很复杂。关键是把它变成一条自动化的检查链路Agent 每执行一步就把它的输入、输出、当时的历史承诺、当前的客观状态记录到日志里然后跑一组断言输出一份“违规点报告”。坚持跑下来你很快会发现很多在单轮演示中看不见的问题会在第几步、哪个环节第一次崩坏全部变得清晰。5.3 一套最小可复用的三步验证法如果你现在还没有系统化的评测环境可以从一个最小验证流程开始。这个流程足够轻能让你在两三天内对你的 Agent 长期一致性有一个基本判断。第一步跑一条长 trace。选一个需要多轮决策的业务流程比如“从一个老客户咨询到报价、下单、库存扣减、后续回访”的完整链路。让它跨多个轮次、多个状态完成。第二步回放关键决策点。把 Agent 在每个决策点的输入和输出打印出来重点检查它有没有引用已经过期的状态、有没有推翻之前的结论。第三步用断言清单批量扫违规点。把 5.2 里的断言脚本跑一遍生成一张违规点清单然后按“记忆层、决策层、目标层”分类看看问题集中在哪一层。这套方法的价值不是一次性告诉你 Agent 有多好而是帮你建立一个可复用的回归检查流程。以后每换一次模型、每改一次提示词、每接一个新工具都能用同一套断言重新验证避免“改好了一个 bug破坏了另一个承诺”。5.4 排查链路当 Agent 行为开始“漂移”当 Agent 在长流程里出现前后矛盾、遗忘承诺、策略漂移、状态错乱时不要急着去调提示词。更稳妥的排查顺序是从输入到环境再到模型一层一层定位。先看输入层历史上下文有没有被截断系统提示里有没有放进过期信息。再看记忆层长期记忆模块有没有被错误覆盖检索时是不是召回了一段语义相似但内容错误的历史记录。然后看状态层外部状态有没有及时更新Agent 拿到的是不是最新版数据。接着看规划层Agent 是否在每一轮重新生成完整计划时把上一轮的计划和承诺一并丢弃。再看工具层调用外部系统时写入是否成功、失败后有没有重试、权限是否足够。最后才回到模型层温度设置是否太高导致同样的输入每次输出都不一样系统提示是否明确要求了“当你需要修改先前决策时必须说明原因”。这个排查顺序的核心逻辑是先排除外部信息错误再看 Agent 内部机制最后才怀疑模型本身的表达能力。大多数长期连贯性问题其实出在状态没有更新、历史上下文被截断、记忆模块召回错误而不是模型听不懂指令。6. 长期经营评测给 LLM 智能体工程化留下了什么6.1 时间成为一等公民长期经营评测提出的最大工程启示是把“时间”从边缘变量变成了核心变量。过去设计 Agent 时我们关心的是“输入一段话得到一段合理输出”现在要关心的则是“这个 Agent 站在时间线的哪一点它需要记住哪些历史它此刻做出的决策会怎样限制未来的选择”。这也解释了为什么现在很多智能体框架、数据库、状态机设计越来越强调记忆模块、会话级历史、外部状态存储和审计日志。本质上这些设计不是锦上添花而是在为“时间连贯性”兜底。如果没有一个外部系统专门记录“发生过什么”和“当前什么状态”单靠 LLM 自己记住一切长期经营场景很快就会崩盘。6.2 评测推动记忆、状态和审计设计MerchantBench 这类评测的另一个价值是间接给 Agent 工程化提了一组需求你要有可查询的状态层要有可回放的历史日志要有可断言的一致性规则。这些需求在真实生产中一样重要。试想一下一个经营类 Agent 在真实业务里出了错你首先要做的不是训模型而是查它当时看到了什么状态、参考了什么历史、为什么做这个决策。如果没有状态快照和决策日志排查会变得非常困难。评测驱动的 Agent 设计天然会把这些问题暴露出来逼着开发者在早期就做好审计能力。现在常见的做法比如搭建 RAG 检索库、给 Agent 接入工具调用、通过 MCP 连接外部业务系统、用专门的记忆模块管理长期偏好本质都在解决同一个问题让 Agent 在长流程中不要“失忆”不要“自相矛盾”。评测基准只是把这些工程要求从“感觉应该这样做”变成了“必须这样做”。6.3 边界别把基准当成经营能力的全部也要说清楚长期经营连贯性评测不是万能钥匙。它适合回答“智能体能不能在规则清晰的模拟世界里保持一致”不适合回答“智能体能不能处理好真实世界的复杂人情和不确定性”。真实经营里的信任、沟通、博弈、意外风险很多是模拟环境难以刻画的。所以我的建议是把这类基准当成一个“入场资格测试”而不是“经营能力终测”。用它来筛掉那些单轮看起来很强、但一放长线就自相矛盾的 Agent再用真实场景里的小规模试点来验证剩下的 Agent 是否真的能承担业务。两手都要有没有连续性评测你很难发现长期隐患只信评测你又容易忽略真实世界的复杂约束。回到最初那个守不住店的智能体。MerchantBench 这类工作真正提醒我们的不是哪家模型排名更高而是LLM 智能体要想真正进入经营类场景就要把“长期连贯”当成和“单步正确率”同等重要的工程指标。下一步你不妨先不做复杂评测而是把你业务里那些“不能破坏的事实”写下来作为断言检查跑一遍自己的 trace。哪怕只有十几个关键节点你也会很快看清楚Agent 是在替你做决策还是在陪你说胡话。