AOS 2026.9.2 发布记录详解：捆绑 Astrid 2026.9.2 的可选认证 MCP Streamable HTTP 传输，与打标前的发布验证门禁

本篇围绕release/RELEASE-2026.9.2.md这一份 AOS 2026.9.2 的发布记录展开：它说明了该补丁版本如何捆绑带可选认证 MCP Streamable HTTP 传输的 Astrid 2026.9.2 运行时、哪些既有能力保持不动、运行时来源与元数据摘要的认证要求，以及打标（tag）之前必须通过的四道验证门禁。读完后，你将掌握 AOS 补丁发布的最小变更面如何界定、发布证据链如何从“已发布的上游工件”而非私有演练产物中取得，以及 publication 与 dev/stable 频道晋级之间为何必须是两次独立的授权动作。

一、版本定位：2026.9.x 系列中的第二个补丁

AOS 2026.9.2 是继已发布的 AOS 2026.9.1 之后的运行时更新（见 release/RELEASE-2026.9.2.md）。自 2026 年 9 月起，Astrid、AOS 与 Oracle 统一采用YEAR.MONTH.PATCH日历版本（CalSemVer）：同一日历月系列的首发是2026.9.0，后续修复依次为2026.9.1、2026.9.2……新月份系列从补丁号 0 重新开始，且已发布版本不可变、不做重命名（见 release/VERSIONING.md）。

因此 2026.9.2 在系列中的角色是明确的补丁位：它不引入新的月度能力线，只是把 Astrid 运行时从 2026.9.1 推进到 2026.9.2，并同步精确的运行时与客户端库 pin。仓库后续已演进到2026.9.3（当前 release/runtime-compatibility.toml 中 pin 的是 Astridv2026.9.4，产品版本2026.9.3），这正体现了“pin 随每次发布前移”的机制。

CHANGELOG.md 中 2026.9.2 一节（2026-09-13）给出了与发布记录一致的净变更描述：

Bundle Astrid 2026.9.2, adding optional authenticated MCP Streamable HTTP transport and honoring the selected workspace configuration for that transport. Existing stdio host integration and Community capsule selection are unchanged. Update the exact runtime and client-library pins while retaining GNU, musl, and macOS filesystem providers and authenticated runtime metadata.

二、核心变更：捆绑 Astrid 2026.9.2 与可选的认证 MCP Streamable HTTP 传输

2026.9.2 的技术主体只有一条：运行时（Astrid）升级到 2026.9.2，其中新增了可选的、经认证的 MCP Streamable HTTP 传输，并且该传输会遵循为该传输选定的工作区（workspace）配置。

这条变更有几个值得注意的边界，均直接来自发布记录原文：

1. 可选（optional）：Streamable HTTP 传输不是默认行为，既有集成不需要任何改动。
2. 认证（authenticated）：该传输走认证通道，与 AOS 一贯的“私有输入/权限面必须可信”的设计取向一致。
3. stdio 宿主集成不变：aos mcp serve面向 agent 宿主的 stdio 通道保持原样。从本仓库结构看，AOS 对 MCP 端点拥有明确的归属边界——crates/unicity-aos-bootstrap/src/mcp/mod.rs 的模块注释写明：“被 pin 的运行时 MCP shim 在本发布中仍然是兼容传输；AOS 拥有外部可见的命令、服务器身份与交互策略（AOS owns the externally visible command, server identity, and interaction policy）”。也就是说，Streamable HTTP 传输的实现位于被捆绑的 Astrid 运行时一侧，本仓库只负责宿主侧的 stdio 集成与交互策略。
4. 作用域限定：发布记录明确声明“这不宣称能刷新一个已在运行的 Codex 会话的工具目录（This does not claim to refresh the tool catalog of an already-running Codex conversation）”。这是对升级生效范围的诚实约束：新传输对新建立的宿主集成生效，已运行会话的工具目录不保证被热刷新。

对使用者的实际影响可以概括为：如果你通过 stdio 使用 AOS 宿主 MCP 工具，2026.9.2 对你而言是一次无感知的运行时升级；只有当你主动选择 Streamable HTTP 传输并按工作区配置启用认证时，才会接触到新能力。

三、明确保持不变的部分

发布记录用三段话划定了“最小变更面”，这是补丁发布中最容易被忽视、却最有价值的信息：

3.1 Community capsule 成员不变

