04 - 計画モードとバックグラウンド エージェント: 迅速ではなく、よりスマートに作業します
多くの開発者がエージェント モードが従来のものであることを認識するまさにその瞬間があります。 十分ではありません。プロンプトは正しく、コンテキストが提供されていますが、エージェントはすぐにコードの作成を開始します。 問題を本当に理解する前に。不要なファイルの追加、不要なクラスの変更 触らなければならなかったのですが、20 分間自律的に実行した後、機能するコードベースができていることに気づきました。 しかし、それは間違った方向に成長しました。
この問題に対するカーソルの答えは次のように呼ばれます。 プランモード。書く前に たった 1 行のコードで、エージェントはプロジェクトを分析し、明確な質問をして、計画を生成します。 マークダウンで構造化されており、承認を求められます。各ステップを確認して検証した場合にのみ、 処刑が始まります。そして根本的に異なる哲学: コードを書く前に考える.
プラン モードと並行して、Cursor 2.0 が導入されました。 バックグラウンドエージェント: AI プロセス ワークツリーを介して分離された git ブランチ上で並行して動作します。ブランチでコードを書いている間 メインでは、最大 8 人のエージェントがそれぞれ別のタスクで同時に作業できます。 完全に独立した環境で、仕事やお互いの邪魔をすることはありません。
この高度な記事では、両方の機能を詳しく説明します。どのように機能するか、いつ機能するかについて説明します。 それらを使用する方法、それらを組み合わせる方法、および複雑な開発ワークフローに最も効果的なパターンは何か。
この記事で学べること
- プラン モードが AI 支援開発のパラダイムをどのように変えるか
- 完全なワークフロー: プロンプトの生成から計画の承認まで
- バックグラウンド エージェントとは何ですか。Git ワークツリーは Cursor でどのように機能しますか?
- Cursor 2.0 で最大 8 つの並列エージェントを起動する方法
- Mission Control: 実行中のエージェントの監視と管理
- 実際の使用例: 機能のスキャフォールディング、並行したバグ修正、移行プロジェクト
- 長期実行エージェント: 制限、ベスト プラクティス、コスト管理
- カーソル ルールが生成されたプランをどのようにガイドするか
- 本番環境でテストされた実際の制限と回避策
シリーズ内での位置づけ: カーソル IDE と AI ネイティブ開発
| # | アイテム | レベル |
|---|---|---|
| 1 | カーソル IDE: 開発者向け完全ガイド | 初心者 |
| 2 | カーソル ルール: プロジェクトの AI の構成 | 中級 |
| 3 | エージェント モード: コマンドを使用してコードベースを変更する | 中級 |
| 4 | プラン モードとバックグラウンド エージェント (ここにいます) | 高度な |
| 5 | カーソルフック: ワークフローを自動化する | 中級 |
| 6 | MCP とカーソル: IDE をデータベースと API に接続 | 高度な |
| 7 | Cursor AI を使用したデバッグ: 3 倍高速 | 中級 |
| 8 | 2026 年のカーソル vs ウィンドサーフィン vs 副操縦士 | 初心者 |
| 9 | プロフェッショナルなワークフロー: カーソルを使用した Angular プロジェクト | 高度な |
プラン モードとは何ですか、またエージェント モードとの違いは何ですか
プラン モードを理解するには、まずプラン モードで解決される問題を理解する必要があります。で エージェントモード 標準の場合、フローは直接的です。指示を与えると、エージェントが関連ファイルを読み取って開始します。 すぐに実行すること。このアプローチは、限定的で明確に定義されたタスクに対して効率的です。 but systematically fails on complex or ambiguous problems.
エージェントに次のように尋ねることを想像してください。 「認証モジュールをリファクタリングしてサポートする Google と GitHub を使用した OAuth2」。通常モードのエージェントが編集を開始する可能性があります JWT を使用していることやカスタム ミドルウェアがあることを知らずに、既存の認証ファイルを作成し、 または、アーキテクチャにサーバー側のセッション管理が含まれていること。結果は正しいコードです 抽象的には間違っていますが、プロジェクトの文脈では間違っています。
「コードを書く前に考える」という哲学
プランモードでは、 審議層 処刑前。いつ プラン モードをアクティブにすると、エージェントはコードを作成しません。質問をし、コードベースを検索し、識別します。 依存関係と制約を定義し、正確に説明する構造化文書を生成します。 ファイルごとに、段階的に実行するつもりです。
プランは編集可能な Markdown ファイルです。編集したり、同意しない手順を削除したりできます。 エージェントが考慮していない制約を追加し、誤った仮定を修正します。ときのみ 問題がなければ、「ビルド」をクリックすると、承認された計画に従って実行が開始されます。
プラン モードとエージェント モードをいつ使用するか
2 つのモードのどちらを選択するかは、主にタスクの複雑さと曖昧さによって決まります。
モード選択ガイド
| タスクの特性 | 推奨モード |
|---|---|
| シンプルで明確に定義されたタスク (バグ修正、機能追加) | ダイレクトエージェントモード |
| 複数のモジュールに影響する複雑な機能 | プランモード |
| アーキテクチャのリファクタリング | プランモード必須 |
| 移行（フレームワーク、データベース、ライブラリ） | プランモード + バックグラウンドエージェント |
| よく知っていてすでに実行したタスク | 特定のルールを使用したエージェント モード |
| 不明なコードベースまたは継承されたコードベース | 常にプランモード |
| 構造化定型文の生成 | プランモードまたはテンプレートを使用したエージェント |
プランモードの仕組み: プロンプトから実行可能なプランまで
プランモードは、 を押すと有効になります。 Shift + Tab エージェント入力フィールド、または 複雑なリクエストを検出すると、Cursor によって自動的に提案されます。一度 アクティブになると、流れは 4 つの異なるフェーズに分割されます。
フェーズ 1: コードベースの調査と分析
エージェントはプロンプトから起動するのではなく、コードベースから起動します。エージェントモードと同じツールを使用する (セマンティック検索、ファイル読み取り、grep)、プロジェクトを探索してコンテキストを理解します。特定する 関連ファイル、既存のドキュメントの読み取り、依存関係と関係の分析 モジュール間。
このフェーズ中にエージェントができることは、 説明の質問。あなたの場合 要求があり、重要な点で曖昧なため、続行する前に指定するよう求められます。 これらの質問は貴重です。多くの場合、考慮していなかった暗黙の仮定が明らかになります。
フェーズ 2: 計画の作成
分析が完了すると、エージェントは構造化された Markdown ドキュメントを生成します。計画 内容: 目的の概要、関連するファイルの分析、番号付きのステップのリスト 詳細な説明、作成または変更されるファイルのパス、および潜在的な 管理するリスクや依存関係。
Cursor 2.2 では、プランに次のことも含まれます。 人魚の図 生成された フロー、アーキテクチャ、コンポーネント間の関係を自動的に視覚化します。
認証リファクタリング用に生成されたプランの例を次に示します。
# Piano: Refactoring Autenticazione con OAuth2
## Obiettivo
Aggiungere supporto OAuth2 (Google e GitHub) al sistema di autenticazione esistente,
mantenendo la compatibilità con il flusso email/password attuale.
## Analisi Codebase
- File autenticazione: src/auth/auth.service.ts, src/auth/auth.guard.ts
- JWT gestito in: src/middleware/jwt.middleware.ts
- Session management: server-side (express-session)
- Database: PostgreSQL con tabella `users` (id, email, password_hash, created_at)
## Step da Eseguire
### Step 1: Aggiunta dipendenze OAuth2
- [ ] Installare `passport`, `passport-google-oauth20`, `passport-github2`
- [ ] Aggiornare package.json e package-lock.json
- File: package.json
### Step 2: Configurazione strategy OAuth
- [ ] Creare src/auth/strategies/google.strategy.ts
- [ ] Creare src/auth/strategies/github.strategy.ts
- [ ] Aggiornare src/auth/auth.module.ts per registrare le nuove strategy
- File da creare: 2 nuovi, 1 modificato
### Step 3: Migrazione schema database
- [ ] Aggiungere colonne `oauth_provider` e `oauth_id` alla tabella users
- [ ] Creare migration: db/migrations/20251205_add_oauth_fields.sql
- [ ] Aggiornare User entity per riflettere nuovi campi
- File: User.ts, nuova migration
### Step 4: Aggiornamento route e controller
- [ ] Aggiungere endpoint GET /auth/google e GET /auth/google/callback
- [ ] Aggiungere endpoint GET /auth/github e GET /auth/github/callback
- [ ] Aggiornare auth.controller.ts
- File: auth.controller.ts, app.routes.ts
### Step 5: Test e validazione
- [ ] Aggiornare test esistenti per compatibilità
- [ ] Aggiungere test integrazione per flusso OAuth
- File: auth.spec.ts, nuovi file di test
## Rischi Identificati
- La migrazione DB richiede backup preventivo in produzione
- I callback URL devono essere configurati nelle console Google/GitHub
- I secret OAuth devono essere aggiunti alle variabili d'ambiente
## File NON Toccati
- src/middleware/jwt.middleware.ts (compatibilità preservata)
- Frontend components (fuori scope di questo piano)
フェーズ 3: 計画のレビューと編集
プランはエディターで Markdown ファイルとして開きます。直接編集できます: 削除します 不要な手順、制約の追加、ファイル名の修正、アプローチの指定 代替案。これは最も重要な段階です。あなたの介入が品質を決定します。 次の実行の。
避けるべきよくある間違い
計画を読まずに承認しないでください。すぐに「ビルド」をクリックしたいという誘惑が強いですが、 しかし、これがまさにプラン モードがエージェント モードと異なる点です: あなたのレビューとその一部 プロセスに不可欠です。レビューなしで承認されたプランはエージェント モードよりも悪い なぜなら、それは誤った制御感を与えるからです。
フェーズ 4: 計画に基づく実行
「構築」をクリックすると、カーソルはエージェント モードに入りますが、計画は構造化されたガイドになります。 エージェントは、計画を「仕様」として使用し、定義された順序でステップを実行します。 参考。進行状況をリアルタイムで監視できます。完了した各ステップは マークが付けられ、エージェントは元の計画からの逸脱を報告します。
実行中に予期しない問題が発生した場合、エージェントは停止して質問します。 間違っている可能性のある解決策に向けて独立して進むのではなく、指示に従ってください。
バックグラウンド エージェント: アーキテクチャと運用
プラン モードは実行品質の問題を解決しますが、 バックグラウンドエージェント 速度と並列性の問題を解決します。 11 月に Cursor 2.0 とともに導入 2025 年、それぞれ 1 つの環境で最大 8 つのエージェントを同時に実行できるようになります git は完全に分離されました。
Git Worktree: 基盤となるテクノロジー
バックグラウンドエージェントは以下に基づいています git ワークツリーのネイティブ機能 git を使用すると、複数の作業ディレクトリを同じリポジトリに関連付けることができます。 別の枝にあります。従来のクローン (リポジトリ全体を複製する) とは異なります。 ディスク上)、ワークツリーで軽量: git オブジェクト ストアを共有し、スペースのみを必要とします。 ブランチ間で実際に異なるファイルの場合。
カーソルの場合、これは各バックグラウンド エージェントが次のものを持っていることを意味します。
- Un 専用の git ブランチ 彼は孤立して取り組んでいる
- Una 別の作業ディレクトリ ローカルファイルシステム上で
- Un 個別のコードベースインデックス セマンティック検索用
- 干渉なし あなたの仕事や他のエージェントと
その結果、ブランチで作業できるようになります。 main 3人のエージェントが編集している間
機能/認証、機能/ダッシュボード、および修正/パフォーマンスを同時に入力することなく、
対立している。
Cursor 2.0 を使用したバックグラウンド エージェントの起動
並列エージェントを開始するには、主に 2 つの方法があります。最初で最も一般的なもの: Composer パネルから新しいエージェント タブを開き、特定のタスクを割り当てます。 各タブは、バックグラウンドで動作できる独立したエージェントを表します。
Cursor 2.0 で導入された 2 番目のアプローチでは、複数のエージェントを起動できます。 同じプロンプトから: メインエージェントが指示を受け取り、 それをサブタスクに分解し、それぞれで並行して動作する子エージェントを生成します。 サブタスク。子エージェントを非同期にできるようになり、親エージェントが 子どもたちが演奏している間も続けます。
# Workflow con 3 Background Agents in Parallelo
## Setup iniziale
# Abilita la visualizzazione dei worktrees nel pannello SCM (opzionale)
# Cursor settings.json:
{
"git.showCursorWorktrees": true
}
## Branch principale (il tuo lavoro normale)
$ git branch
* main
feature/auth-oauth
feature/dashboard-redesign
fix/api-performance
## Struttura worktrees (gestita automaticamente da Cursor)
$ git worktree list
/home/user/myproject abc1234 [main]
/tmp/cursor-agent-1/myproject def5678 [feature/auth-oauth]
/tmp/cursor-agent-2/myproject ghi9012 [feature/dashboard-redesign]
/tmp/cursor-agent-3/myproject jkl3456 [fix/api-performance]
## Ogni agente lavora nel suo worktree isolato
# Agent 1 - OAuth2 implementation
# Prompt: "Implementa OAuth2 con Google seguendo il piano auth-plan.md"
# Agent 2 - Dashboard redesign
# Prompt: "Refactoring del dashboard component con nuovi charts per D3.js"
# Agent 3 - Performance fix
# Prompt: "Ottimizza le query N+1 nel modulo ordini identificate dal profiler"
## Al completamento, i branch sono pronti per review e merge
$ git diff main...feature/auth-oauth
$ git diff main...feature/dashboard-redesign
$ git diff main...fix/api-performance
非同期エージェントと再帰的スポーン
Cursor 2.2 の最も重要な革新の 1 つは、エージェントが機能する機能です。 ある意味で 完全に非同期。以前のバージョンでは、エージェントが メインで生成されたサブエージェントは、それぞれが完了するまで待つ必要がありました。 続けてください。これで、子が並行して作業している間、親は続行できるようになります。
さらに強力なのは、サブエージェントが独自のサブエージェントを生成できることです。 を作成する 調整されたワークツリー。プリンシパルエージェントは次のことができます。 機能 A を子に委任し、子は孫の間で作業を分割します。 テスト用と実装用の孫。カーソルハンドルの同期 ツリーの結果を一貫した方法で表示します。
Mission Control: 並列エージェントの監視
複数のエージェントが同時に作業する場合、何が行われているかを可視化することが重要になります。 それは起こっています。 Cursor 2.0 はインターフェイスをパラダイムで再設計しました エージェント中心: ファイルを管理する代わりに、プロセスを管理します。
エージェントパネル
カーソル サイドバーにアクティブ エージェント パネルがあります。すべてのエージェントに彼らはやって来ます 自分自身を見せてください：
- 名前と任務 割り当て済み (最初のプロンプトから派生)
- ブランチ git 彼が取り組んでいること
- Stato: 実行中、入力待ち、完了、エラー中
- 実行された最後のステップ 詳細なログ付き
- 変更されたファイル 現在のセッションで
- 消費されたトークン そして費用の見積もり
実行エージェントとの対話
エージェントをクリックすると、チャット履歴が開き、ファイルが表示されます。 彼はそれを変更し、新しい指示を与えるか、実行を中断します。エージェントの場合 行き詰まったり、間違った方向に進んでいる場合は、クリックするだけで停止できます 新しいメッセージでリダイレクトします。
Mission Control の便利なショートカット
| アクション | ショートカット・方法 |
|---|---|
| 新しいエージェントの背景 | コンポーザパネルで Cmd+Shift+N |
| エージェント間の切り替え | エージェントパネルをクリックするか、Cmd+Shift+Tab をクリックします。 |
| エージェントごとにプラン モードを有効にする | エージェント入力での Shift+Tab |
| 実行中のエージェントを停止する | エージェントヘッダーの停止ボタンをクリックします。 |
| 差分エージェントを確認する | エージェントパネルで「変更されたファイル」をクリックします |
| SCM ワークツリー表示を有効にする | git.showCursorWorktrees の設定: true |
実際の使用例
ケース 1: プラン モードによるフィーチャ スキャフォールディング
典型的なシナリオ: 完全なモジュールを既存のアプリケーションに追加する必要があります。 プラン モードを使用しない場合、エージェントは異なる規則でフォームを生成する可能性があります。 プロジェクトの残りの部分から無視するか、統合されたアーキテクチャ パターンを無視します。
プラン モードのフローは次のとおりです。
- Composer を開き、 を押します Shift+Tab プランモードを有効にする
- 機能について説明します: 「WebSocket経由のリアルタイム通知モジュール、ユーザー設定および履歴管理を追加」
- エージェントはプロジェクトを分析します。既存のパターン、命名規則、モジュール アーキテクチャを特定します。
- 彼はあなたに次のような質問をします。 「プロジェクトは状態管理に Redux または Context API を使用していますか?」, 「テストを含めるべきですか、それとも別々に処理しますか?」
- プロジェクトの規則を尊重して、ファイルの正確な構造を使用して計画を生成します。
- ステップを確認し、場合によっては削除します (例: 「ストーリーブックのストーリーを追加しないでください。私たちはそれらを使用しません」)
- [ビルド] をクリックすると、最初の試行からフォームが正しくスキャフォールディングされます。
ケース 2: バックグラウンド エージェントと並行してバグ修正を行う
アプリケーションの異なるモジュールにそれぞれ独立した 4 つのバグのリストがあります。代わりに それらを順番に修正すると、並列化できます。
# Esempio: 4 bug fix in parallelo
## Agent 1: Fix validazione form
# Branch: fix/form-validation
# Prompt: "Il form di registrazione accetta email non valide.
# File: src/components/RegisterForm.tsx
# Aggiungi validazione RFC 5322 e mostra errore inline"
## Agent 2: Fix query performance
# Branch: fix/slow-dashboard-query
# Prompt: "La dashboard impiega 8s a caricare.
# File: src/api/dashboard.service.ts, line 45
# La query fa N+1 su orders->items. Aggiungi eager loading"
## Agent 3: Fix mobile layout
# Branch: fix/mobile-navbar
# Prompt: "Su viewport < 768px il navbar si sovrappone al content.
# File: src/components/Navbar.css
# Z-index e position sticky si conflittano"
## Agent 4: Fix gestione errori
# Branch: fix/error-boundaries
# Prompt: "L'app crasha senza error boundary.
# Aggiungi React ErrorBoundary al router e ai moduli critici"
## Risultato dopo ~15 minuti:
## 4 branch pronti, ciascuno con il proprio fix isolato
## Review e merge sequenziale o con stacked PRs
メリットは一時的なものだけではありません。修正が個別のブランチに分離されているため、レビューは そしてもっと単純です。各 PR は 1 つの問題のみに触れており、違いは最小限であり、理解できるものです。
ケース 3: 計画 + バックグラウンド エージェントによる移行プロジェクト
最も強力な使用例: 計画が必要な複雑な移行 正確さと平行性。たとえば、アプリケーションを JavaScript から TypeScript に移行します。
最適なワークフロー:
- 計画モードを使用して完全な移行戦略を生成する
- この計画では 30 個のファイルが特定され、4 つの依存関係クラスターにグループ化されます。
- クラスターごとに 1 つずつ、4 つのバックグラウンド エージェントを起動します
- 各エージェントには、そのコンテキストとしてマスター プランとそのファイルのサブセットがあります。
- エージェントが動作している間、Mission Control から監視し、競合を管理します。
- 完了したら、4 つのブランチを確認し、正しい順序でマージします。
長期稼働エージェント: その仕組みと期待されること
カーソルのバックグラウンド エージェントは、 IDE を閉じました。この機能は、次の作業が必要なタスクに特に役立ちます。 移行、大規模なテストの生成など、数十分以上 徹底的なコードベース分析。
セッションの継続性
単純なチャット ウィンドウとは異なり、バックグラウンド エージェントは独自のチャット ウィンドウを維持します。 セッション間の状態。エージェントを開始し、ラップトップを閉じて、戻ってきたときに実行できます。 エージェントは引き続き動作しました (リモート マシン上で実行するように構成されている場合)。 カーソルは両方の実行をサポートします 地元 (プロセスは次の場合に停止します) IDE を閉じます) リモート (エージェントはインフラストラクチャ クラウド上で続行します)。
トークンとコストの制限
長時間実行されるエージェントは大量のトークンを消費します。消費量を監視することが重要です 請求時に予期せぬ事態を避けるため。カーソルはリアルタイムでトークンを表示します Mission Control パネルのエージェントごとに消費されます。
並行エージェントのコストに注意する
各バックグラウンド エージェントは個別にトークンを消費します。 8 つのエージェントを起動する 同時に、同じエージェントの 8 倍のトークンを消費する可能性があります。 期間。 Pro プラン (月額 20 ドル) では、毎月の上限があります: 並列処理の管理 慎重に。本当にメリットが得られるタスクには並列エージェントを使用します。 並列化。すべての操作のデフォルトとしてではありません。
プラン モードとカーソル ルール: 強力な相乗効果
プラン モードは単独で動作するのではなく、次のものに大きく影響されます。 カーソルのルール プロジェクトで設定されます。エージェントが生成するとき 計画の場合、ルールはその内容を形成する制約およびガイドとして機能します。
ルールが計画をどのように導くか
次のようなルールを定義した場合 「常にクリーンな3層アーキテクチャを使用する」 o 「すべての新機能には Jest による単体テストが含まれている必要があります」、生成された計画 これらの制約は自動的に反映されます。エージェントはロジックを導入することを提案しません ルールで関心事の分離が指定されている場合、コントローラーでのビジネスの管理。
# Esempio: .cursor/rules/architecture.mdc
---
alwaysApply: true
---
# Architettura del Progetto
## Layer Separation (OBBLIGATORIO)
- Controllers: solo routing e validation input
- Services: logica di business e orchestrazione
- Repositories: accesso dati, zero logica business
- DTOs: trasferimento dati tra layer, tipizzati
## Naming Conventions
- Service: `*.service.ts`
- Repository: `*.repository.ts`
- DTO: `*-request.dto.ts`, `*-response.dto.ts`
- Controller: `*.controller.ts`
## Testing Requirements
- Unit test per ogni Service (copertura min 80%)
- Integration test per ogni Repository
- File test: `*.spec.ts` nella stessa directory
## Quando Plan Mode genera un piano con questa rule attiva:
## - Ogni step crea file nel layer corretto
## - I nomi seguono le convenzioni definite
## - I test sono inclusi come step separato nel piano
## - Non viene mai suggerito codice che attraversa i layer erroneamente
計画を最適化するためのルール
構造をガイドするプラン モード固有のルールを作成することもできます。 実装だけでなく、計画自体についても次のとおりです。
# Esempio: .cursor/rules/planning.mdc
---
alwaysApply: true
---
# Linee Guida per la Pianificazione
## Prima di generare un piano, DEVI:
1. Identificare tutti i file che verranno modificati
2. Verificare se esistono test da aggiornare
3. Controllare se ci sono migrazioni DB necessarie
4. Valutare l'impatto sulle API esistenti
## Struttura del Piano (OBBLIGATORIA)
Ogni piano deve contenere:
- ## Obiettivo (1 paragrafo)
- ## Analisi Impatto (file, dipendenze, rischi)
- ## Step Implementazione (numerati, con file paths)
- ## Testing (unit + integration)
- ## File NON Toccati (elenco esplicito)
- ## Rollback Strategy (come annullare se va male)
## Dimensione degli Step
- Ogni step deve essere atomico (completabile in 10-15 min)
- Step troppo grandi vanno spezzati in sub-step
- Evita step che dipendono dallo stato di step paralleli
実際の制限と回避策
プラン モードとバックグラウンド エージェントは強力な機能ですが、制限がないわけではありません。 限界を知ることは、能力を知ることと同じくらい重要です。
計画モード: 飛行機内の幻覚
計画にはエラーが含まれている可能性があります: 存在しないファイル パス、間違った仮定 アーキテクチャ上、ステップが冗長または欠落しています。エージェントは全力を尽くします プロジェクトを理解していても、コードベースが大規模であったり、文書化が不十分だったりすると、間違っている可能性があります。
回避策: 分析中にエージェントに正確なパスを強制的に引用させます。 プロンプトに追加: 「計画を作成する前に、見つかったファイルをリストアップしてください 調査を行って、それらが正しいことを確認してください。」。この「チェックポイント」 significantly reduces errors in the final plan.
バックグラウンド エージェント: 競合のマージ
2 つのエージェントが異なるブランチ上の同じファイルを変更する場合、マージ時に 衝突が起こるでしょう。カーソルはセマンティック調整を自動的に処理しません。 マージはあなたの仕事です。
回避策: 並列エージェントを起動する前に計画を分析する そしてタスクが本当に独立していることを確認してください。 2 人のエージェントが接触する必要がある場合 同じファイル (例: 中央ルーティング ファイル)、特定のタスクのシーケンス そして残りを並列化します。
長い計画における長いコンテキスト
非常に大規模なプロジェクトの場合、生成される計画は非常に長くなる可能性があります。 実行中にエージェント コンテキスト ウィンドウに入りません。結果 and that the final steps of the plan are executed with less context and can 精度が低くなります。
回避策: 大きな計画を打ち破る。プランモードを使用して生成する 主要なフェーズを特定し、プラン モードを再度使用する「メタプラン」 各フェーズの詳細な計画を作成します。このウォーターフォールアプローチ 各ステップのコンテキストを管理しやすくします。
外部依存関係をブロックするエージェント
たとえば、データベースにクエリを実行したり、外部 API を呼び出したりする必要があるエージェント これらのリソースにアクセスできない場合、タスクを完了するのはブロックされます ローカルまたはリモートの開発環境で実行されます。
回避策: カーソルルールを使用して処理方法を指定します 外部依存関係: 「DB から実際のデータが必要な場合は、ファイルを使用してください fixtures/sample-data.json をモックとして使用します。」。これにより、エージェントは次のことを行うことができます。 外部リソースに直接アクセスしなくても続行できます。
プラン モードとバックグラウンド エージェントのベスト プラクティス
1. 計画の体系的な見直し
計画を実行する前に計画をレビューするプロセスを確立します。自分自身を制限しないでください 素早くスクロールするには: 各ステップが適切であること、ファイルが適切であることを確認してください。 が実際に存在することを確認し、実行順序が正しいことを確認します。 よく検討された計画は、ほとんどの場合、実行に成功します。
2. エージェントを起動する前にコミットする
エージェントを起動する前に (プラン モードまたはバックグラウンドで)、必ず次の操作を行ってください。 現在の作業のコミット。 HEAD から Git ワークツリーをフォークする current: クリーンな作業ディレクトリにより、エージェントが確実に分岐します。 既知の安定した状態から開始します。
3. 並列エージェントの詳細なタスク
エージェントは、明確に定義された限定されたタスクで最も効果的に機能します。抵抗してください エージェントに膨大なタスクを与えたくなる誘惑 (「すべての e コマース モジュールを実装する」): それらを並列化できる小さなタスクに分割します。平行性の井戸 粒状であり、平行モノリシックよりも信頼性が高くなります。
4. コードベースで初めてプラン モードを使用する
よくわからないコードベース (継承されたプロジェクト、 あなたが貢献するオープンソース、新規顧客）、常にプランモードを使用してください 最初のタスクのために。生成された計画により、パターンを簡単に把握できます。 たとえプロジェクトを実行しないことに決めたとしても、プロジェクトのアーキテクチャ上の側面を考慮する必要があります。
5. コストの最適化
すべてのタスクに計画モードが必要なわけではありません。 i に対して計画モードを選択的に使用する 複雑なタスク。単純なタスクの場合 (変数名の変更、インポートの追加、 ドキュメントのタイプミスを修正)、エージェント モードは直接、より効率的で低コストです。 プラン モードのコストには、分析と実行の両方が含まれます。
6. マージ前の差分の確認
バックグラウンド エージェントがタスクを完了した後は、自動的にマージしないでください。
アメリカ合衆国 git diff main...feature/agent-branch それぞれを確認する
編集します。エージェントの差分は一般的にクリーンでよく整理されています。
しかし、統合前に人間によるレビューは依然として不可欠です。
計画モードと他の AI 計画アプローチの比較
プラン モードは AI 支援による計画への唯一のアプローチではありませんが、次のことを実現します。 代替品と比較したいくつかの特徴的な機能。
最も一般的な代替アプローチは、技術仕様を手動で記述することです。 ドキュメントに含めて、それをコンテキストとしてエージェントに渡します。これは機能しますが、時間がかかります 非常に長く、エージェントの分析能力を活用できません。 コードベースを独立して調べて、関連するファイルを識別します。
2024 年にリリースされる GitHub Copilot Workspace は、以下と同様の機能を提供します。 計画モードは GitHub の問題に統合されました。 Copilot は問題を分析し、 プランを作成し、PR を自動的に開くことができます。 Cursor の利点と統合 エディターを使用して直接実行: プランは同じ環境で生成および実行されます。 ローカルプロジェクトのコードと構造を完全に可視化します。
結論
プラン モードとバックグラウンド エージェントは、質的な飛躍を表します。 開発者が AI と共同作業できる場所。それだけではありません 仕事のスピードアップ: 委任できる仕事の種類を変えることです。
プラン モードでは、以前は反復的なエージェント モードが必要だった複雑な機能が利用可能になります。 多くの監視は、計画が最初に承認される構造化されたプロセスになります 実行の。エージェントが開始されるため、生成されたコードの品質が向上します。 一般的なプロンプトからではなく、問題を深く理解することから。
バックグラウンド エージェントを使用すると、並列処理は大規模エージェントの特権ではなくなります。 大規模なチームを持つ企業。 1 人の開発者が 8 つのエージェントをオーケストレートできる 同時に働くことで生産性が倍増します これは従来の逐次開発では考えられないことです。
2 つの機能の組み合わせ - 並行エージェントによって実行される正確な計画 調整された - おそらく今日の IDE で利用できる最も高度なワークフロー コマーシャル。練習と学習曲線が必要ですが、開発者にとっては それをマスターするために投資した人は、大きな見返りを得ることができます。
シリーズの次のステップ
- 次： カーソルフック: ワークフローを自動化する - エージェントの実行前および実行後のアクションを自動化する方法
- 前の記事: エージェント モード: コマンドを使用してコードベースを変更する - エージェント モードとその機能の完全ガイド
- 関連記事： カーソル ルール: プロジェクトの AI の構成 - ルールがプラン モードとエージェントをどのようにガイドするか
他シリーズとの接続
- MCP とカーソル: バックグラウンド エージェントは MCP ツールを使用して、 実行中に外部データベースや API にアクセスします。を参照してください。 MCPシリーズ (ID 64-77) 詳細については。
- バイブコーディング: プランモードと「スペックファースト」アプローチはリンクされています バイブコーディングの原理に直接触れます。を参照してください。 バイブコーディングシリーズ 補完的な観点から。
- モダンな角度: Angular ワークフローでは、カーソル、プラン モード、および理想的なものを使用 完全なモジュールを足場にします。分かりますか カーソルを使用した Angular ワークフロー (ID 297).