AIエージェントフレームワークポリシー
概要
このプロジェクトは意図的に以下のような大規模AIエージェントフレームワークの使用を避けています：
- LangChain
- AutoGPTスタイルのフレームワーク
- CrewAI
- Semantic Kernel
- その他のモノリシックなエージェントフレームワーク
代わりに、システムは独自の軽量エージェントアーキテクチャを実装しています。
この決定は意図的であり、いくつかのアーキテクチャ上の考慮事項に基づいています。
理由1: アーキテクチャの制御
ほとんどのエージェントフレームワークは独自のアーキテクチャを課します。
典型的な例：
- チェーンベースの実行モデル
- 不透明なメモリシステム
- フレームワーク固有のツールインターフェース
- 隠れたプロンプトオーケストレーション
自律的にソフトウェアを構築するよう設計されたシステムにとって、実行アーキテクチャに対する完全な制御が必要です。
コアシステムを内部で実装することで、プロジェクトは以下を定義できます：
- 独自のツールシステム
- 独自のメモリアーキテクチャ
- 独自のワークフローエンジン
- 独自のコンテキスト管理
これにより、フレームワークの制約なしにシステムが進化できます。
理由2: 安定性
AIエージェントフレームワークは非常に速く進化します。
主要な破壊的変更はしばしば数ヶ月ごとに発生します。
エコシステムで観察された例：
- LangChainのアーキテクチャ変更
- 頻繁なAPI再設計
- 依存関係の不安定性
- 実験的な機能の廃止
長期的な自律エンジニアリングシステムにとって、安定したアーキテクチャは急速なフレームワークの反復よりも重要です。
フレームワークのロックインを避けることで長期的な保守性が向上します。
理由3: シンプルさ
ほとんどのフレームワークは大きな複雑さを導入します：
- 大きな依存関係ツリー
- 重い抽象化レイヤー
- 不明確な実行フロー
- 困難なデバッグ
Autonomous Engineerはシンプルで明示的なシステム設計を優先します。
フレームワークの代わりに、システムは直接実装します：
- ツール実行
- メモリ取得
- ワークフロー調整
- コンテキスト構築
これにより、システムが推論しやすく、AIエージェントが変更しやすくなります。
理由4: AI最適化アーキテクチャ
従来のフレームワークは主に以下のために設計されました：
- チャットエージェント
- RAGパイプライン
- シンプルなツール使用
このプロジェクトは自律ソフトウェアエンジニアを構築しています。
そのようなシステムには専門的な機能が必要です：
- 仕様駆動開発ワークフロー
- リポジトリレベルの推論
- 長期エンジニアリングメモリ
- 決定論的ツール実行
- コードベーススケールのコンテキスト管理
これらの要件は典型的なエージェントフレームワークと大きく異なります。
アーキテクチャを直接構築することで、自律開発に最適化された設計が可能になります。
理由5: フレームワーク独立性
システムは特定のAIプロバイダーまたはフレームワークから独立していなければなりません。
サポートされるモデルプロバイダーには以下が含まれることがあります：
- OpenAI
- Anthropic
- ローカルモデル
- 将来のプロバイダー
同様に、アーキテクチャは以下と互換性を維持すべきです：
- 異なるエージェント戦略
- 異なるモデル機能
- AIツーリングの将来の改善
フレームワークのロックインを避けることでこの柔軟性が維持されます。
システムがまだ使用するもの
プロジェクトは大規模エージェントフレームワークを避けていますが、適切な場合にはライブラリを使用します。
例：
- OpenAI SDK
- 埋め込みライブラリ
- ベクターデータベース
- トークナイザーライブラリ
目標はエージェントオーケストレーションフレームワークを避けることであり、有用なライブラリを避けることではありません。
まとめ
Autonomous Engineerは大規模AIエージェントフレームワークの使用を意図的に避けています。
代わりに、システムは以下のための独自のアーキテクチャを実装しています：
- ツール実行
- ワークフロー調整
- メモリシステム
- コンテキスト管理
このアプローチは以下を提供します：
- アーキテクチャの制御
- 長期的な安定性
- シンプルな実行モデル
- 将来のAI機能への柔軟性