ThinkRail（JetBrains/thinkrail）：把每个 Agent 任务切进独立 git worktree，用 SPEC.md 图谱让项目意图跨会话存活

一、导读

编码智能体最大的痛点不是「不会写代码」，而是三件事同时失控：多个 Agent 在同一个工作目录里互相覆盖改动、会话一结束项目意图就蒸发、以及 CLI 里那一大坨 diff 根本没法逐行评审。JetBrains InnovationHub 孵化的 ThinkRail 给出的答案很硬核：把每个任务切进独立的 git worktree，把项目意图写成代码旁边一张可被 Agent 读写的 SPEC.md 图谱，再用一个真 IDE 把评审做成一等公民。

核心结论：它的技术含量不在「给 pi 套个界面」，而在把「上下文问题」当成「文件结构问题」来解——不靠提示工程、不靠向量库，而是让规格成为仓库里可 diff、可提交、可回滚的一等产物；同时用 packages/contracts 这个版本化类型协议把前端与引擎宿主彻底解耦，让 UI 能独立发布。但它也极其年轻：0.x 版本、无稳定版基准、Linux 产物未签名，且维护团队在官方 issue 中承认规格图谱从未做过基准对照评估——这是评估它时必须一并读的注脚。

二、项目速览

项目	内容
仓库 / 团队	`JetBrains/thinkrail`，JetBrains InnovationHub（孵化项目）
主语言 / 许可	TypeScript / Apache-2.0
Star / Fork	2,796 / 149（GitHub REST API，2026-10-26 抓取）
当日涨星	1,156（GitHub Trending daily，2026-10-26 抓取）
首次建仓 / 最近推送	2026-07-08 / 2026-10-26
开放 issue	225
最新版本	v0.3.0-nightly.6（2026-10-25）；最新稳定版 v0.2.0（2026-10-18）
贡献者 / 集中度	25 人；Top 1 提交 248 次，第二 166 次，第三 52 次
最近提交	2026-10-26 21:30 `fix(pi-dag): persist thinking level in stored outcomes (#927)`
底层引擎	pi（`earendil-works/pi`，开源 TUI 编码智能体，进程内运行）
构建栈	Bun 1.4.4 + Node ≥22.19；前端 React 19 + Zustand + Tailwind v4；桌面端 Electrobun

口径说明：当日 daily 榜共 14 条，涨星高于本项目的 VoiceStudio（2,292）、hallmark（2,235）、impeccable（1,551）、TradingAgents（1,376）、cindy（1,268）均已在本站「开源项目」栏目近 14 天内发布，按查重规则淘汰；ThinkRail 为当日合规且未发布项中涨星最高者（ainews_search('thinkrail') 返回空）。

三、为什么是它：把「隔离、知识、接口」三件事一起解

第一，它对准的是并行 Agent 的碰撞问题。 pi 本身是刻意极简的 harness，灵活性带来的是门槛：新手要花很久才学会驾驭它，老手也觉得终端在处理「Agent 周边工作」时很笨拙。更致命的是并行：多个 Agent 在同一个工作树里会互相碰撞，也会和用户自己的编辑碰撞。 ThinkRail 的解法是把隔离下沉到 git 原语——每个工作区就是一条 git worktree 加一条独立分支，Agent 并行干活，主分支干净到你主动合并为止。

第二，它把「项目意图」从会话里搬进仓库。 官方对问题的描述非常直白：意图会蒸发——聊天里做出的决定随会话结束，下一次要么重新推导，要么直接矛盾。 主流解法是向量库或更大的上下文窗口，ThinkRail 选了第三条路：代码旁边放一张互连的 SPEC.md 图谱，由 Agent 通过专用 spec_* 工具读取、搜索、维护。

第三，它把「评审」做成了产品主线。 从 CLI 评审 Agent 改动很难：读 diff、在精确行上评论、再把反馈交回 Agent。ThinkRail 把 Monaco 编辑器、diff、终端、锚定行评论塞进同一个工作台，v0.2.0 起每个 Agent 回合都带一个 receipt 与 Review 按钮，支持逐 hunk 保留或回滚。

