版本、发布与监控

第 6 课 · 共 6 课 约 9 分钟

版本号怎样区分兼容与破坏；指标与运行历史；谁能跑；AIDC 用语义版本、应用版本、运行记录和用量。

本课目标

读完这一课，你将能够

  • 用 X.Y.Z 三段版本号区分兼容的改动和破坏性的改动
  • 说出函数的指标与运行历史看什么，以及谁能运行、看到什么
  • 说出 AIDC 里对应的语义版本、应用版本、运行记录与用量，以及怎样用工作流做告警

版本：源码与签名发布后不可改

函数版本写成 X.Y.Z：主版本、次版本、补丁。同一版本的签名与源码不能改，但可以更新超时或内存配置。Automate 的函数效果指定 version，也可以设 autoUpgrade。智能体只能发预发布版本，例如 1.1.0-rc.1。

兼容的改动破坏性的改动（升主版本）
输入加一个可选输入加必填输入、删输入（哪怕可选）、调换输入顺序
输出改进性能，行为不变输出类型从整数改成字符串
函数本身修一个不改变预期行为的 bug删除函数

主版本 0 是初始开发期，随时可能变，调用方不该当它稳定。发布前平台会做兼容检查，但检查并不完整：内部实现上的破坏它查不到，所以不能因为检查通过就发补丁。如果不小心把破坏性改动当次版本发了，不能改已发的版本，要恢复兼容，再发一个新的次版本。示例工厂的 supplierScore 可以这样演进：

  1. 1.0.0

    输入一个供应商，输出一个分数。

  2. 1.1.0

    加一个可选输入 windowDays：兼容，升次版本。

  3. 2.0.0

    输出从一个数变成 { score, reasons }：破坏性，升主版本。

监控与权限：看得见，才管得住

标准模型给两样东西。指标：近乎实时地显示最近 30 天每种函数的成功与失败次数，以及 P95 时长（95% 的调用不超过的时长）。运行历史：最近 7 天每一次执行。失败分成几类，比如运行时错误、资源超限、面向用户的错误、输入无效、输出无效、加载数据不被允许、改了没声明的对象类型，一眼能看出是代码、调用方还是资源的问题。

30 天指标的时间范围：成功、失败次数与 P95 时长
7 天运行历史的保留范围

监控规则可以对「P95 时长超过阈值」和「窗口内失败次数超过阈值」告警，还能只看面向用户的失败，或只看非面向用户的失败——后者多半是基础设施的问题。

权限有四点要记住：

  • 运行函数需要对它有查看权限，看指标同理；
  • 函数读对象时用的是调用者的权限，同一个函数对不同的人可能返回不同的结果；
  • 函数驱动的 Action 是特例：使用者不需要能读那个函数，由 Action 自己的权限管；
  • 行、列级的读限制只管读，不延伸到函数的输出。

在 AIDC 里：版本号、运行记录、用量

AIDC 已支持 Function 的语义化版本发布、列表和隔离执行。用 aidc semantic functions publish 发布，用 aidc semantic functions list 查看。新文档没有说明专用函数指标页和监控规则。其他版本与运行记录看下面三处：

SEMANTIC

语义版本

aidc semantic publish --notes "…" 发一个语义版本 vN，只增，定义没变不占号。破坏性改动（删类型、删属性、改类型、改主键、Action 删参数或新增必填参数）在定义时返回，发布时记 changeKind: breaking。

APP

应用版本

工作流就是应用：aidc app deploy 到 test 通道（版本号是清单的 version，内容变了就要升），aidc app publish 到正式，aidc app rollback order-risk --version 1.1.0 回退。提示词和 models 都在清单里，改一句提示词、换一个模型，都是一个新版本。

RUNS

运行记录

每次运行留下每一步的状态、耗时、输出和 token，保留 180 天。超过 5 分钟没有进展的运行标为「中断」，可以重跑。看 aidc semantic automate runs、status、watch。

改一句提示词之后的一轮发布，大致是这样：先部署到 test 通道，用评测集预演，没有变差再发布，变差了就回退。

aidc app deploy ./order-risk --notes "Clarify the at_risk rule in the prompt"
aidc semantic automate run order-risk --param order_no=SO-2001 --preview --channel test
aidc app publish order-risk --version 1.2.0
aidc app rollback order-risk --version 1.1.0    # only if the new version is worse

用量看 aidc app usage order-risk：本月计算分钟（缺省 2000 / 月，用完之后数据变化和定时都不再开跑，下月恢复）、定时和今天的通知。模型花了多少，看 aidc semantic usage summary --app order-risk。开了 actionLog 的 Action 每次成功提交还会写一个日志对象（例如 log.adjust-seats），谁在什么时候用什么参数改了什么，一查便知。

告警靠工作流自己。notify 步骤的收件人写死在清单里，必须是本公司账号；dedupe 与 cooldown（缺省 6 小时）防止告警风暴，每个应用每天最多 20 封（limits.notificationsPerDay）。「ERP 数据两小时没来」这类看门狗，用定时触发加 hoursSince 判断。

谁能运行，由 trigger.manual.roles 决定。别的应用调用它的能力时，以「提供方应用 × 成员角色」执行，只有发布到正式通道的版本才对外可见。

模型参与的逻辑变好，走的是同一条路：证据、提案、新版本（aidc evolve evidence order-risk），改前改后用同一份评测集对比。

要点

  • 版本号 X.Y.Z：加可选输入是兼容的；加必填输入、删输入、改输出类型、删函数是破坏性的，要升主版本。
  • 同一版本的源码与签名不能改，超时或内存配置可以更新。误发破坏性改动，要恢复兼容，再发新版本。
  • 监控看指标（30 天成功、失败、P95）和运行历史（7 天）；函数读对象用的是调用者的权限。
  • AIDC 今天用语义版本、应用版本、180 天的运行记录、计算分钟用量和 notify 告警对应这些事。

练一练

给「供应商评分」定版本，再设计一条告警

版本号是给调用方看的承诺，告警是给运维看的承诺。

下面五个改动各升哪一段：加可选输入 windowDays；输出类型从数变成结构；删除一个可选输入；修一个不改变行为的 bug；调换两个输入的顺序。

小测

选一个答案，马上看解析。

Q1给 supplierScore 加一个可选输入 windowDays，版本从 1.0.0 该升到？

Q2你把一个破坏性改动当作 1.1.0 发布了，怎么补救？

Q3在 AIDC 里，你改了工作流 AI 分析步骤的一句提示词，应该怎么做？

延伸阅读