2026 启动器生态观察兼容层 MCP 双轮驱动平替正在变成生态【免费下载链接】tinycastTinycast — a tiny, fully native macOS launcher, hotkeys, and clipboard history.项目地址: https://gitcode.com/GitHub_Trending/ti/tinycast启动器这个品类的竞争在 2026 年发生了一次实质性的范式转移。过去几年市场上出现了一批以Raycast 平替自居的开源工具比拼的维度是内存占用、命令数量、界面手感——本质上是在同一个功能表格里逐行勾选。而 TinycastREADME.md给出了一个不同的答案它不满足于复刻功能而是选择了兼容既有生态——原生运行 Raycast 扩展、原生对接 MCPModel Context Protocol工具调用再配合从 Raycast 一键导入数据。当平替开始直接消费别人积累的扩展资产和 AI 工具协议时它就不再是替代品而是新生态的起点。这篇文章结合仓库源码拆解这双轮驱动的具体实现以及它揭示的 2026 年启动器赛道格局。兼容层把别人的扩展生态变成自己的运行时Tinycast 最核心的工程决策藏在 Scripts/raycast-runtime/ 这个目录里。这里维护的不是一个迷你解释器而是一整套完整的 Raycast 扩展运行时同一个package.json 预构建 CommonJS bundleTinycast 直接原生渲染成 SwiftUI 面板没有 Electron、没有浏览器、没有 Node.js。这个运行时本身是一个压缩后约 200KB 的生成文件 Tinycast/Resources/RaycastRuntime.generated.js由 Scripts/raycast-runtime/build.mjs 构建并提交进仓库——也就是说构建 Tinycast 本身永远不需要 Node。它在 JavaScriptCore 上运行macOS 系统自带嵌入成本为零二进制体积内部塞进了 React 19、react-reconciler、完整的raycast/apishim以及一批 Node 内建模块的真实 polyfill。入口文件 Scripts/raycast-runtime/src/index.js 展示了整个运行时的边界设计Swift 只调用__tinycast暴露的几个方法boot、start、dispatch、popNavigation、settle、fireTimer、stopReact 和react/jsx-runtime由运行时自己注册扩展 bundle 里所有 external 的依赖react、raycast/api、node:fs等都由模块注册表接管defineModule(react, reactModule); defineModule(react/jsx-runtime, jsxModule); defineModule(raycast/api, raycastApi); defineModule(react-dom, { render: () { throw new Error(react-dom is not available — Tinycast renders extensions natively.); }, ... });两层翻译让 React 树变成原生视图要让一个为浏览器/Electron 写的组件树落到原生 SwiftUI 上需要两层巧妙的翻译机制都由 Scripts/raycast-runtime/src/reconciler.js 和 Scripts/raycast-runtime/src/api/components.js 实现__slotRaycast 的组件通过 props 传递元素actions{ActionPanel/}、detail{List.Item.Detail/}、metadata{…}而 React 从不渲染躺在 props 里的元素。每个 shim 组件把这些 props 重新发射为__slot子节点序列化时再折叠回父组件的 props——这样这些元素内部的 hooks 依然正常工作Swift 收到的是一棵结构化 JSON 树。{$fn: nodeId:propName}函数 props 变成可派发的句柄。handler 表在每次 commit 时重建保证一个派发总能到达最新渲染产生的回调。Swift 侧 Scripts/raycast-runtime/src/host.js 定义了 JS→Swift 的唯一接缝分两种调用风味异步invoke走主 actor剪贴板、toast、窗口控制、fetch、execSwift 稍后通过__tinycast.settle回答JS 线程从不阻塞在 UI 上同步invokeSync只服务 Node shimfs.readFileSync、execSync、createHash、gunzipSync因为 Swift 完全在 JS 队列上处理它们不会与主 actor 死锁。覆盖到什么程度缺口又有多诚实兼容性的真实水准以实测数据为准。docs/features/extensions.md 记录了在开发机上对真实 Raycast 里安装的 37 个扩展的测量结果32 个扩展 / 147 个 view 命令中的 114 个可以完整启动并渲染且可通过 Scripts/raycast-runtime/test.mjs 和Scripts/run-tests.sh ext-test复现。支持面包括完整的组件集List/Grid/Detail/Form/ActionPanel/Action及全部便捷变体、系统 APIClipboard、LocalStorage、Cache、environment、getPreferenceValues、showToast、confirmAlert等、Node 内建模块path、fs、os、child_process、crypto、zlib、http/https、stream、buffer、url等甚至还有两个以小博大的实现WebAssemblycompile/instantiate走同步构造器跑通 JavaScriptCoresql.js、Zotero 这类重度依赖 WASM 的扩展因此能加载。.local域名解析Scripts/raycast-runtime/src/dgram.js 里那个 UDP socket 从来不碰网络——它解码 mDNS 查询转给系统getaddrinfo解析再编一个应答包发回去。Home Assistant 的默认地址homeassistant.local就靠这个跑通且因此不需要任何组播 entitlement 或本地网络弹窗。更值得注意的是缺口处理的态度AI、BrowserExtension、WindowManagement三个命名空间被声明为不支持但导入它们没问题调用时会抛出一个写明原因的错见 Scripts/raycast-runtime/src/api/index.js 的rejectingNamespace而不是静默降级。这种显式报错优于隐性失效的边界哲学正是兼容层能赢得开发者信任的关键——用户可以验证哪些能用、诊断哪些不能用而不必在无声的 bug 里猜。安装、更新与深链一条完整的生态通道兼容层不只是运行时还包括一套完整的安装渠道docs/features/extensions.md 列出四条路径——搜索 Raycast Store 直接安装已构建的 bundle零编译、从 GitHub 源码在本地构建自动选 pnpm/Bun/Yarn/npmray build -e dist直接产出、从本地 Raycast 导入已构建的 bundle零网络以及从文件夹添加。Tinycast 甚至注册了raycast、com.raycast和tinycast三个深链 schemeraycast://extensions/owner/extension/command可以从浏览器或其他应用直接运行已安装命令tinycast://则保证自家链接不依赖 Raycast 是否抢到 scheme。菜单栏命令原生NSStatusItemNSMenu渲染和no-view后台刷新interval调度、指数退避、失败回滚也一并覆盖。这套通道意味着一个扩展开发者为 Raycast 生态写的东西可以原封不动地成为 Tinycast 生态的一部分——这就是兼容层即生态位的底层逻辑。MCP把工具调用协议变成 AI 能力的统一入口如果说兼容层让 Tinycast 继承了 扩展生态那么 MCP 支持则让它接入了一个正在爆发的工具生态。docs/features/mcp.md 详细记录了完整的 MCP 客户端实现既可以连接远程 HTTP 端点也可以拉起本机 stdio 子进程服务器服务器按句柄命名空间隔离slug前缀模型按需调用。三种运输方式一套安全模型两种传输都走同一个 JSON-RPC 2.0 编码器MCPProtocol只是成帧不同MCPHTTPTransport每消息一个 POST或 SSE 流MCPStdioTransport走子进程 stdin/stdout 的换行分隔协议超时统一为 15 秒、tools/call放宽到 60 秒。命令的查找交给Platform/ExecutableLocator先问登录 shell 再走 PATH——因为 GUI 应用继承的是 Finder 的 PATH上面根本没有npx、uvx和node。安全边界是这个模块最值得称道的部分默认全关mcpEnabled关闭时完全关闭——不建连接、不驻留进程、不对模型暴露任何工具。mcpServers与开关一起被排除在设置备份之外因为服务器列表既是可执行代码的来源也是聊天上下文的去向一个导入不能替另一台 Mac 决定连接什么。凭据只在登录 Keychain服务器配置持久化在UserDefaults里的只是端点、认证模式、header 名、命令和参数真正的 secret 一律进KeychainSecretStore.mcpSecrets绝不进入日志、错误或备份。远程端点强制 HTTPS复用 AI 提供商的AIEndpointPolicy.validate明文 HTTP 仅对localhost/127.0.0.1/::1开放。OAuth 全链路PKCE S256、RFC 9728 资源元数据发现、RFC 7591 动态客户端注册、回调只绑定127.0.0.1:4962、拒绝一切跨源重定向——改个 URL 不能把旧 token 借给新端点。信任、限流与把工具调用当内容每次对话的首次工具调用会触发一个三方对话框Always Allow持久化/Allow This Chat仅本次会话/Dont Allow拒绝这一次Escape 永远不能持久化决定.never只能在设置里设置。被拒绝的调用不会抛错而是以AIToolResult的形式回到模型那里让它读得懂、绕得开。每一轮工具循环有三重限制docs/features/ai.md轮数上限AIToolRounds10/25/50/100/无限默认 25、单次结果体积上限、整轮结果总量上限。工具名通过MCPToolName规范化为slug__tool截断到 64 字符——这是 OpenAI 的硬上限。双向的角色切换谁跑循环取决于路由架构上最优雅的一点是谁执行 MCP 循环完全由路由决定。在 API 路由上OpenAI、Anthropic、Gemini、OpenRouterTinycast 自己是 MCP 客户端AIToolLoopProvider作为装饰器包装底层 provider 跑循环而在 Codex 和 Claude 路由上vendor CLI 自己是 MCP 客户端Tinycast 负责提供服务器并应答它的征询。这里有一个极其硬核的细节Codex 通过-c mcp_servers.tinycast-handle注入服务器同时按名字禁用用户~/.codex/config.toml里自己配置的服务器——因为如果不显式禁用用户自己的服务器会在 Tinycast 线程里启动而CodexTurnRunner对此完全看不见。Claude 则用--strict-mcp-config加每轮临时写入的0600配置文件把工具权限问题通过control_request通道回传给 Tinycast 的信任对话框。整个过程只有 Settings 能改变既定决定updatedPermissions永远不会发出。从平替到生态扩展即生态的路径现在可以把两条轮子并起来看了。Tinycast 的生态位策略可以概括为三句话数据层兼容Raycast 导入、扩展层兼容Raycast 运行时、协议层开放MCP。数据层的代表性动作是 docs/features/raycast-import.md 描述的.rayconfig解密导入Raycast v2.x 导出文件是RAYCFG3容器AES-256-GCM 负载 scrypt 密钥派生N16384, r8, p1Tinycast 在 Service/RaycastDecoder.swift 里完整实现了解密与字段映射Snippets、Quicklinks、剪贴板历史、热键、设置一次性迁移。配套地自有数据以单个.tinycast文件打包docs/features/backup.md五个可勾选类别设置与快捷键、剪贴板历史、Snippets、笔记、启动器学习数据且明确排除扩展、AI 聊天历史与 Keychain 材料——扩展是第三方代码与第三方数据聊天历史和 API 密钥留在产生它们的 Mac 上。这三点共同回答了平替这个词为什么会过时平替比的是功能清单生态比的是接入成本。当 Tinycast 能原生运行 114/147 个 Raycast 命令、能直接搜 Raycast Store 安装、能解密用户的 Raycast 数据迁移时从 Raycast 迁到 Tinycast的成本从重新配置一切降为几分钟导入。兼容层抹平的是迁移摩擦这是任何功能清单都替代不了的。MCP 让工具能力不被应用内建锁死。2026 年的 AI 启动器竞争本质是谁能调用的工具最多。Tinycast 的选择是拥抱 MCP 这个开放协议让文件系统、数据库、开发工具等一切 MCP 服务器都成为自己 AI 聊天的能力延伸——而且对 Codex/Claude 两个别人家的客户端也主动供服务器姿态是协议优先而不是自家优先。原生与零依赖是生态的信任底座。全 Swift 6、零第三方依赖、无遥测、常驻内存低于 100MBREADME.md这保证了运行第三方扩展这个在别处需要用户下很大决心的动作在这里的心理成本足够低——再加上 AGPL-3.0 开源、可审计、可贡献CONTRIBUTING.md 甚至给每个 PR 规定了内存预算。由此回看 2026 年的启动器赛道格局正在分化成两类玩家一类继续在功能矩阵里内卷比拼谁的内建命令更多另一类以 Tinycast 为代表选择兼容别人的生态、开放自己的协议用扩展兼容层降低迁移成本、用 MCP 接入更大的工具网络把自己变成一个可以自举生长的节点。当平替可以消费前一个生态的全部资产并且通过开放协议接入下一个生态时它已经不再是替代品——生态从来不是从零长出来的而是从兼容与开放里长出来的。Tinycast 的路线图印证了这一点扩展运行时、MCP 客户端、Raycast 导入、备份互操作四个方向没有一个是重造轮子全部是接住轮子并转起来。这或许就是 2026 年启动器生态观察最有价值的结论开源启动器的竞争已经从功能之争变成了接口之争、协议之争、生态之争。【免费下载链接】tinycastTinycast — a tiny, fully native macOS launcher, hotkeys, and clipboard history.项目地址: https://gitcode.com/GitHub_Trending/ti/tinycast创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/10 13:24:53 · 阅读 1.2k 2026 启动器生态观察：兼容层 + MCP 双轮驱动，‘平替‘正在变成‘生态‘
2026 启动器生态观察兼容层 MCP 双轮驱动平替正在变成生态【免费下载链接】tinycastTinycast — a tiny, fully native macOS launcher, hotkeys, and clipboard history.项目地址: https://gitcode.com/GitHub_Trending/ti/tinycast启动器这个品类的竞争在 2026 年发生了一次实质性的范式转移。过去几年市场上出现了一批以Raycast 平替自居的开源工具比拼的维度是内存占用、命令数量、界面手感——本质上是在同一个功能表格里逐行勾选。而 TinycastREADME.md给出了一个不同的答案它不满足于复刻功能而是选择了兼容既有生态——原生运行 Raycast 扩展、原生对接 MCPModel Context Protocol工具调用再配合从 Raycast 一键导入数据。当平替开始直接消费别人积累的扩展资产和 AI 工具协议时它就不再是替代品而是新生态的起点。这篇文章结合仓库源码拆解这双轮驱动的具体实现以及它揭示的 2026 年启动器赛道格局。兼容层把别人的扩展生态变成自己的运行时Tinycast 最核心的工程决策藏在 Scripts/raycast-runtime/ 这个目录里。这里维护的不是一个迷你解释器而是一整套完整的 Raycast 扩展运行时同一个package.json 预构建 CommonJS bundleTinycast 直接原生渲染成 SwiftUI 面板没有 Electron、没有浏览器、没有 Node.js。这个运行时本身是一个压缩后约 200KB 的生成文件 Tinycast/Resources/RaycastRuntime.generated.js由 Scripts/raycast-runtime/build.mjs 构建并提交进仓库——也就是说构建 Tinycast 本身永远不需要 Node。它在 JavaScriptCore 上运行macOS 系统自带嵌入成本为零二进制体积内部塞进了 React 19、react-reconciler、完整的raycast/apishim以及一批 Node 内建模块的真实 polyfill。入口文件 Scripts/raycast-runtime/src/index.js 展示了整个运行时的边界设计Swift 只调用__tinycast暴露的几个方法boot、start、dispatch、popNavigation、settle、fireTimer、stopReact 和react/jsx-runtime由运行时自己注册扩展 bundle 里所有 external 的依赖react、raycast/api、node:fs等都由模块注册表接管defineModule(react, reactModule); defineModule(react/jsx-runtime, jsxModule); defineModule(raycast/api, raycastApi); defineModule(react-dom, { render: () { throw new Error(react-dom is not available — Tinycast renders extensions natively.); }, ... });两层翻译让 React 树变成原生视图要让一个为浏览器/Electron 写的组件树落到原生 SwiftUI 上需要两层巧妙的翻译机制都由 Scripts/raycast-runtime/src/reconciler.js 和 Scripts/raycast-runtime/src/api/components.js 实现__slotRaycast 的组件通过 props 传递元素actions{ActionPanel/}、detail{List.Item.Detail/}、metadata{…}而 React 从不渲染躺在 props 里的元素。每个 shim 组件把这些 props 重新发射为__slot子节点序列化时再折叠回父组件的 props——这样这些元素内部的 hooks 依然正常工作Swift 收到的是一棵结构化 JSON 树。{$fn: nodeId:propName}函数 props 变成可派发的句柄。handler 表在每次 commit 时重建保证一个派发总能到达最新渲染产生的回调。Swift 侧 Scripts/raycast-runtime/src/host.js 定义了 JS→Swift 的唯一接缝分两种调用风味异步invoke走主 actor剪贴板、toast、窗口控制、fetch、execSwift 稍后通过__tinycast.settle回答JS 线程从不阻塞在 UI 上同步invokeSync只服务 Node shimfs.readFileSync、execSync、createHash、gunzipSync因为 Swift 完全在 JS 队列上处理它们不会与主 actor 死锁。覆盖到什么程度缺口又有多诚实兼容性的真实水准以实测数据为准。docs/features/extensions.md 记录了在开发机上对真实 Raycast 里安装的 37 个扩展的测量结果32 个扩展 / 147 个 view 命令中的 114 个可以完整启动并渲染且可通过 Scripts/raycast-runtime/test.mjs 和Scripts/run-tests.sh ext-test复现。支持面包括完整的组件集List/Grid/Detail/Form/ActionPanel/Action及全部便捷变体、系统 APIClipboard、LocalStorage、Cache、environment、getPreferenceValues、showToast、confirmAlert等、Node 内建模块path、fs、os、child_process、crypto、zlib、http/https、stream、buffer、url等甚至还有两个以小博大的实现WebAssemblycompile/instantiate走同步构造器跑通 JavaScriptCoresql.js、Zotero 这类重度依赖 WASM 的扩展因此能加载。.local域名解析Scripts/raycast-runtime/src/dgram.js 里那个 UDP socket 从来不碰网络——它解码 mDNS 查询转给系统getaddrinfo解析再编一个应答包发回去。Home Assistant 的默认地址homeassistant.local就靠这个跑通且因此不需要任何组播 entitlement 或本地网络弹窗。更值得注意的是缺口处理的态度AI、BrowserExtension、WindowManagement三个命名空间被声明为不支持但导入它们没问题调用时会抛出一个写明原因的错见 Scripts/raycast-runtime/src/api/index.js 的rejectingNamespace而不是静默降级。这种显式报错优于隐性失效的边界哲学正是兼容层能赢得开发者信任的关键——用户可以验证哪些能用、诊断哪些不能用而不必在无声的 bug 里猜。安装、更新与深链一条完整的生态通道兼容层不只是运行时还包括一套完整的安装渠道docs/features/extensions.md 列出四条路径——搜索 Raycast Store 直接安装已构建的 bundle零编译、从 GitHub 源码在本地构建自动选 pnpm/Bun/Yarn/npmray build -e dist直接产出、从本地 Raycast 导入已构建的 bundle零网络以及从文件夹添加。Tinycast 甚至注册了raycast、com.raycast和tinycast三个深链 schemeraycast://extensions/owner/extension/command可以从浏览器或其他应用直接运行已安装命令tinycast://则保证自家链接不依赖 Raycast 是否抢到 scheme。菜单栏命令原生NSStatusItemNSMenu渲染和no-view后台刷新interval调度、指数退避、失败回滚也一并覆盖。这套通道意味着一个扩展开发者为 Raycast 生态写的东西可以原封不动地成为 Tinycast 生态的一部分——这就是兼容层即生态位的底层逻辑。MCP把工具调用协议变成 AI 能力的统一入口如果说兼容层让 Tinycast 继承了 扩展生态那么 MCP 支持则让它接入了一个正在爆发的工具生态。docs/features/mcp.md 详细记录了完整的 MCP 客户端实现既可以连接远程 HTTP 端点也可以拉起本机 stdio 子进程服务器服务器按句柄命名空间隔离slug前缀模型按需调用。三种运输方式一套安全模型两种传输都走同一个 JSON-RPC 2.0 编码器MCPProtocol只是成帧不同MCPHTTPTransport每消息一个 POST或 SSE 流MCPStdioTransport走子进程 stdin/stdout 的换行分隔协议超时统一为 15 秒、tools/call放宽到 60 秒。命令的查找交给Platform/ExecutableLocator先问登录 shell 再走 PATH——因为 GUI 应用继承的是 Finder 的 PATH上面根本没有npx、uvx和node。安全边界是这个模块最值得称道的部分默认全关mcpEnabled关闭时完全关闭——不建连接、不驻留进程、不对模型暴露任何工具。mcpServers与开关一起被排除在设置备份之外因为服务器列表既是可执行代码的来源也是聊天上下文的去向一个导入不能替另一台 Mac 决定连接什么。凭据只在登录 Keychain服务器配置持久化在UserDefaults里的只是端点、认证模式、header 名、命令和参数真正的 secret 一律进KeychainSecretStore.mcpSecrets绝不进入日志、错误或备份。远程端点强制 HTTPS复用 AI 提供商的AIEndpointPolicy.validate明文 HTTP 仅对localhost/127.0.0.1/::1开放。OAuth 全链路PKCE S256、RFC 9728 资源元数据发现、RFC 7591 动态客户端注册、回调只绑定127.0.0.1:4962、拒绝一切跨源重定向——改个 URL 不能把旧 token 借给新端点。信任、限流与把工具调用当内容每次对话的首次工具调用会触发一个三方对话框Always Allow持久化/Allow This Chat仅本次会话/Dont Allow拒绝这一次Escape 永远不能持久化决定.never只能在设置里设置。被拒绝的调用不会抛错而是以AIToolResult的形式回到模型那里让它读得懂、绕得开。每一轮工具循环有三重限制docs/features/ai.md轮数上限AIToolRounds10/25/50/100/无限默认 25、单次结果体积上限、整轮结果总量上限。工具名通过MCPToolName规范化为slug__tool截断到 64 字符——这是 OpenAI 的硬上限。双向的角色切换谁跑循环取决于路由架构上最优雅的一点是谁执行 MCP 循环完全由路由决定。在 API 路由上OpenAI、Anthropic、Gemini、OpenRouterTinycast 自己是 MCP 客户端AIToolLoopProvider作为装饰器包装底层 provider 跑循环而在 Codex 和 Claude 路由上vendor CLI 自己是 MCP 客户端Tinycast 负责提供服务器并应答它的征询。这里有一个极其硬核的细节Codex 通过-c mcp_servers.tinycast-handle注入服务器同时按名字禁用用户~/.codex/config.toml里自己配置的服务器——因为如果不显式禁用用户自己的服务器会在 Tinycast 线程里启动而CodexTurnRunner对此完全看不见。Claude 则用--strict-mcp-config加每轮临时写入的0600配置文件把工具权限问题通过control_request通道回传给 Tinycast 的信任对话框。整个过程只有 Settings 能改变既定决定updatedPermissions永远不会发出。从平替到生态扩展即生态的路径现在可以把两条轮子并起来看了。Tinycast 的生态位策略可以概括为三句话数据层兼容Raycast 导入、扩展层兼容Raycast 运行时、协议层开放MCP。数据层的代表性动作是 docs/features/raycast-import.md 描述的.rayconfig解密导入Raycast v2.x 导出文件是RAYCFG3容器AES-256-GCM 负载 scrypt 密钥派生N16384, r8, p1Tinycast 在 Service/RaycastDecoder.swift 里完整实现了解密与字段映射Snippets、Quicklinks、剪贴板历史、热键、设置一次性迁移。配套地自有数据以单个.tinycast文件打包docs/features/backup.md五个可勾选类别设置与快捷键、剪贴板历史、Snippets、笔记、启动器学习数据且明确排除扩展、AI 聊天历史与 Keychain 材料——扩展是第三方代码与第三方数据聊天历史和 API 密钥留在产生它们的 Mac 上。这三点共同回答了平替这个词为什么会过时平替比的是功能清单生态比的是接入成本。当 Tinycast 能原生运行 114/147 个 Raycast 命令、能直接搜 Raycast Store 安装、能解密用户的 Raycast 数据迁移时从 Raycast 迁到 Tinycast的成本从重新配置一切降为几分钟导入。兼容层抹平的是迁移摩擦这是任何功能清单都替代不了的。MCP 让工具能力不被应用内建锁死。2026 年的 AI 启动器竞争本质是谁能调用的工具最多。Tinycast 的选择是拥抱 MCP 这个开放协议让文件系统、数据库、开发工具等一切 MCP 服务器都成为自己 AI 聊天的能力延伸——而且对 Codex/Claude 两个别人家的客户端也主动供服务器姿态是协议优先而不是自家优先。原生与零依赖是生态的信任底座。全 Swift 6、零第三方依赖、无遥测、常驻内存低于 100MBREADME.md这保证了运行第三方扩展这个在别处需要用户下很大决心的动作在这里的心理成本足够低——再加上 AGPL-3.0 开源、可审计、可贡献CONTRIBUTING.md 甚至给每个 PR 规定了内存预算。由此回看 2026 年的启动器赛道格局正在分化成两类玩家一类继续在功能矩阵里内卷比拼谁的内建命令更多另一类以 Tinycast 为代表选择兼容别人的生态、开放自己的协议用扩展兼容层降低迁移成本、用 MCP 接入更大的工具网络把自己变成一个可以自举生长的节点。当平替可以消费前一个生态的全部资产并且通过开放协议接入下一个生态时它已经不再是替代品——生态从来不是从零长出来的而是从兼容与开放里长出来的。Tinycast 的路线图印证了这一点扩展运行时、MCP 客户端、Raycast 导入、备份互操作四个方向没有一个是重造轮子全部是接住轮子并转起来。这或许就是 2026 年启动器生态观察最有价值的结论开源启动器的竞争已经从功能之争变成了接口之争、协议之争、生态之争。【免费下载链接】tinycastTinycast — a tiny, fully native macOS launcher, hotkeys, and clipboard history.项目地址: https://gitcode.com/GitHub_Trending/ti/tinycast创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考