“Community capsule membership are unchanged”意味着 2026.9.2 没有增删任何社区胶囊。当前仓库中这份不变的选择即 release/community-capsules.txt：按 distro 顺序列出的 22 个胶囊 allowlist（capsule-cli、capsule-mcp、capsule-registry、capsule-openai-compat、capsule-react、capsule-session、capsule-identity、capsule-users、capsule-router、capsule-prompt-builder、capsule-context-engine、capsule-hook-bridge、capsule-hook-adapter-oracle、capsule-meta-harness、capsule-shell、capsule-http、capsule-fs、capsule-system、capsule-forge、capsule-skills、capsule-agents、capsule-memory），每个条目的已发布工件身份来自各自Cargo.toml/Capsule.toml，前缀保持aos-*。

3.2 文件系统提供方与卷格式不变

“GNU, musl, and Darwin retain their packaged filesystem providers. Volume format and historical releases are unchanged.” 即三大平台继续使用各自打包的文件系统提供方，卷格式不迁移，历史发布与 tag 不被替换。这与 2026.9.0 首发时的平台矩阵（release/RELEASE-2026.9.0.md 中 GNU Linux、musl Linux x86_64/ARM64 原生归档、Darwin 签名应用）一脉相承。

3.3 运行时来源与元数据摘要的认证来源

发布记录强调：“Runtime source and metadata digests come from authenticated published Astrid v2026.9.2, not private rehearsal artifacts.”（运行时源码与元数据摘要来自经认证的已发布Astrid v2026.9.2，而非私有演练工件）。这一要求的前一版先例完整写在 release/RELEASE-2026.9.1.md 中：“精确的 Astrid 源码提交与 GNU/Darwin、musl 两组元数据摘要必须来自经认证的已发布 v2026.9.1 工件；全部四个直接的 Astrid 客户端依赖必须解析到已发布的 2026.9.1 crates；私有演练的哈希与身份不是生产 pin。”

落到仓库文件层面，这类 pin 的载体就是 release/runtime-compatibility.toml（记录产品版本、运行时 tag/提交、发布元数据资产及其 BLAKE3 摘要）、Distro 的 Astrid 要求、bootstrap 的运行时常量与运行时命令清单——release/RELEASE-2026.9.0.md 明确要求这些 pin“together”（一起）更新，且“不得虚构缺失的生产哈希，不得用一次性的演练密钥替代生产信任”。

四、打标前的验证门禁：四样证据缺一不可

release/RELEASE-2026.9.2.md 的最后一段是本发布记录的操作核心：

Before tagging, validate the release contract, packaging, installer and actual MCP invocation with the composed candidate. CI and signature verification alone are not an end-to-end installation claim. Publication and dev/stable promotion remain separate authorized actions.

可以拆解为两条规则、四个动作：

4.1 用组合候选（composed candidate）验证四件事

4.2 两条不可合并的授权边界

• “CI 和签名验证本身不构成端到端安装声明”：绿灯的 CI 与通过的生产签名验证，只能证明构建与工件完整性，不能证明真实安装—启动—调用链路可用。这也是 release/RELEASE-2026.9.0.md 中“在 macOS 与 GNU/musl x86_64/ARM64 上演练候选（安装、旧布局迁移、start/stop、文件系统的写/同步/卸载）”要求的延续。
• “Publication 与 dev/stable 晋级仍是两个独立的授权动作”：把候选发布（publication）到发布位，与把它晋级到 dev/stable 频道，必须由两次独立授权完成，不能在一次操作里顺手晋级。频道与工作流的完整契约可参考 docs/release-channels.md 与 release/RELEASE-2026.9.0.md 中“按依赖顺序发布：Astrid → AOS → Oracle”的说明。

五、发布证据链速览

• 发布记录本身：release/RELEASE-2026.9.2.md
• 同系列前一版（含“Release dependency”一节，展示认证 pin 的完整要求）：release/RELEASE-2026.9.1.md
• 净变更描述：CHANGELOG.md
• 版本规则：release/VERSIONING.md
• 运行时/元数据 pin 文件：release/runtime-compatibility.toml（注意：当前工作区内容反映的是后续 2026.9.3 的 pin，2026.9.2 发布时对应的 v2026.9.2 pin 已随系列前移）
• 契约校验脚本：scripts/validate-release-contract.py、测试 scripts/test_validate_release_contract.py
• 社区胶囊 allowlist：release/community-capsules.txt
• 宿主 MCP 端点与交互策略归属：crates/unicity-aos-bootstrap/src/mcp/mod.rs
• 发布渠道文档：docs/release-channels.md

一句话总结：AOS 2026.9.2 是一次变更面极小的补丁发布——唯一的能力增量是 Astrid 2026.9.2 带来的可选认证 MCP Streamable HTTP 传输；它的全部工程重量都压在“pin 必须来自经认证的上游发布工件”“打标前必须用组合候选完成契约/打包/安装器/真实调用四项验证”“发布与频道晋级分权执行”这三条可审计的规则上。