为什么 40 万浏览量的 LoopX 能让 Agent 连续运行 200+ hours，却不会把错误计划坚持到底？ 技术主张：长程 Agent 的难点不是永远制定正确计划，而是能够检测计划失效，在不越权的情况下写出新的可执行前沿。 Replan 什么时候触发？LoopX 主要识别四类时机。 1. 外部事实使原假设失效 PR review 改变 public contract，CI 暴露新的兼容问题，branch / merge 出现 blocker。系统先写入 fresh evidence，证明“哪条事实变了”，再判断原路线是否仍成立。 2. 当前路线持续没有推进 一次 monitor no-change 只会 backoff、quiet、no spend；它可能只是正常等待。只有同一条 lane 连续无变化，而且当前没有可执行工作时，停滞才会形成 replan trigger。 3. 工作前沿耗尽，但目标还没有满足 Todo 看起来全关了，不代表 goal 已完成。只要 acceptance 仍有 gap、successor 缺失，或者 evidence 不足以支持 terminal，系统就必须重新生成可执行前沿。 4. 用户反馈或权限边界发生变化 用户修改目标、验收标准或 decision scope 后，旧计划可能失去继续执行的授权。系统先保留或创建 user gate，再重算仍可安全推进的工作。 触发之后，LoopX 执行一条可验证的状态迁移： external change → fresh evidence → replan trigger → authority check → bounded state delta → executable frontier → resume 这条链有四个约束： • 证据先于 Replan：失败、等待或模型的主观判断不能直接推翻计划。 • Replan 不越过权限：blocked 工作继续 blocked；Agent 只能推进不依赖该决定的安全工作，或提出具体问题。 • Replan 必须写出状态变化：保留、拆分、新增、退役、替换工作，或请求一个决定。只有“已重新规划”的 ACK 会被判定为 replan_noop，不构成 material progress，也不应 spend。 • 已有可执行工作时继续推进优先：Replan 不做周期性打断；只有路线失效、停滞或前沿耗尽时才接管下一次 transition。 以 auto PR issue fix 为例： PR checks pending → 一次 no-change：backoff，继续等待 → 连续 no-change，且没有 runnable work：触发 replan → review 又改变 contract：写入新 evidence 和 user gate → 原 successor 保持 blocked → replan 增加不依赖 gate 的安全工作 → owner decision 到达 → 在新 contract 下 resume 模型可以更换，session 可以中断，host 可以重启。下一轮仍能读回原目标、最新证据、尚未越过的权限边界，以及新的可执行前沿。 你的 Agent 最常在哪一种变化后继续执行旧计划：外部事实改变、等待太久、目标没有达标，还是用户反馈改变边界？