Raindrop Workshop：让编码 Agent 自己写并跑 Agent 评测

它要解决的是 Agent 调试里最费时间的那一段

普通 Agent 项目出问题时，开发者面对的是一个黑盒：模型输出了什么、调了哪个工具、参数对不对、中间哪一步开始跑偏，全靠自己往代码里插日志。Raindrop Workshop 把这段过程变成可视的：README 的说法是「每一个 token、每一次工具调用、每一个决策」都会流进 Workshop，而且是实时流式，不需要轮询或刷新。

它的目标用户不是做模型训练的人，而是写 Agent 应用的工程师，尤其是已经在用编码 Agent 的那批人。README 里反复强调的用法是：在仓库里打开 Claude Code，执行 /instrument-agent，Agent 就被接上 Raindrop tracing，同时浏览器里打开 Workshop。之后 trace 会在 Agent 运行的当下出现。

这个定位值得说清楚。它不是一个评测框架，也不是一个 prompt 管理平台。它把「看」和「改」串在一起：先让你看到 trace，再让编码 Agent 读这份 trace 去写断言、跑、看失败、改代码、再跑，README 把这套循环叫 self-healing eval loop。评测本身不是新概念，新的是把写评测这件事交给一个能直接改你仓库的 Agent。

数据怎么流：本地 daemon、SQLite 与流式 UI

从 README 能确认的架构信息有限，但足够拼出一条链路。安装脚本拉下来的是 raindrop 二进制，raindrop workshop 命令启动本地守护进程并打开 UI，默认监听 5899 端口，这个端口同时承担 HTTP 和 WebSocket，所以 trace 是推过去的而不是前端定时拉的。

落盘用的是 SQLite，默认路径 ~/.raindrop/raindrop_workshop.db，可以用 RAINDROP_WORKSHOP_DB_PATH 改。SQLite 这个选择意味着单机、单文件、无外部依赖，raindrop workshop reset 会先确认再删掉这个本地库，这是一条明确的清理路径。

SDK 侧还有一个环境变量 RAINDROP_LOCAL_DEBUGGER，README 的说明是「镜像 trace 到哪」，默认未设置。也就是说 trace 的来源是接进你 Agent 代码里的 SDK 埋点，而不是去抓网络流量。这一点决定了它的适用范围：没接 SDK 的进程不会出现在 UI 里。

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，模型侧提到 AWS Bedrock、Azure OpenAI、Vertex AI。清单很长，但 README 没有给出每种组合的验证状态，选型时值得按自己那一项去仓库里核对，而不是假定全矩阵等价可用。

安装只有一条命令，源码构建是给贡献者的

README 在这一点上态度很强硬：使用 Workshop 只需要一条命令。

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

文档明确说不需要 clone，也不需要 build，并且专门提醒：如果你在用 AI 编码 Agent，让它去跑这条命令，不要为了试用去从源码构建，源码路径只适用于开发 Workshop 本身的人。

装完之后在仓库里对编码 Agent 执行 /instrument-agent，它会接上 tracing 并打开浏览器。做生产 trace 回放的话，还有 /setup-agent-replay，README 说它会脚手架出一个 HTTP endpoint，用真实 Agent 代码回放某条生产 trace。

CLI 层面还有几条常用命令：raindrop workshop 启动并打开 UI，raindrop workshop setup 先写 .env 再启动，raindrop workshop status 查健康状态，raindrop workshop reset 确认后删本地库，raindrop update 更新二进制。

配置项一共三个，都在 README 的表格里：RAINDROP_WORKSHOP_PORT 默认 5899，RAINDROP_WORKSHOP_DB_PATH 默认 ~/.raindrop/raindrop_workshop.db，RAINDROP_LOCAL_DEBUGGER 默认未设置。数量少是好事，但也说明可调空间不大，比如端口冲突之外没有更多网络层选项。

贡献者路径是另一套：git clone 仓库，bun install，bun run dev，这条命令会同时起本地 daemon 和 Vite UI，启动后访问 http://localhost:5899。

让 Agent 写 eval 是个真实的设计取舍

self-healing eval loop 是 Workshop 最有意思也最该警惕的部分。按 README 的描述，流程是：Claude 写 eval，跑你的 Agent，看到失败，改代码，再跑，直到所有断言通过。

这里有一个必须点明的问题：断言是 Agent 写的，代码也是 Agent 改的。当同一个模型既定义「什么算通过」又负责让代码通过时，断言本身的质量就成了整个循环的上限。如果它把断言写松了，循环会更快地变绿，但那不代表被测行为真的正确。README 没有描述任何对生成断言的审查环节，也没有提到断言会被版本化或人工确认。

所以更稳的用法是把它当草稿生成器：让 Agent 基于 trace 产出断言，然后自己读一遍这些断言是不是真的在测你关心的行为，再决定是否合入。README 强调的那句「Claude 读取你的 trace，针对你的代码库写 eval，修好出问题的地方」，描述的是能力，不是保证。

另一个取舍在数据面。trace 会进本地 SQLite，同时也会被编码 Agent 读取。如果你的 trace 里带着用户输入、内部 prompt 或工具返回的敏感内容，那么「让 Agent 读 trace」就等于把这些内容送进了模型上下文。README 没有讨论脱敏或字段过滤，这一点需要你自己在埋点层面处理。

