AgentScope 2.0は、複雑なエージェント作業を任せる開発チームに向け、計画・状態管理機能をまとめたハーネスを主な開発の入口に据えた。サーバーが作業を調整し、隔離されたサンドボックスがツールを実行する構造により、開発チームは共通基盤を再利用しつつ、業務ツールと結果の判断に集中できる。

1. ハーネスが複雑な作業の標準の入口に

Alibaba Cloudコミュニティが2026年11月11日に公開した記事は、Java実装を中心にAgentScope 2.0のハーネス構造を紹介している。フレームワークがモデルやツールなどの構成要素を提供するのに対し、ハーネスはモデルへの情報伝達、タスクの進行、ツールの呼び出し、進行状態の保存という作業の進め方まで組み合わせる。

従来のバージョンがモデルの判断とツール呼び出しを繰り返す流れやエージェント間の協調に重点を置いていたのに対し、今回は長期タスクに必要な作業の進め方を標準構成にまとめた。開発者はハーネスをそのまま使うことも、構成要素や実行過程をカスタマイズすることもできる。

2. サーバーによる調整と隔離実行を分ける

ツールを隔離環境で実行するTool-In-Sandbox構造では、モデルの判断とツール呼び出しをつなぐ流れ、モデル呼び出しとコンテキストの構成をサービス側で進める。ファイル操作やコマンド・コード実行など隔離が必要な動作は、ツールのインターフェースを通じてサンドボックスで実行し、結果と成果物をハーネスに返す。運用者はハーネスを中央で管理しながらユーザーやセッションごとの実行環境を構成し、調整サービスとサンドボックスのリソースを個別に拡張できる。

この構造は、複数の事業チームにエージェントをサービスとして提供したい組織を想定している。プラットフォームチームは状態管理、隔離環境、権限と可観測性の機能を共通基盤として提供し、事業チームはドメイン知識やツール、結果の受け入れ基準を担う形だ。重複実装を減らせる一方、状態や権限、実行環境を運用する責任もプラットフォーム設計に集中する。

3. タスク・情報・行動をつなぐ仕組み

記事はハーネスの役割をタスク、情報、行動の3層で説明する。タスク層は計画と進行状態、サブエージェントの協調を扱い、情報層はモデルに渡す資料とワークスペースを構成する。行動層はツールの実行権限を確認し、実行結果を次の判断の根拠として返す。

計画モードに入ると、通常の変更ツールを遮断し、読み取り専用ツールと計画・協調用に許可したツールを残す。影響の大きい変更では、まず調査して計画を立て、人の確認を経て実行する方式だ。以下は原文のJavaの例でハーネスを構成する部分である。

HarnessAgent agent = HarnessAgent.builder()
        .name("remediation-agent")
        .model(model)
        .workspace(workspace)
        .enablePlanMode()
        .enableTaskList()
        .planFileDirectory("plans")
        .build();

原文が挙げた決済サービスの依存関係の脆弱性を修正する事例に当てはめると、計画が修正範囲を定め、テスト結果が次の修正の根拠となる。目標と現在の進行状態、検証結果を分けて管理し、長い対話の中で何を終えたのかを再び推測する手間を減らす方式だ。

4. 導入時には業務の境界も設計

導入対象は、複数の段階を経ながら情報が蓄積し続け、実行中に次の経路を探す必要がある作業だ。経路が決まった短い問い合わせや構造化情報の抽出には、軽量な呼び出しと作業の調整が適している場合もあると記事は説明する。

脆弱性の修正業務であれば、アプリケーションは検査するコードのバージョンと、テスト、セキュリティ点検、提出文書の受け入れ基準を定める。サンドボックスにはコード修正とテストに必要な権限を与え、本番環境へのデプロイは別の業務ツールで扱う形で、実行の境界を設計できる。

5. 実装言語と実行環境に合わせて適用

併せて確認したAgentScopeの公開リポジトリはPython実装を案内しており、Python 3.11以上を必要とする。ローカル環境に加え、アプリケーションを隔離して実行する単位であるコンテナや外部サンドボックスとの連携に対応し、複数のユーザーとセッションを扱うエージェントサービスも提供する。Javaの紹介記事とは別に、Pythonでの適用方法を確認できる資料だ。

Javaの例で計画機能を有効にするだけでは、作業は計画モードで開始されないため、計画を先行させる必要があるアプリケーションはモードへの移行を明示しなければならない。業務結果の自動受け入れも標準提供されるものではなく、検査対象と基準、検証手順は呼び出し側が構成する必要がある。

AgentScope 2.0の変化は、エージェントの組み立てを超えて長期タスクの作業の進め方を標準のハーネスにまとめた点にあり、その利便性の代償は業務権限と結果の受け入れ基準を明確に設計する責任である。