为什么 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 最常在哪一种变化后继续执行旧计划：外部事实改变、等待太久、目标没有达标，还是用户反馈改变边界？

开源项目 LoopX：超长程 Agent 自主运行 200+ hours，状态不漂移。 我的技术主张是：LLM 上下文有限，长程 Agent 需要外置状态，通过完备的状态管理、监督和规划，让 Agent 无人干预时跑得稳、持续有产出；有人干预时跑得更好，能吸收反馈继续演进。 两条真实 trajectory 分别跨越 220.7 / 272.9 小时，跨多轮执行、等待、人工决策、writeback 与 resume 后，整个 loop 仍能找回目标、证据和下一步。 目前 LoopX 已有 3 个 showcase：auto PR issue fix、AutoML experiment 和 auto coredump fix。 以 OpenViking 开源仓库的 PR issue fix 为例，Agent 不只是循环写代码。它需要持续理解 issue 的不同状态，判断何时开发、何时等待、何时请求 review，处理 CI、冲突和上游变化，并连续交付多个 PR。 这对应 LoopX 的 domain state 管理：领域系统决定真实状态，LoopX 负责把状态投影成下一步可执行的工作。 与此同时，Agent 还可以在干活过程中实现能力自进化。当它发现现有系统缺少某项能力时，可以提出 feature、完成开发与验证、发布新的离线或在线版本，再使用新能力继续原来的任务。 长程 Agent 天然适合自进化，“完成工作”和“升级完成工作的系统”可以在同一条长程轨迹中发生。 LoopX 把这些信息外置成结构化控制面： • Goal / Vision：目标是什么，什么不能被局部优化牺牲 • Todo / Gate：当前执行的 frontier，以及必须留给人的关键判断 • Identity / Authority：谁能 claim、writeback、approve • Evidence / Receipt：每次推进留下什么可回读证据 • Quota / Scheduler：何时继续执行，何时安静等待 • Handoff / Recovery：换模型、换会话、换 host 后如何恢复 你也可以把它理解为一块专门给 Agent 设计的可执行 Kanban。 普通看板只展示“谁在做什么”；LoopX 的状态会直接约束和驱动下一次 bounded turn，让看板本身成为执行系统的一部分。 这套系统最强的地方是通用性。它不只可以修 PR，还可以做 auto research、长期实验、自媒体运营、复杂 feature 开发和办公任务。 Agent 不再只是一次性的回答机器，而可以围绕一个人的 vision，长期工作、等待、吸收反馈、积累证据并持续演进。 LoopX 从一开始 build in public：状态协议、CLI、控制面实现和真实运行轨迹都进入了开源仓库；它也已经和 OpenViking、NoKV 等 agent infra 项目形成了开源合作伙伴关系。 我希望 LoopX 最终能放大每个人的 vision 和想象力。只要你有自己的目标、想法或技术主张，就能拥有一个全天候继续工作和探索的 Agent 系统，帮助你把愿景一点点变成现实。 欢迎试用、提 issue、贡献代码，或者用一个真实的 multi-day task 跑 LoopX。