【Rust日报】2026-11-13 Pi GPUI - 用 GPUI 运行本机已安装的 pi 编程代理
内容提要
Pi GPUI 是用 Rust 和 GPUI 编写的原生应用，可运行本机已安装的 pi 编程代理，支持多会话、会话树与斜杠命令，凭据由 pi 保存。Rust 1.100 稳定了 never 类型和自定义分配器 API，Cargo 引入 lint 系统与依赖冷却。Rust 的 13 个 GSoC 2026 项目全部通过，涉及 GPU offload、链接器 Wild、Miri 调试器等。Rust Glancer 探讨持久化增量计算。
延伸解读
Pi GPUI 的架构取舍：会话隔离与凭据边界
Pi GPUI 不内置 pi，而是为每个会话单独启动本机已安装的 pi，通过 stdin/stdout 上的 JSONL 通信。这种设计让多个会话可以并行工作，一个会话继续运行时仍能查看另一个。凭据完全由 pi 保存，应用不接触登录信息，降低了凭据泄露面。代价是用户必须自行安装 pi 1.4 或更新版本，应用只负责界面与交互。
GPUI 状态模型的争议：性能精度该由谁承担
文章引用的评论指出，GPUI 和 egui 都不适合作为复杂桌面应用的默认选择：框架若不能指出哪个值变了、谁依赖它，性能就难以上去；由应用手工补上这份精度，又会失去 API 的简单性。评论认为更直接的是组件只运行一次，并用 signal 标出依赖。文中还提到 Discord 已宣布用 GPUI 重写客户端，而评论作者自己也在做基于 signal 的框架 zgui。
Rust 1.100 的实用变化：never 类型与 Cargo lint
Rust 1.100 稳定了 never 类型 !，使其可出现在任意类型位置，包括 Result<T, !> 这类泛型参数，Infallible 成为其别名。兼容性上，2015、2018 和 2021 edition 的 never-type fallback 从 () 改为 !，部分既有代码或依赖可能需要修改。Cargo 引入自己的 lint 系统，默认启用 cargo::unused_dependencies，提示未使用却增加构建时间的依赖，但检测目前不包括未使用的 dev-dependency。
供应链防护的边界：dependency cooldown 不是完整方案
Cargo 新增可选的 dependency cooldown（minimum publish age），开启后解析器会忽略发布时间短于设定期限的版本，除非该版本已在 Cargo.lock 中。它不作用于 cargo install，还依赖注册表提供发布时间。文章明确提醒，应将其视为额外防护，而不是完整的供应链方案。对于关注依赖安全的团队，这意味着仍需配合其他审查手段，不能仅靠这一开关。
Q&A
Pi GPUI 是什么？它支持哪些平台？
Pi GPUI 是用 Rust 和 GPUI 编写的原生应用，可在桌面运行用户已安装的 pi 编程代理。它支持 macOS 13 的 Apple silicon，以及 x86_64 和 arm64 的 Linux（beta），以 MIT 许可证发布。
Pi GPUI 如何与 pi 通信？需要什么版本的 pi？
每个会话单独启动本机的 pi，使用 pi --mode rpc，经 stdin 和 stdout 上的 JSONL 通信。它需要 pi 1.4 或更新版本。
Pi GPUI 的凭据管理是怎样的？
凭据不经过应用：在 pi 中执行 /login 连接订阅或 API key，由 pi 保存。
Rust 1.100 稳定了哪些主要特性？
Rust 1.100 稳定了 never 类型 !（可写在任意类型位置，Infallible 成为其别名）和自定义分配器 API（Allocator、Global、System 及 Box::new_in、Vec::new_in 等），还稳定了 DropGuard、bool::toggle、Box::take 等。
Cargo 在 Rust 1.100 中引入了哪些新功能？
Cargo 引入了自己的 lint 系统（如默认启用的 cargo::unused_dependencies），并新增可选的 dependency cooldown（minimum publish age，RFC 3923），开启后解析器会忽略发布时间短于设定期限的版本（除非已在 Cargo.lock 中）。
Rust 的 GSoC 2026 项目成果如何？有哪些代表性项目？
Rust 的 13 个 GSoC 2026 项目全部通过最终评估。代表性项目包括：安全 GPU offload（std::offload）、链接器 Wild 的 WebAssembly 链接和链接脚本支持、Miri 交互式调试器 priroda、rust-analyzer 的 SyntaxEditor 迁移、libc 1.0 推进等。
Rust Glancer 为什么需要持久化增量计算？
Rust Glancer 希望压低内存占用，长期未采用增量计算，而是自己维护持久化缓存。但缓存格式需手工实现并持续优化，计算与缓存绑定导致复杂度上升，因此到了会明显受益于持久化增量计算的阶段。
