AITM 允许直接在运行中的实例内运行自己的定期维护和自动化脚本—无需重新构建 Docker 镜像，无需重新部署，只需重启容器。

User Jobs（计划插件作业）

plugins 文件夹位于何处

每个 AITM 发布构建（完整版、在线版和精简版 Docker 变体）都在镜像中内置了 plugins-runtime/ 层。但真正对您重要的文件夹，是持久化的、绑定挂载的数据卷：数据目录内的 plugins—通常是运行中容器内的 $AITM_DATA_DIR/plugins，而不是镜像内部的路径。

• 首次安装时它是空的。
• 首次启动时，容器的入口脚本会向其中放入参考用的 example-scheduled-job 插件—但仅当该子目录尚不存在时才会这样做，因此您对该文件夹所做的修改在升级和重启后仍会保留。
• AITM 每次容器启动时都会重新扫描 plugins 目录—因此添加或编辑作业后，必须重启容器才能使其生效（无需重新构建）。

添加自己的作业

1. 在挂载的 plugins/ 路径下创建一个新的子目录（每个作业/插件一个目录）。
2. 在其中添加一个包含 aitm.jobs 数组的 plugin.json 文件。
3. 添加作业的 handler.path 所指向的脚本文件。
4. 重启 AITM 容器。

plugin.json 的结构

字段	说明
name	唯一的作业标识符。
label	在界面中显示的可读名称。
intervalMs	作业重复执行的间隔，单位为毫秒。
priority	调度优先级—参见下方的安全说明；"high" 保留给 AITM 自身的内部作业。
timeoutMs	作业被终止之前的最长运行时间。
onTimeout	达到超时时间时的处理方式。
heavy	将作业标记为资源密集型。
parallel	是否可以与其他作业并发运行。
concurrencyGroup	同一组内的作业绝不会并发运行。
after	必须先完成才能运行本作业的作业。
next	本作业成功完成后要运行的作业。
minFreeRamMb / minFreeCpuPercent	运行所需的最低空闲资源。
kind	'in-process' | 'child-process' | 'remote'—作业的执行方式。
allowedModes	允许该作业运行的服务器模式。
handler	{ type: 'script', path, args, env }—运行什么以及如何运行。

示例

与随附的 example-scheduled-job 一致的示意结构：

{
  "aitm": {
    "jobs": [
      {
        "name": "example-scheduled-job",
        "label": "Example Scheduled Job",
        "intervalMs": 3600000,
        "priority": "normal",
        "timeoutMs": 60000,
        "kind": "child-process",
        "handler": {
          "type": "script",
          "path": "./run.js",
          "args": [],
          "env": {}
        }
      }
    ]
  }
}

无需重新部署即可调整作业

运维人员可以通过 REST 覆盖运行中作业的间隔、优先级或启用状态，而无需重启容器或重新部署：

• GET /api/scheduler/jobs/:name/override
• PUT /api/scheduler/jobs/:name/override

完整的技术参考（作业清单 schema 内部细节、kind/allowedModes 的语义、超时/重试机制）见 AITM 自带的文档。