當AI能連續工作30小時，"對話框思維"已經過時了
整理版優先睇
對話框思維已經過時，Long-running Agent用狀態管理取代記憶
呢篇文章係由工程師Addy Osmani寫嘅，佢發現AI agent喺長期任務會撞上三堵牆：context window有限同腐化、新會話要從零開始、模型自己評分太寬鬆。作者認為問題唔係模型唔夠聰明，而係架構設計——要將模型循環、執行環境同會話日誌分開處理。
文章介紹咗最簡單嘅Ralph Loop模式，靠文件系統持久化狀態，令agent每次醒來都可以重建上下文。然後拆解Anthropic、Google、Cursor三大廠商點樣實現呢個概念，雖然包裝唔同，但底層模式一樣：大腦、執行、會話解耦。最後畀咗開發者、產品搭建同無人值守任務嘅具體行動指南，亦坦白承認成本、安全、目標漂移同人工驗收仲係硬骨頭。結論係：真正嘅AI同事唔係更聰明嘅對話框，而係識得管理狀態同結構化交接嘅系統。
- Long-running Agent嘅核心係將模型（大腦）、執行沙箱（手）同會話日誌（記憶）解耦，解決context腐化同記憶中斷。
- Ralph Loop模式揭示核心洞見：agent失憶但文件系統唔會，透過prd.json、progress.txt等檔案持久化狀態。
- 三大廠商方案趨同：Anthropic拆成Brain/Hands/Session；Google推出Memory Bank同Sessions；Cursor採用Planner/Worker/Judge三層。
- 實操要點：開發者維護AGENTS.md、寫計劃文件；產品搭建可選託管運行時或自搭；無人任務用ADK+Memory Bank+Cloud Run。
- 未解決問題：成本高、安全邊界大、目標漂移、人工驗收困難——需結構化產出同熔斷機制。
對話框思維嘅盡頭
你有冇試過畀AI一個複雜任務，睇住佢一步步行，但到關鍵位context window就滿咗？要唔重新嚟過，要唔花半個鐘餵返上下文——然後佢又犯返上一輪改好嘅錯。呢個唔係你嘅問題，亦唔係模型蠢，而係個架構本身有問題。
- 1 第一堵：Context有上限，仲會腐化。就算100萬token嘅窗口都會裝滿，而裝滿之前模型表現已經開始跌——呢個現象叫 context rot。
- 2 第二堵：新會話，白板開始。冇持久化機制，每次會話交接就係一場生產力災難——好似軟件項目每個新工程師對上一班做咗乜一無所知。
- 3 第三堵：模型畀自己打分，永遠打高分。佢自己判斷完成未，結果永遠係「完成」，就算只做咗30%。
模型會忘記
任務只完成了30%
白板開始
簡單但有效：文件系統救場
喺大廠出手之前，一班工程師用極簡方式搞掂咗呢個問題，最出名係Ralph Loop模式——一個bash腳本循環，核心係六步：由任務列表拎下一個未完成任務、將任務連上下文同歷史餵畀agent、執行agent、跑測試或驗收邏輯、將結果追加落progress.txt、更新任務狀態。
# Ralph Loop 模式
while task in task_list; do
feed task + context + history to agent
run agent
run tests or acceptance logic
append result to progress.txt
update task status (done/fail/blocked)
done呢個模式嘅變體被多次重新發明，Anthropic、Google、Cursor後嚟嘅託管運行時，底層邏輯同呢個腳本驚人相似——只係加咗生產級可恢復性、安全性同可觀測性。
文件系統唔係
prd.json
progress.txt
AGENTS.md
三間大廠嘅解法：一樣嘅骨幹
Anthropic、Google、Cursor近月各自發佈咗long-running agent方案，拆開嚟睇，結構高度趨同——都係將大腦、執行同會話分開。
- 1 Anthropic：拆成Brain（模型）、Hands（執行沙箱）、Session（追加式事件日誌），p50首token延遲下降60%，p95下降超過90%。
- 2 Google：Vertex AI整合Memory Bank同Sessions，agent有長期記憶，按用戶身份索引，Payhawk報告費用報銷時間縮短50%以上。
- 3 Cursor：Planner（探索生成任務）、Worker（專注執行）、Judge（決定迭代結束），仲發現不同模型適合唔同角色——GPT喺長期自主工作表現反而好過Opus。
呢啲方案嘅共同點係：將模型循環、執行沙箱、持久化會話日誌三件事分開，規劃同生成分開，生成同驗收分開，記憶變成可查詢嘅託管服務。商業包裝唔同，但底下一樣。
大腦/執行/會話分離
p50首token延遲下降60%
Memory Bank
Planner/Worker/Judge
你可以點樣開始？實戰指南
根據你嘅場景，起點唔一樣，以下係三種主要情況嘅建議。
- 開發者：直接用Claude Code或Cursor，harness已內置。維護AGENTS.md（每一行係真實踩坑換嚟），寫計劃文件帶明確完成標準，agent話完成但唔確信時用Ralph Loop循環驗收，多小時或隔夜任務用worktree跑同每完成有意義單元就commit。
- 產品搭建者：唔好自己造運行時。三個真實選項：Google Agent Platform（Agent Engine + Memory Bank + Sessions）、Claude Managed Agents、或基於ADK/Claude Agent SDK自搭。託管方案解決大腦/執行/會話分離同審計，自搭可以玩奇怪模型。
- 無人值守自動化（監控、研究、運營）：Memory Bank風格持久化係你需要嘅。ADK + Memory Bank + Cloud Run + Cloud Scheduler係目前最乾淨組合，適合『每N小時跑一次、積累狀態、閾值觸發告警』。
但都有幾件事仲未搞掂：成本——frontier模型行24小時燒錢快過預期，要有預算上限同熔斷機制；安全邊界——有API key同雲權限嘅agent攻擊面大過一次聊天；目標漂移——原始目標經過多個context window再摘要會失真；驗收——24小時自主行為靠人審計成本高，必須靠結構化產出（PR、commit、測試報告）先可操作。
AGENTS.md
Ralph Loop
目標漂移
結構化產出
你有冇遇過呢種情況：
同AI佈置咗一個有啲複雜嘅任務，睇住佢一步步執行，點知去到關鍵節點，context window滿咗。一係從頭嚟過，一係花半個鐘將上下文餵返畀佢——然後佢又犯咗上一輪啱啱改好嘅錯誤。
呢個唔係你嘅問題，亦唔係模型太蠢。呢個係一個架構問題。
而呢個架構問題，而家正被系統性地解決緊。
我哋都活喺「單次會話」嘅幻覺裏面
過去兩年，大家對AI agent嘅想像，基本上係咁樣：打開一個對話框，輸入目標，agent調用工具，token流過屏幕，任務完成。
呢個範式嘅天花板好明顯：「個模型會唔記得嘢。」 佢喺第九輪啱啱修好嘅bug，到第十八輪可能重新出現。佢喺上下文就快滿嘅時候話「任務完成」，即使工作只做咗30%。成個系統嘅設計假設，係你同AI都坐喺同一張枱前面，唔會離開。
但真實嘅工作唔係咁樣嘅。
真實嘅工作係：一個功能開發要3日，一份競品分析要通宵，一個數據遷移任務要喺後台行一個禮拜。呢啲任務需要嘅係一個「能夠持續推進、能夠從失敗中恢復、能夠喺唔同會話之間保持記憶」嘅agent——而唔係一個更聰明嘅聊天窗口。
呢個就係Long-running Agent要解決嘅問題。
三堵牆，攔住咗所有想認真用AI做嘢嘅人
研究呢個方向嘅工程師同研究者，幾乎無一例外都會撞到同樣三堵牆。
「第一堵：Context有上限，仲會腐化。」
就算係100萬token嘅上下文窗口，都會裝滿。更麻煩嘅係，未裝滿之前，模型嘅表現已經開始下降——呢個現象叫做context rot（上下文腐化）。一個24小時嘅運行任務，冇可能塞得入任何一間廠商規劃路線圖上嘅context window。一定要有另一種解法。
「第二堵：新會話，由白板開始。」
Anthropic喺一篇研究文章裏用咗一個好準確嘅比喻：「想像一個軟件項目，工程師輪班工作，但每個新嚟嘅工程師對上一班發生咗咩事完全唔知。」 冇顯式嘅持久化機制，每次會話交接就係一場生產力災難。
「第三堵：模型幫自己打分，永遠打高分。」
叫模型自己判斷「任務完成咗未」，佢話「完成」嘅機會遠高於正常水平。冇獨立嘅驗證信號，你就會得到一個以30%完成度交貨、但充滿自信嘅agent。
Long-running Agent嘅設計，本質上就係喺度回答呢三個問題。
最簡單嘅解法：agent係失憶嘅，但檔案系統唔係
喺大廠開始發佈託管運行時之前，有一班工程師用極簡嘅方式解決咗呢個問題。
其中流傳最廣嘅係一個叫「Ralph Loop」嘅模式，核心實現就係一個bash腳本：
由任務列表度攞下一個未完成嘅任務 將任務、相關上下文、歷史進度餵畀agent 調用agent執行 跑測試或其他驗收邏輯 將結果追加寫入 progress.txt更新任務狀態（完成/失敗/阻塞） 返去第1步
聽落好簡單。但佢有效，原因係一個核心洞察：
「agent本身係失憶嘅，但檔案系統唔係。」
prd.json係計劃，progress.txt係實驗記錄，AGENTS.md係滾動更新嘅規則手冊。每次agent「醒嚟」，都從檔案度重建足夠嘅狀態去繼續工作。agent失憶冇問題，重要嘅嘢擺喺出面。
呢個模式嘅變體被獨立咁重新發明咗好多次。Anthropic、Google、Cursor後嚟發佈嘅各種託管運行時，底層邏輯同呢個bash腳本驚人咁相似——只不過加上咗生產級嘅可恢復性、安全性同可觀測性。
三大廠商嘅方案：殊途同歸
最近幾個月，Anthropic、Google、Cursor相繼發佈咗自己嘅long-running agent方案。拆開嚟睇，結構高度趨同。
「Anthropic嘅答案：大腦/執行/會話，三件事分開」
Anthropic喺工程博客度提出咗一個「decoupling」框架：將agent拆成三個可以獨立替換嘅部分。
「Brain（大腦）」：模型本身，加上調用佢嘅harness循環 「Hands（執行）」：沙箱化嘅臨時執行環境，工具喺呢度實際運行 「Session（會話）」：每個思考、工具調用、觀察結果嘅追加式事件日誌
呢三件事解耦之後，好處係具體嘅：容器冧咗唔等於會話丟失，新容器調用wake(sessionId)就可以從日誌度重建狀態。Anthropic報告呢個設計令p50嘅首token延遲下降咗60%，p95下降超過90%——因為可以喺沙箱準備好之前就開始推理。
最值得劃線嘅一句話：「harness裏面嘅每個組件，都編碼咗一個關於模型做唔到乜嘢嘅假設。」 當模型能力提升，之前繞過佢嘅假設就需要更新。解耦令你可以只改一個組件，而唔係成個系統推倒重嚟。
「Google嘅答案：將基礎設施變成名詞」
Google喺Cloud Next '26上將Vertex AI整合咗入「Gemini Enterprise Agent Platform」，將long-running agent變成咗有名、有SLA嘅產品。
幾個關鍵組件：
「Agent Runtime」：支援「自主運行數天」嘅agent，冷啟動時間低過1秒 「Agent Sessions」：持久化對話同事件歷史，可以綁定你自己嘅CRM或數據庫ID 「Memory Bank」：長期記憶層，從會話中提煉記憶，按用戶身份索引，供下次調用檢索
一間財務SaaS公司Payhawk報告，用Memory Bank支援嘅agent處理費用報銷，提交時間縮短咗50%以上。
「Cursor嘅答案：規劃者、執行者、裁判，各司其職」
Cursor喺博客度記錄咗一個有意思嘅失敗歷程。佢哋第一版係平等地位嘅多agent協調模型，結果agent們都變得好保守，喺鎖文件上內卷，唔敢提交。第二版換成樂觀並發控制，去咗瓶頸，但協調問題冇解決。
第三版先至行得通，設計係：
「Planners」：持續探索代碼庫，生成任務，可以遞歸生成子規劃者 「Workers」：專注嘅執行單元，唔協調、唔關心全局 「Judges」：決定一輪迭代幾時結束、幾時重啟
Cursor嘅發現裏面有一條出人意料：「系統行為好大程度上取決於我哋點樣寫prompt，而唔係harness或者模型。」 而且唔同模型適合唔同角色——佢哋發現GPT模型喺長期自主工作上表現反而優於Opus，因為Opus更容易提前收手或者走捷徑。「同一任務，唔同角色，換唔同模型。」 呢個本身已經成為設計嘅一部分。
你今日就可以用嘅實操指南
理論講完，返到實際。根據你嘅場景，起點唔一樣：
「如果你係開發者，想叫AI幫你處理自己嘅代碼庫：」
直接用Claude Code、Cursor或類似工具，harness已經內置咗。你需要做嘅係：
好似飛行員檢查清單咁維護你嘅 AGENTS.md——每一行都應該係真實踩坑換返嚟agent開始之前，先寫一個計劃文件，帶明確嘅完成標準 agent話「完成咗」但唔肯定嘅時候，用Ralph Loop——叫佢循環一次「呢個真係做曬未」 多個鐘或者過夜嘅任務，喺worktree度行，等佢每完成一個有意義嘅單元就commit
「如果你喺度搭建一個託管嘅agent產品：」
唔好自己造運行時。而家有三個真實選項：Google嘅Agent Platform（Agent Engine + Memory Bank + Sessions）、Claude Managed Agents，或者基於ADK/Claude Agent SDK自搭。取捨好標準：託管方案幫你解決大腦/執行/會話三分離、可觀測性、身份認證、審計日誌；自搭就俾你用奇怪嘅模型做奇怪嘅事（Cursor嘅玩法）。大多數團隊嘅起點應該係託管運行時加上自己寫嘅循環邏輯。
「如果你做嘅係無人值守嘅自動化任務（監控、研究、營運）：」
呢度Memory Bank風格嘅持久化係你真係需要嘅，亦係Claude Code冇提供嘅。ADK + Memory Bank + Cloud Run + Cloud Scheduler係目前我見過最乾淨嘅組合，適合「每N個鐘跑一次、積累狀態、閾值觸發警報」呢類場景。呢度Cursor嘅planner/worker/judge分層都比IDE編程場景更有價值，因為任務真係並行嘅，失敗模式都唔同。
有幾件事，真係仲未解決
唔誇大進展：呢個方向有幾個問題目前仲係硬骨頭。
「成本。」 一個用frontier模型運行24小時、調用幾十種工具嘅agent，燒錢速度超出大多數人預期。冇預算上限同熔斷機制，agent可能用一個下晝燒曬一個禮拜嘅API額度。呢個問題可解，但需要顯式處理。
「安全邊界。」 有API key、有雲端訪問權限、能夠執行shell命令嘅long-running agent，攻擊面遠大過一次聊天會話。大腦/執行分離嘅意義之一就喺呢度——模型生成嘅代碼跑喺冇辦法接觸到憑證嘅沙箱裏面。
「目標漂移。」 經過多個context window，agent嘅原始目標會被摘要、再摘要，逐漸失真。呢個係agent「去做咗我冇叫佢做嘅事」最常見嘅原因，亦係hooks同judge機制存在嘅核心理由之一。
「驗收係一個真實嘅人力問題。」 24小時嘅自主行為，靠人嚟審計嘅成本好高。結構化產出（PR、commit、測試報告、簡報）係令呢件事可行嘅唯一方式。冇呢啲，你就只能睇日誌，然後漏咗重要嘅嘢。
最後
Anthropic、Google、Cursor最終都收斂咗去同一個形狀：「將模型循環、執行沙箱、持久化會話日誌三件事分開。規劃同生成分開。生成同驗收分開。記憶變成可查詢嘅託管服務，供任何一次agent調用檢索。」
表面區別係商業包裝：Google嘅版本適應企業級審計需求，Anthropic嘅版本係「我哋嘅harness，幫你託管咗」，Cursor嘅版本係「長任務由IDE度拎出嚟放到雲端」。
但底下嘅模式係一樣嘅。
「聊天窗口同真正嘅AI同事之間嘅距離，唔係更好嘅模型，而係狀態、會話同結構化交接。」 呢個係而家最值得花時間學嘅地方。
METR有一條數據值得記住：frontier model以50%可靠性完成嘅任務時長，大約每7個月翻一倍。按呢條曲線，日級任務喺2028年。年級任務喺2034年。
模型嘅能力曲線係客觀嘅，能夠唔能夠駕馭佢，取決於你對狀態管理呢件事嘅理解有幾深。
❝原文連結：https://addyosmani.substack.com/p/long-running-agents
❞
你有沒有遇到過這種情況：
給AI佈置了一個稍微複雜的任務，看着它一步步執行，結果到了關鍵節點，context window滿了。要麼重頭來過，要麼花半小時把上下文喂回去——然後它又犯了上一輪剛改掉的錯誤。
這不是你的問題，也不是模型太笨。這是一個架構問題。
而這個架構問題，現在正在被系統性地解決。
我們都活在"單次會話"的幻覺裏
過去兩年，大家對AI agent的想象，基本上是這樣的：打開一個對話框，輸入目標，agent調用工具，token流過屏幕，任務完成。
這個範式的天花板很明顯：「模型會忘記。」 它在第九輪剛修的bug，第十八輪可能重新引入。它在上下文快滿的時候宣佈"任務完成"，即使工作只完成了30%。整個系統的設計假設，你和AI都坐在同一張桌子前，不會離開。
但真實的工作不是這樣的。
真實的工作是：一個功能開發需要3天，一份競品分析需要通宵，一個數據遷移任務需要在後台跑一週。這些任務需要的是一個「能持續推進、能從失敗中恢復、能在不同會話間保持記憶」的agent——而不是一個更聰明的聊天窗口。
這就是Long-running Agent要解決的問題。
三堵牆，攔住了所有想認真用AI做事的人
研究這個方向的工程師和研究者，幾乎無一例外會撞上同樣三堵牆。
「第一堵：Context有上限，還會腐化。」
就算是100萬token的上下文窗口，也會裝滿。更麻煩的是，還沒裝滿之前，模型的表現就已經開始下降了——這個現象叫做context rot（上下文腐化）。一個24小時的運行任務，不可能塞進任何一家廠商規劃路線圖上的context window。必須有別的解法。
「第二堵：新會話，白板開始。」
Anthropic在一篇研究文章裏用了一個很準確的比喻："想象一個軟件項目，工程師輪班工作，但每個新來的工程師對上一班發生了什麼一無所知。" 沒有顯式的持久化機制，每次會話交接就是一場生產力災難。
「第三堵：模型給自己打分，永遠打高分。」
讓模型自己判斷"任務完成了嗎"，它說"完成"的概率遠高於應該的水平。沒有獨立的驗證信號，你就會得到一個以30%完成度交付、卻充滿自信的agent。
Long-running Agent的設計，本質上都是在回答這三個問題。
最簡單的解法：agent是失憶的，但文件系統不是
在大廠開始發佈託管運行時之前，有一批工程師用極簡的方式解決了這個問題。
其中流傳最廣的是一個叫「Ralph Loop」的模式，核心實現就是一個bash腳本：
從任務列表裏取下一個未完成的任務 把任務、相關上下文、歷史進度餵給agent 調用agent執行 跑測試或其他驗收邏輯 把結果追加寫入 progress.txt更新任務狀態（完成/失敗/阻塞） 回到第1步
聽起來很樸素。但它有效，原因在於一個核心洞見：
「agent本身是失憶的，但文件系統不是。」
prd.json是計劃，progress.txt是實驗記錄，AGENTS.md是滾動更新的規則手冊。每次agent"醒來"，都從文件裏重建足夠的狀態來繼續工作。agent失憶沒關係，重要的東西存在外面。
這個模式的變體被獨立地重新發明了很多次。Anthropic、Google、Cursor後來發佈的各種託管運行時，底層邏輯和這個bash腳本驚人地相似——只不過加上了生產級的可恢復性、安全性和可觀測性。
三大廠商的方案：殊途同歸
最近幾個月，Anthropic、Google、Cursor相繼發佈了自己的long-running agent方案。拆開來看，結構高度趨同。
「Anthropic的答案：大腦/執行/會話，三件事分開」
Anthropic在工程博客裏提出了一個"decoupling"框架：把agent拆成三個可以獨立替換的部分。
「Brain（大腦）」：模型本身，加上調用它的harness循環 「Hands（執行）」：沙箱化的臨時執行環境，工具在這裏實際運行 「Session（會話）」：每個思考、工具調用、觀察結果的追加式事件日誌
這三件事解耦之後，好處是具體的：容器崩潰不等於會話丟失，新容器調用wake(sessionId)就能從日誌裏重建狀態。Anthropic報告這個設計讓p50的首token延遲下降了60%，p95下降超過90%——因為可以在沙箱準備好之前就開始推理。
最值得劃線的一句話："harness裏的每個組件，都編碼了一個關於模型做不到什麼的假設。" 當模型能力提升，之前繞過它的假設就需要更新。解耦讓你可以只改一個組件，而不是整個系統推倒重來。
「Google的答案：把基礎設施變成名詞」
Google在Cloud Next '26上把Vertex AI整合進了「Gemini Enterprise Agent Platform」，把long-running agent變成了有名字、有SLA的產品。
幾個關鍵組件：
「Agent Runtime」：支持"自主運行數天"的agent，冷啓動時間低於1秒 「Agent Sessions」：持久化對話和事件歷史，可以綁定你自己的CRM或數據庫ID 「Memory Bank」：長期記憶層，從會話中提煉記憶，按用戶身份索引，供下次調用檢索
一個財務SaaS公司Payhawk報告，用Memory Bank支持的agent處理費用報銷，提交時間縮短了50%以上。
「Cursor的答案：規劃者、執行者、裁判，各司其職」
Cursor在博客裏記錄了一個有意思的失敗歷程。他們的第一版是平等地位的多agent協調模型，結果agent們都變得保守，在鎖文件上內卷，不敢提交。第二版換成樂觀併發控制，去掉了瓶頸，但協調問題沒解決。
第三版才跑通，設計是：
「Planners」：持續探索代碼庫，生成任務，可以遞歸生成子規劃者 「Workers」：專注的執行單元，不協調、不關心全局 「Judges」：決定一輪迭代何時結束、何時重啓
Cursor的發現裏有一條出人意料："系統行為很大程度上取決於我們怎麼寫prompt，而不是harness或模型。" 而且不同模型適合不同角色——他們發現GPT模型在長期自主工作上表現反而優於Opus，因為Opus更容易提前收手或走捷徑。「同一任務，不同角色，換不同模型。」 這本身已經成為設計的一部分。
你今天就可以用的實操指南
理論說完了，回到實際。根據你的場景，起點不一樣：
「如果你是開發者，想讓AI幫你處理自己的代碼庫：」
直接用Claude Code、Cursor或類似工具，harness已經內置了。你需要做的是：
像飛行員檢查清單一樣維護你的 AGENTS.md——每一行都應該是真實踩坑換來的agent開始之前，先寫一個計劃文件，帶明確的完成標準 agent說"完成了"但你不確信時，用Ralph Loop——讓它循環一遍"這真的做完了嗎" 多小時或隔夜的任務，在worktree裏跑，讓它每完成一個有意義的單元就commit
「如果你在搭建一個託管的agent產品：」
別自己造運行時。現在有三個真實選項：Google的Agent Platform（Agent Engine + Memory Bank + Sessions）、Claude Managed Agents，或者基於ADK/Claude Agent SDK自搭。取捨很標準：託管方案幫你解決大腦/執行/會話三分離、可觀測性、身份認證、審計日誌；自搭讓你用奇怪的模型做奇怪的事（Cursor的玩法）。大多數團隊的起點應該是託管運行時加上自己寫的循環邏輯。
「如果你做的是無人值守的自動化任務（監控、研究、運營）：」
這裏Memory Bank風格的持久化是你真正需要的，也是Claude Code沒有提供的。ADK + Memory Bank + Cloud Run + Cloud Scheduler是目前我見過最乾淨的組合，適合"每N小時跑一次、積累狀態、閾值觸發告警"這類場景。這裏Cursor的planner/worker/judge分層也比IDE編程場景更有價值，因為任務真的是並行的，失敗模式也不一樣。
有幾件事，還是真的沒解決
不誇大進展：這個方向有幾個問題目前還是硬骨頭。
「成本。」 一個用frontier模型運行24小時、調用幾十種工具的agent，燒錢速度超出大多數人的預期。沒有預算上限和熔斷機制，agent可能用一個下午燒掉一週的API額度。這個問題可解，但需要顯式處理。
「安全邊界。」 有API key、有云訪問權限、能執行shell命令的long-running agent，攻擊面遠大於一次聊天會話。大腦/執行分離的意義之一就在這裏——模型生成的代碼跑在無法觸碰到憑證的沙箱裏。
「目標漂移。」 經過多個context window，agent的原始目標會被摘要、再摘要，逐漸失真。這是agent"去幹了我沒讓它乾的事"最常見的原因，也是hooks和judge機制存在的核心理由之一。
「驗收是個真實的人力問題。」 24小時的自主行為，靠人來審計的成本很高。結構化產出（PR、commit、測試報告、簡報）是讓這件事可操作的唯一方式。沒有這些，你就只能翻日誌，然後漏掉重要的東西。
最後
Anthropic、Google、Cursor最終都收斂到了同一個形狀：「把模型循環、執行沙箱、持久化會話日誌三件事分開。規劃和生成分開。生成和驗收分開。記憶變成可查詢的託管服務，供任何一次agent調用檢索。」
表面區別是商業包裝：Google的版本適配企業級審計需求，Anthropic的版本是"我們的harness，幫你託管了"，Cursor的版本是"長任務從IDE裏拿出來放到雲上"。
但底下的模式是一樣的。
「聊天窗口和真正的AI同事之間的距離，不是更好的模型，而是狀態、會話和結構化交接。」 這是現在最值得花時間學的地方。
METR有一條數據值得記住：frontier model能以50%可靠性完成的任務時長，大約每7個月翻一倍。按這條曲線，天級任務在2028年。年級任務在2034年。
模型的能力曲線是客觀的，能不能駕馭它，取決於你對狀態管理這件事的理解有多深。
❝原文連結：https://addyosmani.substack.com/p/long-running-agents
❞