给 Agent 接一个“兼容 OpenAI”的公司网关，协议代码可以复用，官方账号的 OPENAI_API_KEY 却不能因为协议兼容就自动拿来用。模型目录、服务端点和认证都属于这个网关自己的身份。

最近在 rpi 里推进 Provider 分层，就是想把这件事理顺：供应商怎么接入、凭据怎么绑定、增量怎么回来，由适配层处理；Agent 继续负责工具循环、会话和取消。接一个新服务，不应该顺手改一遍 Agent 的执行逻辑。

仓库：https://github.com/bigfish1913/pi-rust

先说 rpi 能拿来做什么

rpi 是 Rust 原生的 coding-agent runtime，也提供基于这套运行时的终端编码助手。可以直接装 CLI 用，也可以把 rpi-agent 等 crate 嵌进自己的程序，自己掌控工具、事件和输出。

如果你已经有自己的工作流，还可以通过动态库扩展提供工具或 Provider。对 Rust 开发者来说，这条路径比较有意思：业务能力可以先在自己的嵌入式 Agent 里调试，再通过扩展适配器交给 rpi 宿主使用。

这次 Provider 工作服务的就是这个定位。核心依赖统一的 Provider 契约，内置实现和插件实现从同一入口被调用，上层消费统一事件。

已有协议的新服务，尽量只加配置

例如 OpenAI 官方和公司网关都使用 Chat Completions，它们可以复用请求编码和 SSE 解析代码，但要分别保留自己的 provider ID、模型目录、端点和凭据。

这带来两个直接好处：协议修复不用给每家供应商复制一遍；切到公司网关时，也不会仅因“兼容 OpenAI”就去读官方的 key。

当前代码已经支持通过 models.json 配置已有协议的新身份。更特殊的请求签名、私有接口等需求，可以沿 Provider 扩展方向接入。需要说明的是，插件的模型目录和认证声明还在收敛，暂时不能承诺任意新协议都能“装一个 package 就全部接好”。

Rust 插件边界，选了 C ABI + JSON

跨动态库直接传 Rust trait object、String 或异步运行时对象，会把宿主和插件绑在不稳定的 Rust ABI 上。rpi 的扩展边界使用 C ABI 函数指针和 JSON 信封，字符串由分配它的一侧释放。

这条路线允许插件不依赖宿主使用同一 Rust 编译器版本，但仍需遵守插件 ABI 和平台要求。代价也很实际：插件与宿主同进程，内存所有权、动态库持有和退出时机都得处理；它不是安全沙箱。

插件也要边生成边显示，取消时及时返回

开发分支里的流式 Provider 会通过回调交付 chunk，宿主把它们转成 Agent 和 TUI 消费的事件流。同步 FFI 调用放在 spawn_blocking 中，避免阻塞异步转发路径。

这里最关心的行为是：增量在结束前能被上层看到；一次请求只有一个终态；用户取消以 Aborted 结束，而不是再补一个成功完成。

欢迎拿自己的接入需求来试

如果你在用 Rust 做内部编码助手、给现有工具嵌 Agent，或者需要接公司的模型网关，可以从 rpi 的 CLI 或最小嵌入示例开始：

cargo install rpi-cli
rpi --help

• 项目与使用说明：https://github.com/bigfish1913/pi-rust
• 官网：https://rpi.bigfisharc.cn/
• 最小嵌入示例：https://github.com/bigfish1913/pi-rust/tree/162d0dd591504aa0a20d2693d8be774b2ad4d66b/examples/minimal
• 插件示例：https://github.com/bigfish1913/pi-rust/tree/162d0dd591504aa0a20d2693d8be774b2ad4d66b/examples/plugin-stub

这轮尤其想收集两类真实需求：现有 OpenAI/Anthropic 兼容网关在哪些地方并不兼容，以及私有认证、模型目录、取消语义中哪些部分需要扩展声明。欢迎带接口差异或最小复现提 issue；这些材料能直接帮助确定 Provider 与宿主的边界。