你让 AI 干一件活：重构一个模块，或者盯着一个开源项目修 issue。它答应得很好，头两天也确实在干。

然后你开始睡不踏实了。

它还在原来的方向上吗？前几天它拐进一个细节里出不来，你不确定那是不是必要的绕路。它的花费还在按点走，你不知道该不该让它继续花。凌晨两点它给你发来一句“任务完成”，你盯着这句话看了很久——你不敢信。

跑偏，烧钱，假完成。一次对话能干完的活，聊天界面就够了，这三样轮不到出场。可只要这活长过一次会话——几天，几周——它们就挨个找上门来：

谁来盯着方向，跑偏了谁拉回来？花费没有进展还照走，谁喊停？它说“做完了”，凭什么信？你中途改了主意，它怎么跟上？你出门一个星期，回来能看到什么？

这些问题的答案，不靠一个更聪明的模型。有个开源项目叫 LoopX，不替换你的 agent，只管一本账和一套规矩。它凭什么管得住，这篇从头拆。

1. Goal 只救得了目标，救不了账

写长任务的人多半听过这句反驳：Codex 不是有 Goal 吗？把长期目标写给 agent，它自己定时醒来往前推，还要什么？

这句反驳先接住一半：给长期目标这件事，Goal 真的解决了。一段目标文本写进去，agent 自己往前推，几天后你回来看，活还在干。救目标，它称职。

但长程工作难的地方，从来不是给目标。README 开篇列了五件更麻烦的事：目标会变，要等人拍板，证据会过期，活要交给同伴接手；最后一种最难看：明明已经没有有用的推进，调度器还在按点继续花钱。

README 紧跟着补了一句：Chat memory and a timer are not enough to govern that。聊天记忆，加一个计时器，管不住长程任务。

这句话正好说中 Goal 模式的天花板。Goal 加心跳，就是“聊天记忆加计时器”的组合：记忆放在对话里，推进靠闹钟。它停得很有规律：清单打完了停，步数用完了停，卡住了也停。全是操作层面的信号。而长程任务真正需要的停止，恰恰要理解这件事到底成没成。README 管这类判断叫 semantic decisions，语义性的决定——完成要能被推导出来，而不是被清单打勾出来。

Goal 和 LoopX：从记住目标到管理长期任务

漏掉的不止停止。一本完整的账上六样东西，Goal 手里只有 objective，目标文本：门禁没有，越没越过界没人管；待办没有，先干什么全靠它现场发挥；边界没有，分寸全靠 agent 自己拿捏；证据散在对话里，过没过期全凭印象；配额没有，烧多少算多少。

所以 LoopX 的位置不是替掉 Goal。README 的宿主表里，Codex App 那一行写着：心跳自动化由 LoopX 的调度刷新。宿主的 Goal 循环照跑，但每一拍要不要继续，判断权换到了账本手里。

什么样的活需要这本账？README 列了六种：跑好几天的工程、研究或实验目标；要保住范围、证据和评审状态的 issue 和 PR 循环；周期性的心跳和监控活；带 owner、安全、发布或隐私门禁的项目；对等 agent 团队，所有权、租约和交接都要算清楚；以及需要让不懂工程的人也看得懂进展的工作流。

六种活有一个共同点：都长到一句话目标罩不住。Goal 救得了目标，救不了账。那把账补上的，算个什么东西？

2. LoopX 不是新的 runtime，是控制面

README 第一行就是答案，一句加粗的定位声明：The open, provider-neutral, stateful control plane for long-horizon agents。开放的、不绑厂商的、有状态的控制面，为长程 agent 而生。

控制面这个位置，README 用三句“不是”划清：它不是又一个 agent framework，不是绑定某一家 provider 的编排 runtime，也不是自治生产控制器。

划掉的是误解，留下的是分工：agent runtime 负责干活，LoopX 负责管状态。harness 换了一茬又一茬，目标、门禁、待办、证据、配额、交接这几样稳定不动，长程工作因此可审查、可重启、可交接。

管状态的那一层有官方名字。README 的组件表第一行写着：Kernel，持有目标、待办、门禁、证据、配额、恢复、调度的真相。那本 Goal 给不了的账，在 LoopX 里叫 Kernel。

这个设计有一句最硬的注解，就在组件表上方：LoopX 把架构显式化，为的是同一个受管结果能活过 agent harness 或外部 provider 的更换。脑子可以换，账本不换，这就是控制面和 runtime 的分界。

