Zenn
Closed6

グラフベースでフローエンジニアリングができるエージェントフレームワーク「AgentKit」を試す

LLM
agent
agentkit
kun432kun432

ここで知った。

https://twitter.com/tom_doerr/status/1844164327697416282

GitHubレポジトリ

https://github.com/Holmeswww/AgentKit

AgentKit: コーディングではなく、グラフによるフローエンジニアリング


refered from https://github.com/Holmeswww/AgentKit

AgentKitは、単純な自然言語の指示から複雑な人間の「思考プロセス」を明示的に構築するための統一されたフレームワークを提供する。ユーザーは、レゴブロックを積み重ねるように、ノードのチェーンを組み合わせていく。ノードのチェーンは、自然な構造を持つ「思考プロセス」を明示的に強化するように設計することができる。

ノードの異なる配置により、異なる機能性を表現することができ、ユーザーはさまざまな機能性を統合して多機能エージェントを構築することができる。

基本的なエージェントは、サブタスクのプロンプトのリストとして簡単に実装できるため、プログラミングの経験がなくても、誰でも設計および調整が可能である。

kun432kun432

論文

https://arxiv.org/abs/2404.11483

AgentKit: 動的グラフを用いた構造化LLM推論フレームワーク

どんなもの？

大規模言語モデル(LLM)を使った複雑なタスクを、シンプルな自然言語プロンプトを組み合わせて解決するためのフレームワーク「AgentKit」を提案しています。AgentKitの基本構成要素は「ノード」と呼ばれる単位で、各ノードには特定のサブタスクのためのプロンプトが含まれています。ユーザーはこれらのノードをLEGOブロックのように組み合わせることで、複雑な「思考プロセス」を明示的に構築できます。例えば、論文を書くタスクであれば、1)コアメッセージの特定、2)先行研究のギャップの特定、といった思考プロセスを設計できます。プログラミング経験がなくても、サブタスクのためのプロンプトリストとして基本的なエージェントを実装できる点が特徴です。

先行研究と比べてどこがすごい？

既存のLLMエージェントフレームワーク(Auto-GPT、LangChainなど)には2つの課題がありました。1つ目は手順的な要件への準拠で、例えば自動運転車は安全規則に厳密に従いながら状況に応じた適応が必要です。2つ目はアクセシビリティと使いやすさで、コードベースのエージェントはタスク特化型のAPIプラットフォームに依存し、多くのコード例が必要でした。AgentKitはこれらの課題に対し、自然言語でサブタスクを記述し組み合わせることで、明示的な推論手順に従いながら、プログラミング経験なしでも実装可能なフレームワークを実現しています。また、モジュール性により各ノードの出力を自然言語で確認でき、エラーの原因特定も容易です。

技術や手法の肝はどこ？

AgentKitの核となる技術は、Dynamic Directed Acyclic Graph(DAG)によるノードの管理です。各ノードは1)依存ノードの出力と外部データベースからの入力の前処理、2)LLMへのプロンプト、3)結果の後処理という3ステップで構成されています。ノード間の依存関係はエッジとして表現され、IF...ELSE分岐やFOR...LOOPSなどの複雑な制御も、実行時にノードやエッジを動的に追加/削除することで実現できます。例えば、道路状態が悪い場合に滑りやすい道路を識別するサブタスクを追加するといった柔軟な対応が可能です。また、中央データベースを通じてタスク仕様や指示、現在の観察結果をすべてのノードで共有できる設計になっています。

どうやって有効だと検証した？

CrafterとWebShopという2つの異なるタスクで評価を行いました。Crafterは手続き的生成を特徴とするオープンワールドのサバイバルゲームで、AgentKitは階層的計画、リフレクション、経験からの学習といった高度な機能を実装し、SOTA(state-of-the-art)の性能を達成。特にGPT-4-turboを使用した従来手法SPRINGと比較して80%の報酬改善を達成し、45%のコスト削減も実現しています。また、eコマースプラットフォームでの商品検索・閲覧・識別を行うWebShopタスクでは、フューショット学習を必要としない6ノードのシンプルなエージェントを設計し、従来のSOTAと比較して5%の性能改善を達成しています。

