PI-Desktop
如果学生在学校里学习的结果是使自己什么也不会创造，那他的一生永远是模仿和抄袭。——列夫・托尔斯泰
PI-Desktop：把 AI 编程代理带进一间真正属于开发者的桌面工作室
项目地址：https://github.com/vastsa/PI-Desktop
AI 编程代理正在越来越多地参与真实开发工作。它们能阅读代码、修改文件、执行命令、运行测试，也能围绕一个目标持续推进任务。但许多代理至今仍住在终端里、编辑器扩展里，或某个托管服务的狭小入口中。
PI-Desktop 想做的，是给这些代理一张更完整的桌面工作台。
它是一个本地优先的 AI 编程代理桌面应用，围绕项目、会话、模型、工具、审查和长时间运行的任务组织工作流程。开发者可以打开本地项目，自行配置模型，让代理开始工作，同时始终保留对权限、修改和执行结果的掌控。
它不要求 PI-Desktop 账户，也不要求通过固定的中转服务，更不把工作流锁定在某一个编辑器中。
这是一种很明确的产品姿态：模型可以自己选，项目可以自己开，代理可以自己跑，真正的控制权仍然留在使用者手里。
不是聊天窗口，而是一处代理工作空间
如果把传统聊天式 AI 工具比作一张对话桌，那么 PI-Desktop 更像一间正在运转的开发工作室。
项目、对话、代码审查、文件、预览、通知和扩展能力被集中到同一个桌面空间中。代理不再只是侧边栏里偶尔弹出的助手，而是可以围绕项目持续工作的参与者。
PI-Desktop 的核心方向可以概括为四个部分。
桌面优先
PI-Desktop 让开发者可以跨项目、跨会话地工作，而不必把代理流程绑在某一个终端或编辑器里。
在同一处工作空间中，可以管理本地仓库、查看长期对话、检查修改结果、查看命令输出、预览应用，并在不同任务之间切换。
这种组织方式尤其适合持续推进的开发工作。一个复杂任务往往不会在一轮对话中结束，也不会只涉及一个文件。它可能经历代码探索、方案讨论、实现、测试、修复、审查和继续迭代。PI-Desktop 希望把这些过程放进一个连续的桌面环境中，而不是散落在多个工具窗口里。
自带模型
PI-Desktop 不把代理运行时固定在一份硬编码模型列表上。
它支持 OpenAI、Anthropic、兼容 OpenAI 的 API、托管模型网关，以及 Ollama 和 LM Studio 等本地网关。开发者可以配置多个提供商与多个模型，并在每个会话中切换模型。
模型配置还可以包含上下文窗口、输出限制、推理控制、温度等与模型相关的行为。
这意味着，同一个项目里的不同任务不必被迫使用同一种模型。开发者可以直接在 Composer 中切换模型，而不需要重新创建会话。
模型不再是一扇只能从外部打开的门，而是工作空间中的一项可配置资源。
默认可检查
代理可以读取文件、编辑代码、执行命令，但特权操作会经过 PI-Desktop 的权限层。
开发者可以审查代码差异，检查命令输出，并决定每个会话拥有多大的自主程度。
这让代理的行动不再只是一个黑箱过程。它可以工作，也可以前进，但每一步仍然处于可查看、可审查的边界之内。
在 AI 参与编码的场景里，结果当然重要，但过程同样重要。代码改了哪些地方，命令执行了什么，测试发生了什么，代理是否走偏，这些都不应该被一句最终回答掩盖。
PI-Desktop 把审查能力放进工作流本身，让开发者看到的不只是代理说了什么，也包括代理做了什么。
为扩展而生
PI-Desktop 支持 Skills、MCP Server、Subagents 和可安装 Plugins。
插件可以提供工具、命令、工作区面板、工作面板视图、主题、服务、Skills、MCP Server、Subagents 和插件间消息能力。
这种扩展方向让桌面工作空间不只是一个固定功能集，而可以不断长出新的接口、新的面板和新的代理协作方式。
从一句提示，到一份可审查的修改
PI-Desktop 的开始路径很清晰。
第一步是连接模型。进入设置中的模型配置，选择提供商或兼容 API，并添加凭据。
第二步是打开项目。开发者可以从侧边栏加入任意本地仓库或项目目录。
第三步是选择工作模式。PI-Desktop 提供 Agent、Plan 和 Goal 三种模式。
第四步是审查结果。开发者可以在 Review 面板中检查编辑内容，查看命令输出，预览应用，并在不离开 PI-Desktop 的情况下继续对话。
这条流程从提示开始，但终点不是一句文本回答，而是一份可以被检查、被继续推进、被验证的工作结果。
Agent、Plan 与 Goal：同一个代理，三道不同的门
PI-Desktop 将代理工作方式分为 Agent、Plan 和 Goal 三种模式。
它们使用的是同一个代理，但给开发者提供了不同的批准边界。无论处于哪一种模式，特权工具都仍然要经过权限层。
| 模式 | 开始前需要批准的内容 | 代理的工作方式 | 适合的场景 |
|---|---|---|---|
| Agent | 不需要额外批准 | 读取、编辑、执行命令、测试和迭代 | 希望代理直接开始完成工作 |
| Plan | 实现计划 | 先研究仓库，形成冻结的实现计划，然后等待批准 | 变更较大或风险较高，希望先确认方法 |
| Goal | 目标与验收标准 | 自行选择路径，持续工作直到目标达成 | 更关心结果，而不是每一步具体路线 |
Agent：让代理直接进入工作循环
Agent 是默认的工作循环。
它会检查目录结构，修改文件，执行命令，运行测试，并持续向前推进。对于目标清晰、边界明确的任务，Agent 模式提供了最直接的协作节奏。
开发者提出需求，代理进入项目，开始读取、修改、验证和迭代。
Plan：先看清路线，再开始施工
Plan 模式强调批准边界。
代理会先研究仓库，然后输出一份不可变的实现计划。在开发者确认之前，执行不会开始。
对于影响范围较大、实现路线需要审慎确认的任务，这种模式让方案先于改动出现。开发者可以先审视代理准备如何做，再决定是否让它真正开始修改项目。
计划在这里不是一次临时的口头建议，而是执行之前的一道明确门槛。
Goal：锁定结果，把路径交给代理
Goal 模式更关注最终目标与验收标准。
开发者锁定目标后，代理自行决定实现路径，并持续工作直到目标满足。
它适合那些结果比过程更重要的任务。开发者不需要逐步指定实现方法，而是明确希望看到什么结果，再由代理选择合适的行动路线。
Agent 让代理直接做事，Plan 让开发者先审方案，Goal 则把注意力聚焦在最终达成的目标上。
三种模式像三种不同的协作节奏，让开发者可以根据任务风险、复杂度和控制需求，决定代理究竟应该多快开始行动。
长任务不该被塞进一个上下文窗口
大型任务往往不属于单一上下文窗口。
PI-Desktop 提供 Subagents，用于把独立工作委派给后台子代理。它们可以承担代码库探索、多文件实现、研究与调查、测试分析，以及对抗式审查等工作。
每个 Subagent 都在独立上下文中运行，并将结果回传给父代理。
这让复杂任务不必完全依赖一个代理在一段单线程对话中完成。不同工作可以被拆分，交给不同上下文中的子代理处理，再由父代理接收结果并继续推进。
对于大型仓库或多步骤任务来说，这种分工让任务更接近真实开发中的协作形态。
一个代理负责整体方向，子代理分别去探索、实现、分析或审查。它们各自带着独立上下文工作，再把发现与结果带回来。
为长时间会话准备的桌面环境
PI-Desktop 并不是只为一次提示设计。
它支持管理多个项目和会话，可以置顶或归档对话，也可以分支会话。代理运行时，开发者还可以排队提交提示。
文件可以通过 @ 被引用，工作流中可以使用斜杠命令，也可以在多个会话中搜索。
对于持续流式输出的场景，PI-Desktop 会进行检查点保存。README 表示，当应用重启或运行时发生故障时，被中断的工作会在可能的情况下得以保留。
这让会话不再像一次性聊天记录，而更像持续运行的开发现场。
一个任务今天没有完成，并不意味着明天必须从头开始。一个代理因为应用重启被打断，也不意味着所有上下文都必须重新拼接。PI-Desktop 试图让长期任务拥有更稳定的停靠点。
把注意力放在工作，而不是答案表面
AI 编程代理最容易给人留下印象的，往往是最后那段回答。
但真正决定代码是否可靠的，通常是那些藏在回答背后的过程：修改了哪些文件，执行了哪些命令，测试输出是什么，差异是否符合预期，应用是否能够预览。
PI-Desktop 为这些工作准备了专门的界面区域。
开发者可以查看长期运行的会话与对话导航，按会话选择提供商、模型和推理等级，也可以通过插件市场扩展工作空间，并为模型配置提供商连接。
它关注的不是只让代理回答得更像一个助手，而是让代理工作的过程更接近一个可以检查的工程流程。
Skills、MCP、Subagents 与 Plugins：工作空间可以继续生长
PI-Desktop 的扩展能力并非只有一种入口，而是由多层机制组成。
Skills：把可复用的工作方法交给代理
Skills 可以为代理提供可复用的指令与工作流。
它们既可以全局安装，也可以针对单独项目启用。这样一来，不同项目可以拥有不同的代理工作习惯、流程要求与任务方法。
MCP：把外部工具与服务接进来
PI-Desktop 可以通过 Model Context Protocol Server 连接外部工具和服务，而不需要把这些能力硬编码进桌面应用中。
应用还可以被外部 MCP Agent 控制。通过设置 PI_DESKTOP_MCP_CONTROL=1 启动应用后，可以从 Electron 用户数据目录中的 mcp-control.json 读取回环端点与 Bearer Token。
该端点支持项目、会话和 Agent 工作流，并提供经过审查的桌面操作目录。它默认关闭，只绑定回环地址。调用它的本地 Agent 将拥有与桌面端相同的操作权限，其中 confirm: true 并不代表向用户发起确认提示。
Subagents：让专业分工成为可能
Subagents 可以拥有自己的指令、工具和模型选择，然后被其他代理委派任务。
这使得一个父代理不仅能自己完成工作，也可以把特定类型的任务交给更适合的子代理。
Plugins：把能力扩展到应用本身
插件不仅能为代理增加工具，也能改变 PI-Desktop 的工作空间体验。
它们可以带来命令、面板、工作面板视图、主题、服务、Skills、MCP Server、Subagents 和插件间通信能力。
插件可以通过本地方式安装，也可以通过 .piplug 包工作流从市场安装。
PI-Desktop 同时明确指出，插件进程会受到权限控制，并且与渲染进程隔离，但插件仍然属于用户信任的代码，而不是完整的操作系统级沙箱。
本地优先，不等于永远不联网
PI-Desktop 对本地优先的定义很具体。
对话会以 JSONL 形式保存在本地，并建立 SQLite 索引。设置保存在本机。API 凭据保存在操作系统钥匙串中。日志保存在本地。PI-Desktop 不收集遥测数据。
模型请求则会直接发送到开发者配置的提供商或端点。
| 数据类型 | 行为 |
|---|---|
| 对话 | 以 JSONL 形式本地存储，并使用 SQLite 索引 |
| 设置 | 保存在本机 |
| API 凭据 | 保存在操作系统钥匙串 |
| 日志 | 保存在本地 |
| PI-Desktop 遥测 | 不收集 |
| 模型请求 | 直接发送至开发者配置的提供商或端点 |
PI-Desktop 不要求账户，也不强制让请求经过 PI-Desktop 托管的中转服务。
如果使用远程模型提供商，模型请求所需要的上下文自然会发送给对应提供商，并遵循该提供商自身的隐私政策。
这种本地优先的表达没有回避网络模型的客观事实，也没有把本地优先简化成口号。它清楚划分了哪些数据在本地，哪些请求会直接流向开发者选择的模型端点。
从其他编码代理带来的会话，也能继续留在桌面里
PI-Desktop 支持导入来自 Claude Code、Codex、OpenCode 与 Pi 的本地会话。
开发者可以通过设置中的导入功能，把已有工作带入 PI-Desktop 工作空间。
这项能力让会话不必因为更换使用界面而被隔断。已经进行过的工作、已经积累的上下文与已经形成的对话轨迹，可以被带到新的桌面环境中继续管理。
桌面壳、宿主核心与代理循环的分工
PI-Desktop 的架构将用户界面、特权宿主能力与代理循环分开。
1 | flowchart TB |
React Renderer 负责聊天、项目、审查和设置等界面内容。
Electron Main 负责桌面编排。
Rust Host Core 负责特权工作区操作、权限、持久化和密钥。
pi Agent Sidecar 负责模型交互与代理循环。
模型提供商可以是云端，也可以是本地端点。
渲染层不具备 Node 集成能力。特权操作、文件系统、SQLite 与密钥管理由 Rust Host Core 持有，代理循环与模型交互则由 pi Agent Sidecar 承担。Electron 在两者之间负责协调桌面应用的整体运行。
这种分工让用户界面、特权能力与代理逻辑各自拥有清晰边界。
可运行于 macOS、Windows 与 Linux
PI-Desktop 面向 macOS、Windows 和 Linux 提供桌面构建。
支持的包类型包括：
| 平台 | 架构 | 包类型 |
|---|---|---|
| macOS | Apple Silicon | .dmg 与 .zip |
| macOS | Intel | .dmg 与 .zip |
| Windows | x64 | NSIS 安装程序与便携式 exe |
| Linux | x64 | .AppImage、.deb、.rpm 与 .asar |
Linux x64 包需要 glibc 2.35 或更高版本。README 列出了 Ubuntu 22.04 及之后版本、Debian 12 及之后版本，以及 Fedora 36 及之后版本所提供的对应支持条件。
对于本地开发，项目要求 Node.js 22.19 或更高版本、pnpm 10 或更高版本，以及稳定版 Rust 工具链。仓库当前固定使用 pnpm 11，而 CI 与发布构建使用 Node 24。
本地运行可以使用以下流程：
1 | git clone https://github.com/vastsa/PI-Desktop.git |
验证修改时，可以执行：
1 | pnpm typecheck |
文档开发与检查可以使用：
1 | pnpm docs:dev |
仍在快速成长的 Early Preview
PI-Desktop 目前处于 Early Preview 阶段。
README 表示，项目正在积极开发，已经能够用于真实编码工作流，但 API、扩展接口以及部分桌面行为仍可能继续演进。
当前的 0.14.x 版本线已经包含桌面壳、流式代理运行时、Agent、Plan 与 Goal 工作流、具备权限意识的工作区工具、项目与会话、会话导入、本地 MCP、Skills、Subagents、Plugins，以及审查与预览工作流。
项目当前关注的方向包括：
- macOS 标签发布资格验证
- 安装程序升级与回滚资格验证
- 持续强化运行时与会话恢复能力
- 更强的插件沙箱与发布者验证
- 更广泛的界面驱动端到端覆盖
这意味着 PI-Desktop 不是一个已经停止变化的封闭成品，而是一套仍在继续搭建、继续加固、继续扩展的桌面代理工作空间。
让工作流仍然属于开发者
PI-Desktop 的一句核心表达很有力量：使用你想用的模型，保留属于你的工作流。
它并不试图让开发者放弃现有项目、现有模型选择或现有工作方式。相反，它把本地项目、模型配置、权限审查、会话管理、工具接入、代理协作和插件扩展放到一个桌面环境中。
在这里，AI 编程代理不只是终端里的一段命令，也不只是编辑器角落的一次补全。
它可以拥有项目、任务、会话、计划、目标、子代理、工具、审查与恢复能力。
而开发者仍然可以看见代码如何变化，决定代理在何时开始执行，选择模型从哪里来，确认特权操作如何发生，并把整个工作过程留在自己的桌面工作空间里。