Pi 的 Rust 实现来了：rpi，不止一个终端 Agent

如果你熟悉 Pi，rpi 可以理解为它的 Rust 实现：同样能在终端里读文件、改代码、执行命令，也能作为库嵌入自己的程序。

rpi 用 Rust 重新实现 Pi SDK，并在这套运行时之上提供终端 CLI 和原生扩展。 想直接使用编码助手，可以安装后运行；想构建自己的 Agent，则可以选择需要的模型接入、工具循环和会话管理组件。

已经有 Pi，为什么还要做 Rust 实现？

Pi 本身就有 SDK。rpi 的目的不是证明 Agent 必须用 Rust 写，而是让这套能力更方便地进入 Rust 应用和工具链。

比如，你正在开发一个 Rust 服务，希望它接收任务、调用模型、执行自定义工具，再把进度送到自己的界面。使用 rpi，可以在进程内处理消息、事件和取消，不必把终端程序当成唯一入口。

为此，rpi 采用 library-first 设计：先提供可独立使用的库，再用同一套库组成 CLI。这带来三个实际收益：

  • 按需嵌入：只要模型与工具循环，就使用 Agent 层；需要保存会话、分支与恢复，再加入运行管理层。
  • 复用核心能力：终端助手和自己的应用使用同一套运行时，不必各写一个工具循环。
  • 离线测试流程：用确定性的模型响应和内存执行环境，验证消息与工具往返，不必每次都请求真实模型。

rpi 核心运行时无需 Node，但部分扩展仍依赖外部工具。它也不是 Pi 的接口兼容层：不能默认现有 Pi 扩展安装后就能直接运行。上游归属与 MIT 许可信息保留在项目 NOTICE 中：

上游归属与 MIT 许可原文（展开查看）

https://github.com/bigfish1913/pi-rust/blob/d73d4c79b6a399c375827b5df812e235c3a3c9ae/NOTICE

架构：模型、工具与会话各管一层

rpi 把运行流程分成几层。图中箭头表示职责调用关系，不表示模型和工具同时执行。

rpi 架构：入口、Harness、Agent Loop、模型接入与工具执行

图：带会话管理的运行路径。只需要核心循环的应用，可以直接使用 Agent 层。

  • rpi-ai：接入模型。 统一消息与流式响应，支持 Anthropic、OpenAI-compatible 和自定义网关。
  • rpi-agent：驱动循环。 把模型请求、工具调用和结果反馈串起来，处理事件、队列与取消。模型提出操作，程序实际执行工具。
  • rpi-tools：执行操作。 提供文件与命令工具，并允许替换执行环境。配合 faux 测试 Provider，可以确定性地验证循环。
  • rpi-harness：管理运行。 负责会话持久化、分支、上下文压缩与恢复。最小嵌入式应用可以跳过这一层；恢复不等于所有外部操作都只执行一次。

以“读取一个文件并解释内容”为例：用户任务进入循环，模型提出读文件请求，宿主执行工具，把结果加入消息，再请求模型生成回答。你的应用可以订阅这段过程的事件，把“正在读取”“正在生成”等状态显示在自己的界面里。

外围由 rpi-tui 和 rpi-cli 提供终端体验，rpi-telemetry 定义遥测合约，rpi-plugin-sdk 与 rpi-extensions 负责插件接口和加载，共组成九个核心 crate。

扩展：把自己的工作流接进来

rpi 原生扩展是 Rust 动态库，通过 C ABI——明确的二进制调用合约——向宿主注册工具、模型接入、命令、事件处理和资源。Skills 与提示词描述工作方法，原生插件则加入实际执行能力。

截至 2026 年 10 月 6 日，配套仓库已有 15 个已发布扩展包。下面按使用场景逐个介绍，功能以所列发布版本为准。

任务规划：目标、计划和待办分开管理

rpi-todo（0.2.1）——维护具体待办。 支持新增、查看、完成、删除和清空任务，也可以给任务加标签。默认清单属于当前会话，项目级清单则用于长期积压事项；两者独立保存，避免新会话接手上一段对话的未完成计划。

rpi-goal（0.1.6）——保存项目目标。 用来记录当前要完成什么、推进到哪里，并支持暂停、恢复和归档。目标可以配置轮次或时间预算，耗尽后自动暂停。它关注的是持续目标，todo 关注的是目标下面的一项项工作。

rpi-plan-mode（0.1.4）——先探索，再执行。 进入计划模式后，工具范围收紧到只读探索及计划完成操作，适合先阅读仓库、比较方案。完成的计划写入 .rpi/PLAN.md，再恢复此前的工具集，避免还没理清方案就开始修改文件。

人机协作：把需要确认的决定交还给人

rpi-ask-user（0.1.5）——结构化提问。 支持选项、自由输入、多选和补充说明，适合确认目标平台、实现方案或操作范围。问题会进入 TUI，等待回答后再返回工具结果；超时或取消会关闭请求。没有交互式 UI 的宿主会明确报错。

