AIエージェントのためのコンテクスチュアル・エンジニアリング：マヌスからの最前線の経験

ある Manus オープンソースのモデルをベースにエンドツーエンドのエージェントモデルをトレーニングするのか、それとも最先端モデルの強力な「コンテキスト学習」機能を活用してエージェントを構築するのか。

10年前に戻ると、開発者は自然言語処理の分野で選択肢すら持っていなかった。自然言語処理が BERT の時代には、どんなモデルでも、新しいタスクのために何週間も微調整と評価を行わなければならない。迅速な反復を求め、まだ製品市場適合性（PMF）を見出していないアプリケーションにとって、この遅いフィードバック・ループは致命的となりうる。これは、オープンな情報抽出と意味検索のためにモデルをゼロからトレーニングしていた前回のスタートアップから学んだ厳しい教訓であった。 GPT-3 歌で応える Flan-T5 こうした自己研究モデルの出現は、ほとんど一夜にして淘汰された。皮肉なことに、文脈学習の時代を切り開き、まったく新しい道を指し示したのは、こうした新しいモデルだった。

このレッスンのおかげで Manus コンテキスト・エンジニアリングに賭けるのだ。これによって、製品の改善サイクルは数週間から数時間に短縮され、製品そのものは基礎となる大きなモデルの開発と「直交」したままとなる。モデルの進歩が上昇気流であれば、それは上昇気流であり、製品そのものは上昇気流である。Manus 海底に固定されたポールではなく、水上のボートになること。

しかし、コンテクスチュアル・エンジニアリングは順調とは言い難い。むしろ実験科学に近い。Manus エージェントフレームワークは、チームがコンテキストを形成するためのより良い方法を発見するたびに、4回にわたって完全に作り直された。この手動プロセスは、アーキテクチャの検索、キューワードのデバッグ、経験的な推測をミックスしたもので、チームでは「確率的卒業降下」と名付けている。

この記事では、チームが「SGD」によって達成した局所最適解を紹介する。もしあなたが独自のAIエージェントを構築しているのであれば、これらの原則がより早く収束させる手助けになることを願っている。

KVキャッシュ周辺の設計

インジケータが1つしか選択できない場合は KV キャッシュヒット率は、レイテンシとコストに直接影響するため、プロダクショングレードのAIエージェントを測定するための最も重要な指標であることは間違いない。これを理解するためには、まず典型的なエージェントがどのように動作するかを理解する必要がある。

ユーザー入力を受け取ると、エージェントは一連のツール呼び出しを通じてタスクを完了する。各反復において、モデルは、環境で定義された現在のコンテキストに基づいて、事前に定義された行動空間から行動を選択する（たとえば Manus の)がVMサンドボックスで実行され、オブザベーションを生成する。その後、振る舞いと観察結果はコンテキストに追加され、次の反復の入力となる。このループはタスクが完了するまで続く。

各ステップでコンテキストが大きくなる一方、出力（通常は構造化された関数呼び出し）は 比較的短いことは明らかです。これは、通常のチャットボットとは対照的に、エージェントの入力と出力のトークンの比率に深刻な不均衡をもたらします。通常のチャットボットとは対照的です。 Manus その比率は平均で約100：1である。

幸いなことに、同じ接頭辞を持つコンテキストは KV キャッシュメカニズム。KV キャッシングは、計算された Key-Value ペアを保存し、同じプレフィックスを再度処理する計算オーバヘッドを劇的に削減することで、最初のトークン生成時間（TTFT）と推論コストを大幅に削減します。これは、セルフホストモデルを使用する場合でも、推論 API を呼び出す場合でも、大きなコスト削減となります。取る Claude Sonnet たとえば、キャッシュされた入力トークンのコストは100万トークンあたり0.30ドルであるのに対し、キャッシュされていないトークンのコストは100万トークンあたり3ドルと、10倍の差がある。

コンテクスチュアル・エンジニアリングの観点からは KV ヒットをキャッシュするには、いくつかの重要なプラクティスがある：

1.キュー単語の接頭辞の安定性を保つ。 大規模な言語モデルの自己回帰的な性質により、1つのTokenの違いでも、そのToken以降のすべてのキャッシュが無効になる可能性がある。よくある間違いは、システムプロンプトの最初に秒単位のタイムスタンプを入れることである。これによってモデルは現在時刻を知ることができますが、キャッシュヒットを完全に破壊することにもなります。

2.文脈を「加法的」にする。 以前の動作や観察を修正することは避けてください。また、直列化プロセスが決定論的であることを確認すること。多くのプログラミング言語やライブラリは、JSONオブジェクトをシリアライズするときに、キーの安定した順序を保証しません。

3.必要に応じて、明示的にキャッシュのブレークポイントをマークする。 モデルベンダーや推論フレームワークによっては、プレフィックスの自動インクリメンタルキャッシュをサポートしておらず、手動でコンテキストにキャッシュのブレークポイントを挿入する必要があります。ブレークポイントを設定する際には、キャッシュの有効期限を考慮し、少なくともブレークポイントにシステムプロンプトの終了時刻が含まれていることを確認してください。