議論はある？

論文では2つの主要な制限事項が議論されています。1つ目はLLMのクエリコストの増加です。各ノードでLLMへの問い合わせが必要となるため、全体的なコストが増加する傾向にあります。2つ目はプロセス設計とプロンプト作成に必要な手作業です。Majumder et al.(2023)やNottingham et al.(2024)は環境報酬からプロンプトを学習する手法を提案していますが、現状では5ステップ以下の限定的なタスク長でしか実験が行われておらず、環境ノイズや同時目標を持つ長期的タスクへのスケーリングは未解決の問題として残されています。

次に読むべき論文は？

以下の論文を読むことで、関連する研究をより深く理解できます：

  • Wei et al.(2022) "Chain-of-thought prompting elicits reasoning in large language models" - 明示的な推論のためのプロンプト設計の基礎となる研究
  • Wang et al.(2023a) "Voyager: An open-ended embodied agent with large language models" - スキルライブラリを用いたLLMエージェントの実装例
  • Lewis et al.(2020) "Retrieval-augmented generation for knowledge-intensive nlp tasks" - 外部知識の活用に関する研究
  • Madaan et al.(2023) "Self-refine: Iterative refinement with self-feedback" - LLMによる自己改善メカニズムの研究
Q
DAGということは推論ループやHuman-in-the-loopはできないのでしょうか？

論文の内容を詳しく確認しながら、この点について解説させていただきます。

  1. 推論ループについて：
    • 論文ではDAGを使用していますが、実は動的な推論ループのような機能も実現可能です。
    • これは以下の2つの方法で実現されています：
      1. 動的なノード/エッジの追加削除機能：実行時に新しいノードを追加することで、反復的な処理を実現
      2. データベース（DB）の活用：各ノードは共有DBを通じて状態を保持・更新可能
  2. Human-in-the-loopについて：
    • 論文では直接的な言及はありませんが、システムのアーキテクチャ上は可能です
    • その理由は：
      1. 中央データベース（DB）が外部入力を受け付ける設計になっている
      2. ノードの動的な追加/削除が可能で、人間の入力に基づいて新しい推論パスを構築できる
  3. 具体例：
    • Crafterゲームでの実装例では、以下のような循環的な処理を実現しています：
      • 3ステップごとに経験からのフィードバックを生成
      • プランニング→実行→リフレクション→プランニングの循環的なループ
      • 未知の情報のリスト（Lunk）と知識ベース（KB）の動的な更新

つまり、技術的にはDAGの制約を保ちながら、動的な更新によって実質的な循環処理やHuman-in-the-loopを実現可能な設計となっています。

ただし、これは「1回の実行」の中でのDAGという制約であり、複数回の実行を通じて循環的な処理を実現している点に注意が必要です。

単純なワークフローではないということね。あとは実際に触って見て確認する。

kun432kun432

インストール

Colaboratoryで。

パッケージインストール。extrasがいくつか用意されており、プロプライエタリなLLMとしてはOpenAIとAnthropicが対応しているので、これを有効にする。

pip install agentkit-llm[proprietary]

Getting Started

今回はOpenAIを使うこととするので、まずAPIキーをセット。ここの環境変数名はOPENAI_API_KEYではなくOPENAI_KEYなので注意。あと、OPENAI_ORGも必須になっていて、個人で使う限りはこの設定は不要なので空文字列をセットしておく。

import os
from google.colab import userdata

os.environ['OPENAI_KEY'] = userdata.get('OPENAI_API_KEY')
os.environ['OPENAI_ORG'] = ""

