我该怎么改

回复 群友 6814： 先别推倒重写，也别继续加能力。沿着上一轮审查的 e4fa1e2 版本，先修“谁有权宣布任务完成”，再拆架构。下面是改造建议，不代表我已经验证过新代码。 第一步：把子动作和父目标的完成权分开 拿“获得 3 个铁矿石”举例： 移动到矿石附近 → 挖掘 → 拾取 → 检查背包。 移动完成，只能表示“走到了”，不能直接跳过整个采集目标。 让 tickTravel 只返回“进行中、成功、失败”，不再直接调用 advance。挖掘、拾取等子动作同样处理。 父目标收到子动作结果后决定下一步；只有父目标验收通过，顶层执行器才能 advance。 注意区分：单独的移动任务，到达就是完成；采集任务内部的移动，到达只是中间步骤。 第二步：堵住“失败当成功”的出口 优先处理上一轮指出的两处： extract_item 不能所有失败都放行。只有明确检测到空槽，而且当前要求是“清空槽位”时，才能当作无需操作；如果要求“取到材料”，空槽也不能算完成。 物品无法识别时，验收应返回“目标无效”，不能直接推进。 背包满、距离不足、容器失效分别返回明确原因。恢复逻辑根据原因处理，不要统一重试，更不要统一忽略。 第三步：统一成功的含义 把三个阶段分开记录： 指令已接收。 动作已执行。 目标已验证。 前两个都不能自动等于第三个。Forge ACK、工具返回成功、队列执行结束，都只是执行证据。 每种目标明确自己的验收条件。例如“再获得 3 个铁矿石”，应检查相对任务开始时增加了多少；“背包至少有 3 个”，则检查当前数量。这两种目标别混用。 验收尽量读取权威游戏状态，避免拿缓存库存或模型回复判定完成。 第四步：先补回归测试，再拆控制器 至少锁住这些场景： 走到掉落物旁边，但物品没进背包：父目标不能完成。 容器提取失败：不能直接进入合成步骤。 未知物品：必须明确失败。 收到动作 ACK，但库存未变化：不能宣布拿到材料。 技能仍在执行：isRunning 不能报告空闲。 取消后旧动作返回成功：不能继续推进已取消的任务。 先用可控的模拟结果稳定复现，再进游戏验证。这比只重跑一次 L1–L8 更容易定位问题。 第五步：按职责拆，而不是按文件长度拆 让控制器只负责调度。 规划模块：决定要做什么。 执行模块：管理当前步骤和子动作。 验收模块：判断目标是否真的成立。 恢复模块：根据失败原因选择补救、重规划或终止。 用一个明确的主状态替代 planning、reflecting、parked 等互相交叉的标志。每次切换状态统一处理进入、退出和取消，并给任务加标识，拒绝旧任务结果回写。 最后再改 Skill 选择 名称和描述匹配只用于找候选；真正执行前检查结构化的产出、消耗、工具、工作站和适用条件，完成后仍走统一验收。 最推荐你的第一个改动范围：移除子动作里的 advance、修复两处失败放行、补对应回归测试。先把“假成功”消掉，再谈更聪明的规划。