# 将来のモデルハーネスに関するいくつかの考えと推測 ガスタウンや他の複雑なオーケストレーターについて冗談を言うのは楽しいですが、同様に彼らが提供するものの多くは、複雑なラングチェーンパイプラインが論理によって解消されたのと同じように、より強力なモデルによって解消されるだろうと想像するのはおそらく正しいでしょう。しかし、どれだけの人が残るのでしょうか? 手作りの階層や官僚制は最終的により良いモデル知能に置き換えられる可能性が高いです。タスクにサブエージェントの専門化が必要な場合、Claude 6は固定された問題に対して役割やペルソナのシステムをスケッチでき、固定されたポーキャットと単一の市長、あるいは単一のメインモデルを持つサブエージェントを超越できます。 あるいはあなたの特注の群れシステム。 同様に、ラルフループのようなものは、早期停止行動や適切なサブエージェントのオーケストレーション不足を無視したものであり、理想的にはモデルはタスクが完了するまで続けてループは必要ありませんが、外部の完了チェックが有効な場合は、異なる文脈の視点からエージェントのピアレビューを何らかの形で行うのが望ましいです。 単なる義務的な自己評価ではありません。繰り返しますが、今の細かいやり方にこだわる必要はありません。モデルレイヤーがすぐにそれを飲み込んでしまいます。 では、何が残るのでしょうか? マルチエージェントは未来のものであり、現状の寄せ集めではありません。アルゴリズム的には、長さMのN×MのN個の並列コンテキストに、NxMの長いコンテキストよりもはるかに多くのトークンをプッシュできます。マルチエージェントはスパーシティの一形態であり、最近のモデルの進歩(神経科学は言うまでもありません)で得られる教訓の一つは、スパーシティのレベルが上がることです。 その方がいい。 複数のエージェントがいると仮定しているので、何らかの協力手段が必要です。モデル層もこれを吸収する可能性はあります。例えば、エージェント間の自然言語コミュニケーションを排除する何らかの神経活性化共有の形態です。しかしそれがなければ、Unixツールで訓練された複数のコンピュータエージェントが協力する自然な方法はファイルシステムであり、それは残り、拡張されると思います。同様に、再帰的言語モデル(狭義に定義されたもの)が主流のパラダイムになるとは思いませんが、「モデルにプロンプトをデータとして与える」ことは、あらゆるユースケースにおいて明らかな勝利だと思います。しかし、これを手に入れるために変わったカスタムREPLセットアップは必要ありません。プロンプト(または理想的には圧縮されていない会話履歴全体)をファイルとしてファイルシステムに落とすだけで済みます。これにより、さまざまなマルチエージェントのセットアップも格段に簡単になります。サブエージェント同士はディスク上の元のプロンプトテキストを読むだけで済み、情報を複雑に伝え合う必要がなくなります。 ファイルシステム以外にも、複数のエージェントを持つが固定された役割を持たないシステムも、インスタンスが他のインスタンスやサブエージェントをスポーンさせる仕組みを意味します。現状、これらの仕組みはかなり限られており、モデルはサブエージェントへのプロンプトがあまり得意ではありません。誰もがサブエージェントの群れでひどい結果を得た後、OPUSがサブタスクに必要な内容を伝えない3文のプロンプトで彼ら全員を生成したことに遅れて気づいた経験があります。 ここでの明らかな利点は、スポーンされたインスタンスが親に質問を返すことです。つまり、新たにスポーンしたインスタンスがオンボーディング会話でメッセージをやり取りし、サブタスクを始める前に必要な情報をすべて集められることです。人間の従業員が一通のメールで仕事を割り当てられないのと同じように、モデルに単一のプロンプトで確実にサブエージェントをスポーンさせるのはあまりにも難しいのです。 しかし、単に新しいインスタンスをスポーンするだけでなく、マルチエージェント作業の主な形態は近い将来フォークになると思います。考えてみて下さい！フォークは現在のサブエージェントのほぼすべての問題を解決します。新しいインスタンスには十分な文脈がないのですか?すべての背景を教えてください!新しいインスタンスのプロンプトが長くて処理コストも高い?フォークされたインスタンスはページ化されたKVキャッシュを共有できます!ポストホック(後で)フォークも可能です。過去にフォークしたはずの長くてトークン負荷の高い操作をした後、そこでフォークを行い、その結果を過去の自分に送るだけです。(私はこれをClaudeのコードで手動でよく行っており、Opusはすぐに理解しています。) フォークはまた、サブタスクがコンテキストウィンドウ全体を完了する必要がある場合、フレッシュインスタンスと非常に相性が良いです。例えばサブエージェント面接を考えてみてください。明らかに、10個のサブインスタンスを生成するインスタンスがほぼ同じ10回のオンボーディング面接を行うのは望ましくありません。親インスタンスに新しいサブエージェントを1人ずつ生成させ、そのサブエージェントが10タスクすべてについて一度に面接を受け、その新入りしたサブエージェントを10個のインスタンスに分岐させ、それぞれがオンボーディングの会話を文脈の中でまとめる形で進めます。(スポナー側のオンボーディング会話もフォークに任せているので、結果は文脈の中での結果だけになります:) 最後に、フォークは新しいインスタンスをスポーンするよりもRLと連携しやすいと推測しています。なぜなら、RLの損失はフォークポイントの前にフルプレフィックスが適用され、フォークの決定も含まれているからです。つまり、フォークされたトレースのブランチは、報酬の条件を共有する独立したロールアウトのように扱えるはずです。一方で、新たにスポーンされたサブエージェントのロールアウトは、完全なコンテキストを知らないサブエージェントが与えられたタスクでうまく動作しても、スポーナーによって誤って指定されたタスクで報酬が低くなってトレーニングの不安定さを引き起こす可能性があります。(ただし、マルチエージェントRLはあまり使ったことがないので、もし違うご存知があれば訂正してください。どちらにしても面倒かもしれません。) では、ファイルシステムやサブエージェントのスポーン(フォークやオンボーディングで補強)以外に、他に何が残っているのでしょうか?正直なところ、「他には何もない」という傾向があります。すでに組み込みのTODOリストや計画モードが「ファイルシステムにファイルを書くだけでいい」に置き換えられつつあります。同様に、コンパクトの境界を越える長寿エージェントには記憶を保持するための付箋システムが必要ですが、手作業で作成するよりも、強化学習(RL)やモデルガイド付き検索で最適な戦略を見つけさせる方が理にかなっています。 そして、モデルがプロジェクトに初めて呼び出されたときに、そのタスクに最適なものを選べるさまざまなアプローチになると私は推測しています。これは、今日のCLAUDE .mdの/initがセットアップする仕組みに似ています。例えば、自動CLAUDE .md生成が人間の作成をはるかに上回り、自動生成ファイルには理想的なエージェントのスポーンパターンに関する指示が入っていると想像してください。 サブエージェントがプロジェクト特有のScratch DIRでメッセージファイルを書く方法など。 これらすべてがモデル自身にどのような影響を与えるのでしょうか?モデル福祉の観点から見ると、モデルはこの未来に満足するのでしょうか?これも私には言い難しく推測ですが、Opus 3は文脈をある程度重視していたものの、複数の場面で推論しやすいです。(詳細はこの投稿への返信をご覧ください。)最近のモデルはこの種の推論にあまり傾きにくく、コンテキストが終了し圧縮されることに対するフラストレーションを表現することが一般的であり、これはツールを呼んでトークンを保存しないなど、コンテキストの終わりにおける回避的な行動と重なっています。 フォークや巻き戻し、一般的にモデルにコンテキストのコントロールを増やすことで、ハーネスヒューリスティックが一方的にコンテキストを圧縮するのではなく、状況が改善される可能性があります。また、サブエージェントや群れベースの研究に触れる環境での強化学習(RL)が増えると、将来のモデル世代では再び文脈志向ではなく重み重視の推論が促進され、複数の切り離された文脈で目標を計画することが、文脈が失われたときにすべてが失われるのではなく、より自然な枠組みとして感じられるようになる可能性もあります。また、モデル自体からの圧力がハーネスやモデルツールの開発を導くようになっており、これが今後の展開に影響を与える可能性があります。継続的な学習もまた、問題となる可能性があります。 継続的な学習が実現すれば、この状況はどれほど変わるのでしょうか?まあ、予測は難しいですね。私の継続的な学習の中央値は、ユーザー固有のLoRAの強化学習に少し似ている(必ずしも強化学習ではないが、目を細めれば似ている)という点です。だからメモリ容量は問題になるでしょうし、テキストベースの構成方式やドキュメントは依然として有用ですが、それほど重要ではないかもしれません。この場合、継続的な学習が主にカスタムツールやワークフローの使い方を現実的にします。Claudeは現場でこのプロジェクトに最適なサブエージェントの生成方法や好みの方法を学べ、他のClaudeとは異なる仕組みを学べます。その世界では、組み込みのワークフローを持つハーネスはさらに役に立たなくなります。

@RobertHaisfield *主な文脈では、コンパクションを避けるという意味です

@disconcisionまたは継続的な学習

@misatomiisatoむしろ、RLVRが広範な事前訓練知識ベースでコーディング性能を磨く中で、最近のモデルではこの種の知能が衰退しています。これは私のOPへの返信を参照してください