企业官网建设流程全解析

Remodex多Provider路线图解读：RuntimeAdapter如何接入OpenCode与Claude

【免费下载链接】remodexRemote Control for Codex.项目地址: https://gitcode.com/gh_mirrors/re/remodex

Remodex是一款本地优先的开源AI编码远程控制工具，让iPhone成为Mac上Codex等AI编程代理的"遥控器"。它的多Provider路线图正在把架构从"只服务Codex"升级为通用运行时接入层：通过名为RuntimeAdapter的桥接适配器，未来可无缝接入OpenCode、Claude、Cursor等多种AI编程运行时。本文将用通俗语言拆解这套设计的核心思路、接入方案与分阶段落地路径，帮你快速看懂Remodex的下一步演进方向。

先认识Remodex：本地优先的AI编码遥控器

Remodex由两部分组成：运行在Mac上的本地桥接程序（bridge），以及运行在iPhone上的SwiftUI应用。整体链路是：

iPhone应用 → 加密中继（relay）→ Mac本地桥 →codex app-server运行时

• 配对采用二维码一次性引导，之后走端到端加密通道，中继本身看不到明文内容
• git提交、推送、切分支等操作都在Mac本地执行，手机只负责"下达指令"
• 完整架构说明见 README.md 中的Architecture一节

Remodex在iPhone上实时查看Codex编码会话与Diff的界面

为什么要画多Provider路线图

目前的桥接层说的是"Codex方言"：

• 运行时启动逻辑写死在 phodex-bridge/src/codex-transport.js 中，只负责拉起codex app-server
• 桥接层转发thread/start、turn/start这类Codex风格的方法
• iOS端的模型默认值、推理强度选项也都是围绕OpenAI/Codex设计的

但仔细盘点后会发现，Remodex的地基其实已经具备了多Provider条件：

也就是说：缺的只是一个运行时适配器层。这正是路线图的出发点，完整论证见 Docs/multi-provider-standalone-architecture.md。

核心设计：RuntimeAdapter是什么

路线图的灵魂是在phodex-bridge内部加一层Provider中立的运行时适配器接口。它刻意保持很小，第一版只要求每个运行时实现"启动/关闭 + 收发原始JSON-RPC消息"四个能力；成熟后再演进为结构化的方法集合，如listModels、startThread、startTurn、interruptTurn、respondToApproval、事件订阅等。

与之配套的是能力描述符（Capability Descriptor）：每个Provider自我声明支持哪些能力，例如是否支持模型列表、推理强度、审批、线程分叉、语音转录等。

这套设计带来两个直接好处：

1. iOS几乎不用重写——桥接层把OpenCode事件"翻译"成现有App已理解的thread/*、turn/*、item/*事件
2. UI按能力自适应——某个Provider不支持"服务层级"或"推理强度"，App自动隐藏对应控件，而不是显示一堆无效选项

桥接层的总入口在 phodex-bridge/src/bridge.js，iOS端事件消费逻辑在 CodexService+Incoming.swift。

OpenCode如何接入：第一个"非Codex"运行时

OpenCode被选为首个扩展目标，因为它天生就适合做无头运行时：

• opencode serve可以启动本地无头HTTP服务器
• 提供OpenAPI端点与Server-Sent Events事件流
• 配套TypeScript SDK可直接编程控制：会话、异步提示词、中断、权限应答

接入形态是：桥接层自动拉起或连接opencode serve，创建SDK客户端，把OpenCode的"会话/消息/事件"翻译成Remodex的"线程/回合/条目"概念。关键的映射关系如下：

初期通过功能开关即可启用，无需改App：REMODEX_PROVIDER=opencode remodex up。

一个值得注意的细节：OpenCode本身就是多模型网关，可以在其中选择Anthropic的Claude模型。所以Claude能力其实会以"OpenCode + Anthropic模型"的形式先行落地，用户不写代码也能感受到多Provider带来的模型选择自由。

Claude与Cursor的接入路径

在路线图里，Claude是"后续原生Provider"之一：与Codex、OpenCode适配器并列，挂在同一个RuntimeAdapter接口下，共享事件归一化与能力描述符机制。官方建议是"等OpenCode适配器验证接口契约后，再逐个添加Claude、Gemini、Cursor"，避免过早抽象。

Cursor则是最典型的"多表面"Provider，单独有一份深度集成文档 Docs/cursor-cli-sdk-acp-integration.md，其策略是把Cursor拆成三种模式：

共同原则只有一条：Cursor/Claude都关在桥接层适配器边界之内，不直接接入iOS，也不让中继理解Provider语义，从而保住local-first的产品承诺。

五阶段落地路线图

整个多Provider演进按风险从低到高拆成六个阶段：

阶段划分刻意让每一步都可独立交付：第一个PR只做"包一层"，第二个PR才加OpenCode，避免大爆炸式重构。

安全红线：多Provider不牺牲本地优先

无论接入多少运行时，Remodex坚持几条硬约束：

• 中继保持"哑转发"：不解析Provider ID、模型、提示词内容
• Provider服务器默认绑定127.0.0.1，不向局域网暴露
• 不记录密钥：配对密钥、Provider API Key、会话令牌一律不落日志
• 审批策略保守映射：手机端的"完全访问"不会被放大成Provider侧的"允许一切"

这些约束保证：即使将来App里能选十几个模型，你的代码、git操作和文件读写依然只发生在自己的Mac上。

写在最后：一张图看懂演进方向

iPhone Remodex → 中继/加密/配对 → Mac本地桥 → RuntimeAdapter ├─ Codex（默认） ├─ OpenCode（首个扩展） ├─ Claude（后续原生） └─ Cursor / Gemini / …

对普通用户来说，路线图的终点很直观：打开Remodex，像切换Wi-Fi一样选择底层运行时与模型，而配对的手机、加密的通道、本地执行的工作区全部保持不变。对开发者来说，最值得关注的代码位置是 phodex-bridge/src/ 与 relay/ 目录，以及 Docs/ 下两份架构文档——它们是多Provider路线图的"源代码级说明书"。

Remodex的多Provider之路，本质是把"一个Codex遥控器"进化为"一个本地AI编码运行时总管"，而RuntimeAdapter就是这场升级的枢纽。

【免费下载链接】remodexRemote Control for Codex.项目地址: https://gitcode.com/gh_mirrors/re/remodex