翻 GitHub 趋势看到 huangruiteng/loopx（https://github.com/huangruiteng/loopx），三个月不到涨到 5k+ stars。项目定位一句话：long-horizon agent control plane——给 Codex、Claude Code 这类 agent harness 提供长程状态、治理、恢复与决策，而不是替代它们。我把它读了一遍，记录核心机制、上手命令，以及哪些场景我建议绕开。
它解决什么问题
单次会话里，agent 完成任务没问题：上下文在、目标在、一次跑完。长程任务才是麻烦：目标会变、要等人拍板、证据过期、多个 agent 交接，scheduler 还可能在没有有效进展时继续烧钱。聊天记忆和定时器都顶不住——聊天记录会截断，定时器不知道目标是什么。
LoopX 的做法是把「长期不变的东西」从会话里拿出来，放进一层本地文件状态，harness 只负责执行有界的一轮（turn）。目标、gate、todo、证据、quota 都存在状态里，跨轮次、跨工具、跨 agent 稳定。
翻译成运维的话：这像给 agent 加了一套「作业调度 + 审批流 + 审计日志」，状态落盘，而不是活在模型上下文里。
核心机制
循环大致是：
需要人判断？ → 提出具体问题，等
有安全侧路？ → 跑一个有界 agent slice
否则 → harness 执行一轮
执行后 → 写回证据 + handoff + 下一个 todo
quota 决定 → 下一次 tick 是否继续
控制面分六层（见 docs/architecture.md）：Registry（登记 goal、仓库、adapter、权限来源）、Goal state（单 goal 的活动状态文件）、Run log / history（每轮报告与索引）、Status / attention queue（下一步谁该动）、Compute quota（每个 goal 允许自动消耗多少算力）。
几个值得注意的设计选择：
- quota 不是可选项。每次 tick 都受 quota 约束，没有有效迁移就停，防止空转。很多「agent 长期任务」方案只做重试、不管预算，这里把预算做成了硬机制。
- gate 是硬边界。需要 owner 决定、安全或发布审批的，状态里直接设 gate，agent 到这就停下来问人。README 反复强调：危险权限、生产写入、公开发布、最终 ownership 留在人类手里。
- 看板只是投影。官方心智模型是「agent 原生 Kanban」，但卡片移动走 claim / gate / monitor / validate / writeback 这类有类型的操作，状态文件才是事实源，UI 坏了不影响状态。
上手
Python 3.11+，直接 pip 装，标准库之外无 runtime 依赖，不用 clone：
python3 -m pip install --upgrade loopx
loopx workflow-skills --install
loopx doctor
然后 loopx connect 把项目接上（状态已存在时复用，别用 bootstrap 覆盖）。.loopx/、.codex/goals/、.local/ 必须进 gitignore，ACTIVE_GOAL_STATE、运行时 registry、日志、凭据都不能提交。
loopx status 看谁该下一步，loopx dashboard 起浏览器/PWA 看板。集成面很广：Codex App/CLI、Claude Code（/.claude/skills）、OpenCode（/.config/opencode/commands）、Pi 都有对应命令文件；OpenCode 2 走独立的常驻 worker，TUI 关了任务还能续。
它明确不做什么
- 不是 agent framework，不绑定 provider，不替代 harness——执行仍由 Codex/Claude Code 完成。
- 不是无人值守的生产控制器。README 原话：dangerous permissions, production writes, final ownership stay with the human。
我的判断
值得试的场景：你确实在跑跨天任务（issue 修复、实验、benchmark、多步重构），需要恢复点、需要中途给人看进度、需要在多个工具间接力。这类场景里「状态落盘 + 预算控制」是真需求，不是包装。
我会谨慎的场景：
- 项目太新。2026-05-31 建仓，到 8 月 5k stars、56 个 open issues，CLI 命令面和状态格式大概率还在变。接生产前先想清楚升级成本，README 里备份/迁移命令（
loopx backup-state --execute、loopx update plan）的存在本身就说明这一点。 - 案例证据强度要打折。README 的「200+ 小时」「4 天无人干预」「7 个合并 PR」主要是作者自己的 dogfooding 或用户自述，文档自己标了 evidence boundary：200+ 小时是 wall-clock 时间，不是连续执行。它证明了方向有人踩过，不等于你能拿到同样结果。
- 概念负担不低。state kernel、effect interpreter、projection、typed operator、turn 双枚举（
LoopXTurnRoute/LoopXTurnResultKind）……术语密集、文档量大。如果只是想在单会话里多跑几轮，用不上它。 - 个人项目 + 大功能面。loopx/ 下模块很多（todos.py 近 10 万字节），靠个人维护能撑多久未知。
对偏运维的读者，LoopX 更有价值的不是「让 agent 自己跑」，而是它把「给 agent 做预算、做审批、做审计」显式化了——自建 agent 服务时这套分层可以直接借用。
真要接，先 pip install loopx + loopx doctor 看当前环境的兼容性，再决定要不要把一个跨天任务挂上去；在那之前，别把 README 的案例当成你也能拿到的结果。
项目地址：https://github.com/huangruiteng/loopx （Python / Apache-2.0 / 5,213 stars，2026-05 底建仓）
成稿信息均来自仓库 README / docs / repo 元数据，未实测安装（未声明版本与真实运行结果）。