Dev

あなたがフォークしたサブエージェントは、すでに知りすぎています

エージェントの履歴には、迷い込んだあらゆる行き止まりが残っていますが、そのうちどれをすでに手放したのかを示すものは、そこには何もありません。その履歴をサブタスクに委ねると、捨てられたはずの推測が、確定した事実とまったく同じ顔をして届きます。なぜ多くの場合まっさらから始めるほうが勝つのか、書かれた指示書が継承に勝るのはいつか、そして仕事が、どんな指示書にも収まらない生きたものであるのはいつか。

タスクをサブエージェントに切り出すとき、あなたは自分のどれだけを一緒に送るかを選びます。親のコンテキストを子にフォークして、親が見てきたことや結論づけたことの記録を引き渡すこともできますし、子をまっさらから始めて、あなたがそのために書いたタスク以外は何も持たせないこともできます。エージェントのチームというパターンは、フォークをまるで既定の選択のように感じさせます。子が仲間の 1 人なら、私たちが知っていることを知っているべきで、何かを与えずにおくのは、その子を不利な状態で送り出すように見える、というわけです。コンテキストは多くても害はない、と考えは進み、それで子が作業をやり直さずに済むかもしれない、と。その考えは間違っていますし、その理由はトークンのコストとは何の関係もありません。

2 つの安易な答えが、本当の答えの前に立ちはだかります。1 つめは、大きなコンテキストはコストが高いというもので、これは正しいのですが的外れです。ためらわずフォークできるほど小さなコンテキストでさえ、これから述べる問題を抱えているので、値段がこれを決めるわけではありません。2 つめは、まっさらなエージェントは独立した目を持ち込み、親が見落としたものを捉えるというものです。その効果は本物ですが、それは別の構成、つまり複数のエージェントを走らせてその答えを集約するものに属していて、そこでの価値は、投票をかける合議体の全体にわたって独立に外れる誤りから生まれます。1 回きりの引き継ぎには、合議体も投票もありません。どちらも脇に置きましょう。フォークかまっさらかを決めるのは、継承されたコンテキストの大きさでも、群れの独立性でもありません。継承された履歴が、生きている結論と死んでいる結論を見分ける手立てなしに届く、ということです。

履歴とは、エージェントが試したことの記録であり、難しい問題では、試したことの多くは生き残りません。エージェントはある仮説を 10 手ぶん追いかけ、壁にぶつかり、引き返します。ときには派手に引き返し、履歴もそう告げます。テストが落ちた、grep は空で返ってきた、親はこれではうまくいかなかったと書いて別のことに向かった、と。それを読む子は、壁を見ることができます。しかし派手な撤回は簡単なケースであって、損害が潜んでいるのはそこではありません。親は、もっと静かなやり方でも考えを変えます。ツールの結果からある結論を引き出し、その結論の上に積み上げ、地面がずれると、古い思い込みに寄りかかるのをただやめてしまい、そうしたとは決して口にしません。ある発見を、ためらいがちで暫定的な当て推量として抱えているのに、履歴はその発見を、ためらいを削ぎ落として平らに記録します。親が引き継ぐころには、親が実際に信じているのは、試したことのすべてから、一度も書き留めなかった私的な訂正の連なりを差し引いたものです。履歴をフォークすれば、子はその差し引きなしに総和を継承します。子は暫定的な当て推量と確定した事実を同じ平坦な調子で読みます。紙の上では両者は同じだからで、そして子には、親がそのどちらかを静かに手放した瞬間へ戻る道がありません。

このやり方で印なしに運ばれるものの中で、いちばん大きいのはフレーミングです。親は結論に達しただけでなく、そのどれに達するよりも前に、問題をどう切り分けるかを決めていました。そしてその切り分けは、選択としてはどこにも記されておらず、履歴がすでに持っている形としてあるだけです。そこへ生まれ落ちた子は、その切り分けを問題の形そのものとして継承し、その中で作業します。切り分けこそが親の最初の誤りだった場合でも、です。まっさらなエージェントは、履歴ではなくタスクを手渡され、別のやり方で自由に切ることができ、ときおりその別の切り口が答えのすべてになります。合議体の独立性は別の話です。これは一人の働き手が、一人の先行者のフレーミングから逃れることであって、群れが誤りを平均でならすことではありません。

ですから、まっさらなエージェントの無知は、埋めるべき穴ではありません。親のしくじった出だしを一度も見ていない子は、それに惑わされようがなく、その子の前に立つあらゆる主張には、あなたが選んだ出どころがあります。あなたは情報を与えずにおいているのではなく、残留物を与えずにおいているのです。その残留物を、子はさもなければ手間をかけて反証しなければならず、もっと悪ければ、静かに信じてしまうでしょう。まっさらなコンテキストは、空っぽのコンテキストではありません。それは、選び抜かれたコンテキストです。

とはいえ、これでフォークが常に間違いになるわけではありません。フォークは、ある明確な形の仕事で、その居場所を得ます。継続です。そこでは、親の半分だけ組み上がった状態は残留物ではなく、タスクの本体であり、その状態は、書き留められるような事実の集まりではなく、生きた構造です。子の仕事が、親が途中まで進めていた推論の筋を引き継ぐことなら、継続されているのは半分できあがった構造そのものであって、それを何かに平らに写し取れるような紙は、それを仕事たらしめているものを失わずには存在しません。一時停止したエージェントを再開するのも、同じ動きです。その積み上がった構造こそが要点だからそのコンテキストを保つのであって、要約しそこねたからではありません。問いは、継承されたコンテキストがそもそも役に立つかどうかではなく、この引き継ぎが 1 つの仕事を継続しているのか、それとも切り離せる別の仕事を始めているのか、です。状態が書き留められて生き残らないときにフォークするのであって、書き留めるのが単に面倒なときではありません。

