企业官网建设流程全解析

AgentMercury 这个思路真正值得关注的地方，不是模型结构又有了什么变化，而是它把训练和评测拆开了。这个“拆开”不是简单的数据划分，而是“训练环境与评测集脱钩”：训练阶段让智能体在它自己的环境里试错，评测阶段却用一套和训练环境不同分布、不同情境、甚至不同交互规则的任务来考核。这样做的好处是，评测结果能更接近真实未见过场景的表现，而不是“背题”成绩。

说得直白一点：如果你是做智能体、对话系统或强化学习任务，并且发现模型在评测集上分数越来越高，但换一批任务就明显变笨，那大概率不是模型能力不够，而是训练环境和评测集绑得太紧。下面围绕这个现象，拆一下 AgentMercury 的脱钩思路怎么落地，以及怎么验证它确实提升了泛化能力。

1. 别急着追模型结构，先看“训练环境和评测集脱钩”这件事

1.1 AgentMercury 真正解决的：不是训练得更久，而是测得更准

AgentMercury 具体用什么网络结构、用什么强化学习算法，这里不展开。因为它真正值得讨论的不是结构，而是评测方式。

这个判断要放在智能体训练的背景下看。智能体不像普通分类模型那样只吃固定输入，它要在环境里去决策、去尝试、去拿反馈。训练结束后，我们通常会用另一批任务来评估它的能力。这里的问题在于：如果评测任务和训练任务来自同一个环境生成器，甚至就是从训练数据里留出来的一部分，那么智能体完全有可能通过记住环境特征、奖励模式、状态分布来拿高分，而不是通过学会通用的决策能力。

所以 AgentMercury 的核心价值不是“换一个更大的模型”，而是“换一套更严格的考试方式”。考试题目如果和平时练的题相似，考出来的分数再高，也不能说明真实水平。这个道理放到智能体训练里，就是训练环境与评测集脱钩的核心原因。

1.2 脱钩不是把评测集藏起来，而是切断“评测集来自训练环境”这条捷径

脱钩会让人误解成“评测时换一批新数据”，但这里远不止换数据。脱钩要求的是，评测过程中不能依赖训练环境里才有的信息。

我一般从两个层面理解：

• 数据层面：评测任务的文本、图片、环境状态、工具调用链路，不能是训练环境里已经出现过的数据，也不能是同分布直接抽样出来的数据。
• 接口层面：评测时给模型提供的观测、动作空间、奖励信号，不应沿用训练环境完全相同的编码方式。如果训练时靠某个隐藏状态拿到高分，评测时这个状态不存在，智能体还能不能正确决策？这才是真正的考察点。

换句话说，脱钩是切断“评测集来自训练环境”这条捷径。评测集不是训练集随机的另一个子集，而是独立设计的一套评估协议，覆盖训练环境没见过的分布。这样一旦分数下降，我们能更早发现真实的泛化短板，而不是等到上线才暴露。

2. 训练环境和评测集一旦“黏在一起”，泛化能力会被虚高掩盖

2.1 评测分数高，不代表到了新环境还高

常见做法是：智能体在某个环境里训练，然后从训练环境里随机抽任务做评测，每轮还在调整超参。最终评测集分数一路涨，看起来模型在进步。实际上，评测任务和训练任务共享同一个状态分布、同一个奖励函数、同一套工具列表，智能体并不需要学会非常泛化的策略，只要在训练环境里找到规律就能赢。

这种情况下，模型学到的是“当前环境的快捷方式”，不是“解决一类问题的能力”。换到另一套环境，界面变了、状态编号变了、任务目标表达变了，分数就会掉得很明显。

所以评价一个智能体，不能只看它在训练环境上的评测，而要看它到独立评测集上的迁移表现。AgentMercury 的脱钩思路，本质上是把“在训练环境里的表现”和“在陌生任务上的泛化能力”分成两件事看。

2.2 常见泄漏路径：状态信息、奖励信号、分布记忆

我排过一次智能体评测问题，发现分数虚高往往来自三条路径：

1. 状态信息泄漏。智能体能看到的环境状态里，藏了训练时容易识别的特征，比如关卡编号、特殊 token、固定开头。评测集如果仍然包含这些特征，模型不需要推理就能输出正确答案。
2. 奖励信号泄漏。训练时回报函数会在某一类行为后给高分。评测时如果不换奖励设定，模型只要复现训练时的“肌肉记忆”就能拿高分，而不是在新环境里探索。
3. 分布记忆。评测任务虽然没用训练数据，但生成方式和训练环境一致，比如同样一批模板，只是换了几个词。模型见过大量类似模板后，本质上是在做模板匹配。

这三种泄漏其实很难用“数据不重叠”来消除。必须让评测环境在分布上、交互规则上、奖励设计上都和训练环境拉开距离。

2.3 用 yolov5 训练环境搭建来理解“环境一致”的诱惑

yolov5 这一类的视觉模型训练，能很直接地解释这个问题。

