Phodal Huang が中国語で書いたこの記事は、AutoDev (unit-mesh/auto-dev) でコードレビューがどのように扱われているかを解説している。記事の冒頭では、著者が実際のエンジニアリング環境のコードレビューに見る課題が挙げられている。リントの結果、テスト、issue、変更履歴がそれぞれ別のシステムに散らばっていること、複雑なロジックは単一のツールでは理解しにくいこと、そして人手によるレビューは遅く、個人の判断に左右されることである。記事は、この機能を試すための手段として、AutoDev CLI 0.3.0（autodev review -p . で実行）と AutoDev Desktop（compose-0.3.0）を紹介している。
中心となる主張は、マルチエージェントの協調と情報の集約を組み合わせることで、AI がシニアエンジニアのように変更のコンテキスト、履歴、品質上のリスクを理解し、修正の提案を生成したり修正を直接適用したりできるようになり、分析から修復までのループが閉じるというものである。
要点
- 著者はレビューの流れを 4 段階のパイプラインとして説明している。静的な情報収集（Code Audit）、AI による分析（Code Analysis）、修正計画の生成（Modification Plan）、自動修正（Generate Fixes）である。
- 静的な収集の段階では、Git の差分から変更されたハンクを抽出し、CodeGraph などのツールで影響を受けるクラスやメソッドを特定し、ESLint、Ktlint、Detekt などのリンターを実行し、関連する issue、要件、テストを構造化データとして集約する。記事によれば、この段階ではトークンを消費しない。
- 分析の段階では、差分、構造、リント、issue、テストのデータをシステムプロンプトに組み込み、さまざまなレビュー種別（総合、パフォーマンス、セキュリティ、スタイル）に沿って分析する。必要に応じて
read_fileやgrep_searchなどのツールでコンテキストを補い、重大度、位置、提案を含む構造化された指摘を生成する。 - 計画の段階では、リントと AI の指摘を統合して優先順位をつけ、実行可能な修正計画にまとめる。ユーザーは、それが修正の入力として使われる前に、項目を追加したり絞り込んだりできる。
- 修正の段階では、CodeReviewAgent が CodingAgent を調整する。CodingAgent は実際に変更されたハンクをもとに作業し、複数回のツール呼び出し（ファイルの読み書き、リファクタリング、テスト）を行って、ロールバックやさらなるイテレーションに対応した最終的なパッチを出力する。
- 作業を複数のエージェントに分ける動機として著者が挙げるのは、レビューに静的解析、コンテキストの理解、コード生成、エラーからの回復が必要な場合、1 つのエージェントではトークンの制限の下で安定したスループットを保つのが難しいということである。エージェントを分ければ、必要に応じて組み合わせ、それぞれ独立に進化させ、分析やツールが失敗したときには機能を縮退させたり差し替えたりできる。
- 説明されている役割は次のとおりである。情報を集約し、プロンプトを組み立て、どのエージェントを呼び出すかを決めるメインの CodeReviewAgent。分析用のサブエージェントとして、大きな内容や複雑なコンテキストを扱う AnalysisAgent、ツール呼び出しやモデル出力のエラーを扱う ErrorRecoveryAgent、リポジトリ全体をスキャンする CodebaseInvestigatorAgent。そしてコードの修正を専門とする CodingAgent である。
- サブエージェントは
SubAgentManagerによって生成・破棄され、サブエージェントを含むすべてのツールはToolRegistryに登録され、実行、権限、結果はToolOrchestratorによって一元的に処理される。
背景
この記事は評価ではなく、著者自身のツールの解説であり、レビュー品質の計測結果は報告されていない。調整役のエージェントが焦点を絞ったタスクをサブエージェントに委ねるという構成は、この wiki がサブエージェントアーキテクチャとして説明しているものの一例である。著者は、今後の取り組みとして、テストカバレッジ、CI/CD、インクリメンタル分析を統合する予定だと述べている。