尧图网页设计 
DeepSeek Harness 是我最近一直在折腾的一个本地模型工作台腾讯开源的 Kuikly 则是我选来选去最终定下的跨端框架。把这两个名字放在一起听起来像是硬凑的技术混搭但七天之后我真的把 Harness 的核心链路搬进了手机里做成了一个可以随时揣兜里的移动控制台。先说一句大实话我不是把整个 DeepSeek Harness 的引擎塞进手机——那既没必要也不现实。大模型推理、任务编排、插件执行这些重活继续留在电脑或服务器上跑手机端只做一件事连接、监控、交互。做到这一点之后你会发现装进口袋的真正含义不是把软件装进手机而是把控制权从桌面上拿下来塞进你的裤兜里。如果你手头也在折腾本地模型工具链或者正纠结用什么跨端框架做一个 AI 工具的前端这篇东西应该能给你一些可抄作业的参考。1. 从一个桌面独占的痛点说起为什么非要把 Harness 塞进手机我最初接触 DeepSeek Harness 0.1.1 的时候其实没对它的桌面端有多大意见。CLI 用起来很直接桌面面板能看任务状态插件机制也够灵活。真正让我难受的点是它默认假设你永远坐在工位前。想一想这几个场景你就明白了我白天在电脑上启动了一个长文本生成任务设置好参数就出门了。结果一整天心里都在犯嘀咕任务跑到哪了有没有报错要不要手动停掉正确答案是——我不知道因为我没带电脑。晚上躺床上刷到一段有意思的提示词想快速在本地模型上试一版。但 Harness 的 CLI 在笔记本上笔记本在书房。算了明天再说。周末想用平板对着同一个模型做一轮对话式调参桌面端的 UI 是鼠标键盘逻辑触屏点起来难受得要命。这些问题本质上是同一个执行没问题但遥控器被绑死了。所以我给自己定的目标很明确不动 Harness 的核心引擎做一层远程控制面让手机在任何有局域网的地方都能连上电脑上的 Harness 服务看任务、发指令、接收流式输出。这层控制面我决定用腾讯 Kuikly 来写一次性覆盖 Android 和 iOS不用维护两套 UI。这篇内容适合谁看第一类是本地模型玩家手里已经有 Ollama、vLLM 这类后端想自己做一个小工具把它们管理起来第二类是工具链开发者想借鉴服务端核心 移动端控制面这种拆分思路第三类是正在调研 Kuikly 的跨端开发者想看看这个框架在实际项目里能不能打。三类读者读完后多少都能拿走点东西。2. DeepSeek Harness 的本质拆解它到底是一个怎样的工作台在动手之前我花了整整一个晚上把 Harness 从里到外翻了一遍。我理解中的 DeepSeek Harness不是一个具体的聊天软件也不是一个模型下载器而是一个围绕本地模型做编排与交互的开放工具链。它把模型连接、任务执行、结果展示、插件扩展这几个环节整合到一个统一入口下。2.1 三个核心能力第一是模型连接层。Harness 本身不内置推理引擎而是通过配置去对接本地模型服务比如 Ollama、vLLM或者 DeepSeek 系列模型的本地部署实例。在 0.1.1 里配置连接本地模型时可以显式开启思考模式这个选项会决定请求是走普通对话逻辑还是走深度推理逻辑。你可以针对不同任务配置不同的模型实例这层抽象让 Harness 变成了一个模型中立的工作台。第二是任务编排层。这是它最有价值的部分。你可以在 Harness 里定义一系列任务每个任务包含提示词模板、模型参数、输出处理方式。跑任务时Harness 负责把这一步的输出接到下一步的输入里完成链条式的执行。桌面端和 CLI 都能发起这些任务任务状态和日志被统一记录方便回溯。第三是插件化入口。CLI、桌面控制台、插件系统这些都是接入层。你要在终端里快速跑一遍流程就用 CLI要看全景状态就开桌面面板要扩展 Harness 的能力就写插件。热词里反复出现的插件打包插件推荐说明这套机制在社区里已经被大量使用。2.2 从架构上看到的移动化机会把这套东西拆开看你会发现它天然适合前后端分离模型推理服务Ollama / vLLM ... ↑ Harness 核心引擎任务编排 / 状态管理 / 日志 ↑ 接入层CLI / Desktop / 插件 / 远程 API核心引擎和接入层之间是有明确边界的。也就是说只要 Harness 核心引擎还在电脑或服务器上运行我完全可以在接入层这一侧加一个新客户端——手机。手机不需要认识模型怎么推理不需要知道任务内部怎么编排它只需要和接入层对话给我任务列表、帮我启动一个任务、把这段输出流式传给我。这里我补充一句以上架构拆解是我基于 0.1.1 版本的实际使用和社区讨论做的合理推断不是官方文档的复述。如果你拿到的版本接口有差异思路仍然成立因为服务端核心 客户端接入这个边界是这类工具绕不开的设计。3. 选型博弈Kuikly 凭什么从 Flutter、RN、Compose MP 里胜出确定要做移动控制面之后第一个摆在面前的问题就是用什么框架写我当时把候选方案列了一圈Flutter、React Native、Compose Multiplatform、腾讯 Kuikly。四个方案我都不是没用过但这是第一次为一个AI 工具链前端做选型衡量的维度不太一样。3.1 四个框架的对比框架语言UI 范式JVM 生态复用包体积社区活跃度FlutterDart自绘 Widget基本为零Kotlin 逻辑无法直接复用中等偏大很高Star 多React NativeJavaScript/TS原生组件桥接有成本需要自己搭桥中等很高背靠大社区Compose MultiplatformKotlinCompose 声明式能复用中等持续升温但仍有磨合期腾讯 KuiklyKotlinCompose 风格声明式能复用中等背靠腾讯示例偏国内市场对普通 App 来说这个表格可能还不足以体现差距。但放到我这个项目里有一项指标直接击穿了所有备选方案JVM 层的逻辑复用。3.2 为什么 Kotlin 生态对我至关重要Harness 的插件系统、CLI 工具链以及我和服务端通信时要复用的数据模型都是用 Kotlin/Java 写的。如果选 Flutter这些我全部要拿 Dart 重写一遍如果选 RN至少得搭一层厚厚的桥性能损耗先不说光是类型转换就够我喝一壶。Kuikly 最大的优势在于它整个 UI 层跑在 Kotlin 上。我可以把 Harness 侧的数据模型直接拉过来做一点点字段适配ViewModel 和仓库层完全用同一套 Kotlin 代码。这不是省一点工作量而是把整个项目的核心逻辑保持在一个语言边界内心智负担小得多。另外还有一点比较实际Kuikly 的 UI 是 Compose 风格的声明式写法写惯了 Compose 的人几乎零成本上手。它不是套壳 WebView也 用Kuikly把DeepSeek Harness装进口袋：移动控制台实践
DeepSeek Harness 是我最近一直在折腾的一个本地模型工作台腾讯开源的 Kuikly 则是我选来选去最终定下的跨端框架。把这两个名字放在一起听起来像是硬凑的技术混搭但七天之后我真的把 Harness 的核心链路搬进了手机里做成了一个可以随时揣兜里的移动控制台。先说一句大实话我不是把整个 DeepSeek Harness 的引擎塞进手机——那既没必要也不现实。大模型推理、任务编排、插件执行这些重活继续留在电脑或服务器上跑手机端只做一件事连接、监控、交互。做到这一点之后你会发现装进口袋的真正含义不是把软件装进手机而是把控制权从桌面上拿下来塞进你的裤兜里。如果你手头也在折腾本地模型工具链或者正纠结用什么跨端框架做一个 AI 工具的前端这篇东西应该能给你一些可抄作业的参考。1. 从一个桌面独占的痛点说起为什么非要把 Harness 塞进手机我最初接触 DeepSeek Harness 0.1.1 的时候其实没对它的桌面端有多大意见。CLI 用起来很直接桌面面板能看任务状态插件机制也够灵活。真正让我难受的点是它默认假设你永远坐在工位前。想一想这几个场景你就明白了我白天在电脑上启动了一个长文本生成任务设置好参数就出门了。结果一整天心里都在犯嘀咕任务跑到哪了有没有报错要不要手动停掉正确答案是——我不知道因为我没带电脑。晚上躺床上刷到一段有意思的提示词想快速在本地模型上试一版。但 Harness 的 CLI 在笔记本上笔记本在书房。算了明天再说。周末想用平板对着同一个模型做一轮对话式调参桌面端的 UI 是鼠标键盘逻辑触屏点起来难受得要命。这些问题本质上是同一个执行没问题但遥控器被绑死了。所以我给自己定的目标很明确不动 Harness 的核心引擎做一层远程控制面让手机在任何有局域网的地方都能连上电脑上的 Harness 服务看任务、发指令、接收流式输出。这层控制面我决定用腾讯 Kuikly 来写一次性覆盖 Android 和 iOS不用维护两套 UI。这篇内容适合谁看第一类是本地模型玩家手里已经有 Ollama、vLLM 这类后端想自己做一个小工具把它们管理起来第二类是工具链开发者想借鉴服务端核心 移动端控制面这种拆分思路第三类是正在调研 Kuikly 的跨端开发者想看看这个框架在实际项目里能不能打。三类读者读完后多少都能拿走点东西。2. DeepSeek Harness 的本质拆解它到底是一个怎样的工作台在动手之前我花了整整一个晚上把 Harness 从里到外翻了一遍。我理解中的 DeepSeek Harness不是一个具体的聊天软件也不是一个模型下载器而是一个围绕本地模型做编排与交互的开放工具链。它把模型连接、任务执行、结果展示、插件扩展这几个环节整合到一个统一入口下。2.1 三个核心能力第一是模型连接层。Harness 本身不内置推理引擎而是通过配置去对接本地模型服务比如 Ollama、vLLM或者 DeepSeek 系列模型的本地部署实例。在 0.1.1 里配置连接本地模型时可以显式开启思考模式这个选项会决定请求是走普通对话逻辑还是走深度推理逻辑。你可以针对不同任务配置不同的模型实例这层抽象让 Harness 变成了一个模型中立的工作台。第二是任务编排层。这是它最有价值的部分。你可以在 Harness 里定义一系列任务每个任务包含提示词模板、模型参数、输出处理方式。跑任务时Harness 负责把这一步的输出接到下一步的输入里完成链条式的执行。桌面端和 CLI 都能发起这些任务任务状态和日志被统一记录方便回溯。第三是插件化入口。CLI、桌面控制台、插件系统这些都是接入层。你要在终端里快速跑一遍流程就用 CLI要看全景状态就开桌面面板要扩展 Harness 的能力就写插件。热词里反复出现的插件打包插件推荐说明这套机制在社区里已经被大量使用。2.2 从架构上看到的移动化机会把这套东西拆开看你会发现它天然适合前后端分离模型推理服务Ollama / vLLM ... ↑ Harness 核心引擎任务编排 / 状态管理 / 日志 ↑ 接入层CLI / Desktop / 插件 / 远程 API核心引擎和接入层之间是有明确边界的。也就是说只要 Harness 核心引擎还在电脑或服务器上运行我完全可以在接入层这一侧加一个新客户端——手机。手机不需要认识模型怎么推理不需要知道任务内部怎么编排它只需要和接入层对话给我任务列表、帮我启动一个任务、把这段输出流式传给我。这里我补充一句以上架构拆解是我基于 0.1.1 版本的实际使用和社区讨论做的合理推断不是官方文档的复述。如果你拿到的版本接口有差异思路仍然成立因为服务端核心 客户端接入这个边界是这类工具绕不开的设计。3. 选型博弈Kuikly 凭什么从 Flutter、RN、Compose MP 里胜出确定要做移动控制面之后第一个摆在面前的问题就是用什么框架写我当时把候选方案列了一圈Flutter、React Native、Compose Multiplatform、腾讯 Kuikly。四个方案我都不是没用过但这是第一次为一个AI 工具链前端做选型衡量的维度不太一样。3.1 四个框架的对比框架语言UI 范式JVM 生态复用包体积社区活跃度FlutterDart自绘 Widget基本为零Kotlin 逻辑无法直接复用中等偏大很高Star 多React NativeJavaScript/TS原生组件桥接有成本需要自己搭桥中等很高背靠大社区Compose MultiplatformKotlinCompose 声明式能复用中等持续升温但仍有磨合期腾讯 KuiklyKotlinCompose 风格声明式能复用中等背靠腾讯示例偏国内市场对普通 App 来说这个表格可能还不足以体现差距。但放到我这个项目里有一项指标直接击穿了所有备选方案JVM 层的逻辑复用。3.2 为什么 Kotlin 生态对我至关重要Harness 的插件系统、CLI 工具链以及我和服务端通信时要复用的数据模型都是用 Kotlin/Java 写的。如果选 Flutter这些我全部要拿 Dart 重写一遍如果选 RN至少得搭一层厚厚的桥性能损耗先不说光是类型转换就够我喝一壶。Kuikly 最大的优势在于它整个 UI 层跑在 Kotlin 上。我可以把 Harness 侧的数据模型直接拉过来做一点点字段适配ViewModel 和仓库层完全用同一套 Kotlin 代码。这不是省一点工作量而是把整个项目的核心逻辑保持在一个语言边界内心智负担小得多。另外还有一点比较实际Kuikly 的 UI 是 Compose 风格的声明式写法写惯了 Compose 的人几乎零成本上手。它不是套壳 WebView也