04 · 服务

AI 发布管理

面向 AI 智能体的 ChaRM:每一次变更都有版本、经过测试、获得审批,并且可以回滚。 提示词、模型、工具或数据一变,智能体的行为就会改变。我们为您的智能体引入 SAP 变更与发布管理的纪律:清单、版本、固定的评测关口、风险评级、审批,以及一条退路。

问题所在

智能体很少在第一天就出问题。它们往往在第三次更换模型、修改提示词或引入一个没人测试过的新工具之后出问题,而那时没有人说得清运行的是哪个版本、谁批准的、怎样退回去。在运转良好的 SAP 系统环境中,没有传输、测试和审批,任何东西都进不了生产。智能体会采取行动,理应遵循同样的纪律。

我们交付什么

  • 每个智能体、模型、技能和 MCP 服务器的清单:有登记、有负责人、有版本
  • 固定的评测关口,每次变更都必须通过:确定性测试用例、提示词注入测试与工具测试,按严重程度加权;关键类别中只要出现一项回归,即阻止发布
  • 每个智能体的风险评级,包括欧盟《人工智能法案》分类,以及职工委员会可以审阅的文档
  • 每次变更都有一份发布档案:变更内容、测试证据、决策、具名审批人与回滚目标版本
  • 只允许追加的审计日志:每条记录都包含上一条记录的哈希值,较早的记录一旦被修改或删除,验证时即可发现
  • 需要由 LLM 为输出评分时,使用经过校准的 LLM 评判器:其结论与人工评分足够一致后才予采纳
  • 回滚:一个可随时退回的已验证版本,并在您需要之前就测试好
  • 运营:按会话的链路追踪、单次操作成本、漂移监控与发布日历,基于您自己的 Git 发布流水线,或面向 SAP Cloud ALM 与 AI Agent Hub 设计
  • 执行轨迹核查:委派给智能体的任务,只有记录的工具调用显示必需步骤已成功执行,才算完成,而不是凭智能体自己的汇报

如何推进

审计 → 构建 → 长期服务:每项服务都走同一条生产线,并针对本服务量身调整。每个阶段结束后,由您决定是否继续。

  1. 01

    审计

    盘点当前运行的一切:智能体、模型、提示词、工具、负责人,并对照发布纪律做差距检查:哪些有版本、经过测试、获得审批、可以回滚。

  2. 02

    构建

    建立发布流程本身:用您的真实案例搭建评测关口,配合风险评级、审批流程、审计记录与回滚,并接入您的流水线。

  3. 03

    长期服务

    我们与您一起运营这道关口:每一次更换模型、修改提示词都要通过它,测试集也随每一次事件不断扩充。

相关行业

以下是本服务与我们深度熟悉的行业的交汇点。

常见问题

如何知道 LLM 评判器的判断是对的?

先测量,再信任。需要由 LLM 为输出评分时,我们将其判断与人工对同一批用例的评分进行对比,用 Cohen’s kappa 系数衡量一致性,并扣除偶然一致的影响。系数达到 0.7 及以上,才采纳其结论。我们正在用这种方法校准自己的评判器,目前尚无结果可报告。我们的 43 个确定性关口用例不使用 LLM 评判器。

“AI 发布管理”在实践中意味着什么?

对智能体的每一次变更,无论是提示词、模型、工具还是数据源,都要经过版本管理、固定的评测基线、风险评级和审批,并保留一个可回滚的已验证版本。就像 ChaRM,只不过对象是智能体。

为什么更换模型也算一次发布?

因为同一个提示词在不同模型上的表现并不相同。在我们自己的关口中,一个受测模型曾声称要重启服务器,而它根本没有执行重启的工具。固定的测试集能在投产前发现这类问题,而不是在投产之后。

这需要 SAP 吗?

不需要。这套纪律来自 SAP 变更与发布管理,但流程可以运行在任何技术栈上:基于您自己的 Git 发布流水线,或与您现有的变更管理并行。

这对欧盟《人工智能法案》有帮助吗?

它打下了基础:一份清单、每个智能体的风险分类、有记录的测试与审批,以及审计记录。某个用例是否属于高风险需逐案评估;针对高风险用途的义务计划自 2027 年 12 月 2 日起适用。

用 30 分钟把事情谈清楚。

带上一个流程和您的技术栈。我们会做好准备,坦诚告诉您智能体是否值得投入,以及哪项服务是合适的起点。