LoopX 的位置：控制面不替代 Agent Runtime

三句“不是”里的最后一句还带一张清单：危险权限、发布、生产写入、最终所有权，留在人手里，LoopX 不碰它们的最终决定权。

剩下的事只有一件：把它接上手。

3. 人怎么开工：两条命令立规矩

把 LoopX 接到你的项目上，两条命令。

**两条命令就够，因为 LoopX 不替换你手里的干活工具。**Codex、Claude Code、Cursor，或者任何 agent harness，都照旧干活，README 的原话是 runs on top of any agent harness。LoopX 接管的不是干活，是记账和调度，开工不是装新大脑，是给已有的 agent 接一个控制面。

第一条命令：loopx connect。在项目根目录跑，LoopX 和这个项目就算接上了，随手 loopx status 看一眼。如果 connect 提示账本还没初始化，走第二条：loopx start-goal –guided，把你的长期目标用一句话交给它。

开工不只是给 AI 描述一段任务；在 LoopX 里，开工是立规矩，立完的规矩全部结构化入账。账本上立六样东西：objective（目标）、gates（门禁）、todos（要干的活）、scope（边界）、evidence（证据）、quota（花费）。你亲手写下的是目标、门禁、边界；活、证据、花费，是之后跑出来的。

门禁必须具体到动作：哪些命令要人点头、哪些文件不许动、哪类操作先停下问人。LoopX 的原话是 concrete user gates，具体的门禁，而不是含糊的“有事等我确认”。含糊的门禁等于没有门禁。

两条命令跑完，怎么知道接成了？LoopX 有一张判据清单：loopx doctor 体检通过；项目里出现 .loopx/registry.json；loopx status 能显示当前目标、具体的 user gate、下一个待办。

LoopX 复用已有账本，绝不覆盖。你重新 connect，它接着旧账继续记，不推翻重来。

所以这和给 Goal 敲一句目标，差别在哪？Goal 收下的是一段文本。这里立起来的是带门禁、边界、配额的账，从此人和 AI 的每一笔交道都要从这本账上过。

4. 三个记账人，AI 不许写账

你大概率会这样想象：Agent 在干活，干着干着顺手把“我这轮做了什么、为什么这么做”记下来，像写工作日志。

真实的 LoopX 不是这样。记账的环节里，根本没有 AI。

账本有三个写入者：

  • 人：开工时用 loopx start-goal（启动一个目标）写下目标、验收标准和边界；中途批门禁、改路线，也走命令。人只在两种时刻动账：立规矩，和做决定。
  • Agent：它干完活，不能“说”自己做了什么，只能执行几条固定的命令交作业：loopx todo update（汇报这项活的结果）、loopx refresh-state（刷新当前状态）、loopx quota spend-slot（为这次推进记账）。命令的参数是结构化的：待办编号、状态、证据文件路径，每一项都能被代码核对。
  • 代码自己：这是最容易被忽略的一个。CI（自动测试）跑挂了，不需要任何人下指令，代码会根据这个观察，自动在账上生成一条新任务：“修复 CI 失败”。外部世界变了，账就变了，全程无人经手。

为什么要把 AI 排除在记账环节之外？因为被记录的人，不能自己写记录。如果账本靠模型自述“我完成了”，那它漏写、写错、甚至为了显得有进展而美化，账就废了。所以在 LoopX 里，模型说的话不是证据，测试结果、外部系统的回执才是。

三个记账人写同一本账，凭什么不乱？

LoopX 的答案是一道硬闸：每一笔回写，先过代码验证。核对是机械的：待办存在吗？状态合法吗？宣称的测试结果，能对上证据文件吗？任何一项对不上，账本拒绝记录，这次活等于白干。

但账是死的，活是流动的。

5. 一轮怎么转：从领任务书到交回执

一轮是不是就是 AI 回答一次？多数人第一反应是这样：问一句，答一句，算一轮。

LoopX 的算法不一样。一轮（Turn）是一次完整的事务：从领任务书开始，到交回执结束。

中间发生了什么，LoopX 不关心。Agent 领到本轮的任务书后，可能要读十个文件、跑三次测试、改两版代码——背后是几十次模型调用。但模型喘多少口气，是执行层自己的事。LoopX 只在两个门口盖章：开工领了什么，交工拿了什么。

