SEAL: Synergistic Co-Evolution of Agents and Learning Environments

Paper: arXiv:2605.24426 Code: yihaohu0118/SEAL Code reference: main @ a0d22dba (2026-05-25)

1. Motivation (研究动机)

当前 LLM agents 的 self-evolution 通常把“agent 变强”理解成单侧优化：要么只更新 policy，要么只扩展 curriculum / task / environment distribution。SEAL 认为这两类路线在交互式 tool-use 场景中共享一个结构性瓶颈：训练时 environment 提供的学习信号没有跟上 agent 能力边界的变化。agent 经过若干轮训练后，失败模式会从“不会调用工具”转向“参数类型错”“调用顺序错”“收到错误后不会恢复”等更细粒度问题；如果环境仍只返回稀疏的 binary verifier reward，policy 只能知道整条 trajectory 成败，却不知道失败应归因到哪个 turn、哪个 tool schema、哪类 recovery 行为。

论文把这个问题命名为 Agent-Environment Misalignment。这里的 environment 不是测试 benchmark 本身，也不是 tool 的真实语义或 verifier，而是 training-time learning substrate：任务暴露方式、observation interface、action constraints、execution error feedback、recovery hints 等让模型学习的接口层。这个定义很关键，因为它允许训练时增强反馈，但不改变 benchmark 的 tool semantics、task labels、transition dynamics、reward 和 evaluation verifier，避免把方法收益混成“测试接口变简单”。

研究这个问题值得做，是因为 realistic tool-use agents 的错误通常发生在 multi-turn、strict-schema、可执行环境中：一次无效 tool call 可能导致后续状态全错；一次参数类型错误可能需要先查询 prerequisite information 再恢复；final answer 错误可能只是早期 tool argument 错误的下游结果。若训练只用终端 reward，credit assignment 非常粗；若 curriculum 不看当前 agent 的 executable failures，又可能生成“更难但不对症”的环境。SEAL 的目标是在 low-resource 场景下，用少量 400 个 BFCL V3 training samples，把失败轨迹转成更有诊断价值的训练信号，从而提升多轮 tool-use 学习效率和 OOD transfer。

2. Idea (核心思想)

核心 insight：agent 和 training-time environment 应该共同进化，而连接两者的共享信号不是 free-form reflection，而是 executable verifier-grounded failure diagnosis。SEAL 先让当前 policy 在可执行 tool environment 中 rollout，再把失败分解成 turn-level diagnostic labels；同一组 labels 一方面更新训练接口，让后续 observation 暴露更清楚的 schema / constraint / recovery cues，另一方面重加权 GRPO advantage，让更可归因、更可修复的轨迹贡献更大 policy-gradient 信号。

与 model-centric RL / self-reflection 的根本差别在于，SEAL 不只把失败当作 reward 或文本反思来更新 policy，而是把失败 profile 反馈给 training interface。与 environment-centric curriculum / data evolution 的差别在于，SEAL 不泛化地增加任务难度或多样性，而是根据当前 agent 已经暴露出的 executable failure types 定向调整接口。因此它形成闭环：policy 暴露能力缺口 → diagnosis 汇总 failure profile → interface 和 policy update 同时改变 → 下一轮 rollout 产生新的 failure profile。

Figure 1 解读：图中对比了三种 self-evolution 形态。只更新 agent 的方法会面对固定环境，容易受稀疏 reward 和自分布 rollout bias 限制；只更新 environment 的方法可能没有对齐当前 agent 的真实失败；SEAL 则用 verifier-grounded diagnosis 把 agent side 与 environment side 连成闭环。注意这里的 environment adaptation 只发生在 training-time interface，而不是修改 benchmark verifier 或 tool semantics。

3. Method (方法)

3.1 Overall framework：闭环 co-evolution 训练循环

