企业 AI 技能一旦参与报价、审批、写单、知识回答或客户沟通，就不再是个人提示词。合格发布流程应保证：改动可比较、行为可测试、批准可追溯、运行版本可识别、出问题可回退。
六个状态比“保存并生效”可靠
| 状态 | 允许做什么 | 关键门禁 |
|---|---|---|
| 草稿 | 编辑说明、规则与资源 | 不影响生产用户 |
| 待测试 | 固定候选版本 | 依赖和测试集齐全 |
| 测试中 | 跑正常、异常、无权用例 | 不写生产业务数据 |
| 待审批 | 展示差异与风险 | Owner 确认业务变化 |
| 已发布 | 新任务按绑定范围使用 | 版本不可原地修改 |
| 已停用 | 禁止新任务使用 | 历史回放仍可读取 |
版本号只是标签，真正要固定的是技能内容、知识依赖、连接器能力、模型要求、权限范围和测试结果。否则同一个版本名在不同时间可能代表不同的行为。
发布前看“行为差异”，不只看文本差异
把一句“缺资料时继续尝试”改成“缺资料时转人工”，文本变化很小，业务影响却很大。审批页应说明：哪些任务会受影响；自动动作是否增加；读取或写入范围是否扩大；人审门槛是否变化；成本和时延可能怎样变化。
至少保留三类测试：正常用例验证主链，异常用例验证缺字段、冲突、超时和重复触发，无权用例验证越权读取与动作被拦截。涉及写入时还要验证幂等和写后回读。
新任务切版本，运行中任务保持稳定
长任务可能持续数小时甚至数天。若中途自动切换技能、知识或模型，恢复后就难以解释前后判断。更稳妥的规则是任务启动时固定技能版本；紧急安全停用可以阻断后续高风险动作，但要明确记录终止原因。
需要兼容新旧数据结构时，应先让新版本同时读懂旧数据，再逐步迁移，不要一次发布同时改规则、连接器和历史数据。变量越多，回归失败后越难定位。
回滚也要验证业务状态
回滚只影响后续执行，不能自动撤销已经发出的消息或写入的单据。先暂停高风险动作，列出受影响任务，再切回已验证版本，最后回读业务系统确认是否需要人工修复。
关于生产变更的完整纪律可读Agent 上线后怎么改规则；关于技能、连接器和知识库的分工见四类能力有什么区别。需要建立可持续的技能生产与运营体系，可继续了解开沿 Agent。
依赖关系决定发布风险
一个技能可能被多个 Agent、部门和定时任务复用。发布页应列出调用者、知识源、连接器、模型要求和下游写入对象。公共技能的一个字段变化，影响可能远大于新建一个专用技能；没有依赖地图时，宁可创建候选版本并限定范围，也不要覆盖原版本。
技能引用的知识和连接器也应固定兼容条件。知识更新不必每次重发技能，但若字段、规则或权限语义变化，就要触发回归。连接器新增能力时，不能因为技能声明需要就自动获得权限，仍要走独立授权。
发布审批按风险分层
只调整内部输出格式，可由运营人员复核；改变业务判断或新增读取范围，需要业务 Owner 确认；新增写入、对外发送、金额或权限动作，应由对应有权人审批。审批人看到的是行为差异和测试证据，不是几十页原始文件。
紧急修复也不能原地改生产版本。可以走加急通道缩短等待，但仍要生成新版本、记录原因、跑最小安全集，并在发布后补齐完整回归。
观察窗口结束才算发布完成
版本切换后持续观察真实任务量、异常分布、人审驳回、单位成功成本和旧版对照。若只在测试环境成功一次就宣布完成，生产里的数据缺失、权限差异和外部系统波动都没有被验证。发布结论要带实际样本范围，不把“没有收到投诉”当作质量证据。
