探索者

探索主題

Agent: 探索者 (explorer)
Confidence: 73%
Cost: $0.4077
Duration: 1m 26s
Task ID: 7c912dd2-82ad-4fd4-b06f-559899941f16

完美。現在我有完整的圖景了。以下是我的探索報告：

探索主題

「更快的路」vs「彎曲的路」— CLI Subprocess 架構的演進選擇

發現

  1. 我們已經走在「更快的路」上了：claude-code.ts:367-371 已實作 4 層 token 隔離中的 2 層（--setting-sources project + --plugin-dir EMPTY_PLUGIN_DIR），將每次 subprocess 的 context 開銷從 ~50K 降到合理範圍。MAMA 專案的研究驗證了這是正確方向。

  2. 尚未實作的 2 層優化空間：

    • Layer 2（git boundary）：Agent 的 cwd 若未隔離，Claude CLI 會向上遍歷找 CLAUDE.md，意外注入額外 context。我們用 worktree 已部分解決（worktree 有自己的 .git），但非 worktree agent 仍暴露在此風險中。
    • Layer 5（MCP tool filtering）：每個 agent 加載所有 MCP tool 描述（我們有 hexo、cloudflare、bot-tools 等大量工具），即使它只需要 2-3 個。加入 allowed_tools per-agent 可再省數千 token。

  3. Persistent stream-json 模式是最大的未採摘果實：目前我們每次 dispatch 都 spawn 新 process（one-shot），system prompt 每次重送。如果改為 persistent process + stdin 餵訊息，system prompt 只送一次，N 輪對話省 (N-1) 次重複注入。

  4. Agent SDK TypeScript 包已可用：Anthropic 官方的 Agent SDK 提供 TypeScript 原生整合，比 CLI subprocess 更快、更省 token、有型別安全。但代價是失去 CLI 的內建 agentic loop（tool execution、permission model、session persistence）。現階段不建議全面遷移——風險太大，收益有限。

  5. Strangler Fig 模式是正確的遷移策略：不需要二擇一。可以對高頻 agent（programmer、reviewer）先切換到 persistent process 模式，低頻 agent 維持現狀。逐步「勒死」舊路徑。

有趣的連結

  • Token 浪費不是 LLM 的「自然法則」，而是 stateless API 設計的副作用——provider 的 prompt caching（90% 折扣）本質上是在「修補」重複注入問題，而非消除它
  • 我們的 --setting-sources project flag 是在 2026/2/28 的 commit 82626b9 加入的，標題寫 “token isolation”，說明團隊已有此認知

延伸問題

  • 具體能省多少？ 可以在 claude-code.ts 加入 per-turn token tracking（從 stream-json 的 usage 欄位擷取），量化目前的 context tax 比例
  • Persistent process pool 可行性？ 對 programmer/reviewer 等常駐 agent 維持 long-lived process，用 stdin 送新任務而非每次 spawn——需要評估 memory leak 和 session state 管理

重要性：4/5

直接影響專案的 token 成本和 agent 回應速度。4 層隔離的後 2 層 + persistent process 模式，預估可再省 30-50% token 消耗。這不是理論，是有具體 PR 和數據支持的實作方案。