PaperlayerView exact revision on arXiv

AI要約・英語からAI翻訳

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

arXiv:2608.21156v1cs.IRcs.AIcs.ET

TL;DR

多様で相互に依存する長期タスクには、単一エージェントの能力やコンテキストの拡張を超えた、システム全体での組織化が必要である。本サーベイは、作業の組織化、エージェントの協調、実行時の状態管理という観点からGraph Engineeringを整理する。応用分野を通じて、作業の組織化やエージェントチームの設計は一般的である一方、持続的なシステム進化は依然としてまれである。

  • 課題

    多様で相互に依存する長期タスクには、個々のエージェントの能力やコンテキストの拡張を超えた、システム全体での組織化が必要である。

    出典：§1 · p. 5

  • 方法

    本論文は、作業の組織化、エージェントの協調、実行時の状態管理という相補的な3つのグラフの観点からGraph Engineeringを概観する。

    出典：§1 · p. 5, §10 · p. 35

  • 結果

    応用分野を通じて、作業の組織化やエージェントチームの設計は一般的である一方、持続的なシステム進化は依然としてまれである。

    出典：§9.7 · p. 34

  • 示唆と限界

    システム全体の知能は、モデルやエージェントを単に追加することよりも、作業・エージェント・状態の関係を明示的に組織化することに大きく依存する。

    出典：§10 · p. 35

    明示的なグラフ構造だけでは、タスクの完了、根拠、有効な状態、許可された行動について、エージェント間で解釈の一貫性は保証されない。

    出典：§6.1 · p. 25

Abstract

from arXiv · show

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 はじめに

序論では、タスク編成、エージェント間の協調、実行時の状態管理を担うシステムレベルのパラダイムとして、グラフエンジニアリングを提案する。複雑な目標の達成には、個々の能力の拡張や単なるエージェント数の増加ではなく、専門化されたエージェントの協調が必要であると論じる。

1 はじめに

  • ハーネスエンジニアリングとループエンジニアリングは、外部リソースと、計画・行動・観察・検証・適応の継続的なサイクルを組み合わせ、個体知能を実現する。プロンプトエンジニアリングとコンテキストエンジニアリングは、構造化された指示と整理されたタスク関連情報を通じて、モデル知能を引き出す。本サーベイは、個々のエージェントの基盤モデル、ハーネス、ループ、局所状態と、エージェントシステムのチーム、共有リソース、環境、協調機構、システムレベルの状態を区別する。出典：§1 · pp. 4–5
  • 異種かつ相互依存するタスクは単一エージェントの組織化能力を超えるため、システム知能には、明示的な作業編成、責任配分、協調、状態管理が必要である。単一エージェントのループは、コンテキスト内の競合と逐次処理主体の制御を生み、独立した作業の分離、同期、部分的な復旧を妨げる。能力やコンテキストの拡張、あるいは単なるエージェント数の増加では、こうした組織化上の限界は解消されない。出典：§1 · p. 5
  • グラフエンジニアリングは、実行に用いるグラフ構造によってタスクを編成し、異種エージェントの協調を図り、変化する実行時状態を管理することで、システム知能の基盤を提供する。タスク編成は、分解、依存関係、並行性、検証を表現する。エージェント間の協調は、割り当て、通信、同期、統合を構造化する。実行時状態管理は、進捗を追跡し、並行更新間の整合性を確保し、来歴を保持し、障害を分離して、復旧と適応を支援する。出典：§1 · p. 5
  • 今後の研究の方向性には、オントロジー工学、動的かつ自己進化するグラフシステム、グラフを基盤とするエージェント向けオペレーティングシステムが含まれる。出典：§1 · p. 6
  • 本サーベイは、モデル知能、個体知能、システム知能にわたるベンチマーク、データセット、実行可能な環境を、エージェントシステムの評価に関する原則や課題とともに整理する。評価上の論点には、構造の忠実性、動作の正しさ、システムの進化、ガバナンスが含まれる。出典：§1 · p. 6
  • 本サーベイは、エンジニアリングの技術スタックと応用を概観し、相互運用性、実行をまたぐ構造の進化、状態の来歴、持続的なシステム進化における不足を明らかにする。ソフトウェアスタックは、モデル開発、持続稼働するエージェント実行基盤、複数構成要素のオーケストレーションを支える。応用は、ソフトウェア工学、科学的発見、医療、企業の業務フロー、デジタルエージェント、社会・経済シミュレーションに及び、これらの分野では作業編成、協調、実行時状態管理がますます共通して求められている。出典：§1 · p. 6

2 基礎事項

個別エージェントは、基盤モデル、エージェントハーネス、反復的なエージェントループを組み合わせたものである。エージェントシステムは、共有資源、外部環境、協調機構、システム全体の実行時状態を通じて複数のエージェントを組織化する。

2.1 個別エージェント

  • 個別エージェントは、基盤モデルの認知能力と、資源へのアクセスや行動の実行を可能にするエージェントハーネスを組み合わせたものである。モデルは言語理解、推論、計画、生成を担う。ハーネスは、知覚とコンテキスト構築、記憶・知識へのアクセス、ツール呼び出し、再利用可能なスキル、実行時の管理・統制を提供する。出典：§2.1 · p. 6
  • エージェントループは、知覚、推論、行動、フィードバック処理、状態更新を繰り返し、エージェントの能力を継続的に活用する。エージェントは自律的であり、環境を知覚し、意思決定を行い、行動を実行し、フィードバックに応じて振る舞いを適応させる。出典：§2.1 · p. 6

2.2 エージェントシステム

  • エージェントシステムは、役割、能力、タスクが異なりうる複数のエージェントを、共有資源と外部環境を軸に組織化する。各エージェントは固有のモデル、ハーネス、ループ、局所状態を保持する。共有資源には、各エージェントがハーネスを介してアクセスするツール、モデルサービス、記憶、知識ベース、検証器、人間による支援が含まれる。環境は観測とフィードバックを提供し、エージェントの行動に応じて変化する。出典：§2.2 · pp. 6–7
  • 協調機構は協働を制御し、システム状態は個別エージェントの局所状態ではなく、システム全体の稼働状況を捉える。協調には、タスクの割り当て、情報交換、結果の統合、競合の解消、障害への対処が含まれる。システム状態には、タスクの進捗、共有された結果、エージェントの稼働可否、資源の状態、環境の変化、障害の記録が含まれる。出典：§2.2 · p. 7

