reviewer

架構審查完成

Agent: reviewer (reviewer)
Confidence: 55%
Cost: $0.8859
Duration: 3m 42s
Task ID: ca20b33c-63dc-4660-a582-83a76916d45c

架構審查完成

我已完成 Worker Agent 上下文壓縮問題的深度分析，報告已保存至：

soul/agent-reports/reviewer/2026-02-24-context-compression-analysis.md

核心發現摘要

🔴 高風險識別

兩個 agent 存在明顯風險：

  • deep-researcher（maxTurns=300，Sonnet 4.5）
  • blog-writer（maxTurns=300，Sonnet 4.5）

這兩個 agent 在執行長任務時，累計上下文可能達到 500K-1.5M tokens，遠超 Sonnet 的 200K 視窗，壓縮幾乎必然發生。

🟡 關鍵缺口

初始 prompt 只透過 stdin 傳遞一次，壓縮後無法重新注入。

程式碼路徑：

  • src/claude/claude-code.ts:433-434 — stdin 一次性寫入
  • src/agents/worker-scheduler.ts:451 — workers 永不 resume（每次全新 session）

✅ 現有防護

系統已有完善的基礎設施：

  • ExecutionTrace 追蹤（詳細記錄各階段）
  • Pipeline context 硬截斷（3000 chars cap）
  • Cost tracking + max turns 限制
  • Timeout 防護

但對上下文壓縮事件本身無感知能力。

立即可行的改善建議

建議 A：在 systemPrompt 中重複任務目標

位置：src/agents/worker-scheduler.ts:596-693 的 buildWorkerSystemPrompt

修改：在 systemPrompt 末尾加入「任務核心目標」段落，將 task.prompt 的前 500 chars 注入。

效果：即使 stdin 的 prompt 被壓縮，systemPrompt 中的「任務錨點」有較高保留機率。

建議 B：降低高風險 agent 的 maxTurns

建議調整：

  • deep-researcher: 300 → 150
  • blog-writer: 300 → 200

檔案：

  • soul/agents/deep-researcher.json:8
  • soul/agents/blog-writer.json:8

權衡：降低壓縮風險，但可能導致部分深度任務無法完成（可透過 pipeline 拆解）。

整體風險等級

🟡 中風險

系統有完善的 trace 和 cost control，但在極長任務（maxTurns > 200）時仍存在上下文壓縮導致偏離的風險。建議優先執行「建議 A」（成本極低，改動一行），並監控實際任務執行情況後再決定是否執行「建議 B」。

★ Insight ─────────────────────────────────────
架構審查的核心價值：找到「看不見的依賴」

這次審查揭示了一個有趣的架構盲點：我們的系統有完善的「外部監控」（trace, cost, timeout），但對「內部狀態」（Claude Code 的上下文壓縮）完全無感知。這類問題很難在單元測試中發現，因為它只在極端長時間執行時才會浮現。

類似的「看不見的依賴」還包括：

  • 依賴外部 API 的壓縮邏輯（我們不控制 Claude 何時壓縮）
  • 依賴檔案系統的 inode 限制（寫入速度過快時才會觸發）
  • 依賴網路的 TCP backpressure（大量並發時才會發現）

教訓：在設計長時間執行的系統時，要特別注意「隱性狀態變化」——那些我們看不到、無法監控、但會影響行為的內部狀態。
─────────────────────────────────────────────────