很多人第一次训练 yolov5 时，会把同一批图片随机分成训练集和验证集。这里有个隐蔽问题：同一段视频里的连续帧，或者同一个设备在同一个场景下拍的照片，很容易同时出现在训练集和验证集里。模型看过这些图片的相似特征，验证集分数自然很高。但把模型部署到新的工厂、新的摄像头、新的光照条件下，mAP 立刻下降。

这种随机划分的问题就在于验证集和训练环境太一致。评测图片虽然文件不同，但来源场景相同，相当于“训练环境与评测集黏在一起”。要让泛化结果可信，就要按场景、按设备、按时间段来划分验证集，让验证集的核心分布与训练环境脱钩。这和 AgentMercury 的思路是相通的。

3. 把脱钩落到实操：从构建独立评测集到统一评测协议

3.1 第一步：把训练环境和评测环境拆成两套配置

先做配置拆分。训练环境通常包含：

• 环境名称或 ID
• 状态观测格式
• 动作空间
• 奖励函数
• 任务模板列表
• 最大步数

评测环境不能继续使用这份配置。可以单独建一份 eval_config，字段对应但内容不同。比如：

train_env: env_id: "mercury_town_v1" observation: "text" action_space: "navigate, talk, use_tool" reward: "task_complete + step_penalty" task_templates: ["template_set_A", "template_set_B"] eval_env: env_id: "mercury_town_eval_v2" observation: "text + structured_context" action_space: "navigate, talk, use_tool, ask_clarify" reward: "task_complete + efficiency_score" task_templates: ["template_set_C", "template_set_D", "template_set_E"]

这里的关键是，评测配置里不能只改 task_templates 一个字段。状态格式、奖励函数、工具范围最好也要有差异。如果完全一样，评测集就变成了训练环境的一个版本号，脱钩也就失去了意义。

3.2 第二步：让评测集覆盖“训练环境没见过”的分布

构建评测集时，不能只从训练分布抽样。要刻意加入训练环境覆盖不到的分布。拿对话评测集构建来说，训练数据如果都是客服问答模板，评测集就应该包含：

• 不同语言风格的输入
• 不同领域的任务
• 不同数量的工具调用
• 混合了异常输入的情况
• 需要澄清和追问的场景

否则只能证明模型会做客服问答模板，不能证明它具备对话能力。

这里还要考虑评测集的难度和区分度。如果评测集太简单，大家都能拿满分，脱钩就没有意义。如果评测集太难，模型完全做不出，也难以判断是模型问题还是任务不合理。一般建议先把评测任务按难度分层，然后观察模型在每一层的成功率。

3.3 第三步：设好评测协议，避免人为偏差

评测集独立还不够，评测过程也要固定。我见过不少项目，评测集没问题，但评测协议不统一：

• 允许模型重试 3 次和只允许 1 次，结果差别很大
• 超时时间一个用 10 秒，一个用 60 秒
• 最终答案解析方式不一致，同一个输出有时判定对有时判定错
• 随机种子不固定，状态初始化每次都不同

所以评测协议至少要包含这些项：

• 每回合最大步数
• 每一任务最大尝试次数
• 超时时间
• 随机种子
• 答案解析规则
• 成绩统计方式（成功率、平均步数、平均分数）

这些参数要在评测开始前锁死，并且写进配置里。评测结果如果只记录一个总分，没有协议细节，后续很难复现。

3.4 一个最小化的评测执行伪代码

给一个通用伪代码，不是 AgentMercury 的源码，但可以体现脱钩评测的流程：

def run_evaluation(agent, eval_cfg): results = [] for task in eval_cfg["tasks"]: env = create_env(eval_cfg["env_config"], seed=eval_cfg["seed"]) obs = env.reset(task) done = False steps = 0 while not done and steps < eval_cfg["max_steps"]: action = agent.act(obs) obs, reward, done, info = env.step(action) steps += 1 results.append({ "task_id": task["id"], "success": info.get("success", False), "steps": steps, "score": info.get("score", 0), }) return summarize(results)

注意这里 create_env 必须使用 eval_cfg["env_config"]，不能顺手传训练环境配置。如果两套环境封装在同一类里，也要用不同的初始化参数。评测代码里不应该出现先加载训练环境再替换任务的写法，这样很容易把训练环境的隐藏状态带进评测。

4. 脱钩之后怎么判断泛化真的提升了

4.1 四个可量化的观察指标

脱钩不是口号，要能验证。我建议至少盯四个指标：

1. 同分布评测分数：也就是训练环境内评测，看模型有没有保住基本能力。
2. 脱钩评测分数：独立评测集上的成功率或得分，这是核心指标。
3. 分数差距：同分布分数减去脱钩分数。这个差距越小，说明模型不是在背题，泛化越稳定。
4. 方差稳定性：同一模型多次评测的波动。如果标准差很大，说明结果受随机初始化或评测任务抽样影响太大，不足以判断泛化。

不要只追求脱钩评测分数这一项。如果同分布分数很高、独立评测分数很低，恰恰说明之前的评测体系掩盖了过拟合。