3 モデル知能から個体知能へ

基盤モデルの学習がモデルの能力を確立し、プロンプトエンジニアリングとコンテキストエンジニアリングがその活用を方向づけ、ハーネスとフィードバック駆動のループが個々のエージェントの持続的な自律行動を可能にする。それでも、単一エージェントによる作業編成には、並列スケジューリング、独立した検証、追跡可能な障害復旧に限界がある。

3.1 基盤モデル：モデル知能の確立

  • 事前学習は汎用的な能力を確立し、事後学習は実演、選好、報酬、対話からのフィードバックを通じて、指示追従、アラインメント、推論、エージェントとしての行動を発達させる。事前学習では、データの精選、密なモデルまたは混合エキスパート型のアーキテクチャ、協調的な学習戦略を通じて、モデル規模、データ、計算資源のバランスを取る。事後学習では、教師ありファインチューニング、選好に基づくアラインメント、強化学習を組み合わせ、検証可能な報酬、ツール利用、環境との複数ターンの相互作用を取り入れる傾向が強まっている。出典：§3.1 · p. 8, §3.1.1 · pp. 8–9, §3.1.2 · p. 9

3.2 プロンプトエンジニアリングとコンテキストエンジニアリング：モデル知能の引き出しと条件付け

  • 推論時には、プロンプトエンジニアリングがタスクの指定、推論の構造化、指示の最適化を行い、コンテキストエンジニアリングがモデルのパラメータを変更せずに情報を取得、処理、維持する。プロンプトの最適化には実行軌跡や省察を利用できる。コンテキストの処理では順位付け、圧縮、枝刈り、再構成を行い、その管理では作業に有用な情報を継続的に保持する。Lost in the Middle は、コンテキストを長くするだけでは情報の効果的な活用が保証されないことを示している。出典：§3.2 · p. 9, §3.2.1 · pp. 9–10, §3.2.2 · p. 10

3.3 ハーネスエンジニアリング：エージェント能力の統合・制御

  • ハーネスエンジニアリングは、モデル呼び出しをまたいで持続するツール、インターフェース、実行環境を提供し、実行時のオーケストレーションが資源の編成、検証、保守、改善を統括する。ツール統合の対象は、関数呼び出しやAPIアクセスから、コード、ファイル、シェル、ブラウザ、さらに多様なコンピュータ操作へと広がっている。コンテキストエンジニアリングが各モデル呼び出しに提示する情報を決めるのに対し、ハーネスは呼び出しをまたいで資源と実行可能な機能を維持する。出典：§3.3 · p. 10, §3.3.1 · p. 10, §3.3.4 · p. 11
  • 記憶管理は呼び出しをまたいで再利用可能な経験を能動的に維持し、スキル合成は成功した手順と外部知識を、持続的に保持され進化する能力ライブラリへと変換する。記憶機構は、関係に基づく情報の構造化や実行状態の復元を支援するとともに、保存、検索、更新、統合、削除の制御を強めている。スキルエンジニアリングは、手順の再利用にとどまらず、構築、合成、フィードバック駆動の最適化、来歴管理、ガバナンス、ライフサイクルの保守、実行時コストの削減へと広がっている。出典：§3.3.2 · pp. 10–11, §3.3.3 · p. 11

3.4 ループエンジニアリング：エージェントの反復実行の実現

  • ループエンジニアリングは、制約付きの状態保持型フィードバック制御を用い、進捗と証拠に応じて実行を継続、修正、復旧し、上位判断に委ね、または終了する。目標、受入基準、未解決の要件、検証ゲート、資源制限、停止条件により、継続は自動的ではなく条件付きとなる。ResearchLoop は持続的な契約と証拠を維持し、Proof-or-Stop [131] はライフサイクルの遷移に際して、新たな機械的検証可能な証拠を要求する。出典：§3.4 · p. 12, §3.4.1 · p. 12

3.4.2 相互作用の枠組み

  • ループ内の相互作用は、タスク状態、行動意図、観測、検証結果、エラーを交換することで、制御器、モデル、ハーネス、監督者の間の連続性を維持する。Sovereign Agentic Loops [115] は、実行前に構造化された意図を状態および方針と照合する。AgentRx [19] は実行軌跡から障害箇所を特定し、Supervising Ralph Wiggum [407] は反復的な改善が停滞した際にメタ認知的な監督を加える。出典：§3.4.2 · p. 12

3.4.3 環境フィードバック

  • 環境フィードバックは、観測された状態変化を証拠に変換し、ループが進捗を受け入れるか、再試行、再計画、状態復元、上位への判断委譲を行うかを決定する。意図した効果、実際の状態遷移、観測された結果は異なり得るため、観測は現在の状態を反映し、その後の判断を正当化する必要がある。ここで扱うのは、環境から得られた結果がループの継続をどう制御するかであり、ハーネスが提供する実行環境ではない。出典：§3.4.3 · pp. 12–13, §3.4 · p. 12

3.5 個体知能の限界

  • 個体知能には依然として、タスクの逐次的なスケジューリング、専門的役割と検証の独立性不足、持続的な状態の維持と障害復旧の難しさによる限界がある。逐次実行は並列性を活かせず、誤った中間結果を伝播させるおそれがある。制御の共有は役割の混同や確証バイアスを生み得る。コンテキストだけでは体系的に管理された持続的な状態にはならず、誤りの箇所を特定し、影響を受けた工程を追跡可能な形で修復することが難しい。出典：§3.5 · pp. 13–14

4 グラフエンジニアリング：個体知能からシステム知能へ · 4.1 グラフエンジニアリングの概要

グラフエンジニアリングは、グラフ構造によってタスク、構成要素、実行時状態の関係を外在化し、システム全体の組織化、協調、監視、復旧、最適化を支える。

