最近看幾個 AI coding tool 和企業 Agent 平台的演進，我越來越有一個感覺：Agent 的長任務能力已經不只是「能不能丟到背景跑」了。真正的分水嶺，是它能不能在跑到一半時，被安全地停下來、倒回去、接著做，或者乾脆承認這個任務不該再繼續。
這聽起來很像系統工程裡的老問題，沒錯，確實是老問題。只是以前我們把它放在 batch job、workflow engine、message queue、CI pipeline 裡談；現在輪到 AI Agent 進來面對同一件事。
很多展示影片裡的 Agent 都很順：你給它一個目標，它開檔案、查資料、跑測試、改程式、寫報告，最後交付一個漂亮結果。這種 demo 看起來很有未來感，但從技術主管角度，我其實會先問另一組比較掃興的問題：如果它做到一半方向錯了怎麼辦？如果上游資料後來被修正怎麼辦？如果它停了又自己復活怎麼辦？如果使用者按下取消，它到底取消了什麼？
這些問題沒有 demo 友善，卻決定 Agent 能不能進正式流程。
背景執行不是成熟，只是第一步
早期我們談長任務 Agent，常常把焦點放在「不要阻塞主對話」。這當然重要。使用者丟一個要跑二十分鐘的分析、重構或報表任務，不可能要求他盯著同一個 session 等。把任務交給背景 worker、sub-agent 或 queue，是很自然的架構。
但背景執行只解決了互動體驗，沒有解決任務治理。
一個任務跑在前景或背景，對系統來說只是 execution placement 的差異；真正麻煩的是它有沒有清楚的狀態。它現在是 queued、running、waiting approval、blocked、cancelling、cancelled、failed、completed，還是「看起來還活著但其實沒在做事」？如果狀態講不清楚，背景執行反而會讓問題更難發現，因為使用者看不到中間過程，只能等最後結果。
我現在會把長任務 Agent 當成一個狀態型服務看，而不是一段比較長的 prompt。它需要任務 ID、執行紀錄、輸入快照、工具呼叫歷史、成本紀錄、可重試邊界，以及最重要的：停止語意。
停止語意比開始語意更難
「開始一個任務」通常很簡單。收到需求、建立 task、分配 worker、開始執行。真正難的是「停止一個任務」。
停止不是把 process kill 掉就好。Agent 可能已經改了檔案、送出 API 請求、建立草稿、寫入資料庫、排了下一個子任務，甚至正在等待某個外部工具回應。這時候使用者按下取消，系統要回答幾個問題：哪些動作已經完成？哪些動作尚未開始？哪些動作可以 rollback？哪些需要人工確認？哪些只是停止後續，不回復既有變更？
如果這些沒有定義清楚，「取消」就只是一種心理安慰。畫面上顯示任務停了，底層可能還有 worker 在跑；主任務標成 cancelled，子任務卻繼續寫檔；甚至更糟，系統把停止當成失敗，自動重試，結果使用者明明按了停，Agent 過幾分鐘又從某個角落醒來繼續動手。
這種狀況在人類工作裡也很荒謬。你叫同事先不要寄那封信，他點頭說好，結果五分鐘後因為「待辦事項還在」又把信寄出去了。你不會說這個同事很自動化，你會覺得他很可怕。
Agent 也是一樣。
Rewind 不是魔法，是承認過程需要被治理
最近一些工具開始強調 rewind、resume、checkpoint 之類的能力，我覺得方向是對的。這些功能表面上看是使用者體驗：做錯了可以倒回去，中斷了可以接著做。但在更深一層，它其實是在承認一件事：Agent 的工作過程本身需要被建模。
如果系統只保存最後輸出，就沒有真正的 rewind。你頂多要求模型「再產生一次比較好的版本」。但如果系統保存了中間決策、檔案差異、工具呼叫、測試結果、人工指示與狀態轉移，才有機會回到某個可信的檢查點，而不是靠語氣很堅定地說「我會修正」。
對 CTO 來說，這個差異很大。前者是聊天體驗，後者才像工程系統。
尤其當 Agent 開始處理多步驟任務，錯誤常常不是最後一步才發生。可能是一開始理解需求時就偏了，可能是選錯工具，可能是中途讀到過期資料，也可能是某次測試失敗後做了錯誤假設。若沒有中間狀態，最後只能整包丟掉重跑；有中間狀態，才有機會從錯誤前一刻分岔修正。
長任務要有租約，而不是無限生命
我也越來越覺得，長任務 Agent 不該被設計成「一旦開始就永遠有權繼續」。它應該有某種租約概念。
任務開始時，系統給它一段有效執行權限：可以讀哪些資料、可以用哪些工具、可以花多少成本、可以跑多久、可以產生哪些副作用。時間到了、條件變了、上游資料失效了、使用者取消了，租約就要到期。到期後 Agent 不能假裝自己還在原本的授權範圍內。
這跟傳統企業系統的 session、token、lock 很像。差別在於 Agent 的動作更開放，執行路徑更不固定，所以租約要描述的不只是登入狀態，而是任務邊界。
例如一個分析任務可以持續查詢資料、整理結論，但不能自動送出正式文件；一個開發任務可以改本地分支、跑測試，但不能自己 merge；一個營運任務可以草擬通知，但發送前需要人確認。這些都不只是權限設定，也是長任務生命週期的一部分。
生產環境需要的是可預期，不是永不失敗
我不期待 AI Agent 永遠不犯錯。說真的，人類也做不到。真正該追求的是：犯錯時能不能看得見、停得住、回得去、說得清楚。
這也是我看長任務 Agent 成熟度時最在意的地方。它不一定要一次把所有事做完，也不一定要每次都產出完美答案。但它要讓我知道現在跑到哪裡、為什麼卡住、接下來打算做什麼、哪些變更已經落地、哪些只是暫存，以及我按下停止後會發生什麼事。
企業導入 AI 時，大家很容易被「它可以自己完成一整串工作」吸引。這當然迷人，尤其對小團隊來說，長任務 Agent 真的可能補上很多人力缺口。但越是讓它跑得遠，越不能只靠信任模型本身。模型能力會進步，工具也會變多；最後真正決定能不能放心使用的，會是這套工作流有沒有把狀態、權限、停止、回復與稽核設計進去。
對我來說，AI Agent 進 production 的成熟指標不是「它可以背景跑三小時」。那只是開始。
更成熟的指標是：它跑到一半被叫停時，不會裝死，也不會偷偷復活；它做錯時，可以回到可理解的檢查點；它重試時，知道哪些事不能重做；它交付時，不只給結果，也交代過程。
會跑的 Agent 很酷。停得下來的 Agent，才比較像可以交付給真實世界的系統。