第四，涨星动因是「大厂开源 + 议题命中」的叠加。 项目 2026-07-08 建仓，8 月由 JetBrains 正式介绍，10 月 18 日发布 v0.2.0、10 月 25 日 nightly.6 冲上 Hacker News 首页（199 分、147 条评论），随后进入 GitHub 日榜。它踩中的是 2026 年最热的两个议题：Agent 并行编排与上下文持久化——而 JetBrains 的品牌背书让「大厂也这么解」变得值得一读。

四、【重点】架构原理

4.1 整体架构：三层解耦 + 进程内 Agent

graph TD
    subgraph CLIENT["客户端层（可独立发布）"]
        WEB["apps/web<br/>React 19 + Zustand + Tailwind v4<br/>Monaco 编辑器 / diff / 终端"]
        DESK["apps/desktop<br/>Electrobun 原生壳"]
    end
    subgraph WIRE["协议层"]
        CTR["packages/contracts<br/>版本化类型协议<br/>WS method/channel 常量 + WsErrorCode 封闭集"]
    end
    subgraph HOST["引擎宿主层"]
        SRV["packages/server<br/>Bun.serve HTTP+WS<br/>每对话一个进程内 pi 会话"]
        SH["packages/shared<br/>shellEnv + Central 适配"]
    end
    subgraph PI["Agent 引擎（外部）"]
        PIA["@earendil-works/pi-coding-agent<br/>模型 / 技能 / 压缩 / 成本 / 会话状态"]
    end
    subgraph EXT["捆绑 pi 扩展"]
        SG["pi-spec-graph<br/>7 个 spec_* 工具 + skill"]
        SUB["pi-subagents / pi-todos"]
        DAG["pi-dag / pi-delegation"]
        BG["pi-background-commands"]
    end
    subgraph FS["文件系统真相"]
        WT["git worktree（每任务一分支）"]
        SPEC["SPEC.md 图谱（代码旁）"]
    end
    WEB <-->|"WS /ws?protocol=N"| CTR
    DESK <--> CTR
    CTR <--> SRV
    SRV --> PIA
    SRV --> SG
    SRV --> SUB
    SRV --> DAG
    SRV --> BG
    SG <--> SPEC
    SRV <--> WT
    PIA <--> WT
    SRV --> STATE["~/.thinkrail 持久化"]

关键设计是「薄宿主」定位：官方原话是「ThinkRail is a thin host that runs pi in-process」——pi 拥有模型、技能、上下文压缩、成本与会话状态，ThinkRail 拥有工作区、编辑器与 wire，并且「绝不会在你背后替你拼提示词」。这条边界决定了它的能力上限被 pi 的接口锁住，也决定了它无法偷偷改变 Agent 的实际行为——对可审计性来说是加分项。

4.2 分层模块拆解

层	目录	职责	关键接口
引擎宿主	`packages/server`	HTTP+WS 服务、静态托管、WS 分发注册表、项目/工作区/git/fs/终端服务、进程内 `AgentSession` 管理	`createServer(options) → RunningServer`；`bootHost(options) → BootedHost`
协议	`packages/contracts`	浏览器↔宿主 wire 的唯一真相：实体类型、WS 方法与频道注册表、协议版本、`WsErrorCode` 封闭集	唯一被 `apps/web` 依赖的包
规格图	`packages/spec-graph`	可移植 pi 包：spec 模型 + 七个 `spec_*` 工具 + skill + `before_agent_start` 规则	`pi-spec-graph/core`（无 pi 依赖的读模型）
前端	`apps/web`	React 19 + Zustand + Tailwind v4	可脱离宿主独立发布
桌面	`apps/desktop`	Electrobun 原生壳、更新器、签名身份	打包运行时由 Electrobun 拥有
CLI	`apps/cli`	自包含二进制，内嵌同一引擎	`thinkrail ~/code/repo`
编排扩展	`pi-subagents`、`pi-dag`、`pi-delegation`、`pi-todos`、`pi-background-commands`	子代理、DAG、委派、待办、后台命令	以 pi 扩展形式注入

