Raindrop Workshop：讓 Claude Code 讀你的 trace、寫 eval、再自己修到過

它要解的是「agent 跑完之後沒人知道發生什麼事」

寫 agent 的人常遇到一種狀況：程式跑完了，輸出看起來不對，但你手上沒有任何中間過程。模型呼叫了哪些工具、在哪一步轉向、哪個 span 花掉最多時間，全都消失在 console 的殘影裡。Raindrop Workshop 針對的就是這個缺口。README 把它定位成「the local debugger your agent is missing」，訴求是讓你在本機即時看到 agent 的每一個 token、每一次工具呼叫、每一個決策。

目標讀者相當明確：已經在用 Claude Code 這類 coding agent 開發 agent 應用的工程師。README 的敘述是「Give Claude Code the power to read your traces, write evals against your codebase, and fix what's broken」，也就是把 trace 當成 Claude Code 的輸入，讓它據此產生 eval，再讓它自己把失敗修掉。這個定位比單純的 tracing 工具更進一步，因為它假設你的 coding agent 有能力讀懂你的程式碼並改動它。

如果你的工作流程裡沒有 coding agent，或者你的 agent 應用只是偶爾手動跑幾次、失敗了看 log 就能判斷，那 Workshop 的整套機制對你來說是超額配置。它不是一個通用的 APM，而是一個把除錯迴圈壓縮進編輯器工作階段的工具。

trace 從 SDK 側鏡射，經 HTTP 與 WebSocket 進到本機 daemon

從 README 能確認的資料流有兩段。第一段在 SDK 側：環境變數 RAINDROP_LOCAL_DEBUGGER 用來指定「where to mirror traces」，預設未設定。第二段在本機：raindrop workshop 會啟動一個 daemon，同時提供 HTTP 與 WebSocket 服務，預設埠是 5899，並在啟動後開啟瀏覽器 UI。README 描述 trace 是「streams into Workshop as it happens. No polling, no refreshing」，這與 WebSocket 的設定相符。

持久化落在 SQLite。RAINDROP_WORKSHOP_DB_PATH 的預設值是 ~/.raindrop/raindrop_workshop.db，也就是說 trace 預設存在使用者家目錄下，而不是專案目錄內。這個選擇有實際後果：同一個人在多個專案之間切換時，trace 會累積進同一個檔案，除非你為每個專案指定不同的 DB 路徑。對照之下，raindrop workshop reset 這個指令「delete local DB after confirmation」，刪的是整個本機資料庫，不是單一專案的資料。

至於 trace 從 SDK 到 daemon 之間走什麼協定、span 的資料結構長什麼樣、取樣策略如何，README 沒有交代。這部分無法從現有材料確認，需要實際安裝後觀察，或直接讀原始碼。

安裝路徑只有一條，原始碼建置是給貢獻者用的

README 對安裝的態度相當強硬，反覆強調不要 clone。正式路徑是一條指令：

curl -fsSL https://raindrop.sh/install | bash

裝完之後，在你的 repository 裡開啟 coding agent，執行 /instrument-agent。README 說這個指令「will instrument your agent with Raindrop tracing and open Workshop in your browser」，之後 trace 就會在 agent 執行時串進 UI。

如果你的環境需要明確的設定，CLI 提供了幾個入口。raindrop workshop setup 會寫入 .env 然後啟動並開啟 UI；raindrop workshop status 用來檢查健康狀態；raindrop update 更新執行檔。開發 Workshop 本身才需要 bun install 與 bun run dev，後者會同時啟動本機 daemon 與 Vite UI，預設位址是 http://localhost:5899。

另外有一個 replay 相關的指令 /setup-agent-replay，README 說它會「scaffolds an HTTP endpoint that replays a production trace against your real agent code」。這對把線上失敗案例拉回本機重現很有用，但 README 沒有示範這個 endpoint 的實際形狀，也沒有說明 production trace 要從哪裡取得。

eval 迴圈綁在 Claude Code 上，其他 coding agent 只被列在相容清單裡

README 的相容性清單很長：語言涵蓋 TypeScript、Python、Go、Rust；SDK 包含 Vercel AI SDK、OpenAI Agents SDK、Anthropic SDK、Claude Agent SDK、LangChain、LangGraph、CrewAI、Mastra、Pydantic AI、DSPy、Google ADK、Strands、Agno、Deep Agents；provider 涵蓋 AWS Bedrock、Azure OpenAI、Vertex AI；coding agent 則列出 Claude Code、Codex、Devin、Cursor、OpenCode。

問題在於，功能敘述裡反覆出現的只有 Claude Code。self-healing eval loop 的描述是「Claude writes the eval, runs your agent, sees the failure, fixes the code, and re-runs until every assertion passes」，coding-agent integration 那段同樣指名 Claude Code。清單上的其他 coding agent 到底能不能驅動這個 eval 迴圈，README 沒有說。這是一個明顯的落差：相容清單講的是「可以接入」，而 eval 迴圈講的是「Claude Code 可以讀懂並修改」。

如果你用的是 Cursor 或 Codex，合理的預期是 trace 能進來、UI 能看，但自動寫 eval 與自動修復那一段可能不會動。這不是文件瑕疵而已，它直接決定了這個工具對你的核心價值有多少。採用前應該先確認你的 agent 是否真的能觸發那條迴圈。

本機 Workshop 與 Raindrop Cloud 是兩套並存的安裝，不是升級關係

README 明確區分兩者：Workshop 是本機除錯器，Raindrop Cloud 是託管產品，提供 AI 功能的生產環境可觀測性。文件特別強調「Local Workshop and Raindrop Cloud coexist: they use distinct MCP server names (workshop vs raindrop) and separate install registries, so neither overwrites the other」。

