事情是这样的。你有没有试过把一个大任务交给 Codex，做那种要连续几天、步骤也很多的任务？比如把一个旧项目重构掉，先读代码，再改架构，再补测试，最后还要跑一轮验证。
第一天，Codex 说得头头是道，目标、计划、风险，安排得明明白白。第二天呢？它可能已经忘了为什么要这么改，忘了昨天做到哪一步，甚至把一个已经验证过的方案重新做一遍。
第三天更刺激。你打开会话，发现它正在认真地把项目往另一个方向带。你问它为什么，它说，因为这样更合理。
？？？
这时候你很难说它完全错了，它只是已经不记得自己为什么出发。
为什么 Agent 一到长期任务就容易跑偏
很多 Agent 做短任务很厉害，做长期任务却总有点不太行。模型会写代码，问题在于它缺少一套能支撑长期工作的系统。
LoopX 到底补了什么
最近看到一个叫 LoopX 的项目，第一眼看它的介绍，野心其实挺大。它的目标很明确，给 Codex、Claude Code、Cursor、Pi 这些 Agent 补上一层长期工作控制系统，具体执行仍由 Agent runtime 负责。
Agent 负责干活，LoopX 负责记住目标、安排下一步、保存证据、控制消耗、等待人的决定，再把工作交给下一轮继续。听起来有点像给 Agent 装了一套操作系统，但更准确一点，它像是一个长期任务的控制面。
这个词听起来有点工程师，我还是用大白话说。LoopX 不负责替你写代码，它负责确保 Agent 明天醒过来的时候，知道自己是谁，正在做什么，为什么要做，接下来该做哪一步，以及什么事情不能擅自决定。
长期任务不能只靠聊天记录
这就很关键了。一个 Agent 的连续工作不能只靠聊天记录。聊天记录能告诉它过去说过什么，却不一定能说明哪些决定已经生效，哪些证据已经验证，哪些事情正在等你拍板。
记忆和工作状态不是一回事。一个人说自己要减肥，和他每天打开冰箱之前都能看到自己的计划、体重记录、饮食预算、医生建议，这完全是两件事。前者是愿望，后者才像系统，LoopX 做的就是后者。
它把一个长期目标拆成可以持续更新的状态，里面有目标、待办、任务归属、需要人决定的 gate、最近一次执行留下的证据、剩余额度，以及下一轮应该从哪里接着做。
这套东西听起来不性感，但长期工作往往就是靠这些不性感的东西撑起来的。
你可以把一次 LoopX 工作回合想成这样，先检查现在是否应该继续，再领取一个有限范围的 todo，由 Codex 执行这一小段工作。执行完之后，不能只凭一句「已经完成」收尾，还要跑测试、检查文件、验证真实结果，验证通过后写回证据，再生成下一步。
如果需要你决定，就停下来问你；如果没有必要继续，就暂停；如果还有安全的下一步，才进入下一个回合。
一次工作回合怎么运转
它关心事情真的有没有发生，也会把 Agent 的自我汇报放到验证之后。
它和普通 /goal 有什么区别
这也是 LoopX 和普通 /goal 之间最重要的区别。/goal 更像是把一个任务交给 Agent，LoopX 会把这个任务保存成可以持续更新、可以恢复的长期状态，也给交接和审阅留下位置。
一个目标、一组 todo、几个 gate、一串证据、一个 quota，再加上一个下一步。Agent 每次只需要处理一个有限切片，不用每一轮都重新理解整个宇宙。
1、先把目标写清楚
很多人给 Agent 下任务的时候，喜欢说得很大，比如「帮我把这个项目做好」「把整个系统优化一下」「持续研究这个方向」。这种话人听得懂，Agent 不一定知道该从哪里开始。
LoopX 的思路是，长期目标要有明确边界。你可以告诉它最终要完成什么，哪些事情不在范围内，什么结果算完成，什么时候必须停下来问人。
比如可以这样写。
请把当前项目的登录流程重构完成。
完成标准
现有测试全部通过
新增登录失败场景测试
不修改公开 API
保留现有用户数据格式
涉及删除数据、发布或生产写入时先暂停并询问
每一轮只处理一个可以验证的工作切片这段话看起来没有什么魔法，甚至有点朴素。长期任务靠的是清楚的边界，Prompt 写得花哨并不能替代这件事。
目标越模糊，Agent 越容易用自己的理解填空。第一天它觉得重构登录模块最重要，第二天觉得应该先把数据库也顺手换了，第三天可能开始做一个你根本没要求的管理后台。它没有故意跑偏，只是你给它的目标里本来就没有画边界。
2、再把目标拆成有限 todo
一个长期目标不能直接变成一条永远运行的指令，要拆成一段一段可以交付的工作。比如先扫描当前登录流程和相关测试，再整理认证逻辑，接着设计接口边界，迁移登录成功路径，补充失败场景，最后运行完整测试并生成交接记录。
这份清单比普通待办更具体。LoopX 还会关心这个 todo 由谁负责、是否已经被领取、有没有其他 Agent 正在处理，以及完成后需要留下什么证据。静态清单因此变成了可以流动的工作队列。
如果你只有一个 Agent，它可以防止 Agent 一口气把所有事情混在一起做。多个 Agent 协作时，一个负责实现，一个负责审阅，另一个负责验证，大家通过 ownership、lease 和 handoff 交接，不用靠聊天猜测谁做到了哪一步。
听起来有点像项目管理软件，但普通看板主要告诉你卡片在哪一列，LoopX 还会追踪这张卡片有没有明确授权、有没有验证证据，以及下一次谁可以继续动它。
3、把人类决定写成 gate
很多 Agent 系统都有一个很模糊的状态，叫等待用户。但等待用户到底在等什么，是等你确认预算、选择方案，还是提供一个文件？如果只写一句等待用户，过两天你自己也不知道为什么卡住了。
LoopX 更强调具体的 user gate。
比如修改数据库结构、公开发布和使用真实用户数据，这些决定都可以单独设成 gate。
这就像在道路上设置了一个闸门，Agent 可以走到门前，却不能越过它。如果主任务被 gate 卡住，LoopX 允许某些经过审计的安全侧路继续推进。比如你还没有决定是否发布产品，Agent 可以先做本地测试、补文档、整理风险，但不能因为你没回复就顺手替你发布。
这件事我觉得特别重要。数字员工得知道哪些事情可以自己推进，哪些事情必须等老板签字。
4、不要相信 Agent 的自我汇报，要看证据
这块是 LoopX 最有价值的地方之一。Agent 很喜欢说一句「已经完成」，但它的完成有时候只是生成了一个看起来完成的回答。文件有没有真的写对，测试有没有真的通过，接口有没有真的生效，旧逻辑有没有被破坏，这些都需要另外验证。
LoopX 的工作流会把验证器放在 Agent 之后。Codex 负责执行，独立验证器负责检查，LoopX 再根据结果决定是否接受这次写回。验证没通过，状态就停在修复，不会被标记为完成；当前路线不对，就重新规划；需要你行动，就明确告诉你要做什么；暂时不能运行，就等待。
这个过程有点像软件工程里的 CI。
这个过程会检查代码构建，也会把验证结果写回长期任务状态。
几天之后你回来看，既能看到 Agent 说了什么，也能看到哪些事情真的被验证过。输出是观点，证据才是状态变化。
5、用 quota 管住 Agent 的手
如果你给 Agent 一个定时器，它就可以不断醒来，但不断醒来不等于不断产生价值。有时它只是重复检查，或者卡在同一个问题上，任务已经完成时还可能继续消耗额度。
所以 LoopX 里还有一个 quota 概念。每一轮自动运行之前，先判断当前是否值得运行。
没有新的有效状态迁移，就安静一点；正在等待人类决定，就不要绕过去；当前 Agent 没有合适的 todo，就不要硬找活干；上一轮验证失败，就进入修复，不要直接假装成功。
这件事听起来很像给 Agent 装了一个自动刹车。
日常可以查看这些状态。
loopx status
loopx diagnose
loopx history --goal-id <goal-id>
loopx quota should-run --goal-id <goal-id>
loopx review-packet其中，loopx status 是最值得看的命令。它应该告诉你现在的目标、当前 gate、下一条 todo、最近的证据，以及下一步是否应该继续。
我觉得这比一个漂亮的 Dashboard 更重要。Dashboard 只是展示，事实源还是 LoopX 保存的状态。
6、最后才是 heartbeat
很多人一听到连续运行，就会想到定时任务，每隔几分钟唤醒一次 Agent。听起来很简单，但如果没有目标、todo、gate、evidence 和 quota，定时器只是在定时制造聊天记录。
这就是为什么 LoopX 把 heartbeat 放在整套系统的最后。
heartbeat 的作用，是先问当前有没有值得做的事情。有就执行一个有边界的回合，没有就等待；需要人工判断，就发一个具体问题；完成条件已经满足，就停止。
这就从每天叫醒 Agent，变成每天检查这个项目是否值得继续，差别非常大。
具体怎么开始用
那具体怎么开始用？
官方推荐的路径并不复杂。
普通用户不需要先 clone LoopX 仓库，可以从项目主页提供的 no-clone 安装方式开始。
安装之后运行 loopx doctor，确认本机环境没有问题。
然后进入你要让 Codex 长期工作的项目目录。
cd /你的项目目录
loopx connect
loopx status如果项目还没有目标状态，再使用 guided path。
loopx start-goal \
--guided \\
--project . \\
--goal-text '把当前项目的登录流程重构完成，并通过测试'连接完成之后，可以在 Codex 中使用 $loopx，或者从 /skills 里选择 LoopX。不要一上来就让它长时间开发，先让它完成接入检查，并汇报当前 state id、需要你决定的 gate、Agent 的第一条 todo，以及下一步最安全的动作。
这一步看起来有点慢，但慢一点是好事。你要先确认它接入的是哪个项目，复用的是不是已有状态，当前目标有没有被错误覆盖。尤其是已经存在 .loopx/、.codex/goals/ 或其他本地状态的项目，更不能随手重新初始化。
长期系统最怕同时存在两套状态，一套在聊天里，一套在本地文件里，最后谁说了算，没人知道。
它不是什么
说到这里，可能有人会问，LoopX 能不能让 Codex 连续干四天，还保证不出问题？答案没这么简单。
项目自己的说明也很克制，目前定位是早期但可用的本地控制面，离完整 Agent 平台和生产级自主控制器还有距离。
我也没有把它包装成一个已经被我连续跑了四天的神奇案例。工具类文章最容易犯的错，就是把别人的演示说成自己的实测，把理论上可以写成我已经验证，这玩意没必要。
LoopX 的价值，落在它把长期工作的几个关键问题摆到了明面上。它并不承诺无人值守的时长。
它把这些问题摆到了明面上，目标有没有变，下一步是什么，谁拥有这个任务，什么事情需要人判断，这次修改有没有证据，现在是否值得继续。
这些问题，原来经常藏在聊天记录里。
现在被单独拿出来，变成了可以检查、可以写回、可以交接的状态。
你想想看，一个普通员工第二天回到公司，桌上有项目目标、待办列表、会议结论、审批记录、测试报告和下一步安排。他当然还需要自己思考，但不需要每天重新猜测整个公司发生了什么，Agent 也是一样。
我们过去总觉得，数字员工只差一个更强的模型。
后来慢慢发现，模型只是员工的大脑。
员工要长期工作，还需要任务系统、权限系统、审计系统、交接系统和停止机制。
没有这些东西，模型越强，可能只是越快地把事情做偏。
这也是我看到 LoopX 时最有感觉的地方。它把 Agent 当成一个会忘、会误判、会重复的执行者，它可能把自己的输出当成事实，也可能在没有新进展的时候继续消耗。
所以我们要给它建立一套外部的工作记忆，让它每次只做一点，做完留下证据，遇到边界停下来，下一轮从状态继续。
这听起来不像科幻片。
甚至有点像给一个新员工写 SOP。
数字员工这个词，也不该只指一个神奇的聊天机器人。
数字员工最早的样子
它更应该指一个有目标、有权限、有记录、有边界，也知道什么时候该停下来的工作单元。我们活在一轮一轮的对话里，Agent 也一样。每一轮结束之后，都给下一轮留下一份看得懂的状态，Agent 才能连续起来，这就是 LoopX 想补上的那一层东西。
如果你只是改一个按钮，直接用 Codex，改完就结束。如果你要做一个持续几天的重构、研究、实验、PR 修复，或者一个需要不断监控的项目，可以试着把它接进来，但先别追求完全自动，先让 Agent 学会记住目标、留下证据、知道什么时候等你。
至于连续工作几天，反而是后面的事情。一个不会写回状态的 Agent，跑一天和跑三天没有区别；一个知道自己做到哪一步、为什么继续、什么情况下必须停下来的 Agent，哪怕每次只工作二十分钟，也可能真的把事情一点点推完。
回到开头那个问题。第二天醒来的 Agent，应该能看着那份状态回答清楚，我现在在做什么，为什么继续，已经验证了什么，下一步是什么，还有什么需要你决定。如果它能回答清楚，那它才算接上了昨天的工作。
这可能就是数字员工最早的样子，不完美，不神奇，但能交接、能复盘、能停下来等人，然后在被允许的时候继续往前走。