LoopX 是什麼？讓 AI agent 跑 200 小時不忘記目標的開源內核，但那個數字要拆開看（2026）

最後更新：2026 年 8 月 7 日

你把一個要做三天的任務丟給 AI agent。第 40 個回合，它忘記自己本來要幹嘛，把上星期已經做完的東西又做了一次。

一句話結論：LoopX 是一個開源的「狀態內核」，跑在 Codex、Claude Code 這類 agent 上面，專門保住跨回合會流失的目標、決策和證據。它不執行任務，只負責讓長任務不斷片。2,984 星，MIT 授權，但目前只適合真的在跑多天任務的人。

LoopX 是什麼？一張表看完

先把事實擺出來。以下數據我用 GitHub API 在 2026 年 8 月 7 日當天實查，沒有抄任何二手報導：

項目	資料（截至 2026 年 8 月 7 日）
專案	huangruiteng/loopx
GitHub 星數	2,984 星（fork 221、未結 issue 31）
授權	MIT
語言與依賴	Python 3.11+，標準庫以外零執行時依賴
建立日期	2026-05-31（不到 10 週）
最新版本	v0.4.2（2026-08-06 發布）
支援系統	macOS、Linux；Windows 要走 WSL
支援 agent	Codex App、Codex CLI、Claude Code、OpenCode、Pi、Cursor、自訂 runner
作者	清華電機出身、ByteDance AML 工程師
它是什麼	本地控制層（control plane）
它不是什麼	不是 agent 執行引擎，不是全自動生產控制器

LoopX 到底解決什麼問題？

解決一件很具體的事：長任務跑到一半，脈絡消失。

單次對話裡，agent 的表現通常不差。問題出在任務跨越好幾天、好幾十個回合的時候。目標中途改過，但沒有東西記錄「為什麼改」；某個決定其實需要你點頭，但那句請求被淹在對話紀錄裡沒人看到；兩個 agent 同時動同一個專案，誰負責哪塊沒人講清楚；上一輪說「完成了」，但拿不出任何證據。

這些東西平常靠兩樣撐著：對話記憶，加一個定時器。兩樣都不夠。context window 一滾動，劇情就跟著不見了。

LoopX 的做法是把「必須活過回合交界」的狀態抽出來，放在一個獨立的層：目標、閘門、待辦、範圍、證據、額度。你的 agent 照樣執行，只是每次開工前先問這一層「我現在該做什麼」，收工後把「我做了什麼、證據在哪」寫回去。

它把自己的職責壓縮成五個問題：目標是什麼？下一步是什麼？哪裡需要人來判斷？證據變了什麼？這個迴圈還能不能繼續跑？

「跑 200 小時」是真的嗎？這個數字要拆開看

這是這篇文章我最想講的一段，因為中文圈已經開始把這句話傳成「AI 可以自己跑 200 小時」。

200 小時這個數字確實來自官方 README，指的是兩條實際軌跡：一條開源 issue 修復（作者本人在 volcengine/OpenViking 的 PR 貢獻紀錄），一條自動 ML 實驗。但同一份 README 自己加了一句限定，中文轉述基本上都把它漏掉了：

「Elapsed lifetime is wall-clock project time, not 200 hours of continuous model execution or a claim of unattended production autonomy.」

loopx README，2026 年 8 月版

翻成白話：那 200 小時是「這個專案從第一個 PR 到最後一次更新，掛鐘走了 200 多小時」，不是模型連續運算 200 小時，也不是無人看管的自主運行。中間有多少回合、多少次人類介入、多少次停下來等你回答，都算在那 200 小時裡。

你可能以為	官方實際說的
AI 連續運算 200 小時	專案掛鐘時間跨越 200 多小時
全程無人看管	明確否認「unattended autonomy」
LoopX 幫你跑任務	LoopX 只保存狀態，任務還是 agent 跑
可以放上生產環境	作者寫明它不是生產控制器

我把這段挑出來講，不是要唱衰這個工具。剛好相反：作者願意在自己的宣傳素材旁邊親手貼一張免責標籤，這種克制在 2026 年的 AI 開源圈相當少見。我上個月寫 Gemini Spark 那篇時就吐槽過，會自己標「我做不到什麼」的產品，通常比滿口自動化的可靠。

它跟一個 TODO.md 檔案差在哪？

差在四件事會不會被機器讀懂。一個 TODO.md 加一段長 system prompt，其實可以撐很久，直到下面任何一項成立：