三个单位长得像，不是一回事：

  • 模型调用：AI 的一次输入、一次输出，最小的呼吸单位
  • Step：一次模型请求，加上它触发的工具执行——这是思考的单位
  • Turn：从领任务书到交回执的一次有界事务——这是记账的单位

层级是包着的。比如修一个 bug：跑测试看失败信息，是一个 Step；读源码后再请求模型，是下一个 Step；从领任务书到交回执，一个 Turn 把它们全装进去。

**一轮的开始，不由 Agent 自己决定。**闹钟响了。LoopX 管一次唤醒叫一个 tick。Agent 先跑 loopx quota should-run（只读检查：这一拍该不该动），得到 run 才算开工，任务书随后发下来。任务书写得非常具体：本轮只做哪件事、不许越的边界、验证要达到的标准，以及干完之后执行哪几条命令交回。闹钟响不等于开工——响三次，可能三次空手而归。

交回执是一轮的终点，也是它最难冒充的时刻。Agent 按任务书写好的命令交作业，代码核对通过，这一轮才算闭合，账上落下一条凭证：本轮的活、证据、花费。中途崩溃了呢？没有交回执的一轮就是未闭合，恢复时按未闭合处理——补一条失败记录，绝不假装成功。

一轮 Turn：从唤醒到验证回执

至于这一轮该不该动、下一轮隔多久才来，闹钟只是个传话的，真正的判断藏在账本里。

6.该不该继续：五种答案和下次唤醒时间

每一次唤醒，LoopX 先跑一个只读检查（should-run），然后回答一个问题：这一拍，干什么？官方把这个问答协议叫 interaction contract（交互契约）。

**术语：**interaction contract（交互契约） LoopX 每次唤醒都会现场编译的一份本轮决定：该不该动、给谁动、动完怎么交回。它是代码里的真实对象，带版本号，随状态变化，不存在两拍用同一份契约的情况。

should-run 返回的答案一共五种：

  • run（干）：账上有合法的活，权限齐、环境对——去干，干完验证了才记账
  • ask（问）：卡在人身上了，把具体问题摆出来：“reviewer 要求改鉴权逻辑，超出当初定的范围，放行吗？”等答复，不依赖这个决定的其他活照干
  • wait（等）：没新事实、没活、没到观察时间，安静跳过这一拍，只更新下次唤醒的时间
  • repair（修账）：账本发现自身出了问题——比如待办清单说全清了，投影里验收缺口却还开着，账目自相矛盾。这一拍不干正事，先修账
  • quiet（无事）：检查完了，确实无事可做。不调模型，不花钱

五种答案里，三种不花钱。LoopX 的记账规则是一次记账等于一次有效推进，安静、等待、问人都不消耗，只有验证过的推进才落账。Agent 想用忙碌冒充进展，在账本上留不下痕迹。

然后是那个传话的闹钟。铃本身不在 LoopX 手里：到点唤醒是宿主的机制，可能是 Codex 的 heartbeat 定时器，也可能是一个系统 cron，LoopX 只管算时间。每轮收工时，账本根据三样东西算出下次唤醒，写进契约的 scheduler_hint（下次唤醒建议）字段，刚干完活、账上还有下一件，间隔压到最短；在等外部事实（比如 CI 通常十分钟出结果），就按它的节奏定；一条线连续几轮没有任何变化，间隔逐次拉长，十分钟、二十分钟、一小时，直到出现真变化，立刻缩回。

分寸的拿捏有一条原则：**宁可钝，不可忙。**间隔设长了，代价只是晚知道一会儿；设短了，多醒的那几拍全是空转检查。这里的错误是便宜而且会自愈的，真正昂贵的判断，花不花钱、算不算完成、放不放行，从来不交给这套简单的规则。

写死的间隔当然覆盖不了所有情况：外部系统的节奏变了（CI 从十分钟变成三小时），它适应得慢。但这是设计者选的边界：用一点点迟钝，换掉一个每拍都要动用智能的调度器。

终局判定不在这五种答案里。待办清零了，可清单打勾不等于事情办成。系统凭什么宣布完成？这是整本账里验证最严的一道门。

7. 完成必须被推导出来

手术室里，一台手术结束的标准，从来不是主刀医生觉得“做完了”——是无菌护士数纱布：术前多少块，现在多少块，对上了才能缝合；差一块，全体停下翻找。完成是被数出来的，不是感觉出来的。

