开源LoopX：长程Agent状态管理，狂跑200小时不跑偏
内容提要
LoopX 是字节工程师开源的长程 Agent 控制平面，运行在 Codex、Claude Code 之上，通过独立状态层持久化目标、证据与配额，防止 Agent 多轮后跑偏。它跨运行时保留状态，适合开发研究，不适合生产运维。
延伸解读
跨运行时状态持久化的独特价值
LoopX 的核心差异在于跨运行时的状态持久化。与 ZCode 或 Claude Code 的会话级目标管理不同，LoopX 将目标、证据和配额存储在本地 .loopx/ 目录，独立于任何 Agent 运行时。这意味着你可以在 Codex 中启动任务，然后在 Claude Code 中继续，状态不会丢失。对于需要切换工具或长期迭代的开发研究场景，这避免了重复配置和上下文重建，但前提是接受其本地优先、不传云的设计。
配额系统如何防止无效消耗
LoopX 的配额系统通过为每个目标分配计算配额，控制 Agent 何时可以消耗计算资源。每个回合，Agent 需通过 loopx quota should-run 检查是否应当运行，执行后通过 loopx quota spend-slot 记录已验证的切片。当有效配额归零，调度器会通知宿主停止自动化。这解决了定时器驱动下 Agent 在无进展时仍持续烧钱的问题，但配额仅管理计算分配，不涉及人类奖励、写权限或生产许可。
200小时的真实含义与局限
README 中提到的 200+ 小时是项目挂钟时间，而非模型连续运行或无人看管的自主运行。两条公开轨迹跨越 220.7 和 272.9 小时，期间包含多轮执行、等待、人工判断和模型切换。LoopX 证明的是 Agent 能在这些中断后找回目标、证据和下一步，而非完全自主。此外，SWE-Marathon 基准显示更多自验证行为并未稳定提升得分，且每个任务仅运行一次，不足以证明普遍性能提升。
适用边界与当前限制
LoopX 明确不适用于生产运维，不授予凭证、不批准破坏性操作、不代替用户发布。它适合开发和研究场景，尤其是需要长程状态管理的任务。对于单轮问答式使用，其开销远大于收益。当前 v0.4.x 阶段，核心稳定部分仅限于 CLI 契约和状态管理，宿主集成支持级别参差不齐，Claude Code 需 opt-in 适配器，Codex App 最成熟。Explore 和部分高级路径默认关闭或实验性，多 Agent 编排需手动配置。
Q&A
LoopX 是什么？它主要解决什么问题？
LoopX 是字节跳动工程师开源的长程 AI Agent 控制平面，运行在 Codex、Claude Code 等运行时之上。它通过独立状态层持久化目标、证据与配额，解决 Agent 多轮后跑偏的问题。
LoopX 的配额系统是如何工作的？
每个目标分配一个计算配额数字，Agent 每回合通过 loopx quota should-run 检查是否应当运行，执行后通过 loopx quota spend-slot 记录已验证的切片。当有效配额归零，调度器会通知宿主停止自动化。
LoopX 和 ZCode、Claude Code 的长任务功能有什么不同？
ZCode 是完整的桌面 Agent 环境，绑定自家运行时；Claude Code 的 /goal 是会话级别，关掉窗口就失效。LoopX 是 Provider-neutral 的本地控制平面，运行在多个 Agent harness 之上，跨运行时保留状态，切换 Agent 后目标、证据和下一步不丢失。
LoopX 的 200 小时是指模型连续运行 200 小时吗？
不是。200+ 小时指的是项目从第一个 PR 到最后一次更新的挂钟时间，包含多轮执行、等待、人工判断、模型切换和任务恢复，并非模型连续运算或无人看管的自主运行。
LoopX 适合哪些场景？不适合哪些场景？
适合开发和研究场景，尤其是需要跨回合保持状态的长程任务。不适合直接挂在生产流水线上做自动运维，也不适合单轮问答式场景，因为开销远大于收益。
LoopX 的架构中四个角色分别负责什么？
Agent 负责规划并执行有界动作，Provider 负责调用外部系统，Capability 负责规范化和验证输出，Kernel 负责持久化状态。执行路径是 Agent→Capability→Provider，控制路径反向回来。
