桌面应用RPA计算机视觉【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon点击查看免费下载本文以 OneDragon 项目绝区零全自动一条龙的通知配置模块为主线系统讲解NotifyConfig的二维配置语义应用通知 × 节点通知、operation_notify.py的运行时读取与发送逻辑、通知池的合并机制以及旧版整数配置的自动迁移实现。读完本文你将能够完全理解该框架中通知系统从 YAML 配置到多端推送渠道的完整工作链路并掌握为应用/节点接入通知能力的正确姿势。一、通知配置模块概览通知配置由 NotifyConfig 维护它是一个继承自YamlConfig的配置类对应的配置文件名为notify以 YAML 形式落盘。运行时由 operation_notify.py 根据当前运行的应用Application实时读取并执行推送。整个通知体系可以拆成三层来看配置层NotifyConfig负责读取、写入、迁移通知配置逻辑层operation_notify.py负责在应用生命周期和节点执行的关键时机组装消息、决定是否推送推送层PushService负责把消息实际发送到用户配置的各类推送渠道。其中配置层与逻辑层是本文的核心推送层作为链路终点简要带出。二、通知语义的二维配置模型框架把通知语义拆成两个互相平行、互不依赖的维度这一点是理解整个通知系统的钥匙维度控制内容取值对应枚举应用通知lifecycle应用生命周期消息开始 / 结束关闭、仅结束、开始和结束NotifyLifecycleMode节点通知detail运行过程中的节点细节消息关闭、仅失败、逐条、合并NotifyDetailMode两个维度在源码中分别由两个枚举承载见 notify_config.pyNotifyLifecycleModeoff关闭不发送开始和结束通知、finish_only仅结束应用完成后发送通知、start_and_finish开始和结束应用开始和完成时发送通知NotifyDetailModeoff关闭不发送节点细节通知、error_only仅失败只在节点失败时立即通知、all逐条每个标记节点完成后立即通知、merge合并应用结束时合并发送节点细节。注意枚举的内部value如off、finish_only才是真正落盘到 YAML 中的字符串值label如关闭仅结束是界面展示文本desc是配置说明。因此 YAML 中applications.app_id.lifecycle存的是start_and_finish这样的字符串而不是中文。2.1 merge_error_immediate_notify合并模式的补充开关merge_error_immediate_notify是仅在节点通知为合并merge时才生效的附加开关当节点通知选择合并模式时失败节点会额外立即推送一条通知而不是等到应用结束再随合并消息一起发出。从 notify_config.py 的实现看它默认取旧字段notify_on_error的值默认True保证旧版用户迁移后行为一致。对应到运行逻辑operation_notify.pyshould_send_fail_notify current_fail and ( detail_mode NotifyDetailMode.ERROR_ONLY.value.value or ( detail_mode NotifyDetailMode.MERGE.value.value and operation.ctx.notify_config.merge_error_immediate_notify ) )可见仅失败模式下失败节点本来就会立即通知而在合并模式下只有打开了merge_error_immediate_notify才会对失败节点额外即时推送。2.2 消息内容模板应用生命周期消息格式operation_notify.py任务「{应用名}」运行{成功/失败/开始}节点细节消息格式operation_notify.py任务「{应用名}」节点「{节点名}」 运行「{成功/失败}」 状态「{status}」可选仅 detailTrue 时追加 {自定义消息}可选三、配置结构与读写 APINotifyConfig的核心配置结构如下YAML 简化示意title: 一条龙运行通知 # 通知标题可自定义 enable_notify: true # 通知总开关 merge_error_immediate_notify: true # 合并模式下失败节点立即通知 notify_schema_version: 2 # 迁移后写入的 schema 版本 applications: app_id: lifecycle: start_and_finish # 应用通知off / finish_only / start_and_finish detail: all # 节点通知off / error_only / all / merge # 以下为旧版迁移来源字段迁移后保留 # enable_before_notify: true # notify_on_error: true # app_id: 0~33.1 关键 APINotifyConfig提供的读写接口notify_config.pyAPI作用enable_notify通知总开关默认True属性读写直接对应 YAML 中enable_notifytitle通知标题默认一条龙运行通知merge_error_immediate_notify合并模式失败立即通知开关application_notify_settings读取整个applications字典get_app_notify_modes(app_id)获取某应用二维模式(lifecycle, detail)无新结构时回退旧版映射set_app_notify_modes(app_id, lifecycle, detail)写入某应用二维模式任一参数为None时保留当前值get/set_app_lifecycle_mode、get/set_app_detail_mode单独读写某一维度set_app_notify_modes在写入时会把现有applications中所有应用设置拷贝一份再覆盖目标应用避免丢失其他应用的配置notify_config.py。值得注意的默认值当某应用在applications中不存在对应设置时get_app_notify_modes会回退到_get_legacy_modes(app_id)即按旧版整数配置映射若连旧字段也不存在则lifecycle默认为start_and_finish、detail默认为all。3.2 多开instance_idx隔离NotifyConfig.__init__(self, instance_idx, app_map)接收两个参数instance_idx多开实例索引传给YamlConfig后用于区分不同实例的配置文件app_map: dict[str, str]应用 ID 到应用名的映射迁移旧配置时需要遍历所有已注册应用。app_map由上层OneDragonContext注入GUI 界面也正是遍历notify_config.app_map为每个应用生成一张配置卡片。四、运行时读取链路operation_notify.pyoperation_notify.py 是通知的运行时大脑所有通知最终都从这里发出。它暴露了两个核心入口send_application_notify(app, status)应用生命周期通知send_node_notify(operation, round_result, current_node, next_node)节点细节通知由 operation.py 在每一轮节点执行结束后自动调用。4.1 应用生命周期通知send_application_notify的参数status语义True 成功、False 失败、None 开始。它的决策流程operation_notify.py读取该应用的生命周期模式与节点模式若生命周期为off且节点模式不是merge直接返回两者都关才不发若status is None开始消息仅当生命周期为start_and_finish时直接推送结束消息成功/失败的发送策略分三种节点模式为 merge 且通知池非空调用push_merged_async合并发送若生命周期未关闭把结束消息放在合并列表开头生命周期未关闭单条推送并附带通知池中最后一张截图pool.last_image否则不发送。4.2 节点通知装饰器与触发时机节点通知通过node_notify装饰器以元数据标注的方式声明operation_notify.py执行框架在节点结束钩子中读取func.operation_notify_annotation并调用send_node_notify。node_notify的参数参数含义when触发时机NotifyTiming.PREVIOUS_DONE上一节点完成后、CURRENT_DONE当前节点完成后无论成败、CURRENT_SUCCESS仅成功后、CURRENT_FAIL仅失败后custom_message自定义附加消息send_image是否附带节点执行时的last_screenshot截图默认Truedetail是否在消息中追加节点返回状态默认False同一个函数可以被多次装饰以实现多种时机通知例如成功时通知一次 失败时通知一次。仓库中已有大量真实用法可作参考例如charge_plan_app.py 使用node_notify(whenNotifyTiming.CURRENT_FAIL)在充能计划失败时通知另一节点同文件第 372 行用CURRENT_DONE, detailTrue展示状态详情city_fund_app.py、coffee_app.py、email_app.py 等在成功节点上使用CURRENT_SUCCESS迷失之地玩法中大量使用CURRENT_DONE并配合send_imageFalse、detailTrue控制消息粒度见 lost_void_app.py。send_node_notify的处理逻辑operation_notify.py通知总开关关闭或当前节点为空时直接返回按应用读取detail模式off完全不收集error_only仅失败节点收集all/merge全部收集汇总当前节点与下一节点PREVIOUS_DONE类上所有装饰器标注过滤掉不符合当前成败状态的通知组装消息后先pool.add()入池再根据模式决定是否立即推送all模式逐条立即推error_only与merge merge_error_immediate_notify 仅失败节点立即推。4.3 通知池合并模式的数据基础合并模式依赖 notify_pool.py 中的NotifyPool。它在ApplicationRunContext中创建每次应用开始运行时清空重用默认上限条目 200 条、图片 10 张超出条目上限时丢弃最旧条目超出图片上限时移除最旧图片文本始终保留仅图片被置空以控制内存last_image属性从池尾向前遍历取最后一张图供应用结束通知附带截图。五、GUI 交互推入式设置页与 Flyout 弹窗通知配置的 GUI 有两处入口交互方式不同1. 一条龙运行页中的通知设置推入式滚动设置界面由 NotifySettingInterface 实现通过 app_setting_manager.py 的show_notify_setting以pivot_navi.push_setting_interface推入。不再使用弹窗编辑配置变更在控件值变化时立即写入NotifyConfig无需点确定。界面包含通用分组合并模式失败节点立即通知开关SwitchSettingCard直接绑定merge_error_immediate_notify应用通知分组按app_map为每个应用生成AppNotifySettingCard每行两张卡片横向排列卡片上提供生命周期与节点通知两个下拉框app_notify_setting_interface.py。2. 应用卡片更多菜单中的通知设置Flyout由 AppNotifySettingFlyout 实现入口是应用卡片更多菜单中的通知设置按钮见 app_run_card.py通过show_app_notify_settingapp_setting_manager.py以TeachingTip弹出。它只编辑当前应用的应用通知和节点通知两个维度作用域更聚焦。六、旧版配置迁移6.1 旧版整数等级语义main 分支旧版配置使用应用 ID 对应的整数值旧值含义0关闭1仅应用2全部逐条3全部合并旧版同时还有两个布尔字段enable_before_notify是否发送开始通知与notify_on_error失败时是否通知。这些语义在 notify_config.py 中以NotifyLevel枚举保留注释明确说明仅用于迁移已有配置。6.2 迁移触发与映射规则启动构造NotifyConfig时若 YAML 中没有applications新结构会立即执行_migrate_legacy_config()完成迁移并落盘notify_config.py遍历app_map中每个应用调用_legacy_level_to_modes转换写入applications、merge_error_immediate_notify取旧notify_on_error默认True并写入notify_schema_version: 2。逐项映射规则_legacy_level_to_modesnotify_config.py旧等级新 lifecycle新 detail0关闭offoff1仅应用旧enable_before_notify为真 →start_and_finish否则 →finish_only旧notify_on_error为真 →error_only否则 →off2全部/逐条同 1 的 lifecycle 规则all3全部/合并同 1 的 lifecycle 规则merge可见迁移并非机械的一对一替换enable_before_notify决定开始通知是否保留notify_on_error决定仅失败级别下失败节点是否即时通知。6.3 迁移后的只读范围迁移完成后旧字段仍保留在文件中作为迁移来源不删除便于追溯与再次迁移但运行时只读取applications.app_id.lifecycle和applications.app_id.detail。框架内不再暴露旧版整数通知等级 API——NotifyLevel仅是迁移内部工具新代码一律通过NotifyLifecycleMode/NotifyDetailMode的字符串值操作。七、推送链路PushService 与多渠道发送配置与逻辑层最终都汇入 push_service.py 的PushService完成实际投递使用max_workers1的单线程线程池串行推送避免多应用并发时消息乱序init_push_channels内置了 SMTP、Webhook、钉钉、飞书、企业微信、OneBot、Bark、Server 酱、PushPlus、Discord、Telegram、Ntfy、Gotify、WxPusher 等二十余种渠道push_service.py 第 72-95 行push()在channel_id未指定时遍历所有通过配置校验的渠道发送push_config.send_image为假时统一剥掉截图应用生命周期使用push_async单条推送合并模式使用push_merged_async一次送出多条push_service.py。八、附一条龙运行汇总通知NotifyApp作为通知主题的延伸仓库在 notify_app.py 中提供了一个非玩法的通知应用APP_IDnotifyAPP_NAME通知优先级 3000见 notify_const.py它在一轮一条龙运行结束后汇总各应用的运行记录格式化出一条龙运行完成消息含成功指令列表、失败指令列表以及充能计划应用估算的当前体力通过PushService.push推送给用户。其运行记录 notify_run_record.py 每次运行都会重置保证每次都执行汇总推送。九、小结OneDragon 的通知系统通过应用通知 × 节点通知的二维正交配置把生命周期消息与节点细节消息彻底解耦配合merge_error_immediate_notify、通知池合并、装饰器标注等机制实现了从逐条即时到结束合并再到仅失败提醒的完整通知粒度谱系同时通过构造时的自动迁移让旧版整数配置0~3无缝升级到新二维结构。开发者接入通知时只需记住两条路径应用级通知走send_application_notify节点级通知用node_notify装饰器标注具体推不推、怎么推全部由operation_notify.py按配置裁决。赞分享桌面应用RPA计算机视觉【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon点击查看免费下载相关推荐ZenlessZoneZero-OneDragon绝区零一条龙AI 编码协作入口与开发规范解析ZenlessZoneZero OneDragon绝区零一条龙AI 编码协作入口与开发规范解析 本文以仓库根目录的 AGENTS.md https://li桌面应用RPA计算机视觉绝区零一条龙ZenlessZoneZero-OneDragon迷失之地检测模型来源、消费链路与发布规范深度解析绝区零一条龙ZenlessZoneZero OneDragon迷失之地检测模型来源、消费链路与发布规范深度解析 导读 迷失之地Lost Void是《绝桌面应用RPA计算机视觉DS2API Ollama兼容接口指南3个接口让Ollama客户端直连DeepSeek模型DS2API Ollama兼容接口指南3个接口让Ollama客户端直连DeepSeek模型 DS2API 是一款 DeepSeek 兼容中间件接口通过 Ol桌面应用RPA计算机视觉上一篇还在一首一首转NCMncmdumpGUI免费一键搞定NCM格式转换下一篇MPh 实战指南10 行 Python 让 COMSOL 自动批量跑仿真创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
绝区零一条龙（ZenlessZoneZero-OneDragon）通知配置体系全解析：二维配置语义、运行时读取链路与旧版迁移实现
桌面应用RPA计算机视觉【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon点击查看免费下载本文以 OneDragon 项目绝区零全自动一条龙的通知配置模块为主线系统讲解NotifyConfig的二维配置语义应用通知 × 节点通知、operation_notify.py的运行时读取与发送逻辑、通知池的合并机制以及旧版整数配置的自动迁移实现。读完本文你将能够完全理解该框架中通知系统从 YAML 配置到多端推送渠道的完整工作链路并掌握为应用/节点接入通知能力的正确姿势。一、通知配置模块概览通知配置由 NotifyConfig 维护它是一个继承自YamlConfig的配置类对应的配置文件名为notify以 YAML 形式落盘。运行时由 operation_notify.py 根据当前运行的应用Application实时读取并执行推送。整个通知体系可以拆成三层来看配置层NotifyConfig负责读取、写入、迁移通知配置逻辑层operation_notify.py负责在应用生命周期和节点执行的关键时机组装消息、决定是否推送推送层PushService负责把消息实际发送到用户配置的各类推送渠道。其中配置层与逻辑层是本文的核心推送层作为链路终点简要带出。二、通知语义的二维配置模型框架把通知语义拆成两个互相平行、互不依赖的维度这一点是理解整个通知系统的钥匙维度控制内容取值对应枚举应用通知lifecycle应用生命周期消息开始 / 结束关闭、仅结束、开始和结束NotifyLifecycleMode节点通知detail运行过程中的节点细节消息关闭、仅失败、逐条、合并NotifyDetailMode两个维度在源码中分别由两个枚举承载见 notify_config.pyNotifyLifecycleModeoff关闭不发送开始和结束通知、finish_only仅结束应用完成后发送通知、start_and_finish开始和结束应用开始和完成时发送通知NotifyDetailModeoff关闭不发送节点细节通知、error_only仅失败只在节点失败时立即通知、all逐条每个标记节点完成后立即通知、merge合并应用结束时合并发送节点细节。注意枚举的内部value如off、finish_only才是真正落盘到 YAML 中的字符串值label如关闭仅结束是界面展示文本desc是配置说明。因此 YAML 中applications.app_id.lifecycle存的是start_and_finish这样的字符串而不是中文。2.1 merge_error_immediate_notify合并模式的补充开关merge_error_immediate_notify是仅在节点通知为合并merge时才生效的附加开关当节点通知选择合并模式时失败节点会额外立即推送一条通知而不是等到应用结束再随合并消息一起发出。从 notify_config.py 的实现看它默认取旧字段notify_on_error的值默认True保证旧版用户迁移后行为一致。对应到运行逻辑operation_notify.pyshould_send_fail_notify current_fail and ( detail_mode NotifyDetailMode.ERROR_ONLY.value.value or ( detail_mode NotifyDetailMode.MERGE.value.value and operation.ctx.notify_config.merge_error_immediate_notify ) )可见仅失败模式下失败节点本来就会立即通知而在合并模式下只有打开了merge_error_immediate_notify才会对失败节点额外即时推送。2.2 消息内容模板应用生命周期消息格式operation_notify.py任务「{应用名}」运行{成功/失败/开始}节点细节消息格式operation_notify.py任务「{应用名}」节点「{节点名}」 运行「{成功/失败}」 状态「{status}」可选仅 detailTrue 时追加 {自定义消息}可选三、配置结构与读写 APINotifyConfig的核心配置结构如下YAML 简化示意title: 一条龙运行通知 # 通知标题可自定义 enable_notify: true # 通知总开关 merge_error_immediate_notify: true # 合并模式下失败节点立即通知 notify_schema_version: 2 # 迁移后写入的 schema 版本 applications: app_id: lifecycle: start_and_finish # 应用通知off / finish_only / start_and_finish detail: all # 节点通知off / error_only / all / merge # 以下为旧版迁移来源字段迁移后保留 # enable_before_notify: true # notify_on_error: true # app_id: 0~33.1 关键 APINotifyConfig提供的读写接口notify_config.pyAPI作用enable_notify通知总开关默认True属性读写直接对应 YAML 中enable_notifytitle通知标题默认一条龙运行通知merge_error_immediate_notify合并模式失败立即通知开关application_notify_settings读取整个applications字典get_app_notify_modes(app_id)获取某应用二维模式(lifecycle, detail)无新结构时回退旧版映射set_app_notify_modes(app_id, lifecycle, detail)写入某应用二维模式任一参数为None时保留当前值get/set_app_lifecycle_mode、get/set_app_detail_mode单独读写某一维度set_app_notify_modes在写入时会把现有applications中所有应用设置拷贝一份再覆盖目标应用避免丢失其他应用的配置notify_config.py。值得注意的默认值当某应用在applications中不存在对应设置时get_app_notify_modes会回退到_get_legacy_modes(app_id)即按旧版整数配置映射若连旧字段也不存在则lifecycle默认为start_and_finish、detail默认为all。3.2 多开instance_idx隔离NotifyConfig.__init__(self, instance_idx, app_map)接收两个参数instance_idx多开实例索引传给YamlConfig后用于区分不同实例的配置文件app_map: dict[str, str]应用 ID 到应用名的映射迁移旧配置时需要遍历所有已注册应用。app_map由上层OneDragonContext注入GUI 界面也正是遍历notify_config.app_map为每个应用生成一张配置卡片。四、运行时读取链路operation_notify.pyoperation_notify.py 是通知的运行时大脑所有通知最终都从这里发出。它暴露了两个核心入口send_application_notify(app, status)应用生命周期通知send_node_notify(operation, round_result, current_node, next_node)节点细节通知由 operation.py 在每一轮节点执行结束后自动调用。4.1 应用生命周期通知send_application_notify的参数status语义True 成功、False 失败、None 开始。它的决策流程operation_notify.py读取该应用的生命周期模式与节点模式若生命周期为off且节点模式不是merge直接返回两者都关才不发若status is None开始消息仅当生命周期为start_and_finish时直接推送结束消息成功/失败的发送策略分三种节点模式为 merge 且通知池非空调用push_merged_async合并发送若生命周期未关闭把结束消息放在合并列表开头生命周期未关闭单条推送并附带通知池中最后一张截图pool.last_image否则不发送。4.2 节点通知装饰器与触发时机节点通知通过node_notify装饰器以元数据标注的方式声明operation_notify.py执行框架在节点结束钩子中读取func.operation_notify_annotation并调用send_node_notify。node_notify的参数参数含义when触发时机NotifyTiming.PREVIOUS_DONE上一节点完成后、CURRENT_DONE当前节点完成后无论成败、CURRENT_SUCCESS仅成功后、CURRENT_FAIL仅失败后custom_message自定义附加消息send_image是否附带节点执行时的last_screenshot截图默认Truedetail是否在消息中追加节点返回状态默认False同一个函数可以被多次装饰以实现多种时机通知例如成功时通知一次 失败时通知一次。仓库中已有大量真实用法可作参考例如charge_plan_app.py 使用node_notify(whenNotifyTiming.CURRENT_FAIL)在充能计划失败时通知另一节点同文件第 372 行用CURRENT_DONE, detailTrue展示状态详情city_fund_app.py、coffee_app.py、email_app.py 等在成功节点上使用CURRENT_SUCCESS迷失之地玩法中大量使用CURRENT_DONE并配合send_imageFalse、detailTrue控制消息粒度见 lost_void_app.py。send_node_notify的处理逻辑operation_notify.py通知总开关关闭或当前节点为空时直接返回按应用读取detail模式off完全不收集error_only仅失败节点收集all/merge全部收集汇总当前节点与下一节点PREVIOUS_DONE类上所有装饰器标注过滤掉不符合当前成败状态的通知组装消息后先pool.add()入池再根据模式决定是否立即推送all模式逐条立即推error_only与merge merge_error_immediate_notify 仅失败节点立即推。4.3 通知池合并模式的数据基础合并模式依赖 notify_pool.py 中的NotifyPool。它在ApplicationRunContext中创建每次应用开始运行时清空重用默认上限条目 200 条、图片 10 张超出条目上限时丢弃最旧条目超出图片上限时移除最旧图片文本始终保留仅图片被置空以控制内存last_image属性从池尾向前遍历取最后一张图供应用结束通知附带截图。五、GUI 交互推入式设置页与 Flyout 弹窗通知配置的 GUI 有两处入口交互方式不同1. 一条龙运行页中的通知设置推入式滚动设置界面由 NotifySettingInterface 实现通过 app_setting_manager.py 的show_notify_setting以pivot_navi.push_setting_interface推入。不再使用弹窗编辑配置变更在控件值变化时立即写入NotifyConfig无需点确定。界面包含通用分组合并模式失败节点立即通知开关SwitchSettingCard直接绑定merge_error_immediate_notify应用通知分组按app_map为每个应用生成AppNotifySettingCard每行两张卡片横向排列卡片上提供生命周期与节点通知两个下拉框app_notify_setting_interface.py。2. 应用卡片更多菜单中的通知设置Flyout由 AppNotifySettingFlyout 实现入口是应用卡片更多菜单中的通知设置按钮见 app_run_card.py通过show_app_notify_settingapp_setting_manager.py以TeachingTip弹出。它只编辑当前应用的应用通知和节点通知两个维度作用域更聚焦。六、旧版配置迁移6.1 旧版整数等级语义main 分支旧版配置使用应用 ID 对应的整数值旧值含义0关闭1仅应用2全部逐条3全部合并旧版同时还有两个布尔字段enable_before_notify是否发送开始通知与notify_on_error失败时是否通知。这些语义在 notify_config.py 中以NotifyLevel枚举保留注释明确说明仅用于迁移已有配置。6.2 迁移触发与映射规则启动构造NotifyConfig时若 YAML 中没有applications新结构会立即执行_migrate_legacy_config()完成迁移并落盘notify_config.py遍历app_map中每个应用调用_legacy_level_to_modes转换写入applications、merge_error_immediate_notify取旧notify_on_error默认True并写入notify_schema_version: 2。逐项映射规则_legacy_level_to_modesnotify_config.py旧等级新 lifecycle新 detail0关闭offoff1仅应用旧enable_before_notify为真 →start_and_finish否则 →finish_only旧notify_on_error为真 →error_only否则 →off2全部/逐条同 1 的 lifecycle 规则all3全部/合并同 1 的 lifecycle 规则merge可见迁移并非机械的一对一替换enable_before_notify决定开始通知是否保留notify_on_error决定仅失败级别下失败节点是否即时通知。6.3 迁移后的只读范围迁移完成后旧字段仍保留在文件中作为迁移来源不删除便于追溯与再次迁移但运行时只读取applications.app_id.lifecycle和applications.app_id.detail。框架内不再暴露旧版整数通知等级 API——NotifyLevel仅是迁移内部工具新代码一律通过NotifyLifecycleMode/NotifyDetailMode的字符串值操作。七、推送链路PushService 与多渠道发送配置与逻辑层最终都汇入 push_service.py 的PushService完成实际投递使用max_workers1的单线程线程池串行推送避免多应用并发时消息乱序init_push_channels内置了 SMTP、Webhook、钉钉、飞书、企业微信、OneBot、Bark、Server 酱、PushPlus、Discord、Telegram、Ntfy、Gotify、WxPusher 等二十余种渠道push_service.py 第 72-95 行push()在channel_id未指定时遍历所有通过配置校验的渠道发送push_config.send_image为假时统一剥掉截图应用生命周期使用push_async单条推送合并模式使用push_merged_async一次送出多条push_service.py。八、附一条龙运行汇总通知NotifyApp作为通知主题的延伸仓库在 notify_app.py 中提供了一个非玩法的通知应用APP_IDnotifyAPP_NAME通知优先级 3000见 notify_const.py它在一轮一条龙运行结束后汇总各应用的运行记录格式化出一条龙运行完成消息含成功指令列表、失败指令列表以及充能计划应用估算的当前体力通过PushService.push推送给用户。其运行记录 notify_run_record.py 每次运行都会重置保证每次都执行汇总推送。九、小结OneDragon 的通知系统通过应用通知 × 节点通知的二维正交配置把生命周期消息与节点细节消息彻底解耦配合merge_error_immediate_notify、通知池合并、装饰器标注等机制实现了从逐条即时到结束合并再到仅失败提醒的完整通知粒度谱系同时通过构造时的自动迁移让旧版整数配置0~3无缝升级到新二维结构。开发者接入通知时只需记住两条路径应用级通知走send_application_notify节点级通知用node_notify装饰器标注具体推不推、怎么推全部由operation_notify.py按配置裁决。赞分享桌面应用RPA计算机视觉【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon点击查看免费下载相关推荐ZenlessZoneZero-OneDragon绝区零一条龙AI 编码协作入口与开发规范解析ZenlessZoneZero OneDragon绝区零一条龙AI 编码协作入口与开发规范解析 本文以仓库根目录的 AGENTS.md https://li桌面应用RPA计算机视觉绝区零一条龙ZenlessZoneZero-OneDragon迷失之地检测模型来源、消费链路与发布规范深度解析绝区零一条龙ZenlessZoneZero OneDragon迷失之地检测模型来源、消费链路与发布规范深度解析 导读 迷失之地Lost Void是《绝桌面应用RPA计算机视觉DS2API Ollama兼容接口指南3个接口让Ollama客户端直连DeepSeek模型DS2API Ollama兼容接口指南3个接口让Ollama客户端直连DeepSeek模型 DS2API 是一款 DeepSeek 兼容中间件接口通过 Ol桌面应用RPA计算机视觉上一篇还在一首一首转NCMncmdumpGUI免费一键搞定NCM格式转换下一篇MPh 实战指南10 行 Python 让 COMSOL 自动批量跑仿真创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考