本地 Workshop 与 Raindrop Cloud 是两条不重叠的路径

README 把关系写得很清楚：Workshop 是本地调试器，Raindrop Cloud 是托管产品，做的是生产环境的可观测性，入口是 app.raindrop.ai。同一个 raindrop 二进制连接云端，且云端路径不涉及本地 daemon。

两条路径的安装命令不同。本地是 curl -fsSL https://raindrop.sh/install | bash，云端是 raindrop cloud setup，或者在安装一行命令时加参数：curl -fsSL https://raindrop.sh/install | bash -s -- --cloud。加 --cloud 时执行的是 raindrop cloud setup，不启动守护进程。

登录是独立的一层，凭证缓存在 ~/.raindrop，用 raindrop login 走 OAuth，raindrop logout 清除。README 说明 raindrop cloud setup 只在你尚未登录时才替你调用 login，所以日常只需要跑 cloud setup。cloud setup 会做三件事：把组织的 RAINDROP_WRITE_KEY 写进 ./.env，安装托管的 MCP server，以及把 raindrop-setup 和 raindrop-investigate 两个 cloud skill 装进你的编码 Agent。之后在 Agent 里执行 /raindrop-setup 完成应用埋点，事件流向 app.raindrop.ai。

两者可以共存，因为 MCP server 名字不同（workshop 与 raindrop），安装注册表也是分开的，不会互相覆盖。卸载云端用 raindrop cloud uninstall，它移除托管 MCP 和 cloud skill、清掉云端安装注册表，本地 Workshop 不受影响；加 --wipe 才会把 RAINDROP_WRITE_KEY 从 ./.env 里删掉。

还有一个交互细节：交互式跑 raindrop setup 时，最后会问你是否顺带配置 Raindrop Cloud，拒绝就保持纯本地。非交互场景（CI、管道脚本）不会弹提示，这种情况必须显式用 cloud setup 或 --cloud。

什么时候它不合适

最明显的一种错配是：你要的是生产环境的持续可观测性，却打算用本地 Workshop 顶上。它跑在你机器上，数据库是本地 SQLite，raindrop workshop reset 就能删掉，这不是一个面向线上流量的形态。这类需求对应的是 Raindrop Cloud 那条路径。

第二种是语言和 SDK 不在清单里。README 列了四种语言和十多个 SDK，但如果你用的是自研框架或者清单之外的编排库，就得先自己确认 SDK 埋点能不能接上，因为 trace 来自 SDK 侧而不是网络层抓包。

第三种是团队协作场景。本地 SQLite 意味着 trace 默认只在这台机器上，README 没有描述多人共享一份 trace 或把 trace 附到 PR 上的机制。如果你的调试流程依赖同事复现同一个失败，Workshop 本身不解决这个问题。

第四种是把它当成评测结果的权威来源。前面已经说过，断言由 Agent 生成，README 没有提供断言审核或回归基线管理的说明。把它当作 CI 里的评测门禁之前，需要先确认断言本身是不是可信。

至于许可证，仓库是 MIT，README 结尾也只写了 MIT 一行。MIT 对商用和修改都比较宽松，但 README 没有提到云端服务的条款、数据处理位置或写入 key 的保管要求，这些属于服务协议层面的事，不在本仓库文档范围内，需要单独确认。

维护成本与版本节奏

从给出的发布信息看，v0.1.19 在 2026-08-14，v0.1.20 和 v0.1.21 都在 2026-08-22，最后两次发布相隔约半小时。版本号仍停在 0.1.x，说明 API 和 CLI 还处在会变的阶段，README 里的命令和配置项在升级时值得重新对一遍。

升级路径是明确的：raindrop update 更新二进制。因为安装方式是一条 curl 脚本而不是包管理器，所以你不会从 npm 或 pip 的锁文件里得到版本约束，二进制版本需要自己留意。

本地状态集中在两处：~/.raindrop 下的凭证和数据库，以及项目里的 .env。前者用 raindrop logout 和 raindrop workshop reset 清理，后者在云端安装时由 raindrop cloud setup 写入 RAINDROP_WRITE_KEY，用 raindrop cloud uninstall --wipe 移除。搞清楚这三个清理入口，迁移机器或换项目时就不会留下残留。

需要提醒的是，README 没有给出本地库的 schema 稳定性承诺，也没有提到数据库迁移策略。如果 RAINDROP_WORKSHOP_DB_PATH 指向的库在升级后不兼容，README 里现成的处理方式就是 raindrop workshop reset，代价是丢掉历史 trace。

编辑结论

适合已经在用 Claude Code、Codex、Cursor 等编码 Agent，并且手里有一个跑在本机、需要反复调试的 Agent 项目的人：装上 raindrop 二进制，跑 /instrument-agent，trace 就会进 5899 端口的 UI。不适合只想看生产流量、不想在本地跑守护进程的团队，那类需求对应的是 raindrop cloud setup 这条路径，它不启动本地 daemon。上手前先确认三件事：你的语言或 SDK 是否在 README 列出的兼容清单里；RAINDROP_WORKSHOP_DB_PATH 默认落在 ~/.raindrop/raindrop_workshop.db，需要换盘就提前设好；以及你是否接受把 trace 交给编码 Agent 读写，因为它写的 eval 会直接改你的代码库。

官方来源

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