thinkrail
富贵不能淫，贫贱不能移，威武不能屈，此之谓大丈夫。——孟子
又一个「agentic IDE」：它说它会越长越像你，我先把这句话记下来
先吐个槽：IDE 这个词已经不够用了
现在打开任何一个新项目的主页，你都能看到同一套词：agentic、self-improving、learns how you work。
JetBrains 这份也不例外。仓库描述里写的是：在一个轻量、真正的 IDE 里用 pi 写 vibe code，这个 IDE 会围绕你的工作方式自我定制。
副标题四个词，读起来还挺顺口：The Vibe You Need。
行吧。顺口这件事，确实比准确容易。
项目地址：https://github.com/JetBrains/thinkrail
但吐槽归吐槽，往下读完会发现，这份文档至少有一半内容是可以被验证的——它给了截图，给了安装包的名字，给了依赖版本号，给了更新流程。一家公司愿意把「我的安装器需要 glibc 2.38」写进正文，比再写十句 slogan 都更能说明它是真东西。
所以这篇文章分两部分：能验证的部分，和需要打个问号的部分。
它到底做了什么
一句话：给 pi 这个编码 agent 套了一个像样的界面。
就这一句，别被「agentic IDE」四个字唬住。文档自己写得很老实：他们围绕 pi 建了富界面，把工作隔离进独立的工作区，通过 living specs 和可复用的 skills 给 agent 一份持久的项目知识。
三件事，依次翻译成人话。
第一件，做壳。 pi 是一个编码 agent，ThinkRail 给了它一个可视化的工作台——对话、工具步骤、改动、diff，都能放在同一屏里看。
第二件，做隔离。 每个工作区是一个独立的 git worktree。这意味着 agent 的改动长在自己的树枝上，不会直接糊到你正在编辑的工作区里。
第三件，做记忆。 这一条是整份文档里最有内容的：不是给 agent 一个更大的上下文窗口，而是给项目一份「活着的规格」。
「明天」那半句，先记在账上
文档里有半句话很诚实，也很危险：
下一步，我们要加完整的扩展支持，这样 ThinkRail 就能根据你实际的工作方式，造出它自己需要的工具。
「下一步」是软件行业最便宜的两个字。人人都能说，说了也不算数，说完还可以再等一年。
但这句话至少做对了一件事：它写清了要做什么，也写清了为什么——不是为了多加一个插件市场，而是为了让 IDE 自己能长出工具。
这个野心比「支持第三方插件」大一圈。插件市场是别人给你造工具，自造工具是自己给自己造。前者解决生态，后者解决适配。
至于什么时候能看到，文档没说。合理，说了也白说。
工作台长什么样：把「agent 干了什么」摆平
文档里那张主截图，配了一句说明：一个 pi 会话，以及它做出来的改动，被限定在一个隔离的 git worktree 工作区里。
图注写得更细，值得念一遍，因为它几乎就是这个产品的说明书：左侧工具轨道旁边是 Projects 面板，列出各个 worktree 工作区，以及它们的 Settled 货架；中间是一个已经跑完的 pi 对话和它的工具步骤；旁边是这次改动产生的 diff；右侧是 Specs 树，压在 Changes 列表上方，各自的工具挂在边缘轨道上。
这套布局解决的是一个很具体的痛点：用命令行形态的 agent 时，你永远在几个窗口之间来回切——一处看它想干什么，一处看它改了什么，还得去 git 里核对它到底动了几个文件。
把它们放进一个窗口，本身就是产品价值。听起来不高级，但做过这件事的人知道，这比再多两个模型都管用。
那个叫 Settled 的货架也很有意思。名字本身就是个态度：跑完的会话不该消失，它该被摆到架子上，等你回头看。
Living specs：不是记住上下文，是记住项目
这一节是我最想认真夸的地方，所以先把吐槽收一收。
大多数 coding agent 的「记忆」是什么？是一段被塞进上下文的摘要，是一份 AGENTS.md，是每次开新会话时重新读一遍的目录结构。它们记的是这一轮。
ThinkRail 的说法不一样：它给 agent 的是「活着的规格」，一份会随项目长大的规格图谱。截图里那个 Specs 工具，把项目的规格树列出来，选中的规格在编辑器里渲染出来。
规格这个东西，好处是它不依赖任何一次对话。它属于项目，不属于会话。你明天换一台机器、换一个模型、换一个 agent，规格还在那里。
而它坏的地方也很清楚：写规格是人的活。agent 可以消费规格，但规格写得烂，agent 就只能烂得很有条理。
所以这个功能真正的门槛不在技术，在习惯。文档没提这件事，但任何一个用过 spec-driven 流程的人都知道：第一周最兴奋，第三周开始拖欠，第六周开始假装没这回事。
安装：两种形态，一份校验和
文档说，ThinkRail 以两种可叠加的形态发布：一个原生桌面安装器，和一个自包含的 thinkrail CLI。两者都在发布页上附带 SHA256SUMS。
这一条值得单独拿出来夸。「发布时附校验和」是基本功，但真正做到的项目并不多。它意味着你下载完之后可以自己验一遍，而不是只能选择相信。
桌面端三个平台，细节给得相当不客气：
macOS 14 以上，Apple Silicon 和 Intel 各一个 DMG，文件名里带 darwin-arm64 和 darwin-x64。选错了也不会有提示，装不上就是装不上。
Windows x64，解压完整的 setup ZIP，然后在原地运行其中的安装程序，必须挨着它的载荷。这句话写得很克制，但翻译过来就是：别把 exe 单独拖到桌面上双击，它找不到自己需要的东西。
Linux x64 与 ARM64，解压 setup 压缩包，运行 installer。而桌面构建需要 glibc 2.38 以上，外加四个库：
1 | sudo apt install libgtk-3-0 libwebkit2gtk-4.1-0 libayatana-appindicator3-1 librsvg2-2 |
翻译成人话：Ubuntu 24.04 或更新。
这四个库的名单，基本上是一份「靠系统渲染器过日子」的桌面应用的身份证——GTK 3 画界面，WebKitGTK 4.1 跑网页层，AppIndicator 挂托盘图标，librsvg 渲染矢量图。少一个，程序多半会在启动那一秒安静地死掉，连报错都懒得给你。
这就是「轻量」的账单。轻量是相对 Electron 说的，不是相对零依赖说的。
更新流程：不点那个按钮，它就不动
这一段写得好，好到我怀疑是踩过坑之后才写出来的。
打包好的稳定版和夜间版会在后台检查更新，然后在设置里的 Updates 页面提供。流程是三步：下载、准备更新、安装并重启。
关键的一句是：在你选择「安装并重启」之前，什么都不会发生。
然后它会展示安装进度和日志，关闭，用新版本重新打开。重启之后再告诉你更新到底装上了没有；如果没装上，它会解释原因，并提供重试。
这套流程的价值在于它承认了一件事实：更新是一个会失败的操作，而且失败的时候用户最需要的不是「更新成功」的绿色勾，是为什么没成功。
还有一个更现实的细节：更新器只在包携带有效的 HTTPS feed identity 时才出现。早于这个身份的安装，需要先手动装一次。
这句话读起来像一句脚注，其实是整个更新体系的裂缝说明书。它承认了：我们改过发布方式，老用户得手动跳一次。很多项目会把这段藏进 changelog 的一行小字里，这里写在正文。
从源码跑：版本号钉得很死
如果你不想装包，想自己跑，前置条件是三个：
Bun 1.4.4，被钉死的包管理器和运行时。Node.js 22.19 以上，因为在同一进程里跑的 pi 引擎需要它。一个已认证的 pi provider，不然 agent 部分没法工作。
版本钉死到小数点后两位，是好事。它意味着你装出来的东西和我装出来的东西是同一个东西，而不是「大概差不多」。
流程也不复杂，克隆仓库、进目录，然后：
1 | bun install |
这一条命令会同时起宿主和 Web 客户端，Ctrl+C 一起停。
剩下的入口分四类：
1 | bun run --filter @thinkrail/cli dev # 浏览器启动器 |
注意最后两个命令里的那个名字：Electrobun。前面还在说「轻量」，这里就露出了真身——桌面端由 Electrobun 打包，而 Linux 那份依赖清单里的 WebKitGTK，基本等于承认它吃的是系统自带的渲染器，而不是随包发一个 Chromium。
这解释了 Linux 那四个依赖，也解释了为什么 macOS 要 14 以上。
至于检查、端到端测试、桌面打包和仓库布局，文档把话头指向了贡献指南。没有在文档里堆一百行命令——这一点也值得夸，虽然夸得有点勉强。
两种形态，一份内核
文档开头有句话很容易被跳过：桌面安装器和 CLI 是「可叠加」的两种形态。
这个词用得很谨慎。它没说「二选一」，也没说「CLI 是精简版」。两个东西都能装，装在同一个项目上，各干各的活。
这个设计的实际含义是：白天在桌面里看 diff、翻规格树、点掉一个跑完的会话；半夜写脚本的时候，用 CLI 起一个浏览器启动器，或者直接打一个独立二进制出来。
这不算什么惊天动地的架构，但它避开了很多同类产品的通病——先做一个漂亮的壳，然后发现团队里有人不用 GUI，于是慌慌张张补一个功能残缺的命令行。
两边都附带校验和，两边都跟着同一套发布节奏。听着像句废话，但很多项目连这句废话都做不到。
谁该动心，谁该等等
按这份文档给的信息，可以很干脆地分类。
该动心的：已经在用 pi 的人。你本来就在跟它打交道，现在多了一个能同时看对话、工具步骤、diff 和规格的窗口，还多了一层 worktree 隔离。这是纯增益，没有迁移成本的问题。
可以试试的：手上项目多、经常要 agent 同时动好几处的人。工作区隔离这件事，在单项目小改的时候几乎感觉不到好处，一旦并行起来，它就是救命的那根绳。
该等等的：冲着「它会自己造工具」来的人。那部分还写在「下一步」里，现在装上去也变不出来。
该绕道的：Linux 上还在 Ubuntu 22.04 的人。不是歧视，是那四个库和 glibc 2.38 的门槛，装不上就是装不上，硬试只会得到一个静默退出的进程和一段毫无帮助的日志。
这种分类听起来不够热情，但比「适合所有开发者」这种话有用得多。
它没说的三件事
一份文档写得再细，也能从它的沉默里读出点东西。这里有三处空白。
第一，钱。 全文没有一个字提到收费、订阅或额度。对一个要跑 agent 的产品来说，这个问题迟早要回答——agent 烧的是模型调用，模型调用要花钱。现在的沉默可以理解成「还没定」，也可以理解成「装上去你就知道了」。
第二，Windows ARM64。 包名列表里，macOS 给了两个架构，Linux 给了两个架构，Windows 只给了 x64。这个不对称大概率不是疏忽，是排期。用骁龙本的人，现在只能等。
第三，扩展 API 长什么样。 「下一步加完整扩展支持」这句话只说了一半：加什么、怎么加、插件用什么写、能不能访问文件系统。这些都没写。反正还没做，写了也是白写——但这也意味着，现在没人能提前为它准备生态。
三处空白加在一起，画出的画像很清楚：一个主干已经能跑、周边还在长的东西。
身份：一个孵化器项目
文档顶部挂着一个徽章：JetBrains incubator project。
这个身份解释了很多事。它有公司的资源，所以能同时出桌面安装器和 CLI，能给两个平台各打两个架构的包，能写一套带日志和重试的更新器。
但它也解释了另一些事：为什么扩展支持还在「下一步」，为什么文档里到处是「今天」和「明天」的对比。
孵化器项目的典型状态就是这样：主干很硬，枝叶还没长。
许可倒是很干脆，Apache 2.0。
最后
回到开头那句话：它会围绕你的工作方式自我定制。
现在这句话只兑现了一半。它能围绕你的项目定制——通过那些活着的规格；它还不能围绕你的工作方式定制——因为造工具的那部分还没上线。
所以这份文档最可信的地方，不是那句押韵的 slogan，而是那几个具体的数字：Bun 1.4.4、Node 22.19、glibc 2.38、macOS 14。承诺可以含糊，版本号含糊不了。
一个产品说自己会越长越像你，这没什么。真正的问题是：它现在像不像一个能用的东西？
答案是像的。它把 agent 的对话、改动和 diff 摆进同一个窗口，把每次工作隔离进自己的树枝，把项目的知识从会话里搬到规格里。这三件事都不新鲜，但凑齐的不多。
至于「明天造工具」那半句——先记在账上。反正软件行业最不缺的就是明天。