rpi-permissions（0.1.4）——管理工具权限策略。 提供规则检查、授权、撤销和列举，拒绝规则优先于允许规则。插件负责给出策略判定，宿主需要在工具执行前接入检查才能强制执行；它不是系统级沙箱，不能把“安装插件”当成权限隔离已经完成。

代码分析：定位关系，检查改动，描述委派

rpi-codegraph（0.1.5）——查询代码关系。 提供符号搜索、调用者与被调用者、影响范围、相关源码和索引状态查询。它对本地 SQLite 索引做限定范围的查询，不是每次把整个仓库塞进上下文。使用前需要安装外部 CodeGraph CLI，并为项目建立索引。

rpi-lens（0.1.4）——执行有限的代码检查。 可以运行 git diff --check、cargo check、cargo fmt --check 和 Clippy，把诊断结果交给 Agent。工具设有超时和输出上限，不开放任意命令；适合改动后的检查，但不能代替项目自己的测试套件。

rpi-subagents（0.1.4）——描述子任务委派。 delegate_task 将任务整理成带角色、轮次和超时限制的委派描述，并限制递归委派。这个发布版不负责启动完整的子 Agent，实际调度由宿主完成；它是多 Agent 工作流的一块接口，不是装上就自动并行工作的调度平台。

网络工具：搜索线索、阅读原文、接入外部服务

rpi-websearch（0.1.4）——查找公开资料。 使用无需 API key 的搜索来源，返回标题、URL、摘要和来源信息，并在可用时补充 Wikipedia 结果。适合发现文档和参考线索；正文依据仍应通过抓取原文核实，搜索失败也需要处理。

rpi-webfetch（0.1.4）——读取网页正文。 获取公开 HTTP(S) 页面，提取限量可读文本。它限制私有地址、带凭据的 URL 和过大的响应，失败会作为工具结果返回，方便 Agent 换来源，而不是因为一个网址失败就中断整轮工作。

rpi-mcp-adapter（0.1.4）——发送 HTTP JSON-RPC 请求。 注册 mcp_request，可以向指定端点发送方法、参数和请求 ID，并设置超时。这个发布版是 HTTP 传输适配，不是完整的 stdio 或持久连接客户端；要接哪种 MCP 服务，需要先确认其传输方式。

观测与交互渠道：看清运行过程，增加使用入口

rpi-langfuse（0.4.1）——追踪模型与工具执行。 将会话、模型请求、工具调用、Agent 轮次和压缩过程送到 Langfuse，帮助查看耗时、token 用量和失败位置。也提供手工评分、prompt 版本管理与 trace 查询工具。使用前需要配置 Langfuse 地址和项目凭据。

rpi-im-message（0.1.9）——接入飞书/Lark。 通过长连接接收消息，支持文本、Markdown 和卡片发送；配置后也可把消息交给当前 Agent 自动回复。适合把终端中的工作接入协作渠道，但需要配置应用权限、允许的会话范围及自动回复模型。

rpi-voice（0.3.6）——给 TUI 加语音输入和朗读。 支持按键说话、连续对话和回复朗读，识别结果可先进入编辑框，也可配置为发送。识别可以使用本地 SenseVoice 或兼容接口，朗读使用网络 TTS；自动播报默认关闭，不会安装后立即读出所有内容。

rpi-server（0.3.4）——给自己的客户端提供会话服务。 提供 TCP JSONL / JSON-RPC 接口、会话管理和运行事件订阅，让其他程序可以发送任务并观察进度。它是服务集成层，不是现成 GUI；也不能仅凭相似命令名称，默认与 CLI 内置远程模式完全互换。

这些扩展可以围绕一项任务组合。例如，为 Rust 项目修复一个问题：

  1. 先确认方案：用 plan-mode 探索仓库、组织计划；存在多个可选方案时，通过 ask-user 请用户决定。
  2. 定位并推进改动：用 CodeGraph 查询调用关系、判断影响范围，用 todo 跟踪具体待办。CodeGraph 需要提前建立项目索引。
  3. 检查并观察结果：用 lens 执行 Rust 检查，再按项目要求补充测试；需要追查模型请求或工具失败时，接入 Langfuse。

这是组合示例，不是安装后自动运行的流水线。任务目标、执行权限和验证命令可以写入项目规则；技能文件组织工作方法，插件提供所需工具。

插件需匹配平台与宿主能力，并以当前用户权限运行。插件接口是扩展边界，不是安全沙箱。

性能优势：更快启动，更轻的内存占用

现有基准中，rpi 在启动速度、就绪内存和长会话重载上显示出明确优势。下面将启动、重载与工具循环放在一张表中，数值越低越好。Pi 均为 0.87.1；rpi 版本按行标注，不能把历史结果换标为当前安装示例中的 0.3.16。