• 使用者閘門（user gate）：某個決定必須由你來做。LoopX 把它變成一個物件，agent 看得到自己「卡在等人」，而不是把請求寫成一句話沉進對話裡。
• 待辦歸屬：每個待辦標明是人的還是 agent 的，加一個 claimed_by 欄位。多個 agent 就不會撞在一起。
• 額度守門（quota）：回答「這一輪現在該不該跑」。心跳式的自動迴圈最貴的浪費，就是明明產不出任何有效進展還在燒 token。安靜略過、預檢失敗、乾跑都不計入消耗。
• 證據紀錄：進度、驗證、阻塞、額度花費全部 append-only 記下來。上一輪說完成了，這輪查得到憑據。

還有一個設計我覺得比其他部分聰明：安全回退（safe fallback）。當某條路被閘門擋住，經過審核的側路可以繼續走，但不能繞過那道閘門。多數工具在這裡只有兩種選擇，全部停下來，或者讓 agent 自己判斷，兩種都不好。

怎麼裝？三步跑完第一個迴圈

安裝門檻比想像中低，Python 3.11 以上加上 curl、tar 就夠，標準庫以外沒有其他依賴。

第 1 步：安裝，不用 clone

curl -fsSL https://raw.githubusercontent.com/huangruiteng/loopx/main/scripts/install-from-github.sh | bash
export PATH="$HOME/.local/bin:$PATH"
loopx doctor

提醒一句老話：這是管線式安裝腳本，介意的話先把它下載下來讀過再跑。

第 2 步：先用 demo 試水，別碰真專案

loopx demo
cd /tmp/loopx-demo
loopx status
loopx quota should-run --goal-id demo-goal

這一步建立一個可丟棄的目標，含一個使用者待辦和一個 agent 待辦。花你 30 秒，但足夠判斷這套心智模型對不對你的胃口。看到 should_run=True 和 state=eligible 就算通了。

第 3 步：接上真專案，並且立刻加 .gitignore

cd /path/to/your-project
loopx connect
loopx status

這一步會產生 .loopx/registry.json 和 .codex/goals/ 底下的活動目標狀態。提交之前務必把它們加進 .gitignore：

.loopx/
.codex/goals/
.opencode/goals/
goals/**/ACTIVE_GOAL_STATE.md

那些是即時本地執行狀態，裡面有本機路徑和內部筆記。把一個控制器的活動狀態推上公開 repo，是私密路徑外流最常見的方式之一。這類「工具本身沒問題，用的人設定錯」的風險，我在 Uber ADR 那篇 也整理過一整張表。

日常怎麼用？五個指令就是全部

核心循環刻意做得很小，記這五個就夠開始：

指令	它在問什麼
loopx quota should-run	這個 agent 現在該不該動？
loopx todo claim	這一塊誰負責？
loopx todo update	什麼變了？
loopx refresh-state	下一輪該看到什麼？
loopx quota spend-slot	記一筆已驗證的消耗

另外兩個值得知道：loopx review-packet 產出給人看的決策與證據摘要，適合你早上起來想知道昨晚發生什麼；loopx check 在你要公開任何文件之前掃一遍，把憑證、原始日誌、本機路徑攔下來。

官方文件其實鼓勵你不要自己敲這些指令，而是把一段設定說明貼給 Codex 或 Claude Code，讓 agent 自己去接。loopx diagnose 也刻意不給結論，只吐一包證據，讓你的 agent 讀完自己推理。

誰該裝？誰現在別碰？

這個工具的價值跟你的迴圈長度成正比。短任務不會漂移，那些流程對你只會是負擔。回答三題，看看你屬於哪邊：

有哪些風險要先知道？

三件事，裝之前先看清楚。

一、實質上是單人專案。倉庫掛著 19 位貢獻者，數字看起來健康，但拆開來看：作者本人 3,898 次提交，第二名 46 次。這代表迭代快，也代表作者一停下來，整個專案就停下來。

二、版本還在高速變動。14 天內連發 5 個版本（v0.2.13、v0.3.0、v0.4.0、v0.4.1、v0.4.2），最近四週提交數是 592、338、220、169。這種節奏下，指令名稱和狀態格式隨時可能改。想要「裝了就別碰」的穩定工具，現在還不是時候。

三、它驅動不了所有 agent。LoopX 至少需要一個控制鉤子，例如 shell 執行、目標指令、自動化 hook 或自帶排程。你的 agent 什麼都不給，LoopX 還是能記狀態，但每個指令都要你自己敲，那就失去大半意義。

不想用 LoopX，有什麼替代？

照痛點分，不必勉強。

你的痛點	更合適的方向
只是想記住「要做什麼」	一份維護良好的 GOAL.md 加固定 system prompt，先撐著
agent 燒太多 token	看 pxpipe 這類 token 壓縮工具
想教 agent 重複的固定流程	Microsoft Skill Recorder，錄一次生成 SKILL.md
想讓 agent 有自己的執行環境	Cloudflare computer
想要現成託管的自動代理	Gemini Spark，代價是控制權交出去
只是想省終端 agent 的錢	Reasonix

