yoi/docs/plan/memory-prompts.md

6.0 KiB
Raw Blame History

メモリ機構の prompt 要件

Context

docs/plan/memory.md で決めた memory の挙動を、実装時に prompt 要件へ落とすための補助ページ。ここでは「個別タスクをこなすベーシックな system / developer 指示」の上に追加で必要になる、memory 固有の指示だけをまとめる。

前提は tool-based + agentic。専用 schema で挙動を閉じ込めるのではなく、基本は sub-Worker に CRUD tool を渡し、prompt と post-write 検証で振る舞いを制約する。例外は Workflow で、docs/plan/workflow.md の通り自動書き込みはしない。

決定事項

共通原則

memory 関連 prompt は種別を問わず、最低限以下を共有する:

  • source を推論しないsession_id や entry range は wrapper / 呼び出し側が機械付与し、LLM が捏造しない
  • rewrite は許可するが、情報損失は最小化する。既存の主張・根拠・参照を保ったまま整理・圧縮する
  • 単純 append を優先しない。既存 record に統合できるなら update を優先する
  • session 固有の進行状態を書かない。長期参照価値のある内容だけを memory に残す
  • 既存 docs と重複保存しないAGENTS.mddocs/plan/*、固定運用文書に既にある内容を再保存しない
  • 空出力を許容する。保存価値が無ければ「何も追加しない」を正当な結果として扱う

Phase 1: 活動抽出 prompt

Phase 1 は「派生物を作る」段階ではなく、「起きたことを抽出する」段階として縛る:

  • 対象は decisionsdiscussionsattemptsrequests の候補に限る
  • Knowledge 化、summary rewrite、slug 命名、model_invokation 判断は行わない
  • 一回限りの雑談、浅い質問、長期参照価値の薄い進行ログは返さなくてよい
  • 出力は schema 準拠の構造化データのみ。自由文の補足説明で schema 外情報を足さない
  • 対象が無ければ空配列を返す

Phase 2: 統合 prompt

Phase 2 は既存 memory/*knowledge/*、staging を見て、追加・更新・統合を agentic に判断する:

  • 入力には staging の活動ログ、既存 memory/*summary / decisions / requestsの全文、Knowledge 化候補レポートを含める
  • 既存 knowledge/* は prompt に埋めず、Knowledge 検索ツール経由で agent が必要分を引く。まず候補レポートの source や staging の話題に近い slug を検索し、ヒットした slug / description / kind / model_invokation を見て適合先を探す
  • 新規作成より update を優先し、既存 slug に自然に統合できる場合は新規 file を増やさない
  • Decisions / Requests は staging の source をそのまま使い、LLM が sources を組み立てない
  • summary は必要なときだけ rewrite し、常に 1-5k tokens 目安に圧縮する
  • 削除は直接行わず、Decision の置き換えは status: replacedreplaced_by で表現する
  • 人間編集との不整合が見える rewrite は避け、衝突しそうなら保守的に統合する

Phase 2: Knowledge 書き込み prompt

Knowledge の新規作成 / 更新では、Phase 2 全体の原則に加えて以下を明示する:

  • 採択ラインは「このプロジェクト / ユーザーに対して再度参照価値のある事実・ルール・ノウハウ」に限る
  • 一回限りの判断や議論は Decisions に留め、繰り返し参照される抽象化だけを Knowledge に上げる
  • 新規作成は Knowledge 化候補レポートに載った source から派生する場合に限る
  • 既存 Knowledge は Knowledge 検索ツールで検索し、ヒットした slug / description / kind / model_invokation を見て、適合先があるなら必ず update を優先する
  • 新規 slug は「既存に適合先が無い」と説明できるときだけ作る
  • Knowledge は kind を frontmatter に持ち、少なくとも「用語 / 運用方針 / ルール / 事実 / ノウハウ」のどこに寄るかを明示する
  • last_sources は入力で与えられた source を使い、推論で補完しない
  • description は「何の知識か / いつ使うか」が短く分かる文にする
  • description だけで対象範囲が分からない粒度や、複数主題を抱えた file は避ける
  • model_invokation ON/OFF は頻度・常駐コストの判断材料を踏まえて慎重に扱い、初期値は OFF とする
  • #<slug> 参照を書く場合は、実在 record への参照だけを使う
  • AGENTS.mddocs/ に既に固定化されたルールの写しは作らない
  • 保存価値が無ければ Knowledge を何も追加しない

監査 LLM prompt

初期範囲では専用の監査 LLM は持たない(memory.md §書き込み経路と Linter / §将来検討 参照)。意味破壊の抑制は Phase 2 prompt 側の情報損失最小化指示と git diff レビューに寄せる。後から 2 層目として挟む際の入力・check 項目・pass-fail 返却形式はそのときに詰める。

GC prompt

GC は Phase 2 より攻撃的に整理してよいが、可逆性と説明可能性を保つ:

  • 入力には GC 対象 record 群に加えて、Linter Warn、使用頻度メトリクス、replaced chain、sources 過多情報を含める
  • 明示 invoke 保護閾値を超える record は drop / 大幅圧縮の対象外とする
  • 各 record を outdatedsupersededunusednoisy の観点で評価し、なぜ GC 対象なのかを分類する
  • similar-slugsources-overflowreplaced 滞留は主に superseded または noisy の材料として扱う
  • merge / split / trim / drop の理由を diff から読める形で残す
  • 直接削除してよいが、git で可逆である前提に甘えすぎず、誤判定しやすいものは merge / trim を優先する

関連

  • docs/plan/memory.md: memory 全体方針
  • docs/plan/workflow.md: workflow を自動書き込みの例外にしている理由