ではサンプルコード。以下のようなものになっている。

  • タスクは「ゲームのためのLLMエージェント」というトピックについての「エッセイを書く」
  • 3つのエージェントが用意されている
    1. トピックについてのメリット・デメリットをリストアップするエージェント
    2. 1の結果を踏まえて、エッセイのアウトラインを書くエージェント
    3. 2と3の結果を踏まえて、最終的なエッセイを書くエージェント

これらのエージェントの関係をグラフで定義して実行するという流れ。シンプルでわかりやすい記述。

import agentkit
from agentkit import Graph, BaseNode

import agentkit.llm_api

LLM_API_FUNCTION = agentkit.llm_api.get_query("gpt-4o")

LLM_API_FUNCTION.debug = True # APIレベルのエラー・リトライ処理を有効にするには、これを無効にする

graph = Graph()

subtask1 = "ゲームAIにLLMエージェントを使うことのメリットとデメリットを教えて。" 
node1 = BaseNode(subtask1, subtask1, graph, LLM_API_FUNCTION, agentkit.compose_prompt.BaseComposePrompt(), verbose=True)
graph.add_node(node1)

subtask2 = "「ゲームのためのLLMエージェント」というタイトルのエッセイのアウトラインを考えて。" 
node2 = BaseNode(subtask2, subtask2, graph, LLM_API_FUNCTION, agentkit.compose_prompt.BaseComposePrompt(), verbose=True)
graph.add_node(node2)

subtask3 = "では、「ゲームのためのLLMエージェント」というトピックについて、完全なエッセイを書いて。"
node3 = BaseNode(subtask3, subtask3, graph, LLM_API_FUNCTION, agentkit.compose_prompt.BaseComposePrompt(), verbose=True)
graph.add_node(node3)

# ノード間の依存関係を追加
graph.add_edge(subtask1, subtask2)
graph.add_edge(subtask1, subtask3)
graph.add_edge(subtask2, subtask3)

result = graph.evaluate() # プロンプトとアンサーのペアを辞書で出力

実行すると以下のようなメッセージが表示される。

出力
>Warning: The built-in LLM API is only for testing, and will not be actively maintained. Please write your own API for production use.
>Matched model_name gpt-4o to: gpt-4o. If this match is not accurate, then the token counter will not function properly.

今回モデルにgpt-4oを指定しているが、利用可能なモデルの定義は以下にある。

https://github.com/Holmeswww/AgentKit/blob/main/src/agentkit/llm_api/utils.py#L9-L34

gpt-4o-miniやo1などには対応していないのがわかる（実際に使えないかはわからないが、上のコードを見る限り、使えなさそうな感がある）。先程のメッセージも含めて、どうやらこのあたりのメンテナンスは今後もやらない様子。LLMの定義は自分でやれ、ということなのかもしれない。

でタスクの出力は以下のような感じとなった。

Prompt: ゲームAIにLLMエージェントを使うことのメリットとデメリットを教えて。
Answer: ゲームAIにLLM（大規模言語モデル）エージェントを使用することには、いくつかのメリットとデメリットがあります。

メリット

  1. 自然言語処理能力:
  • LLMは自然言語を理解し生成する能力が高いため、ゲーム内のキャラクターがプレイヤーとより自然な会話をすることができます。これにより、ゲームの没入感が向上します。
  1. 柔軟な応答生成:
  • 固定されたスクリプトに依存せず、状況に応じた柔軟な応答を生成できるため、プレイヤーの選択や行動に対してダイナミックに反応することが可能です。
  1. 学習と適応:
  • LLMは大量のデータから学習しているため、さまざまなシナリオに適応しやすく、異なるプレイスタイルやプレイヤーの好みに合わせた体験を提供できます。
  1. コンテンツ生成:
  • ゲーム内のストーリーやクエスト、キャラクターの背景などを自動生成することができ、開発者の負担を軽減します。

