JetBrains 开源代理 IDE ThinkRail

ThinkRail 想解决的，是 AI 写完代码以后，开发者仍要在聊天窗口、编辑器、分支和 PR 之间来回搬运的问题。这个 JetBrains 孵化项目围绕 pi coding agent 搭了一套 IDE，把隔离工作区、项目规格、代码审查和 GitHub 流程放进同一个界面。

它最值得关注的主张是：让项目意图跨会话保留下来，让每次修改都有明确边界。不过，所谓「越用越好」目前主要依靠文档和技能积累，原文没有提供效率对照数据，完整扩展支持也仍在计划中。

并行写代码，先把工作区隔离开

ThinkRail 用 git worktree 切出工作区，每个工作区都有自己的分支和目录。多个 agent 可以并行修改，开发者再决定合并哪个分支、删除哪些结果。它也允许挂接已有 worktree，或者明确选择直接在项目目录里工作。

这里的价值很具体：不同任务不必挤在同一份工作目录里，但隔离目录并不能自动消除业务冲突。两个 agent 分别修改同一套接口约定，最终仍需要审查和协调。

工作区里的编辑器、文件树、变更列表、终端和文档，都跟随当前工作区切换。编辑器基于 Monaco，支持分屏；文件和 diff 上的定位评论可以作为结构化上下文发给聊天，让 agent 知道意见落在哪一处。

每个工作区还能同时运行多个 pi 会话，各自选择模型，展示 token 和费用。执行中可以追加指令，也能排队后续任务、委派 subagents。共享计划由 agent 更新，开发者也能编辑，完成的步骤可以分别提交和审查。

GitHub 流程也被接了进来：顶栏显示分支与 origin、PR 的关系，支持 publish、push、创建 PR，并查看 CI 和审查结果。失败检查或分叉的分支可以交给 agent 处理。PR 合并、关闭，或者工作区安静一周后，工作区会自动归入项目收纳区，再次使用时恢复。

这些能力缩短的是任务切换和交接路径，原文没有证明它们能提高代码正确率。

「越用越懂项目」，靠什么留下记忆

ThinkRail 所说的项目学习，目前主要落在持续维护的规格和可复用技能上。

它把相互连接的 SPEC.md 放在代码旁边，通过专门的 spec_* 工具读取、搜索和维护。规格记录模块意图、边界与约定，避免这些信息只存在于某一次聊天里。界面中的只读 Specs 工具则把关系图呈现为树，方便开发者检查。

ThinkRail 自己也采用 spec-first 开发：每个模块旁放置 SPEC.md，涉及边界、契约或决策的改动，需要在同一次变更中更新规格。goal-and-requirements.md 和 architecture.md 是正式的产品与设计依据。

这个做法成立的前提，是规格足够准确。过期文档一旦被当成事实来源，也可能让 agent 更坚定地沿着错误方向修改。原文描述了维护机制，没有提供规格准确率或长期维护成本的数据。

另一部分积累来自 Agent Skills。已有的可移植技能可以原地读取，内置工作流覆盖项目初始化、设计讨论和提交 PR，后者通过用户自己的 gh 推送分支、创建或更新 PR。

现有 agent 工具还包括网页研究、内联图表、方案比较和文件预览。提出 UI 修改时，可以展示支持评论的前后 mockup。mockup 能帮助讨论意图，但不能替代浏览器里的交互验收。完整扩展支持，以及根据使用方式创建新工具，是后续方向，不能算作已经交付的效果。

前端可以读懂它的架构，试用前也要看清运行边界

ThinkRail 把自己定位为薄宿主：pi 负责模型、技能、上下文压缩、费用和会话状态；应用负责工作区、编辑器与通信，不在背后另行组装提示词。

它分成三层：

• packages/server 与 packages/shared 构成引擎宿主，用 Bun.serve 提供 HTTP 和 WebSocket 服务，每个聊天对应一个进程内 pi 会话。
• packages/contracts 定义带类型、带版本的宿主与 UI 通信协议。
• apps/web 使用 React 19、Zustand、Tailwind v4，只依赖通信契约，可以独立交付。

