Presto 新版系统架构：Modular Runtime + Recipe Layer Stack
一句话架构
Presto 从“桌面 App + 插件页”演化为“常驻控制面 + 可层叠菜谱 + 可替换入口 + 受控能力服务”的本地优先模块化 Runtime。
桌面主程序不再是唯一入口，而是官方 Dashboard / Console；真正的系统核心是常驻后台服务 prestod，它负责解析 Recipe Layer、生成 Desired State、安装与启动插件服务、路由 capability provider、维护 lockfile、暴露 API，并把运行状态反馈给多个入口。
架构边界
该设计借鉴 Docker、Homebrew、NPM、VS Code、Mihomo、K8s、systemd、Terraform、Nix、Git 的工程思想，但不把 Presto 做成通用编排平台。
核心约束：Presto 只编排 Presto 生态内的 package、capability、provider 和 service；Recipe 是声明式编排，不是任意脚本执行器。
常驻控制面
prestod 是唯一事实来源，负责 API、状态、调谐和服务生命周期。入口可替换Desktop、CLI、HTTP API、MCP、第三方 Dashboard 都只是 client。
菜谱可层叠Recipe 像 Docker layer 一样叠加，后层覆盖前层，最终生成 resolved profile。
能力受控服务化插件服务按 capability contract 暴露能力，由 provider router 选择和调用。
1. C4 Context：系统上下文
Presto 作为本地 Modular Runtime 的上下文图
关注外部角色、入口、分发源与运行时边界
Entry Plane / 入口平面
Presto Desktop官方控制台与工作台入口
CLI批处理、脚本、CI 调用
HTTP / RPC API本机或受控远程调用
Third-party Dashboard重新设计的前端入口
↓ API calls
↓ API calls
↓ API calls
↓ API calls
Control Plane / 控制平面
prestod API Server统一入口、鉴权、状态查询、事件流
Recipe Resolver合并菜谱层，生成期望状态
Service Controller安装、启动、停止、重启、调谐
Capability Router根据 provider 选择路由能力调用
↓ reconcile
↓ resolve
↓ manage
↓ route
Capability Plane / 能力平面
Toolchain ServicesTypst、Tinymist、Pandoc、OCR
Workflow Services公文、教案、论文、合同流程
Provider ServicesAI、导出、转换、诊断 provider
Resource Packages模板、字体、样式、素材
↑ packages
↑ metadata
↑ recipes
↑ updates
Distribution Plane / 分发平面
Plugin Registrypackage index, manifest, checksum
Recipe Source / Tap官方菜谱、组织菜谱、个人菜谱
Package Cache本地缓存、预下载、版本并存
Lockfile可复现版本、provider、integrity
2. C4 Container:prestod 内部容器图
常驻后台 Runtime 的主要内部组件
控制面与数据面分离，Desktop 只是 client
Desktop ConsoleProfile、Recipe、服务、日志、Plan Preview、Rollback
CLI / Automation导入配置、批量导出、运行 job
Third-party UI通过授权连接 Runtime API
API ServerREST/RPC、事件流、client session
State Storedesired state, actual state, history
Recipe Resolverlayer merge, override, disable, profile resolve
Plan Engineinstall/start/change/remove 预览
Registry Clientpackage、recipe source、更新索引
Capability Routerprovider group, fallback, selector
Service Controllerlifecycle, health probe, restart, idle TTL
Runtime Adaptersnative process, docker, wasm, external
Permission Gate调用前校验，后续安全专项展开
Observabilitylogs、timeline、metrics、doctor
typst-serviceprovider:
typst.compile@1tinymist-serviceprovider: preview / diagnostics / source-map
workflow-service公文、教案等 workflow action
exporter-servicePDF、DOCX、HTML、PPTX 等导出
external provider远程 AI / 组织服务 / 已有服务
3. Recipe Layer Stack：菜谱层叠模型
Docker-like layer stack，不是逐个菜谱机械启动
层叠决定配置覆盖，服务启动由最终依赖图决定
Recipe Layers
official/base
基础能力、默认 provider、基础 UI entry
基础能力、默认 provider、基础 UI entry
official/typst-writing
Typst, Tinymist, PDF exporter
Typst, Tinymist, PDF exporter
school/gongwen-standard
组织模板、导出规则、默认工作流
组织模板、导出规则、默认工作流
user/my-preferences
个人 provider、预热策略、禁用项
个人 provider、预热策略、禁用项
workspace/presto.yaml
项目级 capability 与 lockfile 偏好
项目级 capability 与 lockfile 偏好
→
Resolved Desired State
所有菜谱层合并后的唯一期望状态
- required capabilities
- selected providers
- service runtime policy
- entrypoints
- lockfile candidates
→
Service Graph
真实启动模型，按依赖拓扑与健康状态调谐
- prewarm resident services
- start workspace services
- keep lazy services idle
- run job services on demand
4. 关键运行流程：导入菜谱并应用
Plan / Apply / Reconcile 流程
借鉴 Terraform、Vercel/Railway 的变更预览与回滚体验
1Import Recipe用户订阅官方菜谱、导入组织菜谱或启用个人菜谱。
2Resolve Layers按 layer order 合并，后层覆盖前层，生成 desired state。
3Plan Preview展示将安装、启动、停止、覆盖、降级、回滚的信息。
4Apply确认后写入 state store 和 lockfile，由 controller 接管。
5Reconcile安装 package，启动 service，执行 health probe，更新 actual state。
6Notify ClientsDesktop/CLI/API 通过事件流看到 ready、warming、degraded。
5. 服务生命周期状态机
systemd-like service lifecycle
服务状态必须可见、可诊断、可恢复
Installed
→
Starting / Warming
→
Ready
Idle
↔
On Demand Job
→
Stopped
Failed / Degraded
→
Restarting
→
Ready
服务模式包括 resident、workspace、document、onDemand、job、external、container。启动延时通过常驻 prestod、懒启动、预热、idle TTL、progressive capability 和可视化 warming 状态处理。
6. 核心概念表
| 概念 | 职责 | 类比来源 | Presto 中的约束 |
|---|---|---|---|
| Package | 可安装、可签名、可缓存的分发单元。 | NPM package / Homebrew formula | 来自可信 registry，不在用户配置中任意指向本地命令。 |
| Capability | 版本化能力协议，包含输入、输出、错误、事件、取消语义与 conformance tests。 | LSP / OpenAPI / VS Code provider | 依赖解析基于能力协议，不基于插件血缘或 fork 关系。 |
| Provider | 某个 package 对某个 capability 的实现声明。 | VS Code default formatter / Terraform provider | 可被用户、workspace、recipe 或官方默认选择与覆盖。 |
| Service | 运行时实体，可暴露一个或多个 provider。 | systemd service / K8s Pod / Docker container | 生命周期由 prestod 管理，支持 native、docker、wasm、external runtime class。 |
| Recipe | 用户可理解的组合单位，声明一组 package、capability、provider、entrypoint 和 runtime policy。 | Homebrew Bundle / Clash profile / Docker layer | 只能声明受控 desired state，不能执行任意脚本。 |
| Profile | 一组已启用 Recipe Layers 合并后的用户运行环境。 | Mihomo profile / Vercel environment | 可导入、导出、切换、回滚，并生成 lockfile。 |
7. 配置与 Lockfile 示例
Recipe 声明示例
apiVersion: presto.dev/v1
kind: Recipe
metadata:
name: official/gongwen-writing
title: 公文写作包
requires:
capabilities:
- document.render.typst@1
- document.export.pdf@1
- workflow.gongwen.assistant@1
providers:
document.render.typst@1: presto/typst
typst.preview.live@1: presto/tinymist
packages:
required:
- presto/typst
- presto/gongwen-template-pack
recommended:
- presto/tinymist
runtimePolicy:
presto/tinymist:
mode: workspace
activation:
- onWorkspaceOpen
- onCapabilityRequest
idleTimeout: 10mResolved Profile 摘要示例
profile:
layers:
- official/base
- official/typst-writing
- school/gongwen-standard
- user/my-preferences
resolved:
providers:
typst.compile@1: presto/typst
typst.preview.live@1: presto/tinymist
ai.text.generate@1: presto/deepseek
services:
typst-service:
mode: resident
state: ready
tinymist-service:
mode: workspace
state: warming
pdf-exporter:
mode: onDemand
state: idle
lock:
presto/typst: 0.13.1#sha256:...
presto/tinymist: 0.14.18#sha256:...8. MVP 收敛建议
| 阶段 | 目标 | 范围控制 |
|---|---|---|
| 阶段 1：插件市场 MVP | 拆出 Typst/Tinymist，建立 manifest、capability、provider、default pack。 | 不开放完整 UI DSL，不做第三方 Dashboard。 |
| 阶段 2：prestod + Runtime Console | 常驻 core、服务状态、启动/停止、日志、配置导入导出。 | 单机单控制面，不做多节点与动态服务发现。 |
| 阶段 3：Recipe Layer | 官方菜谱、组织菜谱、用户菜谱、workspace lock、层叠覆盖。 | Recipe 只声明受控能力和策略，不允许任意 command。 |
| 阶段 4：多入口 | Desktop、CLI、API、MCP、第三方 Dashboard 连接同一 runtime。 | 入口是 client，不拥有系统事实来源。 |
| 阶段 5：高级 runtime class | Docker、remote、wasm 作为可选运行后端。 | 不是基础依赖，不把 Presto 变成通用 PaaS。 |
9. 结论
推荐定位：Presto Core 是本地常驻控制面；Presto Desktop 是官方控制台与默认入口；插件服务是受控 capability provider；Recipe 是面向用户的组合与订阅单位；Registry 是可信分发平面。
复杂度控制：采用这些架构思想作为北极星，但 MVP 必须收敛为“单机、单控制面、受控 package、声明式 Recipe、可观测 service lifecycle”。Presto 不做通用本地编排平台，只编排 Presto 生态内的创作、排版、模板、导出、AI 与工作流能力。