ドメインの知識がオンデマンドでロードされる
「システム プロンプトにすべてを入力しないでください。オンデマンドでロードしてください。」
「フルシステムプロンプト」の落とし穴
あなたには 20 のスキルがあり、それぞれが詳細に書かれています: pdf-processing (PDF の読み方)、code-review (レビュー チェックリスト)、git-workflow (一般的に使用される git ルーチン)... 直感的な方法: それらをすべてシステム プロンプトに入力すると、いつでもモデルを参照できます。
結果:
- 呼び出しごとに 15~30,000 の入力トークンを書き込みます (問題にまったくスキルが必要ない場合でも)。
- モデルの注意力が薄れます。長いシステム プロンプトで説明されるルールへの準拠性が低下します。
- スキルを変更すると、すべての会話履歴のキャッシュが無効になります。
s05 の作り方は 2 つのレイヤーに分割します。
2層アーキテクチャ
レイヤー 1 · 安価: スキルの名前と 1 文の説明のみがシステム プロンプトに表示されます (それぞれ約 100 トークン)。 20 スキル = 2,000 トークン、許容可能。
# 系统提示里的 skill 清单
Skills available:
- pdf: Process PDF files. Extract text, tables, metadata.
- code-review: Systematic code review checklist.
- git-workflow: Common git branching and rebase patterns.
レイヤー 2 · オンデマンド: モデルが特定のスキルを使用する必要がある場合、load_skill(name="pdf") を呼び出すと、完全なスキル本体 (おそらく 5 ~ 10,000 トークン) が、tool_result を通じてコンテキストに挿入されます。未使用のスキルのトークンはロードされません。
# tool_result 里返回完整 skill
<skill name="pdf">
Step 1: Use pdfplumber for extraction...
Step 2: Handle OCR fallback when needed...
Step 3: Structure output as Markdown table...
</skill>
トークンのコストを比較する
実際のシナリオでテストします。 20 のスキルがあり、各ボディに平均 3000 のトークンがあるとします。ユーザーが質問をします (「ログイン インターフェイスのバグを修正してください」など)。この質問にはおそらくスキルは必要ありません。
SKILL.md形式
スキル ファイルは YAML フロントマター + ボディを使用します:
--- name: pdf description: Process PDF files. Extract text, tables, metadata. tags: document,parsing --- Step 1: Use pdfplumber for extraction. Handle multi-column layouts... Step 2: For scanned PDFs, fall back to OCR via tesseract...
フロントマターはレイヤー 1 (名前/説明/タグ)、本文はレイヤー 2 です。この書き方は静的ブログ (Jekyll、Hugo) からインスピレーションを得たもので、慣れている人なら一目で理解できます。