MerchantBench 这个名字直接指向一个经常被忽略的问题LLM 智能体不是能答对几个问题就够了而是要能在长时间、多步骤、多轮交互的经营场景里始终保持逻辑一致、决策连贯、记忆不混乱。过去很多智能体评测只关注单轮问答的正确率或者单个任务能不能跑通但真实业务里一个智能体要连续处理订单、库存、客户、财务、售后每一步都会影响后面的状态。MerchantBench 这类评测的价值就是把“长期经营连贯性”这件事从感觉变成可量化指标。这篇文章适合正在做智能体开发、接 Agent 框架、或者准备上线销售/运营类智能体的团队阅读。最值得关注的不是它有没有给一个最终分数而是它逼着开发者去检查智能体在长链条任务里到底是真理解业务还是在用短期记忆和局部规则硬撑。长期经营连贯性听起来抽象拆开其实很具体。先说评测思路再说怎么搭建验证流程最后聊一聊实际跑评测时最容易出问题的几个环节。下面按我自己的理解顺序展开。1. 为什么要盯住长期经营连贯性单点能力强不等于业务可落地1.1 单轮问答评测的天然短板大多数 LLM 评测集比如常见的选择题、推理题、代码生成题本质上都是单点测试。给一个问题模型输出一个答案跟标准答案比对。这种模式对衡量基础能力有效但对“智能体能不能在真实业务里连续工作”几乎无能为力。真实业务从来不是一问一答。以销售场景为例一个客户可能先问价格再问库存接着要求改地址然后申请退款最后还要开发票。这四个步骤之间不是孤立的存货数量会变订单状态会变客户上下文也会累积。单轮评测很难暴露的问题是智能体会不会忘记之前已经确认过折扣会不会在改地址之后又把订单金额算错会不会把退款后库存变化漏掉MerchantBench 之所以被讨论就是因为它把“经营连贯性”当作第一性指标。这类评测会刻意把任务设计成多轮、有状态、环环相扣的长序列让智能体在一个虚拟场景里持续经营一段时间然后看它的整体表现而不是某一题的对错。1.2 长期经营连贯性到底难在哪里难的地方可以分成三类。第一是记忆管理。LLM 上下文窗口再大也有限度智能体要区分短期记忆和长期记忆要决定什么时候该记住客户偏好什么时候该丢弃临时信息。实际评测里经常出现一种情况前五轮表现都很好第六轮突然把客户名字搞混原因就是前面的信息没有结构化存储而是靠上下文堆叠硬记。第二是状态一致性。经营场景里有大量状态库存数量、订单状态、账户余额、会员等级。智能体每一步决策都会修改这些状态而且这些状态需要跨轮保持一致。如果评测环境没有给智能体提供状态读写接口智能体只能靠推理去猜连贯性就会急剧下降。第三是长序列的动作依赖。长期经营意味着后面的动作依赖前面的动作结果。智能体不仅要会做单步动作还要理解动作之间的先后依赖和冲突。比如先发货再开发票和先开发票再发货在很多业务流程里结果完全不同。如果评测任务里出现这种先后顺序智能体有没有能力感知并遵守就会成为连贯性的分水岭。所以数据安全方面商家不需要担心。因为 MerchantBench 的“经营”是虚拟经营评测环境和真实商户系统完全隔离且智能体只能拿到评测脚本提供的模拟数据。它测的是智能体的逻辑、决策和记忆而不是真实用户隐私也不涉及任何支付敏感信息。注意理解长期经营连贯性不能只看模型本身还要看智能体框架有没有提供记忆模块、状态管理和工具调用能力。否则即使换了更强的模型连贯性也可能上不去。2. MerchantBench 评测思路拆解从经营链路到一致性检查2.1 这类评测一般会覆盖哪些经营环节虽然原始材料里没有完整公开每一项细节但按照评测基准的常见设计MerchantBench 很可能围绕一个完整经营链条展开商品管理、库存补货、订单处理、客户咨询、售后、财务对账这类日常经营环节。评测任务会被编排成多步流程比如“上架商品后统计当日订单然后处理三笔退款再更新库存”这样的组合动作。在设计评测集时通常会有几种任务类型状态更新类让智能体根据新的信息修改已有记录。多步规划类让智能体在多个约束条件下制定下一步行动。冲突消解类让智能体发现两个动作之间存在矛盾并选择正确顺序。长期记忆类让智能体在若干轮之后引用早期信息完成当前任务。这些类型交叉使用才能真正测出“连贯性”而不是单点准确率。2.2 连贯性为什么比单步正确率更关键一个很典型的现象智能体每一步单独看都正确合在一起却错误百出。比如虚拟店铺的评测逻辑。假设智能体第一轮收到订单 A正确地把库存从 10 改成 9。第二轮收到订单 B这时候库存应该是 9智能体如果重新读了一遍数据库发现还是 10然后按 10 去计算就会超卖。如果评测只看第二轮库存更新是否正确可能看到智能体“正确”地把 9 改成 8但实际上它用了错误的初始状态。前后对照发现问题这就是连贯性指标要抓的错误。再比如退款流程。智能体第一轮确认退款 100 元第二轮处理退款时却写成 1000 元。单看第二轮“生成退款单”这个动作模型如果输入上下文里有正确的金额但漏读了就会犯错。如果评测把整个流程串联起来算完成度这种错误会非常明显。所以 MerchantBench 这类评测的重点不是“答对多少题”而是“多轮任务中的状态一致性、记忆准确率、动作依赖正确率”。从这个角度它比传统 LLM 评测更接近生产环境暴露问题的方式。3. 想跑类似评测需要先搭好基础设施3.1 环境准备本地服务、Agent 框架和评测框架不管你是想复现 MerchantBench还是想用类似思路自建评测集先确认三样东西。第一个是模型服务。可以用 OpenAI API也可以用开源模型的本地部署。不同模型能力差异很大如果想快速验证流程先用 API 版本如果想控制成本和隐私再考虑本地部署。关键是先保证模型调用稳定再往后走。第二个是 Agent 框架。热词里经常提到的 Dify、Coze、LangChain 等都可以用来搭智能体。MerchantBench 本身是评测集不限定框架。你需要选择或者搭建一个能管理记忆、能调用工具、能读写状态的环境这样评测才跑得动。如果只拿一个裸模型去跑多轮经营任务很可能每轮都要把全部历史塞进 prompt内存爆炸不说效果也很难看。第三个是评测框架。常规做法是写一个 Python 脚本循环读取任务文件把历史对话、环境状态和动作结果一起交给模型或智能体最后收集输出并计算指标。不需要太复杂的工具只要能记录每一轮的输入输出、状态变化、系统日志即可。一个最小化评测流程可以这样组织# 伪代码仅用于说明评测流程 tasks load_test_cases(merchant_tasks.json) env MockShopEnv() # 模拟经营环境 agent create_agent(modelgpt-4o, memoryinit_memory()) for task in tasks: env.reset() memory.clear() for step in task.steps: observation env.get_state() prompt build_prompt(observation, memory, step) action agent.run(prompt) result env.execute(action) memory.update(result) log(step, prompt, action, result) compute_metrics(task, log)这里的核心是 MockShopEnv它负责维护所有虚拟状态。没有这个环境评测就没法判断动作是否合法也无法追踪状态变化。3.2 运行条件与资源判断如果你用 API资源需求不高主要看请求频率和 token 消耗。多轮长任务 token 消耗会明显高于单轮因为需要携带历史上下文或记忆检索结果。建议先跑 10 个任务估算平均 token再做全量评测。如果你用本地开源模型显存和内存是关键。一个 7B 模型跑单轮推理可能只要 6GB 显存但跑多轮长上下文KV Cache 会占用额外显存可能直接翻倍。模型窗口越短需要塞进 prompt 的内容越少但同样会导致记忆容纳不下。实际操作时建议先用 10 个短任务试运行观察显存和内存峰值再决定要不要加长上下文或换更小的模型。磁盘空间要留足因为需要记录日志和状态快照。连续跑几百个任务日志文件很容易上 GB。建议给每个实验单独建目录按时间戳命名便于回查。4. 评测一个智能体是否“能长期经营”的核心指标4.1 指标设计完成率、连贯性、资源利用和稳定性MerchantBench 如果只是给一个分数很难落地。真正有价值的做法是从多个维度记录。如表所示指标计算方式含义单步执行成功率每步动作被环境接受且符合预期的比例智能体是否具备基本操作能力任务完成率完整经营序列按预期结束的比例智能体能否从头到尾跑通整个流程状态一致性得分对比每一步环境状态与预期状态的差异智能体有没有保持库存、金额等状态一致记忆召回率需要引用早期信息时能否正确引用的比例长期记忆系统是否真正可用多轮连贯性后一动作对前一动作依赖的正确率动作之间是否逻辑自洽资源消耗平均 token 数、调用次数、耗时能力之外还有成本因素其中状态一致性可能是最大亮点。评测时可以每执行一步就把当前真实状态和智能体自以为的状态做对比。如果智能体没有通过工具获取状态而是靠猜测这里会立刻暴露问题。4.2 如何判断评测结果是否可信一个评测结果不能只看分数要看有没有以下问题。第一是测试集泄露。如果任务集在网上被公开过模型训练数据里可能已经包含答案结果会虚高。使用官方评测时要注意评测集是否持续更新或者是否采用私有测试集。第二是随机性。LLM 有采样参数temperature 不同结果差异很大。跑评测时应该固定随机种子或者 temperature 设为 0同时每个任务多次重复看方差。通常至少要跑 3 次取中位数或者平均值。第三是环境实现 bug。MockShopEnv 本身写错可能导致智能体永远无法成功。比如库存扣减逻辑写反了智能体再强也没用。所以正式评测前要先做环境自测用人工编写答案或者固定脚本跑通预期流程确认环境没有低级错误。第四是评估者偏差。如果评测用另一个 LLM 来打分打分模型也可能有偏好。人工抽检一批结果查看打分是否公平这是不可省略的步骤。注意评测集里的任务数量太少分数波动会很大。哪怕只有 50 个任务也要先做误差分析不要急着下结论。5. 实际评测时最容易踩的坑5.1 上下文窗口和记忆丢失很多智能体框架默认把整段历史塞进 prompt这在小任务里没问题一旦经营任务超过 20 轮上下文会越来越长最终触发截断。截断的位置不同智能体可能丢失关键信息比如客户地址、订单编号、折扣信息。结果就是任务后半段错误率飙升。更隐蔽的情况是记忆检索错误。有些框架会把记忆向量化按相似度检索但经营场景里需要的不是语义相似而是“最近一次改过的订单状态”。语义检索可能把一条很久以前但表达相似的记录找出来而不是最新的。评测时如果发现智能体引用错误状态优先检查记忆模块的更新策略而不是模型能力。5.2 任务设计的主观偏差MerchantBench 如果覆盖经营任务设计者需要明确什么是“正确的经营行为”。这个判断有时候非常主观。比如库存不足时智能体是选择拒绝订单还是建议替代商品还是修改预计到货时间不同策略在不同业务里都可能是合理的但评测脚本必须预先定义“期望行为”。如果期望行为定义过窄评测结果就会低估智能体能力。更常见的是任务描述存在歧义。一句话里既包含用户意图又包含系统约束智能体可能会优先执行错误的一个。比如“客户想要尽快发货而系统规定必须全额付款后才能发货”智能体需要理解两件事之间的逻辑而不是简单听从“尽快发货”。这类冲突消解任务如果设计得不好评测结果往往两极分化。5.3 环境不稳定导致的假阳性和假阴性智能体评测特别依赖环境确定性。如果每次执行任务时模拟环境的随机因素过多比如价格浮动、库存补货时间、客户消息顺序那么连续跑两次可能会得到完全不同的结果干扰对智能体的判断。建议评测环境保持“可控随机”有随机性但是使用固定种子确保每次实验可复现。另外要记录每一步的输入输出尤其是工具调用的参数和返回值。不能只记录最终结果否则中间出错时无法定位。错误排查的顺序可以这样来先看报错信息是模型调用失败还是工具执行失败还是状态校验失败。再看输入内容这一步智能体收到的观察是否完整有没有被截断或缺失。再看环境状态上一步执行后的状态是否正确有没有被并发任务污染。再看记忆模块检索到的是不是最新状态有没有过期记录。最后看模型和参数temperature、上下文长度、提示词模板是否适合当前任务。6. 对开发者和评测者的实用建议6.1 先把单轮跑稳再测多轮最后进入长期任务我的习惯是三层测试。第一层是单轮功能测试。给智能体一个清晰、无歧义的经营动作比如“把商品 A 的价格改成 99 元”看它能不能正确修改状态。单轮都做不好多轮只会放大错误。第二层是短序列测试3 到 5 轮验证动作依赖和基础记忆。比如“先创建订单再更新库存最后查询订单”看状态是否连贯。第三层才是 MerchantBench 类型的长期经营测试20 轮以上包含状态回滚、延期处理、跨轮引用。三层全部通过再谈上线。6.2 日志规范是评测质量的根基评测过程中最容易忽略的是日志。很多团队跑完评测只保留一份 final_score.json中间过程全部丢弃。一旦发现分数异常无从查起。建议每轮记录prompt 的实际内容包含哪些记忆、状态、系统指令。模型原始输出。动作解析后的结构化数据。环境状态变化前后的差异。记忆写入和检索的记录。token 消耗、耗时、重试次数。日志格式用 JSON Lines每个任务单独一个文件包含任务 ID、步骤 ID、时间戳。这样后续可以回放任何一个步骤精确定位错误发生点。6.3 不要照搬评测分数要结合业务场景自建评测集MerchantBench 是一个很好的参考但每个团队的业务都不一样。卖数字商品的、做本地生活服务的、做企业采购的经营流程差异巨大。建议在参考公开评测集的基础上基于自己的业务日志构建一批私有任务。做法是抽取真实线上场景里出现过的长链路对话或操作流程脱敏后改写成评测任务。这种做法有两个好处一是任务包含真实业务约束不会出现“理论上合理但业务上不存在”的边角情况二是评测结果可以直接对应到生产问题。自建评测集时要注意不要引入敏感信息。脱敏必须彻底客户姓名、手机号、订单金额等字段都要替换成虚构数据。评测环境本身也应该是隔离的不能访问真实生产数据库。这一点对于任何希望长期做智能体评测的团队都适用。6.4 模型、框架和评测集要解耦最后一条建议比较反直觉分阶段排查时不要同时更换模型、框架和评测集。很多团队在评测时发现分数低立刻换模型、调 prompt、改框架结果根本不知道是哪个改动起了作用。正确做法是基线化。固定一组测试任务先跑通一套默认配置记录基线指标。然后每次只改变一个变量换模型、改记忆策略、调整工具调用方式、改检索逻辑。逐一对比才能找到影响连贯性的关键因素。这个流程我自己实战时深有体会。有次做智能体评测单独看每一步正确率超过 90但完整经营任务完成率只有 31。后来把日志一步步回放发现问题出在“订单状态更新”和“库存扣减”之间的依赖关系上。智能体在生成动作时先更新了订单状态但随后调用库存接口时用了旧订单号库存扣减失败。由于环境没有把失败信息明确反馈给模型模型以为已经成功后续所有统计都错了。这种问题只有完整评测、日志回放和状态对比才能发现。所以MerchantBench 这类评测最值得借鉴的不是某个精确分数而是它把“长期经营连贯性”从口号变成了一套可以检查、可以量化、可以回放的流程。如果你正在做智能体相关项目哪怕不上 MerchantBench也建议早一点建一个多轮状态一致性评测集。等到线上出问题再补成本会高很多。先跑通单条任务看日志再开批量慢慢把连贯性磨出来这个顺序不会错。