企业官网建设流程全解析

训练环境是泳池，评测集是考场，这两个场地一旦共用同一个教练、同一套题库，分数再高也很难说明真实水平。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 的方法论中，至少可以拆出以下维度：

1. 任务分布：用户请求的语义内容、复杂度、语言风格。
2. 工具集合：可调用的工具种类、数量、接口命名、参数结构。
3. 观察空间：环境反馈给 Agent 的状态格式、字段粒度、错误信息表达方式。
4. 指令形态：prompt 的组织方式，是结构化 JSON 还是自然语言，是短指令还是长上下文。
5. 交互深度：任务是否需要多轮记忆、是否需要回溯、是否需要跨工具协调。

训练环境是这些维度的某个具体配置组合，评测集则应该是另一组配置组合。脱钩不是所有维度都偏离到完全不可解，而是在保持任务底层逻辑不变的前提下，改变表面的环境语法。

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( name="train", tool_names={ "search": "search_web", "book": "book_restaurant", "weather": "get_weather", }, observation_keys=["status", "message", "data"], instruction_style="structured", error_message_mode="descriptive", seed=1, ) # 评测环境：工具名换掉，字段名换掉，指令风格也换掉 EVAL_ENV = EnvConfig( name="eval_decoupled", tool_names={ "search": "query_engine", "book": "reserve_dining_table", "weather": "fetch_forecast", }, observation_keys=["ok", "detail", "payload"], instruction_style="minimal", error_message_mode="terse", seed=99, )

这一步解决的是环境语法层的脱钩。逻辑操作仍然只有 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}个人，帮我订位", city=city, date=date, time=time, people=people, ) 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}天气怎么样，需要带伞吗", day=day, city=city, ) 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. 常见问题与排查思路

在把脱钩评测引入实际项目时，会遇到一些典型的坑。下面列出一组我判断最容易出现的问题，供你对照排查。

排查的一般顺序是：先确认评测配置是否真的脱钩，再确认任务是否可解，然后排除随机性干扰，最后再看 Agent 内部工具的调用逻辑。不要一上来就改模型，先怀疑评测环境本身。

8. 最佳实践与工程建议

8.1 从“环境语法矩阵”开始设计脱钩

不要拍脑袋决定评测环境改成什么样。建议先画一张环境语法矩阵，把每个维度能变和不能变的地方列清楚。

• 不能变：任务最终要达成的目标、工具的底层能力边界、输入数据的合法范围。
• 可以变：工具命名、参数顺序、返回字段、指令措辞、错误提示的详细程度、多轮交互中的回复节奏。

有了这张矩阵，评测团队可以系统性地组合出多种脱钩程度：轻度脱钩换措辞，中度脱钩换工具名，重度脱钩直接改状态返回结构。每一档对应不同的能力要求，也对应不同的泛化差距阈值。

8.2 逐步收紧，不要一上来就极限脱钩

如果你的 Agent 目前在同源评测中已经达到 95% 准确率，直接切换到重度脱钩评测，分数可能掉到 30% 以下，团队会非常受挫。更稳妥的做法是分三档推进：

1. 第一周：只改指令措辞。这能暴露 prompt 层面的过拟合。
2. 第二周：加入工具名和字段名扰动。这能暴露工具理解层面的问题。
3. 第三周：加入状态返回结构扰动和模糊错误提示。这能暴露异常恢复能力的问题。

每一档都要记录泛化差距的变化趋势。差距逐步缩小，说明 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 的核心命题相关：只有在评测上不迁就模型的记忆，模型才会在能力上真正妥协于泛化。