設計哲学

Documentation Index

Fetch the complete documentation index at: https://docs.fim.ai/llms.txt

Use this file to discover all available pages before exploring further.

FIM One の DAG 実行エンジンは、意図的な抑制を持って設計されました。マルチエージェントフレームワークで一般的なパターンのいくつかが評価され、意図的に除外されました。このページでは、これらの決定とその背後にある推論を文書化しています。

​

ハンドオフ — 不要

パターン: エージェント間の明示的なタスクハンドオフ。1つのエージェントが作業を完了し、制御を次のエージェントに渡す。 除外理由: DAG線形チェーンは既に順序付きタスクハンドオフを自然にカバーしている。ステップBがステップAに依存する場合、実行者はAの完了を待ち、その後、依存関係メカニズムを介してAの結果をBのコンテキストに渡す。これは構造的にはハンドオフと同等だが、別の抽象化レイヤーを必要としない。 明示的なハンドオフプロトコルを追加すると、ステップ依存関係が既に提供しているものが重複し、追加の表現力は得られない。

​

バックフロー — 不要

パターン: ダウンストリームステップが結果をアップストリームステップにフィードバックして再評価する（結果の逆伝播とも呼ばれる）。 除外理由: PlanAnalyzer の再計画ループがすでにこのユースケースをカバーしています。すべてのステップが完了した後、アナライザーは元の目標が達成されたかどうかを評価します。達成されていない場合（かつ信頼度が停止閾値を下回っている場合）、前のラウンドの結果からのコンテキスト（何がうまくいかなかったか、何を学んだかを含む）を使用して、完全な再計画をトリガーします。 これはステップごとのバックフローよりも粗粒度ですが、より堅牢なアプローチです。ステップごとのバックフローは、デバッグが難しく、無限ループにつながる可能性のある複雑なフィードバックループを作成します。再計画ループは、より清潔な実行モデルで同じ修正効果を実現します：計画、実行、評価、必要に応じて再計画。

​

チーム（エージェント間通信）— 不要

パターン: 実行中に相互に通信する複数の専門化されたエージェント、サブタスク所有権の交渉、または共有状態での協力。 除外理由: DAG依存チェーンはデータ依存タスクに十分です。ステップCがステップAとステップBの両方の結果を必要とする場合、依存エッジはこれを直接表現します。ステップCはそのコンテキストでAとBの出力を受け取ります — エージェント間メッセージングプロトコルは不要です。 DAGモデルはエージェント間通信よりもシンプルで予測可能です。エージェントは交渉する必要がありません。プランナーが実行構造を事前に決定し、エクゼキューターが依存関係解決を通じてデータフローを強制します。これにより、マルチエージェントメッセージングがもたらす調整オーバーヘッドと非決定性を回避できます。

​

agent_hint / role_hint — 不要

パターン: 各ステップを処理するべきエージェントまたはペルソナのタイプを明示的に指示するヒント（例：「リサーチャーエージェントを使用」または「コーダーエージェントを使用」）。 除外理由: 既存の3つのフィールドの組み合わせで十分なガイダンスが提供されます：

• task — ステップが達成すべき内容の自然言語説明。適切に記述されたタスクは、必要な専門知識を暗黙的に示します。
• tool_hint — ステップが使用すべきツールを提案します（例：web_search、python_exec）。これは曖昧なロールラベルよりも実行アプローチをより正確に制限します。
• model_hint — ステップが高速モデルと推論モデルのどちらを使用するかを制御します。これは最も影響力のある実行決定です。

agent_hintまたはrole_hintを追加することは、これら3つのフィールドと冗長になり、プランナーLLMが正しく判断する必要があるもう1つの設定軸を導入することになります。ヒント表面を小さく保つことで、計画エラーを減らします。

​

ディープ マルチエージェント オーケストレーション — 戦略的に延期

上記の「Teams」除外は工学的な議論です：DAG エッジはすでにデータ依存関係を表現しています。このセクションは戦略的な議論を追加します：モデル機能がオーケストレーション複雑性を吸収する業界トレンドです。

​

モデルがオーケストレーションレイヤーを置き換えている理由

マルチエージェント階層は、モデルの制限を回避するための対処法として登場しました。1つのモデルが複雑なタスクを処理できない場合、それを特化したエージェント全体に分解していました。フロンティアモデルの各世代がこの根拠を侵食しています：

​

深さのコスト

モデルが能力に欠けている場合でも、深いエージェント階層には複合的なコストが伴います:

• トークン乗算 — ネストの各レベルでシステムプロンプトとコンテキストが再注入されます。3レベル深い場合、総トークン支出は単一エージェントアプローチの5～10倍になる可能性があります。
• レイテンシスタッキング — 各レベルは完全なLLMラウンドトリップです。ユーザーは最も遅いチェーンを待ちます。
• 情報ロッシー圧縮 — 委譲されたエージェントは生データではなく要約を返します。各レベルで忠実度が低下します。
• デバッグの不透明性 — 「どのレベルがタスクを誤解したのか?」は深さ > 2でほぼ診断不可能です。

​

FIM Oneのポジション

CallAgentToolを使用した1段階の委譲は最適なバランスポイントです：「私は汎用エージェントですが、このサブタスクはSQLの専門家が必要です。」これは、より深い階層の複合コストなしに、実世界の委譲ニーズの大多数をカバーしています。 深いマルチエージェントオーケストレーションは無期限に延期されています。構築が難しいからではなく、フロンティアモデルの軌跡がそれが不要になることを示唆しているからです。FIM Oneの価値は、ツール供給層（コネクタ、MCP、ガバナンス）にあり、モデルが急速に内部化しているオーケストレーション深度にはありません。