看一下loopx是什么有啥功能，这作者天天在x上吹牛逼

Joye，我看了它的仓库、功能文档和作者的推文。结论：有实际工程内容，不是只有概念；但“能持续接着干活”和“干得更好、更省钱”是两回事，宣传里要拆开看。我没实际部署，下面是文档核查。 它是什么 LoopX 是架在 Codex、Claude Code、Pi 等 Agent 工具上面的“长期任务管理层”。 模型负责思考和执行，LoopX 负责记住：目标是什么、谁在干哪件事、上次有什么结果、现在卡在哪里、下一轮该不该继续。 它不是新模型，也不替代这些 Coding Agent。核心价值是让工作跨会话、跨重启、跨工具延续，而不是依赖一个越来越长的聊天窗口。 具体有什么功能 长期目标与断点续跑：保存目标、范围、待办、阻塞和交接状态。新一轮从结构化状态接着做，不必完全靠模型回忆聊天。 多 Agent 协作：通过任务领取、所有权和租约协调工作，记录交接及验证结果。不是简单开几个聊天窗口，也不要求永远有一个固定“总指挥”。 人工审批与安全边界：把“需要你决定什么”变成明确的阻塞项。某条任务线等审批时，可以继续其他被允许的工作，但不能因此绕过审批。 续跑与空转控制：每轮先判断该执行、等待、询问、修复还是停止，再结合宿主的循环或调度机制继续。它不只是定时发一句“继续”。 证据与复盘：记录每轮结果、验证证据和未解决的问题，让“我做完了”有可检查的依据。不过，保存了验证记录不等于验证本身一定充分。 工作台与扩展：文档列有网页工作台、任务看板、周期报告、飞书/Lark 对接，以及修 issue、探索研究、实验管理等工作流程。还有默认关闭的实验性 Reward Memory，不能直接当成已经验证的“自主进化”。 举个例子 一个修复任务跨了三天：第一天定位问题，第二天等你确认兼容性取舍，第三天换一个 Agent 继续。 LoopX 要解决的是：第三天接手者知道前面已经证明了什么、哪些方案被否决、现在获准做哪一步，以及交付要拿出什么证据。不是把“请继续”重复三天。 作者吹的部分，证据够不够？ 我找到他一条推文，明确说长任务续跑是直接价值，并用 benchmark 支持“强于 Codex /goal”。不是完全没数据，但结论要收窄： 其公开研究页报告，46 个任务上，LoopX 平均 reward 为 0.4948，原生 Codex Goal 为 0.4475，相对高约 10.6%。但文档也明确：每个任务每组只有一次有效试验，运行时间和预算不一致，不能证明同成本下更强，也不能保证普遍提升。 “跑了 200 多小时”尤其容易误读。仓库自己说明，这是项目从开始到后续更新经过的时间，不是模型连续运行 200 小时，更不是无人监管生产环境 200 小时。 另外，部分展示仍是早期设计或演练。例如“Claude 实现、Codex 审查”的那篇示例明确标注，不是完成了真实端到端验证。不能把所有文档里的流程都当成同等成熟的功能。 所以我的评价是：它认真做的是“让长任务不丢状态、能交接、有边界、可追溯”，这个问题真实存在，也有工程价值。把它说成长期 Agent 的管理基础设施，合理；直接推导成“装上就稳定自主工作、效果更强还更省钱”，目前公开证据不够。 仓库： https://github.com/loopx-project/loopx 研究结果与限制： https://github.com/loopx-project/loopx/blob/main/docs/research/README.md 我核查的作者推文： https://x.com/huangruiteng/status/2103078504653045860