LoopX 是一个面向长程 AI Agent 的开源控制平面，由字节跳动 AML 高级机器学习工程师黄瑞腾（huangruiteng）开发，于 2026 年 5 月 31 日首次公开。它不替代 Codex、Claude Code 等 Agent 运行时，而是运行在这些运行时之上，为长时间运行的 Agent 工作提供持久状态、治理与恢复能力。
项目定位与背景
LoopX 把自己定位为“循环工程（Loop Engineering）的状态内核”。它解决的核心问题是：Agent 在多轮对话中越跑越偏——你给 Agent 下达一个任务，几小时后回来，发现它在一条完全不相干的技术路径上狂奔了 50 个回合。
LoopX 的设计口号是 “Keep the loop moving. Keep the judgment human.”（让循环持续运转，把判断留给人）。它不授予凭证、不批准破坏性操作、不代替用户发布，适合开发和研究场景，而非直接挂在生产流水线上做自动运维。
一个字节工程师花十周造了个刹车片，让AI跑200小时不跑偏
你以为AI编程助手最怕的是模型不够聪明！错了，它最怕的是跑到第40轮，忘了自己本来要干嘛！
你给Agent丢了一个任务，几个小时后回来，发现它在一条完全不相干的技术路径上狂奔了50个回合。
2026年5月31日，字节跳动AML高级机器学习工程师黄瑞腾在GitHub上开源了一个叫LoopX的项目。截至8月初，这个项目拿到2984颗星，221个fork，MIT许可证，Python 3.11以上就能跑。它干的事情说出来你可能不信——它根本不帮你写代码，只帮你管住那个写代码的AI。
管不住AI的不是模型，是状态丢了
LoopX把自己定位成“循环工程（Loop Engineering）的状态内核”。它不替代Codex或者Claude Code，而是坐在这些Agent运行时的头顶上，专门管一件事：跨回合的状态持久化。
你给Agent下任务，一个回合接一个回合地跑，问题出在哪里？目标中途改过，但没人记录为什么改；某个决定其实需要你点头，但那句请求被淹在对话记录里；上一轮说“完成了”，但拿不出任何证据。这些东西平时靠两样撑着：对话记忆加一个定时器，两样都不够。
Context window一滚动，剧情就跟着不见了。
LoopX的做法很直接：把必须活过回合交界的东西抽出来，放在一个独立的层里。目标、闸门、待办、范围、证据、额度，这些全部存到本地的.loopx/目录下，Agent每次开工前先问这一层“我现在该做什么”，收工后把“我做了什么、证据在哪”写回去。
它的架构核心是四个角色的职责分离：Agent负责规划并执行一个有界动作，Provider负责调用外部系统，Capability负责规范化和验证输出，Kernel负责持久化状态。执行路径是Agent→Capability→Provider，控制路径反向回来：Provider的读回变成Capability的类型化转换，Kernel决定接受还是不接受。
Agent永远不能直接写入治理它的状态，这就是整个设计的命门所在。
五个命令决定AI该不该干活
LoopX最狠的一个机制，是它的配额系统。每个目标分配一个计算配额数字，自动化和控制器用这个数字决定目标多久可以消耗一次Agent时间。配额只管计算分配，不管人类的奖励、写权限或生产许可。
Agent每个回合通过loopx quota should-run检查是否应当运行，执行完成后通过loopx quota spend-slot记录已经验证过的切片。整个Tick的调用就是五条命令：quota should-run决定这一轮该不该跑，todo claim认领任务，todo update更新进度，refresh-state刷新状态，quota spend-slot结算配额。
这个机制解决了一个很微妙的问题：定时器会让Agent在没有有用进展的时候继续烧钱。配额系统直接卡住了这件事——当有效配额归零，调度器就会通知宿主停止自动化。
它不是靠“主控Agent”发号施令，而是靠声明、租约和证据来通信。登记的Agent之间是对等关系，没有永久的领导身份，谁该行动由认领、租约、任务边界和类型化延续来决定。
ZCode和Claude Code都做长任务，LoopX凭什么不一样
你可能会说，ZCode 3.0也有Goal mode，能把长期目标拆成子任务，记录中间进度，会话重启后恢复工作。Claude Code也有/goal命令，设定完成条件后，一个小型快速模型在每个回合后检查条件是否满足，没满足就继续跑。
但是，ZCode是一个完整的桌面Agent环境，底层绑定了GLM-5.2模型，你用的是它的运行时、它的界面、它的权限系统，全都在它的生态里。Claude Code的/goal是会话级别的，只在当前会话有效，关掉窗口就没了。
LoopX完全不同。它是一个Provider-neutral的本地控制平面，运行在Codex、Claude Code、Cursor等Agent harness之上而不是替代它们。你在Codex里开的任务，可以在Claude Code里继续接着做，Goal状态和证据不丢。
Claude Code的支持是一个opt-in适配器，安装后运行/loopx <任务>，再运行/loop，让Claude Code的原生循环由LoopX把关。Codex App获得的是一个心跳驱动器。Cursor和其他自定义运行器手动连接就行。
LoopX的Agent注册与入职系统管控哪些Agent身份参与目标，多个Agent可以通过认领和传递任务来协作。
这就是唯一的不可替代差异：ZCode和Claude Code各自守着自家的运行时，LoopX只管跨运行时的状态。你的工作流换了一个Agent，状态不用重来。你从Codex切到Claude Code，上一轮的目标、已有证据、下一步该做什么，全部原封不动在那里等着。ZCode做得到吗？做不到。
200小时那个数字，不完全是你在想的东西
LoopX的README里最吸引眼球的数字是200+小时。公开了两条跨越220.7和272.9小时的真实任务轨迹。中文圈已经开始把这个传成“AI可以自己跑200小时”了。
实际情况是：那200小时指的是这个项目从第一个PR到最后一次更新的挂钟时间，不是模型连续运算200小时，也不是无人看管的自主运行。中间有多少回合、多少次人类介入、多少次停下来等人回答，全都算在那200小时里。LoopX的README自己加了一句限定：“Elapsed lifetime is wall-clock project time, not 200 hours of continuous model execution”。
但是，这个限定条件并没有削弱LoopX的价值。两条轨迹期间经历了多轮执行、等待、人工判断、模型切换和任务恢复，Agent仍然能找回当前目标、已有证据和下一步。这才是LoopX真正证明的事情。
实际运行中还有一项值得注意的发现。SWE-Marathon这个探索性基准在15个匹配任务上对比了5种执行模式，结果表明更多自验证行为并没有稳定转化为更高得分。LoopX自己的README也承认，SWE-Marathon每个任务每种模式仅运行一次，目前不足以证明普遍的性能提升。
这说明长程Agent的控制不光是“让它多检查几遍”的问题。在哪个节点检查、检查什么、检查后谁来拍板，这些决策的质量比检查的频率重要得多。
只有五天跨度的工作，这东西不适合你
LoopX明确声明不做自主生产控制，不授予凭证，不批准破坏性操作，不代替用户发布。它适合开发和研究场景，不适合直接挂在生产流水线上做自动运维。
如果你的Agent使用场景主要是单轮“帮我写个函数”式的问答，LoopX的开销远大于收益。它不是给你提供一个开箱即用的Agent平台，你仍然需要自己配置Codex或Claude Code。
社区里有更轻量的替代方案，比如codex-autoresearch，一个围绕Codex CLI的长任务包装器，模型干一部分活停了就自动resume说“继续”，循环直到全部做完。这种做法简单粗暴，解决的是“Agent总是自动停”的问题，但它不处理状态漂移、证据验证、多Agent协作这些更麻烦的事情。
在Agent控制平面这个细分方向上，大多数团队的做法是用GitHub Issues或飞书多维表格手动管理Agent任务状态，但这些工具缺乏对Agent回合边界、配额和证据验证的原生支持。
LoopX v0.4.x阶段的核心稳定部分仅限于CLI契约和状态管理，宿主集成（Claude Code、Cursor等适配器）的支持级别参差不齐。Claude Code走的是opt-in适配器路线，装了之后才能用，Codex App是最成熟的路径。
Explore功能和部分高级路径默认关闭或标记为实验性。如果你需要完整的离线评估和多Agent编排，还得手动开启和配置。
所有控制状态都存在.loopx/目录里，本地优先，不传云。
一个值得持续盯着的矛盾是：SWE-Marathon中受控执行比目标驱动执行效果更好，0.33对0.267。但受控执行意味着更多人工介入，而LoopX的卖点恰恰是减少你盯屏幕的时间。控制力和放手之间的平衡点到底在哪里，目前还没有足够的数据给出答案。
作者单位背景 / 黄瑞腾（huangruiteng），字节跳动AML高级机器学习工程师，OpenViking核心贡献者