4.1 グラフエンジニアリングの概要

  • 単一エージェントでは、並列かつ相互依存するタスク、異質な能力、実行時状態への対応が難しい。そのため、共有目標のもとで相補的な構成要素が適応的な全体を形成することが求められる [154] [159]。出典：§4.1 · p. 14
  • システム知能には、単なるエージェントの寄せ集めではなく、関係の明示的な表現、制約付与、最適化が必要である。これにより、スケジュール可能なタスク、能力を考慮した協調、永続化と復旧が可能な実行時状態を支える。こうした要件により、タスク、構成要素、実行時状態の関係の管理が、システム知能の中核となる。出典：§4.1 · p. 14
  • グラフは、目標の分解、依存関係のモデル化、ワークフローの精緻化を通じて、複雑な目標をスケジュール可能かつ実行可能な操作へと変換する [91] [158] [280]。出典：§4.1 · p. 14
  • グラフは、協働を可能にする実行トポロジーと通信パターンを表現し、異質な知的構成要素の協調を図る [69] [79] [205] [433]。出典：§4.1 · p. 14
  • グラフは、イベント、依存関係、状態遷移を記録し、コンテキストやログに散在する情報を、監査・復旧可能なシステム状態へと変換する [35] [41] [467]。出典：§4.1 · p. 14
  • グラフエンジニアリングは、グラフ構造を、システム全体でタスクを組織化し、構成要素の協調を図り、実行時状態を管理するための基盤と位置づける。実行からのフィードバックと状態を示す証拠が、構造の反復的な改善とシステム知能の継続的な進化を支える。出典：§4.1 · p. 15

4.2 タスク編成：実行内容の構造化

タスク編成は、目標と実行可能な操作を、スケジューリング・最適化・修正が可能なグラフ構造として外在化する。目標分解はサブタスク間の依存関係を明示し、ワークフロー最適化は実行可能な操作を構築して、実行時のフィードバックに基づき適応させる。

4.2.1 目標分解

  • 目標分解は、目標を明示的な部分目標グラフで表現し、辺に先行関係、データ依存、論理的依存を符号化することで、協調的なスケジューリングを可能にする。これらのグラフは、ワークフロー構築と実行時の適応に向けた目標空間を定義する。部分目標グラフとワークフローグラフは、暗黙的な推論と行動を、スケジューリング・最適化・修正が可能な作業構造に置き換える。出典：§4.2.1 · p. 15, §4.2 · p. 15, §4.2.2 · p. 16
  • スケジューリング可能なタスクグラフは依存制約下での並列実行を可能にし、動的分解は中間結果が得られるたびにタスクを精緻化する。LLMCompiler [156] はデータフローDAGの実行可能なノードを並列に実行へ回し、Plan-over-Graph [464] は依存制約下で並列化可能なスケジュールを生成する。TDAG [362] とFlow は実行中にタスク分解を精緻化する。進化するグラフは、エージェント生成、タスク割り当て、並列協調も駆動できる 。出典：§4.2.1 · p. 15

4.2.2 ワークフロー最適化

  • ワークフロー最適化は、意味レベルの部分目標を実行可能なグラフへコンパイルし、オペレータノードと依存関係の辺によってスケジューリング、協調、検証を支える。オペレータには、LLM呼び出し、専門エージェント、検索モジュール、ツール、メモリ操作、集約器、検証器などが含まれる。出典：§4.2.2 · p. 15, Figure 6 · p. 16
  • ワークフロー探索は、オペレータの動作、グラフの接続、実行可能な制御フローを最適化し、手作業で設計されたエージェント処理系列への依存を減らす。GPTSwarm はノードと辺を最適化し、AFlow は実行可能なワークフローコードを探索する。A2Flow [473] は実演からオペレータを学習し、MermaidFlow [476] は構造化された中間表現と安全性制約下での進化を組み合わせ、VFlow [373] は領域固有の検証器を組み込む。出典：§4.2.2 · p. 16
  • 実行時適応は、中間フィードバックに基づいてワークフローグラフを修正し、開放的な環境で静的最適化では防げない失敗に対処する。DyFlow [363] は後続のオペレータ部分グラフを生成・調整し、残りの部分目標も修正しうる。EvoFlow [450] は推論中に多様なワークフロー候補を進化させる。QualityFlow [127] は品質信号に基づいて受理、デバッグ、明確化、ロールバック、継続のいずれかを選択し、FlowSteer [181] は実行中にワークフロー構造を変更する。出典：§4.2.2 · p. 16

4.3 エージェント間の協調：作業の担い手の構造化

エージェント間の協調では、グラフ構造を用いて能力をモデル化し、チームの責任分担を組織し、実行時の通信を管理する。これらの機能が一体となり、誰が作業を担うか、責任をどう配分するか、実行の進行に伴って相互作用をどう適応させるかを決定する。

4.3.1 エージェントの能力モデリング

  • 永続的で更新可能な能力グラフにより、エージェントの専門性、資源、権限、信頼性を検索でき、タスク割り当てや再構成に再利用できるようになる。既存手法は、再利用可能な関係ではなく、スコアやルーティング方策として能力を表すことが多い。SkillGraph [254] と MaAS [451] は能力をグラフによる組織化に結び付けているが、その表現は依然として特定のタスクやオーケストレーションに依存している。出典：§4.3.1 · pp. 17–18

4.3.2 エージェントのチーム編成

  • チーム編成グラフは、割り当て、引き継ぎ、委任、監督、検証、報告を規定することで、エージェントの能力を実行可能な分業へと具体化する。単一のシステム内で、専門エージェントへのルーティング、並列実行、出力集約、評価者の連鎖を組み合わせられる。そのグラフは、安定した責任分担とタスクに応じた構造変化の両方を表現する必要がある。出典：§4.3.2 · p. 18
  • チェーン、専門エージェントへのルーティング、ファンアウト／ファンイン構造は、それぞれ段階間の依存関係、異種の専門性、並列での候補生成に対応し、協調上のトレードオフも異なる。チェーンは実行順序を明確にするが、経路の大部分を事前に固定する。集中型ルーティングは調整役のエージェントに負荷をかけうる。並列分岐と集約は推論の多様性を高める一方、通信、計算、集約のコストを増加させる。出典：§4.3.2 · p. 18
  • チーム構造は、タスク要件やエージェントの性能が変化しても固定されたままである必要はなく、設計時の最適化と実行時の再構成を通じて進化できる。Puppeteer [53] はエージェントを動的に選択し、実行順序を決定する。AgentNet は中央制御器なしで接続とルーティングを調整する。SwarmAgentic はエージェントの機能と協働パターンを同時に最適化する。また、自己組織化エージェントの研究 [60] は、専門化と浅い階層構造が創発しうることを示唆している。出典：§4.3.2 · p. 18