测试项目rpi 版本rpiPi
--version 启动至退出 0.3.6 17.5 ms 169.5 ms
启动至响应 get_state 0.3.6 17.7 ms 189.5 ms
空会话就绪 RSS 0.3.6 12.0 MiB 91.5 MiB
重载 100 条历史消息至就绪 0.3.15 16.9 ms 194.9 ms
重载 1,000 条历史消息至就绪 0.3.15 28.8 ms 197.0 ms
重载 5,000 条历史消息至就绪 0.3.15 81.6 ms 212.5 ms
5,000 条消息重载后 RSS 0.3.15 50.8 MiB 116.8 MiB
连续 20 次工具调用 0.3.15 63.1 ms 104.9 ms
连续 100 次工具调用 0.3.15 378.6 ms 402.7 ms

测试环境与方法：

  • 启动基准来自 2026 年 9 月 30 日的公开记录：Windows 11 build 26200、x86_64、release 构建、Node v25.9.0。双方使用独立空配置、空工作目录与离线模式；计时丢弃 3 次预热，取 11 次测量中位数。RSS 是进程驻留内存，单独采样 3 次。
  • 会话重载与工具循环实测于 2026 年 10 月 6 日：Windows 11 build 26300、Ryzen 9 7950X、Node v25.9.0。双方使用独立测试配置、无扩展和本地确定性模型端点，不调用云模型。表中这一组计时均丢弃 2 次预热、测 5 次，报告中位数；重载后 RSS 来自单独一次采样，不是峰值内存。

会话样本采用双方各自的原生 JSONL 格式，逻辑文本相同：用户与助手交替发言，每条约 1,000 个字符。每次启动前恢复原始样本，操作系统文件缓存未清空；就绪以响应 get_state 为准，随后发出请求，核对模型收到的消息数量和尾部标记。这里测的是已完成会话的重新加载，不含 TUI 渲染、压缩组合与执行中断后的恢复。

工具循环在表中列出 20 和 100 次调用两种规模，每次读取同一份 208 字节文件，核对结果成功及模型请求次数，分别对应 21 和 101 次模型请求。计时从提交任务到各自的运行结束通知，不含 CLI 启动。

这张表可以得出几项具体结论：

  • 启动与内存优势明确。 公开基准中，Pi 的版本命令启动、RPC 就绪耗时分别约为 rpi 的 9.7 倍、10.7 倍，rpi 就绪 RSS 低约 87%。
  • 长会话重载更快、占用更低。 三个文本会话规模下，rpi 重载耗时均更短；5,000 条消息时，Pi 重载耗时约为 rpi 的 2.6 倍，rpi 就绪 RSS 不到 Pi 的一半。
  • 20/100 次工具循环。 20 次调用时 rpi 耗时少约 40%；100 次调用结果接近，暂不判定稳定领先。

工具循环每一轮请求都会携带累积的对话和工具结果，后面的请求处理的历史更多。总耗时还包含模拟模型服务、RPC 事件消费和会话运行开销，并不是一次小文件读取耗时乘以调用次数。目前未拆分各环节耗时，差距原因尚未定位；测试也未包含真实模型生成、项目编译和测试，因此不预测真实编码任务的完成速度。

基准原文、原始数据与复现脚本（展开查看）

公开启动基准：

https://github.com/bigfish1913/pi-rust/blob/d73d4c79b6a399c375827b5df812e235c3a3c9ae/docs/performance/benchmark-vs-pi.md

会话重载及 20/100 次循环：

https://blog.laofu.online/benchmarks/rpi-pi-runtime-20261006.json

复现脚本：

https://blog.laofu.online/benchmarks/bench-rpi-pi-runtime.py

已经在用 Pi，值得换吗？

如果现有 Pi 工作流已经满足需求，没有必要仅为更换实现语言而迁移。

如果你正在用 Rust 开发产品，希望直接接管工具、运行事件和会话状态，或者编写原生扩展，rpi 提供了另一条集成路径。它的特点是 Rust 库、CLI 和扩展共享一套核心，而不是承诺模型回答会更聪明。

选择这条路径，也需要管理模型凭据、执行权限、插件依赖和错误处理。rpi 提供运行机制，具体工作流仍由你决定。

开始使用与参与

通过 Cargo 安装：

cargo install rpi-cli --version 0.3.16

安装后按使用文档配置模型凭据，再运行 rpi。不想从源码编译，也可以下载预编译 CLI。

需要扩展时，再逐个安装，例如：

rpi install rpi-todo --version 0.2.1

扩展会在本机编译，需要相应构建环境。开发自己的扩展时，可以通过 rpi dev 编译、监听和热重载，再逐步加入工具或命令。

如果你想先了解 SDK，不必立即配置真实模型。运行仓库的最小示例：

git clone https://github.com/bigfish1913/pi-rust.git
cd pi-rust
cargo run -p minimal

它使用 faux Provider 返回固定文本，展示消息和运行结束事件，不需要模型密钥。先跑通这条路径，再接入真实模型和文件工具，更容易区分控制流程问题与模型服务问题。

欢迎试用，也欢迎从一个具体工具、模型接入或扩展开始贡献。遇到问题时，请附上版本和复现步骤，帮助我们定位。

posted @ 2026-10-07 10:58  付威的网络博客  阅读(10)  评论(0)    收藏  举报