SEAL 面向 interactive tool use，把一条任务视作 partially observable decision process： $M = ⟨ S, A, O, T, O_{E}, H, S_{goal} ⟩ .$ 给定 instruction $q \sim D$ ，policy $π_{θ}$ 与 executable environment $E$ 交互生成 rollout： $τ = {(u_{i}, a_{i}, o_{i})}_{i = 1}^{T} \sim P_{E} (\cdot ∣ q, π_{θ}), T \leq H,$ 其中 $u_{i}$ 是 dialogue context， $a_{i}$ 是模型 action， $o_{i}$ 是 environment observation。verifier $V$ 只给 terminal binary reward： $r (τ) = V (τ, q, E) \in {0, 1} .$ 标准 RL 最大化 $J (π_{θ}) = E [r (τ)]$ ，但这个目标只回答“成功了吗”，不回答“为什么失败”。SEAL 因此把训练反馈扩展成 $(r (τ), Z (τ))$ ：reward 仍由原始 verifier 决定， $Z (τ)$ 是从执行轨迹中抽取的 structured failure diagnoses。

Figure 2 解读：SEAL 的训练循环包含四步：当前 agent 在可执行 tool environment 中生成 multi-turn trajectories；每条 trajectory 被 verifier 打分并被诊断为若干 failure types；failure profile 同时驱动两条路径——训练接口演化与 diagnosis-guided trajectory weighting；policy 再用 weighted advantages 做 GRPO 更新。图的关键不是“多加一个 reward model”，而是同一诊断信号同时改变下一轮环境接口和本轮 policy update 的优化压力。

直觉上，SEAL 把 sparse binary reward 变成“仍然守住原始 verifier 的可执行证据链”。例如模型把 city name 填到 airport code 参数里，终端 reward 只会给失败；SEAL 会把这类失败标成 argument mismatch，并在后续训练接口中更显式地暴露 required arguments / enum constraints，同时在 policy update 中提高这类可归因失败轨迹的学习权重。这样做的价值是：模型没有看到 reference trajectory 或 final answer，但能看到“这类错误该从 schema/constraint/recovery 角度修”。

3.2 Verifier-grounded failure diagnosis

对每条 rollout $τ$ ，SEAL 生成 turn-level diagnostic labels： $Z (τ) = {z_{1}, \dots, z_{T}}, z_{i} \in Z .$ 每个 $z_{i}$ 表示第 $i$ 轮的主导 outcome / failure mode。诊断函数写作： $z_{i} = Ψ (a_{i}, ξ_{i}, s_{i - 1}, s_{i}, F),$ 其中 $a_{i}$ 是模型 action， $ξ_{i}$ 是 parser / schema / execution / verifier evidence， $s_{i - 1}, s_{i}$ 是可获得的前后状态， $F$ 是工具集合。 $Ψ$ 是 deterministic rule-based classifier，优先使用可执行证据，而不是让 LLM 自由评论失败原因。论文强调：诊断不改 reward，仍然满足 $r (τ) = V (τ, q, E), Z (τ) = Ψ (τ, E, V) .$ 诊断优先级来自 appendix：当同一 turn 有多个 failure signals 时，按直接可执行失败优先于 downstream verifier failure 的原则分配 dominant label。

Priority	Label	含义
1	`invalid_tool_call`	action 无法 parse 或调用了不存在的 tool
2	`argument_mismatch`	tool 合法，但 required field、type、enum value 或 argument structure 错
3	`state_mismatch`	action 执行了，但未产生 expected observable state transition
4	`recovery_failure`	模型收到 executable error feedback 后，后续 turn 仍未恢复
5	`missing_tool_call`	模型跳过必要 tool use 或过早给最终回答
6	`response_mismatch`	tool interaction 大体可接受，但 final answer 未通过 verifier

这个优先级避免把早期具体 tool/argument 错误简单归到最终 response mismatch。例如，若 final verifier fail 是因为前面一个 tool call 参数错，SEAL 会记录 argument_mismatch，从而让后续 interface 与 advantage weight 都围绕可修复的错误类型调整。

3.3 Learning-interface evolution：只改训练接口，不改测试环境