不寫程式的人，能從這裡拿走什麼？

你大概不會裝 LoopX。但它背後那個叫「loop engineering」的想法，可以直接搬。

2026 年多數人跟 AI 的合作方式，還停在「開一個對話，講完，關掉」。真正能靠 AI 產生收入的人，做法不一樣：他們把目標、規則、已經拍板的決定、做過什麼的證據，全部寫在對話外面的檔案裡。對話只是執行的那一下，狀態活在對話之外。

這件事直接決定你能不能靠 AI 賺到錢。接案、內容產線、自動化服務這些，客戶真正付錢買的是「同一套流程重複跑一百次，品質不掉」。「AI 幫我寫了一篇」值不了多少錢，那只是打字快一點。差別就在有沒有把狀態放到對話外面。

你今天就能做的最小版本：開一個 GOAL.md，寫三段。目標是什麼、有哪些決定已經定案不准再改、目前卡在等誰。每次開新對話先貼進去。這是 LoopX 的思路，不用裝任何東西。想再往前一步，可以看 主流 AI 工具怎麼選 這篇先把手上的工具定下來。

新手行動清單

• 先確認系統是 macOS、Linux 或已裝 WSL 的 Windows
• 跑 loopx demo，花 30 秒判斷這套模型合不合你用
• 覺得順，才用 loopx connect 接真專案
• 接上的第一時間就把 .loopx/ 和 .codex/goals/ 加進 .gitignore
• 公開任何文件之前跑一次 loopx check
• 不打算裝的人：今天開一份 GOAL.md，寫下目標、已定案決定、目前卡點

常見問題

LoopX 免費嗎？

免費，MIT 授權，可商用。它本身不呼叫任何模型，所以沒有額外 API 費用，你的花費仍然來自底下那個 agent。

LoopX 會取代 Claude Code 或 Codex 嗎？

不會，它們是上下層關係。Codex、Claude Code 這些負責執行，LoopX 負責保存跨回合的狀態。作者在 README 裡寫得很直接：它不取代你的 agent runtime。

Windows 可以用嗎？

要透過 WSL。官方標明支援環境是 macOS 或 Linux shell，原生 Windows 目前不在支援範圍。

「200 小時」代表 AI 自己跑了 200 小時嗎？

不代表。官方 README 明確說明那是專案的掛鐘時間，不是連續的模型運算時間，也不是無人看管的自主運行。中間包含大量人類決策和等待。

現在適合放進正式工作流程嗎？

建議先在可丟棄的專案上試。它 2026 年 5 月底才建立，14 天內發了 5 個版本，作者本人也標明這不是生產環境的自主控制器。危險權限和最終決定權仍然應該留在人手上。

結論：值不值得裝？

如果你每天真的在跑跨天的 agent 任務，被「上輪做完的事這輪又做一次」咬過，那 30 秒的 demo 值得花。這套想法就算你最後沒採用，也帶得走。

如果你的 AI 使用還停在單次對話，現在裝只會多一層繁瑣。收下概念，工具等它過了 v1.0 再說。

我對它的整體評價偏正面，主要因為作者的克制：一個能拿「200 小時」做行銷的專案，選擇在同一段話裡自己標明那個數字不代表什麼。在 AI 開源圈，這種老實比功能表更難得。

延伸閱讀

• Microsoft 開源 Skill Recorder：錄一次工作，AI 自動寫成技能
• Cloudflare 開源 computer：90% 的 agent 工作不需要一台完整電腦
• Agent-Reach：一句話讓 AI Agent 讀推特、看 YouTube、查行情
• Karpathy 用一段《魔戒》宣告舊的 AI 測試方法過期了
• Open Interpreter Rust 重生，接 Kimi K3 跑 Codex 級 coding agent

參考資料

• huangruiteng/loopx GitHub 倉庫與 README（星數、版本、貢獻者數據以 GitHub API 於 2026-08-07 實查）
• LoopX 官方網站與文件
• ArshTechPro, “LoopX: A Control Plane for AI Agents That Have to Keep Working for Days”, DEV Community, 2026-08-05

利益揭露與免責聲明：本文不含任何贊助或聯盟連結，LoopX 為 MIT 授權開源專案，作者與本站無任何往來。文中數據為 2026 年 8 月 7 日以 GitHub API 實查所得，開源專案版本與功能變動快速，實際情況請以官方倉庫為準。安裝任何第三方工具前請自行評估安全風險，尤其管線式安裝腳本建議先行審閱。本文為工具介紹與個人使用評估，不構成任何投資或商業建議。