今日はハーネスエンジニアリングに関する長文を読みました。数万語に及ぶ、ほぼ間違いなくAIが書いたものです。最初の反応は「わあ、なんて強力なコンセプトなんだ」というものではありませんでした。「この人たちは古い言葉に新しい言葉を作る以外に何かアイデアを持っているのか?」というものでした。 私はAIの世界におけるこのパターン、つまり既存の概念が絶えず再発明されることにずっと苛立ってきました。プロンプトエンジニアリングからコンテキストエンジニアリング、そして今はハーネスエンジニアリングへと進みます。数ヶ月ごとに誰かが新しい用語を作り、1万語のエッセイを書き、大手企業のケーススタディをいくつか取り入れ、コミュニティ全体が盛り上がります。しかし実際に内容を見ると、毎回同じことがわかります。 モデルが動作する環境を設計しましょう — どんな情報を受け取り、どんなツールを使えるか、エラーの捕捉方法、セッション間でのメモリ管理の仕組みなど。これはChatGPTが立ち上げられた日から存在しています。誰かが何らかの理由で新しい名前を付けたからといって、新しい分野になるわけではありません。 とはいえ、不満はさておき、記事で引用されている研究やケーススタディには価値があります。特に、私がhow-to-sglangで構築してきた内容と大きく重なる点が大きいからです。だから、これを機会に私が実際に犯した間違いについて話したいと思います。 まずは背景を説明します。SGLangコミュニティで最もよく聞かれる質問は「ハウツークエスチョン」です。8GPUでDeepSeek-V3をどう展開するか、ゲートウェイがワーカーアドレスにアクセスできない場合の対応、GLM-5 INT4と公式FP8間のギャップが大きいかどうかなどです。これらの質問は非常に広範な技術層に及び、コミュニティがどんどん成長するにつれて、返信に追いつけなくなるほどです。そこで、自動的に応答できるマルチエージェントシステムを作り始めました。 最初のアイデアはもちろん最も素朴なものでした――全知全能のエージェントを一人作り、SGLangのドキュメントやコード、料理本をすべて詰め込み、すべてに答えさせるというものでした。 それはうまくいかなかった。 なぜそうなのかを説明するのにハーネス工学理論は必要ありません。コンテキストウィンドウはRAMではありません。詰め込めば詰め込むほど、モデルの注意が散り散りになり、答えはどんどん悪くなります。エージェントが量子化、PD分解、拡散サービング、ハードウェア互換性を同時に理解しようとすると、どれも深く理解できません。 最終的に決定した設計は、多層的なサブドメインエキスパートアーキテクチャです。SGLangのドキュメントにはすでに自然な機能の境界があり、高度な機能、プラットフォーム、サポートモデルなど、モデルごとに整理された料理本があります。各サブドメインを独立したエキスパートエージェントにし、エキスパートディベーティングマネージャーが質問を受け取り、サブクエスチョンに分解し、エキスパートルーティングテーブルを参照して適切なエージェントを起動し、並列で解決し、回答を統合する役割を担いました。 振り返ってみると、この設計はハーネスエンジニアリングコミュニティが推奨するパターンにほぼ完璧に一致しています。でも作っていた時は、これらのパターンに名前があるとは全く知りませんでした。そして、私はそれをする必要もなかった。 1. プログレッシブ・ディスクロージャー — すべての書類を特定のエージェントに押し付けることはありません。各ドメインエキスパートは自分のドメイン知識のみを読み込み、マネージャーは質問タイプに基づいて誰を起動するかを決定します。私の直感では、この設計はより強力なモデルに交換したよりもはるかに多くの改善をもたらしたと思います。この決定を下すのに「プログレッシブ・ディスクロージャー」と呼ばれるものだと知る必要はありません。一度「全部詰め込む」方法を試して失敗するのを見ればいいのです。 2. リポジトリを真実のソースとして — ワークフロー全体がハウツースグラングリポジトリに保存されています。すべての専門エージェントはリポジトリ内のマークダウンファイルから知識を引き出し、外部文書や口頭の合意に依存しません。初期の頃、すべてを網羅した大規模な sglang-maintain.md を書きたいという衝動がありました。しかし、それがうまくいかないとすぐに分かりました。OpenAIのCodexチームも同じミスを犯しました。巨大な AGENTS.md を一つだけ試みた結果、予測可能な形で腐っていくのを見守ってしまったのです。この地雷を自分で踏みつけるのに、彼らのブログを読んでいなくても十分です。これは「モノリシックなドキュメントは必ず古くなる」という古典的なソフトウェア工学の問題ですが、エージェントの文脈ではその結果はさらに悪化します。古くなったドキュメントは単に読まれないだけでなく、エージェントを誤導します。 3. 構造化ルーティング — エキスパートルーティングテーブルは、問題タイプをエージェントに明示的に割り当てます。GLM-5 INT4に関する質問は、クックブックドメインエキスピクトとクオンタイゼーションドメインエキスピクトの両方を同時に起動させます。マネージャーは推測しない;構造化されたインデックスに従っています。ハーネス工学の人々はこれを「機械化された制約」と呼んでいます。私はこれを通常の工学と呼んでいます。 ハーネス工学の考え方が悪いと言っているわけではありません。引用された研究は堅実で、SWE-agentのACI概念は本当に知っておく価値があり、Anthropicのデュアルエージェントアーキテクチャ(初期化エージェント+コーディングエージェント)は長期的な作業を行う人にとって貴重な参考資料です。私がうんざりするのは、新しい用語が絶えず生まれることです。確立された工学の常識を新しい分野としてパッケージ化し、「この言葉を知らないと遅れている」という不安を作り出すのです。 プロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジニアリング――これらは同じものの異なる側面です。来月、誰かがスキャフォールドエンジニアリングやオーケストレーションエンジニアリングを新たに出し、同じSWEエージェント論文を引用する長いエッセイを書き、コミュニティは新たな増幅のサイクルを始めるでしょう。 実際に「sglangの使い方」から学んだことは、新しい語彙なしでも述べられます:...