
Remodex多Provider路线图解读RuntimeAdapter如何接入OpenCode与Claude【免费下载链接】remodexRemote Control for Codex.项目地址: https://gitcode.com/gh_mirrors/re/remodexRemodex是一款本地优先的开源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条件组件是否Provider无关说明中继 relay✅只转发加密载荷不理解业务语义安全传输/配对✅加密通道与Codex无关JSON-RPC信封✅iOS的 RPCMessage.swift 可承载任意方法本地git/工作区处理器✅留在桥接层即可无需进适配器运行时协议层❌当前唯一Codex专属的部分也就是说缺的只是一个运行时适配器层。这正是路线图的出发点完整论证见 Docs/multi-provider-standalone-architecture.md。核心设计RuntimeAdapter是什么路线图的灵魂是在phodex-bridge内部加一层Provider中立的运行时适配器接口。它刻意保持很小第一版只要求每个运行时实现启动/关闭 收发原始JSON-RPC消息四个能力成熟后再演进为结构化的方法集合如listModels、startThread、startTurn、interruptTurn、respondToApproval、事件订阅等。与之配套的是能力描述符Capability Descriptor每个Provider自我声明支持哪些能力例如是否支持模型列表、推理强度、审批、线程分叉、语音转录等。这套设计带来两个直接好处iOS几乎不用重写——桥接层把OpenCode事件翻译成现有App已理解的thread/*、turn/*、item/*事件UI按能力自适应——某个Provider不支持服务层级或推理强度App自动隐藏对应控件而不是显示一堆无效选项桥接层的总入口在 phodex-bridge/src/bridge.jsiOS端事件消费逻辑在 CodexServiceIncoming.swift。OpenCode如何接入第一个非Codex运行时OpenCode被选为首个扩展目标因为它天生就适合做无头运行时opencode serve可以启动本地无头HTTP服务器提供OpenAPI端点与Server-Sent Events事件流配套TypeScript SDK可直接编程控制会话、异步提示词、中断、权限应答接入形态是桥接层自动拉起或连接opencode serve创建SDK客户端把OpenCode的会话/消息/事件翻译成Remodex的线程/回合/条目概念。关键的映射关系如下Remodex方法OpenCode侧动作model/list读取OpenCode的Provider与模型thread/start创建OpenCode会话turn/start向会话发送异步提示词turn/interrupt中止OpenCode会话审批应答回复OpenCode权限请求初期通过功能开关即可启用无需改AppREMODEX_PROVIDERopencode 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 CLI最快的MVP路径按回合拉起进程并解析流式JSONCursor SDK长期首选类型安全、可列模型、可恢复AgentCursor Background显式的云端模式面向GitHub仓库UI中明确标注云端运行共同原则只有一条Cursor/Claude都关在桥接层适配器边界之内不直接接入iOS也不让中继理解Provider语义从而保住local-first的产品承诺。五阶段落地路线图整个多Provider演进按风险从低到高拆成六个阶段阶段目标风险0审计现有架构、确定适配器契约基本完成低1引入适配器缝把Codex包装成适配器行为零变化低2OpenCode MVP藏在REMODEX_PROVIDERopencode开关后中3iOS模型选择器感知Provider按能力隐藏控件中4建立Provider中立的Remodex规范协议逐步迁移iOS中高5逐个添加Claude、Cursor、Gemini等适配器视Provider API而定阶段划分刻意让每一步都可独立交付第一个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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考