一句话结论
现有基准大多考"信息给全了能不能推对"，AdaExploreBench 考的是另一件事：环境的运作规则不告诉你，你得自己动手试出来；规则还会在你不知情的情况下改变，你得从变差的成绩里意识到旧经验已经作废。论文给出的判断是，当前模型的瓶颈不在推理，而在"主动取证"和"识别证据过期"这两步。
方法要点
基准的核心设计只有三条，但每条都直接针对一个具体的失败模式。
一、把环境动态实例化为隐藏规则。 每个任务背后有一条不公开的规则，Agent 看不到它，只能通过动作与环境交互、收集证据，再从证据反推规则。这测的是"会不会主动探索"，而不是"会不会读题"。
二、隐式规则漂移。 规则会在没有任何公告的情况下被替换。Agent 不会收到"规则已更新"的提示，唯一线索是自身表现下滑。这就要求它具备元认知能力：先从成绩变差推断出"我掌握的知识过期了"，再重新探索。这一条是整篇论文最锋利的地方，因为绝大多数 Agent 的默认行为是"按记忆里的成功路径继续执行"。
三、用校准准确率计分。 指标名为 calibrated accuracy（校准准确率），即不只看答对与否，也约束模型的置信度。摘要没有给出该指标的计算细节，引用具体分值前建议先核对全文定义。
为了把瓶颈定位到具体环节，作者还设了两组对照条件：一是直接提供充分证据，二是移除规则漂移。前者测"有证据时能不能用好"，后者测"没有漂移时能拿多少分"，两者与完整设置的差值，就是主动取证与漂移检测各自的代价。
下面是用伪代码还原的评测流程，重点看漂移发生的位置——环境不做任何提示：
for task in AdaExploreBench.tasks:
rule = task.hidden_rule # 规则对 agent 不可见
obs = agent.reset(task.public_obs) # 初始观测不含规则
while not task.done():
action = agent.act(obs) # 需要主动探索才能拿到证据
obs, reward = task.env.step(action, rule)
if task.has_drift and task.env.tick == task.drift_at:
rule = task.resample_rule() # 隐式漂移：无公告、无提示
# agent 只能从 reward 下滑自行推断"旧知识失效"
if agent.detects_stale(reward): # 这一步是多数模型的失败点
agent.reexplore()
score = calibrated_accuracy(agent, task) # 同时对正确率与置信度计分
关键数字
论文摘要只披露了两个数，且没有给出分模型的完整榜单。为避免二手转述失真，这里原样对齐：
| 数据集 / 设置 | 指标 | 对比对象 | 结果 |
|---|---|---|---|
| AdaExploreBench 完整设置（8 个领先 LLM） | 校准准确率 | 八个模型中表现最好的 GPT-6 Sol 与其他七个 | 61.9% |
| AdaExploreBench 对照设置（提供充分证据，或移除规则漂移） | 平均性能 | 与完整设置相比 | 提升接近 10% |
两个数放在一起读，含义比单独看更清楚：最强模型在完整设置下只有 61.9% 的校准准确率，说明任务远未饱和；而只要把证据直接喂给它、或者干脆不让规则漂移，平均性能就提升接近 10%。也就是说，掉分主要不是"想不明白"，而是"没去拿"和"没发现过期"。摘要中提到的评测规模为八个领先大模型，完整的分模型结果需要查全文。
局限与前提
- 信息目前停留在摘要级。 任务数量、规则的形式化表示、漂移的触发频率、校准准确率的具体公式，摘要都没有交代。想据此做工程决策，必须读全文。
- 隐藏规则是人工设定的。 基准把"环境动态"压缩成一条可判定的规则，这与真实系统里权限变更、接口废弃、数据分布漂移混杂在一起的情况相比，仍是简化模型。分数高低不能直接换算成线上表现。
- 隐式漂移的检测依赖反馈信号。 如果真实业务里性能下滑被埋在长周期指标中，或者根本没有可用的即时反馈，这类"从成绩变差推断知识过期"的机制就缺少触发条件。
- 作者自己承认的不足是方向性的：模型在信息充分的条件下往往能有效推理，真正的短板在于主动获取正确的证据，以及识别此前获取的证据何时失效。这条结论同时也是基准的立论前提。
- 评测对象是通用大模型。 信息源只说明测了八个领先 LLM，未披露是否对比过带长期记忆、规划模块的工程化 Agent 框架，因此不能直接推断"加了记忆就一定更好"。
能不能用
开源情况：截至目前未确认。 arXiv 页面只提供 PDF、HTML（experimental）与 TeX 源码，未给出代码或数据仓库链接。想动手，先确认作者是否已放出评测代码，别急着排期。
# 检查论文页面是否已挂出代码/数据仓库链接
curl -sL https://arxiv.org/abs/2610.25950 \
| grep -iE "github|code|dataset|repository" \
|| echo "no repo link found on abstract page"
复现条件： 这是一个多轮交互式基准，成本主要来自 rollout 次数而不是单次推理——每个任务都要让 Agent 反复试错，还要覆盖"漂移前/漂移后"两段，调用量随轮数线性上升。建议先用两三个模型跑一个小子集，确认评分脚本里校准准确率的实现与论文一致，再扩到全量。
值不值得用： 如果你在做需要长期在线、环境会变的 Agent（运维、客服策略、工具链会改版的场景），这个基准测的正是你线上最容易翻车的那一环，值得纳入评测集；如果只是单轮问答或静态任务，它的区分度对你的意义有限。另外，把"性能下滑 → 触发重新探索"当作一条显式策略写进 Agent 循环，是这篇论文成本最低的可落地启示。