SEAL 只演化 training-time learning interface。令 $o_{i}$ 为原始 observation，SEAL 构造增强 observation： $\tilde{o}_{i} = Ω_{t} (o_{i}, F, H_{t}, C_{t}),$ 其中 $H_{t}$ 是历史诊断上下文， $C_{t}$ 是最近 rollouts 汇总出的当前 policy failure profile。实现上， $Ω_{t}$ 由三类轻量组件拼接： $Ω_{t} (o_{i}, F, H_{t}, C_{t}) = o_{i} \oplus ϕ_{schema} (F) \oplus ϕ_{err} (o_{i}, H_{t}) \oplus ϕ_{cap} (C_{t}) .$

$ϕ_{schema}$ ：暴露 tool schema implied affordances，例如 required arguments、enum constraints、argument types、valid tool-call formats。appendix 中 active BFCL 配置使用 observation_lite，把参数描述加上 [required] 或 allowed values，但不泄漏正确 tool choice / hidden parameter / reference trajectory。
$ϕ_{err}$ ：论文描述为把 parse / execution errors 转成 recovery-oriented feedback；released bfcl_env.py 中存在 _enrich_parse_error 与 _enrich_tool_response_text 实现，但当前 exp/SEAL.yaml 没有启用 tool_feedback_evolution，所以主 released recipe 的 active interface evolution 主要是 observation_lite schema annotation。
$ϕ_{cap}$ ：论文描述为根据当前 failure profile 选择 capability-specific cues；released code 中闭环 capability state 主要进入 A-Patch dynamic tag weights，而不是显式实现 interface.evolve / aggregate_failure_profile 这样的接口演化函数。

这种 interface evolution 的边界非常保守：它不改变 tool API、tool signatures、tool outputs、verifier behavior、task labels，也不在 evaluation 时保留 wrapper。换句话说，训练时给模型更清楚的学习信号，测试时仍回到原始 benchmark interface，用以判断 policy 是否真正 internalized better tool-use behavior。

3.4 Diagnosis-guided advantage reweighting

SEAL 的 policy-side 改动不是替换 GRPO，而是在 GRPO group-relative advantage 上做 diagnostic preconditioning。对 trajectory $τ_{j}$ ，先把 turn-level labels 汇总成 empirical diagnostic profile： $p_{j} (z) = \frac{1}{T _{j}} \sum_{i = 1}^{T_{j}} 1 [z_{i} = z], z \in Z .$ 再定义 utility function $ρ : Z \to R_{+}$ ，衡量某类诊断是否 actionable / attributable。trajectory-level diagnostic weight 为： $w_{j} = clip (\sum_{z \in Z} p_{j} (z) ρ (z), w_{m i n}, w_{m a x}),$ 其中论文实验使用 $[w_{m i n}, w_{m a x}] = [0.5, 2.0]$ 。最后把原 GRPO advantage $A_{j}$ 改成： $A_{j} = w_{j} A_{j} .$ 重要性质： $w_{j} > 0$ ，所以它不改变 advantage 的符号，不改变 verifier-induced ranking；verifier reward 仍决定 update direction，diagnosis 只决定“这条轨迹多值得学”。appendix 给出的 utility weights 包括：spurious_tool_call 2.0、correct_abstention 1.8、empty_turn_model_response 1.5、state_mismatch 1.0、response_mismatch 0.9、instance_mismatch 0.6、pass 1.0。直观上，越直接、越可归因的失败权重越高，越模糊、越下游的失败权重越低。

3.5 SEAL training algorithm

每轮 $t$ ，SEAL 用当前 interface $Ω_{t}$ 实例化训练环境，当前 policy $π_{θ_{t}}$ 采样 trajectories： ${τ_{j}}_{j = 1}^{N} \sim P_{E_{Ω_{t}}} (\cdot ∣ π_{θ_{t}}) .$ 每条 trajectory 用原始 verifier 得到 $r (τ_{j})$ ，并用 $Ψ$ 得到 $Z (τ_{j})$ 。诊断集合被聚合为 failure profile： $C_{t} = Agg ({Z (τ_{j})}_{j = 1}^{N}) .$ 随后更新 interface 与 policy： $Ω_{t + 1} = Evolve (Ω_{t}, C_{t}),$ $θ_{t + 1} = GRPO (θ_{t}; {τ_{j}, r (τ_{j}), A_{j}}_{j = 1}^{N}), A_{j} = w_{j} A_{j} .$ 下面伪代码按 released code main@a0d22dba 的实现重写。论文中的 Algorithm 1 是概念流程；代码中最直接对应的是三条链路：multi_turn_progress.py 产生 BFCL per-turn tags，env_manager.py 把这些 tags 写入 rollout extras，apatch.py 按 tag distribution 缩放 batch advantages。

