Apache Burr: 信頼できるAIエージェントとアプリケーションの構築

 (burr.apache.org)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Apache Burrは、シンプルなチャットボットから複雑なマルチエージェントシステムまで、意思決定型AIアプリケーションをPythonで構築するためのフレームワーク
  • アプリケーションはアクションと遷移の集合として定義され、DSLやYAMLなしにPython関数とデコレータで記述される
  • Burr UIは実行ステップごとの監視・デバッグ・追跡を提供し、状態変化をリアルタイムで確認できる
  • 状態をディスク、データベース、カスタムバックエンドに保存し、中断地点から再開できるほか、人間の入力待ちや並列実行もサポートする
  • OpenAI、Anthropic、LangChain、FastAPI、PostgreSQLなど既存ツールと統合でき、ロックインやラッパーなしで利用可能

信頼できるAIエージェントとアプリケーションの構築

  • Apache Burrは、意思決定を行うアプリケーション開発を容易にするApache Incubating Project
  • 対象範囲は単純なチャットボットから複雑なマルチエージェントシステムまで広がる
  • 実装方式は純粋なPythonで、「no magic」を掲げている
  • 公開指標としてGitHub Stars 1,641件、PyPI Downloads 379k+、Discord Members 457+が表示されている

シンプルで強力なPython API

  • Burrは、チャットボットからマルチエージェントシステムまで構成できる組み合わせ可能なインターフェースを提供する
  • サンプルコードではburr.coreのaction、State、ApplicationBuilderを使ってchatアクションを定義する
  • @action(reads=["messages"], writes=["messages"])は、読み取る状態と書き込む状態を指定する
  • ApplicationBuilder()は、アクション、遷移、初期状態、ローカルトラッカーを設定した後にアプリケーションをビルドする
  • 実行例ではapp.run(halt_after=["chat"], inputs={"llm_client": client})の形でLLMクライアントを入力として渡す

AIアプリケーション構築に必要な要素

  • Simple Python APIは、アプリケーションをアクションと遷移の集合として定義し、DSLやYAMLなしでPython関数とデコレータのみを使う
  • Built-in Observabilityは、Burr UIによってアプリケーションの全ステップをリアルタイムで監視、デバッグ、追跡できるようにする
  • Persistence & State Managementは、状態をディスク、データベース、カスタムバックエンドに自動保存し、中断地点から再開できるようにする
  • Human-in-the-Loopは、どの段階でも実行を停止して人間の入力を待てるため、承認ワークフローや対話型エージェントに適している
  • Branching & Parallelismは、並列アクション実行、fan out / fan in、複雑なDAG構築、サブアプリケーションの組み合わせをサポートする
  • Testing & Replayは、過去の実行の再生、個別アクションの単体テスト、状態遷移の検証を通じてAIシステムへの信頼を高める

既存スタックとの統合

  • Burrは、すでに使用しているツールやフレームワークに統合でき、ロックインやラッパーを必要としない
  • LLM統合項目としてOpenAI、Anthropic、Instructorが表示されている
  • フレームワーク統合項目としてLangChain、Hamilton、Haystackが表示されている
  • UIとサービングの統合項目としてStreamlitとFastAPIが表示されている
  • 検証とストレージの統合項目としてPydanticとPostgreSQLが表示されている
  • 統合一覧全体はドキュメントで確認できる

開発者とチームの利用体験

  • Peanut Roboticsのレビューでは、複数のLLMフレームワークを評価した結果、Burrの状態管理がAI意思決定ベースのロボット配備に対する強力な答えだったと評価している
  • Watto.aiのレビューでは、モジュール型AIアプリケーションを作りやすく、UIがデバッグを容易にすると評価している
  • Paxton AIのレビューでは、AIだからといって奇妙で難解な概念を使わない点を強調している
  • Provectusのレビューでは、状態スナップショット生成、デバッグ、再生、評価ケース構築においてBurrの状態管理が有用だと評価している
  • CognitiveGraphsのレビューでは、LangChain、CrewAi、AutoGen、Agency Swarmなど複数のagentic LLMプラットフォームと比べて、Burrが複雑な動作設計により堅牢なフレームワークを提供すると評価している
  • TaskHumanのレビューでは、LangChainからBurrへ移行した後、数時間で使い始められ、コードベース全体をBurrへ切り替えたと評価している