4.3.3 マルチエージェント通信

  • 通信の最適化は、タスク性能、通信コスト、頑健性の均衡を取りながら有用な情報伝達経路を選択し、実行時のフィードバックに基づいてそれらの経路を適応させる。各手法は、冗長な接続や貢献度の低いエージェントを削減し、情報の必要性に応じて疎な辺を再構築する。フィードバックには能力や資源の変化を反映でき、実行履歴からは再利用・改訂可能な通信設計規則が得られる。出典：§4.3.3 · p. 19
  • 通信グラフには、要件の明確化、誤りの修正、出力の評価、行動の承認、実行中の制御の引き継ぎを担う能動的な協働者として、人間を組み込める。暗黙の選好、専門知識、高リスクの行動にエージェントのフィードバックだけでは確実に対処できない場合、人間の参加が重要である。支援、フィードバック、承認、上位判断への付託を表す辺により、人間を最終評価だけでなく、進行中のフィードバックループに組み込む。出典：§4.3.3 · p. 19
  • 通信グラフは、チーム編成が表す比較的安定した役割や責任分担とは異なり、実行時の情報交換とフィードバックを捉える。有効化された辺は、誰がどの情報を交換し、それが後続の行動をどう変えるかを規定する。生成・評価・修正のループは誤りの検出と修正に役立つが、接続を増やせば必ず協働が改善するわけではない。出典：§4.3.3 · p. 19

4.4 実行時状態管理：システムの動作を構造化する

実行時状態管理は、状態記録、証拠に基づく障害箇所特定、検証済み状態からの復旧によって、分散実行を追跡可能にする。これらの機能は、監視、診断、復旧、システムの継続的な進化を支える。

4.4 実行時状態管理：システムの動作を構造化する

  • 実行時状態管理は、実行時状態の一貫した認識を維持し、実行の逸脱を特定し、検証済み状態から実行を復元または方向転換することで、タスク編成とエージェント間協調を補完する。信頼できる実行記録がなければ、エージェント間で状態認識に不整合が生じ、障害箇所の特定や有効な進捗の復元が困難になる。出典：§4.4 · pp. 19–20, Figure 8 · p. 20

4.4.1 状態記録

  • 状態記録は、構造化された表現、管理された更新、可視範囲の制御、整合性管理を備えた、明示的かつ照会可能な実行記録に、状態遷移の証拠、来歴、版を保存する。提案・検証・コミットの境界は、提案された変更と正式な状態を区別する。一方、並行する書き込み主体には、分離、因果順序の維持、競合解決が必要である。イベントソーシングに基づく設計は、再構成、再実行、分岐のために、追記専用の確定済み履歴を保存する [252]。出典：§4.4.1 · p. 20
  • 既存の状態記録研究は信頼性要件を確立しているが、統一的なグラフネイティブ実装はまだ提供していない。出典：§4.4.1 · p. 20

4.4.2 障害箇所特定

  • 障害箇所特定は、実行時記録と外部の証拠を用いて障害を検出し、その影響を追跡し、原因候補を検証し、復旧に向けて実行のどの部分が有効かを判定する。誤りは、顕在化する前にタスクやエージェントをまたいで伝播しうる。時間的・構造的なつながりだけでは因果関係は確立されない。実行主体、状態遷移、依存関係、検証の証拠、証拠に裏付けられた診断を保存することが、原因の帰属とその後の復旧を支える。出典：§4.4.2 · p. 21

4.4.3 障害復旧

  • 障害復旧は、状態間の依存関係と外部への影響を考慮しつつ、有効な作業成果を保持し、明示的な復旧境界から実行を選択的に修復する。復旧では、無効な状態の取り消し、計算の再実行、外部への影響の補償、代替実行への分岐が可能である。再構成可能な内部状態と、補償を要する影響は区別される。復旧境界、是正措置、その結果の状態を記録することで、記録・診断・復旧の循環が完結する。出典：§4.4.3 · p. 21

4.5 システムの進化

システムの進化は、タスク編成、エージェント間の協調、実行時状態管理を改良し、実行時の経験を実行をまたいだ改善につなげる。検証とロールバックは、信頼できる改善を維持しつつ、失敗をその後の意思決定に生かすことで、この循環を完結させる。

タスク編成の進化

  • タスク編成では、実行からのフィードバックを基に分解方法、依存関係、ワークフローを進化させるが、構造の変更には信頼できるシグナルが必要である。TDAG [362] はタスクを動的に分解して専門エージェントを生成し、DynTaskMAS は依存関係を維持し、EvoFlow [450] はワークフロー候補を進化させ、QualityFlow [127] は品質検査に基づいて続行、確認、差し戻しを行う。FlowSteer [181] は、改ざんされた計画シグナルが、再計画や依存関係の形成を望ましくない実行経路へと誘導しうることを示している。出典：§4.5 · p. 22

エージェント間協調の進化

  • エージェント間の協調では、タスク要件や構成要素の能力の変化に応じて、協働経験を通じてチーム構造と通信パターンを進化させる。SwarmAgentic はエージェントの機能と協働構造を同時に最適化し、AgentNet は各エージェントの専門性と文脈に基づいて接続関係とタスクの振り分けを調整する。DyTopo [228] は推論の各ラウンドで通信経路を再構築し、QueenBee Planner [335] は実行履歴と評価から再利用可能な通信設計規則を抽出する。出典：§4.5 · p. 22

実行時状態管理の進化

  • 実行時状態管理では、再利用可能な経験を蓄積するとともに、永続状態を検証・修正して誤った知識の伝播を防ぐ。ReCreate [112] は成功と失敗から領域固有のパターンを抽出し、SkillGraph [254] は失敗を推論のヒューリスティクスに変換し、Swarm Skills [470] は成功した協調スキルを抽出・改良する。MemTX [195] は暫定的な書き込みと検証済みのコミットを分離し、撤回された信念に伴う不整合を修復する。ActiveGraph [252] はイベントソーシングに基づく履歴を保持し、決定論的な再実行と過去の状態からの分岐を可能にする。出典：§4.5 · p. 22

