A4--李伟山--Agent 编排框架选型 和 AI 工程的 CICD：从模型发版到 Skill 灰度的完整流水线.pdf

1、AI AI 工程的工程的 CI/CDCI/CD：从模型发版到从模型发版到 Skill Skill 灰度的完整流水线灰度的完整流水线李伟山 科大讯飞，高级AI架构师0 1AI 发版为何看起来简单做起来要命0 2 八类变更源：代码只是其中之一0 3CI 阶段：把能合并的门设好0 4 灰度策略：不是百分比那么简单0 5模型版本：不在你控制下的变量0 6Prompt 与 Skill 的发版0 7MCP Server 与数据变更0 8回滚、反模式与核心总结AI AI 发版发版为何看起来简为何看起来简单做起来要命单做起来要命传统传统 CI/CD CI/CD：一个已解决的问题：一个已解决的问题传统软件的持续

2、交付流程提交代码单元测试构建镜像推到Registry灰度部署监控告警全量上线工具链成熟：Jenkins/GitHub Actions/ArgoCD/Spinnaker只要按规矩走，传统 CI/CD 是个已解决的问题然后你开始做然后你开始做 AI AI 系统系统.AI AI 系统发版的真实困境（司法办案场景）系统发版的真实困境（司法办案场景）改了量刑建议 prompt 一句话，CI 全绿，上线后判决书格式全乱升级大模型版本，回归测试全过，三天后法官投诉法律引用不准确新增证据链分析 Skill，案情摘要 Skill 的召回率突然下降灰度 5%法官用户，负反馈率是普通用户 3 倍，但 metric

3、看起来正常想回滚，发现 prompt+模型版本混在同一次发版，无法单独回滚AI AI 系统的发版，根本不是传统软件的发版系统的发版，根本不是传统软件的发版AI AI 系统的系统的 9 9 大变更变量大变更变量模型版本模型版本厂商一升行为就变模型参数模型参数temp/top_p/max_tokensSystem PromptSystem Prompt一句话措辞影响巨大Tools Tools 定义定义schema 一变行为就变SkillsSkills加载/版本/描述/脚本MCP ServersMCP Servers版本/能力/可用性编排框架编排框架minor 升级都可能出问题评测集评测集基线变了判

4、断也变数据数据(RAG)(RAG)知识库/向量索引每一件都是变更源，每一件都可能让每一件都是变更源，每一件都可能让 AI AI 系统行为漂移系统行为漂移传统传统 CI/CD CI/CD 的前提在的前提在 AI AI 系统下不成立系统下不成立传统软件传统软件变更源=代码代码是确定的：写什么跑什么代码改动=行为改动单元测试能覆盖AI AI 系统系统变更源=N 件事（9类）LLM 天然不确定影响无法事先穷举单元测试远远不够AI AI 工程需要重新设计的工程需要重新设计的 CI/CD-CI/CD-保留传统工程严谨保留传统工程严谨+AI +AI 特有能力特有能力九九类变更源类变更源先承认代码只先承认代码

5、只是其中之一是其中之一变更源特性差异对比变更源特性差异对比变更源变更源控制方控制方触发频率触发频率影响范围影响范围可回滚可回滚?模型版本厂商+你厂商决定全局锁版本可以模型参数你主动全局/场景是System Prompt你高频全局是Tools 定义你中频涉及该Tool是Skills你+团队高频涉及该Skill版本化后可以MCP Servers你+第三方中频所有调用方锁版本可以业务代码你高频取决于变更是数据你+上游高频取决于变更难测试集你低频全局不可回滚三条核心观察三条核心观察1 1模型版本不完全在你控制下模型版本不完全在你控制下这是 AI 系统最大的外生变量-厂商升级不通知你的行为就变了2 2数

6、据变更最难回滚数据变更最难回滚RAG 索引一旦覆盖旧版本可能就丢了；评测集变了baseline也变了3 3不同变更源的发版机制必须不同不同变更源的发版机制必须不同一刀切的 CI/CD 处理不了 9 种不同性质的变更反模式：所有变更混在一次发版反模式：所有变更混在一次发版git commit-m 升级模型+重写prompt+加3个Skill+升级框架上线后用户投诉上线后用户投诉-你完全不知道是哪个变更引发的你完全不知道是哪个变更引发的司法办案场景：司法办案场景：同时升级了量刑计算模型+修改了证据分析prompt+新增法规检索Skill上线后法官反馈量刑建议偏差大-模型?prompt?还是新Ski