LoopX：给长跑的 Agent 装一个调度中心

你让 Codex 修一个 bug，它跑了 20 分钟，改了三个文件，然后 token 用完了。你重启会话，它从头开始——不记得之前改了什么，不知道还剩哪些 todo，连为什么要这么改都忘了。

这不是 Codex 的问题，是所有 agent loop 的通病。短任务 agent 好做，长任务 agent 难做。一旦工作跨越数小时、数天、多次会话，"聊天记忆 + 定时器"这套就撑不住了：目标会变、决策会累积、证据会过期、agent 之间要交接、调度器会在没有有效转换时继续烧 token。

LoopX 这周上了 GitHub trending，干的就是这件事：给长跑的 agent 装一个本地控制平面。它不是 agent runtime，不替代 Codex 或 Claude Code，而是给这些 runtime 提供一个"状态内核"。

核心抽象：agent-native Kanban

LoopX 的心智模型是看板（Kanban），但不是给人看的看板，是给 agent 用的。

传统看板上的卡片只有标题和描述。LoopX 的卡片携带五样东西：

• identity：这张卡是谁的，归哪个 agent 管
• authority：执行需要什么权限
• evidence：已经做了什么，产出物在哪
• continuation：下一步该做什么
• quota：还剩多少预算

看板上的"移动"是经过验证的操作符：claim（认领）、gate（门控）、monitor（监控）、writeback（回写）。看板本身只是投影，LoopX 的状态层才是真相来源。

这个设计的关键洞察是：长跑 agent 的问题不是"能力不够"，是"状态丢失"。一个 agent 能在 5 分钟内完成的事，拉到 200 小时也完不成，不是因为它变笨了，而是中间的状态——目标、决策、证据、todo——没有被可靠地持久化。

200+ 小时的真实轨迹

README 里给了一个很有说服力的数据点：OpenViking Issue-Fix 和 Auto ML 两条轨迹，各跨越 200+ 小时的 loop 生命周期。

注意这不是 200 小时的连续模型执行，是墙钟时间——一个项目从启动到完成跨越的日历时间，中间有很多次有界的 agent turn、人工决策、证据更新。LoopX 的价值在于：每一次 turn 结束后，状态被可靠地保存；下一次 turn 启动时，agent 能看到完整的上下文。

这和步子哥之前关注的 Heddle 和 CodeRescue 的"颗粒度同构"原理 是同一个方向：系统优化颗粒度应该和被优化对象的颗粒度一致。长跑 agent 的工作颗粒度是"多 turn 轨迹"，不是"单次调用"——所以状态管理也必须在轨迹级别，不是调用级别。

四个关键机制

LoopX 的控制状态包含四个核心机制：

1. 门控（gates）：不是所有操作都能自动执行。危险权限、发布、生产写入、最终所有权——这些留在人手里。LoopX 在 agent turn 之前检查门控，如果需要人工判断，就提出一个具体问题并等待。

2. 配额感知（quota-aware）：agent 不能无限烧 token。LoopX 跟踪每个 turn 的预算，配额耗尽就暂停，等下一次唤醒。这解决了"调度器在没有有效转换时继续烧 token"的问题。

3. 证据日志（evidence logs）：每个 turn 结束后，agent 必须写出证据——做了什么、产出在哪、下一步是什么。这不是可选的日志，是状态的一部分。

4. 可验证交接（verifiable handoffs）：agent 之间交接工作时，不是简单的"我干完了你接着干"，而是有结构化的交接协议——包含当前状态、已完成的工作、待完成的工作、需要的权限。

为什么是"本地控制平面"

LoopX 强调自己是 local-first 的控制平面。这有两个含义：

• 数据本地：状态在本地，不在云端。企业敏感数据、代码、内部文档不离开你的机器。
• 控制本地：LoopX 不是自主生产控制器。危险权限、发布、生产写入、最终所有权都在人手里。

这个定位很聪明。它不和 LangGraph、Temporal 这些云端编排工具正面竞争，而是做"本地状态层"——你可以用任何 agent runtime，用任何云端编排工具，但状态层用 LoopX。

和其他项目的区别

最近 agent loop 管理的项目不少，但角度不同：

• LangGraph：图编排工具，关注"怎么定义 agent 工作流"
• Temporal：通用工作流引擎，不是 agent 专用
• obra/superpowers：技能框架，关注"怎么把工程师经验编码给 agent"
• LoopX：状态内核，关注"怎么持久化 agent 的工作状态"

LoopX 的独特性在于：它不试图替代任何一层，只做状态层。这和 cloudflare/computer 的思路异曲同工——cloudflare/computer 也是只做状态层（文件系统），不做执行层。但 cloudflare/computer 是云端的，LoopX 是本地的。

一个更大的趋势

把 LoopX 放到最近几个 trending 项目里看，会发现 agent 工程正在快速分层：

• Runtime 层：Codex、Claude Code、Cursor
• 状态层：LoopX（本地）、cloudflare/computer（云端）
• 技能层：addyosmani/agent-skills、obra/superpowers
• 评估层：uber/ADR（安全观测）

每一层都在独立发展，但最终会拼成一个完整的"agent 操作系统"。LoopX 选的是最难的一层：长跑状态管理。因为短跑 agent 谁都能做，长跑 agent 才是真问题。

LoopX 的 README 里有一句话说得特别好："Keep the loop moving. Keep the judgment human."（让循环继续转，让判断留给人。）这可能是 agent 工程最简洁的设计原则——自动化一切可以自动化的，但把需要负责任的决策留给人。

项目地址：huangruiteng/loopx · Python · 327 stars today · 200+ 小时真实轨迹