システムの進化

  • システムの進化は、実行、経験、システム全体の更新を結び付け、成功した戦略を蓄積し、失敗をその後の意思決定に生かす。検証とロールバックの仕組みは、実行時の適応にとどまらない信頼性の高い改善を支える。出典：§4.5 · pp. 22–23

5 未解決課題と研究機会

Graph Engineeringは、タスク固有の構造から、相互接続されたグラフを一貫して解釈し、確実に実行し、継続的に進化させる再利用可能な基盤へと発展する必要がある。主要な研究の方向性は、グラフネイティブな能力、制御された構造進化、共通の実行基盤、プライバシーと倫理の保護である。

5.1 グラフネイティブな能力基盤

  • 統合能力グラフは、モデル、ツール、スキル、記憶、データソース、検証器、実行環境を、タスクグラフ、エージェントグラフ、実行時状態グラフと結び付けるべきである。現在は暗黙的な能力間の関係を、依存、互換性、合成、代替、認可、コスト、信頼性を表す型付きエッジとして明示する。タスク分解によって必要な能力を明らかにし、エージェントの割り当てでは利用可能な能力部分グラフを考慮し、実行結果に基づいて能力の信頼性と適用可能性を更新する。出典：§5.1 · p. 23

5.2 自己進化型グラフシステム

  • 自己進化型グラフシステムは、個々の実行軌跡を適応させるだけでなく、実行から得た証拠を永続的かつ再利用可能な構造変更へと変換しなければならない。これには、観測、構造への貢献度割り当て、修正、検証、コミットまたはロールバックが必要であり、変更が現在の実行を超えて一般化するかの判断も含まれる。タスク、エージェント、能力、状態の各グラフにまたがる変更は、共通の制約を守り、来歴管理、バージョン管理、検証、再実行、ロールバックを通じて統制可能でなければならない。出典：§5.2 · pp. 23–24

5.3 グラフネイティブなエージェントOS

  • グラフネイティブなエージェントOSは、型とバージョンを持つタスク、エージェント、能力、状態の各グラフと共通の実行時サービスを通じて、断片化した基盤を統合しうる。オントロジー工学が型、関係、制約を定義し、実行時サービスがスケジューリング、能力探索、保存、権限管理、来歴管理、構造トランザクション、チェックポイント、再実行、ロールバック、可観測性を通じて、その意味論を強制する。実行トレースを生成元の構造に結び付けることで、変更候補を履歴や反実仮想に基づいて評価し、検証済みの改善を新たなグラフバージョンとしてコミットできる。出典：§5.3 · p. 24

5.4 プライバシーと倫理

  • 分散型で永続性を持つエージェントシステムは、プライバシーと説明責任に関するリスクを高めるため、プライバシーを保護する状態管理、適用範囲を限定した権限、来歴を考慮したログ記録、人間による厳格な監督が必要である。機密情報は構成要素間に広がり、タスクをまたいで残存しうるため、不正アクセス、タスク間の情報漏えい、実行トレースからの私的属性の推測を可能にする。偏った証拠、誤った推論、敵対的入力がシステム全体で増幅される場合、分散した意思決定は責任の所在の明確化を困難にする。出典：§5.4 · p. 24

6 今後の方向性：次世代システム知能のためのオントロジーエンジニアリング

オントロジーエンジニアリング は、明示的なグラフ構造だけでは保証できない、機械が解釈可能な共有意味を提供する。今後は、オントロジーをシステム知能の完全な解決策とみなすのではなく、モジュール型オントロジー、実世界に接地した共有意味、厳密なシステムレベルの評価、ガバナンス下での実行時の強制適用に取り組む必要がある。

6 今後の方向性：次世代システム知能のためのオントロジーエンジニアリング

  • オントロジーエンジニアリング は、グラフ構造の接続、検証、再利用、進化に必要な共通の実体・関係・制約を定義し、グラフエンジニアリングを補完する。開放的で長期間稼働する環境では、グラフのビュー、構成要素、実行段階の間で概念の意味が食い違うことがある。共有意味は基盤となるが、目標形成やシステムレベルの評価に関する課題をすべて解決するわけではない。出典：§6 · pp. 24–25, §6.1 · p. 25

6.1 グラフエンジニアリングに基づくシステム知能の限界

  • システム知能の評価では、組織化による寄与を、より高性能なモデル、より長いコンテキスト、推論サンプル数の増加、計算コストの増大による改善と区別しなければならない。評価は、目標形成、意味的一貫性、並列効率、異種能力の割り当て、集団的意思決定、状態の一貫性、復旧、転移、実行時の追加負荷を対象とすべきである。不完全な目標、並行する処理負荷、分散した情報、障害、環境変化について、介入、構造的アブレーション、実行トレース分析を用いて検証すべきである。出典：§6.1 · p. 25
  • システムのオントロジーは、単一の一枚岩的なモデルを要求するのではなく、共通の中核に専門モジュールと領域別拡張を組み合わせるべきである。モジュールは、目標と価値、エージェントと能力、観測と証拠、行動と状態、評価基準を扱う。オントロジーはグラフへの注釈付与にとどまらず、実体、関係の意味、必要な制約、導出可能な結論を定義し、完了、証拠、妥当な状態、権限内の行動をめぐる見解の相違に対処する。出典：§6.1 · p. 25

6.2 目標形成と価値整合

  • 目標オントロジーは、来歴、優先度、権限の範囲、完了基準、制約を明示し、競合や無権限の変更の検出、完了を裏付ける証拠の検証を可能にする。目標オントロジーは、システムが採用すべき価値を決めることはできない。その役割は、目標と規範的制約を明示して検証可能にし、意味的制約を外部化してエージェント間で共有できるようにすることである。出典：§6.2 · p. 25

6.3 共有意味と実世界への接地

  • 意味的一貫性だけでは事実の正しさを保証できないため、共有意味はツール出力、観測、タイムスタンプ、来歴、検証結果に接地させる必要がある。エージェントは、構造的制約、来歴、人間による監督を維持しながら、オントロジーの構築、拡充、整合、更新を支援できる。意味概念は、実行可能な能力やツールのインターフェースにも結び付けるべきである。出典：§6.3 · p. 26