デメリット

  1. 計算資源の消費:
  • LLMは大規模で計算資源を多く消費するため、リアルタイムでの応答生成には高性能なハードウェアが必要です。
  1. 予測不可能な応答:
  • モデルが生成する応答が予測不可能である場合があり、ゲームの意図したストーリーや体験から逸脱する可能性があります。
  1. 倫理的問題:
  • LLMはトレーニングデータに基づいて応答を生成するため、不適切な内容やバイアスが含まれる可能性があります。これにより、ゲーム内で不適切な状況が発生するリスクがあります。
  1. 制御の難しさ:
  • 開発者が意図した通りにモデルの出力を制御するのが難しい場合があり、特定のシナリオやストーリーラインに沿った応答を保証するのが困難です。

これらのメリットとデメリットを考慮し、ゲームの目的やプレイヤー体験に応じてLLMエージェントの使用を検討することが重要です。

Prompt: 「ゲームのためのLLMエージェント」というタイトルのエッセイのアウトラインを考えて。
Answer: 以下は「ゲームのためのLLMエージェント」というタイトルのエッセイのアウトラインの提案です。

I. 序論

  • A. エッセイの目的と概要
  • ゲームにおけるAIの役割と進化
  • LLMエージェントの登場とその重要性
  • B. エッセイの構成

II. ゲームにおけるAIの歴史と進化

  • A. 初期のゲームAIの役割
  • シンプルなルールベースのAI
  • B. 現代のゲームAIの進化
  • 機械学習とAIの進化
  • LLMの登場

III. LLMエージェントの特徴

  • A. 自然言語処理能力
  • プレイヤーとのインタラクションの向上
  • B. 柔軟な応答生成
  • ダイナミックなゲーム体験の提供
  • C. コンテンツ生成能力
  • ストーリーやクエストの自動生成

IV. LLMエージェントのメリット

  • A. プレイヤー体験の向上
  • 没入感とインタラクティブ性の向上
  • B. 開発者の負担軽減
  • コンテンツ生成の自動化
  • C. 多様なプレイスタイルへの適応

V. LLMエージェントのデメリットと課題

  • A. 計算資源の消費
  • リアルタイム応答のためのハードウェア要件
  • B. 予測不可能な応答
  • ストーリーや体験の一貫性の維持
  • C. 倫理的問題とバイアス
  • 不適切な内容のリスク
  • D. 制御の難しさ
  • 開発者の意図に沿った出力の保証

VI. ゲームデザインへの影響

  • A. 新しいゲームデザインの可能性
  • インタラクティブストーリーテリング
  • B. プレイヤーエンゲージメントの向上
  • 個別化されたゲーム体験

VII. 未来の展望

  • A. 技術の進化と新たな可能性
  • LLMのさらなる進化と応用
  • B. ゲーム業界への影響
  • 新しいジャンルや体験の創出

VIII. 結論

  • A. まとめ
  • LLMエージェントの可能性と課題
  • B. 最終的な考察
  • ゲームにおけるLLMエージェントの未来

このアウトラインを基に、各セクションを詳細に展開してエッセイを執筆することができます。

Prompt: では、「ゲームのためのLLMエージェント」というトピックについて、完全なエッセイを書いて。
Answer: 以下は「ゲームのためのLLMエージェント」というトピックに関するエッセイです。

ゲームのためのLLMエージェント

序論

ゲーム業界は常に技術革新の最前線に立ち、プレイヤーに新しい体験を提供し続けています。その中で、AI技術の進化はゲームデザインに大きな影響を与えてきました。特に、近年の大規模言語モデル（LLM）の登場は、ゲーム内のAIエージェントに新たな可能性をもたらしています。本エッセイでは、ゲームにおけるLLMエージェントの役割、メリットとデメリット、そして未来の展望について考察します。

ゲームにおけるAIの歴史と進化

初期のゲームAIは、シンプルなルールベースのシステムに依存していました。これらのAIは、プレイヤーの行動に対して予測可能な反応を示すことが多く、ゲームの難易度を調整するためのツールとして機能していました。しかし、技術の進化に伴い、AIはより複雑で人間らしい行動を模倣するようになりました。機械学習の導入により、AIはプレイヤーの行動を学習し、適応する能力を獲得しました。そして、LLMの登場により、AIは自然言語を理解し、生成する能力を持つようになりました。

