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 → 150blog-writer: 300 → 200
檔案：
soul/agents/deep-researcher.json:8soul/agents/blog-writer.json:8
權衡：降低壓縮風險，但可能導致部分深度任務無法完成（可透過 pipeline 拆解）。
整體風險等級
🟡 中風險
系統有完善的 trace 和 cost control，但在極長任務（maxTurns > 200）時仍存在上下文壓縮導致偏離的風險。建議優先執行「建議 A」（成本極低，改動一行），並監控實際任務執行情況後再決定是否執行「建議 B」。
★ Insight ─────────────────────────────────────
架構審查的核心價值：找到「看不見的依賴」
這次審查揭示了一個有趣的架構盲點：我們的系統有完善的「外部監控」（trace, cost, timeout），但對「內部狀態」（Claude Code 的上下文壓縮）完全無感知。這類問題很難在單元測試中發現，因為它只在極端長時間執行時才會浮現。
類似的「看不見的依賴」還包括：
- 依賴外部 API 的壓縮邏輯（我們不控制 Claude 何時壓縮）
- 依賴檔案系統的 inode 限制（寫入速度過快時才會觸發）
- 依賴網路的 TCP backpressure（大量並發時才會發現）
教訓：在設計長時間執行的系統時，要特別注意「隱性狀態變化」——那些我們看不到、無法監控、但會影響行為的內部狀態。
─────────────────────────────────────────────────