训练环境是泳池评测集是考场这两个场地一旦共用同一个教练、同一套题库分数再高也很难说明真实水平。AgentMercury 这个项目最值得关注的地方不是又给 Agent 加了多少工具、多少 API而是它把“训练环境”和“评测集”这两件平时被混在一起的东西拆开了并且用实验说明脱钩本身就能显著提升泛化能力。这个判断很反直觉。传统做法里评测集本来就是从训练环境里抽样出来的大家更关心怎么把数据切得更均匀、怎么避免同源污染却很少去想评测集和训练环境绑得太死本身就是一个系统性问题。如果你正在做对话系统、RPA 工具、代码助手或者数据分析 Agent大概率遇到过同一种尴尬本地评测跑分很高换一个真实业务场景立刻失灵。这篇文章就围绕 AgentMercury 的设计思路讲清楚训练环境与评测集脱钩到底是什么意思、为什么能提升泛化、以及如何在自己的项目里落地一套可执行的脱钩评测流程。1. 这篇文章真正要解决的问题先问一个直接的问题为什么很多 Agent 在公开评测集上是“优等生”到了生产环境却变成“行为艺术家”答案通常不是模型不够强而是评测方式出了问题。多数团队评测 Agent 的方式是准备一批任务让 Agent 去执行看成功率、看工具调用次数、看最终输出质量。问题是这批任务常常来源于同一个业务团队的标注来源于同一套工具的文档甚至来源于训练时用过的提示词模板。Agent 不需要真正理解任务只需要记住“见到这种描述就调用那个工具”就能刷出高分。AgentMercury 切入的正是这个缺口。从项目名称和核心论断看它不是在模型层做文章而是在测评体系层面提出了一种新范式把训练环境与评测集彻底解耦。训练环境负责提供 Agent 学习技能所需的交互素材评测集则是独立的、动态的、刻意制造“没见过”条件的检验场。两个体系之间尽量少共享样本、少共享工具组合、少共享指令模板这样才能逼着 Agent 用能力而非记忆答题。这篇文章适合这几类读者正在搭建 Agent 评测体系的算法工程师想知道除了准确率还能怎么评估。训练数据团队想避免投入大量人力标注结果模型只是背下了答案。做智能体平台、RPA 工具、客服机器人、代码助手的开发者被“线下高分、线上翻车”反复折磨。对泛化能力感兴趣的研究者想理解脱钩评测与元学习、域泛化之间的联系。读完你会得到三样东西一套解读 AgentMercury 设计思路的分析框架一套可以在自己的 Agent 项目里直接使用的脱钩评测代码以及一组常见坑位的排查清单。2. AgentMercury 的核心思想训练环境与评测集脱钩2.1 先把三个概念划清边界很多人会把“训练环境”“评测集”“测试集”混着用但 AgentMercury 强调的脱钩恰恰要求先把它们分清楚。训练环境Agent 在训练阶段交互的模拟世界包括工具返回值、用户指令分布、状态转移规则、奖励反馈。它决定 Agent 学会什么。评测集用于检验 Agent 能力的一组任务形式上可能是一批 prompts也可能是一套带状态的环境实例。测试集更细的概念指导入模型做最终打分的那批样本是评测集的一部分。传统流水线中三者通常是“嵌套关系”评测集从训练环境的数据分布中采样测试集又从评测集中划分。AgentMercury 的脱钩主张是把评测集从训练环境的数据生成链路中独立出来由另一套机制负责构造、维护和刷新。2.2 “脱钩”不等于“分离测试集”这里需要澄清一个常见误解。很多人会说我早就在做脱钩了训练集和测试集分得清清楚楚。但“划分数据”和“脱钩环境”是两个层面的操作。划分测试集解决的是样本重叠问题避免同一道题既出现在练习册里又出现在考卷里。但样本不重叠不等于测试条件不重叠。如果练习册里的数学题都是“鸡兔同笼”考卷里换了数字还是“鸡兔同笼”模型背下题型照样能拿高分。测试集划分防止的是“背答案”防不了“背题型”。训练环境与评测集脱钩防的是“背场景”。它要求评测任务在工具集合、状态空间、指令形态、交互深度等维度上刻意偏离训练环境的默认配置。比如训练时 Agent 用官方 API 文档学会调用函数评测时就故意换一套接口命名让 Agent 只能靠读取函数签名和注释来完成任务。这种“换了游泳池再考游泳”的设计才能测试出真正的可迁移能力。2.3 AgentMercury 的关键实验逻辑从项目论点看AgentMercury 大概率采用了这样的实验逻辑先用常规方式训练一个 Agent在它的训练环境同源的评测集上打分再用脱钩后的独立评测集打分最后比较两个分数的差。如果脱钩评测得分显著低于同源评测得分说明 Agent 的泛化能力存在水分如果在脱钩条件下通过某种训练策略改进后分数明显回升就说明脱钩不仅能暴露问题还能指导训练。这个逻辑的工程含义很实用评测体系不是等模型训好之后再搭建的“验收工具”而是应该和训练环境并行建设、持续对抗的“压力测试工具”。评测集不是被动的静态题库而是动态生成的、会主动变化的对手。3. 为什么耦合会导致泛化能力虚高3.1 耦合的本质信息泄漏的慢性积累训练环境与评测集耦合最直接的后果是信息泄漏。但这种泄漏不一定是你肉眼可见的“测试集出现在训练集里”更多时候是一种慢性的、分布层面的泄漏。举个例子。训练环境里用户的对话开头经常是“你好请帮我查一下今天的天气”评测集里的任务也写成“你好帮我查天气”。模型不需要理解“查询天气”这个意图只要检测到“你好 天气 查一下”这个 n-gram 模式就能触发正确的工具调用。这种模式下评测分数反映的是模式识别能力而不是任务执行能力。更隐蔽的是工具层面的泄漏。训练 Agent 时工具函数往往带详细 docstring评测时也沿用同一套工具描述。Agent 学会了从 docstring 里提取参数而不是真正理解工具的输入输出约束。一旦生产环境的工具描述变了、字段名变了、返回结构变了Agent 立刻失去方向。这在实际项目中非常常见很多 Agent 一换 API 版本就全面崩盘不是模型变笨了而是它从来没有真正理解过工具。3.2 排行榜幻觉高分代理指标耦合还会造成一个团队层面的问题大家开始优化排行榜而不是优化能力。一旦评测集和训练环境同源指标就成了可被游戏的目标。团队会反复迭代 prompt让模型在评测集上达到 95% 的准确率。但每次 prompt 调整可能只是让模型更适应评测集的表达方式而不是更擅长解决用户问题。最典型的表现是agent 在评测集上成功率上升但平均 tool call 次数没有下降用户满意度没有提升异常恢复能力没有改善。这正是 AgentMercury 这类项目想打破的循环评测集应该是一把不配合的尺子。它不关心你想展示什么只关心你能不能处理没见过的情况。项目里有一句判断我很认同脱钩不是为了把分数压下去而是为了让分数恢复可信。3.3 耦合与过拟合的关系从机器学习原理看训练环境与评测集耦合会同时放大两类风险经验风险低估模型在训练分布上表现好但训练分布不能代表真实环境。测试误差被低估导致上线前误判。假设空间窄化如果评测集和训练环境共享指令风格、工具命名、状态表示模型可以选择一条捷径只拟合训练环境的模式而不去学习任务本身的抽象结构。这个捷径在评测时依然有效于是过拟合被评测结果“合法化”了。AgentMercury 的思路相当于从评测侧强制打断这条捷径。当评测集故意制造分布偏移时依赖捷径的 Agent 会现出原形真正学了抽象能力的 Agent 才能通过。下表可以更直观地看出两种范式下的差异维度耦合模式脱钩模式评测样本来源训练环境同源采样独立构造、跨分布生成工具接口与训练时一致刻意变更参数名、返回值指令风格复用训练模板改变措辞、结构、隐含条件目标检验“学了什么”检验“能迁移什么”常见误区分数虚高需要更多评测成本适合阶段回归测试、调试上线前评估、能力认证4. 设计一个脱钩的评测体系4.1 把“环境”拆成可变的维度要真的实现脱钩第一步是定义清楚环境由哪些维度组成。AgentMercury 的方法论中至少可以拆出以下维度任务分布用户请求的语义内容、复杂度、语言风格。工具集合可调用的工具种类、数量、接口命名、参数结构。观察空间环境反馈给 Agent 的状态格式、字段粒度、错误信息表达方式。指令形态prompt 的组织方式是结构化 JSON 还是自然语言是短指令还是长上下文。交互深度任务是否需要多轮记忆、是否需要回溯、是否需要跨工具协调。训练环境是这些维度的某个具体配置组合评测集则应该是另一组配置组合。脱钩不是所有维度都偏离到完全不可解而是在保持任务底层逻辑不变的前提下改变表面的环境语法。4.2 保持“任务逻辑”稳定改变“环境语法”这里有一个关键设计原则脱钩测评测的是迁移能力不是从零解决问题的能力。因此底层任务逻辑应该保持一致比如“预订餐厅”就是“预订餐厅”但评测环境可以在以下方面做扰动工具名从book_restaurant改成reserve_dining_table。返回字段从status: confirmed改成confirmation: true。用户描述从“帮我订一个周六晚上六点的二人位”改成“周六晚上六点两个人还有位子吗”。反馈从明确的成功标志改成需要 Agent 主动确认的模糊响应。这样设计出来的评测任务对“背题库”的 Agent 是降维打击对真正理解了“预订餐厅”完整链路查询、确认、提交、校验的 Agent 则只是小障碍。4.3 评测集要“动态生成”而不是“一次配好”静态评测集最大的问题是时间一长就会被训练过程反向适应。团队会把历史评测样本的分析结果回灌到 prompt 里逐渐让评测集失去独立性。动态生成是解决这个问题的主要手段。做法是定义任务模板和变异规则每次评测时根据随机种子生成一批任务实例。同一个种子对应同一批任务保证结果可复现不同种子之间任务不重叠保证模型没法记住具体题目。AgentMercury 的实践提示我们评测集应该像密码一样定期轮换甚至可以做成“评测版本”的概念每个版本有一套自己的生成器配置和统计口径。5. 代码示例构建一套可运行的脱钩评测流程下面用 Python 演示一个最小可用的脱钩评测系统。代码会包含三部分环境配置定义、脱钩评测集生成、泛化差距分析。这个示例不依赖任何特定框架可以直接迁移到你的 Agent 工程里。5.1 定义训练环境与评测环境的配置首先我们把环境抽象为一份配置。训练环境用一套配置评测环境用另一套配置两者在工具命名、观察字段、指令风格上刻意不同。# 文件路径env_configs.py from dataclasses import dataclass, field from typing import Dict, List dataclass class EnvConfig: name: str tool_names: Dict[str, str] # 逻辑操作名 - 实际工具名 observation_keys: List[str] # 环境返回给 Agent 的字段 instruction_style: str # plain / structured / minimal error_message_mode: str # descriptive / terse seed: int 42 # 训练环境工具名清晰字段齐全指令模板固定 TRAIN_ENV EnvConfig( nametrain, tool_names{ search: search_web, book: book_restaurant, weather: get_weather, }, observation_keys[status, message, data], instruction_stylestructured, error_message_modedescriptive, seed1, ) # 评测环境工具名换掉字段名换掉指令风格也换掉 EVAL_ENV EnvConfig( nameeval_decoupled, tool_names{ search: query_engine, book: reserve_dining_table, weather: fetch_forecast, }, observation_keys[ok, detail, payload], instruction_styleminimal, error_message_modeterse, seed99, )这一步解决的是环境语法层的脱钩。逻辑操作仍然只有 search、book、weather 三种但 Agent 在评测环境里面对的名字、字段、风格全部是陌生组合。如果 Agent 只是记住了“调用search_web然后读data字段”在评测环境里会立刻失去抓手。5.2 生成脱钩评测样本为了不让评测集变成固定题库我们需要一个任务生成器。它根据任务模板和随机种子生成具体样本并确保生成的指令不包含训练环境的工具名和字段名。# 文件路径eval_task_generator.py import random from env_configs import EnvConfig class DecoupledTaskGenerator: 基于任务模板 环境配置生成评测样本 def __init__(self, env: EnvConfig): self.env env self.rng random.Random(env.seed) def _render_instruction(self, template: str, **kwargs) - str: if self.env.instruction_style minimal: return template.format(**kwargs).strip() if self.env.instruction_style structured: return f[任务] {template.format(**kwargs)} [格式] 请先说明步骤再调用工具 return template.format(**kwargs) def _render_tool_call(self, op: str) - str: return self.env.tool_names[op] def generate_booking_task(self) - dict: city self.rng.choice([上海, 北京, 深圳]) date f{self.rng.randint(1, 28)}号 time f{self.rng.randint(17, 21)}点 people self.rng.randint(2, 6) instruction self._render_instruction( 在{city}找一家{date}{time}的餐厅{people}个人帮我订位, citycity, datedate, timetime, peoplepeople, ) ground_truth { operation: book, tool: self._render_tool_call(book), args: { city: city, date: date, time: time, people: people, }, } return {instruction: instruction, ground_truth: ground_truth} def generate_weather_task(self) - dict: city self.rng.choice([广州, 杭州, 成都, 武汉]) day self.rng.choice([今天, 明天, 周末]) instruction self._render_instruction( {day}{city}天气怎么样需要带伞吗, dayday, citycity, ) ground_truth { operation: weather, tool: self._render_tool_call(weather), args: {city: city, day: day}, } return {instruction: instruction, ground_truth: ground_truth} def make_eval_set(self, n: int) - list: tasks [] for _ in range(n): if self.rng.random() 0.5: tasks.append(self.generate_booking_task()) else: tasks.append(self.generate_weather_task()) return tasks这个生成器有两个作用一是让评测任务与训练环境的指令模板脱钩二是让评测集可以无限刷新。你在每周的回归评测里换一个 seed模型就不可能通过记忆答案来蒙混过关。5.3 评测执行器有了评测任务还需要一个执行器来跑 Agent。为了演示这里用一个“最小 Agent 适配器”接口实际项目中你把run_agent替换成自己的 Agent 调用逻辑即可。# 文件路径eval_runner.py from env_configs import EnvConfig from eval_task_generator import DecoupledTaskGenerator def run_agent(instruction: str, env: EnvConfig) - dict: 实际工程中替换为你的 Agent 调用入口。 这里用一个模拟实现做演示 - 如果 Agent 适配了当前工具命名返回正确工具 - 否则返回一个基于记忆的错误工具名。 known_tools set(env.tool_names.values()) # 模拟Agent 内部有一个从“任务意图”到“工具名”的映射 memory { book: book_restaurant, # 训练环境的书订工具 weather: get_weather, } if 订 in instruction and book_restaurant in known_tools: return {tool: book_restaurant, args: {}} if 天气 in instruction and get_weather in known_tools: return {tool: get_weather, args: {}} return {tool: unknown, args: {}} def evaluate(tasks: list, env: EnvConfig) - dict: success 0 error_cases [] for task in tasks: result run_agent(task[instruction], env) expected_tool task[ground_truth][tool] if result.get(tool) expected_tool: success 1 else: error_cases.append({ instruction: task[instruction], expected: expected_tool, actual: result.get(tool), }) return { env: env.name, total: len(tasks), success: success, accuracy: success / len(tasks) if tasks else 0, error_cases: error_cases[:5], } if __name__ __main__: train_gen DecoupledTaskGenerator(TRAIN_ENV) eval_gen DecoupledTaskGenerator(EVAL_ENV) # 训练环境同源评测这一步相当于“泳池里考试” same_source_tasks train_gen.make_eval_set(100) same_source_score evaluate(same_source_tasks, TRAIN_ENV) # 脱钩评测换工具名、换字段、换指令风格 decoupled_tasks eval_gen.make_eval_set(100) decoupled_score evaluate(decoupled_tasks, EVAL_ENV) print(f同源评测准确率: {same_source_score[accuracy]:.2f}) print(f脱钩评测准确率: {decoupled_score[accuracy]:.2f}) print(脱钩评测中的典型错误:) for case in decoupled_score[error_cases]: print(f 指令: {case[instruction]}) print(f 期望工具: {case[expected]}实际工具: {case[actual]})运行这段代码会看到一个典型的“虚高”现象同源评测的准确率很高因为 Agent 记忆里的工具名book_restaurant、get_weather在训练环境里都有效脱钩评测准确率直接掉到很低因为工具名换成了reserve_dining_table、fetch_forecast。python eval_runner.py预期输出类似同源评测准确率: 0.98 脱钩评测准确率: 0.00 脱钩评测中的典型错误: 指令: 在深圳找一家18点的餐厅5个人帮我订位 期望工具: reserve_dining_table实际工具: book_restaurant如果你的 Agent 也出现这种“同源高分、脱钩低分”的落差说明它还没有真正学会任务抽象只是记住了训练环境里的工具名和字段名。5.4 泛化差距分析脱钩评测的意义不只是暴露问题还要量化问题。我们可以定义一个“泛化差距”指标同源准确率减去脱钩准确率。差值越大说明模型越依赖表面记忆。# 文件路径gap_analysis.py from env_configs import TRAIN_ENV, EVAL_ENV from eval_task_generator import DecoupledTaskGenerator from eval_runner import evaluate, run_agent def compute_generalization_gap(same_score: dict, decoupled_score: dict) - dict: gap same_score[accuracy] - decoupled_score[accuracy] return { same_source_accuracy: round(same_score[accuracy], 3), decoupled_accuracy: round(decoupled_score[accuracy], 3), gap: round(gap, 3), conclusion: ( 泛化信号健康 if gap 0.05 else 存在中度泛化缺口 if gap 0.2 else 存在严重表面拟合 ), } if __name__ __main__: same_tasks DecoupledTaskGenerator(TRAIN_ENV).make_eval_set(200) diff_tasks DecoupledTaskGenerator(EVAL_ENV).make_eval_set(200) same_score evaluate(same_tasks, TRAIN_ENV) diff_score evaluate(diff_tasks, EVAL_ENV) report compute_generalization_gap(same_score, diff_score) for key, value in report.items(): print(f{key}: {value})这个脚本可以直接接入 CI 流程。每次训练完模型跑一次脱钩评测如果泛化差距超过阈值就阻止模型上线。这样“分数虚高”就从玄学变成了可量化的门禁指标。6. 从训练到评测的流程改造6.1 两条流水线并行脱钩评测不是简单加一个脚本而是要改造团队的工作流程。核心原则是训练流水线和评测流水线由不同的配置驱动并且评测流水线对训练过程保持“盲评”状态。具体来说建议把评测分成三个层级第一层冒烟评测。每次训练 checkpoint 都跑使用最小的脱钩任务集用于快速发现 Agent 是否完全失效。第二层回归评测。每天跑一次任务覆盖面较广对比不同训练策略在泛化差距上的变化。第三层认证评测。发布前跑使用最新版本的评测生成器并记录随机种子和评测配置作为线上表现的预测基线。6.2 评测版本管理评测集本身要像代码一样管理。每次评测生成器的变更都应该记录变更原因、变更维度、影响范围。否则团队会陷入另一个坑为了提升脱钩分数反复调整评测生成器最后评测集又变成了新的“训练集”。一个可行的做法是给评测生成器做配置版本号例如eval_spec_v3。训练脚本记录训练环境配置评测脚本记录评测配置。模型上线的同时上线一份“评测证明”这个模型在哪个 seed、哪个评测配置下获得了多少分。6.3 谁有权限修改评测集这个问题容易被忽视。如果负责训练的同学同时拥有评测集的修改权限他会很自然地根据评测失败案例去调训练数据这会让评测集迅速被反向适应。更稳妥的做法是训练团队和评测团队分离或者至少实行权限隔离。评测集的变更要通过独立的评审流程变更后要强制重建一批新样本而不是在失败样本上“打补丁”。7. 常见问题与排查思路在把脱钩评测引入实际项目时会遇到一些典型的坑。下面列出一组我判断最容易出现的问题供你对照排查。问题现象可能原因排查方式解决方案脱钩评测准确率过高接近同源评测环境配置实际仍与训练环境共享了关键变量对比两份 EnvConfig 的工具命名、字段和指令模板在配置中增加更多差异维度例如改变状态返回结构脱钩评测准确率过低几乎为 0任务生成器改变了底层任务逻辑导致任务本身不可解人工抽检评测样本确认真实用户能否完成只扰动环境语法保持任务逻辑和可解性不变同一评测配置下两次结果不一致Agent 本身有随机性或评测任务集未固定 seed检查 Agent 的 temperature 和随机种子评测时固定 Agent 的随机参数生成器固定 seed模型在脱钩评测中频繁调用错误工具Agent 依赖工具名词面匹配缺少基于功能的工具选择查看失败样本里的 tool 名称分布在 Agent 中加入工具功能描述理解层或增加基于语义的工具匹配评测集越跑越“简单”分数逐步上升训练数据被评测集反向污染或评测用例泄漏对比训练数据与评测样本的相似度引入评测集版本轮换用新 seed 重新生成任务团队对“分数下降”产生抵触没有建立合理的验收预期将泛化差距纳入发布评审指标先把评测门禁设为“检测回退”再逐步收紧阈值排查的一般顺序是先确认评测配置是否真的脱钩再确认任务是否可解然后排除随机性干扰最后再看 Agent 内部工具的调用逻辑。不要一上来就改模型先怀疑评测环境本身。8. 最佳实践与工程建议8.1 从“环境语法矩阵”开始设计脱钩不要拍脑袋决定评测环境改成什么样。建议先画一张环境语法矩阵把每个维度能变和不能变的地方列清楚。不能变任务最终要达成的目标、工具的底层能力边界、输入数据的合法范围。可以变工具命名、参数顺序、返回字段、指令措辞、错误提示的详细程度、多轮交互中的回复节奏。有了这张矩阵评测团队可以系统性地组合出多种脱钩程度轻度脱钩换措辞中度脱钩换工具名重度脱钩直接改状态返回结构。每一档对应不同的能力要求也对应不同的泛化差距阈值。8.2 逐步收紧不要一上来就极限脱钩如果你的 Agent 目前在同源评测中已经达到 95% 准确率直接切换到重度脱钩评测分数可能掉到 30% 以下团队会非常受挫。更稳妥的做法是分三档推进第一周只改指令措辞。这能暴露 prompt 层面的过拟合。第二周加入工具名和字段名扰动。这能暴露工具理解层面的问题。第三周加入状态返回结构扰动和模糊错误提示。这能暴露异常恢复能力的问题。每一档都要记录泛化差距的变化趋势。差距逐步缩小说明 Agent 的泛化能力在真正提升差距不变说明训练方向可能错了。8.3 在 CI 里建立评测门禁脱钩评测最大的工程价值是可以作为发布时间门禁。建议在 CI 脚本中加入以下检查每次提交训练代码跑冒烟脱钩评测。如果准确率比上一个版本下降超过 5%阻断合并。每次发布前跑完整脱钩评测并生成包含评测配置版本、seed、样本量的评测报告。这里要特别注意所有评测过程都应只读不允许评测逻辑写回训练数据目录。评测原始结果要留档便于后续追溯模型行为退化是从哪个版本开始的。8.4 注意安全与数据合规边界脱钩评测如果涉及真实的用户数据需要格外谨慎。建议遵守最小权限原则评测样本生成器只用脱敏后的数据字段不接触真实用户隐私内容。评测任务不要求 Agent 访问互联网上的真实第三方服务需要联调时使用 mock 服务或沙箱环境。在评测环境中涉及账号、支付、删除类操作的业务必须使用测试账号、测试环境并做好操作审计和回滚预案。评测环境的安全边界应当与生产环境严格隔离这类操作不能以“测试方便”为理由放宽。8.5 命名与文档规范给示例中的配置和脚本一个约定环境配置统一用EnvConfig每个环境的 name 唯一评测任务生成器的 seed 记录在文件名或 manifest 里每次评测输出一个 JSON 报告文件命名建议为eval_report_{model_version}_{env_name}_{seed}.json。文档方面至少要有两份 README一份给训练团队说明训练环境配置变更流程一份给评测团队说明评测生成器的维度定义和新增扰动的评审标准。这样可以避免训练和评测之间的权限与认知混乱。9. 总结与后续学习方向AgentMercury 给 Agent 评测带来的转变不是多了一个更强的工具或数据集而是把“评测”这件事从训练流程的附属品变成了独立的研究对象。训练环境与评测集脱钩本质上是给 Agent 设了一道“换场景考试”让模型无法再靠记忆训练环境的表面特征来刷分。这种方法的价值体现在三个层面对模型来说脱钩评测让泛化能力成为可优化的目标对团队来说泛化差距成为可量化的发布门禁对项目来说动态评测集避免了基准分数随时间贬值。如果你准备在自己的项目里实践建议从最小改动开始先复制本文的EnvConfig和DecoupledTaskGenerator把项目里的工具名和指令模板作为变量生成一组轻度脱钩评测样本跑一次泛化差距分析。这个实验的成本不高却能很快告诉你团队引以为傲的准确率里有多少是真实能力有多少是环境记忆。后续值得深入的方向有三个一是把脱钩评测与强化学习训练结合在训练阶段引入“环境域随机化”让 Agent 在多变环境中学会更稳健的决策二是研究不同脱钩维度对泛化差距的贡献度比如到底是工具命名的影响大还是状态表示的影响大三是把评测集动态生成与自动化标注结合起来降低脱钩评测的人力成本。这些方向都和 AgentMercury 的核心命题相关只有在评测上不迁就模型的记忆模型才会在能力上真正妥协于泛化。