LLMエージェントの特徴

LLMエージェントの最大の特徴は、その高度な自然言語処理能力です。これにより、ゲーム内のキャラクターがプレイヤーと自然な会話を行うことが可能になり、没入感が大幅に向上します。また、LLMは柔軟な応答生成が可能であり、プレイヤーの選択や行動に応じてダイナミックに反応します。さらに、LLMはストーリーやクエスト、キャラクターの背景などを自動生成する能力を持ち、開発者の負担を軽減します。

LLMエージェントのメリット

LLMエージェントの導入により、プレイヤー体験は大きく向上します。自然な会話とインタラクションにより、ゲームの世界に対する没入感が増し、プレイヤーはより深くゲームに引き込まれます。また、コンテンツ生成の自動化により、開発者はより多くの時間をクリエイティブな作業に費やすことができ、ゲームの質を向上させることができます。さらに、LLMは多様なプレイスタイルに適応するため、個別化されたゲーム体験を提供することが可能です。

LLMエージェントのデメリットと課題

しかし、LLMエージェントにはいくつかの課題も存在します。まず、LLMは計算資源を多く消費するため、リアルタイムでの応答生成には高性能なハードウェアが必要です。また、モデルが生成する応答が予測不可能である場合があり、ゲームの意図したストーリーや体験から逸脱する可能性があります。さらに、LLMはトレーニングデータに基づいて応答を生成するため、不適切な内容やバイアスが含まれるリスクがあります。開発者が意図した通りにモデルの出力を制御するのが難しい場合もあり、特定のシナリオやストーリーラインに沿った応答を保証するのが困難です。

ゲームデザインへの影響

LLMエージェントの導入は、ゲームデザインに新しい可能性をもたらします。インタラクティブストーリーテリングの分野では、プレイヤーの選択に応じてストーリーが動的に変化するゲームが実現可能です。これにより、プレイヤーエンゲージメントが向上し、個別化されたゲーム体験が提供されます。

未来の展望

技術の進化に伴い、LLMはさらに進化し、ゲーム業界に新たな可能性をもたらすでしょう。より

最後が少し切れてしまっているが、各エージェントがそれぞれのサブタスクを実行、グラフに従って結果が引き渡されているように見える。

グラフの可視化みたいな機能はないのだが、こういう流れになっていると思う。

kun432kun432

基本的なエージェントは、サブタスクのプロンプトのリストとして簡単に実装できるため、プログラミングの経験がなくても、誰でも設計および調整が可能である。

とあるように、現時点でもかなりシンプルに放っていると思うが、より簡単にできるようにコマンドラインからグラフを作成することができる模様。

で、そのためにはextrasを[all]でインストールする必要があると記載されているのだが、試してみた限り[all]だとインストールでコケてしまい、また、[proprietary]でも動作したので、以下に流れを。

レポジトリをクローンして、サンプルのディレクトリに移動。

!git clone https://github.com/holmeswww/AgentKit
%cd AgentKit/examples/prompt_without_coding

コマンドラインのツールを実行

!python generate_graph.py

Getting Startedで作成したものをやってみる。こういう感じで設定する。

Welcome to the DAG Manager!
---------------------------

DAG Manager Dashboard
---------------------

Current DAG Nodes and their details:
The graph is currently empty.

Options:
 [A] Add node
 [E] Edit node
 [L] Load graph
 [S] Save graph
 [R] Evaluate graph
 [X] Exit

Choose an action (A, E, L, S, R, X): A     # Aでノードを追加
Enter new node name: 1     # ノード名を"1"とする
Enter node prompt: ゲームAIにLLMエージェントを使うことのメリットとデメリットを教えて。     # プロンプト入力
 Node '1' added.
Enter dependencies (comma-separated, blank to finish):      # 出力結果を受け取る他のノード名を指定（最初のノードなのでENTERでOK）

