これでダウンボートされるのは覚悟のうえで言いますが、まあ始めましょう。過去6か月、課金してくれる顧客向けに、本番環境で約30個のエージェントを動かしてきましたが、フレームワーク論争はほとんど注意を逸らすものだと確信しています。
LangChain、CrewAI、AutoGen、OpenAI Agents SDK。チームがすでに知っているものを選べばいいです。それが思うほど重要ではありません。
実際にエージェントが本番で動くかどうかを決めるのは、このサブでほとんど誰も話題にしない何かであり、フレームワークにはありません。
ここで、すべてのフレームワークのバグを合わせたよりも多くのエージェントを殺してきた（＝失敗させてきた）ものを挙げます。
エージェントがループに陥ります。同じツールを4分で200回呼びます。下流で曖昧なデータが返ってきた何かのせいで、LLMが「永遠にリトライする」と判断してしまうからです。OpenAIの請求額が、1日の$3から午後のうちに$400になります。気づいた時には、もう一気に1,000ドルを燃やしている。しかも監査トレイルがないので、どのエージェントがやったのかさえ特定できません。
カーネルパッチのためにVPSが夜間に再起動されます。進行中のタスクがあるエージェントはすべて失います。明日の朝、サポート担当のエージェントは昨日のチケットを覚えていない。調査チームは何を調べていたか忘れている。パイプライン担当のエージェントは最初からやり直し。これらはどれもフレームワークの問題ではありません。メモリと状態の問題です。
ある顧客が、3日前にエージェントが間違った情報を渡したとクレームします。あなたがデバッグしに行く。エージェントが何を見て、何を判断し、どのツール呼び出しをしたかが記録されていません。フレームワークがログを取っていないのは、フレームワークは観測性（オブザーバビリティ）のためのツールではないからです。あなたは肩をすくめて返金します。
15個のエージェントを連携させる形でスケールしました。同じ顧客について、2つのエージェントが互いに矛盾する信念を持っています。彼らのメモリが共有されていないからです。同じ会話の中で、どのエージェントが先に返答したかによって、顧客は2通りの答えを受け取ります。
十分な回数この状況を見てきたので、実際に必要なのはフレームワークの部分ではないと分かりました。
私が思う本当のスタックはこうです。
フレームワークは単にLLM呼び出しをオーケストレーションしているだけです。チームが好きなものを使えばいいです。それは安い層です。
永続的なメモリ層。クラッシュや再起動、デプロイをまたいで生き残るので、エージェントに実際の継続性があります。エージェントが玩具なのか製品なのかを決めるのは、この層です。
ラッパーとしてフレームワークに後付けするのではなく、ランタイム層でのループ検知。同じ呼び出しをあまりにも多い回数、連続で行っているのを捕まえて、請求が爆発する前に止めるような仕組みです。
エージェントが行ったあらゆる意思決定の監査トレイル。ハッシュチェーンを使うことで、あとから顧客が反論してきたときに何が起きたかを証明できます。1万ドルが絡むと、スクリーンショットやログだけでは不十分です。
同じチーム内のエージェント間でメモリを共有し、同じ顧客について別々の会話をしてしまわないようにすること。
エージェントごとのコスト追跡。どれがあなたの予算を勝手に持っていったのかを本当に把握できるようにすること。
本番で生き残るエージェントと、死んでしまうエージェントの違いを見ていると、「正しいフレームワークを選んだかどうか」では決してありません。下に、この層がちゃんと入っていたからです。自社で丁寧に作り込むか、どこかから借りてきたかのどちらか。
完全な開示ですが、私はこの種のツールを1つ作っています。他にもあります。メモリ領域ではMem0やZepやLetta。観測性の領域ではHeliconeやLangSmith。組み合わせてもいいし、自分で作ってもいい。ただ、あなたの本番エージェントを食い荒らしている“原因”がLangChainかCrewAIかのどちらかと無関係なときに、どっちが優れているか議論するのをやめてください。
あなたの一番ひどい本番エージェントの失敗は何でしたか？ 他の人が実際にぶつかったことを知りたいです。
この問題の大半を解決することを目指した無料ツールを作りましたが、どう思いますか？
[link] [comments]
