执行摘要

• 一句话：新增 Buf 发布流程，托管 gRPC schema 供外部消费
• 推荐动作：值得精读。虽然新增代码只有 85 行，但它在发布治理上有几个可借鉴的设计：用 nightly/main/版本 label 区分不同消费场景；把 token 注入限定在主仓库的非 PR 事件，使 fork 贡献者可跑校验又不泄露凭据；通过 pin action commit 与 CLI 版本提升供应链安全。对要建立外部 schema 或 API 发布渠道的团队来说，这是一个低成本的样板。

功能与动机

PR 目标是把 vLLM 的 canonical gRPC schemas 发布到 Buf Schema Registry（BSR），让外部消费者能按稳定的模块名与不可变标签消费权威 schema。PR body 同时强调 This changes only schema publication and documentation. It does not modify the Protobuf wire schema, generated bindings, or runtime behavior，把影响面刻意控制在发布管道。没有关联 issue，属于 Rust 前端生态建设中协议分发的配套基础设施。

实现拆解

1. 定义 Buf 模块：新增 rust/proto/buf.yaml，声明 version: v2、模块根 path: . 与公共命名空间 buf.build/vllm-project/vllm；lint 启用 MINIMAL 规则集并豁免 PACKAGE_DIRECTORY_MATCH，避免 proto 目录与 package 名强一致带来的迁移成本。
2. 建立 CI 校验链路：新增 .github/workflows/buf.yml，PR 事件命中 rust/proto/** 或 workflow 自身时，用 bufbuild/buf-action（固定 commit 8c6a16e，即 v1.5.0）配合 Buf CLI 1.72.0 执行 build 与 lint；format、breaking、pr_comment、push 全部关闭，fork 贡献者无需 BUF_TOKEN 也能完成校验。
3. 配置发布策略：schedule cron（0 8 * * ）与 workflow_dispatch 触发 nightly 发布；push v tag 触发 release 发布，通过 buf push 更新 main 标签并发布 ${GITHUB_REF_NAME} 对应的版本标签，两条路径都带 --create 与 --create-default-label main 参数，并记录 source-control-url 便于溯源。
4. 文档与运维前置：新增 rust/proto/README.md 与 rust/proto/buf.md，说明 schema 权威来源、标签语义、不可变 pinning 和一次性仓库设置；合并后需在 vllm-project 的 Buf 组织配置权限、添加 BUF_TOKEN secret，并为 main/nightly 标签预注册 Prost/Tonic 生成的 SDK。未新增自动化测试，依赖 buf lint/build、pre-commit 与 Buildkite CI 冒烟。

关键文件：

• .github/workflows/buf.yml（模块 CI工作流；类别 infra；类型 infrastructure）: 核心发布工作流：组合 buf-action 的 PR 校验与 buf push 的 nightly/release 发布逻辑，是本次变更的主体。
• rust/proto/buf.yaml（模块 协议配置；类别 config；类型 configuration）: 定义 Buf v2 模块与 lint 规则，声明模块根和公共命名空间 buf.build/vllm-project/vllm，是发布到 BSR 的配置根基。
• rust/proto/README.md（模块 发布文档；类别 docs；类型 documentation）: 面向 schema 消费者的发布说明，记录发布节奏、不可变 pinning 与 BUF_TOKEN 前置条件。
• rust/proto/buf.md（模块 接口文档；类别 docs；类型 documentation）: 简述 Rust 前端 gRPC 服务的 Inference 与 Control 接口及标签语义，帮助消费者理解协议范围。

关键符号：未识别

评论区精华

该 PR 几乎没有实质性设计讨论：claude[bot] 仅提示 PR 来自 fork、自动 review 被禁用，维护者可通过 @claude review 手动触发；njhill 直接 APPROVED，原话为 “Thanks @connorcarpenter15 lgtm cc @khluu”，并 @ 了 Rust 前端维护者 khluu 以便知会。没有未解决疑虑或争议点，评审结论是变更范围清晰、风险可控。

• 暂无高价值评论线程

风险与影响

• 风险：
  • 依赖外部 BUF_TOKEN secret：nightly 与 release 发布路径的 token 注入限定在主仓库的非 PR 事件；若合并后未配置 secret，定时发布与 release 推送会因无凭据失败，PR 路径不受影响。
  • 首次创建模块依赖 Buf 组织权限：workflow 里的 --create 要求 token 具备创建公共模块的权限，若 vllm-project 组织未创建或授权不足，首次推送即失败且无法自愈。
  • 外部服务可用性：schedule 事件每天执行一次，Buf 服务不可用只会造成发布 job 失败与 CI 噪音，不影响推理主链路。
  • 标签语义依赖 tag 命名：release 路径直接用 ${GITHUB_REF_NAME} 作为 label，尽管 push 触发器限定 v* 前缀，非语义化 tag 仍可能产生不理想标签。
  • 无新增测试：纯配置与文档变更，校验主要靠 buf lint/build 和人工预演，风险可接受。
• 影响：
  • 对用户：gRPC 消费者可从 buf.build/vllm-project/vllm 拉取 schema，用 Buf commit 或生成 SDK 版本实现可复现依赖；nightly 标签每日更新，main 与版本标签随 release 节奏更新。
  • 对系统：仅新增 CI 工作流与文档，不改动 Protobuf wire schema、生成绑定和运行时行为，推理路径零影响。
  • 对团队：需要一次性完成 Buf 组织授权、BUF_TOKEN secret 配置与 Prost/Tonic SDK 预注册；后续所有 rust/proto 变更都会经过 Buf 校验，等于给协议演进加了一道质量门禁。
  • 风险标记：依赖外部 BUF_TOKEN secret, 首次发布依赖 Buf 组织授权, schedule 依赖第三方服务可用性, 标签语义直接映射 GITHUB_REF_NAME, 无自动化测试

关联脉络

• 暂无明显关联 PR