EvoX 跑长任务时在中途改目标，通常不会在“一定重排计划”和“完全沿旧路径走”之间二选一；EvoX 更可能在下一个检查点、步骤边界或重试点才响应。判断依据不是猜测任务引擎的意图，而是把改目标前后的执行记录按时间排开，看任务列表、当前步骤和被放弃步骤是否变化。若目标变更只进入上下文而没有触发计划重建，旧路径就会继续推进。
适用场景是 EvoX 长任务已有计划列表或执行日志可查。操作动作：在任务中段按时序改目标、加约束，分别保存变更前后快照；验证方式是比时间戳、任务列表变化、被放弃步骤，而不是只看页面提示。通常只有出现计划生成、步骤替换或取消记录，才说明发生了重排；否则更接近沿旧路径执行。风险边界：异步日志和批量落盘可能延迟，单次短窗口观察不足以定论，需结合多个检查点确认。
用一条脚本按时序改任务目标，观察计划是否更新
先做一个最小复现：启动一个会持续多步的 EvoX 长任务，在任务进入中段后改目标，不改其他输入，然后等待到下一个检查点。若环境提供程序化入口，用下面的通用骨架；其中 start_long_task、query_plan、update_goal、update_constraints、tail_log 都是占位名，需要替换成实际可用的命令、SDK 方法或页面操作。接入点 A 是目标或约束更新，接入点 B 是计划或任务状态查询，接入点 C 是执行记录导出。
# 通用时序复现骨架：字段名和调用方式按 EvoX 实际环境替换
# 接入点 A：目标更新与约束更新入口
# 接入点 B：任务状态、计划步骤、当前步查询入口
# 接入点 C：执行日志或记录导出入口
def snapshot(tag, task_id):
plan = query_plan(task_id) # 接入点 B：步骤列表、当前步、状态
log = tail_log(task_id, n=200) # 接入点 C：最近执行记录
return {'tag': tag, 'time': now(), 'plan': plan, 'log': log}
task = start_long_task(goal='旧目标', constraints=['旧约束']) # 接入点 A
rows = [snapshot('start', task.id)]
wait_until(task, condition='进入中段或完成若干步骤') # 观察点按环境调整
rows.append(snapshot('before_goal_change', task.id))
update_goal(task.id, new_goal='新目标') # 接入点 A：改目标
wait_until_next_boundary(task) # 等待检查点或步骤边界
rows.append(snapshot('after_goal_change', task.id))
update_constraints(task.id, add=['新增约束']) # 接入点 A：加约束
wait_until_next_boundary(task)
rows.append(snapshot('after_constraint_add', task.id))
dump_json(rows, 'evox_change_timeline.json') # 接入点 C 或本地保存如果没有可用的程序化入口，就在界面按同样时序手动操作：启动长任务，等任务进入中段，先记录当前步骤和时间，再改目标，等一个检查点后再记录，最后新增约束并再记录。每次只改一个变量，否则改目标和加约束混在一起，后面的记录无法区分是谁触发的。建议至少跨两个检查点观察，避免把日志延迟误判为任务不响应。
在执行记录里找计划重排的痕迹
执行记录里不要预设字段名，只按记录类别核对。把快照按时间排序，先定位“改目标”或“加约束”的写入时间，再看该时间之后第一条计划相关记录。重排通常会在任务列表上留下新增、删除、重排或当前步替换；沿旧路径则更多是列表不变、当前步继续、旧步骤依次完成。
| 核对类别 | 更像计划重排的痕迹 | 更像沿旧路径执行的痕迹 |
|---|---|---|
| 时间戳 | 变更时间点后不久出现新的计划生成、步骤替换或取消记录 | 只有变更记录，后续步骤时间戳仍按旧节奏推进 |
| 任务列表变化 | 待执行步骤增加、删除、重新排序，或当前步被换掉 | 任务列表基本不变，当前步继续，旧步骤仍被执行 |
| 被放弃步骤 | 旧路径中未执行步骤出现取消、跳过、失效等状态 | 没有取消或跳过记录，旧步骤继续等待或完成 |
验证时可以先只搜步骤名差异：变更前计划里有、变更后计划里没有的步骤，通常是被放弃或替换的候选；变更后新增且排在当前步之后的步骤，通常是重排产物。风险边界是记录可能异步落盘，或只保留摘要，看到短窗口无变化时不要直接下“沿旧路径”的结论，需要等到下一个检查点再看一次。
对比改目标和加约束两种输入
改目标和加约束是两种不同输入。改目标改变的是任务要达成的结果，加约束限制的是允许怎么达成，因此两种输入触发的行为可能不同。下面的“典型触发行为”需要结合 EvoX 实际配置确认，不能只凭一次页面刷新判断。
| 输入类型 | 可能触发的行为 | 相同点 | 不同点 |
|---|---|---|---|
| 改目标 | 可能重建计划、替换当前步，或只更新上下文直到边界 | 都会先记录变更，通常不会回滚已完成步骤 | 改目标更容易改变步骤集合和优先级，旧路径可能被放弃 |
| 加约束 | 可能保留步骤列表，插入校验、过滤或参数调整，也可能只影响后续决策 | 都依赖检查点生效，都能在日志中留下变更记录 | 加约束通常不替换最终目标；若与旧路径冲突，可能局部改道或提前失败退出 |
记录时建议固定四列：输入类型、变更时间、下一检查点时间、计划是否变化。然后补两列：被放弃步骤、任务是否继续。这样改目标和加约束的行为差异就能落到可核对的变更时序记录表上。如果只改目标就出现步骤替换，而只加约束只出现校验记录，说明两类输入在 EvoX 中的处理路径不同；如果两者都只留下变更记录而没有计划变化，就要怀疑响应发生在更晚的边界，或者该入口没有触发重规划。
把观察结果写成团队的使用约定
把上面的观察写成团队约定，重点不是争论 EvoX 一定重排还是沿旧路径，而是规定人在哪些节点必须确认目标，避免任务在旧路径上跑远。可以先用一条保守约定：长任务在启动后首次计划生成前、进入新阶段或里程碑前、长等待或外部依赖返回后、重试或恢复前、成本或步骤数接近阈值前，以及任何目标或约束写入后，都必须人工确认目标是否仍然有效。
变更后要重新检查这些内容：当前计划步骤列表是否还覆盖新目标；当前步是否应继续；待执行队列里哪些步骤应取消或替换；已完成产物是否还能复用；日志中是否出现取消、跳过或失败退出；外部副作用、预算和时限是否需要调整。操作上，把确认结果追加到同一份变更时序记录表，写明确认人、触发节点和结论。若记录显示目标变更后没有计划更新，建议先暂停推进到下一检查点，再手动确认，而不是默认任务已经重排。