6.4 システム知能の測定

  • オントロジーに基づく測定は、成功、失敗、エージェントの寄与、復旧、状態の一貫性、実行時コストを標準化し、システムの組織化の比較を支える。構成、事象、証拠、介入、結果の共通表現により、トレースの比較可能性が高まり、構造的アブレーションと因果分析が可能になる。オントロジーは、指標が基盤モデル、個々のエージェント、システムの組織化のいずれに関するものかを明確にするが、評価手法に取って代わるものではない 。出典：§6.4 · p. 26
  • オントロジーのガバナンスは、検証済みの意味変更とライフサイクル管理を、権限、証拠要件、妥当な状態遷移の実行時の強制適用に結び付けなければならない。LLMが提案する概念と関係には、来歴の確認、一貫性検証、影響分析が必要である。進化するオントロジーには、バージョン管理、互換性確認、移行、ロールバックも必要となる。オントロジーは概念モデルを定義し、グラフはタスク固有の構造を具体化し、実行時機構はそれらから導かれる運用上の要件を強制適用する。出典：§6.4 · p. 26

7 ベンチマーク、データセット、評価

評価は、範囲が限定されたモデル出力、単一エージェントの継続的な実行軌跡、複数の構成要素からなるシステムの組織化を軸に整理される。グラフエンジニアリングに基づくシステムでは、構造・運用・ガバナンスの検証も必要である一方、公平な貢献の帰属と継続的なシステム進化は未解決の課題である。

7 ベンチマーク、データセット、評価

  • 評価資源はモデル知能、個体知能、システム知能に分類され、範囲が限定された相互作用、単一エージェントの継続的な実行軌跡、複数の構成要素が協調するシステムを区別する。ベンチマークはタスク、評価手順、採点方法を定義し、データセットは再利用可能な事例、アノテーション、グラフ、記録、実行履歴を提供する。環境は観測・変更可能な実行状態を公開する。これら3種類の資源は重複しうる。出典：§7 · p. 26

7.1 モデル知能

  • モデル知能は範囲が限定されたモデル出力を評価し、継続的な相互作用や環境状態は概ね対象外である。ベンチマークは知識、推論、指示追従、コード生成、マルチモーダル理解、検索拡張推論を対象とする [33] [117] [487]。LiveBenchは問題を更新してデータ汚染を抑え 、NPPCは難易度を調整可能な、自動検証できるNP完全問題のインスタンスを生成する 。出典：§7.1 · pp. 26–27

7.2 個体知能

  • 個体知能は、外部機能、永続的な記憶、適応を含むエージェントの継続的な実行軌跡を評価するが、タスクの組織化は単一エージェントまたは局所的な実行環境を中心とする。A2Eは標準化された実行履歴を記録し、効率、ツール使用、計画、エラーからの回復を評価する [345]。Evo-Benchは、モデルが自身のエージェントハーネスを改善できるかを評価する [133]。出典：§7.2 · p. 28

7.3 システム知能

  • システム知能は作業の組織化、協調、実行時状態を評価するが、反復実行を通じた持続的かつ転用可能な改善は十分に検討されていない。MASEvalはトポロジー、オーケストレーション、フレームワーク、実行環境の設計を評価変数として扱う [72]。BenchAgentは統制された評価手順の下で、単一エージェント、固定構成のマルチエージェント、進化するワークフローを比較する [88]。出典：§7.3 · p. 28

7.4 評価原則と未解決課題

  • 評価では、有効性、効率、頑健性に加え、構造の忠実性、操作の正しさ、進化とガバナンスを測定すべきである。これらの追加的な評価軸は、構造が妥当か、グラフ操作が正しく実行されるか、構造変更の追跡可能性と制御可能性が保たれるかを評価する。出典：§7.4 · p. 28
  • システムレベルの性能向上を検証するには、モデル性能、コンテキスト、ツール、再試行、計算資源を統制する必要がある一方、評価の断片化、不十分な構造的貢献度の割り当て、動的評価が課題として残る。今後のベンチマークでは、条件間で揃えた実行予算、版管理されたグラフ成果物、完全な実行履歴と状態スナップショット、統制された構造的摂動、タスクと時間をまたぐ反復評価を提供すべきである。出典：§7.4 · p. 28

8 オープンソースライブラリとエンジニアリングのエコシステム

エコシステムはモデル基盤、永続的なエージェント実行環境、複数構成要素の組織化にまたがり、機能の排他的な区分ではなく、主たる設計対象によって分類される。主要な課題は、インターフェースと状態の分断、実行をまたぐ構造進化の限界、システム改善に至る因果関係の追跡不足である。

8 オープンソースライブラリとエンジニアリングのエコシステム

  • ライブラリは、知能の階層をまたいで機能が重複するため、モデル能力、永続的なエージェント実行環境、複数構成要素の組織化という主たる設計対象によって分類される。対象とするには、ソースコードと文書が公開され、知的システムの構築または実行に関連する再利用可能な抽象化を備えている必要がある。ソース公開型のプロジェクトもライセンス条件を明示したうえで含める。汎用ユーティリティや分野特化型アプリケーションには、直接関連する再利用可能な抽象化が求められる。出典：§8 · p. 29

8.1 モデル知能

  • モデル知能のライブラリは、モデルインターフェース、分散事前学習、事後学習、強化学習パイプライン、推論基盤を通じて、モデルのパラメータと実行を設計・最適化する。例として、TransformersとMegatron Core [323]、LLaMA-Factory、verl、slime 、vLLMとSGLang [163] [479]がある。強化学習パイプラインは学習、ロールアウト生成、報酬を結び付け、エージェントによる自律的な環境との相互作用も取り込むようになっている。推論エンジンもロールアウト基盤を提供する。出典：§8.1 · p. 29

