📌 项目地址：huangruiteng/loopx | ⭐ 1,961 颗星 | 🔧 Python | 📜 未标注
一个会话做完的任务，不需要LoopX
单个Agent在一个会话里完成一个明确任务，这件事已经不算新鲜。真正难的是持续数天甚至数周的工作。
这类工作有几个共性：目标会变，中间需要人类拍板，证据会过期，Agent会把任务交接给其他Agent，调度器可能在没有任何有效进展之后继续消耗配额（以及金钱）。聊天记忆加定时器，管不住这种场景——会话一关，记忆跟着没；定时器一响，不管有没有进展都跑一次。
LoopX解决的就是这个问题。它是一个本地控制面，不替代你的Agent运行时。Codex、Claude Code、Cursor或者你自己写的脚本执行有界回合，LoopX维护一个紧凑的持久状态层，保证长期工作的目标、门禁、待办、范围、证据、配额在多次会话之间保持稳定。
LoopX怎么运作：一个状态流转图说清楚
README画了一张非常清晰的流转图：
objective / issue / project
│
▼
LoopX state: objective + gates + todos + scope + evidence + quota
│
├─ human judgment needed? ── yes ─▶ ask a concrete question and wait
│
├─ safe fallback available? ──────▶ run one bounded agent slice
│
▼
Codex / Claude Code / Cursor / shell agent executes one turn
│
▼
write evidence + handoff + next todo ─▶ quota decides the next tick拆开看，LoopX做的事有两层：
第一层，状态持久化。 objective（目标）、gates（门禁）、todos（待办）、scope（范围）、evidence（证据）、quota（配额）这六样东西，是整个长期工作的事实来源。Agent可以在多个会话之间轮换，但这六样东西不会丢。
第二层，流转控制。 每一步都问：需要人类判断吗？如果需要，提一个具体的问题然后等着。有安全回退路径吗？如果有，执行一个有界回合。执行完之后写证据、写交接、写下一条待办，然后由配额决定下一个tick要不要继续。
一个有用的心智模型是“Agent原生看板”：每一张卡片携带身份、权限、证据和延续信息，移动卡片是受校验的操作，包括claim（认领）、gate（门禁）、monitor（监控）、writeback（写回）。注意，看板只是一个投影，LoopX状态才是唯一事实来源——这意味着无论你用什么方式查看当前进度，最终判断依据是状态层本身。
另外，已注册的Agent彼此是对等的（peers）。谁能在哪个任务上行动，由claim、lease（租约）、任务边界、能力和类型化延续（typed continuation）决定，不需要一个持久的领导角色。这在多Agent团队里很重要：今天这个Agent在线，明天可能另一个Agent接过任务，流程不应该依赖某一个Agent的身份。
LoopX不做什么，边界反而更重要
LoopX不是自主生产控制器。README里写得很明确：危险权限、发布操作、生产环境写入、最终所有权，这些留在人类手里。
这意味着LoopX的定位是一个“让人类能在关键节点介入”的机制，而不是把所有事交给Agent自生自灭。它提供的核心能力是：当需要人类判断时，它会问一个具体问题，然后等待。不猜，不擅自推进，不假装自己有权决定。
这个边界决定了LoopX适合什么场景。README列得很具体：多日工程、研究、基准测试或实验目标；需要保留范围、证据和评审状态的Issue/PR循环；周期性心跳或监控工作；带所有者、安全、发布或私有数据门禁的项目；需要明确所有权、租约和交接的Agent团队。这些都是“单次对话解决不了”的工作类型。
证据与人类判断：不是靠聊天记录
“证据”这个概念是LoopX和普通Agent框架的一个明显分界。聊天记忆是隐式的，会话不结束就一直在，但不可追溯、不可验证、不可审计。LoopX的模式是显式的：每次Agent执行完一个回合，就把证据、交接信息、下一条待办写入状态层。这些不是模型回忆出来的内容，是运行过程中落盘的结构化数据。
这带来的一个实际好处是“可复盘”。数天的工作结束后，你可以逐回合查看：当时目标是什么，Agent做了什么，留下了什么证据，为什么进入下一个状态，哪个节点上人类介入了。这对工程研究类工作尤其有价值——跑完一个多日实验，最重要的不是最终结果，而是过程可回溯。
项目状态与入口
LoopX目前的Star数约1,961，是一个快速迭代期的项目，API有变动的可能。README没有给出具体安装命令，试用入口在项目官网的 Try LoopX 链接，文档在 https://huangruiteng.github.io/loopx/docs/。仓库里有几份值得关注的文档：docs/public-private-boundary.md 专门讲公私边界，docs/product/release-readiness.md 讲发布就绪状态——作者把这两块单独立档，说明项目在治理上不是玩具级别。
对中文使用者来说，项目提供了一份中文README和飞书用户手册，可以直接从仓库页进入。飞书手册的链接在 https://my.feishu.cn/wiki/CaL5wMk9ui17ngkWzeUcMlAYnZg。
说点实际的
我自己的判断是：LoopX的目标用户不是“所有用AI的人”，而是已经在用多个Agent做长期工作、并且被“目标漂移、证据丢失、交接混乱、配额失控”这四个问题困扰的人。
如果你只是用Claude或ChatGPT做一次性问答，LoopX对你没有任何价值。但如果你跑的是多日工程任务，或者有一组Agent在轮流处理issue和PR，那么“聊天记忆加定时器”这套方案确实不够——你需要的是一个把状态、门禁、证据、配额统一管起来的控制面，以及一个在关键节点能叫停人类、而不是自作主张的机制。
LoopX的价值不体现在单回合的Agent有多聪明，而体现在一个十天的任务跑到第七天时，你还能清楚回答三个问题：目标还一致吗？做过什么有证据吗？下一步谁来做、凭什么？