Evidence at a glance
Open Models Do Not Yet Make the Desktop Act
At Open Source Summit Europe on October 8, 2026, openKylin Executive Director Min Liu delivered a keynote titled “From AI Runtime to System Agents.” He introduced KART, a unified AI runtime, and an execution environment for system-level agents. openKylin is an open-source operating system community originating in China and serving global users. The keynote addressed not how to build another model, but how to connect model capabilities to everyday Linux operations.
That problem has become more concrete as open frameworks and open-weight models have spread. Components such as PyTorch, vLLM, and llama.cpp make it easier to build AI applications, but model capabilities remain disconnected from desktop tasks, AI stacks are fragmented, and hardware-software integration is complex. openKylin argues that an operating system should extend its role beyond managing resources such as CPUs, memory, and files: it should understand user goals and turn them into coordinated, observable system actions. The challenge is not simply getting a system to understand a sentence, but making intent execution a constrained system capability.
A Three-Layer Stack Connects Models, Agents, and Linux
openKylin describes a three-layer architecture. At the bottom, KART and the local inference engine kytensor provide shared inference services. In the middle, an agent execution environment supports KylinBot, Kylin-CUA, and third-party agents. At the top, API tools and desktop GUI skills expose existing Linux capabilities to those agents. Rather than placing every function inside a single assistant, the design separates inference, task execution, and system interfaces so that distinct components can work together.
The value of this separation depends on whether the middle layer can turn plans into real operations while preserving permission boundaries and execution monitoring. The material says that permissions and monitoring will govern agent access to the capability layer, but gives no details about authorization, rollback after failure, confirmation for sensitive actions, or audit records. For now, it is best understood as a system-integration direction, not a fully validated secure execution mechanism. Making actions observable does not by itself make them reliably constrainable.
Desktop Features Change the Entry Point, Not Necessarily the Workflow
In openKylin 3.0, the vision appears in three desktop features. AI Assistant shifts interaction from searching for a feature to stating an intent. Global Intelligent Search moves from location-based lookup to semantic discovery. Intelligent Space organizes information around tasks rather than relying only on folders. Together, they target the interaction entry point, search, and information organization, with the aim of reducing how much users need to know about the system’s internal structure.
Yet substantial engineering work remains between entering an intent and completing a task. Accurate semantic search does not mean an assistant can safely modify files. Organizing information by task also requires the system to decide what is relevant, how to update it, and how users can correct the result. The material describes these features’ roles but provides no evaluation data on task completion, error handling, or user controls. For technical leaders, the question is not whether the interface looks more conversational, but whether the features can share context, define the scope of actions, and hand control back to users when something goes wrong.
RISC-V Results Show Progress, but Leave Questions Open
openKylin is extending its system-level AI work to RISC-V. In a separate lightning talk at the summit, Technical Committee member Jianfeng Li discussed building an AI-ready desktop for RISC-V. The community highlighted RVV vector-extension optimization, heterogeneous computing, and AI runtime enablement. It reported that RVV kernel optimizations delivered a 2–5x speedup for FP32 inference with ONNX Runtime, and said that CPU inference with vLLM is supported on the SpacemiT K3. Delivery options include .deb packages, Python wheels, Conda, and Docker.
These details show work across several layers, from instruction-set optimization to frameworks and distribution formats, but the headline number needs its test conditions. The material does not specify the models, workloads, baseline hardware, or measurement method behind the 2–5x result. Nor does it report vLLM performance on the K3, so the result cannot be generalized to all RISC-V devices. openKylin says it plans to contribute the RVV optimizations and inference-framework enablement upstream. For adopters, the practical course is to validate against target hardware, models, and workloads before deployment, rather than treating one optimization as proof of a complete AI desktop.