论文公式与 released code 实现差异：论文 Table 5 使用 invalid_tool_call、argument_mismatch、recovery_failure、missing_tool_call 等诊断标签；released code 的 A-Patch 实际消费的是 multi_turn_progress.py 的 BFCL progress tags：spurious_tool_call、correct_abstention、empty_turn_model_response、state_mismatch、instance_mismatch、response_mismatch、checker_error、gt_error、pass。因此，代码不是把 Table 5 labels 逐一映射到 Table 6，而是在 BFCL grader 的 progress vocabulary 上实现 diagnosis-guided weighting。

import torch
 
TAG_WEIGHTS = {
    "spurious_tool_call": 2.0,
    "correct_abstention": 1.8,
    "empty_turn_model_response": 1.5,
    "state_mismatch": 1.0,
    "response_mismatch": 0.9,
    "instance_mismatch": 0.6,
    "pass": 1.0,
}
EXCLUDE_TAGS = {"checker_error", "gt_error"}
 
 
def compute_per_turn_failure_tags(model_turns, ground_truth_turns, state_checker, response_checker):
    """Paper Z(tau), implemented in env_service/environments/bfcl/multi_turn_progress.py."""
    failure_tags = []
    for model_turn, gt_turn in zip(model_turns, ground_truth_turns):
        if gt_turn.is_irrelevant:
            failure_tags.append("spurious_tool_call" if model_turn.called_tools else "correct_abstention")
            continue
        if not model_turn.called_tools:
            failure_tags.append("empty_turn_model_response")
            continue
        if model_turn.instance_set != gt_turn.instance_set:
            failure_tags.append("instance_mismatch")
            continue
        try:
            state_ok = state_checker(model_turn, gt_turn)
        except Exception:
            failure_tags.append("checker_error")
            continue
        if not state_ok:
            failure_tags.append("state_mismatch")
            continue
        try:
            response_ok = response_checker(model_turn, gt_turn)
        except Exception:
            failure_tags.append("checker_error")
            continue
        failure_tags.append("pass" if response_ok else "response_mismatch")
    return failure_tags
 
 
def trajectory_scale(failure_tags, tag_weights=TAG_WEIGHTS, min_scale=0.5, max_scale=2.0):
    """Released A-Patch scale in agentevolver/module/tocf/apatch.py."""
    effective = [tag for tag in failure_tags if tag not in EXCLUDE_TAGS]
    if not effective:
        return 1.0
    raw_scale = sum(tag_weights.get(tag, 1.0) for tag in effective) / len(effective)
    return float(min(max_scale, max(min_scale, raw_scale)))
 
 
def apply_apatch_advantage_weighting(batch, config, capability_state=None, global_step=None):
    """In-place advantage scaling for samples carrying extras['bfcl_failure_tags']."""
    advantages = batch.batch["advantages"]
    extras = batch.non_tensor_batch.get("extras") or []
    scales = torch.ones(advantages.shape[0], dtype=advantages.dtype, device=advantages.device)
    tag_weights = dict(TAG_WEIGHTS)
    if capability_state is not None and config.tocf.advantage.apatch.dynamic.enable:
        tag_weights = capability_state.update_dynamic_tag_weights(
            tag_weights,
            min_scale=config.tocf.advantage.apatch.min_scale,
            max_scale=config.tocf.advantage.apatch.max_scale,
            ema_beta=0.25,
            prevalence_alpha=1.0,
            confidence_samples=32,
        )
    for idx, extra in enumerate(extras):
        tags = extra.get("bfcl_failure_tags") if isinstance(extra, dict) else None
        if tags:
            scales[idx] = trajectory_scale(tags, tag_weights)
    advantages.mul_(scales.unsqueeze(-1))
    return batch
 
 
