Conduit：把 Open WebUI 装进手机，也允许你完全绕开它

移动端不是缩小版桌面，Conduit 补的是那几处断层

README 自己把问题定义得很具体：Open WebUI 在桌面上很好用，在移动端会在边缘处崩掉。它列出的场景是反向代理后面的鉴权、应用切到后台时中断的流式输出、把一张截图塞进提示词、从主屏幕直接发起一段对话。这四件事都不是模型能力问题，而是客户端形态问题。浏览器在手机上要处理标签页回收、后台节流、文件选择器权限，这些环节叠起来，桌面端顺理成章的操作在手机上就变成了摩擦。Conduit 的定位是原生 Flutter 应用，不是套壳 WebView，目标用户是已经在跑自建 Open WebUI 的人，以及只想把手机直接接到自己模型端点、不想为此再搭一套 Web 服务的人。从 4.0 起，它可以在完全没有 Open WebUI 服务端的情况下工作，这一点改变了它的适用面。

五种连接方式，数据落点和能力边界各不相同

首次启动时 Conduit 会询问连接方式，之后可以再补其他连接。README 给出的选项是 Open WebUI、Direct、Apple On-Device、Apple PCC 和 Hermes。这五条路径不是同一件事的不同叫法，能力差异写得很清楚。Open WebUI 走自建服务端，功能最全：聊天、文件夹、笔记、频道、工作区、工具、网页搜索、图像生成。Direct 走 OpenAI 兼容端点、LM Studio、Azure 风格 API 版本、原生 Ollama 和 OpenRouter，可以带 API key，也可以在本地端点不带 key。Apple On-Device 走 iOS 26 上的 SystemLanguageModel，离线可用，支持流式、采样控制和 JSON-schema 响应，上下文窗口 4K，但图像输入、推理控制和工具调用都不可用。Apple PCC 走 Foundation Models 框架，需要 iOS 27、Apple Intelligence 可用性和 Apple 管理的 PCC 授权，支持图像输入、推理等级、采样与输出上限、JSON-schema、配额与上下文状态显示，还有一个可选的端侧回退用于 PCC 网络故障，但工具调用未启用。Hermes 走自建代理服务端，可以实时看工具执行、在敏感步骤前审批、让定时代理在后台跑，并且 Conduit 只暴露服务端实际上报的能力。选哪条路，等于选了哪些功能会被砍掉。

流式走 WebSocket，渲染不用 WebView

README 说 token 级流式通过 WebSocket 传输，转录在响应增长时保持位置，固定住的提示词不会移位，长对话加载不会卡住界面。渲染层是原生 Flutter 组件，代码块带语法高亮和复制、预览，Mermaid 图原生渲染，LaTeX 与数学公式，推理、工具调用和代码执行段落可展开，内联引用、来源卡片、后续建议，以及 Chart.js 嵌入。把这些放在一起看，它的取舍是明确的：不靠 WebView 换取渲染一致性，代价是每一种富内容类型都要在 Dart 侧单独实现和维护。Mermaid 和 Chart.js 在 Flutter 里不是免费的，它们意味着额外的解析和绘制代码，也意味着当上游语法扩展时客户端需要跟进。这对长期维护成本有直接影响。

隐私的说法要拆开读

README 的表述是聊天首先存在设备上，没有任何流量经过维护者运营的后端。这句话成立的前提是它真的没有中间服务，从连接方式看，Open WebUI、Direct、Hermes 都指向用户自己的地址，Apple 的两条路径指向 Apple 的模型服务，确实没有第三方中转。API key 和自定义请求头保存在平台安全存储里。需要自己判断的部分是：走 Open WebUI 或 Hermes 时，对话内容仍然会到达你自建的服务端，设备优先不等于端到端加密。走 Apple PCC 时，请求离开设备进入 Apple 的私有云计算，README 没有描述这部分的数据处理条款。Direct 直连第三方 provider 时，内容按该 provider 的规则处理。这些都不是缺陷，但把设备优先理解成完全本地是误读。

构建与许可：GPL-3.0 的实际约束