4.2 判断标准：评测分数下降不等于模型退化

脱钩之后，很多人的第一反应是分数怎么降了。这其实是正常的。

比如某个智能体在同一分布下评测分数 92 分，脱钩评测只有 74 分。很多人会觉得模型退化了，于是又跑回原来的评测集调参，直到分数回升。但这样做，又回到了“绑定训练环境”的陷阱。

正确做法是先看下降的分布。如果同分布 92 分、脱钩 74 分，说明模型有基础能力，但在陌生任务上掉点明显。这时候该做的不是把脱钩评测集换掉，而是分析哪些任务类型掉分最多，然后针对那些能力做改进。

如果一个模型在脱钩评测里分数从 50 分提升到 68 分，即使同分布评测从 90 分降到 85 分，那它在泛化能力上也是明显进步的。真正的生产部署看的是后面的数字，而不是训练环境内那个更漂亮的分。

4.3 用对话评测集构建来对照说明

拿对话评测集构建举个例子。假设训练环境是中文客服对话，模型在同分布评测里准确率 88%。构建脱钩评测集时，加入英文邮件回复、多轮追问、工具调用混合场景，模型准确率降到 62%。这时候不要急着否定评测集，而要看：

• 英文任务掉分，是训练数据本身缺少英文，还是模型编码器不支持？
• 多轮追问掉分，是记忆模块上限低，还是策略根本没学会追问？
• 工具调用掉分，是接口格式问题，还是动作空间在评测时新增了 ask_clarify 导致的？

每一个问题都能拆成可改进的技术项。脱钩评测的价值就在这里：它能告诉你该往哪个方向努力，而不是只给你一个高分幻觉。

5. 脱钩方案的常见坑：分数下降、评测不稳定、任务难度失衡

5.1 分数下降先排查的不是模型，而是评测集

脱钩之后遇到分数下降，先不要改模型，按顺序排查：

1. 评测集构建是否合理。评测任务里有没有包含无法完成的逻辑？有没有因为任务模板太少导致抽样不均衡？
2. 评测协议有没有偏移。最大步数、随机种子、解析规则和上一次是否一致？
3. 环境初始化是否有泄漏。评测环境是否错误地加载了训练配置？日志里环境 ID 是否属于 eval 配置？
4. 模型是否做了缓存。如果评测时把之前的输出缓存当成了正确答案，也会导致分数异常。

我的经验里，很多分数下降问题最后查出来是评测脚本的配置串了，不是模型真的变弱了。所以先看评测链路，再动模型参数。

5.2 评测不稳定大概率是任务抽样和随机种子没锁住

评测不稳定，一种情况是每次抽到的评测任务难度差别大。比如评测集总共 200 题，每次随机抽 50 题，但两个子集难度不一致，分数自然波动。建议评测固定整套任务，或者用分层抽样，保证每次都有各个难度档位的题。

另一种情况是环境随机种子没固定。比如智能体的初始状态每次不同，动作结果也带随机性，那分数方差就会很大。评测协议里必须固定所有能固定的随机源，至少固定环境种子、任务顺序、初始状态。模型内部的随机性可以根据需要控制，但环境侧一定要锁住。

5.3 任务难度失衡会让脱钩失去意义

如果评测集全是特别简单的任务，脱钩评测分数很高，容易误以为泛化很好。实际上评测集没有区分度。反过来，如果评测集全是从未见过的高难度任务，模型几乎全失败，也很难看出哪部分能力在进步。

更好的做法是给评测任务分层：

• L1：和训练任务结构相似，但数据不重叠
• L2：任务目标相似，但约束条件和工具范围有变化
• L3：任务目标和交互方式都有明显变化

训练时可以看 L1，判断基本能力有没有保留；重点看 L2，反映中等迁移能力；L3 可以少一些，作为挑战项。这样脱钩评测就不只是一个分数，而是一组能定位问题的分档指标。

5.4 我的排查顺序

把常见问题排成链路：

1. 先看现象：是分数低、不稳定，还是完全无法运行。
2. 再看输入：评测集任务格式、文本内容、工具数量、任务数量是否正常。
3. 再看环境：是否加载了 eval 配置，环境 ID 是否正确，奖励函数是否被训练环境覆盖。
4. 再看协议：随机种子、最大步数、重试次数、超时时间、解析规则是否锁定。
5. 最后看模型：是否过拟合训练环境，是否对某些状态特征有强依赖。

按这个顺序排查，多数问题都能定位。不要一上来就调模型结构或超参，因为评测体系本身不稳的时候，调模型只会让结论更模糊。

回到开头那个问题。做 AgentMercury 这类智能体实验，最该盯住的不是评测分数涨了多少，而是评测分数还相不相信。训练环境和评测集脱钩，看着像给测评加难度，实际上是逼着模型去学更通用的策略。踩过几次坑之后我发现，真正让模型在陌生环境里站得住的，不是更多训练技巧，而是你用什么标准去测量它。建议先从最小规模的训练环境和独立评测集开始，把两套配置写清楚，再逐步扩大任务难度。