JetBrains ThinkRail：一款围绕 pi 编码代理构建的智能体 IDE

JetBrains 发布了 ThinkRail，这是一款开源的“智能体 IDE”，它将 pi 编码代理封装在丰富的工作台中，并将每个任务隔离在独立的 git worktree 中。它的重要性在于，这是一款 JetBrains 品牌的 IDE，却不使用 JetBrains 自家的编辑器引擎：UI 是 Monaco，运行时是 Bun，代理是第三方 npm 包，而非 JetBrains 构建的模型栈。

该项目位于 github.com/JetBrains/thinkrail，采用 Apache 2.0 许可证。仓库带有“JetBrains 孵化器项目”徽章，README 将 ThinkRail 描述为“一款每次使用都会变得更好的智能体 IDE——今天通过活规范学习你的项目，明天构建自身能力。”该项目有自己的网站 thinkrail.ai 和博客 thinkrail.ai/blog。

ThinkRail 到底是什么

ThinkRail 是一个轻量级宿主，它在进程中运行 pi 编码代理，并将其桥接到 Web UI。README 明确说明了职责分工：“pi 拥有模型、技能、压缩、成本和会话状态；应用拥有工作区、编辑器和连接——它绝不会在背后组装提示词。”

代理是 npm 包 @earendil-works/pi-coding-agent。ThinkRail 增加了工作区模型、编辑器、聊天界面以及它们之间的协议。既定路线图是“完整的扩展支持，让 ThinkRail 能够根据你的实际工作方式创建所需的工具。”

隔离工作区是核心抽象

ThinkRail 的核心设计决策是：每个代理任务都在独立的 git worktree 中运行，而不是在你的工作检出中运行。你可以将任何 git 仓库作为项目打开，并从中创建 git worktree 工作区，每个工作区都有自己的分支和工作目录，这样代理可以并行工作而不会影响你的检出。你也可以附加现有的 worktree，或显式在项目文件夹本身中工作。

已完成和休眠的工作区“会自动归置到每个项目的架子上——当它们的拉取请求合并或关闭时，或经过一周静默后——而当你再次在其中工作时，它们会立即恢复。”顶栏显示活动分支相对于 origin 及其拉取请求的状态，发布、推送或打开 PR 的操作一键即达。PR 描述可以从计划、提交、你的 PR 模板或代理撰写的草稿中起草。一旦 GitHub PR 打开，ThinkRail 会显示 CI 检查和审查决定，并允许你将其标记为就绪、将失败的检查或分叉的分支交给代理、使用仓库上次使用的方法合并、重新打开或删除远程分支。

编辑器是 Monaco，而非 JetBrains 引擎

ThinkRail 的工作台是由 Monaco 编辑器标签页、带有实时 git 变更标记的文件树和变更视图、终端和文档组成的可拆分布局，全部限定于活动工作区。你可以在文件和差异上留下锚定的审查评论，并将其作为结构化上下文发送到聊天中，或者在你安装的 IDE 中打开 worktree。

这一细节在 Hacker News 上引发了最多的批评。评论者 @theptip 写道：

嗯，这其中的大部分在 2025 年似乎都算前沿了。而我为什么要用 Monaco？如果我在 JetBrains 生态系统中，难道不是因为比起 VSCode，我更喜欢他们的 IDE 吗？版本化和链接的规范功能听起来还有点意思。

评论者 @tiku 更直白地说：“Jetbrains 用 vs code 真的很令人遗憾。”另一位评论者 @TehCorwiz 也注意到了同样的问题，并表示他们更喜欢 JetBrains 自己的引擎：“所以这看起来是基于 VSCode 而不是他们典型的引擎。我对此有复杂的感受。我其实很喜欢他们的引擎。”

聊天、计划和规范

ThinkRail 支持每个工作区多个并发的 pi 会话，每个会话都有自己的模型以及实时的 token 和成本读数。你可以引导正在进行的回合或排队后续任务，委派给子代理，并处理一个共享计划，代理会更新该计划，你也可以编辑；每个完成的步骤都可以单独提交和审查。

该项目对会话之间上下文丢失的解决方案是“活规范”：一个与代码并存的、相互连接的 SPEC.md 文件图。代理通过专用的 spec_* 工具读取、搜索和维护该图，而只读的规范工具将其在工作台中呈现为树状结构。ThinkRail 本身就是规范优先开发的——每个模块旁边都有一个 SPEC.md，而任何改变边界、契约或决策的变更都会在同一变更中更新规范。权威的产品和设计规范是 goal-and-requirements.md 和 architecture.md。

一位评论者 @photios 询问在哪里可以了解更多关于 SPEC.md 格式和工作流程的信息，然后在 thinkrail.ai/blog/thinkrail-sdd/ 找到了答案。

技能、MCP 服务器和代理工具

你已经为其他编码代理保留的可移植代理技能会原位置读取。内置工作流指导项目设置、设计头脑风暴和发布拉取请求——通过你自己的 gh 推送工作区分支并打开或更新其 GitHub PR。

