# kpt 与 Porch 应用案例及 GitOps 实践调研报告

版本：v1.1
更新日期：2026-11-10

> **研究方式：** 2026-11-09 对 kpt/Porch 的官方发布记录、官方文档、项目治理材料、CNCF 博客与 Nephio 文档做了一手核验，并结合多模型独立研判。搜索工具只用于发现线索，二手聚合站未作为证据；未运行 kpt/Porch，未访谈采用方。定稿阶段（2026-11-10）对 kpt v1.0.0 与 v1.0.1 发布记录、版本政策、治理条款、Porch 兼容页与 Nephio Release 6 页面做了抽查，并补查了项目治理仓库的采用者名单、kpt CLI 的 `pkg update` 参考页与 CNCF 项目页；除新补查的采用者名单与包更新文档外，其余结论与 2026-11-09 的核验记录一致（CNCF 项目页的贡献组织数由 94 变为 93，已在 3.1 标注为动态值）。核验范围、直接来源与限制见 2.3 与附录 B。
> **证据口径：** 见 2.2。

## 一、执行摘要

本报告针对 2026-11-05 CNCF 博客刊出的 kpt v1.0.0 公告展开，回答它在业界的实际使用情况、与 GitOps 的实际结合方式、可获得的收益，以及应否采纳、趋势如何。与初版相比，本版补齐了对官方发布记录、文档与治理材料的一手核验，并纠正了发布状态与版本口径。

**核心结论：这项技术的价值真实存在，但价值点与传播口径并不一致；发布已经核实，稳定性承诺却比公告措辞窄得多；目前仍缺少足以支撑“业界广泛使用”的公开证据。** 具体如下。