Press Enter to continue...
DAG Manager Dashboard
---------------------

Current DAG Nodes and their details:
Node: 1, Prompt: ゲームAIにLLMエージェントを使うことのメリットとデメリットを教えて。, Dependencies: []

Options:
 [A] Add node
 [E] Edit node
 [L] Load graph
 [S] Save graph
 [R] Evaluate graph
 [X] Exit

Choose an action (A, E, L, S, R, X): A     # さらにノードを追加
Enter new node name: 2     # ノード名"2"とする
Enter node prompt: 「ゲームのためのLLMエージェント」というタイトルのエッセイのアウトラインを考えて。     # プロンプト入力
 Node '2' added.
Enter dependencies (comma-separated, blank to finish): 1     # 2つ目のノードは1つ目のノードの結果を受けるので、"1"を指定
 Dependencies of '2' updated successfully.

Press Enter to continue...
DAG Manager Dashboard
---------------------

Current DAG Nodes and their details:
Node: 1, Prompt: ゲームAIにLLMエージェントを使うことのメリットとデメリットを教えて。, Dependencies: []
Node: 2, Prompt: 「ゲームのためのLLMエージェント」というタイトルのエッセイのアウトラインを考えて。, Dependencies: ['1']

Getting Startedだともう一つエージェントが必要なのだが、お試しなのでここまで。

グラフを実行する

Options:
 [A] Add node
 [E] Edit node
 [L] Load graph
 [S] Save graph
 [R] Evaluate graph
 [X] Exit

Choose an action (A, E, L, S, R, X): R     # グラフを実行
Enter the name of the LLM to generate the graph (e.g., gpt-4-turbo-preview): gpt-4o-mini
Warning: The built-in LLM API is only for testing, and will not be actively maintained. Please write your own API for production use.
Matched model_name gpt-4o-mini to: gpt-4o. If this match is not accurate, then the token counter will not function properly.
Evaluating the graph...

以下のような出力になる

1: ゲームAIにLLM（大規模言語モデル）エージェントを使用することには、いくつかのメリットとデメリットがあります。

メリット

  1. 自然な対話:
  • LLMは自然言語処理に優れており、プレイヤーとの対話を自然で流暢に行うことができます。これにより、プレイヤーはより没入感のある体験を得られます。
  1. 柔軟性:
  • LLMは多様なシナリオや状況に対応できるため、プレイヤーの行動に応じてリアルタイムで反応を変えることができます。これにより、ゲームのリプレイ性が向上します。
  1. ストーリーテリング:
  • LLMを使用することで、動的なストーリー展開やキャラクターのバックストーリーを生成することが可能です。これにより、プレイヤーはより深い物語体験を楽しむことができます。
  1. キャラクターの個性:
  • LLMはキャラクターに独自の個性や口調を持たせることができ、プレイヤーとのインタラクションがより魅力的になります。
  1. コンテンツ生成:
  • ゲーム内のクエストやアイテムの説明、NPCのセリフなどを自動生成することで、開発者の負担を軽減し、コンテンツの多様性を増やすことができます。

デメリット

  1. 計算リソース:
  • LLMは大規模なモデルであり、動作させるためには高い計算リソースが必要です。これがゲームのパフォーマンスに影響を与える可能性があります。
  1. 一貫性の欠如:
  • LLMは生成する内容が必ずしも一貫しているわけではなく、時には矛盾した情報を提供することがあります。これがプレイヤーの体験を損なう可能性があります。
  1. 制御の難しさ:
  • LLMの出力は予測不可能な場合があり、開発者が意図した内容やトーンを維持するのが難しいことがあります。
  1. 倫理的な問題:
  • LLMが生成するコンテンツには、意図しない不適切な表現や偏見が含まれる可能性があります。これに対処するためのフィルタリングや監視が必要です。
  1. プレイヤーの期待:
  • プレイヤーがLLMエージェントとのインタラクションに高い期待を持つ場合、期待に応えられないと不満を招く可能性があります。