雲端路徑的指令是 raindrop cloud setup，它會開啟瀏覽器登入、把組織的 RAINDROP_WRITE_KEY 寫進 ./.env，並安裝託管的 MCP server 與兩個 cloud skill（raindrop-setup、raindrop-investigate）。登入狀態另外由 raindrop login 管理，憑證快取在 ~/.raindrop，raindrop cloud setup 只在你尚未登入時才呼叫 login。安裝腳本也支援雲端模式：curl -fsSL https://raindrop.sh/install | bash -s -- --cloud，這個模式不會啟動本機 daemon。

這裡有個容易踩到的細節：RAINDROP_WRITE_KEY 會被寫進專案的 .env。如果你把 .env 納入版控，金鑰就跟著進去了。要撤除雲端安裝用 raindrop cloud uninstall，它會移除 MCP server 與 cloud skill、清掉 cloud install registry，但保留本機 Workshop；加上 --wipe 才會一併從 .env 移除金鑰。另外 README 提到非互動執行（CI、管線腳本）不會跳出提示，需要改用 raindrop cloud setup 或 --cloud。

以 SQLite 為儲存層的本機工具，代價在資料量與多專案共用

把 trace 寫進單一 SQLite 檔是一個務實的選擇：不用架資料庫、不用連線設定、刪除就是刪檔。但它同時定義了這個工具的邊界。長時間執行、高頻率的 agent 會持續往同一個檔案寫入，而 README 沒有提供任何保留期限、輪替或清理策略。唯一相關的指令是 raindrop workshop reset，而它是全刪，不是按時間或按專案刪。

多專案共用同一個預設 DB 路徑也值得注意。~/.raindrop/raindrop_workshop.db 是使用者層級的位置，不是專案層級。如果你同時在兩個 repository 上開發 agent，兩邊的 trace 會混在同一個資料庫裡，UI 上如何區分，README 沒有說明。要避免這個情況，只能自己設定 RAINDROP_WORKSHOP_DB_PATH。

這是本機除錯器的合理取捨，不是缺陷。但如果你的預期是拿它當長期的 trace 儲存庫，或想在團隊之間共享 trace，那就不對了。那正是 Raindrop Cloud 存在的理由。

替代方案：LangSmith 這類託管平台，差別在資料放哪與迴圈由誰驅動

同類工具裡，LangSmith 是常被拿來對比的一個。兩者的差異不在功能清單，而在架構前提。LangSmith 是託管服務，trace 上傳到雲端，eval 在平台上定義與執行，團隊成員透過瀏覽器共享同一份資料。Raindrop Workshop 走的是相反方向：daemon 跑在你自己的機器上，trace 存成本機 SQLite 檔，eval 由你本機的 coding agent 寫進你的 repository。

這個差別會直接影響幾件事。資料落地位置不同，前者需要你接受 trace 離開你的網路，後者預設不出本機。協作方式不同，前者天然支援多人共用，後者的 SQLite 檔在你的家目錄裡。eval 的歸屬也不同，Workshop 產生的 eval 是程式碼，跟著 repository 走；平台型的 eval 通常留在平台上。

如果你的團隊需要共享 trace、需要跨環境比對生產資料，託管平台的路徑更直接。如果你在意 trace 不出本機，或者你希望 eval 就是 repo 裡的一份程式碼、能進 code review，Workshop 的形狀更貼合。Raindrop 自己顯然也認為兩者對應不同場景，README 把它們描述成並存而非取代。

維護成本、版本節奏與 MIT 授權下的實際考量

授權是 MIT，這對商業使用相對寬鬆，條文細節仍應由你自己的法務判斷，這裡不做法律意見。值得注意的是安裝方式：README 建議的入口是 curl -fsSL https://raindrop.sh/install | bash，這是把遠端腳本直接交給 shell 執行。這在開源工具裡很常見，但它意味著你信任的是那個網域當下提供的內容，而不是 repository 裡被 tag 住的版本。對需要可重現建置的團隊，這是採用前應該先想清楚的點。

版本節奏可以從 release 紀錄看出一些端倪：v0.1.19 到 v0.1.20 之間相隔約八天，v0.1.20 到 v0.1.21 則在同一天內發布。0.1.x 的版號本身也說明專案還在早期。頻繁的小版本對使用者是雙面的：修正來得快，但介面與 CLI 行為也可能跟著變動。raindrop update 負責更新執行檔，README 沒有描述版本鎖定或回滾機制。

升級時要留意的具體項目包括 CLI 子指令的行為，例如 raindrop setup 在互動模式下會詢問是否設定 Raindrop Cloud，而這個提示在非互動環境不會出現。如果你的自動化流程依賴互動行為，版本更新後需要重新確認。

編輯結論

如果你已經在用 Claude Code，而且痛點是「agent 跑完之後不知道它為什麼做那個決定」，Workshop 值得先跑一次安裝腳本，把 RAINDROP_WORKSHOP_DB_PATH 指到專案外的固定路徑，再用 /instrument-agent 接一條真實的 agent 流程，看 trace 串流是否如 README 所述即時抵達。反過來說，如果你的主力 coding agent 是 Codex、Cursor 或 Devin，或者你只想看雲端彙整後的生產資料，那 Workshop 的本機 eval 迴圈對你幫助有限，直接看 Raindrop Cloud 那條路徑更合適。採用前務必確認兩件事：你的 agent 框架是否落在 README 列出的 SDK 清單內，以及 raindrop workshop reset 刪除本機 SQLite 的行為是否符合你團隊對 trace 保存的要求。

官方來源

1. License: MIT
2. Project website
3. raindrop-ai/workshop on GitHub
4. README
5. Releases