TypeScript SDK と Python SDK に、いくつかの新機能を追加しました。エージェントと実行メタデータの保存方法を選べるようになり、独自の関数をツールとしてエージェントに公開したり、ローカルのツール呼び出しを自動レビュー経由で処理したり、ネストされたサブエージェントを任意の深さで入れ子にしたりできるようになりました。このリリースには信頼性、パフォーマンス、プラットフォームに関する一連の修正も含まれており、ローカルおよびクラウドの SDK エージェントを本番用スクリプト、CI、カスタム統合でより簡単に実行できるようになっています。"
# Agent.create() または send() ごとに local.customTools を通じて関数定義を渡すことで、ローカルエージェントに独自のツールを持たせられるようになりました。SDK は custom-user-tools という組み込みの MCP サーバーを通じてそれらをエージェントに公開するため、モデルはほかの MCP ツールと同じ経路と同じ権限ゲートを通じて、あなたのコードを呼び出します。
以前は、カスタム機能を公開するには、独自の stdio またはリモート HTTP の MCP サーバーを立ち上げてエージェントに接続する必要がありました。今では、関数定義だけで十分です。カスタムツールは親エージェントのすべてのサブエージェントからも参照できるため、一度定義すれば、そのツールを実行全体で利用できます。
# デフォルトでは、ローカル SDK エージェントは承認を求めずにツール呼び出しを実行します。ヘッドレス実行では人間が介在しないためです。代わりにこれらの呼び出しを自動レビュー に通すには、local.autoReview を設定します。レビューを完全に迂回するのではなく、分類器がどの呼び出しを自動的に実行し、どれを保留にするかを判断します。
この分類器は、permissions.jsonautoRun.allow_instructions フィールドには許可寄りで扱いたい呼び出しパターンを記述し、autoRun.block_instructions にはレビューのために保留したいものを記述します。たとえば、構築されたアーティファクトの読み取り専用の確認は許可しつつ、削除のような破壊的な操作では常に一時停止するようにできます。
{ "autoRun" : { "allow_instructions" : [ "Read-only inspections of build artifacts under ./dist are fine." ], "block_instructions" : [ "Always pause delete operations so I get a chance to review them." ] } } # どちらの SDK も、プロセスの再起動後にエージェントを再開できるよう、エージェントと実行に関するメタデータを永続化します。これまでは、そのストアは SQLite でした。現在は代わりに JSONL ストアを選択でき、読み取りや diff の確認、version control へのチェックインが可能な、プレーンな追記専用ファイルに書き込めます。SqliteLocalAgentStore と JsonlLocalAgentStore はどちらも直接エクスポートされます。
どちらのデフォルトも設定に合わない場合は、public な LocalAgentStore interface を実装し、local.store を通して渡します。エフェメラルな CI 実行向けにインメモリストアを構築したり、エージェントの状態をアプリケーション内の他のデータと一緒に保持したい場合は、永続化先として Postgres を使ったりできます。Python SDK は、host、JSONL、composed JSONL ストアをブリッジ経由で公開しています。
# サブエージェントが、自身のサブエージェントをさらに生成できるようになりました。レビュー用のサブエージェントはテスト作成用のサブエージェントに委任でき、その先もさらに委任できます。各階層はそれぞれ独自のプロンプトとモデルを保持します。特別に有効化する設定は必要ありません。サブエージェントのセッションは、Task を呼び出すために必要なエグゼキューターを登録するため、ネストは、サブエージェントを定義するすべてのエージェントで自動的に機能します。
# 今回のリリースには、両方の SDK にわたる使い勝手を向上させるさまざまな修正も含まれています。
信頼性↓ ↑
実行の相関付け : すべての send() に、プラットフォームで生成された requestId が付与されるようになりました。これは Run と RunResult で利用でき、インメモリ、SQLite、JSONL の各ストアにも保存されます。これにより、agentId から推測しなくても、スクリプトや CI の実行をバックエンドログ、アナリティクス、サポートスレッドに結び付けられます。ローカル実行で信頼性の高い wait() : ローカル実行で、ターミナル結果が書き込まれる前に wait() が完了してしまうことがなくなりました。Hydration は実行が最終状態に達するまで更新を続けるため、自動化処理で完全な結果を読み取れます。dispose 時の安全なチェックポイント : ローカルエージェントを破棄しても、ルート参照が見つからない一方でチェックポイント blob が残っている場合、チェックポイントデータは削除されなくなりました。エージェントディレクトリが消去されるのは、保持すべきものが本当に何も残っていない場合だけです。HTTP/1.1 での Cloud ストリーミング : 一部のプロキシ、古い Node の fetch スタック、特定の CI イメージで使われる HTTP/1.1 transport 上でも、クラウドエージェントのセッションが正しくストリーミングされるようになりました。HTTP/2 の動作に変更はありません。 パフォーマンスとパッケージング↓ ↑
軽量な import : @cursor/sdk を import しても、ローカルエージェントスタック全体が即座に読み込まれなくなりました。Cloud 専用の利用や型だけを使うケースでは、最初のローカル呼び出しまでローカルランタイムのコストが発生せず、API の変更もありません。最初のローカル呼び出し時に一度だけ import コストが発生し、その後はキャッシュされます。自己完結した TypeScript 型 : 公開される .d.ts ファイルが、未公開の workspace パッケージを参照しなくなりました。これにより、skipLibCheck: false 環境での TS2305 や TS2307 エラー、および TurnEndedUpdate のようなストリーム型で暗黙に any になってしまう問題が修正されます。バンドル版 ripgrep : ローカルシェル実行では、グローバルな PATH を変更せずに、バンドルされたプラットフォームの rg バイナリを使います。Windows では、ripgrep を先頭に追加しても Path 変数を壊さなくなりました。 モデル↓ ↑
Composer 2 は Composer 2.5 にルーティング : 廃止された composer-2 slug に固定されたままの SDK クライアントは、自動的に Composer 2.5 にルーティングされるようになりました。高速バリアントも維持されるため、古いスクリプトも引き続き実行できます。 Python SDK↓ ↑
workspace スコープの list_runs : Client、AsyncClient、Agent.list_runs は省略可能な cwd を受け取るようになり、bridge は起動時の workspace にフォールバックします。これにより、bridge がサブプロセスとして実行される際に起きる、誤った「agent not found」結果が修正されます。より分かりやすい not-found エラー : 解決された workspace 内に存在しないエージェントを検索した場合、不明瞭な内部エラーではなく、分かりやすい not-found エラーが返るようになりました。0.1.6 リリースとアナリティクス : cursor-sdk 0.1.6 では Buildkite のリリース経路が文書化され、SDK の利用状況は sdk-python- としてラベル付けされるため、アナリティクスがより分かりやすくなります。 アップグレードするには npm install @cursor/sdk または pip install cursor-sdk を実行してください。composer-2 に固定されたスクリプトは自動的に Composer 2.5 に移行し、requestId は実行メタデータスキーマに安全に追加できます。詳しくは、TypeScript と Python のドキュメントを参照してください。
