Source-linked AI summary
Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence
Yuyuan Feng, Zhishang Xiang, Chaobin Yang, Qichao Ma, Zerui Chen, Yujing Zhang, Ke Huang, Chuanjie Wu, Zhaoxu Liu, Yili Wang, Xin He, Jiapu Wang, Zijin Hong, Hao Chen, Yuanchen Bei, Kun Wang, Shengyuan Chen, Ningyu Zhang, Enyan Dai, Linhao Luo, Qingyi Pan, Qi Wang, Wenqi Fan, Guangjing Wang, Na Zou, Yangqiu Song, Xin Wang, Zechao Li, Xia Hu, Qing Li, Xiao Huang, Zhihong Zhang, Jinsong Su, Qinggang Zhang, Yi Chang
TL;DR
複雑なタスクが単独エージェントの組織化能力を超えるなか、本論文はタスク、エージェント、実行時状態を協調させるシステムレベルのアプローチとしてGraph Engineeringを概観する。調査の結果、作業の組織化とエージェント間協調は一般的である一方、永続的なシステム進化は依然として稀であり、エージェントを単に追加するよりも関係を明示的に組織化することの重要性が示された。
問題
複雑で異質かつ相互依存的な長期タスクは個々のエージェントの組織化能力を超えるため、専門化されたエージェント間でのシステムレベルの知能が必要となる。
手法
本論文は、明示的なグラフを用いてタスク分解、エージェント間協調、実行時状態の進化を組織化するGraph Engineeringを体系的に概観する。
結果
調査対象の各領域では、作業の組織化とエージェント間協調は一般的であり、実行時状態管理は発展途上である一方、永続的なシステム進化は依然として稀である。
要点と限界
システムレベルの知能は、モデルやエージェントを追加することよりも、作業、担い手、状態の関係を明示的に組織化することに大きく依存する。
要点と限界
最終タスクの成功だけではSystem Intelligenceを立証できない。向上が、より強力なモデル、より長いコンテキスト、追加のサンプリング、またはより大きな計算コストによる可能性があるためである。
Abstract
from arXiv · showhide
LLMs have evolved from language generators to autonomous agents capable of complex, long-horizon tasks. This evolution has produced paradigms including Prompt Engineering to elicit model capabilities, Context Engineering to manage information access, Harness Engineering to organize external tools and resources, and Loop Engineering to support continual reflection and self-improvement. Yet as tasks grow more complex, individual intelligence faces a fundamental limit: many tasks require heterogeneous expertise, interdependent subtasks, parallel execution, independent verification, and persistent state, exceeding any single agent's organizational capacity. Augmenting one agent's capabilities or context cannot resolve this architectural mismatch; intelligence must instead be distributed across specialized agents and organized at the system level. We call this System Intelligence: an agent system's ability to organize and coordinate multiple intelligent components into a coherent, adaptive whole pursuing a shared objective. Achieving it requires more than adding agents; it demands explicit structures to organize work, coordinate heterogeneous agents, and maintain evolving execution states. We introduce Graph Engineering, an emerging paradigm for next-generation agent systems. Unlike prior paradigms that mainly optimize individual interactions or agent-level behavior, Graph Engineering constructs explicit, dynamic, evolving graph structures representing tasks, agents, and system states. These abstractions provide a unified foundation for organizing complex objectives, orchestrating heterogeneous agents, modeling system dynamics, and enabling scalable agent evolution. We systematically review the principles, methodologies, and applications of Graph Engineering for LLM agents. Related papers, open-source data, and projects are collected at https://github.com/DEEP-JLU/Awesome-Graph-Engineering.
1 はじめに
LLMはHarness EngineeringとLoop Engineeringを通じてモデルレベルの能力から自律エージェントへと発展したが、複雑で長期にわたるタスクは単一エージェントの組織化能力を超える。本論文はGraph Engineeringを導入し、専門化されたエージェント間で知能を分散するとともに、タスク、協調、進化する実行時状態をシステムレベルで組織化する。
- Model IntelligenceからIndividual Intelligenceへ: Harness EngineeringとLoop Engineeringは、リソース、ツール、メモリ、スキル、永続的な反復実行によってLLMを拡張し、Individual Intelligenceをもたらす。この枠組みでは、エージェントをAgent = Loop(LLM + Harness)と定式化する。
- Individual IntelligenceからSystem Intelligenceへ: Individual Intelligenceは、異種の専門知識、相互依存するサブタスク、並列実行、独立検証、永続状態を必要とするタスクには不十分である。これらの要件は単一エージェントの組織化能力を超える [88] [93] [155] [415]。
- Individual IntelligenceからSystem Intelligenceへ: 単一エージェントの能力やコンテキストを拡張してもこの構造的不整合は解消できないため、知能は専門化されたエージェント間に分散し、システムレベルで組織化されなければならない。本論文はこの能力をSystem Intelligenceと呼ぶ [159] [284]。
- Graph Engineering: Graph Engineeringは動的なグラフ構造を用いて、タスク実行を組織化し、エージェントを協調させ、システムレベルの知能に向けて実行時状態の進化を制御する。その3つの組織化問題はTask Organization、Agent Coordination、Runtime State Managementである。
- 貢献: 本論文は、エージェントおよびシステムの概念、ModelからIndividual、さらにSystem Intelligenceへの発展、グラフに基づく組織化、評価、ソフトウェアスタック、応用を包含する枠組みを構築する。調査対象の応用には、ソフトウェア工学、科学的発見、医療、企業ワークフロー、デジタルエージェント、社会・経済シミュレーションが含まれる。
- 貢献: 未解決の課題には、オントロジー工学、動的かつ自己進化するグラフシステム、グラフネイティブなエージェントオペレーティングシステム、相互運用性、構造進化、状態の来歴、永続的なSystem Evolutionが含まれる。序論では、永続的なSystem Evolutionが現在の実践では限定的であると指摘する。
2 予備知識
Graph Engineeringは、Foundation Model、Agent Harness、反復的なAgent Loopを組み合わせるIndividual Agentと、共有リソース、環境、システムレベルの状態を介して複数のagentおよび支援コンポーネントを協調させるAgent Systemを区別する。
- Individual Agent: Individual Agentは環境を知覚し、推論して行動し、フィードバックを通じて適応するものであり、主にFoundation ModelとAgent Harnessから構成される。Foundation Modelは言語理解、推論、計画、生成を担い、Harnessは知覚とコンテキスト構築のためのインターフェースを提供する。
- Individual Agent: Agent Loopは知覚、推論、行動、フィードバック処理、状態更新を反復的に統合し、時間の経過に伴うagentの能力を組織化する。Foundation Modelは内在的な認知を決定し、Harnessは利用可能なリソースと行動空間を決定し、Loopはそれらの継続的な利用を決定する。
- Agent System: Agent Systemは個別agentの抽象を、共有リソース、外部環境、協調メカニズムを介して動作するagent群へと拡張する。そのagentチームには、異なる能力とタスクを持つ役割特化型agentを含めることができる。共有リソースには、ツール、モデルサービス、メモリ、知識ベース、検証器、人間による支援が含まれる。
- Agent System: Agent Systemの協調メカニズムは、タスクの割り当て、情報交換、結果の統合、競合の解消、失敗への対処を行う。外部環境は観測とフィードバックを提供し、agentの行動に応じて変化する。
- Agent System: System stateは、システム全体にわたるタスクの進捗、共有結果、agentの可用性、リソースの状態、環境の変化、失敗記録を記録する。個別agentのローカルな実行時状態とは異なり、system stateは時刻tにおけるシステム全体の運用状態を表す。
3 Model IntelligenceからIndividual Intelligenceへ
Model Intelligenceは、推論時のPrompt EngineeringとContext Engineeringによって形成されるパラメータレベルの能力から生じ、Loop Engineeringは、持続的な目標追求に向けた、限定的で状態を持つフィードバック駆動型の実行を加える。これらの進展により高能力な個別エージェントが実現する一方、単一エージェントによる組織化は、並列スケジューリング、専門的な検証、持続的な失敗回復によって依然として制約される。
- Model Intelligence: Pre-trainingとPost-trainingは、モデルの一般知識、推論能力、行動能力をパラメータレベルで確立する。Scaling laws、scalable architectures、post-training methodsにより、この能力基盤は段階的に強化・制御される [150] [75] [140] [52] [160] [291].
- Inference-Time Engineering: Prompt Engineeringはタスクを規定して推論を組織化し、Context Engineeringはモデルパラメータを変更せずにタスク関連情報を取得・管理する。両者は、どの能力を発動するか、推論がどのように進むか、どの情報が出力を条件づけるかを決定する [300] [2].
- Loop Engineering: Loop Engineeringは、結果を用いてタスクの後続の軌道を制御し、証拠が十分になるか、継続が正当化されなくなるまで、限定的で状態を持つフィードバック駆動型の実行を調整する [131] [234].その定義上の特徴は、単にモデル呼び出しを反復するのではなく、継続的なフィードバック制御にある。
- Individual Intelligenceの限界: 単一エージェントのループは、並列または相互依存するサブタスクを直列化し、スケジューリングの判断を隠蔽し、並列性を浪費するとともに、失敗箇所の特定を困難にしやすい [93] [126].障害診断では、ログ分析、失敗再現、コード検査を並列に進められるが、伝播した中間結果によって障害段階が不明瞭になる可能性がある。
- Individual Intelligenceの限界: 単一エージェントは、独立した専門家役と検証者役、永続状態、追跡可能な回復を維持することに苦戦し、役割混同、確証バイアス、初期エラーの未修復というリスクを生む [88] [155].こうした弱点は、長時間にわたるwebタスクやcodingタスクで特に重大であり、小さな初期ミスが後段の失敗まで持続する可能性がある。
4 Graph Engineering：個別知能からシステム知能へ · 4.1 Graph Engineeringの概要
Graph Engineeringは、明示的なグラフ構造によってタスクを整理し、異種コンポーネントを協調させ、実行時状態を管理することで、個別知能の限界に対処する。この構造中心の基盤は、System Intelligenceに向けたシステムレベルの組織化、協調、監視、復旧、最適化、継続的進化を支える。
- 4.1 Graph Engineeringの概要: 個別知能は、並列かつ相互依存するスケジューリング、異種能力の統合、実行時状態の維持に苦慮するため、共有目標を追求する相補的なコンポーネントを通じてSystem Intelligenceが必要となる [154] [159]。
- 4.1 Graph Engineeringの概要: System Intelligenceは、単にエージェントを集約するのではなく、タスク、コンポーネント、実行時状態の間の関係を明示的に表現し、制約し、最適化することに依存する。
- 4.1 Graph Engineeringの概要: グラフは運用トポロジーと通信パターンを表現することで異種コンポーネントを協調させ、能力と役割に応じた協働を可能にする [69] [205] [433]。
- 4.1 Graph Engineeringの概要: グラフは、分解、依存関係のモデル化、ワークフローの洗練を通じて複雑な目標を整理し、スケジューリングおよび実行が可能な操作へ変換する [280]。
- 4.1 Graph Engineeringの概要: グラフは、イベント、依存関係、状態遷移を記録することで実行時状態管理を支援し、分散した運用情報を永続的な実行状態表現へ変換する。
- 4.1 Graph Engineeringの概要: Graph Engineeringは、タスク、コンポーネント、実行時状態の間の関係を外部化し、システムレベルの組織化、協調、監視、復旧、最適化を支える中核基盤としてグラフを利用する。
- 4.1 Graph Engineeringの概要: システムの進化では、実行フィードバックと状態エビデンスを用いてGraph Engineeringの構造を反復的に改善し、システム知能の継続的進化を可能にする。
4.2 タスク編成：実行内容の構造化
Task Organizationは、高水準の目標を明示的なサブゴール、依存関係、スケジューリング可能なグラフへ変換し、それらを実行可能なワークフローへコンパイルする。これにより、実行時フィードバックを用いた最適化と適応が可能となる。これは、エージェント設計を暗黙的な推論と行動から、明示的な作業構造へと転換するものである。
- 目標分解: Goal Decomposition Graphは、目標を明示的でスケジューリング可能なサブゴールグラフへ変換し、後続のワークフロー構築と実行適応に向けて依存関係を可視化する。これにより、相互依存するアクション、並列分岐、検証ステップ、さらにコンテキストだけでは管理が難しい動的な再計画に対応できる。
- ワークフロー最適化: 明示的な依存関係グラフは、LLMCompilerの[156] dataflow DAGやPlan-over-Graphの[464]依存関係制約付きエージェントスケジュールを含む、並列スケジューリングを可能にする。上流の依存関係が満たされると、実行可能なノードをディスパッチできる。
- ワークフロー最適化: ワークフロー最適化は、意味的なサブゴールを、LLM呼び出し、エージェント、検索、ツール、メモリ、aggregator、verifier上で動作する実行可能なワークフローへコンパイルする。グラフベースのワークフロー手法は、操作空間を未構造のまま残すのではなく、代替的な制御フローを探索・最適化する。
- ワークフロー最適化: 静的なタスクグラフとワークフローグラフは、開放型環境にはなお不十分であり、中間結果の誤り、ツールの失敗、曖昧なフィードバックに対応する動的適応が求められる。DyFlow [363]は、リアルタイムの実行フィードバックに応答する実行適応型ワークフローグラフの例である。
- 全体的視点: Task Organizationは、タスク管理と実行管理を統合的に捉えるグラフベースの視点を提供し、達成すべき作業、作業を運用化する方法、そして実行を適応させる方法を規定する。Figure 6は、エージェント作業を編成・管理する相補的なメカニズムとして、Goal DecompositionとWorkflow Optimizationを要約している。
4.3 エージェント協調：誰が働くかを構造化する
エージェント協調は、能力をモデル化し、責任と作業フローを整理し、実行の進行に応じて実行時の通信を適応させることで、異種エージェントを構造化する。グラフ表現はこれらの関係を明示するとともに、比較的安定したチーム編成と動的な情報交換・フィードバックを区別する。
- 概要: グラフベースのエージェント協調は、一貫したマルチエージェント実行のための、相互に接続された3つの機能として、能力モデリング、チーム編成、実行時通信を扱う。これらの機能は、適切なエージェントを特定し、責任と作業の移動を決定し、実行中の情報交換を適応させる。
- 能力モデリング: 能力グラフは、スキル、リソース、権限、信頼性に関する情報を用いて、変化する異種の作業をエージェントに割り当てる。能力の不一致は並列実行を遅延させ、下流の結果を損なう可能性がある。永続的で更新可能な表現は、タスク固有のスコア、ルーティングポリシー、オーケストレーショングラフの限界に対処する。
- チーム編成: チーム編成グラフは、割り当て、委任、監督、引き継ぎ、レビューのために、型付き関係によってエージェント、役割、タスクを符号化する。チェーン、ルーティング、fan-out/fan-in、動的に変化する構造を組み合わせ、参加者、責任、作業が参加者間をどのように移動するかを指定できる。
- 通信モデリング: 実行時通信グラフは、特定の実行時点でどのエージェントまたは人間の参加者が情報を交換するか、そしてフィードバックが後続のアクションをどのように変化させるかをモデル化する。通信は明確化、レビュー、エラー訂正、介入を支援し、フィードバックは後続のインタラクションを起動または修正できる。
- 通信モデリング: チーム編成は誰が参加し、どの責任を担うかを決定するのに対し、通信モデリングは実行中のどの時点で情報とフィードバックを流す必要があるかを決定する。この区別により、比較的安定した責任関係と、タスクおよび状態に依存するインタラクション構造が分離される。
4.4 ランタイム状態管理：システムの動作方法の構造化
ランタイム状態管理は一貫した実行履歴を記録し、証拠と依存関係を用いて障害を局所化し、検証済みの境界から選択的に復旧できるようにする。これらの能力が一体となって、モニタリング、診断、安全な再開、継続的なシステム進化の基盤を提供する。
- 概要: ランタイム状態管理は、分散実行の履歴を、モニタリング、診断、復旧、継続的なシステム進化のための信頼できる基盤へと変換する。これはTask OrganizationおよびAgent Coordinationを補完するものであり、何が起こるべきか、誰が行動すべきかだけでなく、実際に何が起こったかを表現する。
- 状態記録: ランタイム状態管理は、進捗、役割、コミットメント、事実、リソース、外部効果に関する分散更新を、一貫性があり追跡可能なビューとして記録する。信頼できる状態には、構造化表現、統制された更新、スコープ付き可視性、一貫性管理が必要であるが、既存研究には統一的なgraph-native実装が欠けている。
- 障害局所化: 障害局所化は逸脱を検出し、依存関係を通じて影響を追跡し、仮説–証拠関係を検証し、復旧に有効な実行領域を特定する。時間的リンクまたは構造的リンクだけでは因果性を確立できない。ランタイム記録は来歴を保持し、検査、バックトラッキング、ブランチレベルの診断を支援する。
- 障害復旧: 障害復旧は、無効な状態を撤回し、計算を再実行し、外部効果を補償し、または代替実行経路へ分岐するための明示的な境界を選択する。効果的な復旧は、状態依存関係とコミット済みの外部効果を考慮しながら影響を受けた領域を選択的に修復し、その後、境界、是正措置、結果として得られた状態を記録する。
4.5 システム進化
システム進化は、実行時の証拠を用いてタスク編成、エージェント協調、状態管理を改良し、複数回の実行を通じてシステム知能を向上させる。Validationとrollbackにより信頼できる改良の持続を保証し、失敗を後続の意思決定に反映することで、実行から経験、進化へと至る閉ループを形成する。
- タスク編成の進化: 中間結果や変化する条件によって事前定義された計画が無効になった場合、目的分解、タスク構造、ワークフローを改良する。TDAG [362]は実行の進行に応じて複雑なタスクを動的に分解し、専門エージェントを生成する。Flow はサブタスクの割り当てを改良する。
- エージェント協調の進化: タスク要件やコンポーネントの能力が変化するにつれて、エージェント協調はチーム構造とコミュニケーションパターンを進化させる。SwarmAgentic は、フィードバックに導かれた集団探索を通じて、エージェント機能と協調構造を共同最適化する。AgentNet は分散協調を支援する。
- 実行時状態管理の進化: 実行時状態管理は、実行履歴を再利用可能な知識へ蒸留するとともに、誤った経験の伝播を防ぐため、更新を検証、改訂、またはrollbackする。これは状態を実行と復旧の範囲を超えて拡張し、将来の改善に向けて経験を蓄積するものである。
- システム進化: システム進化は実行結果をシステムレベルの更新へ変換し、知能を実行時適応から持続的な経験駆動型進化へと発展させる。オープンエンドかつ長期的な実行は、効果的な構造、協調戦略、失敗モードに関する証拠を生成する。
5 未解決の課題と研究機会
Graph Engineeringがタスク固有の構造から再利用可能で継続的に稼働するインフラへ移行するには、能力統合、永続的かつグラフ横断的な進化、graph-nativeなシステム支援、プライバシーと倫理に関する課題が伴う。これらの課題への対応には、能力間の明示的な関係、協調的な構造変化、共有runtime、分散した永続状態に対するガバナンスが必要である。
- Unified Capability Graph: Unified capability graphは、model、tool、skill、memory、data source、verifier、environmentを型付き関係で表現し、それらをtask、agent、runtime-state graphに接続すべきである。Edgeはdependency、compatibility、composition、substitution、authorization、cost、reliabilityを符号化でき、capability選択とtask分解が明示的に連動できるようになる。
- Persistent Evolution: Self-evolving graph systemは、単一のtrajectoryを適応させるだけでなく、実行証拠を永続的で再利用可能な構造変化へ変換しなければならない。どのdependency、agent関係、capability割当、state構造が成功または失敗を引き起こしたのかを特定し、変化が現在の実行を越えて一般化するかを評価する必要がある。
- Cross-Graph Evolution: Task、agent、capability、state graphは、provenance、versioning、permission、runtime assumptionを保持しながら、共有制約の下で協調的に進化しなければならない。1つのgraphを変更すると、必要なcapabilityが変化し、communication relationが無効になり、authorizationや実行条件が損なわれる可能性がある。
- Graph-Native Infrastructure: Graph-native agent operating systemは、task、agent、capability、runtime stateを、共有のscheduling、storage、recovery、provenance、permission機構を備えた型付き・version管理オブジェクトとして統合できる。実行traceをそれを生成した構造に結び付けることで、候補となる変更を歴史的または反実仮想的に評価し、検証済みの改善を新たなgraph versionとして確定できる。
- Privacy and Ethics: Agent、tool、memory、共有stateの長期的な協調は、情報の複製、workflowへの伝播、永続的保持、権限のないアクセス、task横断的な漏洩、意図しないprivate attribute推論を通じて、privacyと倫理上のリスクを増幅する。これらのリスクは、system intelligenceが意思決定と実行状態を、相互接続された複数のcomponentに分散させることで生じる。
6 将来の方向性：次世代System Intelligenceに向けたOntology Engineering
Ontology Engineeringは、Graph Engineeringの構造を接続・検証・再利用・進化させるために必要な、共有された機械解釈可能な意味論を提供する 。将来のSystem Intelligenceには、最終タスクの成功を超えて、明示的な目標形成、グラウンディング、ガバナンス、評価も必要である。
- 動機: Ontology Engineeringは、システムのエンティティ、関係、制約に関する共有定義を確立し、グラフビュー、コンポーネント、実行段階間で解釈が一貫しない問題に対処する 。グラフ構造の接続、検証、再利用、進化を支援する。
- システムレベル評価: 最終タスクの成功だけではSystem Intelligenceを確立できない。評価では、コンポーネントの能力と、システムの組織化、協調、状態管理を分離すべきである。成功、失敗、貢献、リカバリ、一貫性、実行時コストに関する標準化された意味により、比較可能なトレース、構造的アブレーション、因果分析が可能になる。
- オントロジー構造: 階層型オントロジーは、目標、エージェント、能力、エビデンス、ポリシー、状態、結果を包含する基盤概念、専門モジュール、ドメイン拡張を組み合わせるべきである。このモジュール構造により、すべてのシステムが同一のドメイン概念を共有することなく、一貫した定義を提供できる。
- 目標形成と価値整合: Ontology Engineeringは、目標の来歴、優先度、認可、完了基準、制約を明示的かつ検証可能にし、同時に競合や未認可の変更を明らかにできる。規範的制約を明確化するが、システムが採用すべき価値を決定することはできない。
- 共有意味論と世界グラウンディング: 共有意味論は、ツール出力、観測、タイムスタンプ、来歴、検証結果に接続しなければならない。意味論的一貫性だけでは、事実の正しさは保証されないためである。Ontologyに導かれたマルチエージェントシステムは、この意味論層を動的に維持できる。
- ガバナンスと進化: 将来のオントロジーには、来歴チェック、一貫性検証、影響分析、バージョン管理、互換性チェック、移行、ロールバック、実行時に連動した制約適用が必要である [490]。LLMは概念や関係を提案できるが、意味論の変更は採用前にガバナンスを受けるべきである。
7 ベンチマーク、データセット、評価
評価は、Model、Individual、Systemという3つの知能レベルを軸に構成され、その単位は、限定的な出力から、持続的な軌跡、さらに複数コンポーネントから成る協調システムへと段階的に移行する。Graph Engineeringによるシステムには、構造、運用、進化に関する評価も必要である一方、現行のベンチマークは分断されており、システムレベルの改善を切り分ける能力も限定的である。
- 評価レベル: 評価単位は、限定的なモデル出力から、Individual Agentの軌跡、さらに複数コンポーネントとその関係の組織化・協調へと段階的に移行する。Model Intelligenceは限定的な相互作用を評価し、Individual Intelligenceは持続的な推論、ツール利用、環境からのフィードバックを評価し、System Intelligenceは複数コンポーネントの一貫した組織化、維持、改善を評価する。
- 評価資源: ベンチマーク、データセット、実行可能環境は、タスク、再利用可能な成果物、観測・変更可能な実行状態に対して相補的な評価資源を提供する。Table 1では、ベンチマークまたはプロトコル（B）、データセットまたはトレース（D）、実行可能環境（E）を区別しているが、これらは重複しうる。
- System Intelligence: System Intelligenceベンチマークは、作業分解、依存関係を考慮したスケジューリング、階層的オーケストレーション、協調、通信、スケーラビリティ、自己組織化、適応的ワークフロー、トポロジー、ランタイム設計、マルチエージェント最適化を検証する。AgentsNet、DBS、MASEval、MAS-PromptBench、MAFBenchは、適応、進化、代替的なマルチエージェント構成へと評価を拡張している [102] [72] [14]。
- 評価次元: すべてのレベルで、評価では有効性、効率性、頑健性を報告すべきであり、Graph Engineeringによるシステムにはさらに、構造的忠実度、運用上の正確性、追跡可能で制御可能な進化が必要である。これらの次元により、成功した結果と、妥当な基盤構造、正しく実行されたグラフ操作、統治可能な構造変化とを区別できる。
- 未解決の課題: 現行の評価では、システムレベルの改善を、より強力なモデル、大規模なコンテキスト、ツール、再試行、計算資源による効果から切り分ける必要がある。また、分断された資源と、構造に対する弱いクレジット割当にも対処しなければならない。本節では、作業の組織化、協調、ランタイム状態、進化にまたがる評価範囲の分断と、動的なシステムレベル評価の弱さを指摘する。
8 オープンソースライブラリとエンジニアリングエコシステム
オープンソースエコシステムは、再利用可能なインフラ、エージェントランタイム、複数コンポーネントのオーケストレーションを通じて、Model、Individual、System Intelligenceにまたがる。しかし、これらの層は依然として断片化しており、共有表現、実行間の構造進化、型付き因果状態はいずれも限定的である。
- エコシステムの範囲: 多くのライブラリが複数のレベルにまたがるため、主たるエンジニアリング対象によって分類し、Model、Individual、System Intelligenceを実行可能なエンジニアリングスタックへ変換する。本サーベイは、知的システムの構築または実行に直接影響する抽象化を備えた、公開文書化済みの再利用可能なプロジェクトを対象とする。
- Model Intelligence: Model Intelligenceのインフラは、モデル実行、分散事前学習、事後学習、スケーラブルな強化学習パイプラインを対象とする [323]。Transformers、Megatron Core、LLaMA-Factory、verl、slimeが、これらのエンジニアリング上の課題を代表する。
- Individual Intelligence: Individual Intelligenceライブラリは、ミドルウェア、権限、検証、セッション、状態、コンテキストワークフロー、永続メモリ、時間的知識、プロトコル、視覚的構成を用いて、モデル–ツールループを組織化する [296]。代表的なシステムには、LangChain、OpenAI Agents SDK、Claude Agent SDK、Pydantic AI、LlamaIndex Workflows、Haystack、Burr、Letta、Graphiti、MCP、Langflow、Difyが含まれる。
- System Intelligence: System Intelligenceライブラリは、graph execution、メッセージング、役割編成、イベントフロー、workflow engines、トポロジー最適化を通じて、タスク、エージェント、executor、共有状態の関係を明示化する [182]。LangGraph、Microsoft Agent Framework、Google ADK、AutoGen、CrewAI、CAMEL、Mastra、GPTSwarmがこれらのアプローチを例示する。AutoGenはmaintenance modeであるが、歴史的影響力を理由に含めている。一方、Microsoftは新規プロジェクトにAgent Frameworkを推奨している。
- 未解決の限界: このエコシステムには、ツール、メッセージ、ワークフロー、イベント、状態、依存関係、能力、権限、組織に関する共通表現がなく、現在の動的性も、実行間の体系的な進化を可能にするには至っていない。状態はチェックポイント、メモリ、スナップショット、履歴、ログ、時間的ストアに分散している。また、observabilityが、観測や失敗から後続の改善へ至る型付き因果リンクを捉えることはほとんどない。
9 Graph Engineeringの応用
Graph Engineeringの応用は、仕事の組織化、agent間の関係、実行時状態が実行に及ぼす影響に焦点を当て、領域別に整理される。ソフトウェア、科学、医療、企業システムのいずれにおいても、応用は個別agentから構造化されたmulti-agent systemへと移行しつつある一方、完全なGraph Engineeringはなお発展途上の目標である。
- 応用フレームワーク: 構造上の判断が実際の仕事に影響するため、応用は領域別に分類され、intelligence levelとGraph Engineering focusを領域横断的な記述子として用いる。ワークフロー、agent間の関係、または実行時状態の変化が実行を変える場合、研究プロトタイプと実運用システムの双方を対象とする。一方、検索のみを行うknowledge graphは除外する。
- ソフトウェア工学: ソフトウェア工学は、専門家の役割、repository interface、永続的なevent stream、並列agent、worktree、checkpoint、共有task stateを通じて、System Intelligenceへの移行を最も明確に示している。MetaGPTとChatDevは事前定義された段階と役割を用いる 。一方、SWE-agentはagent–repository interfaceを重視し [418]、新しいシステムほど明示的な並列協調を提供している。
- 科学的発見: 科学システムは、協調する専門agent、監督ワークフロー、物理的検証、ならびに後続の仮説を更新するfeedbackを通じて、仮説、証拠、ツール、実験、研究者を組織化する。Co-Scientistは、生成、批評、ランキング、改良を専門agentに割り当てる 。一方、Robinは文献、分析、実験室の証拠を接続する 。
- 医療: 医療では、協調的な専門化、longitudinal state、権限、証拠のprovenanceが必要であり、患者の病歴とガイドラインに基づく進化するcare planへと、多職種相談からシステムが発展している。DeepRareは表現型、遺伝型、検索、分析agentを協調させ、追跡可能な証拠を蓄積する 。AMIEは診察間で会話状態と管理推論状態を維持する 。
- 領域横断的な成熟度: 領域横断的に見ると、Work Organization、Agent Team、Runtime Stateの構造はますます一般的になっているが、完全なGraph Engineeringには、観測可能で制御可能かつ一貫して進化する構造がなお必要である。本レビューでは、現代の構造が実行前に手動で選択されたり固定されたりすることが多いため、graph-structured systemとgraph-engineered systemを区別する。シミュレーション上の創発についても、現実世界の因果主張を支えるには事前のcalibrationが必要である。
10 結論
結論では、異種的で相互依存する長期ホライズンのタスクが個別エージェントの限界を露呈させ、Graph Engineeringを通じて組織化されたSystem Intelligenceが必要になると論じている。Graph abstractionは、work、agent、runtime stateの関係を明示的かつ適応可能にする一方、alignment、governance、evaluation、privacy、安全なself-improvementには未解決の課題が残されている。
- 10 結論: Graph Engineeringは、work organization、agent coordination、runtime state managementという3つの相補的な視点を通じてsystem intelligenceを組織化する。これらのgraph abstractionはtask、agent、stateを表現しながら、system levelの関係を構造化する。
- 10 結論: Graphはworkをスケジュールし、capabilityを結び付け、executionを追跡し、failureを局所化し、agent system全体にわたる制御されたevolutionを可能にする。本surveyは、これらの機能を、Graphが単なる表現手段ではなく、operationalかつ適応可能であることの証拠として提示する。
- 10 結論: System levelのintelligenceは、modelやagentを追加することよりも、複雑なtaskに向けてそれらの関係を明示的に組織化することに依存する。taskがより異種的で相互依存的かつ長期ホライズンになるにつれ、individual-agent loopは、並列処理、専門知識、独立検証、persistent stateへの対応に苦慮する。
- 10 結論: Graph Engineeringは、semantic alignment、graph governance、evaluation、privacy、安全なself-improvementにおける未解決の課題に直面する新興分野である。本surveyは、graph-native infrastructureを、よりscalable、controllable、evolvableなagent systemに向けた方向性として位置付ける。
11 付録
既存のサーベイはエージェントの能力、エンジニアリング基盤、システムレベルの組織化を扱う。一方、Graph Engineeringは、明示的グラフを知的システムの組織化基盤として捉える点に特徴がある。タスクの組織化、エージェントの協調、実行時状態、システム進化を結合した枠組みに統合する。
- 既存のサーベイは、エージェント能力と、グラフによって強化された計画、メモリ、ツール利用、推論、実行、マルチエージェントインタラクションを検討する [20] [218]。
- 他のサーベイは、エージェントを支える基盤とシステム編成に重点を置き、ハーネス、実行ループ、永続状態、オーケストレーション、障害復旧、自己進化を含めて扱う [284]。
- 特定の能力を強化するグラフ–エージェントアプローチとは異なり、Graph Engineeringはグラフ構造を結合することで、タスク、エージェント、実行時エビデンスの変化に応じてシステムを改訂可能にする。動的グラフ変換は密接に関連するが、主として永続的なエージェント進化と、メモリ、ツール、スキル、ワークフロー、関係の書き換えに焦点を置く 。
- Graph Engineeringは、明示的グラフを、タスクの組織化、エージェントの協調、実行時状態管理、システム進化のための組織化の基盤として捉える。これらの構造は、目標、依存関係、ワークフロー、能力、責任、通信、実行エビデンス、障害、復旧依存関係を表現する。
- Graph Engineeringは、システムレベルで、能力、情報、実行基盤、フィードバック駆動型制御の組織化に取り組むことで、Prompt、Context、Harness、Loop Engineeringを拡張する。