LoopX 开源方案让 Agent 掌控长达 200 小时的长周期任务，避免失控。其四窗格终端与状态控制面设计，支持多 Agent 协作并输出中文内容，采用 MIT 协议发布。

核心亮点： 1. 长任务失控难点：目标变化、证据过期、多Agent交接等复杂情况 2. LoopX 核心设计：四窗格终端、状态控制面、判断是否需要人工介入、配额管理机制 3. 项目特点：MIT 协议开源，Python 实现，不替代现有 Agent，专注多 Agent 团队协作

（图像来源：项目仓库。四个窗格中，proposer、executor、evaluator 等角色并行推进，中文内容为它们记录的证据和结论。）

要真正让 Agent 跑完一个跨天任务，难点从来不在“启动”——麻烦往往在后面。比如目标中途发生变化、某个关键决策必须由人来决定、早期收集的证据已经过时、多个 Agent 之间需要交接，或者调度器在没有任何实质进展的情况下仍然空耗配额。这些问题，仅靠“聊天记录加定时器”的模式根本无法解决，因为它们远不止是“记住上次说到哪”这么简单。

LoopX 将这一层状态单独提取出来，构建成一个本地控制面。它出自国内开发者黄瑞腾之手，采用 MIT 协议，Python 实现，于 5 月 31 日建库，目前获得 1.5k 星标，用户手册直接挂在飞书 Wiki 上。README 顶部的一句话概括了它的立场：Keep the loop moving. Keep the judgment human.（让循环持续运转，把判断权留给人类。）

每一轮先问“该不该停下来咨询人”

它并不打算替代你现有的 Agent 运行时。Codex、Claude Code、Cursor 或命令行 Agent 原来怎么运行，接入后依然照常；LoopX 接管的是两轮之间的那段衔接。

一轮的流程从状态内核开始——目标、范围、权限、闸门、待办事项、认领与租约、证据、配额都集中于此。第一个判断不是“下一步做什么”，而是“这件事是否需要人来决定”。如果需要，就提出一个具体问题并停下等待；如果不需要，才让 Agent 去执行一个有边界的切片，执行完毕后写回三样东西：证据、交接说明和下一个待办事项。

“提出一个具体问题”这一要求被单独强调：它要的不是一句含糊的“等待负责人”，而是问题本身要具体到对方能够直接回答。这个设计看似微小，但决定了停下来的那一刻究竟是有效的求助，还是一次无人知道该如何处理的阻塞。

配额决定下一次何时唤醒

大多数“让 Agent 自行继续”的方案，续跑依赖定时器：时间一到就唤醒一轮，至于账户上还有没有额度、眼下是否有值得推进的事项，它并不关心。LoopX 将配额纳入控制面，由 loopx quota should-run 判断这一轮究竟应该交付、提问、等待、自我修复，还是干脆保持沉默。

额度耗尽时它会安静下来，恢复后自行继续。对于按量付费或受速率限制的使用者，这就省去了那些不可能产生任何有效状态转移的空转轮次——这笔开销平时不明显，但在长周期任务中累积起来相当可观。

多个 Agent 之间没有固定主导者

它面向的是 Agent 团队，而非单个 Agent。

多个注册的 Agent 彼此是同级关系，由认领（claim）、租约（lease）、任务边界、能力声明以及带类型的续接共同决定下一个该由谁动手，无需设定一个长期有效的 leader 身份。题图截图展示的正是这一模式：proposer 提出假设，executor 执行实验，evaluator 判断是否晋级，三个角色并行推进且互不阻塞。

作者给出的心智模型是一块面向长周期工作的、Agent 原生的看板：每张卡片携带身份、权限、证据和续接方式，移动卡片则对应一组经过校验的操作——认领、设闸门、监控、写回。需要注意的是，看板只是投影，真相始终保存在 LoopX 的状态中。

安装与使用

要求 Python 3.11+，安装只需一条命令，且运行时不依赖标准库以外的任何包：

curl -fsSL https://raw.githubusercontent.com/huangruiteng/loopx/main/scripts/install-from-github.sh | bash
export PATH="$HOME/.local/bin:$PATH"
loopx doctor

安装完成后，在项目根目录接入即可：

cd /path/to/your-project
loopx connect
loopx status

如果项目尚未初始化，可改用引导流程：loopx start-goal --guided --project . --goal-text "你那个长期目标"。状态保存在项目内的 .loopx/ 目录下。

对国内用户还有一个便利：它自带飞书看板适配器（loopx lark-kanban），可将待办事项和闸门投影到飞书上，让非技术人员也能了解进度。同样，投影出去的只是视图，状态权威仍在 LoopX 这边。

证据展示三条真实轨迹

README 中并非单轮演示，而是三条跨越较长时间的真实轨迹。第一条来自开源 issue 修复：作者本人作为 OpenViking 的贡献者，完成了一段 200 多小时的公开贡献弧，交付的 PR 和沉淀下来的可复用修复知识同步演进。第二条是自动 ML 实验，同样跨越 200 多小时，假设、匹配到的证据、被废弃的谱系、正在运行的重复实验以及晋级与停止的闸门，全部保留在同一张图中。第三条即为题图，多个角色在自动研究中并行迭代。

值得单独提及的是它对数字的处理方式。每次提到“200 多小时”，后面都跟着一句限定——这是墙钟意义上的项目时长，并非 200 小时连续的模型执行，也不是在宣称无人值守的生产级自治。实验那条同样注明，这属于轨迹证据，不构成连续算力、独立复现或生产结果的证明。在不少项目倾向于夸大数字的当下，这种主动收敛声称范围的做法并不多见。

几点注意事项

• • 它不是自治的生产控制器。 README 反复强调：危险权限、发布、生产写入和最终归属权都留在人手中。期望它无人值守地运行生产任务，方向就错了。
• • v0.4.x，作者自称“早期但可用”。 状态和 CLI 契约是稳定的核心，但部分宿主集成和高级路径要么可选、要么默认关闭、要么标注为实验性。
• • 证据全部来自作者本人。 三条轨迹均由其亲自跑出，README 也将“独立采用和结果证据”列入了下一步里程碑——换句话说，目前尚无第三方验证。
• • 概念数量较多。 目标、闸门、待办、认领、租约、能力、证据、写回、配额、投影，要真正上手需先花时间理解这套模型。轻的是安装，而不是心智负担。
• • 仅支持 macOS 和 Linux。 Windows 不在支持之列。

写在最后

“让 Agent 自行继续”这件事，从去年到今年出现了不少方案，大多解决的是“如何让它不停下来”——把计划写入磁盘、加一个定时器、中断后能恢复。

LoopX 关注的是另一半问题：它究竟该不该继续。目标是否依然成立、这个决定是否轮到它来做、手上的证据是否还新鲜、额度是否够用。这几项不明确，运行越久风险越大。

代价也很清晰：它引入了一整套自有概念，学习成本不低，而现有证据全部来自作者一人。但对于真正打算让 Agent 连续运行数天的人来说，“什么时候必须停下来问人”这个问题迟早需要一个答案，LoopX 至少把它当成了首先要回答的问题。

MIT 协议，1.5k 星标。仓库地址：github.com/huangruiteng/loopx。