MAA 明日方舟助手 SSS 保全派驻协议详解从 JSON 字段到战斗主循环的源码解析【免费下载链接】MaaAssistantArknights《明日方舟》小助手全日常一键长草| A one-click tool for the daily tasks of Arknights, supporting all clients.项目地址: https://gitcode.com/GitHub_Trending/ma/MaaAssistantArknights本文以 保全派驻协议文档 为主体完整讲解 MaaAssistantArknightsMAA中type: SSS保全派驻协议的全部字段含义、单关策略strategies的判定规则与actions用法并结合 SSSCopilotConfig.cpp、SSSBattleProcessTask.cpp 等源码还原协议从加载、开局换人、战斗主循环到阶段管理的完整执行链路帮助你从零写出可用的保全派驻作业 JSON。一、协议定位SSS 与 copilot 协议的关系保全派驻游戏内 LT/SS 玩法协议中以SSS指代是 roguelike 式多关卡战斗开局选干员与导能元件中途可增调干员与装备战斗失败可重开整局。为此 MAA 在通用战斗流程协议copilot 协议之外定义了 SS 协议核心差异在于单份 JSON 描述多个关卡stages数组程序按屏幕识别到的关卡名逐关执行每关支持strategies按格子声明“核心干员 工具人”的自适应部署计划与drops中途增调优先级而不是一条固定时间轴提供了 SSS 专属 action 类型如调配干员、CheckIfStartOver。从源码结构看SS 作业数据继承自 copilot 的数据结构AsstBattleDef.h 中namespace sss定义了Strategy含可选core、tool_men、location、direction与完成标记all_deployed、CombatData继承copilot::CombatData新增strategies、draw_as_possible、retry_times、order_of_drops与CompleteData整份协议含buff、equipment、strategy、groups、tool_men、order_of_drops、blacklist与按关名索引的stages_data。协议文件通过SSSTask的set_params以filename参数加载通常放在resource/copilot/目录下与 copilot 作业同目录可参考 协议文档中的示例文件说明。SSSCopilotTask.cpp 中可见set_params校验filename后调用SSSCopilot.load()解析解析失败即报错退出若buff非空则将其写入 OCR 任务SSSBuffChoose的候选文本用于开局选择导能元件。二、协议 JSON 完整字段一览注意JSON 文件本身不支持注释以下注释仅用于说明请勿直接复制使用原文档同样有此提示。{ type: SSS, // 协议类型SSS 表示保全派驻必选不可修改 stage_name: 多索雷斯在建地块, // 保全派驻地图名必选 minimum_required: v4.9.0, // 最低要求 maa 版本号必选 doc: { // 描述可选 title: 低练度高成功率作业, title_color: dark, details: 对练度要求很低balabala……, // 建议在这里写上你的名字作者名、参考的视频攻略链接等 details_color: dark }, buff: 自适应补给元件, // 开局导能元件选择可选 equipment: [ // 开局装备选择横着数可选 // 当前版本暂未实现只会在界面上显示一下 A, A, A, A, B, B, B, B ], strategy: 优选策略, // 或者 自由策略可选 // 当前版本暂未实现只会在界面上显示一下 opers: [ // 指定干员可选 { name: 棘刺, skill: 3, skill_usage: 1 } ], groups: [ // 干员编组可选用法同 copilot 协议中的 groupsactions 中的 name 可以填编组名 { name: 地面阻挡, opers: [ { name: 棘刺, skill: 3 }, { name: 泥岩, skill: 2 } ] } ], tool_men: { // 剩余所需各职业人数按费用排序随便拿必选 // 当前版本暂未实现只会在界面上显示一下 Pioneer: 13, 近卫: 2, // 中英文均可 Medic: 2 }, drops: [ // 战斗开始时和战斗中途招募干员、获取装备优先级 空弦, 能天使, // 支持干员名、职业名 先锋, // 职业名中英文均可 Support, 无需增调干员, // 不招人 重整导能组件, // 支持装备名全写一起.jpg 反制导能组件, 战备激活阀, // 关卡中途的可选装备也放这里 改派发讯器 ], blacklist: [ // 黑名单可选。在 drops 里不会选这些人。 // 后续版本支持编队后编队工具人也不会选这些人 夜半, 梅尔 ], stages: [ { stage_name: 蜂拥而上, // 单层关卡名必选 // 支持 name, stageId, levelId推荐 stageId 或 levelId // 请勿使用 code例如 LT-1因为会和其他保全关卡冲突 strategies: [ // 必选 // 每次检查都会从头自上而下依次进行并跳过执行完毕的策略 // 若当前策略的工具人已经部署完毕 // 若没有 core则认为此策略执行完毕 // 若有 core 且可以部署则部署 core 并认为策略执行完毕 // 若有 core 正在转费用则等待并跳过后续策略 // 若当前策略的工具人还未部署完毕 // 若部署区没有所需工具人则检查下一条策略 // 若部署区存在所需工具人 // 若没有能立即部署的则等待 // 若存在能立即部署的则优先部署费用少的 // 对于同一格的策略 // 若没有 core则允许在待部署区没有所需工具人时不论费用是否转好允许继续检查同一格后续策略 // 若有 core则没有执行完毕时忽略同一格后续策略 // 同一格可以写多个干员 core非最靠后的干员 core 在其策略执行完毕后等效过牌不计入工具人 { core: 棘刺, tool_men: { Pioneer: 1, // 中英文均可 Warrior: 1, Medic: 1 }, location: [ 10, 1 ], direction: Left }, { core: 泥岩, tool_men: { Pioneer: 1, Warrior: 1, Medic: 1 }, location: [ 2, 8 ], direction: Left }, { // 不填写 core可以用于部署辅助过牌的之类的 tool_men: { Support: 100 }, location: [ 2, 8 ], direction: Left } ], draw_as_possible: true, // “调配干员”按钮是否好了就用必选 actions: [ // 可选 // 基本复用抄作业的逻辑可参考 protocol/copilot-schema.md // 符合 action 的条件就执行 action否则执行上面的 strategies 的逻辑 { type: 调配干员 // 新 type“调配干员” 按钮点一下在 draw_as_possible 为 true 时无效 }, { type: CheckIfStartOver, // 新 type检查干员在不在不在就退出重开 name: 棘刺 }, { name: 桃金娘, location: [ 4, 5 ], direction: 左 }, { kills: 10, type: 撤退, name: 桃金娘 } ], retry_times: 3 // 战斗失败重试次数可选默认为 0超过了直接放弃整局 }, { stage_name: 见者有份 // ... } // 写几关打几关比如只写到了 4则打完 4 自动重开 ] }三、顶层字段逐项说明含源码佐证3.1 基本信息与版本约束type、stage_name、minimum_required、doc均由 copilot 的基础信息解析逻辑统一处理SSSCopilotConfig.cpp 中parse()先调用CopilotConfig::parse_basic_info(json)解析出BasicInfo对应 AsstBattleDef.h 中的stage_name、minimum_required、title、title_color、details、details_color随后解析groups。doc中的title/details用于界面展示适合署名与贴攻略链接。3.2 buff / equipment / strategy / opers开局选项buff解析后若非空会写入SSSBuffChooseOCR 任务作为开局元件选择候选见 SSSCopilotTask.cpp是实际生效的字段equipment解析时只接受A/B大小写均可且长度不为 8 会输出equipment size is not 8警告SSSCopilotConfig.cpp如文档所述当前版本暂未实现开局装备的实际选择仅解析保存strategy优选/自由策略与顶层opers同样解析或仅用于展示当前版本未参与实际决策。3.3 groups编组语法复用 copilotgroups由CopilotConfig::parse_groups解析SSSCopilotConfig.cpp并在每关解析时下发给该关的CombatDatastage_data.groups m_data.groupsSSSCopilotConfig.cpp因此strategies/actions里的name均可填编组名用法与 copilot 协议 完全一致编组内干员任选其一优先选练度高的。3.4 tool_men整局职业配额顶层tool_men通过parse_role_counts解析为职业人数表中英文职业名均可。按文档说明当前版本它只在界面展示从源码看配套的自动编队任务BattleFormationTask虽然被挂入了任务链但 SSSCopilotTask.cpp 中AdditionalFormation相关代码被注释并显式set_enable(false)“暂时不支持自动编队”与文档描述互相印证。3.5 drops / blacklist中途增调优先级drops被原样存入order_of_dropsSSSCopilotConfig.cpp战斗开始与半程补给时按此优先级招募干员、获取装备。战斗中的具体执行在 SSSBattleProcessTask.cpp 的check_and_get_drops()先识别半程补给界面SSSHalfTimeDropsBegin若drops为空数组执行SSSHalfTimeDropsCancel直接取消增调否则把drops全列表写入 OCR 任务SSSHalfTimeDrops的候选文本按列表顺序 OCR 匹配并点击——这也解释了为什么列表里可以混写干员名、职业名、装备名如Support、反制导能组件匹配到哪个选哪个无需增调干员则对应界面上的不招募按钮。blacklist存入CompleteData::blackliststd::unordered_setstd::stringAsstBattleDef.h。按文档说明其作用是让drops选择不命中这些干员后续支持自动编队后同样会排除这些“工具人”。四、单关字段stages 与 strategies 判定规则4.1 stage_name 的解析与匹配每关的stage_name支持 name、stageId、levelId推荐 stageId/levelId文档特别强调不要使用 LT-1 这类 code因为会与其他保全关卡冲突。源码中对应机制是解析时通过Tile.find(stage_name)查询该关对应的屏幕显示名ocr_code并以显示名为 key 存入stages_dataSSSCopilotConfig.cpp。运行时 SSSStageManagerTask.cpp 的analyze_stage()用 OCR 任务SSSStageNameOCR读取屏幕关卡名再与stages_data的 key 做精确匹配——匹配不到时程序会判定为通关界面报SSSGamePass或走结算退出。这就是“写几关打几关”的实现写到第 4 关为止第 5 关的名字不在 JSON 中本局即自动结算放弃。4.2 strategies 的判定语义strategies是 SS 协议的核心按数组顺序自上而下逐条检查跳过已完成的策略规则与文档注释一致。SSSBattleProcessTask.cpp 的check_and_do_strategy()实现了完整决策可逐条印证文档中的规则跳过已完成策略strategy.all_deployed为真直接跳过对应“跳过执行完毕的策略”同格互斥用loc_with_strategy记录已有未完结策略的格子后续同格策略被跳过但只有带 core 的策略在等待时才会占用该格if (strategy.core.has_value()) loc_with_strategy.emplace(...)不带 core 的策略在待部署区没有所需工具人时会继续检查同格后续策略——与文档“若没有 core则允许继续检查同一格后续策略”逐字对应core 优先部署当 core 在待部署区、且该策略的tool_men全部部署完时use_the_core若 core 费用已转好则立即部署并标记all_deployed若 core 还在转费用则return false原地等待并阻塞后续策略对应“若有 core 正在转费用则等待并跳过后续策略”工具人部署若tool_men未满则从待部署区找一个职业匹配且费用已转好的干员部署同时确保不会把其他策略的 core 当工具人点掉!m_all_cores.contains(oper.name)部署的工具人技能会被统一设为“好了就用”SkillUsage::PossiblySSSBattleProcessTask.cpp等待语义待部署区存在所需职业但都在转费用时返回 false 等待都不存在时检查下一条策略。另外文档中“同一格可写多个干员 core非最靠后的干员 core 执行完毕后等效过牌”的设计与源码中部署 core 后将其从m_all_cores移除SSSBattleProcessTask.cpp的行为一致已部署的 core 不再受后续策略约束。4.3 draw_as_possible该字段必选对应“调配干员”按钮。在战斗主循环 SSSBattleProcessTask.cpp 的do_strategic_action()中每轮检查完 drops、strategies 与“好了就用”技能后若draw_as_possible为 true 就尝试点一次SSSDrawCard无重试、零延迟的轻量检查。开启后动作列表中显式的{type: 调配干员}就不再需要——文档亦注明其“在 draw_as_possible 为 true 时无效”。4.4 actions复用 copilot 两个 SSS 专属 type单关actions基本复用 copilot 协议 的操作逻辑部署/技能/撤退/二倍速/条件kills/costs/cost_changes/elapsed_time等均同前。执行顺序是符合 action 条件就执行 action否则执行 strategies 逻辑。SS 协议新增了两个 type在 SSSBattleProcessTask.cpp 的do_derived_action()中分发调配干员DrawCard点击“调配干员”按钮并刷新待部署区识别CheckIfStartOver检查干员是否还在场上或待部署区不在则放弃本局重开。SSSBattleProcessTask.cpp 中check_if_start_over()的实现是name指定时在待部署区与战场上都找不到该干员即调用abandon()也可用role_counts校验某职业人数不足。常用于开局几秒内确认关键干员如指定 core没有被随机换走。4.5 retry_times整局容错retry_times可选默认 0。SSSStageManagerTask.cpp 的preprocess_data()将其转换为每关的可用次数retry_times 1即含首战主循环 SSSStageManagerTask.cpp 中某关战斗结束后计数减一次数耗尽则回调SSSSettlementwhy: Cant win, run!并走结算流程放弃整局。五、战斗执行链路从 set_params 到逐关推进5.1 任务链组装SSSCopilotTask.cpp 的构造函数展示了完整子任务链SSSBeginSSSStartFighting进入保全派驻并点击开战含选地图、选元件SSSBuffChoose等界面流程BattleFormationTaskDataResource::SSSCopilot自动编队占位当前被禁用SSSTeamConfirmSSSStartFighting确认编队再次开战SSSStageManagerTask阶段管理主循环注册了SSSDropRewardsTaskPlugin处理干员掉落奖励。set_params还支持loop_times参数默认 1大于 1 时把上述子任务链整体复制多份顺序执行SSSCopilotTask.cpp即连打多局。5.2 开局自动换人进入战斗前的wait_until_start()SSSBattleProcessTask.cpp实现了一套开局预选替换逻辑属于源码层面的实用细节默认最多替换 4 人费用阈值 29费用低于该值不替换若场上先锋少于 2 个阈值降为 25试图换出先锋保证费用运转待部署区若出现“超重绝缘水泥”这类 Drone 装置直接丢弃不计入替换数若作业中指定了“超重绝缘水泥”为 core则只额外换 1 人防止把它换掉。5.3 战斗主循环的帧率与轮询节奏do_strategic_action()每轮依次做四件事check_and_get_drops半程补给→check_and_do_strategy格子策略→use_all_ready_skill全场“好了就用”技能→ 按draw_as_possible尝试调配干员SSSBattleProcessTask.cpp。两个值得注意的工程细节帧率限制每轮截屏间隔受Config.get_options().sss_fight_screencap_interval控制毫秒级限帧防止空转占满 CPU可在 MAA 配置中调整自适应轮询间隔update_deployment_with_skip()在连续 30 秒待部署区无变化时通常进入挂机阶段把识别间隔拉大到 1 秒有变化则立即恢复 0 间隔SSSBattleProcessTask.cpp。5.4 阶段管理逐关识别与结算SSSStageManagerTask.cpp 的_run()主循环是整局骨架等待战斗结束SSSConfirmBattleComplete → OCR 识别当前关卡名SSSStageNameOCR ├─ 识别失败若处于开始界面 → 报 SSSTask SSSGamePass通关 │ 否则 → 报 SSSTask SSSSettlement识别错误或 JSON 不支持该关并结算退出 └─ 命中 stages_data扣减重试次数 → 点击开始SSSStartFighting / SSSTask SSSTask SSSTask SSSTask SSSTask SSSTask → 运行 SSSBattleProcessTask 打本关 → 回到循环顶部识别失败的回调文案Recognition error or JSON does not support this.也再次说明JSON 里没写的关卡会被视为“不支持”程序主动结算本局。六、编写协议的建议清单必选字段别漏顶层type、stage_name、minimum_required、tool_men每关stage_name、strategies、draw_as_possible关卡名用 stageId/levelId避免 LT 系 code 冲突stages按实际出关顺序书写写多少关就打算打多少关strategies 设计关键位写core 少量tool_men按职业配额而非指定干员容错性最好纯工具位可不写 core同格多 core 时把主力放最后drops 优先级把最想要的人/职业/装备放最前无需增调干员放在不想招人的场景不想见的干员进blacklist稳定性兜底给易翻车的关键关设置retry_times开局用CheckIfStartOver检查关键干员actions里可用kills等条件插入撤退、加速等操作命名与署名doc.details中写明作者与攻略出处方便社区追溯。参考文件协议文档docs/zh-cn/protocol/sss-schema.md、docs/zh-cn/protocol/copilot-schema.md协议解析src/MaaCore/Config/Miscellaneous/SSSCopilotConfig.cpp任务入口与参数src/MaaCore/Task/Interface/SSSCopilotTask.cpp战斗执行src/MaaCore/Task/SSS/SSSBattleProcessTask.cpp、src/MaaCore/Task/SSS/SSSStageManagerTask.cpp数据结构src/MaaCore/Common/AsstBattleDef.h【免费下载链接】MaaAssistantArknights《明日方舟》小助手全日常一键长草| A one-click tool for the daily tasks of Arknights, supporting all clients.项目地址: https://gitcode.com/GitHub_Trending/ma/MaaAssistantArknights创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/13 19:59:55 · 阅读 1.2k MAA 明日方舟助手 SSS 保全派驻协议详解：从 JSON 字段到战斗主循环的源码解析
MAA 明日方舟助手 SSS 保全派驻协议详解从 JSON 字段到战斗主循环的源码解析【免费下载链接】MaaAssistantArknights《明日方舟》小助手全日常一键长草| A one-click tool for the daily tasks of Arknights, supporting all clients.项目地址: https://gitcode.com/GitHub_Trending/ma/MaaAssistantArknights本文以 保全派驻协议文档 为主体完整讲解 MaaAssistantArknightsMAA中type: SSS保全派驻协议的全部字段含义、单关策略strategies的判定规则与actions用法并结合 SSSCopilotConfig.cpp、SSSBattleProcessTask.cpp 等源码还原协议从加载、开局换人、战斗主循环到阶段管理的完整执行链路帮助你从零写出可用的保全派驻作业 JSON。一、协议定位SSS 与 copilot 协议的关系保全派驻游戏内 LT/SS 玩法协议中以SSS指代是 roguelike 式多关卡战斗开局选干员与导能元件中途可增调干员与装备战斗失败可重开整局。为此 MAA 在通用战斗流程协议copilot 协议之外定义了 SS 协议核心差异在于单份 JSON 描述多个关卡stages数组程序按屏幕识别到的关卡名逐关执行每关支持strategies按格子声明“核心干员 工具人”的自适应部署计划与drops中途增调优先级而不是一条固定时间轴提供了 SSS 专属 action 类型如调配干员、CheckIfStartOver。从源码结构看SS 作业数据继承自 copilot 的数据结构AsstBattleDef.h 中namespace sss定义了Strategy含可选core、tool_men、location、direction与完成标记all_deployed、CombatData继承copilot::CombatData新增strategies、draw_as_possible、retry_times、order_of_drops与CompleteData整份协议含buff、equipment、strategy、groups、tool_men、order_of_drops、blacklist与按关名索引的stages_data。协议文件通过SSSTask的set_params以filename参数加载通常放在resource/copilot/目录下与 copilot 作业同目录可参考 协议文档中的示例文件说明。SSSCopilotTask.cpp 中可见set_params校验filename后调用SSSCopilot.load()解析解析失败即报错退出若buff非空则将其写入 OCR 任务SSSBuffChoose的候选文本用于开局选择导能元件。二、协议 JSON 完整字段一览注意JSON 文件本身不支持注释以下注释仅用于说明请勿直接复制使用原文档同样有此提示。{ type: SSS, // 协议类型SSS 表示保全派驻必选不可修改 stage_name: 多索雷斯在建地块, // 保全派驻地图名必选 minimum_required: v4.9.0, // 最低要求 maa 版本号必选 doc: { // 描述可选 title: 低练度高成功率作业, title_color: dark, details: 对练度要求很低balabala……, // 建议在这里写上你的名字作者名、参考的视频攻略链接等 details_color: dark }, buff: 自适应补给元件, // 开局导能元件选择可选 equipment: [ // 开局装备选择横着数可选 // 当前版本暂未实现只会在界面上显示一下 A, A, A, A, B, B, B, B ], strategy: 优选策略, // 或者 自由策略可选 // 当前版本暂未实现只会在界面上显示一下 opers: [ // 指定干员可选 { name: 棘刺, skill: 3, skill_usage: 1 } ], groups: [ // 干员编组可选用法同 copilot 协议中的 groupsactions 中的 name 可以填编组名 { name: 地面阻挡, opers: [ { name: 棘刺, skill: 3 }, { name: 泥岩, skill: 2 } ] } ], tool_men: { // 剩余所需各职业人数按费用排序随便拿必选 // 当前版本暂未实现只会在界面上显示一下 Pioneer: 13, 近卫: 2, // 中英文均可 Medic: 2 }, drops: [ // 战斗开始时和战斗中途招募干员、获取装备优先级 空弦, 能天使, // 支持干员名、职业名 先锋, // 职业名中英文均可 Support, 无需增调干员, // 不招人 重整导能组件, // 支持装备名全写一起.jpg 反制导能组件, 战备激活阀, // 关卡中途的可选装备也放这里 改派发讯器 ], blacklist: [ // 黑名单可选。在 drops 里不会选这些人。 // 后续版本支持编队后编队工具人也不会选这些人 夜半, 梅尔 ], stages: [ { stage_name: 蜂拥而上, // 单层关卡名必选 // 支持 name, stageId, levelId推荐 stageId 或 levelId // 请勿使用 code例如 LT-1因为会和其他保全关卡冲突 strategies: [ // 必选 // 每次检查都会从头自上而下依次进行并跳过执行完毕的策略 // 若当前策略的工具人已经部署完毕 // 若没有 core则认为此策略执行完毕 // 若有 core 且可以部署则部署 core 并认为策略执行完毕 // 若有 core 正在转费用则等待并跳过后续策略 // 若当前策略的工具人还未部署完毕 // 若部署区没有所需工具人则检查下一条策略 // 若部署区存在所需工具人 // 若没有能立即部署的则等待 // 若存在能立即部署的则优先部署费用少的 // 对于同一格的策略 // 若没有 core则允许在待部署区没有所需工具人时不论费用是否转好允许继续检查同一格后续策略 // 若有 core则没有执行完毕时忽略同一格后续策略 // 同一格可以写多个干员 core非最靠后的干员 core 在其策略执行完毕后等效过牌不计入工具人 { core: 棘刺, tool_men: { Pioneer: 1, // 中英文均可 Warrior: 1, Medic: 1 }, location: [ 10, 1 ], direction: Left }, { core: 泥岩, tool_men: { Pioneer: 1, Warrior: 1, Medic: 1 }, location: [ 2, 8 ], direction: Left }, { // 不填写 core可以用于部署辅助过牌的之类的 tool_men: { Support: 100 }, location: [ 2, 8 ], direction: Left } ], draw_as_possible: true, // “调配干员”按钮是否好了就用必选 actions: [ // 可选 // 基本复用抄作业的逻辑可参考 protocol/copilot-schema.md // 符合 action 的条件就执行 action否则执行上面的 strategies 的逻辑 { type: 调配干员 // 新 type“调配干员” 按钮点一下在 draw_as_possible 为 true 时无效 }, { type: CheckIfStartOver, // 新 type检查干员在不在不在就退出重开 name: 棘刺 }, { name: 桃金娘, location: [ 4, 5 ], direction: 左 }, { kills: 10, type: 撤退, name: 桃金娘 } ], retry_times: 3 // 战斗失败重试次数可选默认为 0超过了直接放弃整局 }, { stage_name: 见者有份 // ... } // 写几关打几关比如只写到了 4则打完 4 自动重开 ] }三、顶层字段逐项说明含源码佐证3.1 基本信息与版本约束type、stage_name、minimum_required、doc均由 copilot 的基础信息解析逻辑统一处理SSSCopilotConfig.cpp 中parse()先调用CopilotConfig::parse_basic_info(json)解析出BasicInfo对应 AsstBattleDef.h 中的stage_name、minimum_required、title、title_color、details、details_color随后解析groups。doc中的title/details用于界面展示适合署名与贴攻略链接。3.2 buff / equipment / strategy / opers开局选项buff解析后若非空会写入SSSBuffChooseOCR 任务作为开局元件选择候选见 SSSCopilotTask.cpp是实际生效的字段equipment解析时只接受A/B大小写均可且长度不为 8 会输出equipment size is not 8警告SSSCopilotConfig.cpp如文档所述当前版本暂未实现开局装备的实际选择仅解析保存strategy优选/自由策略与顶层opers同样解析或仅用于展示当前版本未参与实际决策。3.3 groups编组语法复用 copilotgroups由CopilotConfig::parse_groups解析SSSCopilotConfig.cpp并在每关解析时下发给该关的CombatDatastage_data.groups m_data.groupsSSSCopilotConfig.cpp因此strategies/actions里的name均可填编组名用法与 copilot 协议 完全一致编组内干员任选其一优先选练度高的。3.4 tool_men整局职业配额顶层tool_men通过parse_role_counts解析为职业人数表中英文职业名均可。按文档说明当前版本它只在界面展示从源码看配套的自动编队任务BattleFormationTask虽然被挂入了任务链但 SSSCopilotTask.cpp 中AdditionalFormation相关代码被注释并显式set_enable(false)“暂时不支持自动编队”与文档描述互相印证。3.5 drops / blacklist中途增调优先级drops被原样存入order_of_dropsSSSCopilotConfig.cpp战斗开始与半程补给时按此优先级招募干员、获取装备。战斗中的具体执行在 SSSBattleProcessTask.cpp 的check_and_get_drops()先识别半程补给界面SSSHalfTimeDropsBegin若drops为空数组执行SSSHalfTimeDropsCancel直接取消增调否则把drops全列表写入 OCR 任务SSSHalfTimeDrops的候选文本按列表顺序 OCR 匹配并点击——这也解释了为什么列表里可以混写干员名、职业名、装备名如Support、反制导能组件匹配到哪个选哪个无需增调干员则对应界面上的不招募按钮。blacklist存入CompleteData::blackliststd::unordered_setstd::stringAsstBattleDef.h。按文档说明其作用是让drops选择不命中这些干员后续支持自动编队后同样会排除这些“工具人”。四、单关字段stages 与 strategies 判定规则4.1 stage_name 的解析与匹配每关的stage_name支持 name、stageId、levelId推荐 stageId/levelId文档特别强调不要使用 LT-1 这类 code因为会与其他保全关卡冲突。源码中对应机制是解析时通过Tile.find(stage_name)查询该关对应的屏幕显示名ocr_code并以显示名为 key 存入stages_dataSSSCopilotConfig.cpp。运行时 SSSStageManagerTask.cpp 的analyze_stage()用 OCR 任务SSSStageNameOCR读取屏幕关卡名再与stages_data的 key 做精确匹配——匹配不到时程序会判定为通关界面报SSSGamePass或走结算退出。这就是“写几关打几关”的实现写到第 4 关为止第 5 关的名字不在 JSON 中本局即自动结算放弃。4.2 strategies 的判定语义strategies是 SS 协议的核心按数组顺序自上而下逐条检查跳过已完成的策略规则与文档注释一致。SSSBattleProcessTask.cpp 的check_and_do_strategy()实现了完整决策可逐条印证文档中的规则跳过已完成策略strategy.all_deployed为真直接跳过对应“跳过执行完毕的策略”同格互斥用loc_with_strategy记录已有未完结策略的格子后续同格策略被跳过但只有带 core 的策略在等待时才会占用该格if (strategy.core.has_value()) loc_with_strategy.emplace(...)不带 core 的策略在待部署区没有所需工具人时会继续检查同格后续策略——与文档“若没有 core则允许继续检查同一格后续策略”逐字对应core 优先部署当 core 在待部署区、且该策略的tool_men全部部署完时use_the_core若 core 费用已转好则立即部署并标记all_deployed若 core 还在转费用则return false原地等待并阻塞后续策略对应“若有 core 正在转费用则等待并跳过后续策略”工具人部署若tool_men未满则从待部署区找一个职业匹配且费用已转好的干员部署同时确保不会把其他策略的 core 当工具人点掉!m_all_cores.contains(oper.name)部署的工具人技能会被统一设为“好了就用”SkillUsage::PossiblySSSBattleProcessTask.cpp等待语义待部署区存在所需职业但都在转费用时返回 false 等待都不存在时检查下一条策略。另外文档中“同一格可写多个干员 core非最靠后的干员 core 执行完毕后等效过牌”的设计与源码中部署 core 后将其从m_all_cores移除SSSBattleProcessTask.cpp的行为一致已部署的 core 不再受后续策略约束。4.3 draw_as_possible该字段必选对应“调配干员”按钮。在战斗主循环 SSSBattleProcessTask.cpp 的do_strategic_action()中每轮检查完 drops、strategies 与“好了就用”技能后若draw_as_possible为 true 就尝试点一次SSSDrawCard无重试、零延迟的轻量检查。开启后动作列表中显式的{type: 调配干员}就不再需要——文档亦注明其“在 draw_as_possible 为 true 时无效”。4.4 actions复用 copilot 两个 SSS 专属 type单关actions基本复用 copilot 协议 的操作逻辑部署/技能/撤退/二倍速/条件kills/costs/cost_changes/elapsed_time等均同前。执行顺序是符合 action 条件就执行 action否则执行 strategies 逻辑。SS 协议新增了两个 type在 SSSBattleProcessTask.cpp 的do_derived_action()中分发调配干员DrawCard点击“调配干员”按钮并刷新待部署区识别CheckIfStartOver检查干员是否还在场上或待部署区不在则放弃本局重开。SSSBattleProcessTask.cpp 中check_if_start_over()的实现是name指定时在待部署区与战场上都找不到该干员即调用abandon()也可用role_counts校验某职业人数不足。常用于开局几秒内确认关键干员如指定 core没有被随机换走。4.5 retry_times整局容错retry_times可选默认 0。SSSStageManagerTask.cpp 的preprocess_data()将其转换为每关的可用次数retry_times 1即含首战主循环 SSSStageManagerTask.cpp 中某关战斗结束后计数减一次数耗尽则回调SSSSettlementwhy: Cant win, run!并走结算流程放弃整局。五、战斗执行链路从 set_params 到逐关推进5.1 任务链组装SSSCopilotTask.cpp 的构造函数展示了完整子任务链SSSBeginSSSStartFighting进入保全派驻并点击开战含选地图、选元件SSSBuffChoose等界面流程BattleFormationTaskDataResource::SSSCopilot自动编队占位当前被禁用SSSTeamConfirmSSSStartFighting确认编队再次开战SSSStageManagerTask阶段管理主循环注册了SSSDropRewardsTaskPlugin处理干员掉落奖励。set_params还支持loop_times参数默认 1大于 1 时把上述子任务链整体复制多份顺序执行SSSCopilotTask.cpp即连打多局。5.2 开局自动换人进入战斗前的wait_until_start()SSSBattleProcessTask.cpp实现了一套开局预选替换逻辑属于源码层面的实用细节默认最多替换 4 人费用阈值 29费用低于该值不替换若场上先锋少于 2 个阈值降为 25试图换出先锋保证费用运转待部署区若出现“超重绝缘水泥”这类 Drone 装置直接丢弃不计入替换数若作业中指定了“超重绝缘水泥”为 core则只额外换 1 人防止把它换掉。5.3 战斗主循环的帧率与轮询节奏do_strategic_action()每轮依次做四件事check_and_get_drops半程补给→check_and_do_strategy格子策略→use_all_ready_skill全场“好了就用”技能→ 按draw_as_possible尝试调配干员SSSBattleProcessTask.cpp。两个值得注意的工程细节帧率限制每轮截屏间隔受Config.get_options().sss_fight_screencap_interval控制毫秒级限帧防止空转占满 CPU可在 MAA 配置中调整自适应轮询间隔update_deployment_with_skip()在连续 30 秒待部署区无变化时通常进入挂机阶段把识别间隔拉大到 1 秒有变化则立即恢复 0 间隔SSSBattleProcessTask.cpp。5.4 阶段管理逐关识别与结算SSSStageManagerTask.cpp 的_run()主循环是整局骨架等待战斗结束SSSConfirmBattleComplete → OCR 识别当前关卡名SSSStageNameOCR ├─ 识别失败若处于开始界面 → 报 SSSTask SSSGamePass通关 │ 否则 → 报 SSSTask SSSSettlement识别错误或 JSON 不支持该关并结算退出 └─ 命中 stages_data扣减重试次数 → 点击开始SSSStartFighting / SSSTask SSSTask SSSTask SSSTask SSSTask SSSTask → 运行 SSSBattleProcessTask 打本关 → 回到循环顶部识别失败的回调文案Recognition error or JSON does not support this.也再次说明JSON 里没写的关卡会被视为“不支持”程序主动结算本局。六、编写协议的建议清单必选字段别漏顶层type、stage_name、minimum_required、tool_men每关stage_name、strategies、draw_as_possible关卡名用 stageId/levelId避免 LT 系 code 冲突stages按实际出关顺序书写写多少关就打算打多少关strategies 设计关键位写core 少量tool_men按职业配额而非指定干员容错性最好纯工具位可不写 core同格多 core 时把主力放最后drops 优先级把最想要的人/职业/装备放最前无需增调干员放在不想招人的场景不想见的干员进blacklist稳定性兜底给易翻车的关键关设置retry_times开局用CheckIfStartOver检查关键干员actions里可用kills等条件插入撤退、加速等操作命名与署名doc.details中写明作者与攻略出处方便社区追溯。参考文件协议文档docs/zh-cn/protocol/sss-schema.md、docs/zh-cn/protocol/copilot-schema.md协议解析src/MaaCore/Config/Miscellaneous/SSSCopilotConfig.cpp任务入口与参数src/MaaCore/Task/Interface/SSSCopilotTask.cpp战斗执行src/MaaCore/Task/SSS/SSSBattleProcessTask.cpp、src/MaaCore/Task/SSS/SSSStageManagerTask.cpp数据结构src/MaaCore/Common/AsstBattleDef.h【免费下载链接】MaaAssistantArknights《明日方舟》小助手全日常一键长草| A one-click tool for the daily tasks of Arknights, supporting all clients.项目地址: https://gitcode.com/GitHub_Trending/ma/MaaAssistantArknights创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考