さらに、もし vLLM などのフレームワークのセルフホストモデルでは、 プレフィックス/ヒントキャッシュが有効になっていることと、 セッション ID などのテクニックを使って分散したワーカーノード間で リクエストが一貫してルーティングされていることを確認してください。

除去の代わりにマスク

エージェントの能力が高まるにつれて、その行動空間は当然複雑になり、はっきり言ってツールの数は爆発的に増える。最近流行しているモデルコンテキストプロトコル（MCP）は、さらに火に油を注ぐことになる。ひとたびユーザーがツールを設定できるようになれば、誰かがあなたの注意深くキュレーションした行動空間に詰め込むことができる、奇妙で奇抜なツールが常に何百と存在することになる。その結果、モデルは間違ったツールを選択したり、非効率的な経路を取ったりする可能性が高くなり、重武装のエージェントは「間抜け」になってしまう。

即座の対応策のひとつは、たとえば次のようなものを使って、ダイナミックな行動空間をデザインすることだ。 RAG(Retrieval Enhancement Generation）技術のオンデマンド・ローディング・ツール。Manus このアプローチも試みられたが、実験から得られた結論は明確である。イテレーションの途中でツールを動的に追加したり削除したりすることは、絶対に必要でない限り避けるべきである。これには2つの理由がある：

1.ツールの定義は通常、コンテキストの先頭にあります。 ほとんどの大規模言語モデルでは、ツール定義はシステムヒントに即座に従うようにシリアライズされている。そのため、変更があれば、その後のすべての動作と KV キャッシュの無効化。

2.モデルは混乱を招くことがある。 以前の行動や観察が、現在のコンテキストにもはや存在しないツールを参照している場合、モデルは混乱する可能性があります。制約のデコードがない場合、これはしばしばフォーマットエラーやモデルが存在しないツール呼び出しを幻視することにつながります。

この問題に対処するためだ。Manus はツールを削除しないが、ツールの可用性を管理するためにコンテキストを認識する ステートマシンを使用する。これは、デコードフェーズ中に特定のトークンのロジットをマスキング（覆い隠す）することで、モデルが現在の状態に基づいて特定のアクションを選択することを防止または強制する。

実際には、ほとんどのモデルベンダーと推論フレームワークは、何らかの形でレスポンスのプリポピュレーションをサポートしており、ツールの定義を変更することなく、行動空間を制約することができる。取る NousResearch な Hermes フォーマットを例にとると、通常3つの関数呼び出しモードがある：

• 自動（オート）： 関数を呼び出すかどうかは、モデル自身が決めることができる。あらかじめ <|im_start|>assistant 実現。
• 必要だ： モデルは関数を呼び出さなければならないが、どの関数を呼び出すかは特に制限されていない。あらかじめ <|im_start|>assistant<tool_call> 実現。
• 指定された： モデルは、指定されたサブセット内の関数を呼び出さなければなりません。これは、関数名の先頭にプリポップすることで実現されます。 <|im_start|>assistant<tool_call>{"name": “browser_.

このメカニズムを使用すると、トークンのロジットをマスクすることで、アクションの選 択を制約することが簡単にできる。例えば、ユーザーが新しい入力をするとManus はアクションを実行するのではなく、即座に反応しなければならない。チームはまた、アクション名を一貫性のある接頭辞で意図的にデザインした。 browser_ で始まるコマンドラインツールで始まる。 shell_ を開始する。これにより、ステートフル・ロジット・ハンドラーを使用することなく、エージェントに特定のツールセットのみを選択させることが容易になります。

このような設計により、モデル駆動型アーキテクチャであっても、以下のことが保証される。Manus プロキシのサイクルは安定している。

ファイルシステムをコンテキストとして使う

最近の最先端の大規模言語モデルは、128Kまたはそれ以上のコンテキストウィンドウを提供しますが、実際のエージェントアプリケーションのシナリオでは、これはしばしば十分ではなく、時には負担になることさえあります。主な問題点は3つあります：

1.観測値は非常に大きくなる可能性がある。 エージェントがウェブページやPDFなどの非構造化データを扱う場合、コンテキストの長さの制限を超えることは容易である。

2.モデルの性能は、コンテキストの長さが長くなるにつれて低下する。 技術的にサポートされていても、モデルの性能はある長さを超えると低下する傾向がある。

3.長いインプットのコストが高い。 プレフィックス・キャッシュを使用しても、開発者は各Tokenの送信と事前投入のための費用を支払う必要がある。

これらの問題に対処するために、多くのプロキシシステムはコンテキストの切り捨てや圧縮戦略を採用している。しかし、過度に積極的な圧縮は、必然的に情報の損失につながる。これは根本的な問題である。エージェントは、以前のすべての状態に基づいて次の動きを予測する性質があり、10歩先のどの観察が後で重要になるかを確実に予測することはできない。論理的には、不可逆的な圧縮にはリスクが伴う。

だからManus ファイルシステムは無限の容量を持ち、本質的に永続的で、エージェントが直接操作できる。このモデルは、ファイルシステムをストレージとしてだけでなく、構造化された外部メモリとして使用し、必要に応じてファイルを読み書きすることを学習します。

Manus の圧縮戦略は常に復元可能なように設計されている。例えば、ウェブページのコンテンツは、URLが保存されている限り、コンテキストから破棄することができる。また、ドキュメントのコンテンツは、ファイルパスがサンドボックスに残っている限り、省略することができる。これにより Manus 情報を永久に失うことなく、コンテキストの長さを効果的に短くすることができる。

この機能を開発する中で興味深かったのは、状態空間モデル（SSM）がエージェント環境でどのように効率的に機能するか？ということでした。 Transformer SSMとは異なり、SSMはグローバルな注意を欠き、長いバックトラック依存関係を扱うのに苦労する。しかし、もしSSMがファイルベースの記憶（長期的な状態をコンテキストの中に保持するのではなく、外部化すること）を使いこなすことができれば、そのスピードと効率性によって、まったく新しいクラスのエージェントが誕生するかもしれない。その時、エージェント化されたSSMは、ニューラルチューリングマシンの真の後継者になるかもしれない。

再話」による注目の操作。

を使用している場合 Manus複雑なタスクを処理する場合、そのタスクに対応するために、次のような興味深い現象が発生する。 todo.md タスクが進行するにつれて、完了した項目を順次更新し、チェックを入れていく。

これは単に擬人化された行動ではなく、注意を操作する精巧なメカニズムである。

ある Manus 典型的なタスクは平均して約50回のツールコールを必要とし、これはかなり長いサイクルである。これはかなり長いサイクルである。 Manus 意思決定のために大規模な言語モデルに依存すると、長い文脈や複雑なタスクでは、脱線したり、初期の目標を忘れたりしやすい。

ToDoリストを常に書き換えることでManus これは、コンテキストの最後に核となるゴールを「再表明」することと同じである。これによって、グローバルプランがモデルの即時の注意範囲に押し込まれ、効果的に「ロスト・イン・ザ・ミド ル」問題を回避し、ゴールドリフトを減らすことができる。事実上、これは自然言語を使用して、特別なアーキテクチャの変更なしに、モデル自身の注意をタスクゴールに向ける。

失敗の記録を残す

エージェントは間違いを犯す。これは欠陥ではなく、事実である。言語モデルは幻想を作り出し、環境はエラーを返し、外部ツールは誤作動し、あらゆる種類の予期せぬエッジケースが溢れる。マルチステップのタスクでは、失敗は例外ではなく、サイクルの一部なのだ。

トレースをクリーンアップし、アクションを再試行し、モデルの状態をリセットし、魔法の「温度」パラメーターが問題を解決してくれることを期待する。この方が安全でコントロールしやすいように感じますが、それには代償があります。証拠がなければ、モデルは適応も学習もできない。

基礎 Manus 私たちの経験では、エージェントの行動を改善する最も効果的な方法の1つは、驚くほど単純です。モデルが失敗した行動とその結果のオブザベーションやスタックトレースを見ると、暗黙のうちに内部の「信念」を更新し、似たような行動への選好を減らし、間違いを繰り返す確率を減らします。

実際、エラーから回復する能力は、真のエージェント知能の最も明確な指標のひとつである。しかし、理想的な条件下でのタスクの成功のみに焦点を当てがちなほとんどの学術研究や公的なベンチマークテストでは、この能力はまだ著しく過小評価されている。

サンプルレス」の罠に注意

「数発のプロンプト」は、大規模な言語モデルからの出力の質を向上させるための一般的な手法であるが、エージェントシステムでは微妙なところで裏目に出ることがある。

言語モデルは優れた模倣者であり、そのコンテキストの行動パターンを模倣する。もしあなたの文脈に似たような「行動-観察」のペアがたくさんあれば、たとえそれが最良の選択でなくなったとしても、モデルはそのパターンに従う傾向がある。

これは、決断や行動を繰り返す作業では非常に危険である。例えば Manus 20人分の履歴書をまとめて見る場合、エージェントはしばしばリズムに陥ってしまう。これは、行動ドリフト、過度の一般化、時には幻覚さえも引き起こす可能性がある。

解決策は多様性を増やすことだ。Manus 異なるシリアライゼーション・テンプレートの使用、代替表現、順序や形式における小さなノイズなど、少数の構造化されたバリアントが行動や観察に導入された。この制御されたランダム性は、固まったパターンを壊し、モデルの注意を調整するのに役立つ。

言い換えれば、"サンプルレス "のパス依存に陥ることを許してはならない。コンテキストが均一であればあるほど、エージェントの振る舞いは脆弱になる。

コンテクスチュアル・エンジニアリングはまだ新しい科学だが、エージェント・システムにとってはすでに成功の礎となっている。モデルはより強力に、より速く、より安価になるかもしれないが、生のパワーの増加は、メモリ、コンテキスト、フィードバックの慎重な設計に取って代わることはできない。どのようにコンテクストを形成するかによって、最終的にエージェントがどのように行動するか、つまり、どの程度速く動作するか、どの程度回復力があるか、どの程度まで拡張できるかが決まる。エージェントの未来は、次から次へと注意深く設計されたコンテクストから構築される。