每日开源 · 第 105 期 · 早间篇
LoopX：
让 AI Agent 团队把 200 小时长程任务跑稳
不是更聪明的 Agent， 而是让多轮、多 Agent、跨会话的工作不漂移
项目速览
**2,087+**GitHub Stars
+327今日新增
Python主要语言
MIT开源协议
一句话定位
LoopX 是一个长运行 AI Agent 团队的本地控制平面。它不替代 Codex、Claude Code 或 Cursor，而是架在它们之上，把目标、门控、待办、证据、配额和交接变成跨会话、跨运行时、跨 Agent 的持久状态内核。
Loop EngineeringLong-horizon WorkAgent-agnosticHuman-in-the-loopQuota-awareCodexClaude CodeCursorOpenCode
**GitHub：**https://github.com/huangruiteng/loopx
**核心信条：**Your agents keep the night shift. You keep the judgment.（Agent 跑夜班，判断权在你。）
它能解决什么问题？
如果你让 Agent 干过跨天的大任务，一定遇到过这种崩溃时刻：
-
第 40 轮的时候，Agent 已经忘了最初的目标是什么，也忘了你之前做过的关键决策。
-
它把"等待 owner 确认"这种模糊状态，埋在聊天记录里，根本没人看到。
-
两个 Agent 同时碰同一个仓库，谁也不清楚谁拥有当前任务。
-
上一轮它声称成功了，但没有任何可验证的证据。
-
一个心跳调度器在无事可做时仍然持续燃烧 Token，直到账单来了才发现。
问题的本质不是 Agent 不够聪明，而是聊天记忆 + 定时器不是控制系统。它缺少"等待批准"、“谁拥有下一步”、"停止花费， nothing changed"这些概念。
“Most agent tooling optimizes the ten minutes a model spends thinking. LoopX is built for the two hundred hours a real project takes — and the gaps in between where nobody’s watching.”
LoopX 的解法是把控制状态外置到一个独立层：目标、门控、待办、范围、证据、配额 存在本地 .loopx/ 里，而不是塞进模型的上下文窗口。每一轮 Agent 变成一个有界切片：检查配额 → 认领待办 → 执行 → 写入证据 → 交接。
核心亮点
1. 四条角色边界：Agent 不直接写治理它的状态
LoopX 的架构由四个角色承载，这个划分是整个设计的核心：
Agent（代理）
通过宿主运行时规划和执行一个有边界的动作。Codex、Claude Code、Cursor 都属于这里。
Provider（提供者）
调用外部系统并返回观察结果和 effect 结果。
Capability（能力）
定义调用者的预期结果，规范化 Provider 返回的数据，验证它，并提出一个类型化 transition。
Kernel（内核）
拥有持久化的 todos、门控、监视器、接受的回写、配额、恢复和调度。
**执行流：**Agent → Capability → Provider
**控制流：**Provider readback → Capability transition → Kernel（接受或拒绝）
关键点：Agent 永远不直接写入治理它的状态。 Provider 的回读先变成 capability 提出的类型化转换，内核决定接不接受。
2. The Tick：五条命令驱动整个循环
LoopX 把整个交互循环压缩成五条命令：
loopx quota should-run— 这个注册 Agent 现在应该行动吗？
loopx todo claim— 谁拥有这个切片？
loopx todo update— 发生了什么变化？
loopx refresh-state— 下一轮应该看到什么？
loopx quota spend-slot— 为一个已完成、已验证的切片记账
顺序就是安全模型：配额在轮次开始前检查，花费只在验证后的 writeback 之后记录。 静默跳过、预检失败、dry-run 预览都不会消耗配额。这是防止心跳调度器乱花钱的核心机制。
3. 五个问题，五类状态
LoopX 把机制折叠成关于运行中目标的五个始终可回答的问题：
What is the objective?
活跃目标、显式范围、当前 authority
What happens next?
有序的 user/agent todos，附带 ownership、claims、leases
What needs human judgment?
具体的 user gate，而不是"等待 owner"的模糊状态
What evidence changed?
紧凑运行历史、验证、阻塞项、已接受的 writeback
May the loop continue?
配额、能力、安全回退、调度器提示、停止条件
4. Gate 是具体问题，不是标志位
这是 LoopX 与普通任务跟踪器最大的区别。门控不是一个 waiting_for_owner 标志，而是循环提出的、具体可回答的问题。
loopx status 会直接显示当前被阻塞的门控和下一个 agent todo。人类只需要回答那个具体问题，不需要从聊天记录里重建上下文。
5. Safe Fallback：P0 被阻塞，P1/P2 继续跑
当一条高优先级 lane 被人为门控阻塞时，LoopX 不会冻结整个项目，也不会让 Agent 自己决定绕过门控。它会选择一条经过审计的安全 fallback lane 继续推进。
这个设计避免了两个常见坏选择：“全部阻塞"或"让 Agent 自己决定”。状态会同时记录两件事：什么被阻塞了，以及为什么另一条路径可以安全继续。
6. Peer Agent：没有持久领导者，只有 claim 和 lease
LoopX 里的注册 Agent 是平等的。没有持久的 leader 身份，谁下一个行动由 claims（认领）、leases（租约）、任务边界、能力、类型化续接 决定。
每个 todo 有 claimed_by 字段，多个 Agent 协调而不是冲突。这对"一个 Agent 团队"来说至关重要。
7. 真实证据：200+ 小时跨会话轨迹
LoopX 的公开证据不是一轮 demo，而是三条真实轨迹，每条跨越 200+ 小时 wall-clock 项目时间（不是连续模型执行，也不是无人值守自主声明）：
-
**OpenViking Issue-Fix：**作者作为 OpenViking contributor，从首次 PR 到最新 review/update，跨越 200+ 小时，保持滚动仓库上下文和 revision-stamped 修复知识。
-
**Auto ML Experiment：**假设、匹配证据、无效 lineage、运行中的 replicate、promote/stop gate 在一个图中保持可见。
-
**Auto Research：**proposer、executor、evaluator/promoter Agent 并行迭代，todo、quota、evidence、targeted wake 全程可见。
OpenViking Issue-Fix 长程轨迹：主线 A 交付 PR，主线 B 持续改进 Agent / LoopX 能力，两者并行演进
Auto ML Experiment 轨迹：基线、结构验证、packed 路线、长程决策、审计结论与最终冠军模型，全部可追溯
8. 只读优先与公开/私有边界检查
LoopX 的检查命令默认只读。例如 loopx configure-goal –goal-id 会报告当前状态、适配性、边界和可复制命令，但除非传递 –execute，否则不对项目做任何更改。
loopx check 会扫描本地路径、凭证、私有状态，防止这些东西被意外发布。对于治理调度器是否花钱的场景，"先读"默认至关重要。
9. 与 LangGraph / CrewAI 不是同一类
LoopX 不是另一个 Agent 编排框架。LangGraph 和 CrewAI 提供执行图和运行 Agent 的方式；LoopX 提供的是跨运行持久化的目标、门控、todos、证据和配额。内核位于 Agent 之下，而不是围绕 Agent。
理论上，你甚至可以把 Pi 这种最小 harness 作为 LoopX 管理目标下的执行器——它们解决的是相邻问题，不是竞争问题。
实战场景展示
场景一：批量修 issue 的"数字员工"
你让 Agent 去修一个开源项目里的一串 issue。传统方式是开一个新会话，修完一个再开下一个，上下文不断重置。
用 LoopX：每个 issue 是一个 bounded slice，P0 是当前要交付的 focused PR，P1 是仓库知识和 terminal resume，evidence 记录 merge/open 结果和可复用发现。Reviewer authority gate 会在需要人类确认时弹出，其他 safe lane 继续跑。200 小时后，目标没有漂移，状态仍然可读。
场景二：长周期 ML 实验
跑一个需要反复试错和验证的 ML 实验。过程中会出现：基线匹配、多个候选路线、无效 lineage、需要停止或提升的 gate。
LoopX 把这些全部变成图中的节点和边：每个决策都有证据，每个候选都有状态，promote/stop gate 是具体的人类问题。即使实验跑了 200+ 小时，你也可以一眼看到"当前冠军是谁、被淘汰的路线有哪些、还需要人类决定什么"。
场景三：P0 被阻塞时的安全轮换
假设一个 benchmark rotation 有三条 lane，P0 需要下载一个巨大的本地镜像才能继续。普通做法要么是"一直重试"，要么是"整个项目暂停"。
LoopX 的做法是：把 P0 变成一个具体的 user gate（“是否下载这个大镜像？”），同时让 P1/P2 的 safe fallback 继续工作。Agent 不会被卡住，用户也不会错过关键决策，quota 也不会浪费在阻塞的 lane 上。
场景四：多 Agent 协作的产品化冲刺
LoopX 作者用自己的项目做 showcase：在 19.6 个日历日里，801 个公开 commit、570 个文件被触碰，覆盖 benchmark adapter、控制面正确性、规划和 dreaming lanes、用户/operator 面、多 Agent ownership、证据和公开边界检查。
保守估算，一个 AI 辅助的产品工程师需要 59-92 个开发日才能完成同等范围。LoopX 的结论是：这种 3-4.7 倍的日历压缩是可能的，但关键在于压缩必须是可治理的——目标、门控、todos、ownership、evidence、合并策略都可见。
上手指南
**前置条件：**Python 3.11+、curl、tar、macOS 或 Linux shell。Python 包没有标准库之外的运行时依赖。
第一步：免 clone 安装
curl -fsSL https://raw.githubusercontent.com/huangruiteng/loopx/main/scripts/install-from-github.sh | bash
export PATH="$HOME/.local/bin:$PATH"
loopx doctor
安装器会在 ~/.local/share/loopx/releases/ 放下 release 快照，在 ~/.local/bin 放下 CLI wrapper，在 ~/.codex/skills 放下可复用 agent skills。
**提示：**更新时不要盲目重跑安装脚本。用 loopx update –check、–dry-run、–execute 做显式更新。
第二步：零风险试用 demo
loopx demo
cd /tmp/loopx-demo
loopx status
loopx quota should-run –goal-id demo-goal
loopx history –goal-id demo-goal
这会创建一个可丢弃目标，含一个 user todo 和一个 agent todo。你应该看到 ok: True 和 should_run=True / state=eligible。
第三步：连接真实项目
cd /path/to/your-project
loopx connect
loopx status
如果项目还没初始化，用引导路径：
loopx start-goal –guided –project . –goal-text "Your long-running objective"
LoopX 会复用已有状态而不是覆盖。记得把这些目录加入 .gitignore：
.loopx/
.codex/goals/
.opencode/goals/
goals/**/ACTIVE_GOAL_STATE.md
第四步：让 Agent 自己接入（Agent-first 路径）
把这段提示词贴给 Codex、Claude Code 或 Cursor：
Connect the current project to LoopX. Do not clone the LoopX repository.
If `loopx` is not on PATH, install it with the official no-clone installer.
Then run `loopx doctor`. Working only from the current project root:
1. If LoopX state already exists, reuse it. Do not overwrite the goal or objective.
2. If the project is not connected, prefer `loopx connect`; use `loopx bootstrap`
only when state clearly needs initialization.
3. Ensure `.loopx/`, `.codex/goals/`, and `.local/` are ignored.
4. Set up the thin LoopX heartbeat for this surface.
5. Stop after setup and report the active state id, current user gate, top agent
todo, and next safe action.
Do not start longer delivery work in this setup turn.
第五步：日常循环
# 查看当前该谁动手
loopx status
# 查看历史
loopx history –goal-id your-project-goal
# 判断是否该自动执行
loopx quota should-run –goal-id your-project-goal
# 添加工作
loopx todo add –goal-id your-project-goal –role agent –text "Run the next bounded validation slice."
# 发布前检查
loopx check –scan-path README.md –scan-path docs/ –scan-path examples/
第六步：心跳与配额记账
loopx quota should-run –goal-id your-project-goal
loopx heartbeat-prompt –thin –goal-id your-project-goal
loopx quota spend-slot –goal-id your-project-goal –slots 1 –source heartbeat –execute
注意：静默跳过、预检失败、dry-run 不会 append spend。
不同 Host 的接入方式
**Codex App（最完整）：**让 Agent 连接项目，用 $loopx 或从 /skills 选择 loopx。心跳自动化从 quota should-run.scheduler_hint 刷新。
**Claude Code：**安装 opt-in adapter，然后 /loopx 再 /loop。Claude 原生 /loop 被 LoopX 门控。
**Codex CLI：**可见 /goal <task_body>，默认无隐藏 headless 执行。
**OpenCode：**静态 command facade，–with-goal-bridge 用于重复目标。
**Cursor / shell / custom runner：**用 installer + loopx doctor，按自定义运行器集成指南手动接线。
今日总结与互动
LoopX 不是一个更好的 Agent 循环，而是循环之上的控制平面。
当 103 期在解决"Agent 记忆"、104 期在解决"Agent 运行时"，105 期的 LoopX 在解决一个更基础也更难的问题：如何让多轮、多 Agent、跨会话、跨运行时的工作保持可治理、可复盘、可交接。
五条命令的 tick、四类角色的职责分离、200+ 小时的真实轨迹、对"无人值守自主性"的明确拒绝，都让这个项目显得 unusually honest。它不是又一个想取代人类的 Agent 框架，而是一个承认"判断权必须留在人手里"的状态内核。
对于已经在用 Codex、Claude Code、Cursor 做跨天工程任务的团队，LoopX 提供了一套可以把"数字员工"真正跑起来的脚手架。
**今日问题：**你最长让 Agent 连续跑过多久？它是在第几轮开始"失忆"或"跑偏"的？欢迎在评论区聊聊你的经验。
— 每天一个值得深读的开源项目 —
本文素材来自 LoopX 官方 GitHub README、官方网站 huangruiteng.github.io/loopx、DEV Community 深度指南、MoClaw 架构分析、explainx.ai 深度评论、苏米客中文解析，以及官方 showcase 案例。
项目地址：https://github.com/huangruiteng/loopx
