Hugging Face Daily Papers 在 8 月 5 日把 MerchantBench 放在显眼位置，这篇论文值得所有做业务 Agent 的团队细读。它的题目是 “Benchmarking LLM Agents for Long-Term Coherence in E-Commerce Operations”，关注的不是模型能不能完成一次工具调用，而是能不能在一个电商卖家环境里连续经营 365 天。
论文摘要给出的设定很具体：MerchantBench 是一个订单级仿真环境，基于 98,843 条真实电商商品记录，提供 26 个交互工具，让 Agent 面对采购、商品上架、价格控制、现金流管理和混合延迟反馈。作者评估了八个 LLM 和两个 Agent 框架，共 48 次运行，每次覆盖 365 个模拟日。这个设定比很多“单题完成率”基准更接近真实业务，因为真实业务的失败往往不是一次答错，而是前面十次看似合理的决策累积成后面的大坑。
核心问题：长期一致性
论文使用 Long-Term Coherence 描述这类能力。可以把它理解成：Agent 在长时间、多轮状态变化和延迟反馈中，仍然保持目标一致、证据一致和策略一致。
电商运营是一个很好的测试场。比如今天降价会影响销量，但利润反馈可能几天后才显现；今天采购太多会占用现金，库存压力可能一周后才爆发；今天为了清库存大幅折扣，可能伤害后续价格锚点。短期任务只问“这一步是否正确”，长期任务会问“这一步是否让未来更难收拾”。
为什么现有 Agent 基准不够
许多 Agent 评测仍然偏向 bounded task：给定目标、给定工具、执行几步、看是否成功。这类评测很有价值，但它容易高估 Agent 的业务可用性。因为真实业务有三个特点：
| 特点 | 单步基准容易忽略什么 |
|---|---|
| 状态持续存在 | 前一次行动会改变后续选择空间 |
| 反馈延迟到达 | 成功或失败不能立刻归因 |
| 目标相互牵制 | 收入、利润、库存、现金流不能只优化一个 |
MerchantBench 的设计刚好抓住这些矛盾。一个 Agent 可以在某一天做出看似聪明的价格调整，却在长期里造成库存周转变差；也可以根据短期销量过度采购，最终现金流紧张。长期一致性就是在这些冲突中保持可解释策略。
论文的工程启发
第一，业务 Agent 需要模拟器。没有模拟器，就只能在生产里试错。生产试错不仅成本高，还很难比较不同模型和提示策略。模拟器不一定要完美复刻真实世界，但必须覆盖关键约束：库存、现金、订单、退货、供应延迟和价格弹性。
第二，评测指标要从单次成功率转向累计效用。电商任务不能只看当天利润，还要看库存健康度、现金安全垫、缺货率、折扣依赖、退货损失和策略波动。一个激进 Agent 可能短期利润漂亮，但长期风险很高。
第三，Agent 记忆不能只是聊天历史。365 天经营会产生大量事件，全部塞进上下文不可行。系统需要结构化状态：商品级指标、订单生命周期、采购承诺、价格变更历史、异常事件和策略假设。上下文窗口负责当前决策，外部状态负责长期事实。
一个简化版状态设计
如果你要在公司内部复刻 MerchantBench 的思想，可以先定义这样的状态表：
products:
product_id
category
current_price
current_stock
avg_margin
last_price_change_day
orders:
order_id
product_id
day
quantity
revenue
fulfillment_status
supplier_events:
event_id
product_id
day
lead_time
wholesale_price
reliability_score
agent_decisions:
day
action_type
target
rationale
expected_effect
observed_effect关键是最后一张表。长期一致性不是只保存事实，还要保存 Agent 当时为什么这么做。否则一个月后销量变化时，系统无法判断这是策略奏效、外部事件影响，还是随机波动。
延迟反馈如何击穿 Agent
MerchantBench 最有意思的地方在于 delayed downstream outcomes。人类运营也会被延迟反馈误导，Agent 更明显。模型通常擅长根据眼前证据做局部推理，却不擅长维护“这件事的后果可能还没出现”的开放假设。
例如 Agent 在第 10 天降价，第 11 天销量上升，它可能立刻把降价判断为成功。但第 20 天发现利润下降、库存虽然减少但补货成本上升，这时需要重新归因。一个成熟系统应该把决策和观察分开：
decision: lower price by 8%
expected window: 7 to 14 days
primary metric: sell-through rate
guardrail metric: gross margin
review day: day 24这比“看到结果就总结经验”可靠得多。Agent 的记忆如果没有评估窗口，就会把短期噪声写成长期经验。
对产品团队的现实建议
如果你正在做销售、采购、客服排班、广告投放或财务运营 Agent，不要只用单回合案例评估模型。至少准备三类测试：
| 测试 | 目的 |
|---|---|
| 短任务回归 | 检查基本工具调用和业务规则 |
| 多日模拟 | 检查状态追踪和延迟归因 |
| 压力场景 | 检查现金、库存、权限等硬约束 |
另外，Agent 的动作范围应该按成熟度逐步放开。第一阶段只生成建议，第二阶段允许低风险动作自动执行，第三阶段才考虑高风险动作审批后执行。MerchantBench 这类基准越发展，越会让团队看到一个事实：业务 Agent 不是一个更会聊天的 BI 面板，而是一个需要策略、状态、审计和回放的控制系统。
局限与价值
任何仿真基准都有局限。电商环境再真实，也无法覆盖所有市场冲击、竞争行为和供应链异常。模拟器里的工具和奖励函数也会影响 Agent 行为。但 MerchantBench 的价值不在于给出最终答案，而在于把 Agent 评测的时间尺度拉长。
过去我们问 Agent：“你能完成这个任务吗？”现在需要问：“你连续做 365 次决策后，系统是否仍然健康？”这两个问题之间，隔着生产落地最重要的差距。
参考来源：Hugging Face Daily Papers 8 月 5 日条目 MerchantBench，arXiv 论文 MerchantBench: Benchmarking LLM Agents for Long-Term Coherence in E-Commerce Operations。