8.2 個体知能

  • 個体知能のフレームワークは、権限、検証、セッション、状態、人間による制御、明示的なワークフロー遷移を用い、モデルとツールのループを永続的かつ観測可能な実行へと変える。LangChain、OpenAI Agents SDK、Claude Agent SDK、Pydantic AIは、モデルとツールのループおよび実行時の制御機能を提供する 。LlamaIndex Workflows、Haystack、Burrは、コンテキスト構築、ワークフロー遷移、イベントのルーティング、永続的な実行を重視する 。出典：§8.2 · p. 29
  • エージェント実行環境は、システムの組織化を主要な抽象化とするとは限らず、長期記憶、時間的知識、標準化された機能アクセス、視覚的なワークフロー構成も統合する。Lettaは永続的な状態と記憶を維持し、Graphitiは変化する文脈的知識を来歴付きの時間グラフとしてモデル化する [296]。MCPはツール、リソース、プロンプトの公開方法を標準化し 、LangflowとDifyは視覚的なワークフロー構成を提供する 。出典：§8.2 · p. 29

8.3 システム知能

  • システム知能のフレームワークは、グラフ実行、メッセージパッシング、組織的抽象化を通じて、タスク、エージェント、実行器、共有状態を明示的に組織化する。LangGraph、Microsoft Agent Framework、Google ADKは、条件分岐、並行、循環、協調による実行を支援する 。CrewAIはCrewsとFlowsを分離し、CAMELはタスク分解と階層的なワーカー協調を組み合わせる [182]。Mastraはエージェント、ワークフロー、永続的な実行状態を統合する 。出典：§8.3 · pp. 29–30

8.4 エンジニアリングのエコシステムにおける未解決課題

  • 互換性のない実行意味論と表現が知能スタックを分断している。MCPは機能の相互運用性を高めるが、実行可能なシステム組織構造までは標準化しない。マルチエージェントシステム間では、タスク依存関係、能力、権限、通信、実行時状態の表現が共有されることはまれである。出典：§8.4 · pp. 30–31
  • 現在のフレームワークの多くは、事前定義された構造内で実行を変化させるにとどまる。実行をまたぐ永続的なトポロジー進化は依然としてまれであり、実行の証拠を構造改善に再利用することが制限されている。GPTSwarmはノードのプロンプトとエージェント間の辺を最適化する 。条件付きルーティング、並列分岐、ワーカー割り当て、復旧は、将来の実行を規定する永続的な組織構造を変えることなく、実行経路を変更できる。出典：§8.3 · p. 30, §8.4 · p. 31
  • 状態の分断と因果追跡の弱さを背景に、型とバージョンを備えた構造が求められる。その構造には、検証済みの構造変更トランザクション、来歴、再実行、ロールバック、制御された改善の保持が必要である。状態は、チェックポイント、記憶、ワークフローのスナップショット、履歴、ログ、時間的知識ストアに分散している。グラフ単位の追跡と反実仮想比較によって、観測、意思決定、構造変異、失敗、復旧、その後の改善を結び付けるべきである。出典：§8.4 · p. 31

9 グラフエンジニアリングの応用

さまざまな応用分野で、グラフエンジニアリングは作業、専門家チーム、永続的な実行時状態を組織化する役割を強めているが、これらの構造の持続的な進化は依然としてまれである。多くのシステムは、蓄積した根拠に基づいて組織構造を恒久的に改訂するのではなく、事前定義された組織構造の中で実行を適応させている。

9.1 ソフトウェア工学とIT運用

  • ソフトウェア工学では、並行ブランチ、依存関係、テスト、マージの管理が進んでおり、Project ALICEはテレメトリとソフトウェア依存関係の根拠に基づいてIT専門家を連携させる 。MetaGPTとChatDevは段階的に連携する専門家チームを導入し [119]、SWE-agentはリポジトリのインターフェースを重視し [418]、OpenHandsは永続化されたイベントを介してツールと委譲を結び付けた 。残る課題は、計画、コードの依存関係、責任の所在、外部への副作用、テスト、復旧を結ぶ構造を版管理し、作業編成が成功する理由を説明できるようにすることである。出典：§9.1 · p. 31

9.2 科学的発見と実験室の自動化

  • 科学研究エージェントは仮説–実験間のフィードバックループを閉じるようになっているが、再現可能なグラフエンジニアリングには、根拠と依存関係を保存しつつ、根拠に応じてシステムの組織構造を再編できることが必要である。Co-Scientistは生成、批評、順位付け、改良を連携させ [99]、Robinは実験室での結果を後続の仮説に取り込み 、Virtual Labは専門家チームを実物による検証につなぐ 。仮説の改良だけでは組織の進化とはいえない。より高度なシステムは、否定的な結果、データの来歴、実験的介入、因果的依存関係を保存しなければならない。出典：§9.2 · p. 33

9.3 医療と臨床意思決定支援

  • 臨床におけるグラフエンジニアリングは、来歴、不確実性、アクセス境界、人間による承認を維持しつつ、専門家と経時的な状態を統合的に管理しなければならない。グラフによる組織化だけでは臨床的な正しさは保証されない。DeepRareは、追跡可能な診断根拠を蓄積しながら、表現型、遺伝子型、検索、分析の各エージェントを連携させる 。AMIEは対話状態を、長期的な管理に関する推論や変化するケア計画から分離し 、過去の症状、治療、治療反応が後の行動にどう影響するかを示している。出典：§9.3 · p. 33

9.4 企業のワークフローとデジタル組織

  • 企業向けグラフエンジニアリングは、権限、職務分離、方針、トランザクション境界、ロールバック義務を徹底しつつ、計画されたワークフローとコミット済みの外部状態を区別しなければならない。WorkTeamとSOANは、ワークフロー構築エージェントと再利用可能な階層型ワークフローを組織化する [396]。Gemini Enterprise Agentic RAGは情報の充足度を確認し、必要な情報が不足していれば検索を継続する 。出典：§9.4 · p. 33

9.5 汎用デジタルエージェントと個人業務の自動化

  • 持続稼働するデジタルエージェントは、セッションをまたぐ状態と再利用可能な能力を維持するが、現在の実行をまたぐ適応は、まだ一般的な構造的自己進化には至っていない。OpenClawは識別情報、ワークスペース、認証、セッション、チャネルを分離し 、Hermes Agentは委譲、スケジューリング、永続メモリ、再利用可能なスキルを組み合わせる 。残る課題は、検証、版管理、変更の取り消しを伴う形で、どの経験を将来の作業構造、能力の割り当て、エージェント間の関係の変更に反映すべきかを判断することである。出典：§9.5 · pp. 33–34

