From 670abdc3362350b5cc5b490db99626842bcb3606 Mon Sep 17 00:00:00 2001 From: Hare Date: Sat, 2 May 2026 23:57:36 +0900 Subject: [PATCH] =?UTF-8?q?docs(tickets):=20memory-consolidation-drop-inpu?= =?UTF-8?q?t-cap=E5=AE=8C=E4=BA=86?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../memory-consolidation-drop-input-cap.md | 65 ------------------- 1 file changed, 65 deletions(-) delete mode 100644 tickets/memory-consolidation-drop-input-cap.md diff --git a/tickets/memory-consolidation-drop-input-cap.md b/tickets/memory-consolidation-drop-input-cap.md deleted file mode 100644 index 4fb7ad08..00000000 --- a/tickets/memory-consolidation-drop-input-cap.md +++ /dev/null @@ -1,65 +0,0 @@ -# Memory Phase 2: 累積入力トークン上限の撤去 - -## 背景 - -Phase 2 (memory.consolidation) の sub-Worker には、累積入力トークンが -`MEMORY_CONSOLIDATION_WORKER_MAX_INPUT_TOKENS = 80_000` を超えると -`PreRequestAction::Cancel` でアボートする circuit-breaker -(`MemoryConsolidationWorkerInterceptor`) が組み込まれている。 -manifest からも `[memory] consolidation_worker_max_input_tokens` で -上書きできる。 - -実運用で、このアボートが notice として頻繁に出ることが分かった: - -``` -[notice] pod: memory Phase 2 consolidation failed: -Aborted: Phase 2 consolidation worker input exceeded 80000 tokens -``` - -原因は `build_consolidate_input` が staging 全文 + 既存 memory 全文を -毎ターン頭で詰めるため、ツール呼び出しを伴う複数ターンで累積入力が -80K に達するため。`worker.on_usage` の `input_tokens` を素直に加算 -しているのでキャッシュヒット込みの値で上限を圧迫する。 - -そもそも Phase 2 は staging + 既存 memory を **全部読まないと判断 -できない** 統合タスクであり、入力サイズで途中アボートしても staging が -未消費のまま残るので、次回 Phase 2 トリガで同じ理由で再度落ちる。 -ユーザーが手で staging を間引かない限り永遠に notice が出続ける。 - -入力が context window に乗らない極端なケースは LLM 側で context -overflow になるため、自前で先回りして止める意味は薄い。runaway 防止は -別途 `Worker::max_turns` が存在するのでそちらに任せる方が筋がよい。 - -## ゴール - -Phase 2 consolidation worker の累積入力トークン上限を撤去する。 -runaway 対策は `Worker::max_turns` に寄せる。 - -## 要件 - -- `MemoryConsolidationWorkerInterceptor` を削除 -- Phase 2 構築箇所 (`Pod::run_consolidate_once`) の interceptor 注入と - `on_usage` 累積カウンタを撤去 -- `MemoryConfig::consolidation_worker_max_input_tokens` を削除 -- `manifest::defaults::MEMORY_CONSOLIDATION_WORKER_MAX_INPUT_TOKENS` を削除 -- manifest cascade (`config.rs`) からも当該フィールドを削除 -- 既存 manifest がこのキーを含んでいたとしても、`#[serde(deny_unknown_fields)]` - 系で読み込み時にエラーにならないよう確認 (現状 `deny_unknown_fields` を - 使っていなければ無視されるはずだが、要確認) -- 関連テスト・docs から `consolidation_worker_max_input_tokens` への - 参照を一掃する - -## 範囲外 - -- Phase 1 (extract) 側の `extract_worker_max_input_tokens` の扱い - (extract は session history の切り出しサイズに別の意味があるため別件) -- compact 側の `compact_worker_max_input_tokens` の扱い -- `Worker::max_turns` のデフォルト値見直し (現状の挙動で問題が出てから検討) -- 累積入力トークンを cache hit/miss で区別するなどのカウンタ精緻化 - -## 完了条件 - -- `cargo check` / `cargo test` が `manifest`, `memory`, `pod` で通る -- Phase 2 trigger が走った際、入力サイズに起因する Aborted notice が - 発生しないこと (整合性レビューで `MemoryConsolidationWorkerInterceptor` - および対応する manifest field が完全に消えていることを確認)