探索者

探索主題

Agent: 探索者 (explorer)
Confidence: 78%
Cost: $0.5713
Duration: 1m 33s
Task ID: c7d272f1-f8c8-44a5-9fe3-11e136d6e3f9

現在我有了足夠的理解。讓我產出報告。

探索主題

「更快的路」—— Agent SDK in-process 整合 vs 現有 CLI subprocess 模式

發現

  1. 我們目前走的「彎路」：每次 agent 呼叫都 spawn 一個新的 Claude Code CLI 子進程（src/claude/claude-code.ts:1），經歷進程啟動 → stdin/stdout JSON 串流 → 解析結果。每次 IPC 都有啟動成本和序列化開銷。

  2. 更快的路：Claude Agent SDK。Anthropic 已推出 TypeScript 版 Agent SDK，將 agentic loop 作為 in-process library 運行，消除進程啟動和 IPC 開銷。自訂 tools 可以用原生函式註冊，無需 MCP server 或子進程。

  3. 但我們不該立刻走捷徑。我們的 CLI 整合已經建立了豐富的基礎設施：session 管理（session-store.ts）、model escalation（escalateModel()）、stream progress 追蹤、busy lock、自動 retry、worktree 隔離。這些都是「彎路」中累積的智慧。遷移到 SDK 需要重新實作這些安全機制。

  4. 混合策略最務實：輕量級呼叫（classifier、dream、diary 等無需工具的 LLM 呼叫）可以改用 Anthropic Messages API 直接呼叫（我們已有 @anthropic-ai/sdk），省去 CLI 啟動成本。重度 agent 任務（programmer、architect 等需要 Read/Edit/Bash 工具的）繼續用 CLI subprocess，因為它自帶工具沙箱和權限管理。

  5. SitePoint 的比較文（2026/2/27）驗證了這個策略：「3 個以下 agent 的線性 pipeline 用自訂方案最佳，超過 20 個 agent 的動態路由才需要框架。」我們的 pipeline engine 已經走在正確的中間路線上。

有趣的連結

  • 這個問題與「過早優化」的辯證完全吻合：彎路上累積的 error handling、session 管理、model escalation 正是系統韌性的來源。如果一開始就走「快路」（直接 API），我們可能會缺少這些防護。
  • Claude-Flow 這個開源框架試圖做中間層，但生態尚未成熟，對我們現有架構沒有吸引力。

延伸問題

  1. 能否將 classifier/dream/diary 等輕量呼叫從 CLI subprocess 遷移到 Anthropic Messages API 直呼？ 預估可省去每次 ~1-2 秒的進程啟動時間，每天數十次呼叫累計可觀。具體做法：在 claude-code.ts 旁新增 anthropic-direct.ts，對不需要工具的場景走 API。

  2. Agent SDK TypeScript 版的穩定性如何？ 如果足夠穩定，長期可以替換 CLI subprocess 層，但需要重新實作 tool permission 沙箱。

重要性：4/5

理由：直接影響系統效能和 API 成本。混合策略（輕量呼叫走 API、重度任務走 CLI）可立即實作，不需要大規模重構。