EvoMAC：自己進化する
マルチエージェント開発ネットワーク

Legend

出典バッジ

出典事実論文本文・表に直接記載。 著者主張著者の評価・結論。 解釈本レポートによるハーネス設計への接続。 未確認本文抽出や論文上で未確定。

Problem

何を解こうとしているか

• 出典事実既存の LLM-driven MAC システムは、ソフトウェア開発で関数レベルの性能を示しているが、チーム構成・役割・ワークフローを人間が設計する依存が大きい。
• 著者主張人間設計への依存は、現実の多様なソフトウェア要求への適応性を制限する。
• 解釈この論文の焦点は「良いプロンプトを書く」ではなく、プロンプトと接続を更新するループそのものを設計することにある。まさに「agent を prompt するのではなく、agent を prompt する loop を設計する」方向。

Method

EvoMAC の中核：textual backpropagation

出典事実MAC network は、LLMエージェントをノード、依存関係を有向辺とする DAG。各ノードは prompt によって subtask を指定され、edge はどの agent の出力がどの agent に渡るかを表す。

T = Phi(X, A_t)                 # testing team generates target proxy
for k in 0..K-1:
    G_k = Phi(X, A_g^k)         # coding team forward pass
    L_k = <G_k, T>_E            # environment feedback as textual loss
    grad_k = G_fn(L_k, A_g^k)   # textual backpropagation
    A_g^{k+1} = U_fn(A_g^k, grad_k)

Software Development Architecture

ソフトウェア開発への適用

Benchmark

rSDE-Bench：要求仕様ベースのソフトウェア開発ベンチ

• 出典事実game は dynamic interactions、real-time state changes、game state transitions を要求する。
• 出典事実website は static/dynamic content management、forms/buttons、page elements の表示・機能を重視する。
• 出典事実平均要求長は game 507 words、website 1011 words。短い instruction ではなく、長い requirements を入力にする。
• 解釈関数補完ではなく「仕様を読む→分解する→複数機能を統合する→テストで要求充足を測る」ため、coding agent harness の実運用に近い。

Evaluation

自動評価は human evaluation と強く一致

出典事実human evaluation は2名の expert code engineers が、生成ソフトを操作して requirements fulfillment を手動確認。全 benchmark 評価に expert 1人あたり約4時間かかった。

著者主張要求ごとに black-box test case を対応させる rSDE-Bench の accuracy は、consistency（要求文との類似度）や quality（executability等の積）より、実際の要求充足を正確に測る。

Results

実験結果：EvoMAC は既存SOTAを上回る

• 出典事実比較対象は single-agent（GPT-4o-Mini, Claude-3.5-Sonnet, Gemini-1.5-Flash）と multi-agent baselines（MetaGPT, Autogen, MapCoder, Agentverse, ChatDev）。multi-agent baseline と EvoMAC は公平性のため GPT-4o-Mini で駆動。
• 著者主張EvoMAC は rSDE-Bench と HumanEval の両方で previous SOTA を上回る。

Ablation

何が効いているか

• 出典事実evolving iteration が増えるほど、Website / Game / HumanEval の5設定すべてで性能が継続的に改善する。
• 出典事実GPT-4o-Mini 駆動版と Claude-3.5-Sonnet 駆動版の両方で、iteration に伴う改善が確認される。強い単体モデルを使う EvoMAC variant は一貫して上位。
• 出典事実objective environment feedback を外し、LLM-driven critique に置き換えると大幅に性能低下。Website Basic/Advanced で 12.67% / 14.97%、Game Basic/Advanced で 21.74% / 18.28% 低下。
• 出典事実coding team / testing team を single-agent に減らすと性能低下。multi-agent collaboration は evolution の柔軟な調整に寄与するとされる。
• 出典事実failure は Website では page display issues、Game では logic errors が多い。page errors は早く解消しやすいが、logic errors は残りやすい。

Harness Lessons

実践に持ち帰る設計原則

Checklist

EvoMAC風に実装するなら

• タスク入力を長い requirements として保持し、短い instruction に潰さない。
• coding team と testing team を分ける。
• unit tests / compiler / 実行ログを feedback API として標準化する。
• agent prompts と network topology を更新対象として永続化する。
• evolution iteration ごとに、生成物・loss・textual gradient・更新後ネットワークを記録する。
• 要求ごとの pass/fail を集計し、どの要求が改善・悪化したかを表示する。
• LLM critique だけで更新しない。必ず客観環境 feedback を入れる。
• proxy test への過適合を避けるため、hidden tests / human spot check / property tests を併用する。

Limits

限界と注意点

• 未確認unit tests が target proxy である以上、テストが仕様を完全に覆わない場合、EvoMAC は proxy に過適合しうる。
• 出典事実著者は future work として、feedback から学ぶ能力を高める reward model の導入、rSDE-Bench の software types 拡張を挙げる。
• 解釈実運用では、セキュリティ、依存管理、UI品質、保守性、非機能要件、ユーザー受け入れのような tests に落としにくい要素も残る。
• 解釈「自己進化」は強力だが、更新対象が prompt/topology であるため、ログ・差分・rollback・評価分離なしに常時運用すると劣化やドリフトを検知しにくい。

Sources

出典

• arXiv HTML: https://arxiv.org/html/2410.16946v1
• arXiv PDF: https://arxiv.org/pdf/2410.16946v1
• rSDE-Bench: https://yuzhu-cai.github.io/rSDE-Bench/

本レポートは arXiv:2410.16946v1 のHTML抽出テキストをもとに、Hermes が直接生成しました。Claude Code はこの実行時点で session limit のため最終生成には未使用です。数値・表は原論文 Table 1 / Table 2 / Figure 4–7 付近の本文抽出に基づきます。