对前端和全栈开发者，这个分工很有参考价值：界面围绕稳定协议组织，agent 的会话能力留给引擎。桌面端和浏览器端复用同一宿主，状态统一保存在 ~/.thinkrail。

下面是原文给出的源码启动步骤，适合查看宿主和网页客户端如何协作：

git clone https://github.com/JetBrains/thinkrail.git
cd thinkrail
bun install
bun run dev                          # host + web client together; Ctrl+C stops both

要留意最后一行同时启动宿主和客户端。环境要求是 Bun 1.4.4、Node.js ≥ 22.19，以及已认证的 pi provider；需要 agent 工作时，只有网页跑起来还不够。

其他入口包括 bun run --filter @thinkrail/cli dev、bun run build:binary、bun run desktop:dev 和 bun run desktop:build。项目采用 Apache License 2.0。

直接试用可运行 thinkrail ~/code/my-repo，需要 PATH 中有 git，并通过 JetBrains AI 或 pi 支持的 provider 认证。ThinkRail 没有独立账号体系。thinkrail --help 查看参数，thinkrail --version 查看构建。

下面保留原文的渠道安装示例，方便区分稳定版、夜间版和固定版本：

curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash -s -- --channel nightly
curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash -s -- --channel stable --version 0.1.2
curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash -s -- --channel nightly --version 0.2.0-nightly.10

关键看 --channel 与 --version：固定版本必须属于所选渠道。Windows 对应配置使用 THINKRAIL_CHANNEL、THINKRAIL_VERSION、THINKRAIL_PREFIX、THINKRAIL_NO_MODIFY_PATH。

桌面版 macOS 仅支持 Apple Silicon，没有 Intel 构建；Windows 支持 x64；Linux 支持 x64 / ARM64，但要求 glibc 2.38+、GTK 3、WebKitGTK 4.1、Ayatana AppIndicator 3 和 librsvg 2，原文以 Ubuntu 24.04 或更新版本说明依赖。

CLI 可用 thinkrail update 更新，界面发起更新后仍需手动重启宿主。thinkrail uninstall 默认保留数据，--remove-data 才删除，-y 跳过询问。手动安装要核对 SHA256SUMS；自动更新要求可执行文件位于 <prefix>/bin/thinkrail[.exe]。

我的判断

我认可它把工作区、审查和项目知识放在一起。相比单独使用 agent CLI，这套界面减少了上下文搬运；相比只给现有编辑器加聊天面板，它把分支和 PR 纳入了任务生命周期。代价是团队要接受新的工作台，并持续维护规格。

但「越用越好」仍是一个需要验证的产品判断。原文没有任务耗时、缺陷率或与其他方案的对照，不能据此判断它优于现有 IDE 加 agent 的组合。

还要把产品边界读完整。MCP 调用是否询问，取决于服务器是否声明只读，以及项目中的信任配置；仓库自带服务器默认关闭，批准后才启用。这个机制提供了控制入口，仍需要用户判断服务器和工具是否可信。

--no-analytics 并不等于关闭全部数据发送。 原文明确说，基础使用事件和错误报告始终发送，关联随机安装 ID；thinkrail --no-analytics 或 THINKRAIL_NO_ANALYTICS=1 关闭的是当次额外分享。按项目说明，报告不包含提示词、代码、凭据和项目路径等内容。额外分享开启时，特定条件下还会关联网站访问，关联在 30 天后过期。

发布成熟度也有差异：Windows 相关可执行文件有签名，macOS CLI 已签名但尚未公证，旧 DMG 或本地包可能未签名，Linux 产物未签名。这些是试用前需要核对的具体条件。

能拿来做什么

• 给已有前端或 Node 项目挑一个边界清楚的小任务，用独立 worktree 完成修改、审查和 PR，观察整条流程是否减少了人工切换。
• 给经常被 AI 改错的模块补一份 SPEC.md，写清职责、接口约定和不能破坏的行为，并把规格更新纳入代码审查。
• 做 UI 修改时，先通过前后 mockup 对齐意图，再结合 diff 定位评论反馈，最后在真实浏览器里验收交互。
• 如果你正在开发 agent 工具，可以参考宿主、版本化协议、React 客户端的分层，优先明确会话状态与界面状态分别由谁维护。