この記事は自動翻訳されました。原文はこちらをご覧ください。

コーディングエージェントのミッションコントロール：VS Codeでの統一されたエクスペリエンス

単一のコーディングアシスタントは理解するのが簡単です。異なる場所で動作する複数のエージェントはそうではありません。

1つのエージェントはVS Codeでローカルに実行されます。別のエージェントはクラウド内のGitHub Issueで機能します。CLIエージェントはターミナルで動作します。サードパーティのコーディングエージェントは異なるセッションモデルと異なる制限を持つ可能性があります。共有ビューがなければ、開発者は作業の監督よりも追跡により多くの時間を費やします。

VS Codeの統一されたエージェント体験はAgent Sessionsでその調整の問題に対処します：エージェントを起動し、ステータスを確認し、会話を開き、計画が変わったときに介入する1つの場所です。

これは別のエージェントを追加することよりも、複数のエージェントを管理可能にすることに関するものです。

さまざまなタイプの作業のための1つのビュー

ソース記事では、4つの異なる参加者について説明します：ローカルのGitHub Copilot、クラウド内のCopilot Coding Agent、GitHub Copilot CLI、および対象のCopilot購読者向けのOpenAI Codexです。

彼らは異なる強みを持っています：

ローカルエージェントは現在のワークスペースを検査して素早く変更を加えることができます。
クラウドコーディングエージェントはIssueで非同期に作業し、プルリクエストを開くことができます。
CLIエージェントはターミナル中心のワークフローと操作コマンドに適しています。
別のプロバイダーは異なるモデルまたは推論スタイルを提供できます。

Agent Sessionsはこれらのタスクに共通のホームを提供します。何が実行されているか、何をしているか、会話をどこで拾うかを確認できます。

自律的な作業は調整を排除しないため、その可視性は重要です。これは調整を第一級のエンジニアリングタスクにします。

割り込みはワークフローの一部です

ソースは簡単な観察を行います：「プロンプトを送信してから重要なことを忘れていたことに気付くのは一般的です。」以前は、選択肢は待つかキャンセルすることであることが多かったです。チャットエディタを使用すると、アクティブなセッションを開いてエージェントが作業中に情報を追加できます。

これは実際のコラボレーションに近いです。要件は変わります。テストが仮定を明らかにします。レビュアーがAPIを後方互換性を保つ必要があることに気付きます。有用なエージェントは修正が不要なエージェントではなく、修正を吸収してタスク全体を失わないエージェントです。

.NETの作業の場合、割り込みは次のようにシンプルな場合があります：

Keep the existing public route unchanged. Add the new behavior behind the application service,
use the existing ProblemDetails convention, and add a test for the old response shape.

命令は短いです。リポジトリが既により大きなコンテキストを含んでいるからです。セッションは方向を修正する場所であり、システム全体を再度述べる場所ではありません。

カスタムエージェントがチームの習慣をロールに変える

VS Codeは、Planなどの専門的なエージェントも導入しています。すぐに実装するのではなく、計画エージェントは実装仕様を生成する前に、スコープ、コンポーネント、ライブラリ、および制約についての質問をします。

そのパターンは組み込みエージェントを超えて有用です。チームは焦点を絞ったロールを定義できます：

Researchは証拠を集め、短い決定記録を書きます。
Reviewは変更がリポジトリ規約に対して正しいかどうかを確認します。
Testingは欠落しているケースを特定し、テストプランを提案します。
Architectureはファイルを変更せずにオプションを比較します。

小規模なカスタムエージェント定義は次のようになります：

type: agent
name: plan
description: "Refines vague requests into clear implementation specs"
prompt: |
  Ask about scope, constraints, existing patterns, and edge cases.
  Produce a concise specification before any implementation begins.

有用な部分はYAMLではありません。それは責任の明確な分離です。計画エージェントは本番コードをそっと編集するべきではありません。レビューエージェントは評価することになっているデザインを書き直すべきではありません。

サブエージェントはコンテキストの衝突を削減します

長い会話は無関係なコンテキストを蓄積します。サブエージェントは限定された研究タスク用に分離されたワークスペースを提供し、結果をメインセッションに戻します。

これは次のような質問に適しています：

Analyze the API project and recommend an authentication strategy.
Return trade-offs and a decision record. Do not edit files.

メインエージェントは実装に焦点を保つ一方で、研究エージェントはより狭い質問を処理します。同じ原則がチームにも適用されます：明確な委譲は重複する権限で複数のエージェントを起動するよりも良い結果をもたらします。

注意事項：より多くのエージェントはより多くの調整を意味します

Agent Sessionsはアクティビティを表示できますが、競合する所有権を解決することはできません。2つのエージェントが同じエリアを編集している場合でもマージの問題を作成できます。クラウドエージェントとローカルエージェントは互いに互換性のない仮定を行うことができます。カスタムエージェントは別のエージェントが無視する推奨事項を生成できます。

境界を設定してください：

1つのエージェントが特定のブランチの実装を所有しています。
研究エージェントは追跡されていない編集ではなく成果物を返します。
プルリクエストはレビュー境界のままです。
エージェント名とプロンプトは、変更が許可されているものを述べています。
セッション出力は、重要な決定を説明するときに保持されます。

私の意見

マルチエージェントの未来はチャットウィンドウのキューではありません。それはロール、引き渡し、および責任を持つ小さなチームです。

Agent Sessionsは価値があります。それがその現実を認識しているからです。エディタ、ターミナル、およびクラウド全体で既に起こっている作業に対して、開発者に制御面を提供します。次の生産性の向上は、より多くのエージェントを持つことからではなく、その境界を判読可能にすることから生じるでしょう。

.NETチームの場合、1つの計画エージェントと1つの実装エージェントで開始します。計画出力をIssueまたはプルリクエスト仕様として使用してから、実装エージェントが境界内で作業するようにします。より多くのロールを追加する前に改作を測定してください。

最高のミッションコントロールはまだ所有権を明らかにするものです。