def seal_train_step(trainer, gen_batch, tasks):
    # ae_ray_trainer.py: rollout through ParallelEnvManager; BFCL env applies
    # active train-only observation_lite from exp/SEAL.yaml during sampling.
    trajectories = trainer.env_manager.rollout(tasks, mode="sample")
    if trainer.tocf_stats is not None:
        trainer.tocf_stats.observe(tasks, trajectories, trainer.epoch, trainer.global_steps)
 
    # env_manager.py copies bfcl_dense_progress_info["failure_tags"] into
    # extras["bfcl_failure_tags"], so the RL batch carries verifier-grounded tags.
    batch = build_grpo_batch_from_trajectories(gen_batch, trajectories)
    batch = compute_grpo_advantages(batch, adv_estimator="grpo", num_repeat=8)
 
    if apatch_enabled(trainer.config):
        batch, metrics = apply_apatch_advantage_weighting(
            batch=batch,
            config=trainer.config,
            env_type=trainer.config.env_service.env_type,
            capability_state=trainer.tocf_state,
            global_step=trainer.global_steps,
        )
        trainer.metrics.update(metrics)
    return trainer.actor_update(batch)

3.6 Released code mapping

Code reference: main @ a0d22dba (2026-05-25) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
Full SEAL recipe / launch config	`exp/SEAL.yaml`	GRPO config, BFCL env config, `tocf.feedback.dense_reward`, `tocf.advantage.apatch`
Training entrypoint	`launcher.py`, `agentevolver/main_ppo.py`	`python launcher.py --conf exp/SEAL.yaml`, PPO/GRPO trainer setup
TOCF trainer integration	`agentevolver/module/trainer/ae_ray_trainer.py`	loads `TOCFCapabilityState`; observes TOCF stats after rollout; calls `apply_apatch_advantage_weighting` after GRPO advantages are computed
BFCL executable environment + train-only interface	`env_service/environments/bfcl/bfcl_env.py`	`BfclEnv`, `_apply_observation_lite`, `_enrich_parse_error`, `_enrich_tool_response_text`
Per-turn verifier-grounded progress tags	`env_service/environments/bfcl/multi_turn_progress.py`	`compute_per_turn_progress`, `safe_compute_progress`
Dense BFCL grader and progress metadata	`agentevolver/module/task_manager/rewards/bfcl_dense_env_grader.py`	`BfclDenseEnvGrader.calculate_reward`
Passing failure tags into RL batch extras	`agentevolver/module/env_manager/env_manager.py`	rollout extras include `bfcl_failure_tags` from `bfcl_dense_progress_info`
Diagnosis-guided advantage weighting	`agentevolver/module/tocf/apatch.py`	`_trajectory_scale`, `apply_apatch_advantage_weighting`
Closed-loop capability / dynamic tag statistics	`agentevolver/module/tocf/state.py`, `agentevolver/module/tocf/stats.py`	`TOCFCapabilityState`, `update_dynamic_tag_weights`, trajectory stats collectors
Released BFCL data split	`data/bfcl_train.parquet`, `data/bfcl_eval_400.parquet`, `data/bfcl_400_split.json`	train/eval split files

论文公式与 released code 实现差异：除了上面提到的 label vocabulary 差异，训练配置也有一个需要注意的差异。论文 Appendix Table 4 写默认 backbone 为 Qwen2.5-7B-Instruct、GPU memory utilization 为 0.6；released exp/SEAL.yaml 当前写的是 actor_rollout_ref.model.path: Qwen/Qwen3.5-4B 与 gpu_memory_utilization: 0.4。此外，paper-level “interface evolves from failure profile” 在 released main recipe 中没有对应的 interface.evolve 函数；当前 active code path 是 train-only observation_lite schema annotation + TOCF stats/state + dynamic A-Patch weights。bfcl_env.py 虽然包含 parse/tool feedback enrichment code，但 exp/SEAL.yaml 未启用 tool_feedback_evolution。因此本笔记的实验结果仍按论文表格解释，但复现实验时应以 exp/SEAL.yaml 作为代码锚点，并确认作者是否后续更新过配置。