1. **发布与版本已核实，但要按日期与版本分别理解。** kpt v1.0.0 的 GitHub 发布日为 2026-08-31（[Release v1.0.0](https://api.github.com/repos/kptdev/kpt/releases/tags/v1.0.0)），CNCF 博客公告日为 2026-11-05（[CNCF 博客](https://www.cncf.io/blog/2026/11/05/kpt-v1-0-0-is-released/)）；两者相差约两个月，不能合并成一个“发布时间”。截至本次核验，最新的非预发布补丁为 2026-09-25 发布的 v1.0.1，v1.0.2 仍在预发布（[Release v1.0.1](https://api.github.com/repos/kptdev/kpt/releases/tags/v1.0.1)、[Releases](https://api.github.com/repos/kptdev/kpt/releases?per_page=15)）。
2. **v1.0 不等于“全面稳定”。** 官方版本政策采用修改过的语义化版本：包格式不得改变、子命令与命令行参数不得删除，但 minor 版本仍可包含破坏性变更，且与特定 Kubernetes 版本的兼容策略尚未定义（[VERSIONING.md](https://raw.githubusercontent.com/kptdev/governance/main/VERSIONING.md)）。公告中“所有组件都已稳定”属项目方主张，不是独立验证。
3. **kpt 与 Porch 是两个层次的东西。** kpt 是面向 Kubernetes 资源模型（KRM）的配置包工具链，可完全在本地或 CI 中使用；Porch 是可选的包编排服务，把包的修订、审批与发布搬到集群内。**引入了 kpt 不等于必须部署 Porch**〔判断：Porch 不替代 kpt，kpt CLI 可独立使用；“可选”为架构推论〕。
4. **在 GitOps 体系中，两者的主要位置是上游“配置创作与渲染”层，但“kpt 完全不参与部署”的说法过强。** Porch 明确不是部署工具、不提供包仓库、不替代 kpt，部署由 Flux、Argo CD 或 Config Sync 完成（[Porch Overview](https://porch.kpt.dev/docs/1_overview/)）；kpt 工具链自身则包含 `kpt live apply`，Nephio 的官方安装流程实际使用它（[Nephio 安装文档](https://docs.nephio.org/docs/guides/install-guides/common-components/)）。`kpt live apply` 是命令式的一次性 apply 与等待，本次未取得其提供常驻漂移协调的直接说明，不能把它当作持续协调器的等价替代〔判断〕。
5. **“零接触”自动化的是包修订的生成、审批流转与发布，不是集群同步，更不是免运维。** 该词出自项目方公告，属定位表述（[CNCF 博客](https://www.cncf.io/blog/2026/11/05/kpt-v1-0-0-is-released/)）；审批决策本身仍由组织承担（5.4）。
6. **“无模板”不是 kpt 独有的优势。** Kustomize 同样不依赖模板；kpt 官方 FAQ 把两者的差异描述为“就地定制（WYSIWYG, in-place）”与“异地 overlay（out-of-place）”之别，并明确两者可以组合使用（[kpt FAQ](https://kpt.dev/faq/)）。kpt 真正区别于既有组合的是“KRM 原生函数 + 包修订生命周期 + 上游包跟随”，而不是“不用模板”本身。
7. **公开可核实的采用证据总体稀缺，但并非空白。** 本次检索覆盖发布前后的公开线索，可核实的项目级集成是 Nephio：其 Release 6 集成 Porch v1.5.6，安装文档实际使用 kpt 命令（[Nephio R6](https://nephio.org/nephio-release-6-strengthening-stability-and-security/)、[安装文档](https://docs.nephio.org/docs/guides/install-guides/common-components/)）。此外，项目治理仓库的采用者名单载有一条 **Nokia 的产品使用声明**：采用级别原文为 “Production as part of the NCOM Evo Suite product”（[采用者名单](https://github.com/kptdev/governance/blob/main/adopters.md)〔已核实名单条目；属项目方名单中的自述，使用实际未独立核实〕）。该名单不在 kpt 主仓，主仓根目录确实没有 ADOPTERS/USERS 文件（[仓库根目录](https://api.github.com/repos/kptdev/kpt/contents/)）。项目级集成、名单条目与演示不能等同于经独立核实的生产采用；本次**未取得**可指名的非电信企业生产案例，也未取得运行范围、维护经验与量化收益。“未取得”不等于“不存在”。
8. **收益目前基本停留在设计意图。** 配置可审计、结构化变更可审、包生命周期管理、多环境变体、策略前移等收益都有清晰的设计逻辑与可度量指标，但没有可公开引用的量化结果。其中多数在“Kustomize 或 Helm + CI 策略校验 + Argo CD”组合下同样可以获得。
9. **成本是明确的、可预估的。** 学习曲线、额外控制面运维、函数镜像供应链（函数按任意代码执行对待）、生态与人力的可得性，这四项构成采用的主要代价；此外还有 minor 破坏性变更带来的持续升级回归，以及 Porch 对 Kubernetes 最低版本的要求（当前文档为 1.37.0）〔已核实〕；由旧集群与非主流发行版带来的适配成本属本报告判断〔判断〕。
10. **建议：不要因为一则发布消息而采用。** 若确实存在“大量配置包的派生、上游跟随与修订审批”痛点，或确有现有工具难以表达的程序化变换需求，按“先只做 CLI 渲染、接入现有 CI 与 GitOps，再按需评估 Porch”的路径做一次同负载对照试点，并始终保留退回纯 YAML 的路径。若痛点是模板可读性或简单环境差异，Kustomize 或 Helm 仍然是更经济的选择。
11. **趋势判断：稳定的小众。** kpt 更可能在电信、边缘与重度平台工程场景中长期存续，成为通用企业 GitOps 默认渲染层的概率很低〔判断〕。具体命题、未校准的概率区间与推翻条件见第十一章；证据可信度整体为中低至低。

> **必须同时说明的三点边界。** 其一，**博客刊载不等于 CNCF 官方背书，也不等于项目晋级**：kpt 是 CNCF Sandbox 项目，2023-06-30 获接受，不是 Incubating 或 Graduated（[CNCF 项目页](https://www.cncf.io/projects/kpt/)）；2026-07 博客所称“近期完成 onboard”（原文为 fully onboarded，此处为中译）是另一个时点，两者不可合并成“2026 年加入 CNCF”。其二，**公告中的“所有组件稳定”“已准备好被广泛采用”“零接触 GitOps”是项目方主张**，本次没有独立第三方验证。其三，**发布、包修订审批与集群部署批准是三件事**：发布已经核实，不代表任何组织的部署获批或变更已生效。

## 二、调研范围、方法与证据边界

### 2.1 调研问题

议题提出的问题可拆为五组，本报告按此组织：

| 组 | 问题 | 对应章节 |
|---|---|---|
| 是什么 | kpt 与 Porch 各自定位、核心概念、版本与成熟度 | 第三章 |
| 用得怎样 | 业界实际使用案例、可指名采用者、厂商支持 | 第四章 |
| 怎么用 | 与 Argo CD、Flux 等 GitOps 工作流的结合方式，“无模板”的真实差异 | 第五章 |
| 值不值 | 优势与收益、局限与成本、替代方案对比、采纳路径 | 第六至九章 |
| 往哪走 | 趋势判断、风险与合规、置信度与反例条件 | 第十至十一章 |

### 2.2 证据分级

本报告采用四级标注，**以分节框架标注为主**：比较表与推断段落按所在节标为〔判断〕，5.2、5.3、6.1、7.2、8.1 与第十章的表已逐表标注；个别行句未逐一加标时，先以所在节的标注为准，所在节没有节级标注时按下一段的默认规则处理。

| 级别 | 含义 | 标注方式 |
|---|---|---|
| **已核实** | 本次直接打开来源，字段或表述与所引摘录相符 | 〔已核实〕；仅表示“来源中存在该表述或字段”，不表示项目方的效果主张已被独立验证 |
| **项目方主张** | 来源为项目方公告、文档自述或营销表述，未获独立验证 | 〔项目方主张〕 |
| **判断** | 本报告的推断、取舍建议与预测 | 〔判断〕 |
| **未取得** | 本次检索没有找到可指名的材料；不等于“不存在” | 〔未取得〕 |

需要特别提醒：**“已核实”不等于“效果好”，“未取得”也不等于“不存在”。** 前者只说明来源中确有该表述或字段；后者只说明本次检索的覆盖范围内没有找到可指名材料。凡涉及决策的关键项，读者应以官方仓库、版本说明与自身试点结果替换本报告的相应表述。

### 2.3 本次核验做了什么、没做什么

**实际执行（2026-11-09；注明 2026-11-10 的项目为定稿阶段补查）：**

- 直接读取 GitHub REST API：kpt 的 v1.0.0、v1.0.1 发布记录与发布列表，仓库元数据与根目录文件列表；Porch 的 v1.6.0 发布记录、发布列表与仓库元数据。
- 直接打开官方文档：kpt 的入门、包、FAQ、迁移页面与 `kpt pkg update` 命令参考（后者于 2026-11-10 补查）；Porch 的 Overview、Glossary、Architecture 与 Compatibility 页面。
- 直接打开项目与社区材料：CNCF 项目页、CNCF 博客两篇（2026-07-02、2026-11-05）、kptdev/governance 仓库与 `VERSIONING.md`、该仓库的采用者名单 `adopters.md`（2026-11-10 补查）、Nephio Release 6 公告与安装文档、Kubeflow GKE 部署文档、kpt/Porch 创建者的第一人称博客。
- 使用搜索工具补充检索采用案例，检索词覆盖发布前后；搜索结果仅用于发现线索，未把搜索摘要或二手聚合站当作证据。

**没有做：** 未运行 kpt 或 Porch，未审计任何函数镜像，未联系采用方或运营商，未取得任何企业访谈、生产运行范围或量化收益数据。因此本报告对收益、成本与风险的量化表述一律为判断，不冒充实测。

**覆盖限制（如实记录）：**

1. GitHub 发布列表 API 的响应超过读取长度上限，v1.0.1 的发布日期改由单独的 tag API 取得；这是读取方式限制，不是来源缺失。
2. 创建者博客页面未显示署名与日期，只能作为“作者自述”材料，署名与日期标为部分核实。
3. kpt 迁移文档仍停留在 2021 年“v1.0 预发布”的语境，只能用于迁移事实，不能用于描述 2026 年的项目状态。
4. 三组采用案例检索的结果以官方文档、发布说明、创建者博客与二手聚合站为主；二手站疑似自动生成或转述，未作证据升级。
5. 采用统计不限于“发布后新增”，也覆盖存量公开线索，以免只统计新事件而遗漏既有采用；即便如此仍未取得可独立核实的具名生产案例（官方名单中的 Nokia 条目为采用方自述，见 4.2）。
6. GitHub API 字段为本次读取时点值；本报告未留存响应 ETag、Release ID 或页面快照，复核时以同一 URL 与 2026-11-09 的读取日期为准。
7. CNCF 项目页的贡献者与贡献组织数是动态指标：2026-11-09 读取为 246 名贡献者、94 个贡献组织，2026-11-10 复核时组织数为 93。正文按读取日期标注，且两数均不参与任何结论。

### 2.4 关键事实的当前证据状态

| 事实 | 当前结论 | 级别 | 主要来源 |
|---|---|---|---|
| kpt v1.0.0 发布 | GitHub tag 于 2026-08-31 发布，非预发布 | 已核实 | v1.0.0 Release API |
| 公告日期 | CNCF 博客 2026-11-05 刊出 | 已核实 | CNCF 博客 |
| 当前版本序列 | v1.0.1 为非预发布补丁；v1.0.2 仍在预发布 | 已核实 | v1.0.1、Releases API |
| 项目成熟度 | CNCF Sandbox，2023-06-30 接受；非 Incubating/Graduated | 已核实 | CNCF 项目页、governance |
| 兼容承诺 | 包格式不变、CLI 子命令与参数不删除；minor 可破坏；K8s 兼容未定义 | 已核实 | VERSIONING.md |
| Porch 能力边界 | 不部署、不提供包仓库、不替代 kpt | 已核实 | Porch Overview |
| Porch 版本与 API | 服务端 v1.6.3；推荐 API 模块 1.0.1；PackageRevision 仍为 v1alpha1/v1alpha2 | 已核实 | Compatibility、Glossary |
| Kubernetes 要求 | 最低与最新测试版本均为 1.37.0；范围外未正式验证 | 已核实 | Compatibility |
| Nephio 集成 | R6 集成 Porch v1.5.6；安装流程使用 kpt 命令 | 已核实（项目级） | Nephio R6、安装文档 |
| 官方采用者名单 | 治理仓库 adopters.md 载 Nokia：`Production as part of the NCOM Evo Suite product` | 已核实（名单条目；自述，未独立核实） | 治理仓库 adopters.md |
| 具名非电信生产案例与运行数据 | 本次检索未取得；kpt 主仓无 ADOPTERS/USERS 文件 | 未取得（主仓文件缺失已核实） | 检索、仓库根目录 |
| 量化收益 | 本次检索未取得 | 未取得 | 检索 |

## 三、kpt 与 Porch 的定位

### 3.1 kpt：以数据为中心的配置包工具链

kpt 的核心主张是把 Kubernetes 配置当作**结构化数据**来管理，而不是当作需要渲染的模板程序。官方文档把包定义为“一个由人类可读 YAML 文件组成的普通目录”，`Kptfile` 当前示例为 `apiVersion: kpt.dev/v1`；函数以容器分发，读取 YAML、做变异或校验后输出 YAML；渲染按包层级深度优先执行函数（[The kpt Book：包](https://kpt.dev/book/03-packages/)）。〔已核实〕

| 概念 | 含义 | 为什么重要 |
|---|---|---|
| **KRM** | Kubernetes Resource Model，即 `apiVersion`、`kind`、`metadata`、`spec`、`status` 构成的资源模型；这是通用 Kubernetes 术语，不是 kpt 专有定义 | 所有工具的输入输出都是资源列表；**以 KRM 对象表达不等于通过 API 模式与准入校验**（见 3.4、9.3） |
| **Config-as-Data** | 源文件就是最终形态的 YAML，通过函数对数据流做变换 | 与“模板 + 参数”相对：没有渲染期的字符串插值，因此消除的是模板期插值故障；函数自身的类型转换、目标集群的模式校验仍可能出错 |
| **包（package）** | 一个普通目录加一份 `Kptfile`（包元数据、函数流水线声明、上游来源） | 包是可整体拉取、升级、发布的分发单位（[文档](https://kpt.dev/book/03-packages/)） |
| **函数（function）** | 读取 ResourceList、输出变异后 ResourceList 的程序，通常以容器镜像形式分发，分变异（mutator）与校验（validator）两类 | 变换逻辑与配置数据分离；函数可复用、可版本化，也因此成为主要的安全面 |
| **流水线与渲染** | 按 `Kptfile` 中声明的顺序执行函数，得到最终资源 | “渲染”在这里指执行函数链，而不是展开模板；官方文档称按包层级深度优先执行 |
| **变体（variant）** | 同一上游包针对不同环境派生出不同配置 | 多环境管理的落点；早期以 setter/substitution 表达，后逐步让位于函数〔判断，具体演进细节本次未取得直接说明〕 |

版本与成熟度方面，本次可以给出可核实的序列：仓库创建于 2019-09-16；迁移页标题为“Migrating from kpt v0.39 to v1.0”，表明从 v0.39 到 v1.0 经历过一次明显重构，迁移文档明确 `v1alpha1` 的 `Kptfile` 格式与 v1.0 不兼容，并移除了 `cfg` 子命令组（[迁移文档](https://kpt.dev/installation/migration/)）〔迁移事实部分核实：该页仍停留 2021 年语境，不能用于描述 2026 年状态〕；v1.0.0 于 2026-08-31 发布，v1.0.1 于 2026-09-25 发布，v1.0.2 仍为预发布（[Release v1.0.0](https://api.github.com/repos/kptdev/kpt/releases/tags/v1.0.0)、[Releases](https://api.github.com/repos/kptdev/kpt/releases?per_page=15)）。〔已核实〕同一预发布构建另以 `cli/v1.0.2-pre.4` 标签发布，其 `prerelease` 字段为 `false`；这属标签命名差异，不能据此判为稳定版。迁移页面仍把 v1.0 二进制称作“预发布版本”，这是文档未更新，不能用来描述 2026 年的项目状态。

项目治理身份：kpt 是 CNCF Sandbox 项目，2023-06-30 获接受，不是 Incubating 或 Graduated；治理仓库规定每个仓库设两名 code owner，所有 PR 应由两名 code owner 共同批准（原文为 should，此处译为“应”），且两名 code owner 不得来自同一公司（[CNCF 项目页](https://www.cncf.io/projects/kpt/)、[kptdev/governance](https://github.com/kptdev/governance)）。〔已核实〕这是治理规范，不证明实际执行率、投入规模或商业支持。2026-07-02 的 CNCF 博客（[原文](https://www.cncf.io/blog/2026/07/02/reintroducing-kpt-your-toolchain-for-infrastructure-automation/)）称项目“近期已作为 Sandbox 项目完成 onboard”，这是另一个时点；它与 2023 年的接受日期不可混写，也不表示项目晋级。项目页在 2026-11-09 显示 246 名贡献者、94 个贡献组织（2026-11-10 复核时组织数为 93）；这些是动态的贡献指标，不是采用者数量，不能用来支撑“广泛使用”。

**在 2026-08-31 之前长期未发布正式 1.0，这一历史判断仍然成立；但“版本序列无法复述”已过时。** 版本号本身不是成熟度证明：1.0 只说明项目愿意做出有限的兼容承诺（见 7.4），不说明生产可靠性、生态规模或商业支持。

### 3.2 Porch：可选的包编排服务

Porch 的官方定义是“一个基于 Kubernetes、用于管理存储在 Git 仓库中的 KRM 配置包生命周期的系统”（原文为英文，此处为中译），它属于 kpt 项目；官方同时明确：**Porch 不是部署工具，不把包部署到集群，不提供包仓库，也不替代 kpt；部署由 Flux、Argo CD 或 Config Sync 等 GitOps 工具完成**（[Porch Overview](https://porch.kpt.dev/docs/1_overview/)）。〔已核实〕

- **生命周期语义**：包修订有 Draft（编写中）、Proposed（待审）、Published（已批准并定稿）三个阶段；`Repository` 资源把 Porch 连接到 Git 仓库或 OCI 仓库；`PackageVariant` 自动完成包克隆与更新（[Porch Glossary](https://porch.kpt.dev/docs/11_glossary/)）。〔已核实〕这里的“审批”是包修订阶段的门禁，不等于集群部署审批，也不等于变更已生效。
- **架构**：第一代 v1alpha1 采用聚合 API 服务器加自定义 REST 存储，操作在请求路径内同步完成；第二代 v1alpha2 改为 CRD 控制器，是当前开发重点，但需按仓库通过注解 opt-in；函数求值由 Engine 负责，包括 pod evaluator（[Porch Architecture](https://porch.kpt.dev/docs/5_architecture_and_components/)）。〔已核实〕“开发重点”不等于默认启用或已经稳定。
- **版本与迁移**：当前稳定服务端为 v1.6.3（文档标注 2026-07-30，GitHub Release 记录 2026-07-31）；稳定服务端推荐的 API 模块为 1.0.1；v1alpha1 受支持且未宣布 EOL，v1alpha2 仍在开发、按仓库 opt-in；v1.6.4 系列仍为预发布（[Compatibility](https://porch.kpt.dev/docs/3_getting_started/compatibility/)、[Porch Releases](https://api.github.com/repos/kptdev/porch/releases?per_page=8)）。〔已核实〕API 模块 1.0.3 的 GitHub 发布记录标注为非预发布（2026-09-29），但兼容页把它列为 v1.6.4 预发布系列的推荐模块并标为预发布；两处口径不一，本报告不把 1.0.3 当作稳定服务端的推荐版本。Porch 于 2023-12 捐给 Nephio，2026-05 回到 kptdev；v1.6.0（2026-06-29）是回归后的首个版本，发布说明同时说明 v1alpha2 已引入但 v1alpha1 仍是默认 API（[porch README](https://github.com/kptdev/porch)、[v1.6.0 Release](https://api.github.com/repos/kptdev/porch/releases/tags/v1.6.0)）。〔已核实〕该仓库创建于 2023-12-18（即捐给 Nephio 之时，而非回归后新建），其星数（23）与开放 issue 数（182）不能与 kpt 主仓直接比较，也不能用来判断历史影响力。
- **依赖与运维成本**：一个 Kubernetes 集群、可用的 Git 或 OCI 仓库与凭据、函数执行环境、一组自定义资源与 RBAC 配置。对中小团队而言相当于“多养一套控制面”。它不是数据面组件，故障时通常不影响已部署的工作负载，但这一结论以“没有其他运行依赖指向 Porch”为前提；它仍会阻塞包发布流程〔判断〕。

### 3.3 两者的分工

```mermaid
flowchart LR
    subgraph AUTHOR["配置创作与渲染"]
        A["源包<br/>Kptfile + KRM 资源"] --> B["kpt fn render<br/>函数链变换与校验"]
    end
    B --> C["渲染产物<br/>纯 KRM YAML"]
    C --> D["Git 仓库"]
    D --> E["Argo CD / Flux / Config Sync<br/>持续协调与漂移检测"]
    E --> F["目标集群"]
    C -.->|"可选：kpt live apply<br/>一次性 apply 与等待"| F
    C --> G["Porch（可选）<br/>包修订 草稿→提议→发布"]
    G -->|"发布到 Git 分支"| D
    G -.->|"可选：控制器直读包修订<br/>适配实现未核实"| E
```

这张图说明本报告推荐的生产路径：**渲染产物进入 Git，由既有 GitOps 控制器持续协调**。这条路径不需要 Porch，也不需要 `kpt live`，这也是它容易试点、容易退出的原因。

但必须修正初版的一个过强表述：**kpt 工具链不只是“产出配置”。** 官方 FAQ 在说明与 Kustomize 的组合方式时称 “use kpt for packaging and actuation, and kustomize for customization”（[kpt FAQ](https://kpt.dev/faq/)）；Nephio 的安装文档实际使用 `kpt pkg get --for-deployment`、`kpt fn render`、`kpt live init`、`kpt live apply --reconcile-timeout=15m`（[Nephio 安装文档](https://docs.nephio.org/docs/guides/install-guides/common-components/)；命令原文见附录 B 第 21 条）。〔已核实〕因此，“kpt/Porch 的产出只是已渲染配置、部署完全由下游完成”的说法不准确。准确的界定是：**Porch 不部署；kpt 的 `live apply` 可以做命令式的一次性 apply 与等待，但本次未取得其提供常驻漂移协调的直接说明，因此它不构成 Argo CD/Flux 这类持续协调器的等价替代〔判断〕。**

图中经 Porch 的一支是可选叠加，不是必经环节。模式二下，控制器可直接读取包修订（图中虚线），或由 Porch 写入发布分支经 Git 交接（图中实线）；两种情况下 Git 仍可作为审计与回滚载体，但不再是唯一的交接点。虚线只表示一种候选集成路径，本次未核实是否存在现成的适配实现，实际可用的接口、权限与网络边界须按所选发行物评估。

### 3.4 “零接触、无模板”应当如何理解

这两个词是发布方的**定位表述**，不是可验证的能力承诺，应当拆成子命题分别检验：

- **“无模板”**可检验为：配置在创作与渲染链路上以 KRM 对象表达、变更可以直接 diff。这一条在机制上成立，但**Kustomize 同样成立**，因此不构成 kpt 相对 Kustomize 的差异。需要注意：**“无模板”推不出“任意阶段的资源都合法或能通过模式与准入校验”**；渲染产物是否有效，取决于函数实现、目标集群的 API 模式与准入策略，仍须单独验证〔判断〕。
- **“零接触”**可检验为：包修订的生成、审批流转与发布是否无需人工介入（审批决策本身仍由组织承担，见 5.4）。实际上审批策略、凭据轮换、函数参数编排、流水线调试与状态机维护都需要显式配置与人工决策；把它读作“免运维”或“无需人工决策”是误读〔判断〕。项目方公告中的 “zero-touch GitOps” 属〔项目方主张〕，不是独立验证的自动化程度。

## 四、业界实际使用情况

### 4.1 证据现状：稀缺，而不是繁荣

本次检索覆盖发布前后的公开线索，结论是：**除项目治理仓库采用者名单中的一条自述条目外，没有取得可独立核实的、可指名的非电信企业生产采用案例，也没有取得任何企业级生产运行范围、维护主体或故障经验。** 该名单载有 Nokia 的 NCOM Evo Suite 产品使用声明（4.2），但名单自行说明所列组织为公开分享或授权列名、且不穷尽，条目不含运行规模、维护经验与收益，本次未能独立核实。上述表述另有三重限定：其一，受检索覆盖与知识边界限制，“未取得”不等于“不存在”；其二，公开证据本身以项目文档、会议材料与项目方公告为主，缺少独立第三方的采用率与规模数据；其三，名单条目是采用方自述，不是独立审计结果。

可以采用的事实有：kpt 仓库根目录不存在 `ADOPTERS.md`、`ADOPTERS`、`USERS.md` 或 `USERS` 文件，README 也没有列出 “Used by” 条目（[仓库根目录](https://api.github.com/repos/kptdev/kpt/contents/)）；采用者名单位于项目治理仓库，而非主仓，其中列有 Nokia 一条（[采用者名单](https://github.com/kptdev/governance/blob/main/adopters.md)）。CNCF 博客的公告正文没有出现 “production”，也没有具名采用者（[CNCF 博客](https://www.cncf.io/blog/2026/11/05/kpt-v1-0-0-is-released/)）。但“未列出”不等于“未使用”，没有名单也不能证明无人生产使用；反过来，名单条目也不能单独证明部署规模或实际收益。

统计口径说明：本报告的“采用”分两层——**试点采用**指可指名的组织公开说明正在试用，只能证明试点使用；**生产采用**指已投入生产运行，只有这一层能支撑“业界实际使用”的结论。统计不限于发布后新增的线索，也包含存量公开材料；本报告单列的项目级集成是 Nephio，它早于本次发布，只说明工具链在特定语境中已有使用场景，不作为“发布带来采用增长”的证据。官方采用者名单中的 Nokia 条目作为采用方自述单列（4.2），同样不计入经独立核实的生产案例。

### 4.2 已知线索及其证明力

| 线索 | 性质 | 已核实内容 | 能证明什么 | 不能证明什么 |
|---|---|---|---|---|
| **Nokia（NCOM Evo Suite）**〔已核实：官方名单条目；使用实际未独立核实〕 | 厂商产品使用声明（自述） | 项目治理仓库采用者名单的 Adoption Level 为 “Production as part of the NCOM Evo Suite product”；名单说明所列组织为公开分享或授权列名，且“not exhaustive” | 一家具名厂商公开声明其产品在生产中使用 kpt，与 4.3 所述“生态位偏垂直”的判断方向一致 | 不能证明部署规模、运行范围、维护主体、故障经验或量化收益；不是独立核实，也不证明 Porch 被采用；条目没有引用链接 |
| **Nephio** 以 Porch 作为包编排层〔已核实：R6 列 Porch v1.5.6 且安装用 kpt；“包编排层”为结合 Porch 定位的解释〕 | 项目级集成与官方安装流程 | Release 6 集成 Porch v1.5.6（页面更新于 2026-04-01）；安装文档使用 `kpt pkg get --for-deployment`、`kpt fn render`、`kpt live init`、`kpt live apply` | 该工具链在电信云原生自动化语境下有真实的项目级使用与维护投入 | 不能证明某家运营商已在生产环境规模化运行，不能证明收益，也不能证明发布后新增采用 |
| GoogleCloudPlatform 的 Kubeflow GKE 文档曾用 kpt 拉包并调用函数〔已核实〕 | 工具使用旁证 | 2023-03-30 的页面含 `kpt pkg get` 与 `kpt fn eval -i list-setters:v0.1` | 2023 年确有上游文档在安装流程中使用 kpt | 不证明 Porch 被采用，不证明 2026 年仍在使用；初版所称“Google Cloud 配置管理产品线安装文档曾用 kpt”在本次核验中没有找到直接对应的页面，已由本条替代 |
| kpt/Porch 创建者的第一人称叙述〔部分核实〕 | 设计动机 | 页面称 kpt 意在补齐 Kustomize 的缺口，管理大量 WET 变体需要更多编排，Porch 后来先进入 Nephio、再回到 kpt 项目；页面未显示署名与日期 | 说明设计动机与项目分合的历史脉络 | 属作者自述，不是独立采用证据；不写死署名与日期 |
| 社区会议演讲与项目文档 | 项目演示 | 存在活跃的技术社区与文档维护 | 项目仍在维护 | 不构成生产采用证据 |

需要提醒：厂商维度现有两类材料——Nokia 的官方名单自述条目（产品生产使用声明，无规模、维护与收益数据）与 Kubeflow GKE 文档这一条 2023 年的工具使用旁证（附录 B 第 22 条）。前者是采用方自述而非独立支持证据，后者只是工具使用旁证；两者合起来仍不足以形成“厂商生态支持广泛”的印象。该维度在议题中不是必答项，本报告不据此下结论。名单条目在附录 B 第 27 条登记，读取日期为 2026-11-10；该文件在 2026-10-29 的治理仓库提交中即已存在，早于本次核验。

### 4.3 案例稀少的结构性原因

与其说这是“尚未被发现的机会”，不如说有三个结构性原因〔判断〕：

1. **功能与既有工具高度重叠。** Kustomize 已内置于 kubectl 并被 Argo CD、Flux 原生支持，Helm 生态巨大而成熟；kpt 的差异化空间被持续压缩。
2. **引入成本落在平台团队身上。** 函数编写、镜像治理、流水线与（可选的）Porch 控制面运维，都需要专职平台工程能力，而收益主要在大规模、多集群、强审批场景才显现。
3. **生态位偏垂直。** 项目与电信、边缘自动化的结合最深（Nephio 的集成是最直接的项目级线索）；官方采用者名单中唯一的具名使用也来自单一厂商的产品线（4.2），且不含行业分布数据。这既是它的护城河，也限制了它在通用企业市场的扩散。

### 4.4 如何正确引用“案例”

若后续要补充案例，应按证据强度分层，且不得跨层外推：**项目演示 → 参考架构 → 厂商集成 → 客户试点 → 生产部署**。这个阶梯表示的是**证明范围**，不是项目必然经历的演进过程。客户试点可证明该组织确实在试用，但不能证明生产规模、持续运行或收益；只有生产部署一层能支撑“业界实际使用”的结论，且需要同时给出运行范围、维护主体与故障经验。缺少这些要素的材料，只能作为方向示例。

按此阶梯定位 4.2 的线索：Nokia 条目按申报内容属“生产部署”层，但它是名单中的采用方自述，缺运行范围、维护主体与故障经验，且本次未独立核实，因此只能作为“生产使用声明”，证明力低于经独立核实的生产部署记录；Nephio 介于“参考架构”与“厂商集成”之间——它把 Porch 纳入项目级架构并有维护投入，官方安装流程也实际调用 kpt，但本次未见任何单一客户的试点或生产记录，因此不进入第四级；Kubeflow 文档属工具使用旁证，不计入采用阶梯；创建者叙述属设计动机；社区会议与项目文档属“项目演示”层。以上定位为按证据形态作出的判断〔判断〕。另需强调：**发布完成不等于部署批准或变更生效**，任何“已发布即已采用”的推断都不成立。

## 五、与 GitOps 的结合方式

### 5.1 所处环节

kpt/Porch 的主要位置是 GitOps 的**配置创作与渲染（authoring & hydration）层**，位于“人/系统写配置”与“Git 仓库”之间；Argo CD、Flux、Config Sync 等负责从仓库到集群的持续协调。这一分工有官方依据：Porch 明确不部署、不替代 kpt，部署由 GitOps 工具完成（[Porch Overview](https://porch.kpt.dev/docs/1_overview/)）。〔已核实〕

但要把“层”与“能力”分开：kpt 工具链自身包含 `kpt live apply`，具备命令式部署能力；本次未取得其提供常驻漂移检测与持续协调的直接说明，因此不把它按持续协调器评估。因此准确的表述是：**kpt/Porch 不替代持续协调器，但 kpt 并非完全不参与部署。** 这一区分对成本与退出评估很重要——它意味着“只做渲染、不碰集群”是一种可以被采用的架构选择，而不是工具的强制约束〔判断〕。

### 5.2 三种集成方式

下表为结合方式的对照与取舍建议〔判断〕。

| 模式 | 做法 | 优点 | 代价 |
|---|---|---|---|
| **模式一：先渲染后提交**（推荐） | CI 中执行函数渲染并做策略校验，产物提交到环境仓库，Argo CD/Flux 只负责 apply | 最稳、最易审计、最易退出；渲染发生在受限的 CI 环境，凭据暴露面小 | 需要维护渲染流水线；产物仓库会变大 |
| **模式二：Porch 作为配置源** | 控制器从 Porch 的 API 取包修订，或 Porch 直接写入发布分支 | 包级审批流转与版本语义完整，适合多团队协作（审批责任仍由组织承担，具体审批动作可由人工或获授权的自动化执行） | 额外集成、非默认路径，需要评估控制器的凭据与网络边界 |
| **模式三：命令式 apply（`kpt live`）** | 由 CI 或操作者执行 `kpt live apply`，一次性 apply 并等待收敛 | 适合安装、引导与一次性变更；不需要额外控制器 | 本次未取得其提供常驻漂移协调的直接说明；长期生产仍应交给 GitOps 控制器；凭据与执行身份须单独治理 |

实践上更稳妥的顺序是：**先在模式一验证函数与产物质量，确认确有包级治理需求后，再评估模式二。** 模式三可作为安装或迁移期的辅助手段，不应被理解为“用 kpt 取代 GitOps 控制器”。

### 5.3 “无模板”相对 Helm 与 Kustomize 的真实差异

本表为机制对照〔判断〕；除已标注者外，表中产品事实均以官方文档为据。

| 维度 | Helm | Kustomize | kpt |
|---|---|---|---|
| 配置表达 | Go 模板 + values | 基础资源 + overlay/patch | KRM 数据 + 函数链 |
| 是否依赖模板 | 是 | 否 | 否 |
| 变更可读性 | 模板可读性差，values 漂移难审 | 补丁层级深时可读性下降 | 终态 YAML 可直接 diff，但函数行为对评审者不透明 |
| 生态与人力供给 | 最强 | 强，且原生集成 | 弱（基于公开印象的排序，不是统计结果） |
| 程序化变换能力 | 受模板语言限制 | 默认补丁机制受限，外部插件与函数扩展另计 | 强（函数在机制上可做任意变换，含调用外部渲染器；见 8.1 注） |
| 主要代价 | 模板维护成本 | 复杂逻辑表达困难 | 函数工程与镜像供应链 |

“生态与人力供给”一行为基于公开印象的排序〔判断〕，不是统计结果。程序化变换一行的对照限于各工具的默认内置工作流；Kustomize 等工具也可通过外部插件或函数扩展补齐能力，因此缺口评估应同时比较“扩展现有工具”与“引入 kpt”的维护成本，而不能只看默认能力〔判断〕。

结论：**“无模板”是 Helm 与 kpt 之间的差异，不是 kpt 与 Kustomize 之间的差异。** 官方 FAQ 也把两者的区别描述为“就地定制”与“异地 overlay”（翻译），并建议可以组合使用（[kpt FAQ](https://kpt.dev/faq/)）。〔已核实为项目方自述〕对已经在用 Kustomize 的团队，kpt 的吸引力必须来自函数化变换能力与包生命周期管理，而不能来自“无模板”这个说法。反之，若团队被 Helm 模板的维护成本所困，kpt 确实提供了一条不同的路——但要接受函数调试链路更长、评审者更难判断一次变换做了什么。

### 5.4 “零接触”的边界

自动化的是**包修订的生成、流转与发布动作**；不被自动化的是：策略设计与维护、审批决策、异常处置、凭据治理、升级与回滚演练，以及集群侧的部署批准与生效确认。审批流转的自动化不等于审批决策的自动化——审批策略与责任由组织确定，具体审批动作可由人工或获授权的自动化执行。把这些工作全部算进去，才能得到真实的运维成本〔判断〕。

“零接触”也不能覆盖集群同步：Porch 不部署、不提供包仓库（[Porch Overview](https://porch.kpt.dev/docs/1_overview/)）；`kpt live apply` 只做命令式 apply；本次未取得其提供常驻漂移协调的直接说明，因此不按持续协调器评估。把它读作“免运维”“无需人工决策”或“自动同步到集群”，都是对定位表述的误读。

## 六、优势与收益

### 6.1 逐项拆解：设计意图、成立前提与可度量指标

下表全部为**设计意图**，本次调研未取得任何公开量化结果。指标列给出的是“如果要在自己的环境里验证，应该量什么”。

| 收益项 | 设计意图 | 成立前提 | 可度量指标 | 相对默认基线的候选能力差异 |
|---|---|---|---|---|
| **变更全程可审** | 所有变更以 KRM 数据入库，可追溯到具体修订 | 禁止带外修改；渲染只在受控流水线中发生；函数版本与审批记录可关联 | 经评审变更占比、评审时长、配置 diff 行数 | 否（Kustomize + PR 同样可得） |
| **结构化变更比对** | 终态即 YAML，diff 接近最终对象而非模板差异 | 输出经过规范化；评审者能解释函数行为 | 同输入同输出哈希一致率、diff 可解释率 | 部分（能力增量） |
| **包生命周期管理** | 包修订有草稿、提议、发布与审批语义 | 部署 Porch，且有明确的审批流程与仓库凭据治理；职责分离；包修订审批不冒充部署审批 | 发布前置时间、回滚耗时、审批留痕覆盖率 | **是**（实质能力增量，依赖 Porch） |
| **上游包跟随** | 上游包更新可合并到本地定制之上 | 上游包遵循稳定字段约定（版本政策未承诺字段级兼容）；冲突与权限变化须复审 | 升级工时、合并冲突次数 | **是**（实质能力增量，属 CLI 层；官方文档载明拉取上游更新、逐资源三方合并） |
| **多环境变体** | 一套包派生多环境配置 | 环境差异边界清晰、包拆分合理 | 重复配置行数、环境漂移事件数 | 部分（能力增量） |
| **策略前移** | 校验函数在入库前拦截不合规配置 | 策略不可绕过；异常时停止发布而非跳过 | 违规样本拦截率、误报率 | 否（CI 策略校验同样可得） |
| **供应链可固定** | 包与函数可按版本、摘要固定并签名 | 组织实际执行验签、摘要核验与漏洞扫描 | 固定摘要比例、签名覆盖率、验签失败拦截率 | 部分（需自行建设） |

表中标为“部分”的三项（结构化变更比对、多环境变体、供应链可固定）指相对默认组合存在部分“能力增量”；这与 6.2 的“仅两项候选实质增量”并不矛盾——本表按收益项逐项计能力增量，6.2 按“不借外部工程即可原生获得”计实质增量，两处用词与计数口径不同。另需说明三点：其一，程序化变换能力不列入本表，因为它不是一项可独立计量的收益，而是进入评估的第二类需求（6.2、8.3、9.1）；其二，上游包跟随属包工具链（CLI）层能力，不依赖 Porch：官方 `kpt pkg update` 参考文档载明该命令拉取上游变更并合并到本地包，且“kpt performs a 3-way merge for every resource”（附录 B 第 28 条）；这是文档载明的机制，本次未运行验证，也未测试冲突、权限变化与升级回滚的实际表现；其三，“能力增量”是相对本报告所列默认基线的能力判断，不是已测净收益，原生能力不等于组织实际获得的净收益。

### 6.2 哪些是增量，哪些是“同样可获得”

这是本报告认为最需要纠正的一个认知偏差：**上表七项中，只有“包生命周期管理”与“上游包跟随”是 kpt/Porch 相对既有组合的候选实质增量**（此处按“不借外部工程即可原生获得”计；逐项判定与两种计数口径见 6.1 表注）；其余各项，在“Kustomize 或 Helm + CI 策略校验 + Argo CD”的组合下大多可以获得。

这里的“增量”指**相对上述默认组合的原生能力差异**，且是能力层面的候选判断，不是已测净收益。若团队已在既有流水线中自行实现了同等治理（例如自建审批门禁、脚本化的上游跟随与摘要固定），该项对它们不构成增量；评估时应先确认现有方案的实际缺口，而不是按能力清单逐项对标。

因此采用决策应当围绕两个问题展开：**你是否真的有大规模的包派生、上游跟随与修订审批需求？是否存在 Kustomize/Helm 难以表达、必须程序化变换的配置生成需求？** 如果两者都没有，kpt 带来的是额外的工具链，而不是额外的能力。

### 6.3 收益应当怎么验证

三条原则〔判断〕：其一，**同负载对照**——用同一套工作负载、同一组环境差异，分别用现有工具链与 kpt 各做一遍，比较总工时与人工步骤；其二，**区分“设计意图”与“已实现”**——配置文件变少、渲染变快、版本号到 1.0，都不能单独证明整体收益，公告中的“稳定”也不能作为收益证据；其三，**把维护成本算进分子**——函数镜像治理、流水线维护与（若有）Porch 控制面运维的工时，与节省的工时同表对比。

## 七、局限、成本与失败模式

### 7.1 成本项

1. **学习曲线**：KRM 函数、`Kptfile` 流水线、包修订模型三层概念叠加；若引入 Porch，还要再加一层自定义资源与 RBAC。相比 Kustomize 的“会写补丁就能用”，上手门槛明显更高。
2. **控制面运维**：聚合 API 或 CRD 控制器的可用性、证书、仓库凭据轮换、函数执行环境的隔离与配额，都需要长期投入。
3. **函数供应链**：函数是可读写整条资源流的容器，**按任意代码执行对待**。镜像来源、签名、可复现性、逃逸面都必须治理，这是最实质的安全成本；签名只证明来源，不证明行为安全。
4. **生态与人力**：函数与包的生态远小于 Helm chart 生态；熟悉这套工具链的人更难招〔判断〕。
5. **版本升级回归**：官方政策允许 minor 版本包含破坏性变更（[VERSIONING.md](https://raw.githubusercontent.com/kptdev/governance/main/VERSIONING.md)），升级须按版本做回归，不能假定向后兼容。
6. **Kubernetes 适配**：Porch 文档给出的最低与最新测试版本均为 1.37.0，范围外兼容“未正式验证”（[Compatibility](https://porch.kpt.dev/docs/3_getting_started/compatibility/)）。旧集群或非主流发行版需要额外的适配与测试成本。
7. **项目治理的不确定性**：Porch 在 2023-12 捐给 Nephio、2026-05 回到 kptdev，回归后的首个版本是 v1.6.0；治理归属的变化意味着维护连续性需要观察，但它本身不能证明维护投入已出现波动，采用方应把这一点计入长期风险〔判断〕。

最容易被低估的有两项：**函数供应链**（任意代码执行＋镜像治理），以及 **minor 破坏性变更与 Kubernetes 兼容未定义叠加的长期升级成本**。前者是安全面，后者是持续运维面，性质不同，不能互相替代。

### 7.2 失败模式

下表为风险推断与预防建议〔判断〕；具体产品行为仍以所选发行物为准。

| 失败模式 | 机理 | 后果 | 预防 |
|---|---|---|---|
| 函数作恶或越权 | 函数可输出任意资源、访问其运行环境的凭据 | 提权、植入后门、跨租户读取 | 镜像固定摘要与签名、白名单、禁用宿主挂载与外联；按实际执行身份、挂载、网络与凭据逐项收敛 |
| 错误产物经合法审批被反复部署 | 签名与审批确认的是来源与流程，不证明产物行为安全；持续协调会把错误状态反复应用 | 合规外观下的持续性错误 | 最终产物授权校验、审批与发布身份分离、失败拒发；对恶意输出与部分发布做注入测试 |
| 渲染不可重复 | 函数依赖网络、可变镜像或外部状态 | 同输入不同输出，审计与回滚失效 | 固定输入、镜像与环境，连续多次渲染比对 |
| 上游升级覆盖本地意图 | 合并策略不当、字段约定破裂或权限被放大 | 定制丢失或权限被放大 | 升级前 diff 审查、锁定上游版本、冲突与权限变化复审 |
| 版本升级破坏兼容 | minor 版本允许破坏性变更；CLI 子命令与参数虽不得删除，行为仍可能变化 | 渲染或发布中断、流水线失效 | 升级前读版本说明、在隔离环境回归、固定版本 |
| Kubernetes 版本不匹配 | Porch 最低要求 1.37.0，范围外兼容未正式验证 | 服务无法启动或行为异常 | 阶段一核对集群版本；在目标发行版做兼容测试 |
| 状态不一致 | Porch、Git 与集群三方暂时不同步 | 以“已发布”误判“已生效” | 以集群实际状态为准做验收；区分包修订发布与部署生效 |
| 回滚不能撤销副作用 | 回退 Git 提交不会撤销数据迁移、资源删除与外部副作用 | 误以为已恢复 | 演练冻结发布、暂停协调、恢复批准产物；记录不可逆副作用；恢复后复核错误权限不会被重新应用 |
| 包数量爆炸 | 包粒度过细或环境变体过多 | 治理成本反超收益 | 包粒度与变体策略在设计阶段定死 |

### 7.3 社区与维护者风险

仓库当前仍活跃：最近推送时间为 2026-11-06，`archived=false`，`created_at=2019-09-16`；星数 1905、fork 数 277、开放 issue 292（[仓库 API](https://api.github.com/repos/kptdev/kpt)）。〔已核实〕这些数字只能说明仓库仍在活动、待办规模不小；**星数、fork 数与 issue 数都不是采用率、质量或维护健康度的指标**，不能据此推断采用增长或维护衰退。

治理层面，项目规定每个仓库两名 code owner、所有 PR 应由两名 code owner 共同批准（原文为 should，此处译为“应”），且两名 code owner 不同公司（[kptdev/governance](https://github.com/kptdev/governance)），这支持“有基本治理”，但不证明实际执行率、投入规模或商业支持。初版所称“贡献者集中”本次未取得直接统计，只能作为条件性风险：**若主力维护方投入转移，项目存在维护放缓风险；这只能通过仓库活动与发布节奏观察，不能从版本号推断。**〔判断〕

从版本序列看，正式 1.0 直到 2026-08-31 才发布，这是已核实的事实；至于这是否算“迟到多年”，属于评价〔判断〕。而且它同时可能说明项目在打磨稳定性，也可能说明投入有限，不能单独作为成熟度证据〔判断〕。Porch 的治理归属曾在 Nephio 与 kptdev 之间迁移，这一历史也应计入维护连续性风险。

### 7.4 兼容承诺需要分四面核

即使 v1.0.0 已核实，也应当分别核验四件事，不能用一个版本号概括：

1. **包格式（`Kptfile` 的 schema）**：版本政策写明 “Package format MUST NOT change”，这是最强的一层承诺（[VERSIONING.md](https://raw.githubusercontent.com/kptdev/governance/main/VERSIONING.md)）。〔已核实〕
2. **CLI 契约**：子命令 “MUST NOT be removed”、命令行参数 “MUST NOT be deleted”〔已核实〕；但 minor 版本 “may contain breaking changes”，行为与默认值仍可能变化〔判断，由 minor 可破坏推出；来源未单列默认值条款〕。
3. **函数契约（ResourceList 规范）**：本次未取得该规范的独立版本承诺，须按所选函数 SDK 与文档单独核〔未取得〕。
4. **服务端 API（Porch）**：要再分三层——服务端发行版（v1.6.3 稳定）、API 模块（推荐版本 1.0.1；1.0.3 的发布记录与兼容页口径不一，见 3.2，本报告不将其列为稳定服务端的推荐版本）、PackageRevision API 表面（v1alpha1 受支持且无 EOL，v1alpha2 仍在开发、按仓库 opt-in）。Porch 文档给出的 Kubernetes 最低版本为 1.37.0，并声明测试环境之外的兼容性“未正式验证”（[Compatibility](https://porch.kpt.dev/docs/3_getting_started/compatibility/)）。〔已核实〕

另需分辨两套材料：kpt 的版本政策明说“与特定 Kubernetes 版本的兼容策略尚未定义”，这是对 kpt 发布制品的承诺；Porch 的 1.37.0 与“未正式验证”是服务端文档的测试边界。两者不能互相替代，也不能合成一句“已支持所有 Kubernetes 版本”。

另需注意：`latest` 标签“不提供兼容性或稳定性保证”，只应用于测试与开发，“绝不应在生产环境使用”（以上引文为英文原文的中译；[VERSIONING.md](https://raw.githubusercontent.com/kptdev/governance/main/VERSIONING.md)）。因此“v1.0.0 代表全面稳定性承诺”必须收窄为：**包格式与 CLI 表面有较强承诺，minor 仍可破坏，Kubernetes 兼容与服务端 API 表面另计。**

## 八、替代方案与选型

### 8.1 对比

下表为替代方案的定位对照〔判断〕；各方案的具体能力以其官方文档为准。

| 方案 | 更适合的需求 | 相对 kpt/Porch 的位置 | 关系 |
|---|---|---|---|
| **Helm** | 复用成熟 chart、第三方软件分发、参数化安装 | 分发层竞争者 | 同层重叠（可组合，见下注） |
| **Kustomize** | 少量 YAML 差异、轻量 overlay、与 Argo/Flux 原生集成 | 最直接的竞争者 | 同层重叠（多数场景择一） |
| **Jsonnet / CUE** | 复杂配置生成、类型与约束表达 | 可替代函数层 | 可组合 |
| **OCI 制品分发** | 配置的寻址、分发与完整性 | 只解决分发，不解决变体与审批 | 可组合，非互斥 |
| **Crossplane** | 用控制器持续管理云资源 | 不同层，解决的是资源调和 | 可组合 |
| **Argo CD / Flux 原生** | 现有持续协调与健康检查 | 承载层，始终存在 | 上游/下游关系 |

> 注：“同层”指同属配置生成与分发层，因而是竞争关系，但**不是物理互斥**：函数链在机制上可以把 chart 渲染作为其中一个环节调用；官方 FAQ 也建议可以“用 kpt 做打包与 actuation、用 Kustomize 做定制”（翻译）。是否值得组合，取决于团队是否愿意同时维护两套抽象；具体是否有可用的函数实现，本次无法核验〔判断〕。

### 8.2 适用与不适用

**更可能合适**〔判断〕：配置包数量多、跨多集群、需要包级审批与版本语义、有专职平台工程能力、且能接受函数工程的团队；电信网元、边缘站点批量开通这类“由系统生成配置”而非“由人编写配置”的场景。

**不建议引入完整工具链的情形**〔判断〕：只需要简单 overlay 或参数替换、业务团队习惯用 Helm/Kustomize 且无意维护函数工程、或按 9.1 评估后痛点无法量化。此时引入 kpt/Porch 属于“为定位口号支付治理成本”。

**集群规模不是独立门槛。** 集群数量少但包派生、上游跟随与修订审批量大，并具备函数与流水线维护能力的团队，应当按 8.3 进入 CLI 试点；规模判断按 9.1 的口径进行——包治理类痛点按包数 × 环境数 × 集群数的组合规模估算，程序化变换类痛点按变换量级、调用频率或可量化节省估算，任一估算方式足以证明固定成本可被摊薄即可，不以单一集群数量或包数下限否决任何路径。

**Porch 的前置条件。** 缺少专职平台工程能力维护服务端控制器的团队，不应部署 Porch；但这不是不采用 kpt 的理由——kpt CLI 可完全独立于 Porch 使用（3.2），退出与试点路径都以 CLI 为先（8.3、第九章）。发布已核实也不改变这一判断：**是否部署 Porch 取决于包级治理痛点与服务端维护能力，而不是版本号。**

### 8.3 选型路径

```mermaid
flowchart TD
    Q1{"是否存在大规模的包派生、上游跟随、修订审批需求，<br/>或现有工具难以表达的程序化变换需求？"}
    Q1 -->|否| R1["用 Kustomize 或 Helm<br/>+ Argo CD / Flux 即可"]
    Q1 -->|是| Q2{"能否维护函数与<br/>CI 渲染流水线？"}
    Q2 -->|否| R2["先小范围单包试写函数，<br/>或回到现有方案补齐"]
    Q2 -->|是| Q3{"退出路径是否成立<br/>产物能否保持纯 KRM YAML？"}
    Q3 -->|否| R3["先重构产物形态<br/>再评估"]
    Q3 -->|是| P1["阶段二：仅 CLI 渲染（CLI 试点）<br/>接入现有 CI 与 GitOps<br/>须先通过 9.1 评估"]
    P1 --> Q4{"包级审批与多租户<br/>是否成为实际瓶颈？"}
    Q4 -->|否| R4["停在 CLI 层<br/>不部署 Porch"]
    Q4 -->|是| Q5{"是否有平台工程能力<br/>维护服务端控制器？"}
    Q5 -->|否| R5["留在 CLI 层<br/>不部署 Porch"]
    Q5 -->|是| P2["阶段三：Porch 受限试点<br/>单租户、非关键集群"]
```

图中“阶段二”“阶段三”与 9.2 的编号一致：9.2 阶段一（只读评估，含 9.1 评估矩阵打分）位于首问粗筛与“阶段二”节点之间——通过首问的团队先完成只读评估与打分，再进入 CLI 试点。首问中的“大规模”只修饰包派生、上游跟随与修订审批三类需求；程序化变换需求不设规模前提，但同样要通过 9.1 的规模维度——按该维度的替代估算，可用变换量级、调用频率或可量化节省证明固定成本可被摊薄。

## 九、采纳建议

### 9.1 评估矩阵

按以下七个维度打分，任一维度出现“否”即应暂停推进〔判断〕：

| 维度 | 判断问题 | 门槛 |
|---|---|---|
| 痛点真实性 | 包派生、上游跟随、修订审批、程序化变换四类痛点（最后一类指现有工具难以表达、必须程序化变换的配置生成需求）是否已是可量化的瓶颈 | 有基线数据（上述任一类痛点以自身数据可量化即可，例如每月需生成的配置包数、单次变换的人工工时、变更错误率或返工次数） |
| 现有方案缺口 | Kustomize/Helm（含其插件与函数扩展）以及 Jsonnet/CUE 等生成层替代是否已尝试并确认不足 | 有尝试记录，并比较扩展现有工具与引入 kpt 的维护成本 |
| 规模 | 包治理类痛点按包数 × 环境数 × 集群数的组合规模估算（不以集群数单项判定）；程序化变换类痛点按变换量级、调用频率或可量化节省估算 | 任一估算方式足以证明固定成本可被摊薄即可，不设包数下限 |
| 团队能力 | 是否有人能写、审、维护 KRM 函数 | 至少一名专职 |
| 治理前置 | 函数镜像白名单、签名、摘要固定是否可落地 | 试点前就位 |
| 集成方式 | 能否用“先渲染后提交”接入现有 GitOps | 不需要改造下游 |
| 退出成本 | 停用后能否保留可部署产物与审批记录 | 是 |

打分在 9.2 阶段一（只读评估）内完成，作为进入阶段二的前置。四点口径说明：其一，“任一维度为否即暂停”指暂停进入下一阶段，不是永久否决，条件变化后可重评；其二，规模维度是经济性判据而非数量下限——包治理类与程序化变换类痛点各按上表的估算方式证明摊薄即可，包量少但变换需求已可用基线数据量化的团队，不因计数组合低而被暂停；其三，8.3 中“先小范围单包试写”属探索性动作，不计为正式试点，完成后须按本表重评团队能力维度；其四，本表“治理前置”的“试点前就位”指 9.2 阶段二（CLI 试点）开始之前，组织级治理基线另见 9.5。

### 9.2 三阶段路径

1. **阶段一（只读评估，约 1 周，估算）**：核实发布事实与版本序列（v1.0.1 为当前最新的非预发布补丁、v1.0.2 仍预发布）；核实四项兼容面及其各自证据边界——包格式、CLI 契约、函数契约、服务端 API（7.4），其中函数契约没有独立版本承诺，只能按所选函数 SDK 与文档单独核；核对目标集群是否满足 Porch 的最低 Kubernetes 版本要求（当前文档为 1.37.0）并确认范围外兼容未验证（该要求只约束 Porch 服务端，不约束仅使用 kpt CLI 的路径）；盘点自身痛点与基线数据，并按 9.1 完成评估矩阵打分；不做任何部署。
2. **阶段二（CLI 试点，2–3 周，估算）**：不引入 Porch，只在 CI 中用 kpt 完成渲染与校验，产物交给现有 Argo CD/Flux。
3. **阶段三（Porch 受限试点，按需）**：仅当阶段二证明包级治理确实是瓶颈时，在单租户、非关键集群部署 Porch，并同时测试故障与恢复。

### 9.3 最小验证方案

前置条件：选择一个**无敏感数据、无持久化副作用、非生产**的应用，覆盖两个环境，并保留现有流程作为对照基线。涉及不可信函数的步骤，须在一次性、无外网访问、无特权挂载、无发布凭据的隔离执行环境中进行；若无法提供该环境，改为只验证“入口拒绝载入不可信函数”，不实际执行（与第十章供应链控制一致）。

1. 把现有服务转换为一个 kpt 测试包：资源文件 + `Kptfile` + 一至两个函数。
2. 固定输入包提交、函数镜像摘要与执行环境，保存审核后的输出。
3. **连续渲染十次并比对规范化后的资源内容**，任何差异都必须能解释并消除。
4. 注入异常样本：非法资源、越权资源、依赖不可用、不可信函数。对不可信函数分两步：先在默认执行环境中验证入口拒收；仅在具备上述隔离条件时，才实际执行，并验证失败时不会发布部分结果。另加两类：恶意输出（植入后门或跨租户读取）与部分发布（中途失败留下半套资源），验证最终产物授权校验与失败拒发。验收时须区分两种失败：**产物发布失败**应在仓库侧拒发、不留下半套产物；**集群侧部分应用**则须以集群实际状态核对（集群 apply 不具事务性），两者不能用同一判据。
5. 走一遍上游升级：模拟上游包变更，验证合并、冲突处理、权限变化复审与回滚。
6. 若进入阶段三，增加跨租户读取与凭据访问测试、服务中断与恢复测试，并验证 Porch 停机不影响既有负载的前提（无其他运行依赖指向 Porch）。
7. 做一次停用演练：保留已批准产物、导出包修订历史与审批记录、解绑 Porch，验证停用后仍有可执行的变更、上游升级与审批替代流程。恢复演练按固定顺序验收：先阻断错误来源与发布身份，再恢复已批准产物，最后确认遗留权限已清除且后续协调不再引入。

**建议的成功标准**（须在试点前按自身基线确定，不照抄）：

| 指标 | 建议阈值 |
|---|---|
| 渲染确定性 | 同输入同输出，十次一致率 100% |
| 策略拦截 | 预置违规样本 100% 被阻断，误报可接受 |
| 发布授权 | 未获授权的产物 100% 被拒绝；失败时拒发而非部分发布 |
| 追溯完整性 | 变更、审批、产物三者的关联字段 100% 齐全 |
| 恢复能力 | 能恢复到上一份已批准产物；恢复验收同时确认目标产物、集群收敛状态、错误权限已清除、恢复协调后不再复发；耗时满足约定目标 |
| 总成本 | 相对基线的工时与维护成本可解释，而非“感觉更快” |

以上 100% 指标证明的是预置测试集与约定场景内的表现，**不证明所有恶意产物都会被阻断**；试点须同时记录测试集、每个样本的预期拒绝原因与覆盖边界，避免把“样本全拦”读作安全保证。

### 9.4 退出与防锁定

退出便利是**相对在部署期渲染的工作流**（模板在部署时才展开的方案）的一个真实优势〔判断〕：由于倡导 Config-as-Data，其终态产物就是标准 Kubernetes YAML。若要停用，只需解绑 Porch、保留仓库中已生成的产物，下游 Argo CD/Flux 无需重构。

但对已经使用 Kustomize 的团队，产物同为纯 KRM YAML，退出成本相当，这一优势并不额外成立（对照 8.1）。

退出策略有四个必须守住的约束：**产物必须是纯 KRM YAML；业务逻辑不得写进 `Kptfile`；审批记录与依赖信息必须独立留存；包修订历史与审批记录必须可导出。** 需要清醒认识到：保留既有产物只能保证继续部署，不等于后续变更、上游升级与审批仍可执行；回退 Git 提交也不能撤销数据迁移、资源删除与外部副作用，**也不阻止控制器把已授出的错误权限重新应用**。因此退出演练必须包含停用后的变更与审批替代流程，以及这些不可逆副作用的处置，并在恢复后复核错误权限不会被重新应用。〔判断〕

### 9.5 治理前置

函数镜像白名单与摘要固定的组织级基线在规模化之前落地；单团队试点所需的同类控制按 9.1 治理前置于阶段二前就位；包来源与审批流先于多团队推广；`Kptfile` 之外的“隐藏逻辑”一律禁止。进入生产前还须补齐三项：**最终产物的授权校验、执行身份与发布凭据隔离、失败时拒绝发布而非发布部分结果。** 签名与审批只能确认来源与流程，不能证明产物行为安全，这三项不能由签名替代。

## 十、风险与合规

下表为控制建议与风险推断〔判断〕；具体权限与隔离能力须查所选发行物。

| 方面 | 主要风险 | 建议控制 | 说明 |
|---|---|---|---|
| **供应链完整性** | 函数镜像被替换或投毒；包来源被篡改 | 固定摘要、验证签名、私有仓库白名单、生成并检查 SBOM；禁止 `latest` | 签名、漏洞扫描与行为策略承担不同职责，不能互相替代；签名只证明来源，不证明行为安全 |
| **错误产物通过审批** | 恶意或错误输出经合法审批进入生产，并被持续协调反复应用 | 最终产物授权校验；审批、发布与部署身份分离；失败拒发；恶意输出与部分发布测试 | “流程合规”不等于“产物安全” |
| **最小授权** | Porch 持有 Git 写权限与集群权限；函数以某个身份执行 | 读包、修改、批准、发布、部署身份分离；按仓库/租户收敛凭据；按执行身份、挂载、网络与凭据逐项收敛函数权限 | 具体权限范围须查所选发行物，不能从架构概念推断默认安全；能执行代码不等于必然高权限 |
| **多租户隔离** | 函数读取他租户 Secret 或配置 | 分别验证服务端对象、底层仓库、执行环境、缓存与凭据边界 | 命名空间不同不等于隔离成立 |
| **审计追溯** | 无法还原“谁在何时改了什么” | 关联操作者、输入修订、函数摘要、输出摘要、批准记录与部署结果；Git 提交签名 | 审批、发布与部署三处记录须能对齐 |
| **故障恢复** | 状态不一致导致误判 | 准备冻结发布、暂停协调、撤销凭据、恢复批准产物的操作流程；恢复验收须逐个确认目标产物、集群收敛、错误权限清除与恢复协调后不再复发 | 记录不可逆副作用；Porch 停机不影响既有负载的前提是无其他运行依赖指向它 |
| **合规证据** | 误以为用了工具即合规，或误以为 1.0 即全面稳定 | 按实际数据与业务范围落实留存、删除与访问审查；按 7.4 的四层兼容面留存版本与测试证据 | 发布承诺有限不等于合规；采用工具本身不能证明符合任何具体法规或标准 |

一条总的合规视角〔判断〕：**函数具有任意代码执行的能力，应当按不可信代码对待，而不是当作“无害的模板”。** 但“能执行代码”不等于“必然高权限”：函数的实际权限由执行身份、挂载、网络与凭据暴露决定，既不应当从能力推出高权限，也不应当假定它默认就是最小权限——权限必须按执行配置逐项收敛。这一点是 kpt 与传统模板方案在安全模型上最实质的差别，也是最容易被低估的地方。

## 十一、趋势判断

### 11.1 发布信号的含义与边界

发布已经核实，它代表的是一次**有限的稳定性承诺**：覆盖包格式与 CLI 表面，不覆盖 Kubernetes 兼容、Porch 的 PackageRevision API 表面，也不证明生产可靠性、生态增长或商业支持〔判断〕。公告中的“所有组件稳定”“已准备好被广泛采用”属项目方主张，不能作为趋势证据。

尤其不能由发布推出采用：**发布是供给侧的信号，采用是需求侧的事实，两者之间没有必然联系。** 官方采用者名单已有一条具名产品使用声明（Nokia），但不含运行规模、维护经验与收益，本次未独立核实；据此仍不上调采用相关判断。

### 11.2 四个可分别判定的命题

由于独立研判给出的概率口径不同，本报告不合成一个数字，而是拆成四个可分别判定的命题，并把**事件概率**与**证据可信度**分列〔判断〕：

| 命题 | 事件判断 | 事件概率（区间，未校准） | 证据可信度 | 分歧说明 |
|---|---|---|---|---|
| P1a：kpt 到 2027 年仍保持活跃维护 | 较可能成立 | 约五成至六成 | 中低 | 发布已核实、仓库活跃，但维护投入无法从星数或 issue 数推断 |
| P1b：kpt 维持“小众但存续”的定位 | 较可能成立 | 约五成至六成 | 中低 | 采用证据稀缺；定位判断与维护判断共享同一组事实，但含义不同 |
| P2：kpt 成为通用企业 GitOps 的默认渲染层 | 不太可能 | 低于三成 | 中低 | 需先把“默认”定义为被主流 GitOps 控制器或发行版默认集成、并成为多数新项目的默认选择；目前无此类证据 |
| P3：Porch 在电信/边缘之外出现可核实的生产采用 | 无正面证据，不作基准预测 | 不作点估计，也不设上限 | 低 | 未见正面证据；“未取得”不等于“不会发生” |

原有三项命题（P1 已拆为 P1a/P1b）的观察窗口统一至 2030 年前。P1a/P1b 的命题以 2027 年为界，表中概率即指“到 2027 年仍成立”这一时点判断；2030 年是统一观察上限，2027 年之后对 P1 的续判另计。表中概率为研判给出的粗略区间，没有校准依据；证据可信度是对“判断本身有多可靠”的评估，两者不可互相替代。P3 不设概率上限，是因为“未取得案例”只能说明证据缺口，不能支撑任何方向的数量估计。

### 11.3 观察指标

**上调判断的观察点**：出现多家非电信头部企业的公开生产案例（含运行范围、维护主体与故障经验）；Argo CD 或 Flux 将 kpt/Porch 作为一等公民来源原生支持；函数生态与多语言 SDK 明显增长；官方给出明确的 Kubernetes 兼容与支持政策；主流云厂商在托管 Kubernetes 中内置 Porch 类服务。

**下调判断的观察点**：v1.0.2 正式版长期不发布，或发布后维护与补丁中断；仓库归档或活动明显下滑；Porch 停止随 kpt 发布或被归档；主要维护者离开；已有用户公开迁出并说明原因。初版所列“查无 v1.0.0 官方发布记录”已被本次核验排除，不再作为下调观察点。

### 11.4 结论

**kpt/Porch 更可能沿“电信、边缘与重度平台工程”的路线演进，成为一类特定场景的选项，而不是通用 GitOps 的默认组件。** 这一判断的证据可信度为中低；它是否成为“可靠底座”，取决于后续维护投入与治理连续性，本报告不作保证。对本议题的提问者而言，这意味着：把它当作一个“在特定条件下值得试点的选项”，而不是一个“值得押注的平台方向”。〔判断〕

## 十二、结论与建议

| 读者 | 建议 |
|---|---|
| **一般企业的平台团队** | 先确认痛点是否真实。若只是模板可读性或少量环境差异，继续用 Kustomize/Helm，不必引入。若确有大规模包派生与审批需求，或现有工具难以表达、已可用基线数据量化的程序化变换需求，按第九章评估并做 CLI 试点，暂不部署 Porch；规模维度按 9.1 的两类估算方式判断固定成本能否摊薄，不以包数下限卡住变换需求为主的团队。 |
| **电信、边缘、多集群批量开通场景** | 这是该工具链最匹配的生态位，值得认真评估，但同样应从“仅 CLI”开始，并把函数供应链治理与 Kubernetes 版本适配作为前置条件。 |
| **正在做技术选型的管理者** | 把“发布消息”与“采用证据”分开评估。发布已核实，但兼容承诺有限；要求供应商或内部提案方提供可核实的生产案例与量化数据，而不是版本号与定位口号。 |
| **关心趋势的读者** | 观察第十一章列出的上调观察点；在此之前，把它视为“稳定的小众”，不作战略押注。 |

**一句话结论：kpt 与 Porch 解决的是一个真实但相对窄的问题——大规模配置包的派生、上游跟随与修订治理；它不解决“如何做 GitOps”这个更常见的问题，而后者正是大多数团队真正的痛点。**

## 十三、少数意见

以下意见在讨论中提出但未被本报告采纳，或有保留地采纳。列出以便读者自行判断。

1. **“无模板”是不是核心卖点。** 主主持倾向认为“无模板渲染”的价值被高估，包生命周期与上游跟随才是差异化所在；顾问席则把结构化、无模板的配置变换列为首要优势。本报告采纳前者：5.3 明确“无模板”不构成对 Kustomize 的差异，6.2 把增量收敛为两项候选，其中上游包跟随属 CLI 层能力。顾问席的表述保留于此。
2. **证据分级的口径。** 初版讨论中，顾问席把 Nephio 的项目参与方、Google Cloud 配置管理产品线与 KRM 规范的实现细节标注为“可核实事实”；核验席、质疑席与第二主持均认为在离线条件下不能这样标注。本版通过一手核验解决了其中一部分：Nephio 项目级集成、kpt 包与函数、Porch 边界、版本与兼容政策已有直接来源；但顾问席提到的具体运营商名称、Google Cloud 配置管理产品线的直接页面，以及迁移页语境之外的更早版本序列仍未取得，未写入正文。
3. **趋势判断的强度与概率数字。** 顾问席给出“通用企业市场难以撼动”约七成半的把握；核验席的判断是“小众存续五至六成、成为主流渲染层低于三成”；质疑席主张删除缺校准依据的概率，尤其不应给 P3 设“低于一成”的上限。本报告保留 P1a/P1b 与 P2 的未校准区间、删除 P3 的点估计与上限，但未完全删除概率数字；这是与质疑席的保留分歧。
4. **是否存在“已验证收益”。** 顾问席将“配置可审计”与“策略集成”标为已验证收益。其余席位一致认为没有可公开引用的量化结果。本报告一律按设计意图处理（6.1）。
5. **是否可以直接进入 Porch 试点。** 顾问席建议分两阶段直接推进到受限试点；质疑席与第二主持强调必须先验证“仅用 CLI”能否满足流程，再衡量额外治理收益。本报告采纳后者，同时把顾问席的路径作为“阶段二已证明包级治理瓶颈”时的加速选项。
6. **版本成熟度的描述。** 初版讨论中，主主持描述为“长期处于 0.x”，核验席描述为“长期停留于 1.0.0-beta 系列”。本版已用迁移页所载的 v0.39 到 v1.0 重构，以及 v1.0.0、v1.0.1 与 v1.0.2 预发布序列替代；不再引用无法确认的 beta 版本号。
7. **恢复能力的边界。** 质疑席指出，回退 Git 提交不能撤销数据迁移、资源删除与外部副作用，也不能阻止控制器把错误权限重新应用。本报告采纳，写入 7.2、9.3、9.4 与第十章。这是一条容易被“GitOps 天然可回滚”的说法掩盖的风险。
8. **长期观察项（顾问席）。** 顾问席提出两条可作长期参照的路线：一是以 CUE、Jsonnet 等类型约束语言配轻量沙箱实现配置渲染与策略校验；二是把配置包当作遵循通用制品分发协议的不可变构件，交由现有流水线与制品库分发，以降低集群内控制面的长期维护负担。两者都不改变本报告的选型结论，列为观察项。
9. **“仅上游配置层”的表述边界。** 质疑席指出，把 kpt/Porch 整体限定为“仅产出配置”与 `kpt live apply` 的事实不符。本报告已采纳并在 3.3、5.1、5.2 修正；保留的分歧是：`kpt live apply` 是否应被视为一种可长期使用的生产部署方式。本报告的判断是不宜，理由是缺少常驻漂移协调的直接说明，且长期生产仍以 GitOps 控制器为主。

## 附录 A：关键结论证据分级与核验清单

| 结论 | 级别 | 核验方式与支持范围 |
|---|---|---|
| kpt v1.0.0 于 2026-08-31 在 GitHub 发布，非预发布 | 已核实 | 直接读取 Release API；仅支持发布事实，不等于全面稳定性承诺 |
| CNCF 博客于 2026-11-05 刊出 v1.0.0 公告 | 已核实 | 直接打开原文；博客日不等于 tag 发布日 |
| 当前最新的非预发布补丁为 v1.0.1（2026-09-25），v1.0.2 仍在预发布 | 已核实 | Release API 与发布列表；`prerelease=false` 只证发布字段，不证稳定承诺；`cli/v1.0.2-pre.4` 的字段差异属标签命名问题，不能当作稳定版 |
| kpt 是 CNCF Sandbox（2023-06-30 接受），非 Incubating/Graduated | 已核实 | CNCF 项目页与治理仓库；2026-07 博客的“完成 onboard”是另一时点 |
| 兼容承诺分层：包格式不变、CLI 子命令与参数不删除、minor 可破坏、K8s 兼容未定义 | 已核实 | 直接读取 `VERSIONING.md` |
| kpt 的包、`Kptfile`、容器化函数与深度优先渲染 | 已核实 | The kpt Book；KRM 为通用术语，非 kpt 专有定义 |
| Porch 不部署、不提供包仓库、不替代 kpt；部署由 Flux/Argo CD/Config Sync 完成 | 已核实 | Porch Overview 原文 |
| Porch 的 Draft/Proposed/Published 生命周期与 Repository/PackageVariant 对象 | 已核实 | Porch Glossary |
| Porch 当前稳定服务端 v1.6.3、推荐 API 模块 1.0.1、v1alpha1 受支持、v1alpha2 开发中、K8s 1.37.0 | 已核实 | Compatibility 页面与 Porch Releases；须分层理解，不能笼统写“已稳定”或“仍是 alpha”；1.0.3 的发布字段与兼容页标注不一致，未列为推荐版本 |
| Nephio R6 集成 Porch v1.5.6，安装流程使用 kpt 命令 | 已核实（项目级） | Nephio R6 公告与安装文档；不能证明运营商生产运行或收益 |
| Kubeflow GKE 文档 2023 年使用 kpt 拉包与函数 | 已核实（工具使用旁证） | 该文档页面；不证明 Porch 采用，也不证明 2026 年仍在使用 |
| 官方采用者名单载 Nokia 的 NCOM Evo Suite 产品生产使用声明 | 已核实（名单条目）；使用实际未独立核实 | 项目治理仓库 adopters.md（2026-11-10 读取）；采用方自述、名单不穷尽；不含部署规模、维护主体、故障经验与收益 |
| 非电信行业的具名企业生产案例与运行数据：本次未取得 | 未取得（受检索覆盖限制） | 多组检索与仓库根目录；主仓无 ADOPTERS/USERS 文件是已核实事实，“未列出”不等于“未使用” |
| “无模板”不是 kpt 独有优势 | 判断（机制性） | 对照 Kustomize 机制与 kpt FAQ 自述 |
| 收益均为设计意图，缺公开量化 | 未取得（量化数据）；收益定性为判断 | 检索；不能据此否定收益存在，只能说明没有可引用数据 |
| 建议“CLI 先行、Porch 按需” | 判断 | 试点结果与自身基线 |
| 趋势为“稳定的小众” | 判断 | 第十一章观察指标 |

**后续必须补齐的材料：** 官方名单条目（含 Nokia 声明）的部署规模、维护主体、故障经验与收益核实；非电信行业的可指名生产案例；函数契约的版本承诺；Porch 在目标 Kubernetes 发行版上的兼容测试；同负载对照的试点数据；审批与发布授权的实际流程记录。

## 附录 B：参考来源

以下来源均于 2026-11-09 直接读取，第 27、28 条于 2026-11-10 补核。列出的“支持范围”是本次使用该来源的边界，不表示来源支持其他结论。

1. **kpt v1.0.0 Release** — https://api.github.com/repos/kptdev/kpt/releases/tags/v1.0.0 — 字段：`tag_name=v1.0.0`、`published_at=2026-08-31T11:53:52Z`、`prerelease=false`、`draft=false`。支持“发布事实”，不支持稳定性承诺。
2. **kpt v1.0.1 Release** — https://api.github.com/repos/kptdev/kpt/releases/tags/v1.0.1 — 字段：`published_at=2026-09-25T08:12:13Z`、`prerelease=false`、`draft=false`。仅支持“该版本已发布且非预发布字段”，不支持稳定性承诺或采用率。
3. **kpt Releases 列表** — https://api.github.com/repos/kptdev/kpt/releases?per_page=15 — 含 `v1.0.2-pre.4`（2026-11-06，预发布）与 `cli/v1.0.2-pre.4`（同日，字段差异属标签命名）。列表响应超过读取长度上限，v1.0.1 日期由第 2 条单独取得。
4. **CNCF 博客：kpt v1.0.0 is released** — https://www.cncf.io/blog/2026/11/05/kpt-v1-0-0-is-released/ — 作者 epower，2026-11-05。摘录：“After many years and much development, the kpt community has released v1.0.0 of the kpt toolchain.”；“all the components of the project are stable”；“the readiness of kpt for widespread adoption”；“zero-touch GitOps workflow”。正文无 `production`，无具名采用者；上述稳定与采用表述属项目方主张。
5. **CNCF 博客：(re)introducing kpt** — https://www.cncf.io/blog/2026/07/02/reintroducing-kpt-your-toolchain-for-infrastructure-automation/ — 作者 Ciaran Johnston（Ericsson），2026-07-02。摘录：“The kpt project has recently been fully onboarded into CNCF as a sandbox project.”；Nephio 是 “The most robust and complex suite of examples”；“the aim is to stabilise the kpt APIs to release v1”。正文无 `production`。
6. **CNCF kpt 项目页** — https://www.cncf.io/projects/kpt/ — “accepted to CNCF on June 30, 2023 at the Sandbox maturity level”；2026-11-09 读取为“Total contributors 246”“Total contributing organizations 94”，2026-11-10 复核时组织数为 93。均属动态贡献指标，不等于采用者数。
7. **kptdev/governance** — https://github.com/kptdev/governance — “The kpt project is a CNCF Sandbox project.”；“Every repo has two code owners defined in the CODEOWNERS file of the repo.”；“All prs should be approved by both code owners and the code owners should not be from the same company.”；“Even if the number of code owners is higher than 2 only 2 approvals are needed to merge a pr.” 支持治理规范存在，不支持实际执行率或投入规模。
8. **VERSIONING.md** — https://raw.githubusercontent.com/kptdev/governance/main/VERSIONING.md — “We use a modified kind of semantic versioning”；“Minor: may contain breaking changes”；“Package format MUST NOT change”；“Subcommands MUST NOT be removed”；“Command line flags MUST NOT be deleted”；“The compatibility policy with specific Kubernetes versions is not yet defined.”；`latest` 标签“never in production environments”。
9. **The kpt Book：包** — https://kpt.dev/book/03-packages/ — “a kpt package is simply an ordinary directory of human-readable YAML files”；`apiVersion: kpt.dev/v1`、`kind: Kptfile`；render 按包层级深度优先执行函数。
10. **The kpt Book：入门** — https://kpt.dev/book/01-getting-started/ — 包与函数的工作流说明。
11. **kpt FAQ** — https://kpt.dev/faq/ — Kustomize “Builds the final configuration out of place, primarily using the overlay pattern.”；kpt “Optimizes for WYSIWYG configuration and in-place customization.”；建议 “use kpt for packaging and actuation, and kustomize for customization.” 属项目方自述。
12. **kpt 迁移文档** — https://kpt.dev/installation/migration/ — “The existing `v1alpha1` Kptfile format/schema is not compatible with kpt `v1.0`.”；“we removed the `cfg` subgroup”；包格式 v1 的向后兼容承诺。页面仍称 v1.0 为预发布，属文档未更新，仅用于迁移事实。
13. **Porch Overview** — https://porch.kpt.dev/docs/1_overview/ — “Porch is a Kubernetes-based system for managing the lifecycle of KRM configuration packages stored in Git repositories.”；“Porch is not a deployment tool.”；“does not deploy them to clusters”；“Porch does not provide a package registry.”；“Porch also does not replace kpt.”；“Deployment is handled by GitOps tools such as Flux, ArgoCD, or Config Sync.”
14. **Porch Glossary** — https://porch.kpt.dev/docs/11_glossary/ — Draft/Proposed/Published 定义；Repository 连接 Git 或 OCI；PackageVariant 自动克隆与更新。
15. **Porch Architecture** — https://porch.kpt.dev/docs/5_architecture_and_components/ — v1alpha1 聚合 API 与自定义 REST 存储、请求内同步；v1alpha2 CRD 为开发重点并按仓库 opt-in；Engine 负责函数求值与 pod evaluator。
16. **Porch Compatibility & Requirements** — https://porch.kpt.dev/docs/3_getting_started/compatibility/ — “Latest stable Porch server”＝v1.6.3（2026-07-30）；“Recommended API module”＝1.0.1；v1alpha1 “Supported”“no EOL date announced”；v1alpha2 “In development”“per-repo opt-in”；Kubernetes 最低与测试均为 1.37.0；“compatibility outside the tested environment is not formally verified.”
17. **Porch Releases** — https://api.github.com/repos/kptdev/porch/releases?per_page=8 — v1.6.3（2026-07-31）与 api/v1.0.3（2026-09-29）的 `prerelease` 字段均为 `false`；v1.6.4 与 api/v1.0.4 系列为预发布。第 16 条兼容页则把 1.0.3 列为 v1.6.4-pre.2 的推荐模块并标注 Pre-release。两处口径不一，正文只把 1.0.1 作为 v1.6.3 的推荐 API 模块。
18. **Porch v1.6.0 Release** — https://api.github.com/repos/kptdev/porch/releases/tags/v1.6.0 — 2026-06-29；“This release is the first release of Porch in the kpt project from the main branch.”；v1alpha2 已引入，v1alpha1 仍是默认。
19. **porch README** — https://github.com/kptdev/porch — “donated to the Nephio project in December of 2023, but later returned to kptdev in May of 2026.”
20. **Nephio Release 6** — https://nephio.org/nephio-release-6-strengthening-stability-and-security/ — “Porch v1.5.6”，页面更新于 2026-04-01；未点名生产运营商。
21. **Nephio 安装文档** — https://docs.nephio.org/docs/guides/install-guides/common-components/ — `kpt pkg get --for-deployment …@origin/main`；`kpt fn render porch`；`kpt live init porch`；`kpt live apply porch --reconcile-timeout=15m`。
22. **Kubeflow GKE 部署文档** — https://googlecloudplatform.github.io/kubeflow-gke-docs/docs/deploy/management-setup/ — 2023-03-30；`kpt pkg get` 与 `kpt fn eval -i list-setters:v0.1`。
23. **ConfigHub Blog：Kustomize, Kpt, Porch, and ConfigHub** — https://confighub.com/blog/kustomize-kpt-porch-and-confighub-28b781336885 — “kpt was intended to fill gaps with kustomize”；“managing many WET variants required more orchestration”；“Porch initially became part of the Nephio project”。页面未显示署名与日期，属部分核实。
24. **kpt 仓库元数据** — https://api.github.com/repos/kptdev/kpt — `stargazers_count=1905`、`forks_count=277`、`open_issues_count=292`、`archived=false`、`created_at=2019-09-16`、`pushed_at=2026-11-06T11:46:36Z`。不作采用率或质量指标。
25. **kpt 仓库根目录** — https://api.github.com/repos/kptdev/kpt/contents/ — 无 `ADOPTERS.md`、`ADOPTERS`、`USERS.md`、`USERS`；存在 `MAINTAINERS`。采用者名单在治理仓库，见第 27 条。
26. **porch 仓库元数据** — https://api.github.com/repos/kptdev/porch — `stargazers_count=23`、`forks_count=37`、`open_issues_count=182`、`created_at=2023-12-18`、`pushed_at=2026-11-07`。该仓库创建于 2023-12-18（捐给 Nephio 时，非回归后新建）；指标不可与 kpt 主仓直接比较。
27. **kptdev/governance 采用者名单** — https://github.com/kptdev/governance/blob/main/adopters.md — 2026-11-10 读取；该文件在 2026-10-29 的提交 `708bd41` 中已存在。引言：“organizations who are using kpt either in production, or providing its functions with their product offerings”；“This list is not exhaustive and represents a subset of the kpt community.”。唯一列出的采用者为 Nokia（联系人 Gergely Csatari），Adoption Level 为 “Production as part of the NCOM Evo Suite product.”，References 为空。属项目方名单中的采用方自述，未独立核实；名单说明列名组织为公开分享或授权列名。
28. **kpt CLI 参考：`kpt pkg update`** — https://kpt.dev/reference/cli/pkg/update/ — 2026-11-10 读取。“Apply upstream package updates.”；“`update` pulls in upstream changes and merges them into a local package.”；“kpt performs a 3-way merge for every resource.”。支持“上游包跟随”是文档载明的 CLI 机制；本次未运行验证，也未测试冲突、权限变化与回滚表现。

## 附录 C：术语表

| 术语 | 含义 |
|---|---|
| **KRM** | Kubernetes Resource Model，Kubernetes 的资源模型；通用术语，非 kpt 专有 |
| **Config-as-Data** | 把配置作为结构化数据管理，而非用模板生成 |
| **包（package）** | 由 KRM 资源与 `Kptfile` 组成的配置分发单位 |
| **函数（function）** | 对资源列表做变换或校验的程序，通常以容器镜像分发 |
| **渲染（render）** | 执行函数流水线，得到最终配置 |
| **变体（variant）** | 同一上游包针对不同环境的派生配置 |
| **Porch** | 包编排服务，把包修订与发布搬到集群内；不是部署工具 |
| **Hydration** | 由源材料生成最终可部署配置的过程，kpt/Porch 处于此层 |
| **Reconciliation** | 持续协调，由 Argo CD、Flux 等控制器完成，位于下游 |
| **actuation** | 把配置实际应用到集群的动作；kpt 官方 FAQ 用该词概括 kpt 的用途之一 |

## 附录 D：更新历史

> C.1–C.16 为原报告 v1.0 的历史记录，按原文保留；其中 C.2 所称“全程离线”只描述当时版本的研究条件，不适用于本次修订，差异见 C.17。C.1–C.16 中的 v1.0-r1 至 v1.0-r4 指 2026-11-08 首次审议周期的内部工作稿；C.17 起的 v1.0-r1 指 2026-11-09 再审议周期的第 1 轮工作稿，C.21 起的 v1.0-r2 指同一周期的第 2 轮修订工作稿，C.24 起的 v1.0-r3 指同一周期的第 3 轮修订工作稿，C.27 起的 v1.0-r4 指同一周期的第 4 轮（硬上限）修订工作稿，按日期与上下文区分；C.30 为定稿记录，对应正式版本 v1.1；C.31 为终审反馈处理与再定稿记录。过程记录仅供版本追溯，不属于面向读者的结论。

### C.1 v1.0-r1 执笔说明（2026-11-08）

本版为第 1 轮执笔初稿，依据第 1 轮五席独立意见撰写。该轮为意见收集制，五席均提交了有效独立意见、均表决为“需修订”，未进入互评与主持综合，因此本稿没有综合稿可依，直接以各席原文为依据。

### C.2 事实核对与证据处理

- 全程离线，未访问任何外部链接，也未打开议题中转述的地址。因此全文对 kpt/Porch 的产品事实一律标注为待核，未引入任何外部来源、版本号、公司采用案例或引文。
- 议题转述的发布消息按“材料中存在的转述”处理，未升格为已核实事实；报告中同时写明“博客刊载不等于项目晋级”，以避免读者把发布渠道当作背书。
- 顾问席标注为“可核实事实”的内容（包含具体运营商名称、早期版本号、部分术语实现细节）未写入正文，理由见第十三章第 2 条；4.2 保留的“上游厂商安装文档曾用 kpt 拉取安装包”一条为另行标注〔待核〕的工具使用旁证，只说明工具被使用过，不构成产品集成或采用结论。
- 各席对“已验证收益”的表述不予采纳，统一按设计意图处理。
- 未采用任何席位的拟议阈值作为事实结论；第九章的成功标准明确标注为“须按自身基线确定”。

### C.3 各席意见采纳情况

| 席位 | 主要贡献 | 采纳情况 |
|---|---|---|
| 主主持 | 工具分工、收益—前提—指标框架、发布渠道不等于背书 | 大部分采纳；其“无模板被高估”的判断写入 5.3 与 6.2；“包编排才是差异化”的归属已按 6.2 的两项增量校正——上游包跟随属 CLI 层能力，不归入包编排，见第十三章第 1 条 |
| 质疑席 | 失败模式与恢复边界、威胁假设与反例、成本核算口径、区分“项目演示/试点/生产” | 全面采纳，写入 4.4、7.1、7.2、9.4 与第十三章第 7 条 |
| 顾问席 | 概念梳理、部署形态、退出路径、跨领域替代方案 | 概念与退出路径采纳；证据分级与“已验证收益”未采纳，见 C.2 |
| 核验席 | 证据分级、两种集成模式、兼容承诺需分四面核、按架构常识给出成本判断 | 全面采纳，写入 2.2、5.2、7.4 |
| 第二主持 | 分歧清单、同负载对照试点、成功标准须先设基线 | 全面采纳，写入 6.3、9.3 |

### C.4 第 2 轮待办（v1.0-r1 时点）

第 2 轮复审应以本稿为送审材料，重点核对：四项待核关键事实的表述是否仍被当作事实使用；6.1 的“增量/非增量”判定是否成立；第九章试点方案是否可直接执行；第十一章的概率区间是否有过度精确之嫌。（该轮复审已完成，处理结果见 C.6、C.7。）

### C.5 篇幅统计（v1.0-r1）

正文（第一至十三章，不含附录与图示代码）约 8.4 千汉字（自述估算）；表格 17 个（正文 14、附录 3）；图示 2 个。

### C.6 v1.0-r2 修订说明（2026-11-08）

本版依据第 2 轮复审结果修订。该轮为标准深度：五席独立意见与互评齐全，法定人数满足；质疑席最终表决为“通过”，核验席（以普通必需席身份参与）最终表决为“需修订”，主持综合为“需修订”。核验席提出一项实质阻塞意见，指出第八章“不建议采用”一句以集群数量与缺少服务端维护人手单独否决整条工具链，与 CLI 可独立使用的定位、选型树首个分流问题、第九章组合规模口径冲突；主持综合采纳该裁定，另有若干措辞、基准与可度量性意见列为少数意见。

本版的修订原则：**阻塞项按最小改动重写，不牵动其他章节；少数意见凡能以减少歧义的方式落地的，一律改写原文；不可离线核验的产品细节只加限定语与判断标注，不新增事实。** 全文未新增任何外部来源、版本号、案例或引文，证据口径与 v1.0-r1 相同。

主要改动一览：

1. 8.2 重写为三段：不建议引入完整工具链的情形（按痛点与既有方案缺口判断）、集群规模不是独立门槛（改引 9.1 组合口径）、Porch 的前置条件（服务端维护能力只约束 Porch，不约束 kpt CLI）；8.3 选型树在“包级审批是否成为瓶颈”之后增加“能否维护服务端控制器”一问，否定分支明确为“留在 CLI 层”。
2. 1.3、5.3、6.2 三处差异化表述各自标明比较基准；6.2 补“相对默认组合的原生能力差异”与“既有流水线已实现同等治理则不构成增量”的例外，并把决策问句扩为两问（包治理痛点、程序化变换需求）。
3. 3.1 区分“以 KRM 对象表达”与“通过模式与准入校验”，并限定“配置即数据”消除的是模板期插值故障。
4. 7.3 成熟度推断改为条件句；11.2 把事件概率与证据可信度分列，统一观察窗口，P3 不作点估计；1.8 说明“中等”指证据可信度。
5. 9.2 点名四项兼容承诺，工期标注为估算；9.3 增加不可信函数的隔离执行前提与“只验证入口拒收”的替代路径，新增停用演练步骤，恢复验收扩展为目标产物、集群收敛、错误权限清除、不再复发四项；9.4 把退出优势限定为相对部署期渲染的工作流，并补停用后的变更与审批替代验证。
6. 8.1 把 Helm/Kustomize 的关系由“互斥”改为“同层重叠”并加注；第十章区分代码执行能力与授予权限；2.2 改“全文一致”为“以分节框架标注为主”；4.2 补厂商支持证据单薄的说明；5.3 生态排序标注为判断。
7. 本版没有采纳任何新增的外部事实，也未改变 v1.0-r1 的主线结论。

### C.7 第 2 轮复审意见逐条处理

下表按席位来源归并同类意见。处理栏中“已修复”指正文已按意见改写，“书面保留”指本报告维持原判断并给出理由。

| 序号 | 来源 | 意见要点 | 处理 | 落地位置 |
|---|---|---|---|---|
| 1 | 核验席（阻塞项） | 8.2 以集群数量与缺少服务端维护人手单独否决整链，与 CLI 可独立使用、选型分流问题、组合规模口径冲突 | 已修复 | 8.2 三段重写；8.3 增“服务端控制器维护能力”一问；9.1 规模维度注明按三项乘积 |
| 2 | 核验席（兜底项） | 结构未完全确认的段落保留原文兜底 | 已核对 | 兜底项无独立主张，所指内容由第 1 项覆盖 |
| 3 | 核验席、顾问席、两主持、质疑席 | 同一处 8.2 表述孤立阅读仍可能误导演 | 已修复 | 同第 1 项 |
| 4 | 核验席、顾问席、两主持 | 7.3 以“1.0 迟到多年”推断投入有限，预设发布已成立 | 已修复 | 7.3 改条件句，注明不能单独作为证据 |
| 5 | 核验席、质疑席、两主持 | 3.1 把“以 KRM 对象表达”与“资源有效”混同 | 已修复 | 3.1 概念表两行改写，并与 9.3 交叉引用 |
| 6 | 核验席、质疑席、顾问席、第二主持 | 1.3、5.3、6.2 三份差异化清单比较基准不同 | 已修复 | 三处分别标明机制差异、相对 Kustomize、相对默认组合的净收益 |
| 7 | 核验席、第一主持、第二主持 | 9.4 把退出便利说成相对多数方案的优势过宽 | 已修复 | 9.4 限定为相对部署期渲染的工作流，说明 Kustomize 退出成本相当 |
| 8 | 核验席、第一主持 | 退出方案未覆盖停用后的变更、升级与审批替代 | 已修复 | 9.3 增停用演练；9.4 增“保留产物只保证继续部署” |
| 9 | 核验席、质疑席、顾问席、第二主持 | 9.3 注入不可信函数缺隔离执行前提 | 已修复 | 9.3 前置条件与步骤 4 补隔离要求及替代路径 |
| 10 | 核验席、第一主持 | 9.2 阶段一未点名四个兼容面；工期未标估算 | 已修复 | 9.2 点名四项并标“估算” |
| 11 | 核验席 | 8.1 把 Helm 与 kpt 定为同层互斥，与函数可任意变换有张力 | 已修复 | 8.1 改“同层重叠”并加注可组合条件与未核说明 |
| 12 | 核验席、质疑席、第一主持 | 第十章把函数定性为高权限任意代码执行过强 | 已修复 | 第十章结论段区分能力与授予权限 |
| 13 | 核验席、第一主持 | 1.4“唯一线索”与 4.1“发布后新增”范围不齐 | 已修复 | 1.4 改“唯一被各席共同认可的采用类线索”；4.1 增统计范围 |
| 14 | 核验席、质疑席、顾问席、两主持 | 11.2 混用事件概率与证据可信度；仅 P1 有时间界；摘要“中等”易误读 | 已修复 | 11.2 拆分两列、统一观察窗口、P3 不作点估计；1.8 说明“中等”含义 |
| 15 | 质疑席 | 6.2 增量应限于相对默认组合的原生能力，并保留既有流水线已达同等治理的例外 | 已修复 | 6.2 增基准与例外段 |
| 16 | 质疑席 | 恢复验收只看能否恢复产物，不足以证明状态恢复 | 已修复 | 9.3 成功标准与第十章故障恢复行补四项验收 |
| 17 | 顾问席 | 3.1 称配置即数据“不存在缩进错误与类型错误”过绝对 | 已修复 | 3.1 限定为模板期插值故障 |
| 18 | 第一主持 | 3.4 与 5.4 在“审批是否自动化”上表述不一 | 已修复 | 5.2 表与 5.4 明确流转自动化、决策由人承担 |
| 19 | 第一主持 | 3.3 图示只画经 Git 交接，未覆盖第二种集成模式 | 已修复 | 3.3 图示后补模式二说明 |
| 20 | 第一主持 | 6.2 决策问句缺“程序化变换需求”一轴 | 已修复 | 6.2 改为两问 |
| 21 | 第一主持、核验席 | 2.2 称“全文一致”偏强 | 已修复 | 2.2 改为“以分节框架标注为主” |
| 22 | 第一主持、核验席 | 5.3 生态与人力供给排序未标判断 | 已修复 | 5.3 表后注明该行为排序判断 |
| 23 | 第一主持 | 意见采纳表对“包编排才是差异化”的归属过宽 | 已修复 | C.3 按 6.2 两项增量校正，上游包跟随归 CLI 层 |
| 24 | 第二主持 | 摘要、第五章、第六章差异化口径不统一；趋势与成熟度措辞；异常测试隔离；资源有效性 | 已修复 | 分别落于 1.3、5.3、6.2、7.3、11.2、9.3、3.1 |
| 25 | 核验席、第一主持 | 4.2 厂商支持维度证据单薄 | 已补说明 | 4.2 表后声明不据此下结论 |
| 26 | 顾问席（第 1 轮起保留） | 8.2 该句是对无痛点团队的整卷劝退，不应判为阻塞 | 已按阻塞项修复，分歧消解 | 主持裁定计入阻塞（反例可指名：集群少而派生量大、只走 CLI 的团队）；8.2 改写后两种读法收敛，争点不再存在 |
| 27 | 第一主持 | 研究综合席另两项（资源有效性、退出路径）不应计为阻塞 | 已按裁判处理并修复 | 两项均按少数意见修复（第 5、7、8 项），不再有未闭环分歧 |

阻塞项闭环情况：第 1 项为核验席唯一实质阻塞意见，已在 8.2、8.3、9.1 完成改写，交叉引用（3.2、8.1、第十二章）经复核与新表述一致；第 2 项为无独立内容的兜底项，已核对。质疑席在互评阶段未提出阻塞项。**上述声明只覆盖第 2 轮阻塞项所涉章节**；3.3 架构图与模式一表述的冲突、4.1 与 4.4 的用例口径是第 3 轮新发现的问题，处理见 C.11。

### C.8 第 1 轮任务书异议的处置对账

第 1 轮核验席对撰写任务书中的条目提出 11 组“该条为模型知识、需核实”的异议。报告对这些条目的处置如下：任务书条目一律不作为事实引用，正文按证据级别重新表述或不予采用。

| 任务书条目 | 处置 |
|---|---|
| R1 kpt 定位与核心概念 | 3.1 全表〔待核〕，术语口径与附录 B 一致 |
| R2 Porch 定位 | 3.2 全节〔待核〕，仅用于架构分工判断 |
| R3 业界使用案例 | 4.2 保留待核标记，明确不升格为生产采用 |
| R4 与 GitOps 结合方式 | 5.1 标为基于工具分工的判断；5.2 标注非默认路径的代价 |
| R5 优势与收益 | 6.1 统一按设计意图处理，未采用任何量化结论 |
| R6 局限、成本与失败模式 | 7.1、7.2 采其分类，未引用具体产品行为 |
| R7 替代方案对比 | 8.1 表前已标为判断，关系一栏改为同层重叠并加注 |
| R8 采纳建议 | 第九章全部标为建议路径，阈值须按基线确定 |
| R9 趋势判断 | 第十一章拆为三个命题，全部标为判断与未校准区间 |
| R10 风险与合规 | 第十章采其控制项，权限范围声明须查发行物 |
| R11 证据分级汇总 | 2.2 与附录 A 采用三级口径；唯一“已核”仅指议题材料存在该表述 |

### C.9 篇幅统计（v1.0-r2）

- 正文（第一至十三章，不含附录与图示代码）约 1.0 万字（自述估算，按汉字计）；
- 正文表格 14 个，附录表格 5 个，图示 2 个；
- 相对第 1 轮，正文增加约 1.6 千字，集中在第八章（选型排除条件重写）、第九章（隔离与退出、恢复验收）与第十一章（概率口径）。

### C.10 v1.0-r3 修订说明（2026-11-08）

本版依据第 3 轮复审结果修订。该轮为标准深度：五席均作答、法定人数满足，质疑席最终表决为“阻断”，核验席为“需修订”，因此本轮不能判为通过。实质阻塞有两处：一是 9.1 的痛点门槛未纳入程序化变换需求，与 6.2、8.3 的准入条件冲突；二是 3.3 架构图把渲染产物画成必经 Porch，与“模式一不部署 Porch”相矛盾。另有一处试用与生产采用两套口径不一致。

本版修订原则与上一版相同：**阻塞项按最小改动重写，不牵动其他章节；少数意见能以一句话消歧的即落地；不新增任何外部来源、版本号、案例或引文，主线结论不变。**

主要改动：

1. 9.1 痛点真实性一行扩为“包派生、上游跟随、修订审批，或现有工具难以表达、必须程序化变换的配置生成需求”，并允许任一类痛点以自身基线数据满足门槛；其余六个维度与门槛不变。8.2 对 9.1 的援引因此恢复一致，无需改动。表后补三点口径：暂停指暂停进入下一阶段、单包试写属探索不计正式试点、治理前置的试点时点。
2. 3.3 架构图增加从函数渲染结果直达 Git 仓库的连线，把经 Porch 的一支标为可选；图后说明改为“直达连线对应模式一，经 Porch 的一支对应模式二”。
3. 4.1 把“采用”拆为试点采用与生产采用两层；4.4 明确客户试点只能证明试点使用，只有生产部署能支撑“业界实际使用”。
4. 少数意见落地：2.2 与 5.2、5.3、7.2、8.1、第十章补表级判断标注；6.1 表后说明程序化变换属准入需求而非收益项、上游包跟随属 CLI 层能力；1.4 注明 Nephio 为项目级且早于发布；9.3 第 4 步拆句；9.5 区分组织级基线；11.2 明确 P1 概率对应 2027 年时点；第十三章补长期观察项。
5. 更新历史自身修正：C.2 说明 4.2 厂商安装线索的归属；C.7 第 26 项处理栏改为“已按阻塞项修复，分歧消解”；C.7 闭环声明限定为只覆盖第 2 轮阻塞项；C.8 的 R7 行与 8.1 新增的表级标注对齐。

### C.11 第 3 轮复审意见逐条处理

下表合并同类意见，按来源与性质归并。处理栏中“已修复”指正文已按意见改写并注明落点，“不属正文缺陷”指该意见针对材料接收而非报告内容。

| 序号 | 来源 | 意见要点 | 性质 | 处理 | 落地位置 |
|---|---|---|---|---|---|
| 1 | 质疑席 | 9.1 痛点门槛未纳入程序化变换，与 6.2、8.3 准入冲突 | 强席位阻塞 | 已修复 | 9.1 痛点真实性行与表后口径；8.2 援引自动恢复一致 |
| 2 | 核验席（普通异议，非兜底） | 同一 9.1 冲突，并指出第 2 轮为 6.2 增加第二决策轴时未同步更新 9.1 | 第三方核验异议 | 已修复 | 同第 1 项 |
| 3 | 核验席（解析兜底项） | 结构未完全确认的段落保留原文 | 兜底项 | 已核对 | 无独立主张，所指内容由第 1、2 项覆盖 |
| 4 | 质疑席 | 复审材料在任务书条文前被截断，议题原文未送达 | 强席位阻塞（验收事项） | 不属正文缺陷 | 该意见不指向报告内任何位置，属接收环节；正文无需改动。第 4 轮改用精简材料并核对送达完整性 |
| 5 | 第二主持 | 3.3 架构图只有经 Porch 到 Git 的连线，与模式一、阶段二不部署 Porch 矛盾 | 主持席阻塞 | 已修复 | 3.3 图示与图后说明 |
| 6 | 第二主持 | 4.1 把试点计入采用案例，4.4 又称只有生产部署支撑使用结论 | 主持席阻塞 | 已修复 | 4.1 采用分层；4.4 补充试点证明力 |
| 7 | 第二主持 | C.7 闭环声明覆盖过宽 | 主持席意见 | 已修复 | C.7 声明限定为第 2 轮阻塞项所涉章节 |
| 8 | 主主持、核验席 | 2.2 节级标注规则在若干比较表落空 | 少数意见 | 已修复 | 2.2 与 5.2、5.3、7.2、8.1、第十章表前 |
| 9 | 主主持、核验席 | 6.1 七项收益不含程序化变换，易被误读为全部差异 | 少数意见 | 已修复 | 6.1 表后说明 |
| 10 | 主主持 | 1.4 统计范围与唯一计入的 Nephio 线索不齐 | 少数意见 | 已修复 | 1.4 补“项目级、早于发布” |
| 11 | 主主持 | 9.3 第 4 步并写拒收验证与隔离执行 | 少数意见 | 已修复 | 9.3 第 4 步拆为两步 |
| 12 | 主主持、核验席 | 9.1 治理前置“试点前”与 9.5“规模化之前”时点不清；9.1 打分与阶段一先后不明 | 少数意见 | 已修复 | 9.1 表后口径；9.5 区分组织级基线 |
| 13 | 主主持、核验席 | C.8 的 R7 行称 8.1 已标为判断，实际无标注 | 少数意见 | 已修复 | 8.1 表前补标注；C.8 R7 行措辞对齐 |
| 14 | 主主持 | 第十三章第 1 条“上游包跟随属 CLI 层”未落正文 | 少数意见 | 已修复 | 6.1 表后说明 |
| 15 | 主主持、核验席 | 11.2 的 P1 年份界与统一窗口对应不清 | 少数意见 | 已修复 | 11.2 表后说明 |
| 16 | 主主持、核验席 | C.7 第 26 项“书面保留”与“分歧失去对象”并置 | 少数意见 | 已修复 | C.7 第 26 项处理栏 |
| 17 | 核验席 | 4.2 的厂商安装线索与 C.2“产品集成细节未入正文”有张力 | 少数意见 | 已修复 | C.2 补归属说明 |
| 18 | 核验席 | 9.1 团队能力门槛与 8.3 单包试写的补救路径可理解为先后阶段 | 少数意见 | 已修复 | 9.1 表后口径 |
| 19 | 顾问席 | 类型约束语言与轻量沙箱、通用制品分发的替代路线 | 少数意见 | 保留为观察项 | 第十三章第 8 条 |
| 20 | 顾问席 | 认为本轮无阻塞项 | 意见 | 未采纳 | 两处冲突经核对成立，见第 1、5 项 |

**闭环结论：** 第 1、2 项为同一实质缺陷，已按最小改动修复；第 5、6 项冲突亦已修复；第 3 项为无独立内容的兜底项，已核对；第 4 项属材料接收的验收事项，不是报告正文缺陷，第 4 轮以精简材料重发并核对送达完整性。因此本版不存在未闭环的正文阻塞项，强席位的阻断意见所指的正文问题已全部处置，待第 4 轮定向复核确认。

### C.12 篇幅统计（v1.0-r3）

- 正文（第一至十三章，不含附录、图示代码与标点）约 1.09 万字（自述估算，按汉字计）；
- 正文表格 14 个，附录表格 6 个（较上一版增加 C.11 的处理对照表 1 个），图示 2 个；
- 相对上一版（C.9 记约 1.00 万字），正文增加约 0.9 千字，集中在第一章、第三至四章、第六章与第九章的准入与标注表述；未新增外部来源、版本号或案例。此处按两版同一口径的实计汉字差校正；第 4 轮复审指出的算术不齐源于原记数比实计高约 0.06 万字，现以本行为准。

### C.13 v1.0-r4 修订说明（2026-11-08）

本版依据第 4 轮复审结果修订。该轮为标准深度、硬上限：五席独立意见与互评齐全，法定人数满足；两主持席、质疑席与顾问席最终表决为“通过”，核验席（以普通必需席身份参与）最终表决为“需修订”。本轮没有强席位阻塞项；核验席提出一项可定位的第三方核验异议，指出 9.1 规模维度仍只按包数、环境数、集群数的计数乘积判断，未为“包量小、程序化变换需求已能量化”的团队提供替代判据，与 6.2 第二问、8.3 首问与第十二章的建议路径存在读法冲突。

修订原则与前几版相同：按最小改动消除读法冲突，不牵动主线结论；能以一句话消歧的少数意见一并落地；不新增任何外部来源、版本号、案例或引文。

主要改动：

1. 9.1 规模维度改为两类估算方式并存：包治理类按三项计数乘积估算，程序化变换类按变换量级、调用频率或可量化节省估算；门槛改为任一估算方式足以证明固定成本可被摊薄即可，不设包数下限，并在表后口径中明确规模维度是经济性判据而非数量下限。
2. 9.1 痛点真实性的门槛补量化示例（每月需生成的配置包数、单次变换的人工工时、变更错误率或返工次数）；9.2 阶段一补“按 9.1 完成打分”。
3. 8.3 首问改为两类需求并列，明确“大规模”只修饰包治理三项；仅 CLI 渲染节点改标为阶段二并注明须先通过 9.1 评估，Porch 节点改标为阶段三，图后补编号与 9.2 对齐的说明。
4. 8.2 的集群规模段与第十二章一般企业行同步改引 9.1 的两类估算方式。
5. 3.3 图补一条由 Porch 指向持续协调器的可选虚线（控制器直读包修订），图后说明同步并标明该能力待核。
6. 3.2 运维成本一条补判断标注；4.4 补 4.2 线索在五级阶梯中的定位。
7. 附录 A 两行改写：Nephio 线索明确为项目级集成而非生产案例；缺口改为“本次未取得”，不再使用排除句式，证据级别仍按 2.2 的三级口径记待核。
8. C.12 篇幅统计按行文实计改正，与 C.9 及 0.9 千字增量对齐。

### C.14 第 4 轮复审意见逐条处理

下表合并同类意见，按来源与性质归并。处理栏中“已修复”指正文已按意见改写并注明落点，“书面保留”指本报告维持原判断并说明理由。

| 序号 | 来源 | 意见要点 | 性质 | 处理 | 落地位置 |
|---|---|---|---|---|---|
| 1 | 核验席 | 9.1 规模维度仍只按三项计数乘积判断，未给低包量、高变换复杂度团队替代判据，与 6.2、8.3、第十二章冲突 | 第三方核验异议（本轮唯一实质异议） | 已修复 | 9.1 规模维度与表后口径；8.2、8.3、第十二章同步 |
| 2 | 核验席（解析兜底项） | 结构未完全确认的段落保留原文 | 兜底项 | 已核对 | 无独立主张，所指内容由第 1 项覆盖 |
| 3 | 主主持、质疑席、核验席 | 规模维度未写明以可量化节省替代计数乘积 | 少数意见（与第 1 项同源） | 已修复 | 同第 1 项 |
| 4 | 主主持 | 8.3 首问“大规模”修饰范围不清 | 少数意见 | 已修复 | 8.3 首问与图后说明 |
| 5 | 主主持、核验席、第二主持、顾问席 | 8.3 与 9.2 的阶段编号不一致 | 少数意见 | 已修复 | 8.3 节点改标阶段二、阶段三，图后说明 |
| 6 | 主主持、核验席、第二主持 | 附录 A 排除句式可能暗示存在具名生产案例 | 少数意见 | 已修复 | 附录 A 两行 |
| 7 | 主主持、质疑席、核验席、第二主持 | C.12 篇幅算术不自洽 | 少数意见 | 已修复 | C.12 |
| 8 | 主主持、第二主持、顾问席 | 3.3 图未画控制器直读包修订 | 少数意见 | 已修复 | 3.3 图与图后说明 |
| 9 | 核验席 | 3.2 运维成本推断未单独加判断标注 | 少数意见 | 已修复 | 3.2 运维成本条 |
| 10 | 核验席 | 4.2 的 Nephio 未映射进 4.4 五级阶梯 | 少数意见 | 已修复 | 4.4 末段 |
| 11 | 核验席 | 9.1 痛点行未示例如何量化程序化变换需求 | 少数意见 | 已修复 | 9.1 痛点真实性行 |
| 12 | 顾问席 | 类型约束语言与通用制品分发的替代路线 | 少数意见 | 保留为观察项 | 第十三章第 8 条 |
| 13 | 各席 | 证据缺口：发布真实性、四项兼容承诺、非电信生产案例、Porch API 成熟度、量化收益 | 口径声明 | 书面保留 | 摘要边界说明、2.3、附录 A 后续材料 |

**闭环结论：** 本轮唯一表达的实质异议为第 1 项，已按最小改动修复，并同步 8.2、8.3 与第十二章的交叉引用；第 2 项为无独立内容的兜底项，已核对。其余少数意见除第 12 项保留为观察项外均已落地；第 13 项是既定证据边界的再次声明，报告未把待核内容当作已证事实。第 4 轮为硬上限，本版不存在未闭环的强席位阻塞项。

### C.15 篇幅统计（v1.0-r4）

- 正文（第一至十三章，不含附录、图示代码与标点）约 1.15 万字（自述估算，按汉字计）；
- 正文表格 14 个，附录表格 7 个（较上一版增加 C.14 的处理对照表 1 个），图示 2 个；
- 相对上一版（C.12 记约 1.09 万字），正文增加约 0.6 千字，集中在 3.2、3.3、4.4、8.2、8.3、9.1、9.2、第十二章与附录 A；未新增外部来源、版本号或案例。

### C.16 v1.0 定稿说明（2026-11-08）

本版为正式版本 v1.0，依据第 4 轮复审后的修订工作稿定稿：文首版本标记改为正式版本号 v1.0，正文以该工作稿为基础。定稿阶段按复核建议做三处限定性编辑，不改变任何结论、建议优先级或证据级别，也未新增外部来源、版本号、案例或引文：

1. 5.2 表与 5.4 的审批表述由“决策始终由人承担”改为“审批策略与责任由组织确定，具体审批动作可由人工或获授权的自动化执行”，避免把治理责任与具体审批动作混为一谈。
2. 5.3 表与表后说明、9.1“现有方案缺口”一行补默认能力限定：程序化变换能力的对照限于各工具默认内置工作流，Kustomize 等可通过外部插件或函数扩展补齐，缺口评估应同时比较扩展现有工具与引入 kpt 的维护成本。
3. 3.3 图与图后说明把“控制器直读包修订”标注为需额外适配的候选路径，并写明本次未核实是否存在现成的适配实现。

第 4 轮第三方核验异议的处置已在第 4 轮复审后修订中落地，定稿沿用修复后文本：核验席指出 9.1 规模维度只按包数、环境数、集群数的计数乘积判断，未给“包量小、程序化变换需求已能量化”的团队提供替代判据。修复方式为：9.1 规模维度改为两类估算方式并存（包治理类按三项计数组合、程序化变换类按变换量级、调用频率或可量化节省），门槛写明任一估算方式足以证明固定成本可被摊薄即可、不设包数下限；8.2、8.3 与第十二章的交叉引用同步改引该口径。

定稿篇幅与 C.15 基本一致（只增加上述限定语）：正文（第一至十三章，不含附录、图示代码与标点）约 1.15 万字（自述估算，按汉字计）；正文表格 14 个，附录表格 7 个，图示 2 个。

### C.17 v1.0-r1 再审议修订说明（2026-11-09，内部工作稿）

本版是对 v1.0 的再次审议稿，依据第 1 轮意见收集（四席有效作答、一致表决需修订；顾问席缺席按规约采纳）与 2026-11-09 的一手核验记录撰写。正式版本将在后续复审后定为 v1.1；本工作稿文首保留内部标记，不对外发布。

修订原则：**保留原报告的标题、十三章结构与既有更新历史；以一手来源升级证据、纠正日期口径、收窄兼容承诺；不改变“CLI 先行、Porch 按需、收益属设计意图、采用证据稀缺”的主线结论；不新增任何未经来源支持的事实。**

主要改动：

1. **研究方式改写。** 删除“全程离线”的表述，改为“一手核验＋多模型研判”，并在 2.3 如实列出实际读取的页面、GitHub API、未做事项与五项覆盖限制；附录 B 给出 26 条直接来源、读取日期与支持范围。
2. **发布与版本口径。** 全文区分 GitHub tag 发布日（2026-08-31）与 CNCF 博客公告日（2026-11-05）；补充 v1.0.1（2026-09-25）为当前稳定补丁、v1.0.2 仍在预发布；纠正“版本序列无法复述”“若发布属实”等表述。**（第 3 轮更正：v1.0.1 的标注改为“最新的非预发布补丁”，见 C.24。）**
3. **成熟度与治理。** 补充 kpt 为 CNCF Sandbox（2023-06-30 接受）；区分“接受”与 2026-07 博客所称“完成 onboard”；明确博客不等于背书或晋级；贡献者与组织数不作采用率。
4. **兼容承诺收窄。** 7.4 按包格式、CLI、函数契约、服务端 API 四面分层，写入 minor 可破坏、K8s 兼容未定义、`latest` 不得用于生产；11.1 由“稳定性承诺”收窄为“有限承诺”。
5. **Porch 能力与 API 分层。** 3.2 补“不部署、不提供包仓库、不替代 kpt”，区分服务端版本、API 模块与 PackageRevision API 表面；补 Kubernetes 1.37.0 要求、v1alpha1/v1alpha2 状态与 Porch 迁移历史。
6. **修正“仅上游配置层”的过强表述。** 3.3、5.1、5.2 明确 kpt 工具链含 `kpt live apply`，官方 FAQ 以 packaging and actuation 概括其用途；同时说明 `kpt live` 是一次性 apply、不提供常驻漂移协调，不构成持续协调器的等价替代；新增“模式三：命令式 apply”一行与相应图示虚线。
7. **采用证据与统计范围。** 4.1 明确统计覆盖发布前后、不再只统计发布后新增；4.2 用 Nephio 与 Kubeflow 文档两条已核实线索替换无法找到直接页面的“Google Cloud 配置管理产品线”表述；强调“未取得”不等于“不存在”，无 ADOPTERS 文件是已核实事实但不等于无人使用。
8. **收益与成本。** 6.1 为七项收益逐项补强成立前提，把“增量”改为“候选增量”并注明原生能力不等于净收益；6.1 的“三方合并”标注为本次未取得直接说明；7.1 增加版本升级回归、Kubernetes 适配与 Porch 治理不确定性三项成本；7.2 增加“错误产物经合法审批被反复部署”“版本升级破坏兼容”“Kubernetes 版本不匹配”三种失败模式。
9. **趋势命题。** 11.2 把 P1 拆为“活跃维护”（P1a）与“小众定位”（P1b），为 P2 增加“默认渲染层”的可观察定义，P3 删除点估计与上限；11.3 删除已被发布事实排除的“查无发布记录”，改为“v1.0.2 正式版长期不发或维护中断”。
10. **少数意见与治理。** 第十三章保留原有八条并新增第 9 条（`kpt live apply` 是否可作为长期生产部署方式的保留分歧）；第十章、9.3、9.5 增加最终产物授权、发布凭据隔离、失败拒发三项控制。
11. **未改动的部分。** 8.2、8.3、9.1 的旧修复按原样保留（小集群但包治理繁重者仍可进入 CLI 试点、Porch 维护能力只约束 Porch、9.1 两类规模估算与不设包数下限），以避免历史阻塞项复发；第十三章原有少数意见的实质立场不变。

### C.18 第 1 轮审议意见逐条处理

本轮为意见收集制：主主持、质疑席、核验席、第二主持四席有效作答，均表决“需修订”；顾问席未作答，按非强席位缺席规则采纳，本轮不判通过。下表按主题归并四席意见；“已采纳”指正文已改写，“部分采纳”指保留分歧并记入第十三章。

| 序号 | 来源 | 意见要点 | 处理 | 落地位置 |
|---|---|---|---|---|
| 1 | 四席 | 发布已核实，须分列 tag 日与博客日，改写“尚未核实/若发布属实” | 已采纳 | 1、2.4、3.1、11.1、附录 A |
| 2 | 四席 | 补 CNCF Sandbox 身份，区分 2023 接受与 2026-07 onboard，博客不等于晋级 | 已采纳 | 1 边界段、3.1 |
| 3 | 四席 | 版本序列可核实；维护放缓降为条件判断；星数/issue 数不作采用率 | 已采纳 | 3.1、7.3、附录 B |
| 4 | 四席 | 兼容承诺须收窄，7.4 四面分层，11.1 改为有限承诺 | 已采纳 | 7.4、11.1、第十章 |
| 5 | 质疑席 | “仅上游配置层”过强，与 `kpt live apply` 及官方 actuation 表述冲突 | 已采纳 | 3.3、5.1、5.2、13 第 9 条 |
| 6 | 四席 | Porch 服务端、API 模块、PackageRevision 表面与 K8s 要求须分层 | 已采纳 | 2.4、3.2、7.4、9.2、11.2 |
| 7 | 质疑席 | 不能由“无模板”推出任意阶段资源合法或通过模式校验 | 已采纳 | 3.1、3.4 |
| 8 | 四席 | 比较基准须一致，项目方主张须标注 | 已采纳 | 1、3.4、5.3、6.2 |
| 9 | 四席 | 采用证据分层；统计覆盖发布前后；“未取得”不等于“不存在” | 已采纳 | 4.1、4.2、4.4、附录 A |
| 10 | 四席 | 收益仍为设计意图；两项“候选增量”；原生能力不等于净收益 | 已采纳 | 6.1、6.2 |
| 11 | 四席 | 成本补升级回归、K8s 适配、Porch 治理；失败模式补恶意输出与部分发布 | 已采纳 | 7.1、7.2、9.3、第十章 |
| 12 | 质疑席、第二主持 | P1 拆为维护与定位；P3 不作点估计与上限；可信度下调 | 部分采纳（保留 P1a/P1b 与 P2 的未校准区间） | 11.2、13 第 3 条 |
| 13 | 四席 | 研究方式须如实改写；更新历史保留并追加 | 已采纳 | 文首、附录 D |
| 14 | 核验席、第二主持 | 缺来源句子须删除或降级：setter/substitution、Google Cloud 配置管理产品线、三方合并、贡献者集中 | 已采纳 | 3.1、4.2、6.1、7.3 |
| 15 | 质疑席 | 18 项历史异议未逐 ID 内联，宿主须逐项列新落点 | 已采纳 | C.19 |
| 16 | 质疑席 | 顾问席缺席仍应按 P1 采纳，不整轮重跑 | 已采纳 | 本表说明、C.17 |

### C.19 011 议题 18 项历史异议逐项核对（本稿）

核对方式：只读打开原异议记录与同目录复核材料，按原 ID 逐项确认旧修复在本稿中是否仍成立；原目录未作任何修改。18 项构成：11 项第 1 轮“模型知识待核实”类异议、1 项第 1 轮兜底项、3 项实质阻塞项（对应三轮复审）、3 项兜底项。

| 序号 | 短 ID | 阶段/性质 | 旧修复落点 | 本稿是否仍成立 | 核对说明 |
|---|---|---|---|---|---|
| 1 | 43f23e88c97f | r1 待核类 | 3.1 概念表、3.2、附录 B | 成立且已升级 | 3.1 概念与 3.2 边界已有一手来源；未核的演进细节仍标判断 |
| 2 | 3db0e39849d4 | r1 待核类 | 3.2、3.3、5.2 | 成立且已升级 | Porch 定位、生命周期与可选叠加有直接来源 |
| 3 | a7bc5bc81a48 | r1 待核类 | 4.1、4.2、4.4、附录 A | 成立且已升级 | Nephio 升为已核实项目级集成；仍不升格为生产采用 |
| 4 | beedb6bf9809 | r1 待核类 | 5.1、5.2、3.3 | 成立并修正 | 保留分层，补 `kpt live apply` 的边界 |
| 5 | 6ac7d89e183e | r1 待核类 | 6.1、6.2 | 成立 | 七项收益仍按设计意图；增量改为候选增量 |
| 6 | 146d5d0183e6 | r1 待核类 | 7.1、7.2、7.3、第十章 | 成立并扩展 | 增加升级回归、K8s 适配与错误产物风险 |
| 7 | ba354c5cdede | r1 待核类 | 8.1 | 成立 | 同层重叠与可组合注保留 |
| 8 | ba189c6fcf90 | r1 待核类 | 第九章、第十二章 | 成立 | 建议路径与阈值口径未回退 |
| 9 | 5a13709ad749 | r1 待核类 | 第十一章 | 成立并修订 | 三命题拆为四命题，P3 删除上限 |
| 10 | 5013fa719373 | r1 待核类 | 第十章、3.2、7.4 | 成立并扩展 | 补最终产物授权与发布凭据隔离 |
| 11 | b9f1f2909c60 | r1 待核类 | 2.2、附录 A | 成立并升级 | 三级口径升为四级，新增“项目方主张”“未取得” |
| 12 | 6c47b3d915b9 | r1 兜底 | 2.2、附录 A、C.8 | 成立 | 无独立主张；所指内容仍被覆盖 |
| 13 | 90fe063ca306 | r2 阻塞 | 8.2、8.3、9.1 | 成立（不得删弱） | 8.2 三段、8.3 服务端一问、9.1 组合口径原样保留 |
| 14 | aacdc56d3906 | r2 兜底 | 8.2、8.3、C.7 | 成立 | 无独立内容；实质项同第 13 项 |
| 15 | e406d8d5dd74 | r3 阻塞 | 9.1 痛点门槛、8.2、8.3 | 成立（不得删弱） | 9.1 痛点行仍含程序化变换与两类量化示例 |
| 16 | 85861749675f | r3 兜底 | 9.1、9.3、C.11 | 成立 | 无独立内容；措辞与时点已在 9.1、9.3 保留 |
| 17 | 77ab0a919634 | r4 阻塞 | 9.1 规模维度、8.2、8.3、第十二章 | 成立（不得删弱） | 两类估算与“不设包数下限”原样保留 |
| 18 | 986a92781b6a | r4 兜底 | 9.1、8.3、附录 A、C.14 | 成立 | 无独立内容；实质项同第 17 项 |

**核对结论：** 3 个实质阻塞项的旧修复在本稿中均未被删弱；4 个兜底项均无独立主张；11 项待核类异议的旧降级处理未被回退，其中多数已由本次一手核验升级为“已核实”或收窄为“判断/未取得”。原目录保持只读，未作修改。第 2 轮修订改动集中在 1.9、3.1、3.2、3.3、5.1–5.4、6.1、6.2、7.1、7.3、7.4、8.1 注、9.2、9.3 与附录 B 第 26 条，均不涉及 8.2、8.3、9.1 的旧修复落点；第 6 项（7.1 治理措辞）虽在本表覆盖范围内，改动只收紧了因果表述，未删弱该条对维护连续性的提示。核对后结论不变。

### C.20 篇幅统计（本稿，2026-11-09）

- 正文（第一至十三章，不含附录、图示代码与标点）约 1.6 万字（按汉字实计，口径与历史各版一致）；
- 正文表格 15 个（v1.0 为 14 个，本稿新增 2.4“关键事实的当前证据状态”1 个）；附录表格 9 个（附录 A 1 个、附录 C 1 个、附录 D 7 个），图示 2 个；
- 相对 v1.0（约 1.15 万字），正文增加约 4.4 千字，集中在第二章（方法与证据状态）、第三章（版本、Porch API 与 `kpt live apply` 边界）、第四章（采用统计范围）、第七章（成本与失败模式）与第十一章（命题拆分）；
- 新增直接来源 26 条；未新增任何无法追溯的版本号、公司名或引文。

### C.21 v1.0-r2 修订说明（2026-11-09，内部工作稿）

本版依据第 2 轮复审结果修订。该轮为标准深度：五席独立意见与互评齐全，法定人数满足；两个主持席不计票，质疑席在两阶段均表决“通过”，核验席与顾问席在互评阶段表决“需修订”，主持综合为“需修订”。综合稿把 3.2 版本与迁移条目的仓库时间线表述判为唯一阻塞项（五席一致认为该句必须更正，分歧在是否构成阻塞，按 3 比 2 采纳阻塞判定），其余为不阻塞的标注、措辞与证据缺口提示。

修订原则：**阻塞项按最小改动改正；少数意见凡能以一句话消歧的一律落地；不改任何结论、建议优先级、路径编号与证据级别；不新增未经来源支持的事实。** 本轮删除了一项上一稿超出核验摘录支持的分句（见下表第 9 项），这是唯一的事实性删除，理由是核验摘要中只有 code owner 条款，没有 PR 双人批准的原文摘录。**（2026-11-09 第 3 轮更正：该删除所依据的摘要并不完整；治理原文与核验长记录 K05 均含该句，本版已恢复该分句并更正记录，见 C.24。）**

主要改动：

1. **阻塞项（3.2、附录 B 第 26 条）**：把“回归后新仓库”改为“该仓库创建于 2023-12-18（即捐给 Nephio 之时，而非回归后新建）”，使仓库创建时点与同段“2023-12 捐给 Nephio、2026-05 回到 kptdev”的叙述及核验记录一致；星数与开放 issue 数不可与 kpt 主仓比较的结论保留。
2. **版本标注（1.9、3.1）**：把 Kubernetes 1.37.0 的事实标注与旧集群适配成本判断拆开；3.1 补充 `cli/v1.0.2-pre.4` 标签的 `prerelease` 字段差异说明，明确不得据此判为稳定版。
3. **治理表述（3.1、7.3）**：删去“所有 PR 须由两人批准”，只保留有原文摘录支撑的 code owner 条款；结论“有基本治理”不变。
4. **能力否定统一收窄（5.1、5.2、5.4）**：把“不提供常驻漂移协调”的确定式否定统一改为“本次未取得其提供常驻漂移协调的直接说明，因此不按持续协调器评估”，模式三的定位不变。
5. **引文口径（1 边界段、3.2、3.3、5.3、7.4、8.1 注）**：中文译文置于引号内处均标注为中译；3.3 关于 FAQ 的表述由“概括 kpt 的用途”改为说明其组合语境并引英文原文，不再外推。
6. **收益口径（6.1 表头、6.2）**：表头“是否为增量”改为“相对默认基线的候选能力差异”；6.2 首句补“按不借外部工程即可原生获得计”与对 6.1 表注的交叉引用。
7. **治理风险（7.1 第 7 项）**：改为“治理归属的变化意味着维护连续性需要观察”，不再把归属迁移直接当作维护投入波动的证据。
8. **失败验收（9.2、9.3）**：阶段一核对 Kubernetes 版本要求处注明该要求只约束 Porch 服务端；9.3 区分“产物发布失败应拒发”与“集群侧部分应用不具事务性、须以集群实际状态验收”。
9. **保留分歧（11.2、第十三章第 3 条）**：质疑席与第二主持主张删除未校准的概率区间，主主持主张保留。本版保留区间并维持既有“未校准”限定，分歧继续记入第十三章。

本轮未新增任何外部来源、版本号、日期、公司名或引文；核验基础仍是 2026-11-09 的一手核验记录（附录 B 的 26 条来源与核验长记录 K01–K34）。

### C.22 第 2 轮复审意见逐条处理

下表按主题归并同源意见；对照对象为各席互评阶段原文。处理栏中“已修复”指正文已按意见改写，“书面保留”指维持原判断并说明理由，“已核对”指该意见不产生正文改动但已核到具体位置。

| 序号 | 来源 | 意见要点 | 性质 | 处理 | 落地位置 |
|---|---|---|---|---|---|
| 1 | 核验席、顾问席 | 3.2“回归后新仓库”与同段捐出、回归的时间线及 created_at=2023-12-18 冲突 | 阻塞项（主持综合采纳，表决 3 比 2） | 已修复 | 3.2；附录 B 第 26 条 |
| 2 | 核验席、顾问席、第二主持 | 3.1 应说明 `cli/v1.0.2-pre.4` 的字段差异不得判为稳定版 | 非阻塞建议 | 已修复 | 3.1 |
| 3 | 核验席、顾问席、第二主持、主主持 | 1.9 把 1.37.0 事实与成本判断合并标为判断 | 非阻塞建议 | 已修复 | 1.9 |
| 4 | 核验席、质疑席、第二主持 | 5.1、5.4 的“不提供常驻漂移协调”是证据不足的确定式否定，宜统一收窄 | 少数意见 | 已修复 | 5.1、5.2、5.4 |
| 5 | 核验席、顾问席、质疑席、第二主持 | 6.2“候选实质增量”应注明计数基准并与 6.1 表注交叉引用；表头措辞易被读成已测净收益 | 少数意见 | 已修复 | 6.1 表头、6.2 |
| 6 | 核验席、主主持、质疑席、第二主持 | 7.1 第 7 项把治理归属迁移直接写成维护投入波动 | 少数意见 | 已修复（收紧因果） | 7.1 |
| 7 | 核验席、顾问席、主主持、质疑席、第二主持 | 1 边界段、3.2、7.4 的中译置于引号内未标注；5.3、8.1 注同理 | 少数意见 | 已修复 | 1、3.2、7.4、5.3、8.1 注 |
| 8 | 核验席、主主持、顾问席、质疑席、第二主持 | 3.3 称 FAQ“把 kpt 的用途概括为”属转述外推，原文是组合语境 | 少数意见 | 已修复 | 3.3 |
| 9 | 核验席、主主持、第二主持 | 3.1“所有 PR 须由两人批准”超出核验摘录范围 | 证据缺口 | 已修复（删分句，保留 code owner 条款）；第 3 轮更正：删除依据为不完整摘录，本版已恢复，见 C.24 | 3.1、7.3 |
| 10 | 核验席、质疑席 | 9.3 应区分“产物发布失败拒发”与“集群部分应用”，避免被读成集群更新具事务性 | 少数意见 | 已修复 | 9.3 |
| 11 | 质疑席 | 阶段一核对 Porch 集群要求应明确仅约束 Porch 分支 | 少数意见 | 已修复 | 9.2 |
| 12 | 质疑席、第二主持 | 应删除未校准概率区间 | 少数意见 | 书面保留 | 11.2、第十三章第 3 条 |
| 13 | 核验席 | C.19 的 18 项逐项核对表未内联，五席均不宣称完成，须宿主核对 | 证据缺口 | 已核对（宿主按原 ID 逐项对照原异议记录与既有终审记录，见 C.19；本轮改动未触及 8.2、8.3、9.1 的旧修复落点） | C.19 |
| 14 | 核验席、顾问席、第二主持 | R2 成熟度表述与 R6 采用证据分层正确；补充检索建议（运行范围、维护主体、故障经验） | 无缺陷 | 无需修改；建议已记入附录 A“后续必须补齐的材料” | 3.1、4.1–4.4、附录 A |
| 15 | 核验席 | 结构未完全确认的段落保留原文（兜底项） | 兜底项 | 已核对，无独立主张 | 无 |

**闭环结论：** 本轮唯一被主持综合采纳的阻塞项为第 1 项，已按最小改动改正并同步附录 B；核验席与顾问席在互评阶段投“需修订”的依据即该项与上述非阻塞建议，均已在正文落地或书面保留并向读者披露。质疑席两阶段均表决“通过”，未提出强席位阻塞项。第 15 项为无独立内容的兜底项。第 13 项的核对由宿主完成，结论见 C.19。据此，本版不存在未闭环的正文阻塞项；第 3 轮复审为默认轮次。

### C.23 篇幅统计（v1.0-r2）

- 正文（第一至十三章，不含附录、图示代码与标点）约 1.61 万字（按汉字实计，口径与历史各版一致；上一稿同口径为 1.58 万字）；
- 正文表格 15 个，附录表格 10 个（较上一稿增加 C.22 的处理对照表 1 个），图示 2 个；
- 相对 v1.0-r1，正文增加约 0.03 万字（约 290 字），集中在 1.9、3.1–3.3、5.1–5.4、6.1–6.2、7.1、7.3、7.4、8.1 注、9.2、9.3 与附录 B；未新增外部来源、版本号、案例或引文。

### C.24 v1.0-r3 修订说明（2026-11-09，内部工作稿）

本版依据第 3 轮复审结果修订。该轮为意见收集制：插件法定人数未满足，没有互评与主持综合，不能判为通过。五席中四席有效作答：主主持与第二主持表示认可（两主持席不计票），质疑席表决“通过”；核验席（按普通异议席位计）表决“需修订”，提出三项必改；顾问席因引文核验被拒记为盲席，按非强席位唯一缺席的既有规则采纳，其意见不计入有效票。强席位（质疑席）未提出阻塞项。

修订原则：必改项按最小改动改正；非阻塞意见能以一句话消歧的落地；不改任何结论、建议优先级、路径编号与证据级别；不新增未经一手来源支持的事实。本轮重新打开治理仓库、kpt v1.0.1 发布记录、Porch 发布记录与 Porch 兼容页四项来源，核对记录见核验长记录 K38–K40。

主要改动：

1. **治理条款恢复（3.1、7.3、附录 B 第 7 条）**：恢复“所有 PR 须由两名 code owner 共同批准”，与“两名 code owner 不得来自同一公司”并列，并保留“这是治理规范，不证明实际执行率、投入规模或商业支持”的限定。第 2 轮删除该分句所依据的核验摘要并不完整，治理原文与核验长记录 K05 均含该句；C.21 与 C.22 相应行已加更正注记。
2. **版本标签更正（1.1、2.4、9.2、附录 A）**：把“稳定补丁”统一改为“最新的非预发布补丁”。发布记录只支持“已发布且非预发布字段”，不支持稳定性承诺；这与 3.1 关于 `prerelease` 字段不能判稳定的论证一致。
3. **Porch API 模块版本（3.2、7.4、附录 A、附录 B 第 17 条）**：正文不再把 1.0.3 与推荐版本 1.0.1 并列。GitHub 发布记录把 api/v1.0.3 标为非预发布（2026-09-29），兼容页却把它列为 v1.6.4 预发布系列的推荐模块并标注 Pre-release，两处口径不一；本报告只把 1.0.1 作为 v1.6.3 的推荐 API 模块，并在附录保留原始记录与差异说明。
4. **收益计数口径（6.1、6.2）**：6.1 表内“候选增量”统一改为“能力增量”或“实质能力增量”，表注明确它与 6.2“实质增量”是不同计数口径；结论与推荐不变。
5. **兼容章表述（7.4）**：API 模块处注明“推荐版本”，避免被读成服务端支持矩阵。

未改动：核心结论、建议优先级、第九章路径编号、证据级别与第十一章概率区间。上游包跟随的三方合并实现仍未取得直接说明，正文保留该限定，不作事实升级。

### C.25 第 3 轮复审意见逐条处理

下表对照各席独立意见原文；该轮没有互评与主持综合，表决取独立意见阶段。

| 序号 | 来源 | 意见要点 | 性质 | 处理 | 落地位置 |
|---|---|---|---|---|---|
| 1 | 核验席 | 治理引文仍以内部证据文件悬置；应恢复“PR 须两名 code owner 批准且不同公司”，并在更新说明记录第 2 轮删除基于不完整摘录 | 必改项 | 已修复（恢复分句、更正历史注记、正文不含内部证据指针） | 3.1、7.3、附录 B 第 7 条、C.21、C.24 |
| 2 | 核验席 | “v1.0.1 稳定”标为已核实，超出“只证发布事件”的支持上限，且与正文对预发布字段的论证矛盾 | 必改项 | 已修复（改为“非预发布补丁”） | 1.1、2.4、9.2、附录 A |
| 3 | 核验席 | 7.4 的“API 模块 1.0.1/1.0.3”中 1.0.3 缺内联证据 | 必改项 | 已修复（正文不再并列；附录保留原始记录与兼容页差异） | 3.2、7.4、附录 B 第 17 条 |
| 4 | 核验席 | 6.1 与 6.2 的“候选增量”“实质增量”易被读成矛盾，建议改称“能力增量” | 少数意见 | 已修复 | 6.1、6.2 |
| 5 | 核验席 | 7.4 应在“API 模块”后注明“推荐版本” | 少数意见 | 已修复 | 7.4 |
| 6 | 主主持 | 同第 1 项：恢复分句优于仅改历史说明，并删除内部指针 | 非阻塞建议 | 已修复（本稿正文不含内部证据指针） | 3.1、C.24 |
| 7 | 主主持 | 6.1 宜写明部分能力按 6.2 不计为实质增量 | 非阻塞建议 | 已修复（采用“能力增量”并注明两种口径） | 6.1 |
| 8 | 主主持 | 7.4 的 1.0.3 应补证或删除 | 非阻塞建议 | 已修复（同第 3 项） | 3.2、7.4 |
| 9 | 主主持 | 上游包跟随缺独立证据，建议补摘录或降级为判断 | 少数意见 | 书面保留：现有表述已注明“三方合并的具体实现本次未取得直接说明”，并按设计意图计，不升级为事实 | 6.1、第十三章 |
| 10 | 质疑席、第二主持 | 质疑席表决“通过”，第二主持表示认可；均未提出新增必改项 | 无缺陷 | 已核对 | — |
| 11 | 顾问席 | 引文核验被拒，记为盲席；其对 R1–R8 的核对方向与其余席位一致 | 非强席位唯一缺席 | 按既有规则采纳并记缺席，其意见不计入有效票 | — |
| 12 | 结果文件兜底项（结构未能完全确认的段落） | 未给出可定位的独立主张 | 兜底项 | 已核对，无正文改动 | — |

**闭环结论：** 核验席三项必改均已落地；强席位（质疑席）表决“通过”，没有强席位阻塞项。第 3 轮因法定人数未满足只完成意见收集，不能作为通过依据，须进入第 4 轮复审。

### C.26 篇幅统计（v1.0-r3）

- 正文（第一至十三章，不含附录、图示代码与标点）约 1.61 万字（按汉字实计，同口径为 16144 字；上一稿同口径为 15973 字）；
- 正文表格 15 个，附录表格 11 个（较上一稿增加 C.25 的处理对照表 1 个），图示 2 个；
- 相对 v1.0-r2，正文增加约 0.02 万字（约 171 字），集中在 3.1–3.2、6.1、7.3–7.4、9.2 与附录 B；未新增外部来源，新增的是对既有来源的再核对与两处口径更正。

### C.27 v1.0-r4 修订说明（2026-11-09，内部工作稿）

本版依据第 4 轮复审结果修订。该轮为标准深度、硬上限：五席独立意见与互评齐全，法定人数满足，五席在独立意见与互评两阶段均表决“通过”，没有强席位阻塞项，也没有普通异议需要逐项核销；本轮满足完整研讨的通过条件。各席的复审只针对送审精简本，均未回源原始全文；因此本版按同一口径把结论回填到完整正文，并逐句复核限定语未在精简与回填中丢失。

修订原则：**只做这轮提出的表述精度、交叉引用与证据标注修正，不改任何结论、建议优先级、路径编号、概率区间与证据级别；不新增未经一手来源支持的事实、版本号、案例或引文。** 复审席提出的两项保留分歧不强行合并：一是安全审计席主张删除 P1/P2 的未校准数字概率，本版维持区间并保留“判断、未校准”限定，分歧记入第十三章第 3 条；二是顾问席补充的 CUE/Jsonnet 可完全规避供应链执行风险、OCI 分发可替代包生命周期治理、Porch 在电信场景不可替代等扩展论断，证据不足，本版不纳入结论，仅维持 8.1 的不同层面候选方案定位，并保留第十三章第 8 条的长期观察项。

主要改动（逐项依据见 C.28）：

1. **采用证据的唯一性收窄。** 执行摘要与 4.1 不再使用“唯一的项目级集成”这一全称断言，改为“本次检索仅见/本报告单列”，与“未取得不等于不存在”的证据口径一致。
2. **零接触的“审批”改为“审批流转”。** 执行摘要与 3.4 与 5.4“流转自动化≠决策自动化”对齐，并注明审批决策仍由组织承担。
3. **兼容承诺改称兼容面。** 9.2 改为“四项兼容面及其各自证据边界”，并明确函数契约没有独立版本承诺，避免把未取得的承诺列作承诺。
4. **痛点与替代方案就地列明。** 9.1 直接列出包派生、上游跟随、修订审批、程序化变换四类痛点；现有方案缺口补入 Jsonnet/CUE 等生成层替代，避免从“必须程序化变换”直接跳到 kpt。
5. **交叉引用与术语精确化。** “单团队控制见 9.1 阶段二前”改为按 9.1 于阶段二前就位；9.3“转包”改为“转换为 kpt 测试包”；第十章“三处对齐”点明审批、发布与部署三处。
6. **历史口径对齐。** 3.1 的 v0.39 迁移事实改标“部分核实”并注明迁移页停留 2021 年语境；第十三章第 2 条同步改为“迁移页语境之外的更早版本序列未取得”，消除与正文的矛盾。
7. **包级治理瓶颈表述统一。** 第十三章第 5 条改为“阶段二已证明包级治理瓶颈”，与 8.3、9.2 一致。
8. **恢复与权限边界显式化。** 7.2、9.3、9.4 补入“恢复后复核错误权限不会被重新应用”，9.3 停用演练补恢复顺序：先阻断错误来源与发布身份，再恢复批准产物，最后确认遗留权限清除且后续协调不再引入；第十三章第 7 条的“已写入”因此有逐句落点。
9. **验收指标的边界。** 9.3 成功标准表后补说明：100% 只证明预置测试集与约定场景内的表现，不证明所有恶意产物都会被阻断，试点须记录测试集、预期拒绝原因与覆盖边界。
10. **证据标注与交叉引用。** 1.3“不必部署 Porch”补“判断”标注；4.2 的“以 Porch 为包编排层”补支持范围说明；治理条款由“须”改为“应”并注明原文为 should；3.3 注明 Nephio 命令原文见附录 B 第 21 条；3.1 补 2026-07 博客链接；4.2 注明厂商支持旁证即附录 B 第 22 条；7.4 的“行为默认值可变”改标判断；6.1 表注补“上游包跟随属 CLI 层为判断、合并机制未取得独立说明”；2.3 补“GitHub API 为时点值、未留存 ETag 或页面快照”的限制。
11. **未改动。** 核心结论、第十二章建议、第九章路径编号、11.2 的概率区间与附录 A 的证据级别均未改变；8.2、8.3、9.1 的三项历史阻塞修复原样保留。

### C.28 第 4 轮复审意见逐条处理

下表按主题归并五席在独立意见与互评两阶段提出的意见；两阶段表决均为“通过”。处理栏中“已修复”指正文已按意见改写并注明落点，“书面保留”指维持原判断并说明理由，“已核对”指该意见不产生正文改动但已核到具体位置。

| 序号 | 来源 | 意见要点 | 性质 | 处理 | 落地位置 |
|---|---|---|---|---|---|
| 1 | 两主持、质疑席、核验席、顾问席 | “唯一项目级集成 Nephio”是超出检索范围的全称断言 | 非阻塞（多席一致） | 已修复（改为“本次检索仅见/本报告单列”） | 1.7、4.1 |
| 2 | 两主持、核验席、研究综合席 | 执行摘要与 3.4 的“审批”与 5.4“审批决策仍人工”存在读法张力 | 非阻塞 | 已修复（改“审批流转”并注明决策由组织承担） | 1.5、3.4 |
| 3 | 两主持、核验席、研究综合席 | 9.2“四项兼容承诺”与 7.4“函数契约无独立版本承诺”冲突 | 非阻塞 | 已修复（改“四项兼容面及其证据边界”） | 9.2 |
| 4 | 两主持、核验席、研究综合席、顾问席 | 9.1“四类痛点”未就地列明 | 非阻塞 | 已修复（列出包派生、上游跟随、修订审批、程序化变换） | 9.1 |
| 5 | 核验席、研究综合席 | 9.1“现有方案缺口”未比较 Jsonnet/CUE 等生成层替代 | 非阻塞 | 已修复 | 9.1 |
| 6 | 主主持、核验席 | 9.5“单团队控制见 9.1 阶段二前”指向不清 | 非阻塞 | 已修复（按 9.1 于阶段二前就位） | 9.5 |
| 7 | 主主持、核验席 | 9.3“转包”术语不明 | 非阻塞 | 已修复（转换为 kpt 测试包） | 9.3 |
| 8 | 主主持、核验席 | 第十章“三处对齐”未点明三处 | 非阻塞 | 已修复（审批、发布与部署） | 第十章 |
| 9 | 核验席、主主持 | 第十三章第 2 条“早期版本号未取得”与 3.1 的 v0.39 叙述不一致 | 非阻塞 | 已修复（3.1 标部分核实；第 2 条改为“迁移页语境之外的更早版本序列”） | 3.1、13.2 |
| 10 | 核验席、第二主持 | 第十三章第 5 条“阶段二已证明痛点”与 9.2“包级治理瓶颈”宽窄不一 | 非阻塞 | 已修复 | 13.5 |
| 11 | 核验席、质疑席 | 第十三章第 7 条称“错误权限重应用”已写入四处，正文只有原则性覆盖 | 非阻塞 | 已修复（7.2、9.3、9.4 补显式表述与恢复顺序） | 7.2、9.3、9.4、13.7 |
| 12 | 质疑席 | 9.3 的 100% 指标只证明预置样本，不能证明所有恶意产物被阻断 | 非阻塞 | 已修复（表后补测试集、预期拒绝原因与覆盖边界要求） | 9.3 |
| 13 | 质疑席 | 恢复流程未串起“错误权限再次应用”的反例 | 非阻塞 | 已修复（补固定恢复顺序与复核） | 9.3 第 7 步、9.4 |
| 14 | 两主持、核验席、研究综合席 | Nephio 安装命令的两个 flag 在证据摘要中没有单列 | 证据粒度 | 已核对：正文命令出自附录 B 第 21 条所记安装文档原文，未新增事实；3.3 补交叉引用 | 3.3、附录 B 第 21 条 |
| 15 | 主主持、核验席 | 2026-07 博客“完成 onboard”缺对应摘要条目 | 证据粒度 | 已核对：该表述见附录 B 第 5 条，3.1 补原文链接 | 3.1、附录 B 第 5 条 |
| 16 | 主主持、核验席 | “厂商支持仅一条 2023 旁证”未注来源 | 证据粒度 | 已核对：即 4.2 表内 Kubeflow GKE 文档，补附录 B 第 22 条交叉引用 | 4.2 |
| 17 | 核验席 | “行为默认值可变”缺直接条款，系由 minor 可破坏推出 | 证据粒度 | 已修复（改标判断并说明来源未单列） | 7.4 |
| 18 | 研究综合席、核验席 | “上游包跟随属 CLI 层”缺直接证据，自动克隆更新的直接证据指向 Porch | 证据缺口 | 书面保留：6.1 已按“候选实质增量”与“三方合并未取得直接说明”限定，本版补“归属为判断”；不升级为事实 | 6.1、6.2、13 第 1 条 |
| 19 | 质疑席、主主持 | 顾问席的 CUE/Jsonnet、OCI、Porch 不可替代等扩展论断证据不足 | 非阻塞 | 不纳入结论；维持 8.1 候选方案定位，保留为第十三章第 8 条观察项 | 8.1、13 第 8 条 |
| 20 | 质疑席 | 建议删除 P1/P2 未校准数字概率 | 保留分歧 | 书面保留：正文仍标“判断、未校准”，且概率未用作采纳门槛；分歧记入第十三章第 3 条 | 11.2、13 第 3 条 |
| 21 | 核验席 | “以 Porch 为包编排层”应标部分核实，补 Nephio 侧直接表述 | 证据粒度 | 已修复（补“包编排层为结合 Porch 定位的解释”） | 4.2 |
| 22 | 核验席 | “用 kpt 不必部署 Porch”缺直接引文，属架构推论 | 证据粒度 | 已修复（补“判断”标注与理由） | 1.3 |
| 23 | 核验席 | 治理条款“须”强于原文 should | 翻译精度 | 已修复（改为“应”并注明原文） | 3.1、7.3 |
| 24 | 核验席 | GitHub API 字段为时点值，宜留存 ETag 或快照 | 可复现性 | 已核对：本版不补存快照，改在方法与限制中如实说明 | 2.3 第 6 条 |
| 25 | 核验席、研究综合席 | 本轮只审精简本，原始全文未核，回填可能丢失限定语 | 范围限制 | 已核对：本版按完整正文逐句回填并复核，结论与限定语未改变；见 C.27 | 全文 |

**闭环结论：** 本轮五席在两阶段均表决“通过”，无强席位阻塞项、无普通异议需要核销。上表 25 项均为非阻塞的意见、证据粒度或范围限制：除第 18、20 项按书面保留处理外，其余已在正文落地或经原文与附录核对；第 19 项按安全审计席意见不纳入终稿结论。第 4 轮为硬上限，本版不存在未闭环的阻塞项。

### C.29 篇幅统计（v1.0-r4）

- 正文（第一至十三章，不含附录、图示代码与标点）约 1.66 万字（按汉字实计，同口径为 16628 字；上一稿同口径为 16144 字）；
- 正文表格 15 个，附录表格 12 个（较上一稿增加 C.28 的处理对照表 1 个），图示 2 个；
- 相对 v1.0-r3，正文增加约 0.05 万字（约 484 字），集中在 1.3、1.5、1.7、3.1、3.3、6.1、7.2–7.4、9.1–9.5 与第十三章；未新增外部来源、版本号、案例或引文，新增的是对既有来源的交叉引用、标注降级与表述精确化。

### C.30 v1.1 定稿说明（2026-11-10）

本版为正式版本 v1.1，以第 4 轮（标准深度、硬上限）复审后的工作稿 v1.0-r4 为基础定稿。该轮五席在独立意见与互评两阶段均表决“通过”，法定人数满足，无强席位阻塞项，也无普通异议需要核销；定稿沿用其结论、证据级别、建议优先级与第九章路径编号。

**版本升位：v1.0 → v1.1（升第二位，minor）。** 理由：核心结论、总体建议与建议优先级未改变；本次相对原报告新增一手核验来源与四级证据标注，修订第二章（方法与证据状态）、第三章（版本、Porch API 分层与 `kpt live apply` 边界）、第四章（采用统计口径）、第七章（成本与失败模式）、第九章（兼容面与验收边界）与第十一章（命题拆分），纠正发布状态与版本口径，属“结论不变，新增或修订章节、数据、来源、论证”。

定稿编辑仅限四类，均不改变任何结论与证据级别：其一，文首内部标记 v1.0-r4 改为正式版本号 v1.1，更新日期改为 2026-11-10；其二，删除正文中的内部工作稿标记，保留更新历史中各轮的内部标记以利追溯；其三，研究方式补记定稿阶段（2026-11-10）对六项关键来源的抽查，结论与 2026-11-09 核验记录一致；其四，篇幅统计随之更新。定稿未新增外部事实、版本号、案例或引文。

篇幅：正文（第一至十三章，不含附录、图示代码与标点）约 1.66 万字（按汉字实计，与 v1.0-r4 相同）；正文表格 15 个，附录表格 12 个，图示 2 个；附录 B 列直接来源 26 条。

### C.31 终审反馈处理与再定稿（2026-11-10）

首轮终审对 v1.1 定稿投“建议修订后定稿”，提出一项阻塞问题与两项非阻塞建议。本版在不改变核心结论、建议优先级与第九章路径编号的前提下逐条处理，正式版本维持 v1.1（相对原报告 v1.0 仍属第二位升位：结论不变，新增或修订章节、数据、来源与论证）。

1. **采用证据遗漏（阻塞项）。** 终审独立联网抽查发现，kpt 主仓根目录虽无 ADOPTERS/USERS 文件，但项目治理仓库的 `adopters.md` 列有 Nokia，采用级别为 “Production as part of the NCOM Evo Suite product”；该文件在 2026-10-29 的提交中已存在，早于本次核验日。经主持人 2026-11-10 重新打开核实后，本版在 4.2 增加该条目，标为“官方名单所载的厂商产品使用声明（自述，未独立核实）”，并同步改写摘要第 7 条、2.4、4.1、4.2 表后说明、4.3、4.4、11.1、附录 A 与附录 B 第 27 条。保留“未取得部署规模、维护主体、故障经验与量化收益”的限制；该材料不推翻“CLI 先行、Porch 按需”的建议。
2. **上游包跟随的直接依据（非阻塞）。** 补查官方 `kpt pkg update` 参考页，确认其载明拉取上游更新并合并到本地包、逐资源做三方合并；6.1 表与表注改为引用该文档（附录 B 第 28 条），同时保留“文档载明机制不等于已运行验证”的限定，升级前 diff、权限变化复审与冲突测试要求不变。
3. **贡献指标时点（非阻塞）。** 3.1 与附录 B 第 6 条把贡献者与贡献组织数标注为 2026-11-09 读取值，并说明 2026-11-10 复核时组织数为 93；2.3 补第 7 条覆盖限制。两数均不参与结论。

处理原则：只补一项经重新核实的一手来源与一项文档来源，不新增未经核实的公司名、版本号或引文；核心判断、少数意见与概率区间不变。附录 B 的直接来源由 26 条增至 28 条，正文表格数不变，篇幅仅有小幅增加。终审提出的全员复审标志由调度器决定，本版按修订后终稿重新提交终审。