Kilo JetBrains 插件 Bundled-CLI 发布方案突破 400 MB 限制的全平台离线插件仓库构建指南【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode导读本文围绕 Kilo 开源仓库中 JetBrains Bundled-CLI Release Plan 这份发布设计文档展开讲解 Kilo 团队如何在不改变 Marketplace 构建产物的前提下构建并发布一份已签名、覆盖全部平台、内嵌 CLI 二进制的 JetBrains 插件 ZIP并通过 GitHub Pages 自建插件仓库绕过 JetBrains Marketplace 对插件 ZIP 的 400 MB 大小上限。读完本文你将理解kilo.cli.pinned与kilo.cli.bundled两个 Gradle 属性的职责边界、kilo-cli.zip资源在运行时如何被探测与按平台解压、以及publish-jetbrains→publish-jetbrains-bundled的自动化发布链路并可直接复现对应的构建与安装步骤。背景为什么需要一套“Bundled-CLI”发布通道Kilo 的 JetBrains 插件在默认Marketplace模式下保持“瘦身”形态插件本体不包含 CLI 二进制用户在 IDE 中首次连接时后端会根据钉住的 CLI 版本从 GitHub Release 下载对应平台的二进制见 KiloBackendCliManager.kt 中KiloCliDownloader(...).resolve(...)分支。这种设计的优点是插件体积小、发布简单但代价是依赖运行时网络——离线环境或受限网络下无法工作。JetBrains Marketplace 对插件 ZIP 有 400 MB 的体积上限而 Kilo 的 CLI 需要覆盖六个平台darwin-arm64、darwin-x64、linux-arm64、linux-x64、windows-arm64、windows-x64全部内嵌后必然超过该限制。因此方案文档给出的思路是保留 Marketplace 通道不变另起一条“Bundled-CLI”通道把六个平台的 CLI Release 资产全部打进插件后端 jar 的kilo-cli.zip资源中签名后发布到 GitHub Release并通过 GitHub Pages 自建updatePlugins.xml自定义插件仓库供 JetBrains IDE 安装。该方案相关实现细节可在仓库的 AGENTS.md 与 RELEASING.md 中交叉印证。核心原则同一标签、同一源码仅一个构建参数不同方案文档明确了 bundled 构建与 Marketplace 构建的唯一差异两者使用同一个不可变标签jetbrains/vversion构建同一份源码两者都保持kilo.cli.pinnedtruebundled 构建唯一的额外参数是-Pkilo.cli.bundledtruekilo.properties后端运行时属性资源在两种构建中逐字节一致唯一构建产物差异是后端 jar 中是否内嵌kilo-cli.zipkilo.cli.pinned的语义保持不变它只决定“用哪个 CLI 版本 / 从哪份 OpenAPI 源码生成客户端 / 是否允许发布”不控制运行时交付方式。这一原则在 backend/build.gradle.kts 中有直接对应pinned默认true、repoCli!pinned与bundled默认false三个属性共同推导出downloadsCli !repoCli !bundled——只有“既不是本地仓库模式、也不是 bundled 模式”时才需要运行时下载。此外构建脚本还硬性校验了组合合法性if (repoCli.get() bundled.get()) { error(kilo.cli.bundledtrue requires kilo.cli.pinnedtrue; do not combine release CLI bundling with local repo CLI mode.) }也就是说kilo.cli.bundledtrue必须与kilo.cli.pinnedtrue搭配使用禁止与本地 repo CLI 开发模式混用。默认值方面gradle.properties 中kilo.cli.pinnedtrue是唯一可发布状态false仅为本地开发使用从packages/opencode/生成客户端并内嵌本地构建的 CLI生产构建与发布脚本遇到false会直接失败见 build.gradle.kts。Phase 1后端运行时交付——探测资源命中即解压、否则下载Phase 1 改造的是后端 CLI 交付逻辑核心代码集中在 KiloRepoCli.kt 与 KiloBackendCliManager.kt资源探测KiloRepoCli.available()通过类加载器判断kilo-cli.zip资源是否存在fun available(): Boolean KiloRepoCli::class.java.classLoader.getResource(ARCHIVE) ! null决策分派KiloBackendCliManager.resolveCli()先检查available()为真则走KiloRepoCli.extract(force)日志标记Kilo CLI mode: BUNDLED否则走KiloCliDownloader下载钉住版本日志标记Kilo CLI mode: DOWNLOAD。这意味着只要包里带了kilo-cli.zip运行时永远不会发起下载天然满足离线与受限网络场景。按平台子树解压归档内部按platform/bin/kilo[.exe]组织extract()通过select()只挑选当前平台子树KiloCliPlatform.current()判定写入磁盘不会把六个平台的二进制全部落盘解压目标位于 IntelliJ 系统目录下的kilo/repo-cli/cliVersion/并以.complete标记文件做幂等缓存forcetrue时强制重解压。路径穿越防护check()对每个归档条目执行三重校验——拒绝以/开头的绝对路径、拒绝含..的路径、并用canonicalFile确认目标落在根目录内任何越界条目直接抛出IllegalStateException(Archive entry escapes target directory: ...)。版本清理prune()在解压完成后删除同目录下其他历史版本目录避免磁盘上残留陈旧 CLI 版本。以上行为均有测试用例锁定见 KiloRepoCliTest.kt包括缓存命中与强制重解压、多平台归档只解压当前平台、解压后清理陈旧版本以及拒绝../../../bad这类逃逸条目。方案还要求开发期的 repo CLI 暂存目录与 bundled 归档使用同一布局这正是 backend/build.gradle.kts 中stageRepoCli本地仓库模式与stageBundledClibundled 模式两个任务共写generated/kilo-cli-res/kilo-cli.zip的原因——两者产出的归档结构完全一致运行时只需一套解压逻辑。Phase 2Gradle 打包——下载六平台资产并校验 SHA-256Phase 2 在构建层把“内嵌 CLI”变成一条受控的构建链路新增构建期属性kilo.cli.bundled默认false见 backend/build.gradle.kts生产 bundled 构建必须保持kilo.cli.pinnedtrue新增StageBundledCliTask实现在 StageBundledCliTask.kt从 GitHub 下载全部六个平台PLATFORMS列表与运行时KiloCliPlatform.current()保持一致WriteCliChecksumsTask.kt中有同步注释的钉住版本 Release 资产并用发布元数据中的sha256:[a-f0-9]{64}摘要逐一校验最后组装成kilo-cli.zip写入 backend 资源目录条件接线stageBundledCli仅当-Pkilo.cli.bundledtrue或本地 repo CLI 模式时挂到compileKotlin/processResources依赖上普通构建downloadsCli为真则只挂writeCliChecksums为运行时下载提供校验和build.gradle.kts发布防线保留kilo.cli.pinnedfalse在生产构建与发布脚本中仍然硬失败不做任何放宽。对应命令为方案文档原文含签名与校验全流程./gradlew clean buildPlugin signPlugin verifyPluginSignature verifyPlugin \ -Pproductiontrue -Pkilo.versionversion -Pkilo.channeldefault \ -Pkilo.cli.bundledtrue其中kilo.channeldefault对应 stable 渠道RC 使用eap渠道。需要说明stageBundledCli需要访问 GitHub API 下载 Release 资产因此构建环境需配置GH_TOKEN或GITHUB_TOKEN环境变量任务中token.set(...)同时回退读取两者。Phase 3发布工作流——Marketplace 成功后自动触发 Bundled 构建发布链路在 CI 层面闭环相关文件新增 publish-jetbrains-bundled.yml通过workflow_dispatch接收两个必填输入pr已合并的发布 PR 号与merge_commit该 PR 的合并提交 SHA在 publish-jetbrains.yml 末尾增加成功步骤在 Marketplace 发布成功后 dispatch bundled 工作流bundled 工作流的执行顺序见 RELEASING.md 与工作流源码先按merge_commit检出已合并的发布 PR用script/jetbrains-release-validate.ts校验发布 PR 与标签校验用脚本来自受信任的main分支再检出不可变标签jetbrains/vversion叠加已评审的发布元数据gradle.properties、CHANGELOG.md以-Pkilo.cli.bundledtrue构建 bundled 变体执行签名、校验将kilo-code-version-bundled.zip上传到同一个 GitHub Release与 Marketplace 构建共用标签与 Release版本策略RC 与 stable 都会产出 bundled ZIP但只有stable才更新自定义插件仓库 XML。RC 的 bundled ZIP 仅作为 prerelease 附件供“从磁盘安装”测试见 RELEASING.md。这一“先校验合并 PR、再构建不可变标签”的顺序保证了发布物永远来自已评审的合并结果与不可变标签评审意见不会被绕过。Phase 4GitHub Pages 自定义插件仓库最后一步解决“用户怎么装”的问题在 stable 发布时从已签名的 bundled ZIP 元数据生成jetbrains/updatePlugins.xml插件下载 URL 指向 GitHub Release 上上传的 bundled ZIP 资产通过 GitHub Pages Actions 将 XML 部署到https://kilo-org.github.io/kilocode/jetbrains/updatePlugins.xml用户只需在 JetBrains IDE 中把该 URL 加入插件仓库Settings → Plugins → Manage Plugin Repositories之后即可像 Marketplace 一样检索、安装、升级。该 URL 在 RELEASING.md 中被确认为实际生效的稳定自定义仓库地址并明确指出 RC bundled ZIP 不会更新该 stable XML。验收标准与方案边界方案文档给出的验收标准同时划清了能力边界可作为实施后的回归检查清单Marketplace 构建行为不变仍保持瘦身形态、运行时下载 CLIBundled 构建同源同标签使用同一个jetbrains/vversion标签与源码仅-Pkilo.cli.bundledtrue不同且kilo.cli.pinnedtrue签名与附件bundled ZIP 经过签名并挂到jetbrains/vversion对应的 GitHub Release运行时零下载只要kilo-cli.zip资源存在运行时必然解压当前平台 CLI绝不回退下载stable 更新自定义仓库GitHub Pages 上的updatePlugins.xml始终指向最新已签名 bundled ZIP。从源码结构看该方案刻意不做以下事情均为方案文档的显式决策不新增kilo.properties中的cli.bundled标志位、不为 bundled 构建修改任何已提交文件、不把kilo.cli.pinnedfalse重新定义为“内嵌发布”模式。运行时交付完全由“是否存在kilo-cli.zip资源”这一个事实驱动构建期与运行期的职责因此被严格解耦这也是该方案最值得借鉴的架构取舍。延伸阅读方案设计原文bundled-release-plan.md运行时解压与安全校验实现KiloRepoCli.kt运行时决策与 CLI 进程生命周期KiloBackendCliManager.ktGradle 属性推导与任务接线backend/build.gradle.kts、gradle.properties六平台下载与 SHA-256 校验任务StageBundledCliTask.kt、WriteCliChecksumsTask.kt发布全流程说明RELEASING.md、publish-jetbrains-bundled.yml解压行为测试KiloRepoCliTest.kt【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kilo JetBrains 插件 Bundled-CLI 发布方案：突破 400 MB 限制的全平台离线插件仓库构建指南
Kilo JetBrains 插件 Bundled-CLI 发布方案突破 400 MB 限制的全平台离线插件仓库构建指南【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode导读本文围绕 Kilo 开源仓库中 JetBrains Bundled-CLI Release Plan 这份发布设计文档展开讲解 Kilo 团队如何在不改变 Marketplace 构建产物的前提下构建并发布一份已签名、覆盖全部平台、内嵌 CLI 二进制的 JetBrains 插件 ZIP并通过 GitHub Pages 自建插件仓库绕过 JetBrains Marketplace 对插件 ZIP 的 400 MB 大小上限。读完本文你将理解kilo.cli.pinned与kilo.cli.bundled两个 Gradle 属性的职责边界、kilo-cli.zip资源在运行时如何被探测与按平台解压、以及publish-jetbrains→publish-jetbrains-bundled的自动化发布链路并可直接复现对应的构建与安装步骤。背景为什么需要一套“Bundled-CLI”发布通道Kilo 的 JetBrains 插件在默认Marketplace模式下保持“瘦身”形态插件本体不包含 CLI 二进制用户在 IDE 中首次连接时后端会根据钉住的 CLI 版本从 GitHub Release 下载对应平台的二进制见 KiloBackendCliManager.kt 中KiloCliDownloader(...).resolve(...)分支。这种设计的优点是插件体积小、发布简单但代价是依赖运行时网络——离线环境或受限网络下无法工作。JetBrains Marketplace 对插件 ZIP 有 400 MB 的体积上限而 Kilo 的 CLI 需要覆盖六个平台darwin-arm64、darwin-x64、linux-arm64、linux-x64、windows-arm64、windows-x64全部内嵌后必然超过该限制。因此方案文档给出的思路是保留 Marketplace 通道不变另起一条“Bundled-CLI”通道把六个平台的 CLI Release 资产全部打进插件后端 jar 的kilo-cli.zip资源中签名后发布到 GitHub Release并通过 GitHub Pages 自建updatePlugins.xml自定义插件仓库供 JetBrains IDE 安装。该方案相关实现细节可在仓库的 AGENTS.md 与 RELEASING.md 中交叉印证。核心原则同一标签、同一源码仅一个构建参数不同方案文档明确了 bundled 构建与 Marketplace 构建的唯一差异两者使用同一个不可变标签jetbrains/vversion构建同一份源码两者都保持kilo.cli.pinnedtruebundled 构建唯一的额外参数是-Pkilo.cli.bundledtruekilo.properties后端运行时属性资源在两种构建中逐字节一致唯一构建产物差异是后端 jar 中是否内嵌kilo-cli.zipkilo.cli.pinned的语义保持不变它只决定“用哪个 CLI 版本 / 从哪份 OpenAPI 源码生成客户端 / 是否允许发布”不控制运行时交付方式。这一原则在 backend/build.gradle.kts 中有直接对应pinned默认true、repoCli!pinned与bundled默认false三个属性共同推导出downloadsCli !repoCli !bundled——只有“既不是本地仓库模式、也不是 bundled 模式”时才需要运行时下载。此外构建脚本还硬性校验了组合合法性if (repoCli.get() bundled.get()) { error(kilo.cli.bundledtrue requires kilo.cli.pinnedtrue; do not combine release CLI bundling with local repo CLI mode.) }也就是说kilo.cli.bundledtrue必须与kilo.cli.pinnedtrue搭配使用禁止与本地 repo CLI 开发模式混用。默认值方面gradle.properties 中kilo.cli.pinnedtrue是唯一可发布状态false仅为本地开发使用从packages/opencode/生成客户端并内嵌本地构建的 CLI生产构建与发布脚本遇到false会直接失败见 build.gradle.kts。Phase 1后端运行时交付——探测资源命中即解压、否则下载Phase 1 改造的是后端 CLI 交付逻辑核心代码集中在 KiloRepoCli.kt 与 KiloBackendCliManager.kt资源探测KiloRepoCli.available()通过类加载器判断kilo-cli.zip资源是否存在fun available(): Boolean KiloRepoCli::class.java.classLoader.getResource(ARCHIVE) ! null决策分派KiloBackendCliManager.resolveCli()先检查available()为真则走KiloRepoCli.extract(force)日志标记Kilo CLI mode: BUNDLED否则走KiloCliDownloader下载钉住版本日志标记Kilo CLI mode: DOWNLOAD。这意味着只要包里带了kilo-cli.zip运行时永远不会发起下载天然满足离线与受限网络场景。按平台子树解压归档内部按platform/bin/kilo[.exe]组织extract()通过select()只挑选当前平台子树KiloCliPlatform.current()判定写入磁盘不会把六个平台的二进制全部落盘解压目标位于 IntelliJ 系统目录下的kilo/repo-cli/cliVersion/并以.complete标记文件做幂等缓存forcetrue时强制重解压。路径穿越防护check()对每个归档条目执行三重校验——拒绝以/开头的绝对路径、拒绝含..的路径、并用canonicalFile确认目标落在根目录内任何越界条目直接抛出IllegalStateException(Archive entry escapes target directory: ...)。版本清理prune()在解压完成后删除同目录下其他历史版本目录避免磁盘上残留陈旧 CLI 版本。以上行为均有测试用例锁定见 KiloRepoCliTest.kt包括缓存命中与强制重解压、多平台归档只解压当前平台、解压后清理陈旧版本以及拒绝../../../bad这类逃逸条目。方案还要求开发期的 repo CLI 暂存目录与 bundled 归档使用同一布局这正是 backend/build.gradle.kts 中stageRepoCli本地仓库模式与stageBundledClibundled 模式两个任务共写generated/kilo-cli-res/kilo-cli.zip的原因——两者产出的归档结构完全一致运行时只需一套解压逻辑。Phase 2Gradle 打包——下载六平台资产并校验 SHA-256Phase 2 在构建层把“内嵌 CLI”变成一条受控的构建链路新增构建期属性kilo.cli.bundled默认false见 backend/build.gradle.kts生产 bundled 构建必须保持kilo.cli.pinnedtrue新增StageBundledCliTask实现在 StageBundledCliTask.kt从 GitHub 下载全部六个平台PLATFORMS列表与运行时KiloCliPlatform.current()保持一致WriteCliChecksumsTask.kt中有同步注释的钉住版本 Release 资产并用发布元数据中的sha256:[a-f0-9]{64}摘要逐一校验最后组装成kilo-cli.zip写入 backend 资源目录条件接线stageBundledCli仅当-Pkilo.cli.bundledtrue或本地 repo CLI 模式时挂到compileKotlin/processResources依赖上普通构建downloadsCli为真则只挂writeCliChecksums为运行时下载提供校验和build.gradle.kts发布防线保留kilo.cli.pinnedfalse在生产构建与发布脚本中仍然硬失败不做任何放宽。对应命令为方案文档原文含签名与校验全流程./gradlew clean buildPlugin signPlugin verifyPluginSignature verifyPlugin \ -Pproductiontrue -Pkilo.versionversion -Pkilo.channeldefault \ -Pkilo.cli.bundledtrue其中kilo.channeldefault对应 stable 渠道RC 使用eap渠道。需要说明stageBundledCli需要访问 GitHub API 下载 Release 资产因此构建环境需配置GH_TOKEN或GITHUB_TOKEN环境变量任务中token.set(...)同时回退读取两者。Phase 3发布工作流——Marketplace 成功后自动触发 Bundled 构建发布链路在 CI 层面闭环相关文件新增 publish-jetbrains-bundled.yml通过workflow_dispatch接收两个必填输入pr已合并的发布 PR 号与merge_commit该 PR 的合并提交 SHA在 publish-jetbrains.yml 末尾增加成功步骤在 Marketplace 发布成功后 dispatch bundled 工作流bundled 工作流的执行顺序见 RELEASING.md 与工作流源码先按merge_commit检出已合并的发布 PR用script/jetbrains-release-validate.ts校验发布 PR 与标签校验用脚本来自受信任的main分支再检出不可变标签jetbrains/vversion叠加已评审的发布元数据gradle.properties、CHANGELOG.md以-Pkilo.cli.bundledtrue构建 bundled 变体执行签名、校验将kilo-code-version-bundled.zip上传到同一个 GitHub Release与 Marketplace 构建共用标签与 Release版本策略RC 与 stable 都会产出 bundled ZIP但只有stable才更新自定义插件仓库 XML。RC 的 bundled ZIP 仅作为 prerelease 附件供“从磁盘安装”测试见 RELEASING.md。这一“先校验合并 PR、再构建不可变标签”的顺序保证了发布物永远来自已评审的合并结果与不可变标签评审意见不会被绕过。Phase 4GitHub Pages 自定义插件仓库最后一步解决“用户怎么装”的问题在 stable 发布时从已签名的 bundled ZIP 元数据生成jetbrains/updatePlugins.xml插件下载 URL 指向 GitHub Release 上上传的 bundled ZIP 资产通过 GitHub Pages Actions 将 XML 部署到https://kilo-org.github.io/kilocode/jetbrains/updatePlugins.xml用户只需在 JetBrains IDE 中把该 URL 加入插件仓库Settings → Plugins → Manage Plugin Repositories之后即可像 Marketplace 一样检索、安装、升级。该 URL 在 RELEASING.md 中被确认为实际生效的稳定自定义仓库地址并明确指出 RC bundled ZIP 不会更新该 stable XML。验收标准与方案边界方案文档给出的验收标准同时划清了能力边界可作为实施后的回归检查清单Marketplace 构建行为不变仍保持瘦身形态、运行时下载 CLIBundled 构建同源同标签使用同一个jetbrains/vversion标签与源码仅-Pkilo.cli.bundledtrue不同且kilo.cli.pinnedtrue签名与附件bundled ZIP 经过签名并挂到jetbrains/vversion对应的 GitHub Release运行时零下载只要kilo-cli.zip资源存在运行时必然解压当前平台 CLI绝不回退下载stable 更新自定义仓库GitHub Pages 上的updatePlugins.xml始终指向最新已签名 bundled ZIP。从源码结构看该方案刻意不做以下事情均为方案文档的显式决策不新增kilo.properties中的cli.bundled标志位、不为 bundled 构建修改任何已提交文件、不把kilo.cli.pinnedfalse重新定义为“内嵌发布”模式。运行时交付完全由“是否存在kilo-cli.zip资源”这一个事实驱动构建期与运行期的职责因此被严格解耦这也是该方案最值得借鉴的架构取舍。延伸阅读方案设计原文bundled-release-plan.md运行时解压与安全校验实现KiloRepoCli.kt运行时决策与 CLI 进程生命周期KiloBackendCliManager.ktGradle 属性推导与任务接线backend/build.gradle.kts、gradle.properties六平台下载与 SHA-256 校验任务StageBundledCliTask.kt、WriteCliChecksumsTask.kt发布全流程说明RELEASING.md、publish-jetbrains-bundled.yml解压行为测试KiloRepoCliTest.kt【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考