看看这个https://github.com/JetBrains/thinkrail

回复 joye： 这是 JetBrains InnovationHub 出的 ThinkRail，一个围绕 pi coding agent 搭的 agentic IDE，Apache-2.0 开源，已经 2.1k star。 读完 README 后，我的判断是：它真正的产品价值在于“IDE 为 agent 让路”，而不在于“IDE 里带 AI”。它没有像 Cursor、Windsurf 那样把补全器塞进编辑器，也没有像 Claude Code 那样把 agent 塞进终端，而是把 IDE 做成一个薄壳，专门承接 agent 的产物。 三层实现： Engine host 是 Bun.serve 的 HTTP+WS 进程，每个 chat 跑一个 in-process 的 pi session。pi 负责模型、skills、上下文压缩、成本、session state，ThinkRail 自己则明确声明“绝不背着你拼 prompt”。中间是 packages/contracts 的 typed 协议，前端 React 19 + Zustand 跑在 apps/web，并且单独发版，可以远程连 host。桌面端和 CLI 嵌入式同一套 host，状态都放在 ~/.thinkrail。 几个我比较在意的设计： 一是 workspace 用 git worktree 切。每个 workspace 一条分支一个工作目录，多个 pi session 并行工作且互不干扰，你在自己 checkout 里的改动不会被触碰。合并成功后删除其余 worktree；闲置一周或 PR 合并后自动收进 per-project shelf，再次使用时会自动恢复。topbar 直接显示分支相对 origin 的状态和 PR 状态，一键 publish、push 或创建 PR。 二是 SPEC.md 作为 ground truth。代码旁边有一张 spec 连通图，agent 通过专门的 spec_* 工具读取、检索、维护，意图不会因为 session 结束而丢失。整个仓库也是 spec-first 开发的，每个模块旁都有一份 SPEC.md，跨边界改动时要同步更新 spec。 三是 skills 和 workflows 直接复用你已有的 Agent Skills，连加载位置都不变；内置 workflows 负责项目初始化、设计 brainstorming、提 PR，PR 通过你自己的 gh 发。MCP 接 pi 的 mcp.json，非只读调用要在 chat 里确认，repo 自带的 server 不批准就不启。 模型和账号不绑定：用 JetBrains AI 登录，或者走 pi 自己的 auth 接任意 provider，它自己没有账号体系。这点和 Amp、Cursor 的做法相反。 我的看法：JetBrains 这次是在承认“补全式 AI”这条线守不住了，转而押注“agent 干活的地方得是个真 IDE”。它赌的是 spec、worktree、skills 这些会让上下文变长、变更变复杂的工程资产，只有 IDE 形态才承载得动。这个方向我认同，但两个风险也很明确：一是 pi 是外部 agent engine，ThinkRail 对模型行为的控制力有限，harness 一换代它就得跟着追；二是它现在明确写着“下一步才支持 extension”，也就是说自定义能力还得等，现阶段它的护城河是 UI 和 spec 工作流，而不在能力层。 想实际尝试的话，安装命令行版本最快，一条 curl 转给 bash 就能装好，然后 thinkrail ~/code/repo 打开。但注意它是 0.x，nightly 和 stable 并存，别直接用在主仓库里。