cannbot-knowledge公共组件变更机制RFC与A/B实验流程完全讲解【免费下载链接】cannbot-knowledgecannbot算子开发知识库插件依赖的知识库本体仓给cannbot提供统一的知识底座。项目地址: https://gitcode.com/cann/cannbot-knowledgecannbot-knowledge 是 CANNBot 智能体的知识底座仓库它为 AscendC/PyPTO/TileLang/Triton 等算子开发场景提供统一、可追溯的知识卡与检索货架。当你要改动它的公共组件——比如检索 Skill、索引、治理规则或安装器——就必须走一套严格的变更机制先提交 RFC 说明方案再完成可复现的 A/B 实验最后提交关联 PR。本文把这套流程拆成可照做的步骤帮你一次理解、一次做对。一、先判断走哪条贡献路径3 类贡献 3 条路 cannbot-knowledge 的贡献入口分三类选错路径会浪费大量时间。完整定义见 CONTRIBUTING.md贡献类型流程关键动作知识建设知识 Issue → 生产验证 → PR说明缺口、生产方法和预期效果公共组件新增/优化/行为调整RFC → A/B test → PR说明必要性、方案实验证明结果缺陷修复与轻量修订直接 PR附修复依据与定向验证只有第二类需要 RFC A/B。知识错误、检索脚本 bug 等缺陷修复可直接提交 PR无需前置 Issue/RFC 或完整 A/B 实验纯排版、错别字修订同样适用简化路径。 注意如果一次修复里混入了新增能力或主动流程调整必须拆分——新能力部分另走 RFC 流程。二、公共组件边界哪些改动算“公共组件变更”RFC 流程覆盖的是多人共用的机器能力包括检索 Skill 的触发条件、流程与权限边界Query 的过滤、排序与索引Ingest/Lint 行为、治理机器规则安装器、图谱、评测或 CI 工具。这些组件的规范源分布在 governance/contracts/校验实现、governance/schemas/机器可读规则和 evals/治理、安装、检索与 CI 回归。修改它们时遵循一条总原则——扩展优先、保持兼容新增能力优先通过现有扩展点或可选配置接入保留原有默认流程和对外契约内部重构可以改原实现确需主动调整默认流程、接口或既有行为时RFC 必须单列扩展方式为何不足、受影响场景、迁移与回退方案。情形处理要求新增可选能力默认行为兼容说明接入点验证原有路径 新能力提供 A/B 证据内部重构可改实现主动改变默认行为时补齐 RFC 专项说明直接切换默认流程或删除接口未说明迁移影响即视为材料不足须补齐后再申请合入三、RFC 提交指南3 个必答板块 ✍️RFC 使用本仓 Issue 承载标题包含[RFC]。RFC 阶段可以先提交问题和方案采用 RFC 流程的组件 PR 提交前须回填已完成的实验报告。正文按三大板块组织1. 当前问题与修改必要性受影响的组件、用户与具体场景当前行为、复现输入、基线版本和证据问题的频率或影响——为什么现有能力、配置或工作流不能满足需求2. 目标与方案期望改变的行为、范围与不包含的范围设计与实现输入输出、依赖、涉及的事实源和消费者扩展接入方式替代方案取舍如适用既有行为变更的迁移与回退。3. A/B 实验计划与结果假设与验收标准、A 基线与 B 候选、数据集、执行方法、实测结果与结论。一个细节值得留意新增组件时A 基线是“当前完成同一任务的方式”如果当前根本无法完成就记录失败行为和成本避免只展示 B 的成功样例。四、A/B 实验 6 步法让结果可复现 A/B test 指旧方案与候选方案在同一任务集上的对照实验可以离线进行。实验报告至少交付 6 项材料项目必须交付的内容假设和验收标准主指标、不得退化的行为、预先设定的通过阈值及其依据A/B 版本A 的固定基线 commit、B 的候选 commit 及基线、依赖与配置只检验一个变更多个独立改动需拆分对照或补充消融样本与期望结果固定数据集版本、规模、分组和人工核对的期望结果覆盖默认路径、新增扩展路径、错误输入与边界区分调参集和验收集控制变量知识语料、输入、平台条件、资源限制保持一致索引实现改变时两组从同一语料分别构建执行与统计可运行的评测入口、重复次数、随机种子耗时测试区分冷/热缓存采用配对或交替运行完整结果与结论同时报告 A、B、差值、波动和失败样本对照预设阈值逐项判定附复现材料三条红线未执行、仅有实验计划或只报告 B 的结果都不能标为实验通过不得事后降低验收标准而不解释可复用评测用例放在 evals/本地可重建报告放在 Git 忽略的artifacts/RFC/PR 中保留结果摘要和评审者可访问的完整报告。五、检索 Skill 指标怎么选4 维口径速查 修改检索、排序、过滤这类 Skill 时按以下口径组织对照并按 RFC 目标选定主指标检索质量固定 k报告 Hitk前 k 个结果至少命中一张期望卡的查询占比和/或 MRR首张期望卡排名倒数的均值未命中记 0目标问题和既有成功问题分别报告。过滤与边界错误平台、错误技术、draft/deprecated 默认范围、无匹配结果、缺失/损坏/过期索引的处理报告违反次数。开销相同机器、语料和负载下报告查询耗时 p50/p95索引变更补构建时间和体积涉及 Agent 调用补 token 成本。下游效果影响证据召回、排序、查询改写的变更须补代表性端到端算子生成对照——固定模型、提示词、语料、任务与生成预算只替换待评估的检索模块报告编译通过率、数值正确率等失败与超时保留在分母内。记住一条边界检索指标提升不能直接推导任务成功。仅索引、缓存等工程优化若能证明检索结果和行为一致可只做检索回归与性能对照无法证明时补端到端验证。其他组件按职责选指标Lint 规则比较同一批合法/非法输入的接受与拒绝行为安装器比较成功率、幂等性和失败时的文件保护Ingest 比较有效产物比例、内容保真和写入边界。六、PR 提交与 committer 检视最后的门禁 实现完成后按 5 步交付关联 RFC按方案修改规范源涉及治理规则时先改唯一机器事实源再同步消费者更新受影响的文档和测试验证结构、触发条件、原有路径、新增能力、错误路径和权限边界完成 A/B test 并回填 RFC记录当天变更日志见 logs/提交关联 RFC 的 PR由 committer 检视后合入。PR 材料要让评审者沿“问题 → 方案 → 产物 → 证据”核对RFC 方案、A/B 版本、实验报告链接、关键指标与验收结论以及默认流程/接口/行为是否变化。提交前统一运行质量门禁bash check.shcommitter 重点核对RFC 是否解释必要性与方案取舍、主动行为调整是否说明迁移与回退、原有路径与新增能力是否均有验证、A/B 是否达到预设标准。自动检查通过只证明所覆盖的检查通过不能代替内容与效果检视。七、快速自查清单 ✅这次改动属于公共组件变更而不是知识建设或缺陷修复RFC 说明了问题、必要性和“扩展为何不足”实验阈值是实验前设定的不是事后调整的A、B 两组控制变量一致失败样本也保留了原有默认路径和新增能力都有验证证据当天logs/记录了实质变更bash check.sh通过更多背景可阅读README 贡献与检查、设计原则、Agent 工作约定 和 OKF 规范说明。【免费下载链接】cannbot-knowledgecannbot算子开发知识库插件依赖的知识库本体仓给cannbot提供统一的知识底座。项目地址: https://gitcode.com/cann/cannbot-knowledge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考