4. Experimental Setup (实验设置)

4.1 Datasets and splits

In-distribution benchmark：BFCL V3 multi-turn subset，共 800 examples，覆盖 4 类：Base、Missing Functions、Missing Parameters、Long Context。论文采用 low-resource setting：400 training examples（每类 100），remaining 400 用于 held-in evaluation。
Out-of-distribution benchmarks：BFCL V4 的 Web Search 与 Memory；以及 $τ^{2}$ -bench 的 Retail、Airline、Telecom domains。这些 held-out benchmarks 与 BFCL V3 在 tool domains、schema structure、interaction patterns 上不同，用来检验 transfer。

4.2 Models and baselines

SEAL 在三类 3B—8B backbone 上训练：Qwen2.5-3B-Instruct、Qwen2.5-7B-Instruct、ToolACE-2-Llama-3.1-8B。Qwen models 代表 general instruction-tuned agents；ToolACE-2 是更强的 tool-specialized initialization。

受控 baseline 是 Vanilla RL：同一 initial checkpoint、同一 400-sample split、同一 rollout budget、同一 optimizer family、同一 decoding configuration、同一 verifier reward。论文也报告 Gemini-3-Pro-Preview、Claude-Sonnet-4.5、GPT-4o-2024-11-20、Gemini-2.5-Flash、GLM-4.6 355B、Qwen3-32B、Qwen2.5-14B-Instruct、xLAM-2-3b-fc-r、BitAgent-8B、watt-tool-8B 等作为 reference points，但这些模型的规模和训练 recipe 不同，不是严格 controlled baselines。

4.3 Evaluation metrics

所有表格主要报告 success / accuracy percentage。BFCL V3 分为 Average、Base、Miss Func、Miss Param、Long Context；BFCL V4 分为 Avg.、Web Search、Memory； $τ^{2}$ -bench 分为 Avg.、Retail、Airline、Telecom。Figure 3 的 validation curves 按 training steps 报告 BFCL V3 四个 100-sample validation subsets 的 validation accuracy，shaded region 是 binomial standard error。

4.4 Training config

主 BFCL 配置以 released exp/SEAL.yaml 为代码锚点：train_files=data/bfcl_train.parquet，val_files=data/bfcl_eval_400.parquet，train_batch_size=32，max_prompt_length=8192，max_response_length=4096；algorithm.adv_estimator=grpo，use_kl_in_reward=false；rollout.name=vllm、mode=async、training temperature 1.0、validation temperature 0、rollouts per prompt 8、max_model_len=16384、tensor_model_parallel_size=1、max_env_worker=32；actor LR $1 \times 1 0^{- 6}$ ，kl_loss_coef=0.001，entropy_coeff=0，PPO micro-batch size / GPU 1，PPO mini-batch size 8，clip_ratio=clip_ratio_low=clip_ratio_high=0.2、clip_ratio_c=10.0；multi-turn enabled，format llama3_json，max steps 20；trainer 使用 4 GPUs、1 node、total_epochs=6、test_freq=10。SEAL-specific switches 包括 observation_lite.enable=true、apply_to_validation=false、required/enum hints enabled，tocf.feedback.dense_reward.enable=true、mode=capped、partial_credit_cap=0.0，以及 tocf.advantage.apatch.enable=true、min_scale=0.5、max_scale=2.0、dynamic weights enabled。注意：代码当前 actor_rollout_ref.model.path=Qwen/Qwen3.5-4B、gpu_memory_utilization=0.4，与论文 Table 4 的 Qwen2.5-7B-Instruct / 0.6 不完全一致。

5. Experimental Results (实验结果)

5.1 BFCL V3 in-distribution：400 samples 下稳定超过 Vanilla RL