4.3 核心机制一：`spec_*` 工具与「派生、只读、按需重校验」的读模型

packages/spec-graph 最值得读的是它的判定规则与读取模型。判定规则极简：一个文件只要 frontmatter 里带 id 和 type，它就是一份 spec。 读模型则有一条明确纪律：

文件系统是唯一真相；工具读取的模型是派生的、内存中的、只读的、按需重新校验的。每次读取都重跑一遍 glob。

这条纪律的代价是每次读都做一次目录遍历，收益是永远不会读到过期缓存——对「Agent 自己也在改这些文件」的场景，这是正确的取舍。写入侧同样克制：spec_create 按规范字段顺序写 frontmatter，而 spec_update 原地编辑——保留文件自身的字段顺序、注释与嵌套字段，只重写 frontmatter 块（沿用该块原有的行尾符），正文一个字节都不动。这条「不碰正文」的约束，正是让规格变更能干净地出现在 diff 里的前提。

它还是可移植的：该包不依赖 monorepo 里任何 @thinkrail/* 包，因此能在原生 pi 下运行（pi install），ThinkRail 只是把它捆进每个会话。依赖边是单向的（thinkrail → spec-graph），这是可移植性的来源。

4.4 核心机制二：把失败做成封闭枚举的 wire 协议

packages/contracts 有一个非常工程化的设计原则：只有在客户端会因某个失败而采取不同行为时，该失败才配拥有自己的错误码；其余一律退化为普通 error 字符串。 于是有了 WsErrorCode 这个封闭集：NOT_GIT（不是仓库）、ALREADY_OPEN（目录已被某工作区占用）、PUSH_AUTH_FAILED、UNKNOWN_COMMIT、RESOURCE_UNAVAILABLE，以及 SUBAGENT_TRANSCRIPT_NOT_FOUND——后者是 subagent.getTranscript 的永久性未命中，作用正是终止转录对话框的轮询；而「已知子代理但首个转录文件尚未落盘」则返回空消息加当前状态，让运行中的会话保持可轮询。

评审路径同样把歧义消掉：change.* 的四种结果被显式区分——STALE_VIEW（expect 哈希不再匹配宿主读到的内容 → 重读 diff 再提供）、SCOPE_IMMUTABLE（该范围的修改侧是一个 commit，工作树里没有任何东西在被描述）、RANGE_INVALID（区间落在其命名侧之外）、RECEIPT_UNKNOWN（撤销了一个宿主已不再持有的 receipt——receipt 环形缓冲只有 20 深，且随进程消亡）、UNSUPPORTED_CHANGE（符号链接或仅权限位变更，字节导向的写路径刻意拒绝）。这套设计的价值在于：客户端可以针对某个具体失败做出反应，而不是去正则匹配错误消息。

4.5 核心机制三：worktree 隔离与 MCP 的「按调用授权」

隔离的单位是工作区，工作区的实体是 git worktree。项目可以是任何本地 git 仓库；工作区各自带分支、文件、终端与聊天；完成的或休眠的工作区会自动落到按项目分组的 shelf——当它的 PR 合并或关闭，或者安静一周之后。默认工作区可以直接用原仓库，但那是显式选择，永远不是默认。

MCP 授权则按「是否只读」三档分流：来自 pi 的 mcp.json；调用未标只读的接口前，它会在聊天里先问（除非项目已信任这些工具）；仓库自己定义的服务器默认关着，等你批准；OAuth 服务器在设置里登录。授权的最小单位是「调用」，不是一个已经装好的服务器——在 2026 年「指令文件投毒」频发的背景下，这个默认值比多数同类更保守。

4.6 性能优化与设计取舍

进程内运行换掉了 IPC 开销。 pi 通过 createAgentSession 在宿主进程内跑，而不是另起子进程或走 RPC。收益是零序列化损耗、会话状态可直接读；代价是Agent 崩溃可能带走宿主——这解释了为什么 bootHost 要装崩溃日志、shutdown() 要做幂等且有界的生产生命周期（结算会话、排空回合 receipt 与分析、释放 socket/PTY/watcher）。实测中从初始化日志到开始监听只用了 68 毫秒（第三方实测，Windows 10 / nightly.6）。

协议版本化换来了 UI 的独立发布。 packages/contracts 是唯一被前端依赖的包，协议带版本号（实测 WS 路径形如 /ws?client=xxx&protocol=85）。收益是前端可以单独发版、第三方可以照协议写客户端；代价是协议演进必须向后兼容，且实测发现若干参数形状只能从打包后的前端代码反推（如 project.setTrust 用 {id, trusted:true} 而非 {projectId:...}）。

CLI 用 JSC bytecode 编译换启动速度。 nightly.3 把 CLI 二进制改成 JSC bytecode 编译，并把文件与 diff 渲染器抽成独立包。代价是编译产物变大——实测 Windows CLI 单文件 231 MB，桌面包 55.9 MB。nightly.6 还把 Bun 升到 1.4.4，理由是移除被污染的 emSign 根证书，这是一次供应链层面的及时响应。

与「向量库路线」的根本差异： RAG 式记忆把项目知识压成不可读的向量，检索质量不可审计；ThinkRail 把知识留在 Markdown 里，规格被 Agent 改写时会在 diff 里留下痕迹——这是它最重要的可验证性来源，也是它最大的风险来源（见第八节）。

五、【重点】应用场景

场景一：多特性并行开发，Agent 之间互不碰撞

痛点：两个 Agent 同时改同一个 checkout 会互相覆盖；即使不覆盖，你的构建目录也会被搅乱。做法：把仓库开成项目，每个任务「Start building」切一条 worktree 与分支，并行跑，合并你要的那条、删掉其余。 最小可用示例：

curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash
thinkrail ~/code/my-repo          # 打开项目，浏览器起同一套应用

收益与量化：第三方实测（Windows 10 / nightly.6 / DeepSeek）两个任务同时改同一文件，各自建 worktree 与分支、分别提交、main 未被触碰、合并无冲突。 适用边界与不建议：「Work in project folder」模式直接改主目录，界面明确标注 no isolation——想并行就不要在里面干活。另外所有 worktree 共用一个 git stash 栈，实测中 Agent 自己用了裸 git stash 造成互相踩踏；建议在项目规则里写一句「禁止裸 git stash，要暂存就做临时 WIP 提交」。worktree 还会成倍放大磁盘占用与构建缓存，重装依赖的重仓库要自己先量一遍。

场景二：规格驱动开发，让意图跨会话存活

痛点：Agent 不记得你上周否掉过哪个方案，每次都重新推导甚至反着来。做法：在模块旁写 SPEC.md（frontmatter 带 id/type，关系字段用 depends-on/references），Agent 用 spec_* 工具读它、搜它、维护它；侧栏把图谱渲染成只读树。 最小可用示例（限流器二选一的经典教法）：

---
id: module-rate-limiter
type: module-design
status: active
title: 限流器契约
---
## 契约
- 允许突发：桶容量 20，令牌补充 10/s
- 边界行为：恰好等于容量时放行
- 拒绝语义：返回 429，body 含 retryAfterMs

从同一 commit 开两个工作区，各给一个设计（令牌桶 / 滑动窗口），同一份测试文件在两边都能跑且互不干扰，spec 是共同标尺。 收益与量化：把 spec 变更单独提交，就能看出Agent 有没有为了让自己通过而改写契约——这是「规格即文件」相较「规格即提示词」的核心增量。 适用边界与不建议：维护团队在官方 issue 讨论中承认，这套依赖 Agent 持续检索与补充 YAML 图谱的工作流此前从未做过基准对照评估；第三方评析（ic.work）据此指出「成本悖论」——为规避幻觉引入图谱，而维护图谱本身又要高频读写文档，净节省尚无量化数据支撑。不建议在规格会频繁推倒重来的探索期强推这套流程。

场景三：把 CLI Agent 搬进可视化工作台，逐轮评审

痛点：CLI 里读 diff、在精确行上评论、再把反馈交回 Agent，摩擦极大。做法：用 Monaco 标签页、Files 树（带 git 变更标记）、工作区范围内的终端与实时 diff；在文件与 diff 上留锚定评论，作为结构化上下文发进聊天；v0.2.0 起每个回合带 receipt 与 Review 按钮。 最小可用示例：

thinkrail --help                  # --port（默认 24242）/ --no-open / --no-analytics
thinkrail --no-open --no-analytics --port 24242 ./repo

收益与量化：实测确认工作区、对话、token 读数在重启后都还在；token/费用面板与 pi 会话记录逐项一致。 适用边界与不建议：面板单价是写死的美元价——实测指出它不知道 DeepSeek 空闲时段半价，不能直接当账单。另需注意：基础使用事件与错误报告是「always sent」，绑一个随机安装 ID（声明不含提示、代码、文件、凭据与账号身份）；--no-analytics 只管附加数据，实测首次启动的「Share additional usage data」开关默认仍是打开的。

场景四：MCP 与技能的最小授权

痛点：仓库里一个 mcp.json 就能让 Agent 调用任意工具，供应链风险全开。做法：沿用 pi 的 mcp.json；非只读调用先问、仓库自定义服务器默认关闭、OAuth 在设置里登录；设置 → Extensions 逐个开关 ThinkRail 扩展。 最小可用示例：把已装好的 Agent Skills 原地复用（ThinkRail 直接读你为其他编码智能体维护的 Skills），再用内置 workflow 走「项目初始化 → 设计头脑风暴 → 通过你自己的 gh 发 PR」。 收益与量化：授权粒度是「调用」而非「服务器」，配合「仓库自定义服务器默认关闭」，把默认姿态从「先信任」翻转为「先拒绝」。 适用边界与不建议：不建议把「已批准一次」理解为「此后全放行」——项目级信任会放宽后续询问，需要按仓库敏感度决定。

场景五：无头自动化——用 WebSocket RPC 驱动

痛点：想在 CI 或批量脚本里驱动它，却不想开浏览器。做法：UI 通过一条 WebSocket 与引擎通信，帧格式是 {id, method, params} 的 JSON-RPC，用原生 WebSocket 即可驱动。 最小可用示例：

const ws = new WebSocket('ws://[::1]:24242/ws?client=ci&protocol=85');
ws.onopen = () => ws.send(JSON.stringify({
  id: `ci-${Date.now()}-1`, method: 'project.setTrust',
  params: { id: '<projectId>', trusted: true }
}));

收益与量化：实测用这条路把「安装 → 启动 → RPC 驱动 → 免费模型真实 Agent 回合 → Agent 改代码并顺手更新 spec」整条闭环跑通。 适用边界与不建议：实测踩到四个坑——请求 id 全局去重（复用会报 request id was reused with a different payload，用时间戳做前缀即可）；参数名与直觉不一致（session.setModel 要完整模型对象）；未知 API 路径不返回 404，而是回落到 SPA 首页返回 200（靠状态码判活会全绿）；服务只绑 IPv6（用 127.0.0.1 探活会误判为已挂）。此外 v0.2.0 的 provider 列表没有本地模型选项（独立版 pi 支持 llama.cpp，但 ThinkRail 里挂不上）。

六、快速上手

# 方式一：桌面安装包（macOS 14+ arm64/x64、Windows x64、Linux x64/ARM64）
# Linux 桌面版需 glibc 2.38+ 与 GTK3/WebKitGTK 4.1 等：
sudo apt install libgtk-3-0 libwebkit2gtk-4.1-0 libayatana-appindicator3-1 librsvg2-2

# 方式二：CLI（下载后校验 SHA-256，再放进 PATH）
curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash
thinkrail ~/code/my-repo

从源码构建：需 Bun 1.4.4 与 Node ≥22.19，git clone 后 bun install && bun run dev（同时起宿主与前端，Ctrl+C 停止）。其他入口：bun run --filter @thinkrail/cli dev（浏览器启动器）、bun run build:binary（独立 CLI 产物）、bun run desktop:dev / desktop:build（Electrobun 桌面端）。

最小验收清单：① 开一个 git 仓库为项目，切两个工作区各跑一个任务，确认 main 未被触碰；② 写一份带 frontmatter 的 SPEC.md，让 Agent 实现它，再单独提交 spec 变更看它有没有偷改契约；③ 用 --no-analytics 启动后检查 ~/.thinkrail/config.json 里的 analyticsEnabled；④ 用 WebSocket RPC 驱动一次 project.setTrust，确认 id 去重与参数形状。

七、横向对比

维度	ThinkRail	Orca	Claude Code / Codex（纯 CLI）	Cursor / Windsurf
隔离单位	git worktree / 任务	worktree / 任务	无（单工作树）	分支隔离（多代理窗口）
项目知识	`SPEC.md` 图谱，Agent 可读写	状态机 + Decision gate	会话上下文 / `CLAUDE.md`	规则文件 + 索引
多 Agent	支持（受 pi 接口上限约束）	多 harness 并排	单 Agent	多代理窗口
评审粒度	逐 hunk 保留/回滚 + 锚定行评论	Run/Task/Dispatch 状态机	终端 diff	内联 diff
模型来源	自带账号体系，用你自己的凭据	多 harness	各自厂商	各厂商
平台缺口	macOS Intel 无预构建；Linux 产物未签名	—	—	—
成熟度	0.x，无稳定版基准	较成熟	成熟	成熟

读法：如果核心诉求是「多个 Agent 并行且不污染我的 checkout」，ThinkRail 与 Orca 同解，差别在 Orca 用多 harness 换覆盖面、ThinkRail 用规格图谱换知识持久化，代价是能力上限被 pi 锁住。如果核心诉求是「让 Agent 记住项目约定」，ThinkRail 是目前唯一把规格做成可 diff 文件而非向量库的主流样本。

八、局限、风险与社区观察

第一，「越用越好用」是营销措辞，机制上只是本地文档持久化。 第三方评析（ic.work，2026-10-24）拆得很直接：ThinkRail 没有任何跨会话的模型微调能力，也不含强化学习通道，其自我提升完全建立在工程持久化之上——本质是「给智能体配了一个随手记录的本地档案袋」，而非认知层面的蜕变。官方 roadmap 里的「自己造工具」（完整扩展支持）尚未交付。

第二，规格图谱存在「自我指涉」风险。 一个既被 Agent 遵循、又被 Agent 改写的规格，离「一次提示注入就重定义项目真相」只差一步（dev.to 评析原话）。这是它自身前提的真实攻击面，而 README 至今没有回答。同时，Hacker News 讨论中有人强烈质疑「Agent 确实读取了 spec graph」这一表述的可验证性——LLM 并非稳定地理解文档，只是可能把内容随机纳入 context 又在之后丢失。

第三，缺乏基准与量化验证。 维护团队在官方 issue 讨论中承认该工作流从未做过基准对照评估；ic.work 的结论是「实际收益未获量化验证」。本文亦未做独立复现，所有收益数字均来自第三方实测或官方描述，请按此折价。

第四，工程短板与平台缺口真实存在。 实测发现：git stash 跨 worktree 共享导致踩踏；token 面板单价写死；--no-analytics 不关闭基础上报；服务仅绑 IPv6；未知 API 路径回落 200。平台侧：macOS Intel 无预构建桌面版（README 建议用 Apple Silicon 或自行编译，Electrobun 2.0.1 不提供 macOS Intel 桌面构建）；Linux 产物未签名；macOS CLI 已签名但尚未公证，旧版 DMG 与本地构建的包可能被 Gatekeeper 拦截。

第五，与 JetBrains 主线产品的定位割裂。 社区普遍困惑于 JetBrains 的 AI 产品线——Air、ThinkRail、以及更早的 Fleet（2025 年底停止更新分发）与 Junie 各自为政；有长期付费用户表示已取消订阅。「大厂孵化项目」既是背书也是风险：它可能被收编，也可能被放弃。

第六，安全默认值值得肯定，但需自行加固。 MCP 按调用授权、仓库自定义服务器默认关闭，这两条在 2026 年的威胁模型下是加分项。但 pi 官方明确声明不内置权限系统，默认以启动进程的用户权限运行，需要更强边界时应容器化或沙箱化（pi 文档给出 Gondolin micro-VM、纯 Docker、OpenShell 三种模式）。

九、小结与行动建议

ThinkRail 的真正贡献不在于「又一个大厂 AI IDE」，而在于它给出了一个可被复制、且不依赖它本身的方法论：给每个 Agent 任务一条独立 worktree 与分支；把需求放进 Agent 能读、但你能单独审查其修改的版本化文件；把仓库自定义的工具服务器默认关掉直到有人批准。这三条习惯在任何 IDE 或 harness 下都能让并行 Agent 更安全。

先把它当「并行 Agent 的隔离层」试用，而不是当日常主力 IDE——0.x 版本、无稳定基准，官方 roadmap 的核心卖点尚未交付。
隔离就走「Start building」，不要在「Work in project folder」里跑并行任务，并在项目规则里明令禁止裸 git stash。
把 spec 变更单独提交——这是让「Agent 有没有偷改契约」变得可见的唯一低成本手段，也是这套方案最值得偷走的一招。
成本与隐私按生产标准核对：token 面板单价写死不可当账单；--no-analytics 后仍要手动确认 analyticsEnabled；需要硬边界时按 pi 文档容器化。
平台选型先查签名与构建：macOS Intel 需自行编译，Linux 产物未签名，企业分发前先补齐签名与公证链路。

资料来源（抓取于 2026-10-26，除注明外）：GitHub Trending daily 榜与 REST API（JetBrains/thinkrail，★2,796 / 149 fork / 225 open issues / Apache-2.0 / 建仓 2026-07-08 / 最近推送 2026-10-26）；仓库 README、packages/server/SPEC.md、packages/contracts/SPEC.md、packages/spec-graph/SPEC.md、.github/SPEC.md 与根目录树；Releases（v0.2.0 于 2026-10-18、v0.3.0-nightly.6 于 2026-10-25）；贡献者 API（25 人）。第三方实测与评析：掘金《Thinkrail 实测：worktree 隔离了改动，没隔离 stash》（Windows 10 / nightly.6 / DeepSeek）、暗夜独行《JetBrains 开源 ThinkRail 实测》（M4 MacBook / v0.2.0 / WebSocket RPC）、ic.work《用 Spec 图谱压制代码混乱还是增加 Token 账单》（2026-10-24）、dev.to《JetBrains open-sourced an agentic IDE where agents never touch your checkout》、Hacker News 讨论（199 分 / 147 条评论）、开源雷达 2026-10-26、aicassindra 研究摘要（2026-10-26）、hellogithub、daily.dev、aicoolies 工具页。底层引擎资料：earendil-works/pi README 与 npm 包文档、Wikipedia「Pi (AI agent)」、pi.dev 变更日志。本文未做独立复现；所有收益数字均来自上述第三方实测或官方描述，已逐条标注出处，未能核实项已注明「待确认」。