现象
正确下发两条不同微信号客资（qhj13981866488、cdribi），脚本首次运行时：初始待处理线索 = 2，正常添加第一条 qhj 后，待处理线索变为 1，本应继续添加第二条 cdribi；但后续会反复重新添加第一条 qhj，无法正常走第二条客资。
脚本内存过滤黑名单变量（finishedContacts）会被自动清空，相当于每次重新加载原始完整 leadList 任务参数，过滤失效，造成循环重复添加同一微信号。
AI 销售前端线索页面后续异常显示两条完全相同客资，和原始下发参数不一致。
核心怀疑原因
Hamibot 宿主框架存在自动超时 / 定时重启子业务脚本、重载中转参数文件 (temp_task_arg.json) 的全局调度机制：
一旦整体脚本进程被 Hamibot 重启，脚本内纯内存全局变量会被重置初始化，已添加客资的过滤黑名单直接丢失，无法实现持久过滤；
重启后重新加载原始全量 leadList 参数，导致重复执行第一条客资；
请问：
Hamibot 是否存在自动重启常驻子脚本、重载任务参数的调度机制？能否关闭该自动重启功能，让业务脚本保持单一常驻进程持续运行、不被自动重启？
Hamibot 常驻脚本是否支持持久化保存全局变量，避免脚本重启后内存变量丢失？
子脚本任务参数中转文件（temp_task_arg.json）是否会被框架反复自动重写 / 重载，覆盖原有任务状态？
是否有官方常驻脚本模式，保证脚本进程持续运行不被系统 / 框架强制重启？
回答
根据你描述的现象，问题根源在于脚本进程被异常终止后重新启动，导致内存中的过滤黑名单丢失，进而重新加载原始任务参数并重复执行。
以下是针对你四个问题的解答：
1. Hamibot 是否存在自动重启常驻子脚本的调度机制？能否关闭？
Hamibot 本身没有主动定时或自动重启常驻脚本的调度机制。
脚本进程被重启，99% 是由 Android 系统行为导致（如内存不足、应用被回收、省电策略等），并非 Hamibot 框架有意为之。
该行为无法直接“关闭”，但可以通过以下方式让脚本进程更稳定，降低被系统杀死的概率：
- 将脚本注册为前台服务（部分脚本已支持），在通知栏常驻，可显著提升存活率。
- 如手机有“后台管理”设置，将 Hamibot 设为“无限制”后台运行。
- 确保手机已授予所有必要权限（无障碍、后台弹窗、自启动等）。
2. Hamibot 常驻脚本是否支持持久化保存全局变量？
支持。
Hamibot 提供了 storages 模块，可将数据持久化到本地文件，脚本重启后可以读取，避免内存变量丢失。
示例代码（兼容 Rhino 引擎）：
// 文档地址 https://docs.hamibot.com/
var storage = storages.create("my_script_status");
// 保存已处理号码
var finishedContacts = storage.get("finishedContacts", []);
finishedContacts.push("qhj13981866488");
storage.put("finishedContacts", finishedContacts);
每次脚本启动时先从 storages 读取已完成列表，再与任务参数合并处理，即可实现跨重启的过滤。
3. 子脚本任务参数中转文件（temp_task_arg.json）是否会被框架反复自动重写/重载？
不会。
temp_task_arg.json 仅在下发任务、脚本首次启动或重启时由 Hamibot 写入一次，运行过程中不会自动重写或重载。
你遇到的“重新加载原始全量参数”现象，正是脚本进程重启后重新读取了该文件，而内存中的修改并未回写，导致状态丢失。
4. 是否有官方常驻脚本模式，保证脚本进程持续运行不被系统/框架强制重启？
没有绝对保证脚本永不重启的“官方模式”，因为系统层面的强制回收不可控。
但 Hamibot 支持以下手段来最大限度维持常驻：
- 前台服务模式：脚本内开启前台服务，让系统认为脚本是用户主动感知的任务，降低被杀风险。
- 异常捕获与自动恢复：在脚本中捕获异常，避免崩溃退出；若意外退出，Hamibot 会在条件允许时尝试重新启动脚本（取决于系统是否允许）。
- 持久化状态：结合
storages保存执行进度，即使重启也能从断点继续，避免重复执行业务。
综合以上，你的脚本改造建议：
- 在执行每条客资前，将已完成的号码存入
storages。 - 脚本启动时，从
storages读取已完成列表，与任务参数中的leadList做差集，得到真正待处理的号码。 - 确保脚本已授予全部权限，并尽量使用前台服务。
这样即使脚本被系统重启，也不会重复处理已添加的客资，前端线索页面也不会出现异常重复数据。