タスク計画アーキテクチャ
概要
タスク計画システムはAI Dev Agentが複雑なエンジニアリングタスクを管理可能なステップに分解できるようにします。
ソフトウェア開発タスクはめったに原子的ではありません。典型的なタスクには以下が必要です：
- リポジトリの探索
- ソリューションの設計
- 複数のモジュールの変更
- テストの記述
- 実装の検証
タスク計画アーキテクチャにより、エージェントは作業を明確で体系的な方法で構造化できます。
このサブシステムはエージェントループの上に位置し、エージェントが取るアクションのシーケンスを導きます。
目標
タスク計画システムはいくつかの主要な目標で設計されています。
構造化された実行
大きなタスクはエージェントループ内で実行できる小さなステップに分解されるべきです。
適応性
エージェントが新しい情報を発見するにつれて、計画は調整可能でなければなりません。
透明性
計画プロセスは観察可能で人間が理解できるべきです。
堅牢性
エージェントはエラーから回復し計画を修正できなければなりません。
計画階層
タスク計画は階層的です。
ゴール
│
▼
タスク
│
▼
ステップ
│
▼
アクション各レベルは異なる抽象度を持ちます。
ゴール
高レベルの目標。
例：
ユーザーサービスにキャッシュサポートを追加する。タスク
論理的にグループ化された作業単位。
例：
キャッシュレイヤーの実装
サービス統合の更新
キャッシュテストの記述ステップ
タスクを完了するために必要な具体的な操作。
例：
CacheClientモジュールの作成
TTLサポートの追加
CacheをUserServiceに注入アクション
エージェントループ内で実行される実行可能なツール操作。
例：
read_file
write_file
run_tests計画ライフサイクル
計画プロセスはタスクを通じて進化します。
初期計画
↓
実行
↓
観察
↓
計画修正
↓
実行継続これにより、エージェントは新しい情報が利用可能になるにつれてアプローチを改善できます。
初期計画生成
タスクが始まると、エージェントは初期計画を生成します。
入力：
- タスク記述
- アーキテクチャドキュメント
- リポジトリコンテキスト
- 事前知識
出力例：
計画：
1. 現在のUserService実装を分析する
2. キャッシュ戦略を設計する
3. CacheClientを実装する
4. CacheをUserServiceに統合する
5. テストを書く
6. テストスイートを実行するこの計画は厳格なスクリプトではなく出発点として機能します。
動的計画調整
計画は実行中に変更される場合があります。
例：
- 既存のキャッシュモジュールの発見
- テストの失敗
- アーキテクチャ制約の特定
修正例：
元のステップ：
CacheClientを実装する
修正されたステップ：
既存のCacheManagerモジュールを拡張するシステムは柔軟な計画更新を許可しなければなりません。
ステップ実行モデル
各ステップはエージェントループを通じて実行されます。
ステップ
↓
次のアクションを計画
↓
ツールを実行
↓
結果を観察
↓
ステップ進捗を更新ステップはその目標が達成されると完了としてマークされます。
計画表現
計画は構造化されたオブジェクトとして表現されます。
TypeScript表現例：
type TaskPlan = {
goal: string
tasks: Task[]
}
type Task = {
id: string
title: string
status: "pending" | "in_progress" | "completed"
steps: Step[]
}
type Step = {
id: string
description: string
status: "pending" | "in_progress" | "completed"
}この構造により、システムは進捗を正確に追跡できます。
ステップの粒度
ステップは確実に実行できるほど小さく、しかし意味のある作業を表すほど大きくあるべきです。
良い例：
CacheClientにTTLオプションを追加する
CacheをUserServiceで使用するよう更新する
キャッシュ有効期限のユニットテストを追加する悪い例：
キャッシュシステムを実装する粒度が大きすぎるステップは信頼性と可観測性を低下させます。
依存関係管理
一部のステップは他のステップに依存しています。
例：
CacheClientを作成する
↓
CacheClientをUserServiceに統合する
↓
テストを書く依存関係は実行中に尊重されなければなりません。
表現例：
type Step = {
id: string
description: string
dependsOn?: string[]
}並列の機会
一部のタスクは独立して実行できます。
例：
ドキュメントを書く
テストを書く将来のバージョンのシステムは並列実行をサポートする可能性があります。
初期アーキテクチャでは、実行は順次です。
失敗回復
タスク実行中に失敗が発生することがあります。
例：
- コンパイルエラー
- テスト失敗
- ランタイム例外
ステップが失敗した場合、エージェントは以下を行うことがあります：
- ステップを再試行する
- 実装を精緻化する
- 計画を修正する
例：
ステップ: run_tests
結果: 失敗
次のステップ：
失敗したテストを検査して実装を更新する計画検証
主要な変更を実行する前に、エージェントは計画を検証することがあります。
チェック内容：
- アーキテクチャの互換性
- コーディング標準
- 依存制約
これにより、誤った実装の可能性が削減されます。
計画の永続化
計画はエージェントセッションをまたいで永続化されるべきです。
ストレージ例：
.memory/tasks/永続化された計画により、エージェントは中断後に作業を再開できます。
ファイル例：
.memory/tasks/task_42.json人間とのインタラクション
人間は計画をレビューまたは変更することがあります。
ワークフロー例：
エージェントが計画を提案
↓
人間が計画をレビュー
↓
エージェントが承認された計画を実行これは特に大規模または高リスクの変更に役立ちます。
他のシステムとの統合
タスク計画は他のアーキテクチャコンポーネントと密接に統合されています。
エージェントループ
エージェントループは各ステップ内の個別のアクションを実行します。
コンテキストエンジニアリング
関連する計画情報がモデルコンテキストに注入されます。
ツールシステム
アクションはツールを通じて実行されます。
メモリシステム
完了したタスクは再利用可能な知識として保存される場合があります。
可観測性
計画アクティビティはログに記録されるべきです。
イベント例：
- 計画作成
- ステップ完了
- 計画修正
- 失敗回復
これらのログはエージェントのパフォーマンスの分析に役立ちます。
将来の改善
可能な拡張：
- 階層的計画エージェント
- 学習された計画戦略
- 計画最適化
- 協調的マルチエージェント計画
これらの改善により、効率性と信頼性が向上する可能性があります。
まとめ
タスク計画アーキテクチャにより、AI Dev Agentは複雑な開発タスクを管理できます。
システムは作業を階層的に整理します：
- ゴール
- タスク
- ステップ
- アクション
計画は動的であり、エージェントがコードベースについてより多くを学ぶにつれて進化することがあります。
このように作業を構造化することで、エージェントは複雑なエンジニアリングワークフローを信頼性が高く理解しやすい方法で実行できます。