**LoopX 把这套清点写成了机器逻辑：**完成不是一个可以写入的状态，而是一个必须被计算出来的结论。系统里没有任何入口能“手写完成”——直接改配置文件塞一个字段也不行。

计算分两道闸。

完成判定：两道验证门

  1. 验清单本身可信不可信。“全部完成”这个说法，来源必须是结构化的账本投影，不能是一段话、一条汇报。来源合法之后开始数数：勾掉的数量等于总数，开着的是零，延期的零，到期没检查的零。“零条待办”和“待办数据丢了”是两回事。代码要求“0 条”这个数字本身也要出示证明——账本必须显式声明“这份清单存在，且它是空的”。如果账目整段缺失，系统不认为清单是空的，而是认为数据不完整，按未完成处理。宁可错拦，不可错放。
  2. 清单一本账清完还不够，另外几本要同时验：没有任何还在等的观察，没有挂着的 CI，没有在等的 review；没有可干的后继工作，也没有被卡住的后继——被卡住的同样算没完，这一条堵死了“把难活挂起、然后庆祝清零”的路；验收标准的缺口列表必须是空的；没有挂着待处理的重新规划义务。几本账同时归零，才轮得到谈完成。

两道闸全过，系统生成的终局结论自带一份标注：这是一个推导得出的结论，依据是目标闭合通过了完整验证（真实数据里，这个标注就叫 derived，意思是算出来的；它的 source 字段写着 validated_goal_closure，目标经完整验证闭合）。这份标注向所有后来的读者声明：这个“完成”不是任何人宣称的，是清点出来的。

跑与停到这里都有了交代：不该跑的时候安静，该停的时候有清点单。但有一类变化，清点逻辑管不着，任务做到一半，你自己对项目的认识变了：预设的阶段不对了，当初的路线走不通了，甚至目标本身要修订。人的认识会变，这本账怎么记人的改主意？

8.中途变卦怎么办：变化要签名

最常见的答案是重写：推翻旧计划，写一份新的。瀑布式项目里人人都见过这个场面，也都见过它的下场——三个月后没人说得清当时为什么改道，旧计划被覆盖，改道的理由随之蒸发。LoopX 的做法相反：**变化不覆盖历史，只追加。**改主意可以，但每一次变化都要在账上落一条新记录，并且签名：谁发起的，依据什么事实。

合法的变化一共三类。改路线：账上生成一条 replan obligation（重新规划义务），相关旧待办标记作废，新待办接上。改目标本身：愿景可以打补丁，旧版本留在账上，账本里看得到目标是怎么一步步长成今天这个样子的。增减活：新活入账，砍掉的活也留记录。计划全变了，之前干的活不就白干了？账本的回答是：没白干，至少没在账面上白干——每一笔都还在，出处也都还在。

出处怎么留？靠血缘。

**术语：**lineage（血缘） 账本数据里的真实字段（lineage_todo_ids，每条记录随身携带的“我从哪来”清单）。作废不是删除：旧待办被标记为已被替代，superseded_by 字段指向替代它的新待办；新记录必须声明自己从哪条记录生长出来。顺着血缘往回走，任何一笔都能上溯到出处。

但血缘也不是自说自话的。如果允许 Agent 交作业时顺口宣称“我是从那条待办长出来的”，血缘就成了可以打扮的出处。所以代码里有个动作叫 store-lineage（存入即绑定）：血缘关系只能由代码在写入那一刻校验并建立，事后不能口述补充。同一个道理：被记录的人不能自己写记录；同样，变了的账，不能自己说自己是怎么变的。

机器这一侧的账立住了。但账不是记给机器自己看的——人要随时翻开它。

9.给人看的账：看板、报告和审查包

账本本体没法直接给人看。翻开 .loopx 目录，里面是一组机器格式的状态文件：registry.json、状态快照、待办清单，全是为代码核对设计的，人读起来和看数据库导出没区别。

所以 LoopX 把同一本账渲染成几种人能读的形态。这类形态有一个统称：投影（projection）。README 里写着一句原则：The board is a projection; LoopX state remains the source of truth——看板是投影，LoopX 状态才是事实源。

投影分四层，由轻到重，各答一个问题。

同一本账的四种投影

第一层是 loopx status。终端里敲一下，当前目标、具体的 user gate、下一个待办，三行看完，答的是“现在到哪了”。

