200小时？真的假的
先给结论：真的，但不是你想的那种真。
LoopX 官方 README 白纸黑字写着：两条轨迹各跨了 200+ 小时的 elapsed loop lifetime。但人家原话也说得很清楚，elapsed lifetime 是 wall-clock project time，也就是墙钟项目时长。按 24 小时算，200 多小时差不多是 8 天多；实际是跨很多天、每天跑几轮、中间有人看有人改、有评审往返。不是 AI 连轴转 200 小时不眠不休，也不是无人值守跑了 200 小时。官方自己也在强调：LoopX 不是自主生产控制器。
先把最大的误解拆了，再说这个项目到底干了什么。
热词「Loop」跟 LoopX 是什么关系
2026 年 agent 圈最热的词之一就是 loop engineering——Anthropic 那帮人（Claude Code 的核心人物 Boris Cherny 等）带起来的。不再是逐个提示词催 agent，而是设计一个循环让 agent 自己跑：收集上下文 → 行动 → 验证 → 重复，直到目标达成或者停止条件触发。
LoopX 的「Loop」就来自这。它是 loop engineering 的工程化——给这个循环加一层持久状态内核，一个轻量控制平面。
大白话：大家都开始让 AI 自己循环跑活了，但跑起来发现没人记账。LoopX 就是那个记账的。它管六样东西：目标（objective）、闸门（gates）、待办（todos）、范围（scope）、证据（evidence）、配额（quota）。模型执行还是 Codex、Claude Code、Cursor 那套，LoopX 不碰，只管活儿的状态。
Claude Code 有原生 /loop 命令，LoopX 给了个适配器，/loopx 进去再 /loop 就能用。Codex、Cursor 也支持。
一句话总结：Loop 是圈里正在流行的词，LoopX 是把这个词变成可治理工程的个人开源项目。
AI 长跑的三个死法
长跑任务翻车，我见过太多了，死法就那么几种。
第一种，目标漂移。干着干着忘了最初要干嘛。第一天说修登录 bug，第三天开始重构数据库，第五天在调 CSS——每轮对话都是新上下文，AI 只记得最近说的，目标早就丢在几十轮之前。
第二种，证据过期。上一轮查到的东西，下一轮没人知道。跑了个测试发现方案 A 不行，换了新会话，AI 又兴冲冲地推荐方案 A。查过的资料、试过的错、验证过的假设，全在对话历史的马桶里冲走了。
第三种，预算无底洞。API 一烧起来没有刹车。循环跑得越欢，钱烧得越快，没人踩刹车。跑完一看账单，够买台新电脑。
这三个死法不是模型漂不漂的问题。模型该漂还得漂，但真正让长跑崩盘的，是状态没人管。
解法：记账本 + 人在环上
LoopX 的做法朴素得有点土，但管用。
模型每次只干一小段，有界轮次。干完把目标、待办、证据、花了多少钱，全部写进本地账本（state kernel）。下次接着干，先翻账本再动手。
断了能续。中途进程崩了？翻账本接着来。换了 AI 工具能接。今天用 Claude Code 跑了几轮，明天换 Codex 接手？账本里啥都有。
烧钱有预算闸。quota-aware auto-wake，预算决定下一 tick 跑不跑，不给调度器无限花钱的机会。
人在环上，这是关键。危险权限、发布、生产写入、最终所有权，全留在人手里。官方原话：LoopX is not an autonomous production controller。它不会自己拍板上生产。
还有个细节挺有意思：官方说「board is a projection; LoopX state remains the source of truth」——看板只是投影，LoopX 状态才是真相源。这跟很多人的直觉相反。看板是给人看的，状态是机器记的，哪个算数？机器记的那个。
两个 200 小时案例，如实说
官方 README 给了两条轨迹。
第一条，OpenViking Issue-Fix。huangruiteng 以贡献者身份在 volcengine/OpenViking 提 PR，首个 PR 创建到最近评审/更新，横跨 200+ 墙钟小时。重点是它的能力设计：把滚动仓库上下文、修订戳修复知识、面向 reviewer 的偏好分开维护——不同类的信息，放进不同的抽屉，不混。
第二条，Auto ML Experiment。owner 自己跑的一个实验弧：假设 → 配对证据 → 无效谱系保留 → 复现批次 → promote/stop 门。决策谱系跨轮可见，哪个假设死了、为什么死的、证据在哪，全在一张图里。
注意边界：这俩都是作者本人/owner 自运行，不是第三方客户案例。没有外部背书，如实看。
判断：方向是真的，项目是早期
AI 长跑正在从「赌模型不犯错」变成「工程上管得住状态」。这个转向是实打实的。你不可能指望一个模型 200 小时不漂移，但你可以设计一个系统，让漂移的代价可控、让恢复成为常态、让预算有刹车。控制平面是下一波 Agent 工程的地基话题，不是可选项。
LoopX 本身呢？个人开源项目，MIT，Python 3.11+，~319 stars，v0.4.x 早期可用。状态和 CLI 契约是稳定核心，部分宿主集成/高级路径还得看文档。值不值得上生产？另说。但「长跑要人管状态」这个方向，是真的。
长跑不缺引擎，缺的是仪表盘和账本。账本先记起来，跑多久都不怕。
来源清单（按需查阅）：
- GitHub：《LoopX 官方仓库（huangruiteng/loopx，MIT，README 与 Evidence 段）》
- LoopX 项目：《托管前端/展示面板（loopx frontstage）》
- GitHub：《作者在 volcengine/OpenViking 的贡献者 PR 列表》
- Anthropic：《Building Effective Agents（官方工程指南）》
- Anthropic：《Claude Agent SDK Guide / 长跑 Agent 工程文档（loop engineering 相关）》