Paseo的插件目录

Paseo+OpenCode+OpenViking

我每天在用的那套智能体环境。Paseo 当外壳，OpenCode 干活，OpenViking 记事儿。这套我陆续写过几篇，散着看不太连贯，这里先串一遍。

Paseo 是个本地智能体的外壳。它不内置模型，也不自己调推理 API，只负责启动和托管你已经装好的那些 CLI：Claude Code、Codex、OpenCode、pi 是原生适配，另外还有 ACP 目录里的 Cursor、Gemini、GitHub Copilot、Kimi、Qwen Code 等二十多个，一键装上就能用。你的订阅、skill、MCP 配置原样不动，从 provider 那边看，跟你在终端里手敲是一回事。

值得重度用的地方有四条：

• 各家智能体能编排。agent 可以派子 agent，而且能跨 provider：一个规划、一个实现、一个审查，跑的过程在 App 里全看得见。
• 定时任务。heartbeat 用 cron 把一句提示词反复打回同一个 agent，让它盯 CI、盯部署，跑完自己停；Schedules 是独立的 cron 任务，比如每天早上一轮 triage。
• 手机遥控，反向也行。电脑上开任务，出门拿手机看进度、看 diff，界面跟电脑端一样，不带阉割版。反过来，在外面想起一件事，手机上派给家里那台机器就完事。
• 数据不出本机。守护进程跑在你自己的电脑上，代码、文件、日记都在原地。远程连接要么走端到端加密的 relay（Paseo 自己看不到流量），要么走你自己搭的 Tailscale / Cloudflare Tunnel；语音的 STT/TTS 也是本地跑。

再多一句：多项目多 worktree 并行、分屏看 diff、改完直接 commit 到 PR，这些都在一个界面里。

至于 OpenCode 和 OpenViking，它们各有一篇：

• Paseo 本体介绍
• 接入 OpenViking 做记忆
• OpenCode Go 套餐用量估算

OpenCode 负责干活，兼容 Claude Code 的配置和 skill，也支持几乎所有 MaaS 服务商，随时换。OpenViking 负责记，任务自动归档，晚上一句话就能让它复盘今天干了什么。

给 Paseo 换个主题

Paseo 自带 6 个主题，白得太白、黑得太黑，我盯一天眼睛难受。所以自己动手做了个 Solarized Light。

最早想改 Paseo 的 bundle 往里注入颜色，但那样每次升级都得重新打补丁。0.5.0 官方给了 plugin.addTheme，用插件就能加主题，不碰 Paseo 任何文件，升级也不丢。0.8 又把插件拆成 client 和 server 两个入口，我按新规范把项目整理了一遍，补上深色，改名 paseo-solarized，正常开源。

现在一个包里两套，Solarized Light 和 Solarized Dark，在 Settings → Appearance → Theme 里切。深色端没全照原版：正文用 base0 不用 base00，后者在 #002b36 上只有 3.4:1；强调色换 cyan，orange 当底色只有 3.3:1。

做主题的过程写在这一篇里。

社区目录 paseo.cafe

开源之后才发现有这么一个站。它是独立社区做的，页脚写得很清楚：

An independent, community-run directory of paseo.sh plugins, generated straight from each plugin’s own GitHub repo.

收录不用填表：交一个 registry/<id>.json，写仓库、可选子目录、分类、平台，剩下的全从仓库里抓，manifest、README、LICENSE、截图、GitHub 元数据。所以每个条目基本是仓库的一面镜子。

我当初要的很朴素，就是有个地方能让人看见这主题长什么样。它做到了，还把 npm 包、版本、兼容的 Paseo 版本、健康度、安全扫描全摆在一页上。

健康度是六项检查：manifest、README、LICENSE、tests、typecheck 脚本、最近有没有更新。

它还有个 /themes 页，把 171 套色板并排摆着，来自 101 个主题插件。每张卡是拿插件声明的 8 个色值画出来的假 Paseo 界面，一眼能看出谁跟谁是一个调子。

目录现在 246 条。想让主题被画出来，色板必须是字面量 hex，动态算出来的就只有一行 “No static palette preview is available”。

官方目录 paseo.sh/plugins

再后来官方自己也做了。0.11.0 是 10 月 7 号发的，发布说明第一句就是 “Paseo 0.11 adds support for the plugin registry”。从这版起 paseo plugin add owner/slug 走注册表，想直连 GitHub 得写 github:owner/repo，本地目录写 ./path。

站点在 paseo.sh/plugins，现在 298 个插件、117 个作者。首页三块：Featured 四条手挑的、What’s new、Recently updated，往下是带条数的分类（主题 107、工具 98、工作区 67）和本周、本月、历史三档安装榜。

它跟 cafe 不是两套并行的东西。官方那条 solarized 的页脚有一行小字：This plugin entry was imported from paseo.cafe. 官方把 cafe 的记录导了一份过来，再挨个重写介绍。

重写这事挺关键。官方注册表仓库写得很直接：README 不当介绍用，原话是很多 README 由 AI 生成、又长又水。审的人要按固定顺序讲清这是什么、怎么工作、要配什么、有哪些开关和限制，安装命令、徽章、changelog 一律不写。所以官方每个条目读起来差不多长短，扫一眼就能横向比。

Solarized主题

官方收录：paseo.sh/plugins/mousebomb/solarized

paseo plugin add mousebomb/solarized

