人工智能大模型Agent 记忆AI AgentRAG知识图谱dsh-plugin【免费下载链接】MemOSSelf-evolving memory OS for LLM AI Agents: ultra-persistent memory, hybrid-retrieval, and cross-task skill reuse, with 35.24% token savings and DeepSeek Harness support.项目地址https://gitcode.com/gh_mirrors/memos/MemOS点击查看免费下载导读本文基于 release-owner-runbook.md 整理完整讲解 MemOS Cloud OpenClaw Pluginmemtensor/memos-cloud-openclaw-plugin的自动化发布体系发布人员只需在同一个受审 PR 中一致升级四个版本文件并合入main系统便会自动完成 Beta/稳定版判定、npm 发布与校验、GitHub Draft Release 创建最后由发布负责人点击 Publish 收尾。读完本文你将掌握这套版本文件驱动发版流程的全部操作步骤、判定条件、Beta 与稳定版差异、Release Notes 规则及各类失败场景的处理方法。设计初衷把发版压缩成一次普通代码合并这套流程的核心结论只有一句话发布人员不需要新建固定名称的release/*分支也不需要手工填写 npm tag 或 40 位 commit。只要把四个版本文件在同一个受审 PR 中一致升级并合入main系统就会自动判断本次是 Beta 还是稳定版完成 npm 发布与验证并创建 GitHub Draft Release发布负责人只需检查 Draft 后点击Publish。值得注意的权限边界是这套流程不会让 GitHub Actions 新建或批准 PR因此仓库不需要开启Allow GitHub Actions to create and approve pull requests。版本修改仍由开发人员通过普通 PR 提交Actions 只负责消费已经合入main的代码、发布 npm、创建 tag 和 Draft Release把批准代码与发布产物两个权限点清晰隔离开。仓库中的四个版本文件与版本同步机制发版判定的基础是四个版本事实源全部位于 apps/MemOS-Cloud-OpenClaw-Plugin 目录下文件作用package.jsonnpm 包元数据name为memtensor/memos-cloud-openclaw-plugin同时声明了openclaw/moltbot/clawdbot三组 extensions 入口openclaw.plugin.jsonOpenClaw 宿主插件清单id: memos-cloud-openclaw-pluginkind: lifecyclemoltbot.plugin.jsonMoltbot 宿主插件清单结构与 openclaw 版本一致clawdbot.plugin.jsonClawDBot 宿主插件清单结构与 openclaw 版本一致在本仓库快照中三个 plugin.json 的version均为0.1.20与 package.json 完全一致——这正是 runbook 里四个版本一致门禁对应的仓库现状也说明文档示例中的0.1.21是一次真实可行的升级目标。npm version钩子与 sync-version.jspackage.json 中配置了版本联动脚本sync-version: node scripts/sync-version.js, version: npm run sync-version git add openclaw.plugin.json moltbot.plugin.json clawdbot.plugin.json, publish-beta: npm publish --tag beta, publish-beta-patch: npm version prepatch --preidbeta npm publish --tag beta, publish-latest: npm version $(node -p \require(./package.json).version.split(-)[0]\) npm publish, publish-latest-patch: npm version patch npm publish其中 scripts/sync-version.js 是四文件一致性的本地兜底工具它从更新后的package.json读取新版本号第 9-11 行再遍历openclaw.plugin.json、moltbot.plugin.json、clawdbot.plugin.json三个文件第 15-19 行仅在版本不一致时以 2 空格缩进重写 JSON 并追加换行第 28-33 行。它不会擅自覆盖已一致的版本也不会修改无关字段与只有四个文件一致且确实升级才发版的 CI 门禁思路一脉相承。发布负责人怎么操作稳定版示例0.1.21以发布稳定版0.1.21为例完整操作路径如下选择分支使用团队现有分支例如test或普通版本准备分支即可不要求特定名称。一致升级四个版本文件将 package.json、openclaw.plugin.json、moltbot.plugin.json、clawdbot.plugin.json 的version全部从当前版本改为0.1.21。可以用npm run sync-version从package.json联动同步其余三个文件。可选人工 Release Notes添加.github/release-notes/v0.1.21.md不添加时由 106文档发布 Agent根据 Git 证据自动生成。提交 PR 并合并PR 目标为main确认测试和版本检查通过后由有权限人员合并。观察自动 Workflow合并后打开 Actions 中的OpenClaw Cloud Plugin — Publish Release确认自动 run 为绿色。检查 Draft打开仓库 Releases检查系统创建的v0.1.21Draft重点核对版本号和目标 commit 正确Release Notes 准确中英文官网预览准确npm0.1.21已经通过latestdist-tag 可见。点击 Publish release只有这一步会产生稳定版release.publishedwebhook并让 106 创建 MemOS-Docs PR。合并前会有一条只读的版本门禁它只比较 PR 合并预览与当前main的四个版本值不读取发布 Secrets也不会发布 npm、创建 tag 或 Release。真正有副作用发布 npm、建 tag、建 Release的动作只发生在合并后的自动 Workflow 中——这也是整个流程安全性设计的根基。Beta 示例Beta 流程与稳定版完全一致只是把四个文件的版本从旧版本一致升级为0.1.21-beta.0。系统会自动选择 npmbetadist-tag创建 GitHubPrerelease DraftPublish 后 106 必须成功跳过正式官网同步即不创建正式 Docs PR。系统怎样判断这是一次发版系统比较 PR 合入前的main与合入后的精确 merge commit只有同时满足以下全部条件才自动发版PR 已合入main并且来自当前仓库而不是 Fork四个版本文件在合入前版本一致四个版本文件在合入后版本一致四个版本值都在本次 PR 中发生升级新版本是严格 SemVer并且优先级高于旧版本npm、GitHub tag 和 Release 状态没有冲突。反之如果四个版本值完全没变这是普通代码合并自动跳过、不会发布只改一部分版本文件、四个版本不一致、版本倒退或使用 build metadata 时会失败停止避免产生半正确的包。严格 SemVer 的底层校验仓库内 lib/semver.js 提供了与门禁同源的 SemVer 解析与比较实现cleanVersion第 25-28 行会剥掉v/V前缀parseSemver第 30-47 行用正则严格校验major.minor.patch三段并拒绝 pre-release 中带前导零的纯数字标识符build metadata 虽可解析但按 SemVer 规范不参与优先级比较compareSemver第 80-91 行先比较major/minor/patch再比较 prerelease 标识符且数值标识符按 BigInt 比较第 49-63 行。配套测试 test/check-update-version.test.mjs 验证了这些边界1.0.0-beta.10 1.0.0-beta.9、1.0.0-beta.1 1.0.0-beta.alpha、1.0.0 1.0.0-rc.1、1.0.0build.2 1.0.0build.1build metadata 不参与比较。这与 runbook 中版本倒退或使用 build metadata 时会失败停止的规则相互印证。允许的升级示例runbook 原文0.1.20 - 0.1.21-beta.0 0.1.21-beta.0 - 0.1.21-beta.1 0.1.21-beta.1 - 0.1.21可以看到稳定版可以退回到更低优先级的 prerelease 发布链里继续迭代但必须严格沿着 SemVer 优先级递增。Beta 与稳定版的区别合入后的版本npm dist-tagGitHub DraftPublish 后的 Docs 行为0.1.21-beta.0betaPrerelease Draft106 成功跳过不创建正式 Docs PR0.1.21-alpha.1alphaPrerelease Draft106 成功跳过不创建正式 Docs PR0.1.21-rc.1nextPrerelease Draft106 成功跳过不创建正式 Docs PR0.1.21latest正常 Draft人工 Publish 后由 106 创建 Docs PR即版本号里的 prerelease 前缀决定了 npm dist-tagbeta/alpha/next也决定了 Draft 的类型Prerelease以及 Publish 后是否触发正式 Docs PR。只有完全不带 prerelease 后缀的稳定版才会走到latest与正式 Docs 同步链路。这与 package.json 中publish-beta--tag beta、publish-latest等 npm 脚本的 dist-tag 语义保持一致。为什么 npm 在 Draft 之前发布GitHub Draft 一旦被人工 Publishrelease.publishedwebhook 会立即到达 106。如果此时才异步发布 npm就可能出现官网同步已经开始、npm 却失败或暂时不可见的半发布状态。因此本仓库选择固定时序版本 PR 合入 main - 校验四文件版本与 Release Notes - npm publish 校验 version/gitHead/dist-tag - 创建不可变 tag 和 Draft Release - 人工 Publish - 稳定版进入 106 Docs PR预发布版成功跳过这个时序的本质是权限分界合并版本 PR 表示团队已经批准了代码与 npm 发布Draft 的人工边界则用于最后确认 GitHub Release 和官网文案。反过来也要明确边界——如果团队要求人工审批前 npm 也不能发布那么仅靠原生 Draft 是不够的必须改用受保护 GitHub Environment 的审批按钮。Release Notes 规则默认方式106 自动生成不创建.github/release-notes/v版本.md时Workflow 会基于真实 tag range 和本次 merge commit 调用 106生成中英文内容、真实source_refs、质量报告和 Docs Preview。其中有一个关键细节稳定版会跳过中间 prerelease tag以上一个稳定 tag 为 evidence 基线这样做的目的是避免 Beta 阶段已经承载的真实功能在beta - stable升级时被漏掉——也就是说0.1.21的 Release Notes 会以0.1.20上一个稳定 tag为基线而不是以0.1.21-beta.1为基线。人工方式随版本 PR 提交创建.github/release-notes/v版本.md时文件必须包含## Changelog公开 Markdown隐藏的doc-agent-release-notes-json双语证据块唯一的!-- doc-agent: source-idopenclaw-cloud-plugin --标记。人工文件也必须通过 source ref、覆盖率、双语和长度检查不能绕过质量门禁。换句话说人工方式只是内容来源的切换质量红线不降级。哪些合并不会发布分支名不决定是否发版。test、feature/*、fix/*、docs-sync/*都可以合入main区别只在于版本文件的状态四个版本值没有变化正常跳过发布四个版本值全部一致升级进入自动发布只有部分版本变化或版本不一致检查失败要求修正。这套以版本文件为准、以分支名为无关变量的设计允许团队沿用任意日常分支做发版准备降低了流程仪式感带来的协作摩擦。失败怎么处理runbook 给出了覆盖各阶段的失败处置清单合并前版本检查失败继续修改原 PR四个版本一致且确实升级后再合并。106 文案生成失败不会发布 npm、tag 或 Draft修复 endpoint、证据或人工 notes 后再处理。npm 发布失败且 registry 没有正确版本不会创建 tag/Draft根据 Action 错误处理禁止猜测成功。npm 已成功但同一次自动任务尚未创建 tag/Draft可先点击Re-run系统确认 npmgitHead与原合并 commit 完全相同后只补缺失元数据不会重复发布 npm。npm 已成功但 tag/Draft 未创建使用现有 Workflow 的显式 Recovery它从 npmgitHead补齐元数据不会重复发布 npm并且仍然只创建 Draft 等待人工 Publish。Draft 文案不通过不要点 Publish。修订 Draft 时不得删除或损坏隐藏的双语 evidence payload 和source-id。tag 指向、npmgitHead、四文件版本任一冲突必须人工排查Workflow 不会移动已有 tag。核心原则可以提炼为两条以 npmgitHead与合并 commit 的一致性作为幂等恢复的锚点保证 Recovery 不会重复发布所有自动产物止步于 Draft最终发布权始终保留在人工 Publish 这一步。旧的手动入口OpenClaw Cloud Plugin — Publish Release的Run workflow手动入口仍然保留但只用于三类历史场景Dry-run试运行、故障注入、以及部分失败场景的 Recovery。正常的新版本发布不再需要填写旧表单直接走四个版本文件一致升级并合入main即可。如何在本地核对版本状态作为发布准备的一环可以在本仓库快照中直接核对四个版本文件的一致性。当前快照中 package.json、openclaw.plugin.json、moltbot.plugin.json、clawdbot.plugin.json 均为0.1.20。升级时若使用 npm 脚本方式只需npm version更新package.jsonsync-version.js会自动把新版本写入其余三个文件并git add然后再人工检查 PR diff 中四个文件是否都发生变化即可。需要说明的是runbook 描述的 GitHub Actions WorkflowOpenClaw Cloud Plugin — Publish Release及其版本门禁运行在插件自身的 GitHub 仓库中本仓库镜像仅包含插件源码、四个版本文件、sync-version.js与semver.js等本地佐证Workflow 定义本身不在本镜像内。小结MemOS Cloud OpenClaw 插件的自动发版流程用四个版本文件 只读合并前门禁 合并后自动化 人工 Publish的组合把发版从高风险的运维操作收敛为一次可审阅的普通代码合并版本号是唯一的发布意图声明SemVer 严格校验保证版本语义正确npm 先行发布避免半发布状态Draft 人工边界守住最终发布权gitHead锚点保证失败恢复的幂等性。对于同时维护多个宿主OpenClaw / Moltbot / ClawDBot的 npm 插件项目这套模式具有直接可复用的参考价值。赞分享人工智能大模型Agent 记忆AI AgentRAG知识图谱dsh-plugin【免费下载链接】MemOSSelf-evolving memory OS for LLM AI Agents: ultra-persistent memory, hybrid-retrieval, and cross-task skill reuse, with 35.24% token savings and DeepSeek Harness support.项目地址https://gitcode.com/gh_mirrors/memos/MemOS点击查看免费下载相关推荐jsPDF 版本发布全流程指南从 GitHub Release 到 npm 自动发布的标准化操作手册jsPDF 版本发布全流程指南从 GitHub Release 到 npm 自动发布的标准化操作手册 本文以 jsPDF 官方仓库的 RELEASE.md h后端quiche GitHub Draft Release 自动化指南从版本提交哈希到草稿发布quiche GitHub Draft Release 自动化指南从版本提交哈希到草稿发布 本篇指南讲解 quiche 仓库中如何通过 .opencode/s网络通信后端Hydra 发布自动化指南用 tools/release 统一管理 hydra-core、bundled 插件与 configen 的版本与发布Hydra 发布自动化指南用 tools/release 统一管理 hydra core、bundled 插件与 configen 的版本与发布 本指南面向开发工具后端CLI上一篇如何为 OpenClaude 的模型标记可被 /effort 控制的 reasoning 元数据下一篇Elementor Atomic Builder:全局变量绑定 PropValue 的完整机制——从 $$type 存储到 var(--label) 渲染创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考