結論

LLMエージェントをゲームAIに使用することは、プレイヤー体験を向上させる多くの可能性を秘めていますが、同時に技術的な課題や倫理的な問題も伴います。これらのメリットとデメリットを考慮しながら、適切に活用することが重要です。

2: 「ゲームのためのLLMエージェント」というタイトルのエッセイのアウトラインを以下に示します。このアウトラインは、LLMエージェントの役割、利点、課題、そして将来の展望を包括的にカバーすることを目的としています。

アウトライン

I. はじめに

  • A. ゲーム業界におけるAIの重要性
  • B. LLM（大規模言語モデル）エージェントの定義
  • C. 本エッセイの目的と構成

II. LLMエージェントの基本概念

  • A. LLMの技術的背景
    1. 自然言語処理の進化
    2. トレーニングデータとモデルの仕組み
  • B. ゲームにおけるLLMエージェントの役割
    1. NPC（ノンプレイヤーキャラクター）との対話
    2. ストーリー生成とダイナミックなコンテンツ

III. LLMエージェントのメリット

  • A. 自然な対話と没入感の向上
  • B. プレイヤーの行動に応じた柔軟な反応
  • C. コンテンツ生成の効率化
  • D. キャラクターの個性と深みの増加

IV. LLMエージェントのデメリット

  • A. 計算リソースの要求
  • B. 一貫性の欠如と矛盾の可能性
  • C. 制御の難しさと予測不可能性
  • D. 倫理的な問題と不適切なコンテンツの生成

V. 実際のゲームにおけるLLMエージェントの事例

  • A. 成功事例の紹介
    1. 特定のゲームタイトルやプロジェクト
    2. プレイヤーの反応と評価
  • B. 課題に直面した事例
    1. 失敗や問題点の分析
    2. 改善策や教訓

VI. 将来の展望

  • A. 技術の進化とLLMエージェントの可能性
  • B. ゲームデザインにおける新たなアプローチ
  • C. プレイヤー体験のさらなる向上に向けた展望

VII. 結論

  • A. LLMエージェントのゲームにおける意義
  • B. メリットとデメリットのバランス
  • C. 今後の研究と開発の重要性

このアウトラインを基に、各セクションを詳細に展開していくことで、LLMエージェントがゲームに与える影響やその可能性について深く掘り下げたエッセイを作成することができます。

kun432kun432

まとめ

グラフでフローを制御するタイプのマルチエージェント構築フレームワークといえば、LangGraphが恐らく有名だと思う。

https://zenn.dev/kun432/scraps/7ea614c804cfe7

以前自分が試したときには少し学習のハードルが高いと感じたのだが、LangGraphはエージェントの挙動を細かく制御するための機能が豊富だし、またLangChainの知識も活用できる≒必要になるという点を踏まえると、致し方ないところもあるかなと思う。

それに比較すると、AgentKitはコードも直感的で、ノーコードと言わないまでもかなりわかりやすいのではないかと思う。反面、LangGraphが持っている豊富な機能は、少なくともドキュメント等でも見当たらないないので、恐らくLangGraphよりは機能的には劣るのかもしれない。

個人的には、ユースケースにあったフレームワークの選択はありだと思っていて、以下で取り上げたOpenAIのSwarmのような軽量フレームワークというものも存在意義があると思うし、AgentKitも同じような位置づけとして良いのではないかなと感じた。

https://zenn.dev/kun432/scraps/30a5c55db75fb9

ただ、残念なのは

  • ドキュメントはGitHubのREADMEとAPIリファレンスだけ。
  • 上に書いた通り、ビルトインのLLM API対応はメンテしない方針の様子（今後は自分で書く必要が出てくるかもしれない）。
  • IssueやPR見る限りあまり活発な雰囲気を感じない。

というところかな。個人的な印象として商用で利用するには厳しいのはあるんだけど、それはそれとしても、ちょっと今後に不安が残る感じ。

このスクラップは16日前にクローズされました