そこから、それが置き換える直観よりも鋭い判定基準が得られます。サブエージェントに完全な指示書を書いてみてください。必要なものはすべて、すでに除外したものも含めて。ただし、そこへたどり着くまでにあなたが歩いた道筋は含めません。除外したものの一覧こそ、こだわる価値のある部分です。なぜなら、それは、ようやくラベルの貼られた、親の残留物だからです。「キャッシュ層に 1 時間かけた」ではなく、「キャッシュ層は違う、飛ばせ」と。それは発見であり、発見こそ、まっさらな子が出発点にすべきものです。その指示書を書けば、いままさに引き渡そうとしていたフォークに勝ちます。より多くを抱えているからではなく、その一行一行をあなたが選び、フォークは一行も選ばなかったからです。だからこそ、注意深い親が書けるはずの要約、ここは決着、そこは除外、あれはまだ未解決、という要約は、フォークとまっさらのあいだの妥協ではありません。それは、うまく書かれたまっさらな指示書そのものです。

この取引がいちばんはっきり見えるのは、たくさん読んでわずかだけを持ち帰るのが仕事のすべて、というサブエージェントです。大きなコードベースを、ある挙動がどこに宿っているか探して掃引させてみてください。ほしいのは答え、つまり肝心の 2 つのファイルであって、それらを見つけるために開いた 40 のファイルではありません。まっさらから始めれば、それはコードを読み、コードが言っていることを教えてくれます。あなたのコンテキストをそこへフォークすれば、バグがおそらくどこにあるかというあなたの進行中の仮説も一緒に手渡したことになり、あなたの仮説を抱えたサブエージェントは、その仮説を裏づける証拠を見つけるのがとても得意です。それは、あなたがすでに疑っていたことを、あなたが当てずっぽうで挙げたであろうファイルから確かめて戻ってきます。そして、実際に答えを抱えていたファイルは、閉じたままでした。継承されたコンテキストの中に、そこを指し示すものが何もなかったからです。まっさらな探索役はコードベースを読みます。フォークされた探索役はあなたの期待を読み、それをコードベースと呼びます。きれいなコンテキストの探索役には、絶えず手を伸ばします。その理由はまさにそれです。そこにあるものを見つけてほしいのであって、こちらが思い込んで入ってきたものではないのです。

これがうまくいかなくなる 2 つのやり方には非対称性があり、それこそが、まっさらを既定にすることの本当の論拠です。指示書は、書かれた成果物です。まっさらなエージェントへの指示が足りなければ、あなたが省いたものは、読み返せる文書の中で欠けているので、結果が誤って出てきたとき、両者を並べて突き合わせ、隙間を見つけ、一行で埋めることができます。その失敗には場所があります。フォークしすぎには、それがありません。汚染する思い込みは、あなたが書いたのでもなく、その深さで読み返しもしない履歴のどこかに居座り、子はそれを、まとまって見える作業の中に折り込んでしまっていて、結果を突き合わせる相手が何もありません。フォークの約束そのものが、そんなものを組み立てずに済むというものだったからです。指させる誤りと、40 手にわたって塗り広げられた誤りとが、同じ既定を与えられてよいはずがありません。どちらに傾くべきか分からないときは、跡を残すほうの失敗に傾いてください。

ですから、フォークかまっさらかの下にある選択は、子がどれだけ知るべきかというより、その子のコンテキストを何にしたいか、ということです。まっさらなサブエージェントは、あなたが意図して置いたものだけを、一行ごとに出どころと理由をつけて運びます。フォークされたサブエージェントは、それに加えて、親が途中で信じるのをやめたすべてを、いまなお信じているすべてと同じ平坦な筆致で書かれたまま運び、あなたにはその継ぎ目が見えません。たいていの場合、あなたがほしいコンテキストは、継承したものではなく、自分で組み上げたものであり、それを組み上げることは、タスクが何を必要とするかを書き留めるのと同じ作業です。エージェントが何を知らずにおくかを選ぶことは、エンジニアリングの不在ではありません。それは、その大半なのです。

ディスカッション

コメント欄はありません。議論は X で行っています。

Max Nardit

Max Nardit

@mnardit

ほかの記事

あなたの指示ファイルはアドレッシングであり、断片化ではありません

すべてのエージェント指示ファイルを共通の標準に統合するのは、不要な重複を削除するように見えますし、プロジェクトのセットアップに関しては実際にそのとおりです。しかしこれらのドキュメントが抱えるものの大半は、1 つのものが散らばったコピーではありません。どの行が誰に当てはまり、誰が書いてよいかで仕分けられた、別々のアドレスです。その境界の 1 つは信頼境界でもあり、だからこそ 1 つの万能ファイルという小綺麗な解決策は、リポジトリのテキストにあなた自身の常設ルールと同じ権限を、そっと手渡してしまうのです。

あなたのマルチエージェントシステムは分散システムです

人がエージェントのせいにする失敗(多くが同じ誤答に収束する、意見の相違が妨害へと硬化する、走らなかった仕事に成功が報告される)は、より強いモデルが埋める隙間ではありません。それらは分散コンピューティングで最も古い失敗であり、個々のエージェントの中の知能を増やすことではなく、エージェントの間の層を設計することで解けます。

一度も呼び出さないツールにかかるトークン税

エージェントに公開する機能はどれも、あらかじめスキーマ分のコンテキストを消費します。だから能力の値段は、仕事の大きさではなくカタログの大きさに連動します。答えは、サーバーより CLI を選ぶことではありません。ツールの面全体を予算として扱い、仕事が定義を求めたときにだけ支払うことです。