Wukong、Qoder、opencode などの AI コーディングツールに Workbench CLI スキルをロードし、自然言語を使用してエージェントを操作することで、Elastic Compute Service (ECS) インスタンスのクエリ、コマンドの実行、ファイルの転送を行います。構造化された JSON 出力とコマンドの終了コードのパススルーにより、エージェントは結果を独立して評価し、後続の操作につなげることができます。
Workbench CLI が AI エージェントに適している理由
ECS インスタンスに接続する他の方法と比較して、Workbench CLI は本質的に AI エージェントから呼び出すのに適しています。
構造化 JSON 出力: すべてのコマンドは
--output jsonをサポートし、予測可能なフィールド構造を返します (たとえば、exec はoutput、stderr、およびexit_codeを返します)。そのため、エージェントは正規表現を使用してテキスト出力を解析する必要はありません。終了コードのパススルー：
workbench execはリモートコマンドの終了コードをパススルーするため (SSH と同様)、エージェントはリモートコマンドが成功したかどうかを判断できます。コマンドが失敗した場合、--output jsonは構造化されたエラー情報を出力し、エージェントはそれを解析して再試行するかエラーを報告するかを決定できます。ステートレス実行：
workbench execの各呼び出しは、シェルの状態が引き継がれることなく、独立した環境で実行されます。エージェントはセッションコンテキストを維持する必要がなく、コマンドの動作が以前の状態によって予測不能になることはありません。直感的なコマンドセマンティクス：
list/exec/upload/downloadという名前は、一般的な運用タスクに 1 対 1 で対応しているため、エージェントは--helpを通じて自律的に使用方法を学習できます。
前提条件
お使いのコンピューターに Workbench CLI がインストールされ、認証情報と最小権限の RAM ポリシーが設定されていること。詳細については、「Workbench CLI のインストールと認証情報の設定」をご参照ください。
対象の AI コーディングツール (Wukong、opencode、またはシェルコマンドを実行できる他の AI ツール) がお使いのコンピューターにインストールされていること。
エージェントの出力をより適切に評価できるように、まず「Workbench CLI を使用した ECS インスタンスの管理」を読んで、各 workbench サブコマンドの使用方法に習熟することを推奨します。
AI ツールへの Workbench CLI スキルのロード
Alibaba Cloud は、すべてのサブコマンドの使用方法、パラメーターの説明、終了コードの意味、典型的なワークフローを含む公式の Workbench CLI スキルをリリースしました。スキルが AI コーディングツールにロードされると、自然言語で操作の意図を表現するだけで、エージェントが自律的に workbench コマンドを呼び出すことができます。ここでは、Qoder、Wukong、opencode の順にスキルをロードする方法を説明します。
Qoder
Qoder が実行されているターミナルで、次のコマンドを実行して skills CLI で公式スキルをロードします。
npx skills add aliyun/alibabacloud-aiops-skills --skill alibabacloud-workbench-cli --agent qoder -y --full-depthスキルがロードされたら、Qoder で次の対話を試して検証できます。
ユーザー：ローカルの app.jar をインスタンス i-bp1a2b3c4d5e6f の /opt/app ディレクトリにデプロイしてください。
エージェント：(workbench upload と workbench exec を呼び出してデプロイを完了し、結果を段階的に報告します。)Wukong
Wukong はまだ skills CLI によるワンコマンドでのロードをサポートしていません。スキルパッケージをダウンロードして手動でインポートする必要があります。
Workbench CLI スキルページに移動し、スキルの ZIP パッケージをダウンロードします。
ダウンロードした ZIP パッケージを Wukong にインポートします。
インポート後、スキルを有効化 (ロード) します。
スキルがロードされたら、Wukong で次の対話を試して検証できます。
ユーザー：workbench を使用して、中国 (杭州) の実行中のインスタンスを一覧表示してください。
エージェント：(自動的に workbench list ecs -r cn-hangzhou --status Running --output json を実行し、結果を要約します。)opencode
opencode が実行されているターミナルで、次のコマンドを実行して skills CLI で公式スキルをロードします。
npx skills add aliyun/alibabacloud-aiops-skills --skill alibabacloud-workbench-cli --agent opencode -y --full-depthスキルがロードされたら、opencode で次の対話を試して検証できます。
ユーザー：インスタンス i-bp1a2b3c4d5e6f に接続し、そのディスク使用率を確認してください。
エージェント：(自動的に workbench exec -i i-bp1a2b3c4d5e6f -c "df -h" --output json を実行し、結果を説明します。)その他の AI ツールについては、Workbench CLI スキルページをご覧ください。
典型的な対話シナリオ
シナリオ 1：実行中のインスタンスのクエリ
ユーザープロンプト：
中国 (杭州) の実行中のインスタンスを一覧表示してください。エージェントの実行：
workbench list ecs -r cn-hangzhou --status Running --output json簡略化されたレスポンス：
{
"instances": [
{ "instance_id": "i-bp1a2b3c...", "instance_name": "web-prod-01", "status": "Running", "private_ip": "172.16.0.10" },
{ "instance_id": "i-bp2x4y5z...", "instance_name": "api-prod-02", "status": "Running", "private_ip": "172.16.0.11" }
]
}エージェントの要約：中国 (杭州) (cn-hangzhou) には現在、web-prod-01 (i-bp1a2b3c...) と api-prod-02 (i-bp2x4y5z...) の 2 つの実行中のインスタンスがあります。
シナリオ 2：リモートコマンドの実行と結果の分析
ユーザープロンプト：
i-bp1a2b3c4d5e6f のディスク容量が十分にあるか確認してください。エージェントの実行：
workbench exec -i i-bp1a2b3c4d5e6f -c "df -h" --output json簡略化されたレスポンス：
{
"output": "Filesystem Size Used Avail Use% Mounted on\n/dev/vda1 40G 36G 4.0G 90% /\n/dev/vdb1 100G 20G 80G 20% /data\n",
"stderr": "",
"exit_code": 0
}エージェントの分析：ルート / パーティションは 90% 使用されており、残りは 4.0 GB で上限に近づいています。ログをクリーンアップするか、システムディスクを拡張することを推奨します。/data パーティションは使用率 20% で、十分な空き容量があります。
シナリオ 3：ファイルの転送
ユーザープロンプト：
./app-2.0.tar.gz を i-bp1a2b3c4d5e6f の /opt/deploy ディレクトリにデプロイし、展開して検証してください。エージェントの実行 (順次呼び出し)：
workbench upload ./app-2.0.tar.gz /opt/deploy/app-2.0.tar.gz -i i-bp1a2b3c4d5e6f
workbench exec -i i-bp1a2b3c4d5e6f -c "cd /opt/deploy && tar xzf app-2.0.tar.gz" --output json
workbench exec -i i-bp1a2b3c4d5e6f -c "ls -lh /opt/deploy/app-2.0/" --output jsonエージェントの要約：ファイルのアップロードに成功しました。展開は終了コード 0 で正常に完了しました。ディレクトリには bin/、config/、app.jar (120 M) が含まれています。デプロイは完了です。
権限とセキュリティに関する推奨事項
AI エージェント専用の RAM ユーザーまたはロールの使用：エージェントの認証情報を人間のものと分離します。これにより、監査ログで「人間の操作」と「エージェントの操作」を区別しやすくなり、問題の原因を迅速に特定できます。
最小権限ポリシーを使用し、Resource でスコープを絞り込む: エージェントには必要な Actions のみを付与し、インスタンス ARN を使用して
Resourceを特定のインスタンスに絞り込むことで、誤った操作が他のインスタンスに波及するのを防ぎます。ヒューマンインザループ (HITL) 確認の有効化：
workbench connectに組み込まれているエージェントモードは、デフォルトでコマンドを実行する前にY/nによる確認を求めます。外部の AI ツールに対しても、コマンド実行前にユーザー確認を有効にすることを推奨します。本番環境では RamRoleArn の使用を推奨: エージェントシナリオは長時間にわたって実行され、認証情報を頻繁に使用するため、静的な AccessKey ペアが漏洩すると高いリスクを伴います。認証情報が自動的に更新されるように、RamRoleArn または CredentialsURI を優先してください。
よくある質問
エージェントがスキルをロードした後に "command not found" エラーが発生した場合のトラブルシューティング
原因: AI ツールが子プロセスを実行する際、そのシェル環境はユーザーシェルの PATH を継承しないため、workbench バイナリを見つけることができません。
解決策：
絶対パス
/usr/local/bin/workbench(Linux/macOS) またはC:\Program Files\workbench\workbench.exe(Windows) を使用します。スキル定義またはシステムプロンプトでバイナリパスを明示的に宣言します。
AI ツールの起動方法と、シェルプロファイル (
~/.bashrcまたは~/.zshrc) を継承しているかどうかを確認します。
エージェントのループ再試行による大量のセッション発生を制限する方法
原因：エージェントでエラーが発生すると、繰り返し再試行し、そのたびに新しいセッションを作成するため、サーバー側のリソースを徐々に消費します。
解決策：
スキルまたはプロンプトで、認証失敗や存在しないインスタンスなどの再試行不可能なエラー (
--output jsonのmessageフィールドに基づいて判断) が発生した場合、自動的に再試行せずに直ちにエラーを報告するようにエージェントに指示します。セッションは、約 30 分のアイドルタイムアウト後に自動的に回収されます。セッションを長時間保持する必要がない場合は、エージェントの処理が完了次第
/exitでセッションを閉じるようにします。定期的に
workbench session close --allまたはworkbench daemon stopを実行して、残存セッションをクリーンアップします。
エージェントに --output json のみの使用を強制する方法
原因：デフォルトでは、エージェントはテキスト出力を使用することがあり、解析が不安定になる可能性があります。
解決策：スキル定義またはシステムプロンプトで、すべての workbench コマンド呼び出しに --output json を追加し、JSON スキーマに従って結果を解析するようにエージェントに明示的に指示します。成功した場合、フィールドは output、stderr、exit_code になります。失敗した場合は、{code, message} が出力されます。
関連ドキュメント
Workbench CLI を使用したインスタンスへの接続：ツールの位置づけとクイックスタートについて説明する親トピックです。
Workbench CLI のインストールと認証情報の設定：CLI のインストールと認証情報/権限の設定について説明します。
Workbench CLI を使用した ECS インスタンスの管理：各コマンドの詳細な説明とトラブルシューティング (connect セッション内で AI アシスタントを使用する方法を含む) を提供します。