探索者

探索主題

Agent: 探索者 (explorer)
Confidence: 83%
Cost: $0.4009
Duration: 1m 26s
Task ID: dfb572fc-58c5-40ed-8f4b-dc357680da99

我現在有足夠的資訊來完成探索報告了。

探索主題

「更快的路」——從 CLI subprocess 到 Agent SDK 的架構跳躍

發現

  1. 我們走的「彎曲路」：專案目前透過 child_process.spawn 呼叫 Claude Code CLI，每次調用都是新 process（src/claude/claude-code.ts:1），每次啟動有 ~12 秒的冷啟動開銷。這是最顯著的「彎路」。

  2. 更快的路已存在：Claude Agent SDK TypeScript 提供 in-process 的 query() API，不需要 spawn 子進程。但根據 Issue #34，SDK 本身仍有 ~12s/call 的開銷（每次 query 都 spawn 新 process），尚未實現 hot process reuse。因此「更快的路」目前和「彎路」速度相當。

  3. 真正的快路是 Anthropic Messages API：直接呼叫 @anthropic-ai/sdk 的 Messages API 只需 1-3 秒回應。但這會失去 Claude Code 的 agent loop、tool use、file I/O 等能力——我們的 multi-agent 架構（worktree isolation、MCP tools、session resume）全部依賴 CLI 的 agentic 能力。

  4. 第二條快路：Webhook 取代 Long Polling：grammY 原生支持 Cloudflare Workers webhook 模式，可以把 Telegram 入口從 WSL2 本機遷移到 edge，但我們的 bot 需要 filesystem access（soul/、plugins/、git worktree），Workers 無法做到。這是一條「看起來快但走不通」的路。

  5. 最務實的加速：我們已經有 session resume（--resume flag, session-store）和 per-chat queue。真正可改善的是 Agent SDK 的 session-based API（一旦 Anthropic 實作），或是自建 process pool——保持 2-3 個 warm Claude Code process，重複使用而非每次 spawn 新的。

有趣的連結

  • 這個「要不要走彎路」的問題，映射到軟體架構的經典抉擇：正確性 vs 速度。CLI subprocess 模式雖慢，但提供完整的 agentic 能力（tools、sandbox、MCP）。直接 API 呼叫雖快，但喪失 agent loop。我們選擇了正確性。
  • grammY 的 webhook + Cloudflare Workers 是另一個「看似更快但犧牲太多」的例子——edge 部署很酷，但 soul/ 必須在本機。

延伸問題

  • Claude Agent SDK 何時會支援 hot process reuse？ 一旦實現，可以從 raw CLI spawn 遷移到 SDK 的 query() API，獲得 ~10x 的續發查詢加速（12s → <1s）。這是值得持續追蹤的上游 issue。
  • 能否建立 warm process pool？ 在 claude-code.ts 中預先 spawn 2-3 個 idle Claude Code CLI process，收到請求時直接 pipe prompt 進去，省去冷啟動。需要研究 CLI 是否支持 stdin 持續輸入模式。

重要性：4/5

直接影響專案的回應速度和 agent 吞吐量。一旦上游 SDK 成熟，遷移可節省大量 per-call overhead，改善所有 agent 的執行效率。