Model / training	Average	Base	Miss Func	Miss Param	Long Context
Qwen2.5-3B-Instruct	5.75	11.00	6.00	3.00	3.00
+ Vanilla RL	9.25	16.00	9.00	6.00	6.00
+ SEAL	14.00	19.00	15.00	12.00	10.00
Qwen2.5-7B-Instruct	14.00	22.00	14.00	10.00	10.00
+ Vanilla RL	30.75	46.00	27.00	27.00	23.00
+ SEAL	40.25	58.00	36.00	34.00	33.00
ToolACE-2-Llama-3.1-8B	32.00	45.00	26.00	35.00	22.00
+ Vanilla RL	38.50	52.00	30.00	40.00	32.00
+ SEAL	46.75	58.00	46.00	44.00	39.00

相对原始 checkpoints，SEAL 在三种 backbone 上分别带来 +8.25、+26.25、+14.75 average-point gains；相对受控 Vanilla RL，分别再提升 +4.75、+9.50、+8.25 points。最能说明机制有效的是 Qwen2.5-7B：Missing Functions 从 14.00% 提到 36.00%，Missing Parameters 从 10.00% 提到 34.00%，正好对应 SEAL 重点诊断和修复的 tool selection / argument constraint 错误。ToolACE-2 已经是 tool-specialized model，SEAL 仍把 average 从 38.50 提到 46.75，说明收益不只来自弱模型“补基础格式”。

参考模型中，Claude-Sonnet-4.5 为 61.38 average，Gemini-3-Pro-Preview 为 60.75，GLM-4.6 355B 为 68.00，xLAM-2-3b-fc-r 为 58.38；这些不是受控 baseline，但提供了当前 BFCL V3 multi-turn 的 broader performance range。

5.2 OOD generalization：BFCL V4 与 $τ^{2}$ -bench 均有 transfer

Model / training	BFCL V4 Avg.	BFCL V4 Web Search	BFCL V4 Memory	$τ^{2}$ Avg.	Retail	Airline	Telecom
Qwen2.5-3B-Instruct	4.69	0.00	9.38	9.64	5.26	14.00	9.65
+ Vanilla RL	5.98	0.50	11.26	10.60	6.14	16.00	9.65
+ SEAL	8.63	2.00	15.26	11.76	8.77	16.00	10.52
Qwen2.5-7B-Instruct	9.17	6.50	11.83	16.11	16.67	20.00	11.67
+ Vanilla RL	10.26	7.50	13.02	17.19	19.30	20.00	12.28
+ SEAL	12.71	9.50	15.92	20.79	26.32	22.00	14.04

SEAL 只用 BFCL V3 的 400 training samples 训练，却在 held-out BFCL V4 和 $τ^{2}$ -bench 上提升。Qwen2.5-3B 的 BFCL V4 Avg. 从 4.69 到 8.63， $τ^{2}$ Avg. 从 9.64 到 11.76；Qwen2.5-7B 的 BFCL V4 Avg. 从 9.17 到 12.71， $τ^{2}$ Avg. 从 16.11 到 20.79。说明 SEAL 学到的不只是 BFCL V3 的具体 task distribution，而是更通用的 schema-following、missing-tool recovery、argument repair 与 multi-turn state tracking 行为。

5.3 Ablation：三个组件都重要

Variant on Qwen2.5-7B	Average	Base	Miss Func	Miss Param	Long Context
Qwen2.5-7B-Instruct	14.00	22.00	14.00	10.00	10.00
+ Vanilla RL	30.75	46.00	27.00	27.00	23.00
SEAL w/o Environment-Side Adaptation	35.75	52.00	31.00	32.00	28.00
SEAL w/o Diagnosis-Guided Reweighting	32.75	48.00	27.00	31.00	25.00
SEAL w/o Closed-Loop Update	33.00	46.00	32.00	28.00	26.00
Full SEAL	40.25	58.00	36.00	34.00	33.00