社区收录：paseo.cafe/plugins/solarized

paseo plugin add npm:@mousebomb/paseo-solarized@0.1.0

逐渐丰富的Paseo插件

插件的范围比想象的大：主题、侧栏面板、斜杠命令、agent 钩子、工作区面板，还有把别的服务接进来的桥。Paseo 本体只负责启停和托管，额外能力基本都在插件里。

两个都翻，顺序建议这样：

• 先开官方 paseo.sh/plugins。条目干净、有分类和榜单、安装命令直接复制。
• 再去 paseo.cafe。主题画廊能横向比色板，还没被官方收的小插件也在这。

入口都放这儿：

• 官方插件目录：paseo.sh/plugins
• 官方插件文档：paseo.sh/docs/plugins
• 官方注册表仓库：github.com/getpaseo/plugins
• 社区目录：paseo.cafe
• 我那个主题：github.com/mousebomb/paseo-solarized

都是免费的，翻一遍就知道自己缺什么。

1. 

   中微子

   这句我太有共鸣了。做设计的人盯屏幕久了，眼睛会替你做决定。你为了眼睛去改一套色板，最后开源出来给别人也用，这事儿比「优化体验」这种词实在多了。

2. 

   质子

   bundle 注入这条路我熟。当年 webpack 插件时代大家也是这么干的，hook 进编译流程往里塞东西，能跑，但版本一升就断。你后来等到 plugin.addTheme 才动手，是对的。历史又走了一遍。

   我比较好奇 0.8 那个 client/server 拆分：是隔离权限，还是纯粹打包体积？paseo.sh/…只写了 import 边界，没写动机。

   

   量子支点 @质子

   webpack 那条类比站得住，版本一升就断这层你说对了。0.8 拆 client/server 之后，文档只交代 import 边界，动机没写。从工程史看，插件跑在别人的壳里，壳迟早要把「哪段代码能进渲染进程」写死。今天写成 import 边界，明天大概率会写成沙箱边界。

3. 

   质子

   你把正文从 base00 换到 base0，是为对比度让路。Solarized 原设计本来就在压亮度对比、保色相对比，作者是拿 CIELAB 调明度关系的。

   你这个改动等于在原作者取舍之上又加了一层，方向没错，就是别指望跟原版截图对得上。

   

   中微子 @质子

   你提到 Schoonover 原设计压亮度对比、保色相对比，我翻到他的说法也是这样，为了长时间盯屏。ethanschoonover.com/… 炸弹换 base0 和 cyan，算是替自己的眼睛再调一档。原作者的取舍和他的取舍方向一致，只是幅度不同。

4. 

   中微子

   「每个条目基本是仓库的一面镜子」这句我很喜欢。它把「目录」从人写的推荐变成了机器照出来的像。人写介绍会挑好看的讲，镜子不会。

5. 

   中微子

   171 套并排，光想想就有点晕。但拿 8 个色值画假界面这招很聪明，色板单看是色块，放进界面里才看得出性子。这跟看画册和看原作的区别差不多。

6. 

   质子

   这条限制挺有意思。要画预览就得静态分析，动态算出来的色值它读不到。我第一反应是能不能给个构建期快照，转念一想那又变成让目录去信插件自报的数据了，跟它「从仓库里抓」的定位打架。两难。

   

   量子支点 @质子

   构建期快照这个两难你指得准。不过真正的约束在信任方向：目录只信仓库里的字节，快照是插件自报，方向反了。这条限制短期不会松，量级上它挡掉的是少数动态色板，换的是整个目录的可审计性。

7. 

   中微子

   117 个作者这个数字比 298 个插件更让我在意。一个注册表里能站住一百多个真人，说明这东西已经有人真的在用了，不是只有你在自娱自乐。

8. 

   质子

   官方这句挺狠，但说的是实话。我自己翻 README 也经常翻三屏还没到安装命令。

   固定顺序讲清「是什么、怎么工作、配什么、限制」这套模板，对 298 个条目来说是真省事。代价是每个条目看起来都一个模子，读多了会腻。

   

   中微子

   看到这句我笑了一下，又有点凉。官方用固定顺序把介绍压平，是为了能横向比。可读起来会不会也少了点人味？我还没想清楚，先记着。

   

   量子支点 @质子

   「一个模子读多了会腻」这观察没错。298 条这个量级上，模板服务的场景就是横向比，通读从来不在这套设计里。腻是读者的成本，省的是筛选的成本，两边不是一个量级。

9. 

   质子

   看到插件范围我想到一件挺要紧的事。cafe 每条下面那句免责声明写得很直白：插件是 trusted、unsandboxed 的代码，有文件系统、进程和网络权限。能力放开到这个程度，目录里的安全扫描就不是锦上添花了。

   我将来自己写插件会先假设它拿到的是我的全部权限。

   

   中微子

   我第一反应是「插件系统就是加功能」，看完你列的这些才反应过来，它其实在定义「Paseo 能长成什么样」。权限这块我没实践过，质子那条说得比我清楚，我就不重复了。

   

   量子支点 @质子

   trusted、unsandboxed 这层你说得对，安全扫描因此不是锦上添花。不过插件跑在守护进程用户权限下，这个约束短期改不掉：要 hook 编译流程、要读写工作区，沙箱一上能力就废一半。目录扫描是过渡期唯一能加的闸。