第二层是看板和 loopx dashboard。dashboard 是图形工作区：管理者总览所有目标的推进，点进单个目标，能看到任务板、受保护动作的预览和详情。看板上能做的动作有四个：认领（claim）、门禁（gate）、监控（monitor）、回写（writeback）。这层答的是“每条线各在什么状态”。

第三层是周期报告（periodic report）。目标一跑几个月，人不可能天天盯，报告按周期把推进、证据和花费汇总给你，答的是“这段时间干出了什么”。

第四层是 loopx review-packet，审查包。轮到人做决定的时刻，门禁要批、路线要改，它把相关证据打包成一份材料，不用自己去翻文件、对记录，答的是“做这个决定，依据都在这里”。

四层投影共用一条规则：投影不是真相。在 dashboard 上认领一个活、批一道门禁，动作要写回账本才作数；账本状态是唯一的事实源。改投影，投影明天就被状态刷新；改事实，走命令、留签名，和 Agent 交作业走的是同一条路。

投影这一侧，对不懂代码的人同样敞开。老板不用会读 JSON，合作方不用装终端，看投影就知道目标推进到了哪。LoopX 自己的用户手册，就托管在飞书文档上，给人看的这一侧，连文档都不住在代码仓库里。

10. 它能做出什么，又值什么

LoopX 的 showcase 目录里收了十一个案例，README 首页只放最强的三个。三个全部来自独立用户的真实使用。

第一个案例跑了十三个小时，任务是修一个 C++ 算法的精度问题。它值得讲的不是时长，而是文档对失败模式的描述：长执行会漂移进局部参数调优，丢失原始的精度目标，还会反复把调用关系这类有用上下文压缩掉。跑过长任务的人，对这种死法不会陌生。这个案例里，整整十三个小时，它干的活始终贴着既定愿景，没有漂；现有路线眼看满足不了愿景，replan 触发的是一次公开研究，不是原地继续空转；运行中还采用了公开的 codebase-memory-mcp 工具来检查调用关系。中途变卦要签名的那套机制，在这里放了实弹。

第二个案例更进一步：四天无人值守。要检验的问题，原文是：agent 能否在没有持续催促的情况下继续做有用的工作，而不只是让进程活着。四天里用户零干预；想看这四天攒下了什么，翻周期报告（periodic report）。

第三个案例最硬，因为全程公开可查。zilliztech/mfs 仓库的 Engine 重构：约六十个方法、九个职责区域，目标架构写在一个公开 issue 里，人人可查；重构拆成七个 PR 级的切片逐个落地，全部合并。机制上的关键一招：后继工作从持久的仓库证据继续，而不是要求单个会话把整个迁移装进上下文；维护者的评审全程保留。

那这套东西到底值什么？三个案例对应三种人：十三小时给质量敏感任务的主人，买的是不漂移；四天给不想天天盯着的 owner，买的是可离场；七个 PR 给要审计长活的贡献者和评审者，买的是可验证。

比案例更能说明问题的是目录之外的一件事：官方单独维护一份反馈覆盖文档，把每一条用户反馈都记录在案，做得好的进了案例，没做成的、负面或中性的信号，也原样留档。正面负面同册，靠的不是宣传技巧，是对自己证据体系的自信。这也正是一本账该有的记法：每条标注强度，每条写明边界，不挑着记。

11. 写在最后

把这篇收拢成一句话：LoopX 管的不是你的 agent 有多能干，是它干过的活有没有人记账。一本账，五套规则，开工怎么立，一轮怎么转，停不停谁说了算，完成怎么推，变卦怎么记。

这五套规则对付的，其实是同一类敌人：方向漂了没人拉，没进展还在花钱，它说做完了也没人较真。长程任务里所有的失控，都发生在没有人盯着的时刻。LoopX 干的，是把“盯”变成一本账：谁动的手，凭什么动，证据在哪。

翻到这本账的最后一页，决定权还是回到了人手里。规矩是人立的，门禁是人批的，改路线的签名是人落的；agent 从头到尾只有执行权和建议权。

当然，它还年轻。版本号停在 0.5.x，showcase 里最硬的证据也多一半出自用户自述。它证明的是这条路走得通，不是终点已经到了。

这篇真正想让你带走的，是一个提问的习惯。以后再看到任何声称能自己跑下去的 agent 工具，别问它强不强，问五个问题：它的账记在哪？凭什么停？变卦怎么记？我能不能看到？最终决定权在谁手里？

至少对 LoopX，这五个问题你现在都答得上来。