在 shell 之外，代理可以获得网络研究以及直接在聊天中内联渲染图表、选项比较和文件预览。当代理提出 UI 变更时，它会显示一个前后对比的 mockup，你可以像评论差异一样评论它。设置 → 扩展列出了代理收到的 ThinkRail 扩展，并允许你逐个关闭它们。

MCP 服务器来自你的 pi mcp.json，或者可以从设置中添加，包括一些预设。ThinkRail 在服务器调用非只读操作之前会在聊天中询问（或者始终允许你在项目中信任的工具），保持仓库定义的服务器处于关闭状态，直到你批准它们，从设置中登录 OAuth 服务器，并在每个聊天的后台命令和子代理旁边显示其服务器。

提供商和凭据

ThinkRail 没有自己的账户。你可以使用 JetBrains AI 登录，或通过 pi 自己的认证连接任何提供商。评论者 @lousken 质疑了该支持的范围：“本地模型支持和任何 openai 兼容的 API 支持在哪里？Pi 代理兼容更多东西。”

安装：桌面应用和 CLI

ThinkRail 以两种附加形式发布——原生桌面安装程序和独立的 thinkrail CLI——两者都在发布页面上附带 SHA256SUMS 校验和。

桌面构建可用于 macOS Apple Silicon（DMG；没有 Intel 桌面构建）、Windows x64（解压完整的 setup ZIP 并就地运行其 setup 可执行文件）和 Linux x64/ARM64（解压 setup tarball 并运行 installer）。Linux 桌面构建需要 glibc 2.38+，以及 GTK 3、WebKitGTK 4.1、Ayatana AppIndicator 3 和 librsvg 2，这意味着 Ubuntu 24.04 或更新版本，需要包 libgtk-3-0 libwebkit2gtk-4.1-0 libayatana-appindicator3-1 librsvg2-2。

CLI 安装程序会下载正确的二进制文件，验证其 SHA-256 校验和，并将 thinkrail 放入你的 PATH。在 macOS、Linux 和 Windows 的 Git Bash 下：

curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash

在 Windows 的 cmd 和 PowerShell 下：

powershell -c "irm https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.ps1 | iex"

然后运行 thinkrail，可以附带一个 git 仓库作为项目打开：thinkrail ~/code/my-repo。CLI 需要 git 在 PATH 中，并且需要一个模型提供商——要么从应用进行 JetBrains AI 登录，要么使用你自己的提供商凭据。thinkrail --help 列出标志，thinkrail --version 打印构建版本。

安装程序接受 --channel stable|nightly 和 --version，并且固定的版本必须属于所选频道。在 Windows 上，这些选项是环境变量：THINKRAIL_CHANNEL、THINKRAIL_VERSION、THINKRAIL_PREFIX 和 THINKRAIL_NO_MODIFY_PATH。thinkrail update 为已安装的频道重新运行安装程序，并替换 <prefix>/bin/thinkrail[.exe]。thinkrail uninstall 删除可执行文件、安装程序添加的 PATH 条目和安装元数据，并询问是否删除你的 ~/.thinkrail 应用状态——默认保留，使用 --remove-data 删除，使用 -y 跳过问题。

打包的稳定版和夜间版桌面构建会在后台检查更新，并在设置 → 更新中提供，遵循下载 → 准备更新 → 安装并重启的流程。在你选择安装并重启之前，不会应用任何内容。更新程序仅在包带有有效的 HTTPS 源身份时出现；早于该身份的安装需要先手动安装一次。

平台和签名说明

JetBrains 会签名 Windows CLI、桌面设置可执行文件以及桌面应用安装的每个可执行文件和 DLL。macOS CLI 已签名但尚未公证。签名并公证的桌面 DMG 需要协调的 JetBrains 服务管道，因此较旧发布的 DMG 和本地构建的包可能仍未签名并被 Gatekeeper 阻止。Linux 工件未签名。没有预构建的 macOS Intel CLI——必须从源代码构建。

架构：三个环层

ThinkRail 组织为三层：

• 引擎宿主 — packages/server（加上 packages/shared）：一个 Bun.serve HTTP+WS 宿主，每个聊天有一个进程内 pi 会话，由 apps/cli 或 apps/desktop 启动。
• 连接 — packages/contracts：宿主和 UI 之间的类型化、版本化协议。
• UI 客户端 — apps/web：React 19 + Zustand + Tailwind v4，独立发布；它通过连接与宿主通信，仅依赖契约。

桌面应用和浏览器 CLI 都嵌入相同的引擎宿主，应用状态位于 ~/.thinkrail 下。从源代码构建需要 Bun 1.4.4（固定的包管理器和运行时）、Node.js ≥ 22.19（进程内 pi 引擎需要）以及已认证的 pi 提供商以进行代理工作。README 中的开发命令是 bun install、bun run dev（同时运行宿主和 Web 客户端）、bun run build:binary（生成独立的 CLI 工件），以及 bun run desktop:dev / bun run desktop:build（用于 Electrobun 应用）。

Bun 依赖引起了 @photios 的反应：“还有……为什么用 bun？！我刚刚从所有系统中清除它，哈哈！有普通的 pnpm 支持会很好。”