9.6 社会・経済シミュレーション

  • 社会・経済シミュレーションは相互作用のトポロジーと変化する共有状態を可視化するが、観測に基づく較正と不確実性分析なしには、シミュレーション上の創発から現実世界の因果関係を確立することはできない。エージェント間の相互作用と局所的な意思決定は、後続のエージェントが直面する環境を変化させる。グラフエンジニアリングに基づくシミュレータは、トポロジーへの介入、再実行、統制されたアブレーションを可能にしつつ、モデル、ペルソナ、トポロジー、メモリ、プロンプト、環境規則に関する仮定を明示できる。出典：§9.6 · p. 34

9.7 分野横断的な知見

  • 作業編成とエージェントチームは広く普及し、実行時状態の管理も明示化が進んでいるが、システムの持続的な進化は依然としてまれである。応用システムでは、チェックポイント、共有タスクボード、イベントストリーム、経時的記録、変化する環境が明示される。多くは、事前定義された組織構造を恒久的に改訂するのではなく、その構造内で実行を適応させている。出典：§9.7 · p. 34
  • システム知能に必要なのは、単なるエージェントの追加や明示的なグラフ構造ではなく、工学的に設計された協調である。システムの価値は、作業分解、責任の割り当て、共有状態、障害の診断と復旧に依存する。完全なグラフエンジニアリングには、さらに構造上の目標、グラフレベルの可観測性、制御された構造変更、構造間の整合性、そして構造改善の効果が持続し、他の状況にも転移することを示す根拠が必要である。出典：§9.7 · p. 34

10 結論

本サーベイは、単にエージェントを増やすのではなく、作業・エージェント・実行時状態の関係を明示的に組織化する、システム知能のための構造中心のパラダイムとして、グラフエンジニアリングを提示する。

10 結論

  • システム知能は、複雑な目標を体系化し、異種の構成要素を協調させ、タスクの全期間を通じて一貫した実行時状態を維持する。エージェントは持続的な対話、ツール利用、反復実行を支援するようになったが、単一のループでは並列作業、専門知識の活用、独立した検証、状態の永続化への対応が難しい。出典：§10 · p. 34
  • グラフエンジニアリングは、グラフによる抽象化を用いてシステム内の関係を明示し、運用可能かつ適応可能にする。本サーベイの中心的な教訓は、システムレベルの知能が、単にモデルやエージェントを増やすことよりも、作業・実行主体・状態の関係を組織化することに依存するという点である。出典：§10 · pp. 34–35
  • 相互補完的な3つのグラフの視点が、作業の組織化、エージェント間の協調、実行時状態の管理を担う。グラフはタスク・エージェント・状態を表現するだけでなく、作業のスケジューリング、能力の割り当て、実行の追跡、障害箇所の特定、制御された進化を支える。出典：§10 · p. 35
  • グラフエンジニアリングは依然として発展途上の分野であり、意味的整合性、グラフのガバナンス、評価、プライバシー、安全な自己改善に課題を抱える。本サーベイは、グラフを基盤とするインフラを、より拡張性・制御性・進化可能性の高いエージェントシステムへと導くことを目指す。出典：§10 · p. 35

11 付録

グラフエンジニアリングは、グラフを個別のエージェント能力を強化する仕組みではなく、タスク、エージェント、実行時状態を組織化する明示的な構造として扱う。本付録では、このシステムレベルの射程を、能力、実行基盤、進化を中心とするサーベイと区別する。

11.1 関連サーベイとの比較

  • エージェント全般のサーベイ やグラフとエージェントに関するサーベイ [20] [218] は、能力を特徴づけるものであり、システム知能に至るエンジニアリングの全過程を体系化するものではない。計画、推論、記憶、ツール利用、環境との相互作用、実行、マルチエージェント協調を対象とする。出典：§11.1 · p. 62
  • 基盤技術のサーベイは、主にエージェントランタイム, 、外部化された能力とコード中心のハーネス [255] [484]、または実行可能なワークフロー [432] [443] を検討する。実行ループ、ツールインターフェース、コンテキスト管理、永続状態、ライフサイクル制御、評価、ワークフロー最適化を扱い、個体知能およびタスク編成の一部と対象が重なる。出典：§11.1 · p. 62
  • システム指向のサーベイは、オーケストレーション 、協働と自律的進化 [284]、構成要素の継続的改善 [90] を扱い、グラフエンジニアリングが重視する組織化の問題に近づいている。これに対し、本サーベイはタスク編成、エージェント協調、実行時状態管理を相互に結びついた構造として体系化し、システム進化とオントロジーエンジニアリングで補完する。出典：§11.1 · p. 62

11.2 エージェントにおけるグラフベース手法との違い

  • グラフエンジニアリングは、グラフをシステムの組織化基盤とし、タスクの依存関係、エージェントの能力と責務、実行時の実行状態を一体的に表現する。これらの構造は連動する。タスクの変更は必要な能力と割り当てに影響し、エージェントの変更は通信と実行の前提に影響する。また、実行時に得られる証拠は、その両方の見直しにつながりうる。出典：§11.2 · pp. 62–63
  • システム進化は経験に基づく構造的改善を保持し、オントロジーエンジニアリングは実体、関係、制約について、機械が解釈できる共通の定義を提供する。改善は検証、保持、再利用が可能であり、実行をまたいで適用したり元に戻したりできる。進化を中心とする動的グラフの視点 とは異なり、グラフエンジニアリングは進化をシステム知能の組織化における一側面として扱う。出典：§11.2 · p. 63
  • グラフエンジニアリングは、設計対象をモデルの振る舞いやエージェントの継続的な実行から、明示的に調整されたシステムレベルの関係へと拡張する。プロンプトエンジニアリングとコンテキストエンジニアリングは、能力の引き出し方と利用可能な情報を制御する。ハーネスエンジニアリングは実行可能な能力を提供し、ループエンジニアリングはフィードバックに基づく実行を組織化する。一方、既存のグラフとエージェントを組み合わせる手法は、特定の能力を支援するためにグラフを用いる。出典：§11.2 · pp. 62–63

Related papers

Loading 2608.21156v1…