（图源：项目仓库。四个窗格里 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 接管的是两轮之间的那段。
一轮的流程从状态内核开始——目标、范围、权限、闸门、todo、认领与租约、证据、配额都在这里。第一个判断不是「下一步做什么」，而是「这件事需不需要人来定」。需要，就提出一个具体问题然后停下等待；不需要，才让 Agent 去跑一个有边界的切片，跑完写回三样东西：证据、交接说明和下一个 todo。
「提出一个具体问题」这条被单独强调过：它要的不是挂上一句含糊的「等待负责人」，而是问题本身要具体到对方能够直接回答。这个设计看着小，但决定了停下来的那一刻究竟是有效的求助，还是一次没人知道该怎么处理的阻塞。
配额决定下一次什么时候醒
多数「让 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），可以把 todo 和闸门投影到飞书上，让不写代码的人也能看懂进度。同样，投影出去的只是视图，状态权威仍然留在 LoopX 这边。
证据给的是三条真实轨迹
README 里放的不是一轮演示，而是三条跨越较长时间的真实轨迹。第一条来自开源 issue 修复：作者本人作为 OpenViking 的贡献者走完了一段 200 多小时的公开贡献弧，交付的 PR 和沉淀下来的可复用修复知识一起演进。第二条是自动 ML 实验，同样跨越 200 多小时，假设、匹配到的证据、被作废的谱系、正在跑的重复实验以及晋级与停止的闸门，全都保留在同一张图里。第三条就是题图那张，几个角色在自动研究里并行迭代。
值得单独说的是它对这些数字的处理方式。每次提到「200 多小时」，后面都跟着一句限定——这是墙钟意义上的项目时长，不是 200 小时连续的模型执行，也不是在宣称无人值守的生产级自治。实验那条同样写明，这属于轨迹证据，不构成连续算力、独立复现或生产结果的证明。在不少项目倾向于把数字往大了讲的当下，这种主动收窄声称范围的写法并不多见。
几条要注意的
• 它不是自治的生产控制器。 README 反复申明：危险权限、发布、生产写入和最终归属都留在人手里。指望它无人值守地跑生产，方向就错了。 • v0.4.x，作者自称「早期但可用」。 状态和 CLI 契约是稳定的核心，但若干宿主集成和高级路径要么可选、要么默认关闭、要么标着实验性。 • 证据全部来自作者本人。 三条轨迹都是他自己跑出来的，README 也把「独立采纳和结果证据」列进了下一步里程碑——换句话说，第三方验证目前还没有。 • 概念数量不少。 目标、闸门、todo、认领、租约、能力、证据、写回、配额、投影，要真正用起来得先花时间理解这套模型。轻的是安装，不是心智负担。 • 只支持 macOS 和 Linux。 Windows 不在要求之列。
写在最后
「让 Agent 自己接着干」这件事，去年到今年出现了不少方案，多数解决的是「怎么让它别停」——把计划落到磁盘、加一个定时器、断了之后能续上。
LoopX 关心的是另外半个问题：它究竟该不该继续。目标是否依然成立、这个决定轮不轮得到它来做、手上的证据是否还新鲜、额度是否还够用。这几项答不上来，跑得越久风险越大。
代价也很清楚：它引入了一整套自有概念，学习成本不低，而现有证据又全部来自作者一人。但对真打算把 Agent 放出去连跑几天的人来说，「什么时候必须停下来问人」这个问题迟早要有一个答案，LoopX 至少把它当成了第一个要回答的问题。
