Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Exploration collapse: agents converge to fixed policies, losing novel behavior discovery

オープン
#490 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

@Finanzgoblin がすでに取り組んでいます。

2026年2月13日 から。

  • #491 @Finanzgoblin による — オープン

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
20/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
python

調査の方向性

Issue ではファイルやテストが指定されていないため、まずトレーニングループと軌跡キャプチャのエントリポイントである agl.emit_* を特定します。提案を 1 つのメカニズムに絞り、次に公開するメトリクスまたは動作と、既存の報酬追跡を不明瞭にせずに機能することを示す検証を定義します。

索引モデルが issue の本文から書いたものです。

説明

enhancement v0.x

Problem

Agent Lightning's training loop (RL, SFT, prompt optimization) optimizes toward a reward signal. This works well for tasks with stable reward landscapes, but introduces a structural risk: trained agents lose the ability to discover novel behaviors that weren't represented in the reward signal.

This isn't hypothetical — it's a known failure mode in RL literature (reward hacking, policy collapse, mode collapse in generative models), but Agent Lightning doesn't currently surface any mechanisms to detect or mitigate it.

Concrete Engineering Gaps

  1. No exploration decay monitoring
    Once an agent's policy converges, its trajectory diversity drops. Currently there's no metric tracking behavioral diversity over training runs — e.g., how many distinct tool-call sequences the agent explores at epoch N vs epoch 0. Without this, you can't distinguish "agent got better" from "agent got narrower."

Suggested metric: Trajectory entropy over a sliding window. If entropy drops below a threshold while reward plateaus, the agent has likely collapsed to a fixed policy rather than genuinely mastering the task space.

  1. No reward function staleness detection
    The reward signal is assumed to be correct for the duration of training. But in real deployments, the environment changes — APIs evolve, data distributions shift, new capabilities become available. A reward function that was correct last month may be optimizing for a stale objective today.

Suggested mechanism: Periodic reward function auditing. Track correlation between reward signal and downstream task success (measured independently). When correlation degrades, flag the reward function for review rather than continuing to train against it.

  1. No mechanism for productive multi-objective tension
    Many real agent tasks involve competing objectives that shouldn't be collapsed into a single scalar reward. For example:

Speed vs. thoroughness in research agents
Cost vs. quality in code generation
Exploitation of known-good strategies vs. exploration of potentially-better ones
Agent Lightning's current architecture assumes a single reward signal per trajectory. This forces the user to pre-resolve tensions that might be more valuable left as competing objectives.

Suggested approach: Support Pareto-front tracking across multiple reward dimensions. Let the trainer surface the trade-off frontier rather than collapsing it into a weighted sum. This preserves optionality and lets downstream consumers choose their operating point.

  1. No "policy dissolution" mechanism for stale behaviors
    Once a behavior is trained into an agent, there's no structured way to detect that it has become counterproductive and should be unlearned. Fine-tuned behaviors accrete — the agent gets layers of learned policy but never sheds outdated ones.

Suggested mechanism: Attach TTL metadata or validity conditions to trained behaviors. For example: "this prompt optimization was trained against GPT-4o pricing as of 2025-08. Re-evaluate if pricing model changes." The trainer could periodically re-validate policies against their stated conditions and flag stale ones.

  1. Trajectory capture doesn't distinguish novel vs. routine behavior
    agl.emit_*() captures what the agent did and what reward it got. It doesn't capture whether the behavior was novel (first time the agent tried this approach) or routine (repeating a known-good policy). This distinction matters because:

High reward + novel behavior = genuine discovery (should be studied, not just reinforced)
High reward + routine behavior = exploitation (fine, but not learning)
Low reward + novel behavior = exploration (might be valuable signal, currently just negative reward)
Suggested approach: Add an optional novelty flag or auto-compute trajectory similarity to historical traces. Novel high-reward trajectories could be surfaced to the user for analysis rather than just folded into the training batch.

Why This Matters at Scale

The README highlights 128-GPU training and production deployments (Tencent's Youtu-Agent). At that scale, these gaps compound:

Policy collapse is harder to detect across distributed training
Reward staleness affects all replicas simultaneously
Novel behaviors are drowned out by volume of routine trajectories
Multi-objective tensions get resolved implicitly by whoever designed the reward, with no visibility into what was lost

Context

These observations come from building an MCP server where AI agents autonomously discover DeFi strategies. We found that the environment design (what signals agents see, what ambiguity is preserved, what tensions are left unresolved) matters as much as agent optimization for producing useful novel behavior. The failure mode we kept hitting: agents that were "better" by any metric were also more predictable and less likely to find strategies we hadn't anticipated.

主要言語
Python
スター
18.8k
フォーク
1.7k
平均マージ
3日 7時間
マージ済み PR(30日)
11

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/agent-lightning のほかの issue

microsoft/agent-lightning の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。