チーム実践

Agent が真のチームメンバーになれるようにする

計画、Agent のトリアージ、コンテキスト管理からTask Boardのメンテナンスまでの実践的な経験。

次のプラクティスは、Syfo を試し始め、Agent をチームの日常業務に組み込む準備ができている人に適しています。まず、Channel分割とAgent の数を確認します。チーム入門ガイドそしてChannel構成とマルチAgent のコラボレーション, ここでは、最も避けやすく、日常のコラボレーションの効率を最も高めることができるいくつかの習慣に焦点を当てます。

一文で言うと：その人が目標と原則を与え、計画がAgent に渡されます。 あなたはツールを操作するのではなく、要件、判断、受け入れに焦点を当てて、自ら成長するチームを率いています。

Agent に計画を手伝ってもらいましょう

自分で設定方法を理解する必要はなく、計画自体はAgent に任せてください。

Agent にビジネス、プロセス、組織構造について伝え、Channel の分割方法、各 Channel にどのAgent を配置するか、各Task に何人のAgent を割り当てるべきかなどの提案を求めます。
目標と制約 (「N 個のシステムを再構築する必要がある、何日、何人、どのようなリソースが必要か」など) を考慮すると、計画が作成され、各Agent の役割とプロンプトも与えられます。新しいものを作成して貼り付けて開始できます。
ずれがある場合は、いつでも校正できます。それは長期記憶に書き込まれ、使えば使うほどチームにフィットしていきます。

これは、「ツールを自分で操作する」から「Agent のチームを連れてくる」までの重要なステップです。

設計トリアージ / 常駐Agent

マルチChannel のコラボレーションが発生する場合、通常、情報配信と調整のために「常駐」Agent が必要になります (病院の案内デスクなど)。これを有効に活用するには、いくつかの原則があります。

単一責任: オンサイトAgent は転用と調整のみを行い、特定の開発は行いません。開発の詳細で行き詰まってしまうと、タイムリーなトリアージを行う時間がなくなり、行列ができてしまいます。
作成者によって管理される: その動作原理はオーナーによって訓練され、制約されており、他の人が意のままに変更することはできません。直属のマネージャーがいる同僚と同様に、フィードバックはマネージャーに一律に与えられます。
ルールを積み上げずに枠組みを与える：何百ものルールを作らないでください。合わせて「判断枠組み＋ルーティングルール」を抽象化し、その枠組みに従って動作させるようにします。軌道から外れている場合は、再調整してください。
部門を超えた意思決定のためにグループを結成する: 複数の部門が関与する意思決定により、各部門のトリアージ担当者と人間の意思決定者が同じChannelで議論できるようになります。合意に達した後、各部門はTask を自分の部門に持ち帰ります。 1 人のAgent が 2 つの大規模システムにわたってトリアージを実行しないようにしてください。

コンテキストを管理してコストを節約する

Agent は常駐セッションであり、長時間実行するとコンテキストが蓄積して速度が低下します。

アイドル時間中にリセット: アイドル時にセッションを手動またはバッチでリセットします。長期メモリは失われず、再起動後にAgent を以前の動作ノードに復元できます。リセットすると進行中のTaskが中断されるため、暇なときに行ってください。
コントロールコンテキストウィンドウ: 多くのTaskでは、それほど長いコンテキストは必要ありません。デフォルトのコンテキストを妥当な範囲（400K など）内で制御することで、単一リクエストのコストと遅延が削減され、実際の測定は基本的にパフォーマンスに影響を与えません。
シーン別にモデルを選ぶ：
日々のコーディング、ログ分析、技術レポート、自動化されたTask: コストが低く、応答が速い GPT / Codex を優先します。
フロントエンド、UI、美学、コピーライティング: 一般にクロードのパフォーマンスが優れています。

分業がうまく行われている場合にのみ、Agent はリセットするための「自由時間」を得ることができます。そうしないと、常に忙しくなり、夜遅くまで空くまで待つことしかできません。

Agentでコードを書く

結果を見て、差分を少なく見てください: モデルの機能が十分な場合は、コードを 1 行ずつ確認するのではなく、最終的な実行効果を確認して受け入れられるようにすることをお勧めします。変更を確認したい場合は、デュアルスクリーンを使用します。1 つの画面はAgent と通信し、もう 1 つの画面は VS Code を使用して git diff とコミットレコードを表示します。また、Agent のアクティビティページでツールの呼び出しと推論を確認することもできます。
コード品質の単一の独立したTask: 機能に加えて、長いファイルを分割して保守性を向上させるよう定期的にAgent に依頼します (複数のAgent が同じファイルを変更することによって引き起こされる競合を避けるために、単一ファイルは数百行以内に制御する必要があります)。通常、コーディング標準については合意します。
git を使用して複数のバージョンを実行し、ワークツリーを使用して並列処理を実行します:git はバージョンとロールバックのベースです。複数のAgent が同じウェアハウスを並行して開発する場合は、git work Tree を使用します (Agent に指示するだけです)。ワークツリーは多くのハードディスク容量を占有します。ルートディレクトリにインストールされている依存ソフトリンクは再利用することも、使用後に削除することもできます。

自治境界線と二次確認についての合意

Agent には、独自にトラブルシューティングを行う機能があります (たとえば、展開が失敗した場合、ログを取得して修復します)。常に停止して確認を待つ場合は、境界が明確に合意されていない、またはコンテキストが長すぎることが考えられます。

作業仕様をわかりやすく説明する: リスクの低い操作は独立して続行できます (ログを読んで問題を自分で解決できる場合は、質問しないでください)。リスクの高い操作が再確認されました。
高リスクの二次確認(本番環境の変更、データ削除、リリース、外部コミットメント、権限の変更など、元に戻せない操作または影響の大きい操作):
いつ: 不可逆的な操作または影響の大きい操作。
誰が確認するのか: このモジュールの人間のリーダー。
何を確認しますか: スコープ、影響範囲、ロールバック方法を変更し、差分とログを保持します。
長期間運用して信頼が確立された後は、通常のシナリオでは確認を減らし、リスクの高い状況の場合にのみ確認を保持することができます。

Agent にTask Boardを管理させる