JetBrains把一款智能体IDE开源了，Apache 2.0协议，已上GitHub。仓库叫Thinkrail，内核包着pi编码智能体。名字不是重点，重点在它装进去的三个设计取向。
本周智能体栈正在公开拼装：英伟达（NVIDIA）出了运行时层OpenShell，JetBrains补上环境层。Thinkrail的机制可以逐条拆。
隔离靠工作树，不靠提示词
Thinkrail里每个工作区都是一个git工作树，各自带独立分支。README里那句话值得原样引用：“Agents work in parallel without touching your checkout.”（智能体并行工作，不碰你的检出区。）
这是整套设计的核心，也是多数智能体工具答得很差的那道题。常见做法是：智能体就地改文件，你在自己正在构建的同一棵树里审diff，第二个智能体一上来就成了合并冲突制造机。工作树把逻辑翻过来：N个智能体、N个分支，你的检出区不动，合并成为显式的协调点。
这和OpenShell的沙箱是同一个隔离思路，只是抬高了一层——问的不再是“智能体能碰什么”，而是“智能体住在哪棵树里”。
SPEC.md当作事实基准
更深的一注押在上下文上：智能体不可靠，是因为它的上下文随对话结束而死。Thinkrail的答案是每个模块旁边放一份SPEC.md，构成一张规格图，由智能体通过专门的spec_*工具自行维护，“so intent survives the session”（让意图跨会话存活）。
换句话说，文档不是工作的副产品，而是IDE当作事实基准来维护的产物。智能体先读规格知道要做什么，做完再更新规格记录学到的东西。JetBrains自己也在吃这套狗粮：仓库按规格先行开发，每个模块旁边都有一份SPEC.md。
悬而未决的问题是：智能体既遵循规格又编辑规格，这张图在智能体驱动的改写之下还能不能保持诚实？一份被智能体同时读取和修改的规格，离一次提示注入改写项目“事实”只差一步。但作为一种架构，它是第一个认真回答“智能体如何记住我的项目”、且不依赖向量数据库的方案。
没有账号
“ThinkRail has no accounts of its own.”（ThinkRail没有自己的账号体系。）自带模型供应商凭证，和OpenShell的供应商模式一致。
IDE在这里只当宿主：一个HTTP+WS引擎（Bun.serve，每个聊天一个进程内智能体会话）、一套带类型和版本号的通信协议（packages/contracts）、一个React 19客户端。技能、工作流、MCP服务器、子智能体、按聊天切换模型并显示token与成本读数。它是一个套在智能体协议外面的IDE形状外壳，而这个外壳对“谁为推理付费”不持立场。
需要说清的边界
宣传语“gets better every time you use it”（越用越好）是营销话术，对应到今天实际交付的是活规格，自建能力还在明天。项目非常新（0.x版本，本周才出现），通信协议有版本号但很年轻，“智能体编辑下的规格漂移”是对它自身前提的真实攻击，README没有给出答案。
桌面安装包已有（macOS Apple Silicon、Windows、Linux），命令行两条命令即可跑起来，但还没有人能拿出一年的使用记录。
想自己跑：安装脚本走curl管道执行，然后thinkrail ~/code/my-repo。开发者需要Bun 1.4.4加Node >= 22.19，再执行bun install与bun run dev。仓库地址github.com/JetBrains/thinkrail，Apache 2.0，围绕pi编码智能体构建。
一句话收束：工作树承载并行智能体，自维护的规格图承载持久意图，自带密钥、没有账号。这一周拼出了运行时（英伟达）和IDE（JetBrains），还明显缺一层没做完——谁来证明这支智能体队伍实际做了什么。
热门跟贴