RFC: Config v2 (欢迎有兴趣的朋友提出意见)

[wangl-cc]

Config V2 设计规范

概述

• Profile（profiles/*.toml）：定义如何连接——连接方式、客户端与可选的行为/进阶配置
• Task（tasks/*.yaml）：定义做什么——带条件和覆盖的任务列表

在下面的例子里面，由于 Profile 更扁平，适合 TOML；Task 嵌套很深，更适合 YAML。但是，新版本依然支持 TOML，YAML，JSON 三种格式混合使用，你可以选择你喜欢的格式。

设计目标

V2 的目标有两个：

• 对用户更直观：Profile 负责描述“如何连接”，Task 负责描述“做什么”，同时不再直接对接 MaaCore API。client_type 等运行上下文不再散落在任务参数中；任务文件也不再依赖多种隐式变换和不一致的规则，尤其体现在生命周期处理、参数传播，以及 variants 的激活逻辑上。
• 对实现更直接：配置边界更清晰，client_type 的来源唯一，自动生命周期与手写生命周期的语义分离，单 Session 与多 Session 也分别建模。这样可以避免在运行时反复提取、合并、回填和兜底，减少隐式规则和特殊分支。

兼容性

Profile 和 Task 都有一个顶层字段 version

version = 2 

• version = 2 → 按 V2 解析
• version = 1 → 按 V1 解析，不警告 (如果你暂时不想迁移的话，但是后续 V1 会删除，所以最终还是要迁移)
• 无 version → 按 V1 解析 + 弃用警告

Profile 和 Task 必须同时升级，不保证交叉兼容，必须是 Profile V1 + Task V1 或者 Profile V2 + Task V2.

---

Profile 配置

顶层字段

version = 2              # 必填，标识配置格式版本
inherits = "default"     # 可选，继承另一个 Profile，深度合并（子字段覆盖父字段）
client_type = "Official" # 可选

继承示例

inherits 字段用来继承另一个 Profile，可以方便的实现配置复用：

# profiles/default.toml
version = 2

[connection]
type = "General"
address = "emulator-5554"
touch_mode = "MaaTouch"

# profiles/yostar-en.toml
version = 2
inherits = "default"
client_type = "YoStarEN"   # 只改这一个字段，其余全部继承

游戏客户端类型

client_type 是一个横跨多个作用域的配置，决定：

• 加载哪个全局资源包（如 YoStarEN → EN 资源）
• 部分 Preset 使用的游戏包名 / Bundle ID（如 PlayCover）
• 任务条件判断需要的 client_type
• 部分任务需要注入的 client_type

[connection]

type 选择连接类型，除了 General 以外提供了一系列默认值，且决定哪些字段合法。此外，对于部分类型 (类如 Waydroid) 也负责确定如何管理外部环境。

[connection]
type = "General"               # General / PlayCover / Waydroid / AVD / MuMuPro

General（通用模式，直接对标原始的 MaaCore API）

类似于旧版本，但是部分选项的位置和名字发生了变化。

[connection]
type = "General"
address = "emulator-5554"   # 可选，缺省时从 `adb devices` 自动检测
adb_path = "adb"            # 可选
touch_mode = "MaaTouch"     # 可选：MaaTouch / MiniTouch / Adb
adb_lite = false            # 可选
kill_adb_on_exit = false    # 可选
config = "General"          # 可选，连接时使用的配置，可能影响部分行为

PlayCover（macOS 通过 PlayCover 原生运行 iOS App）

touch_mode 内部固定为 MacPlayTools，平台差异资源 iOS 自动加载。

[connection]
type = "PlayCover"
address = "127.0.0.1:1717"  # 可选，默认 127.0.0.1:1717
screencap_mod = "Default"  

Playcover 支持多种截图模式：

• Default：默认兼容模式
• BGR：速度更快，使用目前没发现兼容性问题
• SCK：使用 macOS ScreenCaptureKit 速度最快，但是需要 cli 的宿主 (终端)，被授予了截图权限

Waydroid（Linux Continer）

支持自动启动，连接地址在运行时从 waydroid status 获取：

[connection]
type = "Waydroid"
adb_path = "adb"           # 可选
touch_mode = "MaaTouch"    # 可选
adb_lite = false           # 可选

MuMuPro（macOS）

类似于通用 ADB，但是有已知的 adb_path 和 address

[connection]
type = "MuMuPro"
address = "127.0.0.1:16384"  # 可选
touch_mode = "MaaTouch"      # 可选
adb_lite = false             # 可选
kill_adb_on_exit = false     # 可选

后续可以扩展更多类型，比如 AVD (自动启动)，实体设备 (自动调节分辨率)，以及 Windows 上面的 Mumu / 雷电(截图增强)：

AVD（Android 虚拟设备）

sdk_path 必填，adb_path 和模拟器命令从中推导。

理论上支持截图增强，见 MaaAssistantArknights/MaaAssistantArknights#15608，有待实际实现

[connection]
type = "AVD"
sdk_path = "/home/user/Android/Sdk"   # 必填
avd_name = "Pixel_6_API_33"           # 可选，用于启动指定模拟器
touch_mode = "MaaTouch"               # 可选
adb_lite = false                      # 可选
kill_adb_on_exit = false              # 可选

[behavior]

运行时行为偏好，所有字段可选。

[behavior]
auto_reconnect = true          # 掉线后自动重连，默认 true
deployment_with_pause = false  # 部署时暂停，默认 false

[advanced]

进阶技术配置，大多数用户无需关注。所有字段可选。

[advanced]
inference_engine = "cpu"       # cpu / gpu:0 / gpu:1 / ...，默认 cpu
user_resource = false          # 从配置目录加载自定义资源，默认 false

完整示例

最简配置（PlayCover）：

version = 2

[connection]
type = "PlayCover"

完整配置（General）：

version = 2
client_type = "YoStarEN"

[connection]
type = "General"
address = "127.0.0.1:5555"
adb_path = "/usr/bin/adb"
touch_mode = "MaaTouch"
adb_lite = false
kill_adb_on_exit = false

[behavior]
auto_reconnect = true

[advanced]
inference_engine = "gpu:0"
user_resource = true

---

Task 配置（tasks/*.yaml）

结构

生命周期管理

两个标志控制自动启停：

• manage_environment_lifecycle（默认 true）：是否自动管理外部环境（如 Waydroid session、AVD）。由 Profile 的 connection.type 决定是否实际生效——General / PlayCover 等无外部环境的类型忽略此标志。
• manage_game_lifecycle（默认 true）：是否自动管理游戏启停流程。
  • 启用时，运行时会自动执行 StartUp / CloseDown，client_type 和 account_name 会自动注入给 StartUp。
  • 禁用时，用户可以自己在 tasks 中手写 StartUp / CloseDown task。Runtime 仍会将 Profile 的 client_type 注入到这些 task 的 params 中，但不会从中提取 client_type， client_type 的唯一来源始终是 Profile，同时不再保证中间任务出错后依然执行 CloseDown。

任务

Task 文件支持两种模式，两者不能同时存在：

• tasks：任务列表模式，通常对于单账号任务；
• sessions：编排模式，主要用于多个账号按顺序轮跑；

任务列表模式

version = 2
manage_environment_lifecycle: true  # 可选，默认 true
manage_game_lifecycle: true         # 可选，默认 true
account_name: main                  # 可选，注入给 StartUp

tasks:
  - type: Fight
    # ...

编排模式

所有 Session 共享 Profile 中的 client_type，只有 account_name 不同。实际按顺序串行执行。

manage_environment_lifecycle 只执行一次，(环境只启停一次）。
manage_game_lifecycle 每个 session 执行一次：

• 为 true 时，运行时会在各 Session 之间自动执行 CloseDown → StartUp
• 为 false 时，运行时仅按书写顺序执行，不做额外检查或兜底；如需切账号，需用户自己手写 StartUp / CloseDown

在 sessions 模式下：

• 顶层不能再出现 account_name
• 每个 Session 只描述该账号自己的 tasks
• Session 按顺序执行；当前 Session 未完成时，不会进入下一个 Session
• manage_game_lifecycle = false 时，Session 内允许手写 StartUp / CloseDown，但运行时不额外保证切换正确性

编排模式下的失败处理规则：

• 用户主动中断时，立即停止整个运行，不进入后续 Session
• 当前 Session 运行报错或掉线时，将该 Session 标记为失败，但继续执行后续 Session
• 如果启用了自动游戏生命周期，当前 Session 在报错或掉线后仍会先自动执行 CloseDown，再进入下一个 Session
• 最终结果需要反映所有失败的 Session，不能因为后续 Session 成功而吞掉前面的错误

version = 2
manage_environment_lifecycle: true  # 可选，默认 true，全局一次

sessions:
  - account_name: main
    tasks:
      - type: Fight
        params:
          stage: "1-7"

  - account_name: alt
    tasks:
      - type: Fight
        params:
          stage: CE-6

一个可能的痛点是，多 session 模式可能会存在大量的重复，所以后续可能会加上 template，允许复用。
现阶段主要使用可以利用 YAML 的锚点，一定程度进行复用。

Task 定义

每个 Task 包含：

• type（必填）：MaaCore 任务类型
• name（可选）：控制最终显示在 Summary 里面的名字
• if（可选）：控制该任务是否执行的条件；缺省表示始终执行
• params（可选）：任务执行时始终传给 MaaCore 的基础参数
• override_strategy（可选）：多个 override 同时命中时的处理策略，first 或 merge，默认 first
• overrides（可选）：条件性参数覆盖列表，叠加在 params 之上

除非显式说明，V2 中的 type 都直接对应 MaaCore task 类型。V2 不额外引入新的“生命周期 task 类型”；自动启停由 manage_*_lifecycle 控制。

tasks:
  - type: Fight
    name: Fight Daily
    override_strategy: first
    if:
      weekdays: [Mon, Wed, Fri]
    params:
      stage: "1-7"
      report_to_penguin: true
    overrides:
      - if: OnSideStory
        params:
          stage: ""
      - if:
          weekdays: [Tue, Thu, Sat]
        params:
          stage: CE-6

overrides 的应用策略由 override_strategy 决定：

• first（默认）：按顺序找到第一个命中的 override，应用后停止
• merge：按顺序应用所有命中的 override，后者覆盖前者

无匹配时使用原始 params，任务照常执行 (注意，V1 版本则会静默跳过)。

执行语义

自动游戏生命周期

当 manage_game_lifecycle = true 时：

• 单 Session 模式会在任务列表前后自动执行 StartUp / CloseDown
• account_name 会自动注入给 StartUp
• client_type 会自动注入给需要的任务参数

自动执行的 CloseDown 只在以下情况执行：

• 正常结束
• 运行报错
• 掉线停止

用户主动中断 (Ctrl-C) 时，不自动执行 CloseDown。后续可能添加配置/命令行参数，在报错的情况下，依然不关闭。

手写生命周期

当 manage_game_lifecycle = false 时：

• tasks 中可以手写 StartUp / CloseDown，并允许任意穿插
• 运行时严格按书写顺序执行
• 不再根据 CloseDown 做任何额外兜底
• 失败或中断后的行为与普通任务一致

---

条件系统

条件出现在两处：

• task.if——决定任务是否执行
• override.if——决定该 override 是否应用

字符串形式（无参数条件）

if: Always       # 始终激活（缺省 if 时的默认行为）
if: OnSideStory  # SideStory 期间激活（使用 Profile 中的 client_type）

其中：

• OnSideStory（字符串）表示检查当前 Profile 的 client_type
• on_side_story: Xxx（对象）表示显式检查指定客户端

Weekday（星期）

唯一字段：weekdays。

if:
  weekdays: [Mon, Wed, Fri]
  timezone: Official   # 可选：Local（默认）/ Official / YoStarEN / ... / UTC 偏移整数

timezone 为客户端名称时，以服务器时间 04:00 作为换天边界。

DayMod（天数取模）

唯一字段：divisor。满足 num_days_from_ce % divisor == remainder 时激活。

if:
  divisor: 2
  remainder: 0   # 可选，默认 0
  timezone: 8    # 可选，UTC 偏移整数

Time（每日时间段，循环）

唯一字段：time_after 和/或 time_before。

if:
  time_after: "16:00:00"
  time_before: "23:59:59"
  timezone: Official   # 可选

仅设 time_after：从该时刻到午夜激活。仅设 time_before：从午夜到该时刻激活。支持跨午夜的时间段（如 23:00–01:00）。

DateTime（日期范围，一次性）

唯一字段：start_date 和/或 end_date。

if:
  start_date: "2024-08-01T00:00:00"
  end_date: "2024-08-21T04:00:00"
  timezone: 8   # 可选，UTC 偏移整数

OnSideStory（指定客户端）

if:
  on_side_story: Txwy   # 检查指定客户端的限时活动状态

这里的 Txwy 是显式目标客户端，与 Profile 当前使用的 client_type 无关。

组合条件

# AND——所有子条件满足
if:
  all:
    - weekdays: [Mon, Wed, Fri]
    - time_after: "16:00:00"

# OR——任一子条件满足
if:
  any:
    - weekdays: [Sat]
    - weekdays: [Sun]

# NOT——取反
if:
  not:
    weekdays: [Sun]

---

完整 Task 示例

manage_game_lifecycle: true

tasks:
  # Fight：始终执行，但根据条件覆盖关卡
  - type: Fight
    params:
      stage: "1-7"
      report_to_penguin: true
      penguin_id: "00000000"
    overrides:
      - if: OnSideStory
        params:
          stage: ""
      - if:
          weekdays: [Tue, Thu, Sat]
        params:
          stage: CE-6

  # Mall：仅在 16:00 后执行
  - type: Mall
    if:
      time_after: "16:00:00"
    params:
      shopping: true
      credit_fight: true
      buy_first: [招聘许可, 龙门币]
      blacklist: [碳, 家具, 加急许可]

  # Recruit：始终执行
  - type: Recruit
    params:
      refresh: true
      select: [4, 5]
      confirm: [3, 4, 5]

---

V1 → V2 迁移

Profile 迁移

V1

[connection]
type = "ADB"
adb_path = "adb"
device = "emulator-5554"
config = "CompatMac"

[resource]
global_resource = "YoStarEN"
user_resource = true

[static_options]
cpu_ocr = true

[instance_options]
touch_mode = "MaaTouch"
deployment_with_pause = false
adb_lite_enabled = false
kill_adb_on_exit = false

V2

version = 2
client_type = "YoStarEN"       # resource.global_resource 不再需要手动设，由 client_type 自动推导

[connection]
type = "General"               # "ADB" → "General"
address = "emulator-5554"      # "device" → "address"
adb_path = "adb"
touch_mode = "MaaTouch"        # 原 instance_options.touch_mode
adb_lite = false               # 原 instance_options.adb_lite_enabled
kill_adb_on_exit = false
config = "CompatMac"

[behavior]
deployment_with_pause = false  # 原 instance_options.deployment_with_pause

[advanced]
inference_engine = "cpu"       # 原 static_options.cpu_ocr = true → "cpu"
user_resource = true           # 原 resource.user_resource

主要变化：

• 添加 version = 2
• connection.type：ADB → General
• connection.device → connection.address
• resource.global_resource / platform_diff_resource → 由 client_type 和 connection.type 自动推导，不再需要手动设
• static_options / instance_options → 拆分到 [connection]、[behavior]、[advanced]

Task 迁移

V1

tasks:
  - type: StartUp
    params:
      start_game_enabled: true
      client_type: Official

  - type: Fight
    params:
      stage: "1-7"
    variants:
      - condition:
          type: Weekday
          weekdays: [Tue, Thu, Sat]
        params:
          stage: CE-6
      - condition:
          type: Always
        params: {}

  - type: CloseDown

V2

manage_game_lifecycle: true    # 替代手写 StartUp / CloseDown task

tasks:
  - type: Fight
    params:
      stage: "1-7"             # base params，始终使用
    overrides:                 # variants → overrides
      - if:
          weekdays: [Tue, Thu, Sat]   # condition → if，无需 type 标签
        params:
          stage: CE-6          # 不再需要 Always variant 保底

主要变化：

• StartUp / CloseDown task → manage_game_lifecycle: true（默认值），自动管理游戏启停
• client_type 不再在 task params 中设置，由 Profile 注入
• 用户仍可手写 StartUp / CloseDown（设 manage_game_lifecycle: false），但 client_type 只注入不提取，且运行时完全按书写顺序执行
• variants → overrides，仅覆盖参数，不影响任务是否执行
• condition → if，通过唯一字段推断类型，无需 type 标签
• 不再需要 Always variant 作为保底

[wangl-cc]

@satgo1546 @travellerse @commondservice @dragove @starrin @Jisu-Woniu @JasonHuang79 @Constrat

各位朋友如果有空的话，能麻烦你们看一下这个 RFC 吗?

主要想确认这几件事：

1. Profile 里面新的组织方式，你们觉得是否更合理?
2. tasks / sessions 两种模式是否自然?
3. manage_game_lifecycle 的自动模式有什么不能满足你们的吗?
4. variants -> overrides，新版本的条件分支是否更直观?
5. 对你们自己的配置场景来说，还有哪些明显缺失或不自然的地方?

[Constrat]

1. I don't think that's the "hardest" part of using maa-cli. The current implementation seems fine as-is, at least for me (with the updated waydroid changes, there's basically no configuration required except the preset and adb.
2. Can't say anything about this since I only run one account on global.
3. This is a pretty neat QoL, but then again nothing that couldn't be "easily" done with the current implementation. It was just a

     - type: StartUp
       params:
         client_type: YoStarEN # technically optional as this can be defined in default.toml
         start_game_enabled: true
   
     - type: CloseDown

   Still a good change as the config itself becomes "slimmer" with less repetitions
4. Absolutely. Having a "default" parameters and then the conditional just override specific declared parameters is more flexible.
5. I will report the discussion of Task status notification #511 here:

Technically it's not my case as my rotations are now systemd automated, but in case something doesn't work I ssh from termux (android) into my machine and run another function I made in zsh xD

ssh into my machine when something doesn't work is exactly why I want a remote client. Additionally, running the CLI as a daemon could help with automation (we can build our own scheduler), since systemd can be difficult to configure and manage (like you have to write a zsh script).

Systemd is not even that big of an issue. My biggest complaint and limitation of maa-cli is the base rotation. I thought I had it fixed but tonight for some reason it completely skipped a task (???). For unknown reasons it completely skipped an index?

I added a completely different task at 6 am that runs something completely different which should not have touched anything in the main rotation...? I'm still investigating, but what I was looking for was an automated rotation "changer" based on the exit code of maa itself. If we are to implement a maa-cli daemon with a scheduler I'd really like something either:

• plan_index keeps rotating between the avaiable indexes of a custom base rotation
• directly "switch" rotations at every run (1 time rotation 1, 2nd time rotation 2, 3rd time rotation 3 and back to rotation 1) similar, to what I've done with the script in Task status notification #511

Logs

Task 3 - 3AM	Task 7 - 7AM (???)

TL;DR the problem is not the scheduling, but getting reliable rotations. Relying on $EXIT_CODE may not the brightest "solution".

Because for example. If the infrast task correctly runs, but something else errors out, the rotation won't increase with my current implementation of the script.

Yes I know I could just let systemd run 3 at 3 7 at 7 11 at 11, etc etc. But like I did on WPF I like to "separate" the timers from the real-time clock because in this case doubling the safety nets, is not really reliable when arknights could crash, maa could crash, anything can happen when we don't watch a program. Opposite Heisenbug maybe?

I know I'm proposing things that are not really meant to be tackled with this issue / PR, I'm just bringing cool but more importantly features that I think may be very useful for Arknights automation power users

[commondservice]

我先翻译成英文，方便大家理解

（我去老大有点太长了喵）

I got lazy^^ and just got halfway through... If anyone having trouble with lingual things, just point out and I'd be happy translating ;)

Translation by me

Config V2 Design Specs

Overview

• Profile（profiles/*.toml）:Defines how to connect——connection method,client (type) and optional behavior/advanced configs
• Task（tasks/*.yaml）:Defines what to do——a task list with conditions and overrides

In coming examples, Profiles are more "flat" so TOML fits better; Tasks have more layers, so YAML seems better here. Anyway, new versions do still support mixing up TOML, YAML, JSON, choose whatever you like.

Goals of Design

V2 has two goals:

• Intuitive to users ：Profile describes "how to connect", Task describes "what to do", all without directly going into MaaCore API details. client_type and like, these runtime contexts won't scatter around in task parameters; task files don't rely on multiple implicit conversions and inconsistent rules, which are especially true when it comes to lifecycle processing, parameters passing, and activation of variants.
• Explicit to implementation：Config boundaries get clearer, client_type comes from one source only，semantic separation between auto and manual lifecycle, split modeled single Session & multi Session. This avoids repeatedly extracting, merging, backfilling and providing defaults, and reduces implicit constraints & special branches.

Compatibility

Profile and Task will have a top-level key version

version = 2 

• version = 2 → Parse by V2
• version = 1 → Parse by V1 without emitting a warning (in case you don't wanna migrate, but V1 will get deleted, so eventually you'll have to)
• No version → Parse by V1 + deprecation warning

Profile and Task MUST be upgraded together, no cross-compat guaranteed, IOW must be Profile V1 + Task V1 OR Profile V2 + Task V2.

---

Profile Configuration

Top-level Key

version = 2              # Must have, identifies config scheme version
inherits = "default"     # Optional, inherits another profile, merge by depth(I may have this translation wrong, anyway it means child key overrides parent key, also see below for an example)
client_type = "Official" # Optional

An Example of Inheritance

inherits is used to inherit another Profile, so that configuration reuse can be done conveniently:

# profiles/default.toml
version = 2

[connection]
type = "General"
address = "emulator-5554"
touch_mode = "MaaTouch"

# profiles/yostar-en.toml
version = 2
inherits = "default"
client_type = "YoStarEN"   # One modification only, all others are inherited

Client Type

client_type is a config that spans many scopes, it decides:

• Which global(in contrast to local) asset pack(resource) to load (YoStarEN → EN resources)
• Package ID / Bundle ID that some Presets use (like PlayCover)
• client_type required by tasks condition judgement
• client_type required to be injected into some tasks

[connection]

Use type to choose connection type, aside from General, there are some defaults, and this decides which keys are legitimate. Also, for some types (like Waydroid) this also decides how external environments are managed.

[connection]
type = "General"               # General / PlayCover / Waydroid / AVD / MuMuPro

General(Well, General mode, just matches original MaaCore API)

Like old version, however some configs have their location and name changed.

[connection]
type = "General"
address = "emulator-5554"   # Optional, auto detected from `adb devices` when empty
adb_path = "adb"            # Optional
touch_mode = "MaaTouch"     # One in: MaaTouch / MiniTouch / Adb
adb_lite = false            # Optional
kill_adb_on_exit = false    # Optional
config = "General"          # Optional, config used when connecting, may affect some behaviors

PlayCover(macOS uses PlayCover to run iOS Apps natively)

touch_mode is fixed to MacPlayTools internally, platform_diff resource iOS is loaded automatically.

[connection]
type = "PlayCover"
address = "127.0.0.1:1717"  # Optional, defaults to 127.0.0.1:1717
screencap_mod = "Default"  

Playcover supports multiple screenshot modes:

• Default：default compat mode
• BGR：faster, no compat issues so far
• SCK：uses macOS ScreenCaptureKit which is the fastest, but requires host of cli (the terminal) to be granted sereencap permission

Waydroid(Linux Container)

Supports auto launch, conn addr is retrieved from waydroid status during runtime:

[connection]
type = "Waydroid"
adb_path = "adb"           # Optional
touch_mode = "MaaTouch"    # Optional
adb_lite = false           # Optional

MuMuPro(macOS)

Like general ADB, but with known adb_path & address

[connection]
type = "MuMuPro"
address = "127.0.0.1:16384"  # Optional
touch_mode = "MaaTouch"      # Optional
adb_lite = false             # Optional
kill_adb_on_exit = false     # Optional

More types can be extended, like AVD (autolaunch), real devices (auto-adjust resolution), and MuMu / Leidian on Windows (ScreenCap Enhance):

AVD（Android 虚拟设备）

sdk_path REQUIRED，adb_path and emulator command are infered from it.

Theoretical ScreenCap Enhance support, see MaaAssistantArknights/MaaAssistantArknights#15608, not yet implemented

[connection]
type = "AVD"
sdk_path = "/home/user/Android/Sdk"   # Required
avd_name = "Pixel_6_API_33"           # Optional, use it to boot selected emulator
touch_mode = "MaaTouch"               # Optional
adb_lite = false                      # Optional
kill_adb_on_exit = false              # Optional

[behavior]

Runtime preferences, all keys optional.

[behavior]
auto_reconnect = true          # Default true
deployment_with_pause = false  # Default false

[advanced]

Advanced technical configs, most users won't need to bother, all keys optional

[advanced]
inference_engine = "cpu"       # cpu / gpu:0 / gpu:1 / ..., defaults to cpu
user_resource = false          # Load custom resources from config dir, default false

Full Examples

Simplest config (PlayCover)：

version = 2

[connection]
type = "PlayCover"

Full config (General)：

version = 2
client_type = "YoStarEN"

[connection]
type = "General"
address = "127.0.0.1:5555"
adb_path = "/usr/bin/adb"
touch_mode = "MaaTouch"
adb_lite = false
kill_adb_on_exit = false

[behavior]
auto_reconnect = true

[advanced]
inference_engine = "gpu:0"
user_resource = true

---

Task Configurations（tasks/*.yaml）

Structure

Lifecycle Management

Two flags control autostart/stop:

• manage_environment_lifecycle(default true): whether auto manage external environment(e.g. Waydroid session, AVD). connection.type in Profile decides if actually comes into effect——types without external environments like General / PlayCover ignore this flag.
• manage_game_lifecycle (default true): whether auto manage game start/stop.
  • When enabled, auto StartUp / CloseDown will be executed during runtime, and also client_type & account_name will be injected into StartUp(what about CloseDown)
  • When disabled, users can write StartUp / CloseDown task in tasks. Runtime will still inject client_type from Profile into these tasks' params, but not the other way around. client_type solely comes from Profile. Also no CloseDown guaranteed when some tasks go wrong.

Tasks

Task files support two modes, and they don't co-exist:

• tasks：任务列表模式，通常对于单账号任务；
• sessions：编排模式，主要用于多个账号按顺序轮跑；

任务列表模式

version = 2
manage_environment_lifecycle: true  # 可选，默认 true
manage_game_lifecycle: true         # 可选，默认 true
account_name: main                  # 可选，注入给 StartUp

tasks:
  - type: Fight
    # ...

编排模式

所有 Session 共享 Profile 中的 client_type，只有 account_name 不同。实际按顺序串行执行。

manage_environment_lifecycle 只执行一次，(环境只启停一次）。
manage_game_lifecycle 每个 session 执行一次：

• 为 true 时，运行时会在各 Session 之间自动执行 CloseDown → StartUp
• 为 false 时，运行时仅按书写顺序执行，不做额外检查或兜底；如需切账号，需用户自己手写 StartUp / CloseDown

在 sessions 模式下：

• 顶层不能再出现 account_name
• 每个 Session 只描述该账号自己的 tasks
• Session 按顺序执行；当前 Session 未完成时，不会进入下一个 Session
• manage_game_lifecycle = false 时，Session 内允许手写 StartUp / CloseDown，但运行时不额外保证切换正确性

编排模式下的失败处理规则：

• 用户主动中断时，立即停止整个运行，不进入后续 Session
• 当前 Session 运行报错或掉线时，将该 Session 标记为失败，但继续执行后续 Session
• 如果启用了自动游戏生命周期，当前 Session 在报错或掉线后仍会先自动执行 CloseDown，再进入下一个 Session
• 最终结果需要反映所有失败的 Session，不能因为后续 Session 成功而吞掉前面的错误

version = 2
manage_environment_lifecycle: true  # 可选，默认 true，全局一次

sessions:
  - account_name: main
    tasks:
      - type: Fight
        params:
          stage: "1-7"

  - account_name: alt
    tasks:
      - type: Fight
        params:
          stage: CE-6

一个可能的痛点是，多 session 模式可能会存在大量的重复，所以后续可能会加上 template，允许复用。
现阶段主要使用可以利用 YAML 的锚点，一定程度进行复用。

Task 定义

每个 Task 包含：

• type（必填）：MaaCore 任务类型
• name（可选）：控制最终显示在 Summary 里面的名字
• if（可选）：控制该任务是否执行的条件；缺省表示始终执行
• params（可选）：任务执行时始终传给 MaaCore 的基础参数
• override_strategy（可选）：多个 override 同时命中时的处理策略，first 或 merge，默认 first
• overrides（可选）：条件性参数覆盖列表，叠加在 params 之上

除非显式说明，V2 中的 type 都直接对应 MaaCore task 类型。V2 不额外引入新的“生命周期 task 类型”；自动启停由 manage_*_lifecycle 控制。

tasks:
  - type: Fight
    name: Fight Daily
    override_strategy: first
    if:
      weekdays: [Mon, Wed, Fri]
    params:
      stage: "1-7"
      report_to_penguin: true
    overrides:
      - if: OnSideStory
        params:
          stage: ""
      - if:
          weekdays: [Tue, Thu, Sat]
        params:
          stage: CE-6

overrides 的应用策略由 override_strategy 决定：

• first（默认）：按顺序找到第一个命中的 override，应用后停止
• merge：按顺序应用所有命中的 override，后者覆盖前者

无匹配时使用原始 params，任务照常执行 (注意，V1 版本则会静默跳过)。

执行语义

自动游戏生命周期

当 manage_game_lifecycle = true 时：

• 单 Session 模式会在任务列表前后自动执行 StartUp / CloseDown
• account_name 会自动注入给 StartUp
• client_type 会自动注入给需要的任务参数

自动执行的 CloseDown 只在以下情况执行：

• 正常结束
• 运行报错
• 掉线停止

用户主动中断 (Ctrl-C) 时，不自动执行 CloseDown。后续可能添加配置/命令行参数，在报错的情况下，依然不关闭。

手写生命周期

当 manage_game_lifecycle = false 时：

• tasks 中可以手写 StartUp / CloseDown，并允许任意穿插
• 运行时严格按书写顺序执行
• 不再根据 CloseDown 做任何额外兜底
• 失败或中断后的行为与普通任务一致

---

条件系统

条件出现在两处：

• task.if——决定任务是否执行
• override.if——决定该 override 是否应用

字符串形式（无参数条件）

if: Always       # 始终激活（缺省 if 时的默认行为）
if: OnSideStory  # SideStory 期间激活（使用 Profile 中的 client_type）

其中：

• OnSideStory（字符串）表示检查当前 Profile 的 client_type
• on_side_story: Xxx（对象）表示显式检查指定客户端

Weekday（星期）

唯一字段：weekdays。

if:
  weekdays: [Mon, Wed, Fri]
  timezone: Official   # 可选：Local（默认）/ Official / YoStarEN / ... / UTC 偏移整数

timezone 为客户端名称时，以服务器时间 04:00 作为换天边界。

DayMod（天数取模）

唯一字段：divisor。满足 num_days_from_ce % divisor == remainder 时激活。

if:
  divisor: 2
  remainder: 0   # 可选，默认 0
  timezone: 8    # 可选，UTC 偏移整数

Time（每日时间段，循环）

唯一字段：time_after 和/或 time_before。

if:
  time_after: "16:00:00"
  time_before: "23:59:59"
  timezone: Official   # 可选

仅设 time_after：从该时刻到午夜激活。仅设 time_before：从午夜到该时刻激活。支持跨午夜的时间段（如 23:00–01:00）。

DateTime（日期范围，一次性）

唯一字段：start_date 和/或 end_date。

if:
  start_date: "2024-08-01T00:00:00"
  end_date: "2024-08-21T04:00:00"
  timezone: 8   # 可选，UTC 偏移整数

OnSideStory（指定客户端）

if:
  on_side_story: Txwy   # 检查指定客户端的限时活动状态

这里的 Txwy 是显式目标客户端，与 Profile 当前使用的 client_type 无关。

组合条件

# AND——所有子条件满足
if:
  all:
    - weekdays: [Mon, Wed, Fri]
    - time_after: "16:00:00"

# OR——任一子条件满足
if:
  any:
    - weekdays: [Sat]
    - weekdays: [Sun]

# NOT——取反
if:
  not:
    weekdays: [Sun]

---

完整 Task 示例

manage_game_lifecycle: true

tasks:
  # Fight：始终执行，但根据条件覆盖关卡
  - type: Fight
    params:
      stage: "1-7"
      report_to_penguin: true
      penguin_id: "00000000"
    overrides:
      - if: OnSideStory
        params:
          stage: ""
      - if:
          weekdays: [Tue, Thu, Sat]
        params:
          stage: CE-6

  # Mall：仅在 16:00 后执行
  - type: Mall
    if:
      time_after: "16:00:00"
    params:
      shopping: true
      credit_fight: true
      buy_first: [招聘许可, 龙门币]
      blacklist: [碳, 家具, 加急许可]

  # Recruit：始终执行
  - type: Recruit
    params:
      refresh: true
      select: [4, 5]
      confirm: [3, 4, 5]

---

V1 → V2 迁移

Profile 迁移

V1

[connection]
type = "ADB"
adb_path = "adb"
device = "emulator-5554"
config = "CompatMac"

[resource]
global_resource = "YoStarEN"
user_resource = true

[static_options]
cpu_ocr = true

[instance_options]
touch_mode = "MaaTouch"
deployment_with_pause = false
adb_lite_enabled = false
kill_adb_on_exit = false

V2

version = 2
client_type = "YoStarEN"       # resource.global_resource 不再需要手动设，由 client_type 自动推导

[connection]
type = "General"               # "ADB" → "General"
address = "emulator-5554"      # "device" → "address"
adb_path = "adb"
touch_mode = "MaaTouch"        # 原 instance_options.touch_mode
adb_lite = false               # 原 instance_options.adb_lite_enabled
kill_adb_on_exit = false
config = "CompatMac"

[behavior]
deployment_with_pause = false  # 原 instance_options.deployment_with_pause

[advanced]
inference_engine = "cpu"       # 原 static_options.cpu_ocr = true → "cpu"
user_resource = true           # 原 resource.user_resource

主要变化：

• 添加 version = 2
• connection.type：ADB → General
• connection.device → connection.address
• resource.global_resource / platform_diff_resource → 由 client_type 和 connection.type 自动推导，不再需要手动设
• static_options / instance_options → 拆分到 [connection]、[behavior]、[advanced]

Task 迁移

V1

tasks:
  - type: StartUp
    params:
      start_game_enabled: true
      client_type: Official

  - type: Fight
    params:
      stage: "1-7"
    variants:
      - condition:
          type: Weekday
          weekdays: [Tue, Thu, Sat]
        params:
          stage: CE-6
      - condition:
          type: Always
        params: {}

  - type: CloseDown

V2

manage_game_lifecycle: true    # 替代手写 StartUp / CloseDown task

tasks:
  - type: Fight
    params:
      stage: "1-7"             # base params，始终使用
    overrides:                 # variants → overrides
      - if:
          weekdays: [Tue, Thu, Sat]   # condition → if，无需 type 标签
        params:
          stage: CE-6          # 不再需要 Always variant 保底

主要变化：

• StartUp / CloseDown task → manage_game_lifecycle: true（默认值），自动管理游戏启停
• client_type 不再在 task params 中设置，由 Profile 注入
• 用户仍可手写 StartUp / CloseDown（设 manage_game_lifecycle: false），但 client_type 只注入不提取，且运行时完全按书写顺序执行
• variants → overrides，仅覆盖参数，不影响任务是否执行
• condition → if，通过唯一字段推断类型，无需 type 标签
• 不再需要 Always variant 作为保底

[commondservice]

主要想确认这几件事：

1. `Profile` 里面新的组织方式，你们觉得是否更合理?

2. `tasks` / `sessions` 两种模式是否自然?

3. `manage_game_lifecycle` 的自动模式有什么不能满足你们的吗?

4. `variants -> overrides`，新版本的条件分支是否更直观?

5. 对你们自己的配置场景来说，还有哪些明显缺失或不自然的地方?

1. 感觉 Profile 这部分和现有的差别不大
2. tasks / sessions 对于多账户自动化看起来确实还可以。不过对于 sessions， 为什么不直接 include tasks 文件， 然后写个 cat-config 小功能（变成systemd的模样😄）
3. 挺好的吧，这样就不用手动 adb connect，或者搓 StartUp / CloseDown 了（最近maa-cli好像不会自己连接waydroid了，不过systemd service里加一行 ExecStartPre 的事）

on_side_story: Xxx（对象）表示显式检查指定客户端

感觉有点不太有用啊，客户端都在 Profile 里指定了，检查其它客户端的活动真有用吗（

而且建议改名成 override 系的）因为我还有点点想要 On资源收集全开放（会有吗）

• Time 和 DateTime，感觉time_after和time_before命名有点怪，我个人更喜欢time_from和time_until；DateTime 虽然应该是用不上（），但是命名也和 Time 的统一下，名词放前面。还有 DateTime 接受的格式，或者用到的 parser 最好给个示例的链接

• 还有这些配置文件的顺序会影响执行结果不？我觉得把带条件的往前放放会更直观，举个例子就是先 override if，然后再一个 if，最后默认的 params 兜底，像这样：

manage_game_lifecycle: true    # 替代手写 StartUp / CloseDown task

tasks:
  - type: Fight
    overrides:                 # variants → overrides
      - if:
          weekdays: [Tue, Thu, Sat]   # condition → if，无需 type 标签
        params:
          stage: CE-6          # 不再需要 Always variant 保底
      - if:
          OnSideStory
        params:
          stage: ""
    params:
      stage: "1-7"             # base params，始终使用

• 还有组合条件注释和命名不太一样，可能得提醒大家注意一下（

# OR——任一子条件满足
if:
  any:

总之整挺好，不过建议写 yaml 的时候大家备一个能自动缩进的编辑器 XD

[wangl-cc]

@commondservice 感谢反馈和翻译

不过对于 sessions， 为什么不直接 include tasks 文件， 然后写个 cat-config 小功能（变成systemd的模样😄）

做 sessions 主要是考虑到生命周期，每一个 session 持有一个游戏的生命周期，负责开游戏，执行，然后出错或者完成之后关游戏；对于整个大任务，有一个全局的生命周期用来控制外部环境(比如 Waydroid)。include 我也考虑过，其实实现也不难，对我来说麻烦的就是能不能 override，因为 tasks 是一个列表，所以很难精准的去 override 某一个参数，也许初版可以先不支持 override task， task 按照原样 include 进来。

最近maa-cli好像不会自己连接waydroid了

我没用过 Waydroid 不过 @Constrat 最近修了一下 Waydroid，应该会好用一点了。

on_side_story: Xxx（对象）表示显式检查指定客户端

感觉觉有点不太有用啊，客户端都在 Profile 里指定了，检查其它客户端的活动真有用吗

有道理，因为之前版本没有全局 client，现在有了，确实应该可以忽略，这样实现反序列化和后面验证都更简单了

Time 和 DateTime，感觉time_after和time_before命名有点怪，我个人更喜欢time_from和time_until；DateTime 虽然应该是用不上（），但是命名也和 Time 的统一下，名词放前面。还有 DateTime 接受的格式，或者用到的 parser 最好给个示例的链接

这个有道理，我改一下

还有这些配置文件的顺序会影响执行结果不？我觉得把带条件的往前放放会更直观，举个例子就是先 override if，然后再一个 if，最后默认的 params 兜底

其实在我的降伏 params 不是代表默认的，而是基础值不变值 (虽然也可以作为默认值，来 override)，此外 key 的顺序随便换，三种格式规范里面应该对 key 本身没有任何要求。

yaml 的时候大家备一个能自动缩进的编辑器 XD

YAML 缩进虽然难受，但是 TOML 写这种多层嵌套 + 列表更为痛苦，也许 JSON 是最好的选择 xD。

[JasonHuang79]

Weekday 那里，感觉还是蛮有用的
不过感觉配置那里可以试着把MuMu和雷电的截图增强加进去（这个真的很有用啊喂）
AVD的截图加了吗，感觉这个对于 Linux 用户很有用

[JasonHuang79]

Weekday 那里，感觉还是蛮有用的
不过感觉配置那里可以试着把MuMu和雷电的截图增强加进去（这个真的很有用啊喂）
AVD的截图加了吗，感觉这个对于 Linux 用户很有用

其他的我就没有什么很多的建议了，目前还是用 wpfgui 用得多

这里还有一个小问题
MaaCore 在 Android Termux 中编译是怎么做的，是不是可以直接编译一个 MaaCore 给 maa-cli 用呢？

[wangl-cc]

不过感觉配置那里可以试着把MuMu和雷电的截图增强加进去（这个真的很有用啊喂）
AVD的截图加了吗，感觉这个对于 Linux 用户很有用

现有的 preset 问题就是不能添加额外值，所以实现这些比较麻烦，因为他们要传其他参数。等这个重构完成后，我会预留相关接，然后做 avd，mumu 和雷电。当然有人任何人愿意贡献最好，因为这三个我现在都不用，测试起来比较麻烦。

这里还有一个小问题
MaaCore 在 Android Termux 中编译是怎么做的，是不是可以直接编译一个 MaaCore 给 maa-cli 用呢？

我之前试过在 avd 里面试过，termux 如果我没有记错就是一个 Linux，所以他其实理论上可以直接用预编译的 aarch64-Linux 的 cli 和 core。

[Constrat]

@JasonHuang79 if you're running "pure" termux without root... Good luck.

The way I made maa-cli work in termux was through arch PRoot

aarch64-Linux 的 cli 和 core。

Won't work. maa-cli is build for GNU/Linux environment (glibc) but Termux uses Android-Bionic.
(maa: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=8efba18fca13b26a20c1973251fb39c2170450bc, for GNU/Linux 3.7.0, stripped)

[JasonHuang79]

现有的 preset 问题就是不能添加额外值，所以实现这些比较麻烦，因为他们要传其他参数。等这个重构完成后，我会预留相关接，然后做 avd，mumu 和雷电。当然有人任何人愿意贡献最好，因为这三个我现在都不用，测试起来比较麻烦。

测试这方面，我可以过来帮忙，我能帮忙测 MuMu 和 AVD 的，PC端的 LD 我也可以帮忙测，不过现在是不是应该给选项中的 MuMuPro 加个括号里面写 macOS 区分一下？

if you're running "pure" termux without root... Good luck.

噢我确实是跑在没有 root 的 termux 里的
(My English is poor so I use Chinese)

Translated by myself

Oh I truly run it in Termux without root.

Won't work. maa-cli is build for GNU/Linux environment (glibc) but Termux uses Android-Bionic.

Cli 本体的话，直接用 rust 编译是可以得到二进制文件的，但是当我输入 maa install 的时候，才发现需要自己编译。不过 MaaCore 的话， MAA-Meow 那边倒是有能用在安卓上的 core ，但我不清楚能不能直接用到 cli 这边。

Translated by AI & myself (?

The CLI binary can be compiled directly with Rust, but when I ran maa install, I found out that I had to build it myself. However, for MaaCore, there seems to be a working version over at MAA-Meow —I'm just not sure if it can be used directly with the CLI side.

[satgo1546]

1. Profile 里面新的组织方式，你们觉得是否更合理?

支持提出client_type，这对降低用户配置复杂度很有用。

type = "General"和config = "General"两个字段容易让人混淆。但除了把文档得写得清楚点，我也想不到什么好办法能避免。

2. tasks / sessions 两种模式是否自然?

关于sessions模式的问题：

manage_game_lifecycle 每个 session 执行一次：

• 为 true 时，运行时会在各 Session 之间自动执行 CloseDown → StartUp

为什么要先执行CloseDown？在游戏已经正常打开的情况下，执行包含account_name的StartUp任务，会自动退出当前登录账号，返回登录页面再登录指定账号。这可以省去重启游戏的时间。

• 为 false 时，运行时仅按书写顺序执行，不做额外检查或兜底；如需切账号，需用户自己手写 StartUp / CloseDown

此时，多账号用户也完全可以用tasks模式，把各个账号需要执行的任务连带StartUp/CloseDown扁平化到同一个任务列表里，像下面这样。如果我的理解正确的话，这和sessions模式效果相同，划分多个session是不是没有意义？

version: 2
manage_game_lifecycle: false

tasks:
- type: StartUp
  params:
    account_name: main
- type: Fight
  params:
    stage: "1-7"
- type: CloseDown
- type: StartUp
  params:
    account_name: alt
- type: Fight
  params:
    stage: CE-6

3. manage_game_lifecycle 的自动模式有什么不能满足你们的吗?

我希望允许在执行完最后一个账号的任务后不自动退出游戏，这样我就可以在执行完任务后趁游戏还开着顺便做一些不在日常收菜任务列表里的手动操作，比如搬活动商店、卫一把之类的。

4. variants -> overrides，新版本的条件分支是否更直观?
5. 对你们自己的配置场景来说，还有哪些明显缺失或不自然的地方?

关于条件编写的直观性，我觉得这与设计上选择variants还是overrides关系不大，比较重要的可能是提供一个测试配置效果的方法，类似dry run。

说实话，无论是config v1还是v2，我都认为条件配置这一块太过复杂了。它确实提供了一些实用的功能；但因为可用的条件类型很少，语法又受限于配置文件格式，只能编码非常简单的条件，使该功能的有用程度与配置复杂度不成比例。

比如说，我的需求如下：

• 如果某个SSReopen关卡首次出现，那么刷该SSReopen。
• 如果(无正在进行的SS or 本周整周都有SS)，那么刷当期剿灭。
• 如果有正在进行的SS，那么刷当前SS掉落的、库存最少的蓝材料。
  • 如果当前SS将于2天内结束，那么刷该材料时，无限吃理智药。
• 如果没有正在进行的SS：
  • 如果(今天是星期一四六日 or 资源收集全开放)，那么刷AP-5，否则刷1-7。

这里很多条件目前都无法实现。因此我一直都没有使用过maa-cli的条件系统，而是包了一层脚本，在启动MAA之前先重写配置文件。这些条件应该不算什么小众的需求，我相信其他尝试使用条件系统的用户应该也有遇到过类似的表达力不足的问题，最终放弃或改用其他方式实现。

热更数据里包含SS和资源收集全开放时间的信息，但很难将它们以能适应不同用户的需求的通用的方式加到现有的条件系统里。在maa-cli的条件系统中添加更多条件类型只能缓解而不能根本解决问题。如果继续在当前的条件系统的基础上改进，最终格林斯潘第十定律一定会发力。

我认为比较好的解决方法是允许通过脚本动态生成配置，将SS开放情况、当前日期时间等信息传给脚本。这听起来很激进，但我相信无论是真人还是AI，都更愿意写些&&和||而不是{"all": []}和{"any": []}。这样一来，variants和overrides的语义区别、override_strategy的选择也不再是什么需要专门实现、文档说明的事，而能通过脚本逻辑自然表达出来。

inherits 字段用来继承另一个 Profile，可以方便的实现配置复用：

一个可能的痛点是，多 session 模式可能会存在大量的重复，所以后续可能会加上 template，允许复用。
现阶段主要使用可以利用 YAML 的锚点，一定程度进行复用。

这些也是配置脚本化能自动实现的功能。

YAML 缩进虽然难受，但是 TOML 写这种多层嵌套 + 列表更为痛苦，也许 JSON 是最好的选择 xD。

既然都这么说了，我觉得可以扩展JSON支持到JSON5/JSONC/KSON之类的。原版JSON真不是给人写的。

等这个重构完成后，我会预留相关接，然后做 avd，mumu 和雷电。当然有人任何人愿意贡献最好，因为这三个我现在都不用，测试起来比较麻烦。

我目前日常用的就是maa-cli + AVD，到时候应该可以来帮忙写AVD这块。

[wangl-cc]

为什么要先执行CloseDown？在游戏已经正常打开的情况下，执行包含account_name的StartUp任务，会自动退出当前登录账号，返回登录页面再登录指定账号。这可以省去重启游戏的时间。

这个我还真不知道，感谢提醒。这样就可以不用 close 了，只在每一个 session 开始 startup。

此时，多账号用户也完全可以用tasks模式，把各个账号需要执行的任务连带StartUp/CloseDown扁平化到同一个任务列表里，像下面这样。如果我的理解正确的话，这和sessions模式效果相同，划分多个session是不是没有意义？

多 Session 主要用于处理出错的情况，如果是一个扁平化列表，前一个 session 失败导致终止，可能会导致后面所有任务全都跳过。不过 MAA 的任务失败本身不会导致这个问题，他会跳过然后继续下一个任务。但是如果关掉了自动重连，stop 是 cli 控制得，如果不分 session 会导致这个问题。而且 session 另一个目的就是我希望避免让用户手写 Startup，虽然在不从 startup 提取 client 之后手写也没有什么大问题。

关于条件编写的直观性，我觉得这与设计上选择variants还是overrides关系不大，比较重要的可能是提供一个测试配置效果的方法，类似dry run。

说实话，无论是config v1还是v2，我都认为条件配置这一块太过复杂了。它确实提供了一些实用的功能；但因为可用的条件类型很少，语法又受限于配置文件格式，只能编码非常简单的条件，使该功能的有用程度与配置复杂度不成比例。

比如说，我的需求如下：

• 如果某个SSReopen关卡首次出现，那么刷该SSReopen。

• 如果(无正在进行的SS or 本周整周都有SS)，那么刷当期剿灭。

• 如果有正在进行的SS，那么刷当前SS掉落的、库存最少的蓝材料。

  • 如果当前SS将于2天内结束，那么刷该材料时，无限吃理智药。

• 如果没有正在进行的SS：

  • 如果(今天是星期一四六日 or 资源收集全开放)，那么刷AP-5，否则刷1-7。

这里很多条件目前都无法实现。因此我一直都没有使用过maa-cli的条件系统，而是包了一层脚本，在启动MAA之前先重写配置文件。这些条件应该不算什么小众的需求，我相信其他尝试使用条件系统的用户应该也有遇到过类似的表达力不足的问题，最终放弃或改用其他方式实现。

热更数据里包含SS和资源收集全开放时间的信息，但很难将它们以能适应不同用户的需求的通用的方式加到现有的条件系统里。在maa-cli的条件系统中添加更多条件类型只能缓解而不能根本解决问题。如果继续在当前的条件系统的基础上改进，最终格林斯潘第十定律一定会发力。

我认为比较好的解决方法是允许通过脚本动态生成配置，将SS开放情况、当前日期时间等信息传给脚本。这听起来很激进，但我相信无论是真人还是AI，都更愿意写些&&和||而不是{"all": []}和{"any": []}。这样一来，variants和overrides的语义区别、override_strategy的选择也不再是什么需要专门实现、文档说明的事，而能通过脚本逻辑自然表达出来。

有道理，其实现在就是在实现一个 DSL，而且写起来很丑。所以我想到的一个做法是可以允许任务可以注入变量，比如

tasks:
- type: Fight
  params:
    stage: ${stage}

然后 cli 在运行的时候可以 maa run daily -Dstage=1-7 这样来完成，然后可以 maa cat daily -Dstage=1-7 获得渲染得到的无条件，无输入，无模板的结果。我觉得这个用户脚本生成文件更可控，不过这可能不太适合生成大批量数据。

inherits 字段用来继承另一个 Profile，可以方便的实现配置复用：

一个可能的痛点是，多 session 模式可能会存在大量的重复，所以后续可能会加上 template，允许复用。
现阶段主要使用可以利用 YAML 的锚点，一定程度进行复用。

这些也是配置脚本化能自动实现的功能。

我个人不太喜欢把配置完全脚本化，我个人更倾向于轻微模板化的配置。完全脚本化会可能导致配置可读性下降，而且编辑的时候很难直接通过 schema 验证/补全。我可以让 maa-cli 能够提供更多 metadate，但是不太想让 maa 自己负责读取脚本，动态生成配置这一件事。

既然都这么说了，我觉得可以扩展JSON支持到JSON5/JSONC/KSON之类的。原版JSON真不是给人写的。

我可以去找一些，有没有什么比较好的库可以用一下的。

[commondservice]

@satgo1546 我觉得条件这块，是不是可以考虑引入一个判断函数，用正经编程语言写，然后提供一些便捷的函数提供各种信息（有点nix的感觉），这样又有补全又好实现。最后在配置文件里加个注释，还能兼顾可读性

[Jisu-Woniu]

感觉这么做有点麻烦，毕竟真正的条件逻辑应该达不到那么复杂。引入别的编程语言（比如Lua）就要加一套运行时。（系统Shell可能不需要运行时，但是总归有点安全风险，也不是很好写）