コンテキストセットとピン留め
エージェントが start_session を呼んだとき渡されるのは、ナレッジベース全体ではなく、あなたがキュレーションした起点のコンテキストです。Agents → Context は、その起点のコンテキストを組み立てるビルダーです。エージェントが起点で何を目にするかを、ここで過不足なく決めます。常にロードするノート(ピン留め)、スコープに紐づける再利用可能なまとまり(コンテキストセット)、そしてミュートするメモリのカテゴリです。タグによるピン留めとメモリのミュートはファイルファーストで、ノートのフロントマターに書かれるため、リポジトリをクローンし直しても失われません。一方、コンテキストセットとスペース横断のピン留めはメタデータデータベースに保存されます(これは承知のうえの但し書きで、まっさらなホストへのクローンし直しでも none モードでも、これらは残りません)。
常時ロードのピン留め
ピン留めは、手で付ける「常にロード」の印です(always-load タグに属しているかどうかであって、並び順ではありません)。ピン留めには2つの軸があります。
- 個人 — 個人ドメインにあるノートは
profile.alwaysLoadに入り、すべてのセッションでロードされます。 - プロジェクト — 印を付けたプロジェクトのサブツリーにあるノートは
project.alwaysLoadに入り、エージェントがそのプロジェクトで作業しているとき(projectヒント)にロードされます。
ピン留めはノートの置き場所に紐づきます。個人ドメインのノートはプロファイルへ、プロジェクトのサブツリーにあるノートはそのプロジェクトのバンドルへピン留めされます。ビルダーが見せるのは、エージェントが実際にロードするものそのままです。サーバー側のキュレーションもプレビューも、同じコードを通っています。
コンテキストセット — スペースを横断するまとまり
always-load タグでは、ピン留めは1つのスペースの中に閉じます。コンテキストセットはその制約を外します。コンテキストセットとは、名前を付けて再利用できるノート参照のコレクションで、別のスコープに紐づけられます。
よくある使い方はこうです。共有スペース conventions のノートから「フロントエンド規約」というセットを組み立て、別のスペースにあるプロジェクトへ紐づける。以降、それらのプロジェクトはセッションのたびにこのノート群を受け取り、あなたはセットを1か所で直すだけで済みます — どこでも同時に更新されます。
もっと軽い選択肢もあります。スペース横断のルースピンです。セットで包まず、別のスペースにあるノート1つをスコープへ直接ピン留めします。always-load タグは同一スペース内のピン留め用、セットとルースピンはスペース横断用、という住み分けです。三者は共存でき、重複は note-id で排除されます。
セットはホームとなるスペースに属し、そこでのメンバーシップが閲覧と編集の権限を付与します。個人セットを紐づけられるのは自分の個人ドメインだけです。共有スペース発の共有セットなら、個人ドメインにも任意のプロジェクトにも紐づけられます。個人セットをプロジェクトに紐づけることはできません — それではコンテキストがロードされるのはあなたにだけになってしまうからです。
並び順 = ロードの優先度
一覧でのピン留めとセットの並び順は、自動で導かれるものではなく、あなたがドラッグ&ドロップで決めます。この並びがそのまま優先度になります。上にあるものほど先にロードされ、トークン予算に達したときに削られるのは最後です。ピン留めとセットは1本のランキングを共有するので、セットをピン留めより上に置くこともできます。全体のロード順は ピン留め → セット → メモリ(具体的なものが一般的なものに優先します)。そのうえで、あふれた分がスコープの予算に合わせて切り詰められます。
メモリのミュート(mute)
エージェントのメモリは、既定でコンテキストにロードされます。あるカテゴリがノイズになっているなら、そのカテゴリだけを狙ってミュート(mute)します。ミュートすると、明示的なリクエストなしにメモリがエージェントへ届く経路から、そのメモリが一律で外れます。
start_sessionの時点でロードされる個人プロファイルrecallのバンドル組み立てstart_session(project).knownValuesのカテゴリ辞書
search はミュート済みのメモリを除外しません。そもそもメモリをインデックスしているのは、「書く前に検索する」重複排除のためです。ここで隠してしまえば、エージェントはミュート済みのカテゴリを見つけられず、同じものを二重に作ってしまいます。ミュートは自動で入るコンテキストを黙らせるだけで、削除ではありません。明示的な検索と監査からは、これまでどおりすべてが見えます。元に戻すのは、同じ軸上の Unmute です。
単一のトークン予算
ビルダーの各セクションの上には、ロード量のゲージが1本だけあり、現在のスコープの予算とぴったり一致します。個人向けの応答は1つの予算で動き(まずピン留め、次にメモリ)、プロジェクト向けの応答は独自の予算を持ちます。そこではプロジェクトのピン留めが先に来て、個人側の下地は残りの枠に収まります。ロードされる量は常に予算以下で、どこが切り詰められたかは項目ごとに見えます。プロジェクトのメモリは最初からロードされるのではなく、求められたときに引き出されます。特定のプロジェクトの事実が毎回必要なら、そのノートをピン留めしてください。