仓库主语言是 Dart，许可证是 GPL-3.0，README 里指向 docs/BUILDING.md 作为自行构建的入口，但没有在正文里展开构建步骤，因此具体的 Flutter 版本、平台工具链和签名流程需要打开那份文档确认。GPL-3.0 的实际影响是：如果你修改并对外分发这个应用，分发时需要按同一许可提供对应源码。内部自用修改不触发分发义务，但把改过的包放到企业应用商店或交给外部用户就会触发。应用商店上架版本由维护者发布，日常使用不需要处理这些。想自行构建的人还要额外考虑 iOS 签名和 Android 分发渠道的维护成本，这部分不随上游版本自动解决。最近三个版本 v4.1.2、v4.1.3、v4.1.4 集中在 2026 年 8 月下旬到 9 月初，说明迭代节奏较快，锁死某个旧版本自行维护的代价会随时间上升。

什么时候它不合适

第一种情况是你要的是可审计的 Web 界面。浏览器里的 Open WebUI 可以被企业代理、DLP 和终端管理统一管住，原生应用走的是自己的网络栈，管控方式不同。第二种情况是你的工作流依赖工具调用。README 明确写了 Apple On-Device 和 Apple PCC 都不支持工具调用，如果你的核心用法是让模型调工具，这两条路径直接排除。第三种情况是你在 iOS 26 以下的设备上想用端侧模型，那两条 Apple 路径都不满足系统要求。第四种情况是离线场景：只有 Apple On-Device 明确写了离线可用，走 Open WebUI 或 Direct 都需要网络。第五种情况是权限模型。README 说工作区里没有权限的区块干脆不出现，这是以服务端上报的权限为准的设计，如果服务端配置本身有问题，客户端不会替你把关。

和直接用 Open WebUI 网页版的差别在哪

最直接的替代方案就是在手机浏览器里打开自建的 Open WebUI，或者用 PWA 加到主屏幕。这条路零安装成本、随服务端升级自动更新、功能一定是最新的。差别在于：浏览器要处理后台标签页节流，长响应切到后台后回来的状态不可控，而 Conduit 用 WebSocket 维持 token 级流式并保持转录位置；文件与截图进入提示词的路径在原生应用里是系统级选择器，在浏览器里受限于文件输入的实现；语音输入方面 Conduit 提供端侧或服务端语音识别加完整的语音通话模式，浏览器方案依赖系统键盘的听写。反过来说，网页版不需要你为每个平台单独构建和签名，也不会因为客户端版本落后于服务端而缺少新功能。Conduit 的 Workspace 把模型、知识、提示词、工具、技能做成原生界面，这是网页版本来就有的东西换了个壳，真正的增量在流式稳定性、媒体输入和语音这三块。

先验证什么再决定

如果你在自建 Open WebUI，先在手机上装应用商店版本，用真实的服务器地址和反向代理配置走一遍登录，重点看流式在切后台再切回时能不能续上，这是 README 声称解决的核心问题。然后确认你的服务端版本对应的频道、线程和反应功能是否被正确识别，因为 Conduit 只显示服务端上报的能力。如果你打算走 Direct 直连 Ollama 或 OpenRouter，先测一遍带自定义请求头的端点，确认 key 存进安全存储后重装应用是否还在。如果你在评估 Apple 的两条路径，先确认设备系统版本和 Apple Intelligence 可用性，再确认你的用例是否落在被砍掉的那部分功能里。最后，如果你要自行构建，打开 docs/BUILDING.md 按它列的步骤走一遍，构建通过之前不要基于 README 的功能描述做技术选型。

编辑结论

如果你的团队已经在自建 Open WebUI，且痛点是手机上的反代鉴权、后台断流、截图进提示词，Conduit 值得先装应用商店版本试用一周再决定是否自行构建。如果你需要的是浏览器里可审计的 Web 界面、或者依赖工具调用与图像输入，先确认目标 provider 是否支持：Apple On-Device 明确不支持图像输入、推理控制与工具调用，Apple PCC 未启用工具调用。想自行构建，先读仓库里的 docs/BUILDING.md，确认 Flutter 工具链与签名配置能跑通，再评估分发方式与 GPL-3.0 带来的义务。

官方来源

1. cogwheel0/conduit on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases