エージェントネイティブ・トレーニングは、質問応答からタスク完遂へ：エージェントシステムとハーネス設計に関するサーベイ が示すエージェントエンジニアリングの 4 つのパラダイムのうち 4 番目のものであり、プロンプトエンジニアリング、ワークフローとコンテキストエンジニアリング、ハーネスエンジニアリングに続く。これには 2 つの方向性がある。1 つ目は内在化である。プロンプト、ワークフロー、実行時のオーケストレーションだけに頼るのではなく、対話的な環境でモデルを訓練し、計画を立て、ツールを使い、中間状態を検証し、エラーから回復できるようにする。こうして、最初は外部で実装されていた振る舞いが、次第に部分的にモデルの内部で学習されたものになりうる。2 つ目は共進化である。デプロイを通じて、モデル、ハーネス、改善ループのいずれもが、何を維持し、何を変え、何を元に戻すべきかを示す実行トレースから更新されうる。このサーベイは、これがハーネスをなくすものではないと明言している。設計上の問いは、エージェントの振る舞いのうちどれだけをモデル内で学習させ、どれだけをランタイムに残すか、そしてスタック全体を時間をかけてどう安全に改善していくか、という方向へ移るのである。
用法
内在化について、このサーベイは近年の研究に見られる 2 つの傾向を区別している。1 つは、強化学習を通じて推論から行動への振る舞いを強化することであり、多段階の推論、行動選択、検証を、純粋にプロンプトで引き出すものではなく訓練可能なものとして扱う。もう 1 つは、デプロイ環境により近い環境でエージェントを訓練することで、訓練時とテスト時のずれを減らすことである。サーベイはその総体的な効果を、ハーネスの除去ではなく役割分担の移行として特徴づけている。短期的な振る舞いはより多くがモデルのパラメータへ移る一方で、環境へのアクセス、状態、安全性の制御は引き続きランタイムが担う。
共進化について、このサーベイは有用な抽象化として、制約付きの自己進化ループを提示している。エージェントを実行するとトレースが生まれ、システムはそこから結果、失敗モード、検証器の結果、コストプロファイル、安全性イベントからなる証拠集合を抽出する。次に更新オペレータがモデル、ハーネス、あるいはその両方を変更しうる。その結果は、ホールドアウトタスク、回帰テスト、プロセスチェック、安全性制約をすべて通過した場合にのみ保持され、そうでなければ却下またはロールバックされる。サーベイはこれを固定されたアルゴリズムとしてではなく、制御構造を明示するための方法として示している。信頼できる自己進化には、経験の抽出、功績の割り当て（クレジットアサインメント）、変更、検証を結びつけることが不可欠だというのである。
このサーベイは、「自己進化」という言葉のもとでしばしば混同される 3 つの層を区別している。マルチモデル・ハーネスは各ランタイム役割を誰が担うかを定め、学習可能なハーネスはランタイムのポリシーをどのように最適化するかを定め、共進化はモデル、ハーネス、改善ループをデプロイ時の経験からいつ、どのように一体的に更新するかを定める。サーベイはこれらを互いに置き換え可能なものではなく、補完的なものとして扱っている。
適用される場面
これはサーベイが確立された実践ではなく今後の課題として位置づけている方向性である。そのパラダイム図では、ハーネスエンジニアリングが現在の最前線、共進化を伴うエージェントネイティブ・トレーニングが将来のものとして示されている。またサーベイは、現時点では 4 つのパラダイムすべてが実践の中で共存していることも指摘している。サーベイが描くループでは、証拠集合は実行トレースから抽出されるため、このパラダイムは、結果、失敗モード、検証器の結果、コストプロファイル、安全性イベントを含むトレースがあることを前提としている。
サーベイは、このパラダイムに特有のリスクとして、ベンチマークへの過剰適合、誤った失敗の帰属、古くなったメモリ、安全でない実行時の変更を挙げている。ベースモデルを固定し、可観測性に基づくフィードバックからコーディングエージェントのハーネス構成要素を進化させるある引用システムの主要な教訓として、サーベイは、自己進化は観測可能かつ反証可能でなければならないと報告している。すなわち、構成要素は明示的で元に戻せるものであるべきであり、トレースは証拠へと蒸留されるべきであり、提案される変更は後の結果によって確認できる予測を立てるべきである。さらにサーベイは、エージェントネイティブ・トレーニングはハーネスを訓練環境、証拠パイプライン、検証器、ガバナンス層へと変えるものであり、ホールドアウト評価、アブレーション、監査ログ、ロールバック、影響の大きい変更に対する人間の承認を伴う、と付け加えている。また、多くの失敗は観測の形式、行動の粒度、メモリ検索、検証器のタイミングといったハーネス上の選択から生じるため、パラメータの更新だけではランタイムのボトルネックをすべて吸収することはできない、とも注意を促している。