Cursor SDK のカスタムストア、カスタムツール、自動レビュー
TypeScript SDK と Python SDK に、いくつかの新機能を追加しました。エージェントと実行メタデータの保存方法を選べるようになり、独自の関数をツールとしてエージェントに公開したり、ローカルのツール呼び出しを自動レビュー経由で処理したり、ネストされたサブエージェントを任意の深さで入れ子にしたりできるようになりました。このリリースには信頼性、パフォーマンス、プラットフォームに関する一連の修正も含まれており、ローカルおよびクラウドの SDK エージェントを本番用スクリプト、CI、カスタム統合でより簡単に実行できるようになっています。"
カスタムツール
Agent.create() または send() ごとに local.customTools を通じて関数定義を渡すことで、ローカルエージェントに独自のツールを持たせられるようになりました。SDK は custom-user-tools という組み込みの MCP サーバーを通じてそれらをエージェントに公開するため、モデルはほかの MCP ツールと同じ経路と同じ権限ゲートを通じて、あなたのコードを呼び出します。
以前は、カスタム機能を公開するには、独自の stdio またはリモート HTTP の MCP サーバーを立ち上げてエージェントに接続する必要がありました。今では、関数定義だけで十分です。カスタムツールは親エージェントのすべてのサブエージェントからも参照できるため、一度定義すれば、そのツールを実行全体で利用できます。
自動レビュー
デフォルトでは、ローカル SDK エージェントは承認を求めずにツール呼び出しを実行します。ヘッドレス実行では人間が介在しないためです。代わりにこれらの呼び出しを自動レビューに通すには、local.autoReview を設定します。レビューを完全に迂回するのではなく、分類器がどの呼び出しを自動的に実行し、どれを保留にするかを判断します。
この分類器は、permissions.json 内の自然言語による instructions で調整できます。autoRun.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."
]
}
}JSONL とカスタムストア
どちらの 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-2slug に固定されたままの SDK クライアントは、自動的に Composer 2.5 にルーティングされるようになりました。高速バリアントも維持されるため、古いスクリプトも引き続き実行できます。
- workspace スコープの
list_runs:Client、AsyncClient、Agent.list_runsは省略可能なcwdを受け取るようになり、bridge は起動時の workspace にフォールバックします。これにより、bridge がサブプロセスとして実行される際に起きる、誤った「agent not found」結果が修正されます。 - より分かりやすい not-found エラー: 解決された workspace 内に存在しないエージェントを検索した場合、不明瞭な内部エラーではなく、分かりやすい not-found エラーが返るようになりました。
- 0.1.6 リリースとアナリティクス:
cursor-sdk0.1.6 では Buildkite のリリース経路が文書化され、SDK の利用状況はsdk-python-としてラベル付けされるため、アナリティクスがより分かりやすくなります。
アップグレードするには npm install @cursor/sdk または pip install cursor-sdk を実行してください。composer-2 に固定されたスクリプトは自動的に Composer 2.5 に移行し、requestId は実行メタデータスキーマに安全に追加できます。詳しくは、TypeScript と Python のドキュメントを参照してください。