去掉 Environment-Side Adaptation 后 average 为 35.75，说明只用 diagnosis reweighting 还不够，训练接口必须暴露更有用的 cues。去掉 Diagnosis-Guided Reweighting 后 average 32.75，说明只改 interface 不足以把优化压力集中到高价值轨迹。去掉 Closed-Loop Update 后 average 33.00，说明 failure profile 需要随 policy 能力变化动态更新；固定一次性诊断无法跟踪能力边界。Full SEAL 40.25 是三个组件协同后的结果。

5.4 Learning dynamics：更快、更稳地拉开差距

Figure 3 解读：四个 validation subsets 中，SEAL 相对 Vanilla RL 更快上升并达到更高 final accuracy，尤其在 Missing Functions 与 Missing Parameters 上 gap 更明显。Base 任务两者早期都提升，但 SEAL 稳定在更高水平；Long Context 仍是最难 subset，但 SEAL 曲线更持续上行。这支持论文的解释：当 policy 的主要失败类型变化时，SEAL 会更新 interface 来暴露更相关 cues，而 Vanilla RL 仍只依赖稀疏 terminal signal。

5.5 Limitations 与结论

论文明确指出三点限制。第一，SEAL 依赖 executable environments，需要 tool schemas、execution traces 和 verifier feedback；更 open-ended 的任务可能没有足够结构化的诊断证据。第二，environment evolution 刻意保守，只改 training-time interface，不改 tool semantics 或 evaluation rules；这保证公平，但也限制了 adaptation 范围。第三，diagnostic utility weights 当前跨 task / backbone 固定，未来可学习 adaptive weights；同时 cross-domain generalization 仍然 challenging。

总体结论是：tool-use agent 的改进不应只看 policy optimizer，也应看训练环境是否能随 agent 的 failure profile 变化而变化。SEAL 的实验证明，verifier-grounded failure diagnosis 可以同时作为 interface evolution 和 policy optimization 的共享信号，在 400-sample low-resource 设定下显著提高 multi-turn tool-use learning，并在不同 held-out tool domains 上保留正向迁移。

Paper Notes

探索

SEAL: Synergistic Co-Evolution of Agents and Learning Environments

SEAL: Synergistic Co-Evolution of Agents and Learning Environments

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 Overall framework：闭环 co-evolution 训练循环

3.2 Verifier-grounded failure diagnosis

3.3 Learning-interface evolution：只改训练接口，不改测试环境

3.4 Diagnosis-guided advantage reweighting

3.5 SEAL training algorithm

3.6 Released code mapping

4. Experimental Setup (实验设置)

4.1 Datasets and splits

4.2 Models and baselines

4.3 Evaluation metrics

4.4 Training config

5. Experimental Results (实验结果)

5.1 BFCL V3 in-distribution：400 samples 下稳定超过 Vanilla RL

5.2 OOD generalization：BFCL V4 与 $τ^{2}$ -bench 均有 transfer

5.3 Ablation：三个组件都重要

5.4 Learning dynamics：更快、更稳地拉开差距

5.5 Limitations 与结论

目录

Paper Notes

探索

SEAL: Synergistic Co-Evolution of Agents and Learning Environments

SEAL: Synergistic Co-Evolution of Agents and Learning Environments

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 Overall framework：闭环 co-evolution 训练循环

3.2 Verifier-grounded failure diagnosis

3.3 Learning-interface evolution：只改训练接口，不改测试环境

3.4 Diagnosis-guided advantage reweighting

3.5 SEAL training algorithm

3.6 Released code mapping

4. Experimental Setup (实验设置)

4.1 Datasets and splits

4.2 Models and baselines

4.3 Evaluation metrics

4.4 Training config

5. Experimental Results (实验结果)

5.1 BFCL V3 in-distribution：400 samples 下稳定超过 Vanilla RL

5.2 OOD generalization：BFCL V4 与 τ2-bench 均有 transfer

5.3 Ablation：三个组件都重要

5.4 Learning dynamics：更快、更稳地拉开差距

5.5 Limitations 与结论

目录

5.2 OOD generalization：BFCL V4 与 $τ^{2}$ -bench 均有 transfer