コミュニティとプロジェクトの状態

  • コミュニティは、支援要請、プロジェクト共有、Burrの将来への貢献のための場として構成されている
  • 参加経路はDiscord、GitHub、Twitter / Xで提供されている
  • プロジェクトリソースは、ドキュメント、サンプル、YouTube、ロードマップ、変更ログにつながっている
  • Apache BurrはApache Software Foundationでインキュベーション中のプロジェクトであり、Apache Incubatorが支援している
  • インキュベーション状態はコードの完成度や安定性を必ずしも反映するものではないが、ASFの完全承認をまだ受けていないことを示している

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsのコメント

  • エージェントフレームワークについてはまだ判断を保留しており、エージェントの性質によって有用性が変わる。たとえば、3秒以内に十分に良い応答を返す必要がある場合と、1つの問題を3時間かけて解かなければならない場合では異なる。
    結局のところ、エージェントはコンテキスト構成、LLM呼び出し、要求されたツール呼び出しの実行、最終的なモデル出力のパース、フロントエンドへの返却に要約される。メモリや非同期ツール呼び出しのような拡張はあるが、従来のソフトウェアエンジニアリングの観点ではそれほど複雑ではない。
    誰もが自分のエージェントフレームワークを作りたがるが、特定のエージェントを作る必要があるなら、そのエージェント向けに調整した1対1のコードのほうがはるかに簡単で、保守性も良いと思う。フレームワークの抽象化は中核ロジックを隠して邪魔することが多く、結局はフレームワークが選んだ抽象化に合わせなければならず、実際の目標とずれることがある。

    • エージェント型システムの核心はエージェントを使うことではなく、本当に必要なときだけ使うことにあると思う。動くシステムには、多段階フローを表現するパイプライン/レシピ、複数のエージェントワーカープールでモデルと人の介入ステップを安定して実行する運用基盤、できるだけ多くのことをコードで処理する厚いスキルの管理・配布・セキュリティ・権限、適切なセッションに適切なコンテキストを入れるコンテキスト管理が必要だ。
      そのほかにも、チケット・依存関係・進捗・停止したチケットの再開を扱うプロジェクト管理、会話履歴の保存とメモリ・ドリーミング・累積学習機能、コストと利用量を見るオブザーバビリティ、プロンプト評価と自動調整、モデルプロバイダーの切り替えとモデルバージョン固定、実際のセッションを動かすサンドボックスが必要になる。
      それらをすべて1つのベンダーから受け取る必要はないが、ほとんどの場合、単一のモデルプロバイダーに閉じ込められないこと、そして自分のコンテキストと累積学習は自分で所有することが重要だと思う。
    • ほとんどのエージェントフレームワークで最も深刻な点は、中核ロジックを隠してしまうことだ。実際に言語モデルへ何が送られ、何が返ってくるのかを明確に見せるべきだ。
      エージェント型アプリケーションのあらゆるものは、結局トークン列やプロバイダー呼び出しとして実現されるので、アプリのほぼすべての層でその姿が明瞭であるべきだ。
    • 数十個ものフロントエンドフレームワークに対しても同じように感じていた。将来やって来そうで結局来ない見返りのために、巨大な抽象化と複雑さを背負い込ませるやり方だ。
      それでも人はやることや面白いおもちゃを必要としていて、「次の人」のことはたいていあまり重要視されないので、有給の遊び時間の産物を押し付けても構わないと考えているようだ。
    • 特定のエージェント向けに1対1のコードを作るというやり方にはある程度同意する。ただ、新しいエージェントで新しい手法や方式を作ったとき、古いエージェントをどう更新するか、そして更新したいのかどうかは、保守の観点で悩ましい。
      たとえば Apache Burr はプラグイン可能なベクトルRAGシステムをサポートしている、あるいは今後サポートしそうだが、自分が必要としているのは、文書をコンテキストに追加し、更新されたシステムプロンプトの一部として維持しつつ、その過程に非常に具体的な調整を入れる方式だ。これは既存概念であるRAGをカスタム利用するやり方で、特定のフレームワークにはあまり合わない。
      自分の用途ではカスタム実装が適しているが、古いエージェントを更新するためのエンジニアリング上の選択は依然として残っている。
    • フレームワークの利点は、実際のエージェント記述が簡単になることではなく、ツールやオブザーバビリティなどにある。LangChain も批判される点は多いが、この点は初期から非常に明確に示していた。
      チャットボットを最初から自作するのは簡単か、むしろより簡単かもしれないが、オブザーバビリティやトレーシングを追加しなければならなくなると話は変わる。環境変数を1つ追加するだけで、ほぼ追加作業なしにUIですべてのトレースを眺められるなら、自作の解決策では太刀打ちしにくい。

  • このページが https://vorpus.github.io/performativeUI/ で作られているのか気になる。
    できる限りあらゆるAI生成ランディングページの典型的なクリシェを踏んでいる。あるいは、わざと風刺しているのかとも思う。

  • 個人プロジェクトと業務プロジェクトでこのフレームワークを好んで使っている。AIモデル向けの信頼できる状態を持つワークフローと無料のオブザーバビリティが得られるのが良かった。
    Burrの状態機械をMCPとしてマウントするツールと組み合わせていて、エージェントに従うべきレールを与えつつ、状態機械がどれほど複雑になってもMCPツールは状態機械の探索に制限される: https://github.com/msradam/theodosia
    今はスキルを状態機械へ変換する作業を進めている。人気のある多くのスキルはすでにAIモデルが従うステップの形で書かれているので、Burrの明示的な機能を活用すれば、より安定したものにできそうだ。

  • https://strandsagents.com/ と比べてどうなのか気になる。この分野のツールには関心があり、まだ特定のツールに縛られてはいないが、Bedrock + Serverless on Agent Core は「簡単な導線」のように感じる。ただし、プラットフォーム依存は好ましくない。

    • 別の利用経験も知りたい。このスタックを使っているが、Strands が Agent Core と組み合わせて特別な秘訣を提供しているのかは疑問が残る。
      今のところそうは感じられず、ときには両者が互いに衝突しているように見えることすらある。

  • ここではビルダーパターンとデコレータが見られる。Pythonにもデコレータはあるが、関数やメソッドに適用する「フィルタ」として使うのが最も適切だと思う。この関数はキャッシュし、この関数の出力は常にシリアライズし、この関数をエージェント型実行装置のツールとして準備する、といった使い方である
    登録やフロー制御に使うものではないと思う。異論はあるかもしれないが、誰かが言わなければならない。FastAPIがモダンなデコレータの使い方をあまりにも誤った方向へ引っ張ってしまった
    ビルダーパターンはRustに名前付きキーワード引数がないことから生まれた慣習に近く、Pythonの関数はすでに名前付きの契約を公開している。設定パラメータをメソッドの連鎖呼び出しで順番に渡す理由はほとんどない
    コンストラクタやファクトリにまだ存在しない状態を追加しなければならないなら、それはビルダーパターンではなく登録である。ビルダーパターンを許容できる場所はクエリビルダくらいだと思う。概念を反復的に積み上げていき、メソッド名とキーワード引数というメタデータスロットが実際に有用だからである。キーワード引数の代わりに単一引数を取るメソッドを使うのは間違いだと思う

    • ここでのデコレータは、具体的には関数にメタデータを付与して再利用可能なコンポーネントにし、ビルダはワークフローを作る。Hamiltonでは純粋に宣言的な構成なので全てデコレータで処理するが、再利用性は実際には別問題である
    • ビルダーパターンがRustでしか使われないわけではないが、Pythonで使うには不格好だという点には同意する

  • 信頼できるAIエージェントとは何かについて、かなり素朴なバージョンに見える
    信頼性とは「任せた仕事を完了できるか」を意味するのであって、状態機械とは特に関係がない

  • Burrは初めて聞いたが、なぜApacheでインキュベーションされたのか気になる

    • だめな理由はない。ASFには新しい自由オープンソースプロジェクトをインキュベーションしてきた長い歴史がある
      一部は卒業して誰もが知る名前になり、一部は失敗してattic行きになる。ASFは組織的な支援を提供し、たいていは良いコミュニティを育ててくれる
    • 私が提出したからである。Apacheの手続きを学びつつ他の仕事も並行していたので遅いプロセスだったが、今ではある程度の勢いがつき、より定期的なリリースを始めている

  • ページがClaude Codeで作った使い捨てのゴミのように見え、JavaScriptなしで動かそうという試みすらない。少なくともブランドの一貫性はある

  • 名前の明示的な由来は見つけられなかったが、気になる人のためにHamiltonの例がある: https://github.com/apache/burr/tree/main/examples/multi-agen...

    • Burrは、アメリカ建国の父であり第3代副大統領、そしてAlexander Hamiltonの殺害者であり宿敵でもあるAaron Burrに由来する名前である
      Hamiltonとのつながりは、DAGWorksがHamiltonライブラリに続いて公開した2つ目のオープンソースライブラリだという点にある。BurrとHamiltonが調和し、違いを乗り越えてより良い連邦を作っていたらどうなっていただろう、という発想から付けた名前である
      もともとBurrはHamiltonのDAG実行の間にある状態を扱う仕組みとして作られた。DAGには循環がないからである。その後、適用範囲がより広いことに気づき、より広く公開した
      https://pypi.org/project/burr/

  • コーディングエージェントのオーケストレーションツールやプラットフォームで、おすすめできるものがあるか気になる。複数のマシンでcodexやclaudeエージェントを実行・管理・監視したい
    できればセルフホスト可能、またはオープンソースだとうれしい。claude codeが内部的にそうした機能を多く持っているのは分かっているが、claude専用である

    • ドキュメントを見ると、Burrにはこれを始められるエージェントクックブックがあり、複数マシンのワークフローも扱えるようだ。探していたのはこれではないかと思う
      スキルなどとどう統合して使うのかははっきりしないが、見たところ動きそうだ
      https://burr.apache.org/docs/examples/agents/