本地化

设置 → 语言跟随你的系统语言或你选择的语言。内置了英文和简体中文。你可以通过将翻译后的 en.json 放入 ~/.thinkrail/locales 来添加 ThinkRail 尚未提供的语言，保存后即可应用。代理回复和工具输出保持代理撰写时的原样。

分析和隐私

ThinkRail 收集基本使用事件——启动、聊天创建、消息发送、提供商连接——与随机安装 ID 关联。使用分析从不包括提示词、代码、文件、凭据或账户身份。错误报告始终发送，与相同的安装 ID 关联，并包含错误类型和代码以及错误发生在 ThinkRail 自身代码中的位置；它们从不包括错误消息、文件路径、名称、URL 或来自你的项目或扩展的任何内容。

额外的产品使用数据和你如何找到 ThinkRail 的信息仅在“共享额外使用数据”开启时共享；该开关在首次启动时提供，位于设置 → 隐私中。运行 thinkrail --no-analytics（或设置 THINKRAIL_NO_ANALYTICS=1）会在该次运行中关闭额外共享。在额外共享开启时，打包构建可能会在浏览器中打开一次 ThinkRail 博客，以将你的安装与带你访问的网站访问关联起来——仅在你接受网站上的营销 cookie 或不需要同意时——该链接在 30 天后过期。

Hacker News 评论者的反对意见

讨论大多持怀疑态度，并且有几种不同的批评反复出现。

README 本身受到质疑。 评论者 @exizt88 写道：“我拒绝认真对待一个带有 AI 生成的 readme 的仓库。如果你懒得写 readme，你还懒于做其他什么？（根据 Pangram 的说法，100% 是 AI）。”

与 JetBrains 其他 AI IDE 努力的重叠。 @Deukhoofd 问道：“JetBrains 不是最近发布了 JetBrains Air 吗？这看起来基本上是相同的基本前提，只是实现不同。他们的策略是什么，他们只是在推出竞争产品吗？” @rcr-anti，一位长期的 JetBrains 全产品包订阅者，表示他们想要“要么通过插件实现他们所有 IDE 的融合，要么像 Fleet 曾接近的那种更轻量的通用编辑器”，并补充说他们“以为他们会通过 Air 走那条路，直到他们再次把它取消。Air 现在是一个插件，但那又回到了特定 IDE 的老路。”

worktree 加代理的模式并不新颖。 @sigotirandolas 认为：“我看不出这些新 IDE 的意义。它们大多只是 worktree+沙箱+标签页+提示词，也就是 git+docker+tmux+思考，但如果你真正学会使用这些工具，而不是把你的代理束缚在 IDE 的任何看法上，你会更快乐、更高效。（这也是为什么有这么多这样的 IDE：这并不难，每个人都觉得自己发现时像个天才，而且这是在 AI 时代建立简历的好方法。）”

隔离不足。 @collimarco 写道：“在容器外运行代理对我来说似乎很疯狂……它至少应该为每个代理/任务启动一个单独的微型 VM 或容器。”

企业计费摩擦。 @hkchad 说：“所有 AI IDE 的问题在于你无法将它们与大多数企业/团队账户一起使用，你必须使用 API，这可能比企业计划贵多达 10 倍。我真的很喜欢 JetBrains，用了很长时间，但现在发现自己 99% 的日常工作都用 iTerm 和 Sublime。”

worktree 与其他版本控制工作流程。 @VMG 观察到：“感觉在我刚熟悉 jj 的第二天，每个人都开始痴迷 git worktree。”

在位者忠诚度，但有保留。 @dr_faustus，使用了 JetBrains IDE 十多年，说他们“现在很少打开它们，因为同时在多个 worktree 上工作极其令人沮丧和浪费”，并批评公司的 AI 战略“乱成一团”，“token 不透明且定价过高”。@throwaw12 说“感觉 JetBrains 正在衰落，他们在拼命求生”，而 @johnhamlin 简单写道，“仍然支持这些家伙，” @jwpapi 说他们“愿意尝试一下。”

提到了竞争工具。 @aliasxneo 说他们“必须被_强烈_说服才会离开 oh-my-pi 和 Paseo。” @dangoodmanUT 将这次发布视为姗姗来迟：“很高兴看到 JetBrains 终于醒悟，意识到他们不能再卖 2024 年的 Cursor 竞争对手了。JetBrains 编写新 IDE 似乎很大胆……不确定它是否感觉正确。”

贡献和许可证

贡献受仓库的 CONTRIBUTING.md 管理，其中涵盖检查、端到端套件、桌面打包和仓库布局，以及行为准则。ThinkRail 根据 Apache 许可证 2.0 授权。

总结

JetBrains ThinkRail 是一个 Apache-2.0 孵化器智能体 IDE，它将 pi 编码代理封装在基于 Monaco 的工作台中，具有隔离的 git-worktree 工作区、活的 SPEC.md 项目知识和 MCP 支持，以桌面应用和独立 CLI 的形式发布。

标题

JetBrains ThinkRail：一款围绕 pi 编码代理构建的智能体 IDE