LoopX：跑在任意 AI Agent 之上的长时程控制平面
AI Agent 能在一个会话里把任务做完，但把战线拉长到几天、几周就难了：目标中途会变，之前留下的结论会过期，任务在多个 Agent 之间交接时容易丢上下文，定时器还会在已经没有有效进展时继续空转。LoopX（仓库 huangruiteng/loopx）就是针对这个问题的开源项目——一个 provider 无关、有状态的长时程 Agent 控制平面。它不取代 Codex、Claude Code、Cursor 这些执行器，而是跑在它们之上，把 objective / gates / todos / evidence / quota 这类控制状态固化在独立的一层里，让长期工作可复盘、可续接、可交接。项目当前有 5.2k star、451 个 fork，最新版本 v0.5.2 发布于 2026 年 8 月 22 日，采用 Apache-2.0 许可证（v0.4.8 起，更早版本为 MIT）。
它解决的问题
单会话 Agent 之所以能用，是因为上下文短、目标清晰、跑完即止。长期工作则完全不同：目标会漂移；事实证据会过期，后续行动可能建立在过时的结论上；任务要在不同 Agent 之间交接，边界和归属容易模糊；调度器可能在已经没有有效转化时继续消耗额度。
LoopX 的判断是：聊天记忆加上定时器不足以治理这些问题。它把持久化的控制状态放进一个紧凑的独立层，而不是散落在会话记忆里。
核心机制：一组固定的控制状态
LoopX 的每一环工作都围绕同一组状态展开：
- objective：当前活跃的目标；
- gates：需要人工判断的关卡；
- todos：有顺序、有归属的待办；
- scope：明确的工作范围与权限边界；
- evidence：每一段已做完工作留下的证据；
- quota：额度与调度，决定下一次是否继续跑。
这套状态跨天、跨重启、跨 harness 保持稳定。一次循环可以概括为一个决策流：从 objective 出发，进入 LoopX 状态；如果需要人工判断，就提出一个具体问题并等待；如果有安全回退，就跑一个有界的 Agent 切片；由 harness 执行一个 turn；随后写回 evidence、handoff 和下一个 todo；最后由 quota 决定是否进入下一轮。
agent-native Kanban：把长期任务当成卡片
LoopX 给了一个便于理解的心智模型——agent-native 看板。每张卡片携带身份、权限、证据和续接信息；动作用 claim、gate、monitor、writeback 这类经过验证的算子来表达。登记在案的 Agent 彼此是对等的，由认领、租约、任务边界和类型化的续接来决定下一步由谁行动，而不需要一个持久的 leader。
看板只是一个投影，真正的权威状态始终在 LoopX 状态里。
安全边界：不做什么
LoopX 明确声明自己不是自治生产控制器。危险权限、发布、生产写入以及最终归属权都留在人这一侧。它不授予凭证，不代替人批准破坏性操作，也不会把一段未经核验的运行包装成成功证据。这一点对想在真实项目里引入 Agent 的团队来说，比功能清单更值得先看。
上手
安装要求 Python 3.11+，没有标准库之外的运行时依赖。可以从 PyPI 直接安装：
python3 -m pip install --upgrade loopx
loopx workflow-skills --install
loopx doctor
随后在项目根目录执行 loopx connect 连接项目，再用 loopx start-goal --guided 引导式创建第一个长期目标。项目对 Codex App、Claude Code、Cursor、dsh 以及自定义 runner 都提供了接入路径。
长期运行的证据
README 里给出的案例不是单轮演示。公开的 OpenViking 贡献序列和打码的 owner-run Auto ML 实验，各自跨越 200+ 小时的 elapsed 生命周期——也就是按墙钟时间算的项目跨度，明确声明不是 200 小时连续算力，也不是无人在场的自治主张。除这两条外，还记录了几个来自独立用户的案例，例如一次超过 13 小时的 C++ 精度攻关、一次四天无人干预的运行、以及一次体现为 7 个已合并 PR 的引擎重构。
结论
LoopX 把「长期 Agent 工作」从一段不可控的连续运行，变成了一组有目标、有关卡、有证据、有额度的可复盘过程。它的价值不在替 Agent 写出更多内容，而在让跑了几百小时的工作仍然能被看清、能停得下来、能换人接着做。对于正在把 AI Agent 从「单次任务工具」推向「长期数字员工」的团队，这个项目提供了一个可以直接落地的控制面起点。