AI 代理服務重啟後能否接續工作，取決於已保存的狀態，以及未完成工具呼叫能否安全重做。Earendil 於 2026 年 10 月 1 日隨 Pi 1.0 發布實驗性套件 Pi Durable，目標是讓長時間代理應用保存進度，並在程序中斷後恢復。團隊需要判斷哪些工作會因重啟而遺失、持久化能接回哪一段，以及整合時要承擔哪些責任。
一、Pi Durable 要處理的中斷問題是什麼？
因為對話紀錄、任務進度與應用資料是不同狀態，單獨保存對話不代表工作流程能從中斷點恢復。 Pi Durable 將每一步任務與狀態變更寫入儲存，讓程序重開後能找到未完成工作。
一般代理程式會把使用者訊息、模型回覆和工具結果排成對話紀錄。這份紀錄可以讓系統在下一次請求時看見先前談過什麼，卻未必知道外部工作做到哪裡。例如代理已建立雲端資源，但還沒把資源編號寫回對話；或它已送出工單，卻在收到回覆前遇到部署重啟。重新讀取對話只能找回文字，無法自動判斷外部操作究竟完成、失敗，還是只完成一半。
因此需要分開看三件事：對話紀錄保存模型與使用者交換的內容；任務進度記錄工作目前所在階段、等待條件和重試狀態；應用狀態則包含訂單、計畫、工單、沙盒位置等業務資料。三者如果分頭寫入，中間發生故障，就可能出現「紀錄顯示已完成，外部操作尚未完成」或「工作已建立，對話卻沒有結果」的落差。這種狀態不一致，才是恢復流程需要處理的根因。
Pi Durable 把代理中的模型請求、工具呼叫和自訂工作都視為任務，並將對話與應用文件放在同一套提交機制中。官方設計的目標，是讓一次提交中的紀錄和相關資料保持一致；它並不表示外部服務、資料庫或作業系統的副作用都能自動回滾。恢復範圍仍取決於團隊把哪些資料放進持久化儲存，以及工具與外部系統如何配合。
二、Pi Durable 如何保存進度並恢復任務？
Pi Durable 會在任務推進時保存檢查點；程序重開並連回同一份儲存後，未完成任務可從最後保存的位置繼續。 模型請求會重新送出，工具呼叫則依開發者標記的重播安全性處理。
檢查點可以理解為工作流程的已提交進度。代理收到新工作後，任務會按階段記錄狀態；程序意外退出時，下一個程序開啟相同儲存，就能找到未完成任務並接續排程。官方文件列出記憶體、SQLite 與 JSONL 等儲存選項，也說明儲存介面可由其他後端實作。這些方式的恢復能力並不相同：記憶體儲存適合示範或測試，程序結束後資料也隨之消失；要跨程序重啟，就必須使用能保留資料的後端，並確保新程序連到正確的資料位置。
模型請求與工具呼叫的中斷處理也不同。若模型生成途中程序結束，重新開啟後會再次送出請求；已收到的部分內容會留在對話紀錄並標示為中止。至於工具，Pi Durable 會先記錄呼叫意圖，再執行工具。工具若被宣告為可安全重播，恢復時可以再執行；若沒有這項標記，系統會將中斷狀態與已保存的輸出告知模型，由模型決定後續處理，而不是預設再做一次。
「可以重播」必須由工具設計者負責判斷。查詢工單或讀取檔案通常只讀取資料，重跑較容易控制；寄出通知、建立付款、部署服務等操作則可能產生重複副作用。即使工具呼叫結果尚未寫回，外部服務也可能早已完成動作。可行做法包括使用冪等鍵、以任務識別碼去重、先查詢外部操作結果，或將補償流程納入設計。Pi Durable 提供任務與提交的框架，不能代替外部系統本身的交易保證。
「工具只有在明確標示可安全重播時，才會在重新開啟後重跑。」Pi Durable 官方套件說明
三、一般代理框架與持久化執行的差異在哪裡？
差別在恢復範圍與責任位置：只存對話的流程通常要由應用自行推斷下一步，持久化執行框架則保存任務狀態並管理未完成工作，但仍需要應用端處理外部副作用與資料版本。
| 比較面向 | 主要保存對話的代理流程 | Pi Durable 所描述的持久化執行 |
|---|---|---|
| 保存範圍 | 對話訊息與部分應用自訂資料 | 對話、模型與工具任務、提交中的應用文件 |
| 程序重啟後 | 應用需自行找紀錄、判斷任務是否完成 | 連回同一份持久化儲存後恢復未完成任務 |
| 工具中斷後 | 由應用自行決定查詢、重試或停止 | 可安全重播的工具會重跑；其他工具回報中斷狀態 |
| 開發責任 | 保存對話並自行實作恢復流程 | 定義任務、文件、工具重播規則與外部副作用處理 |
| 主要風險 | 文字紀錄和外部實際狀態脫節 | 儲存或工作階段可恢復，但外部操作仍可能重複或不一致 |
這個比較描述的是兩種設計責任，不代表一般代理框架完全不能恢復，也不表示持久化框架可以涵蓋所有故障。團隊可以在既有程式裡自行建立檢查點、任務佇列和重試邏輯；Pi Durable 的價值在於把這些概念組織成一套代理執行機制，讓開發者可沿用其任務、對話和文件模型。是否省下工程工作，仍要看現有系統已經有哪些元件、使用的儲存後端及工具的種類。
另一個容易混淆的部分是應用狀態。Pi Durable 文件描述以具型別的 JSON 文件保存待辦清單、計畫或工單等資料，並讓文件與對話紀錄在同一個提交中更新。這能降低兩份內部資料各自成功或失敗的機會；但若應用的真實狀態在外部 CRM、支付平台或自建資料庫，文件同步與衝突處理仍須安排。開發者也要確認文件版本變更、對話分支，以及程序更新後舊任務如何由新版本程式接手。
此外，對話提交可使用 requestId 辨識重送，讓客戶端在不確定請求結果時再次提交，並取得原有提交。這解決的是框架內的重複提交問題，不能直接推論第三方服務端的付款、寄信或部署也具備「恰好一次」保證。操作是否重複，仍要在外部服務加上自己的冪等設計或結果核對。
四、哪些代理流程值得評估 Pi Durable？
需要跨越長時間等待、部署重啟或多個可恢復階段的流程，較值得評估 Pi Durable；短時間、容易從頭重做且沒有昂貴副作用的工作，通常先用簡單的工作佇列或重試設計即可。
適合優先盤點的情境，通常能指出明確的中斷成本。例如代理要等待人工核准或第三方 API 回應，等待時間可能比單次模型互動長；代理依序搜尋資料、產生草稿、等待審閱，再執行下一個工具；或者工作所在服務會定期部署，程序重啟時不能要求使用者重新輸入整份任務。這些流程若目前常發生狀態遺失、重工或人工追查，持久化任務模型可能值得做小型試驗。
相反地，若一次工作只需幾秒，輸入資料可重新取得，重跑不會重複收費或對外產生副作用，保存整條代理歷程可能增加不必要的儲存、版本與維護工作。也可能既有工作佇列已經負責任務狀態，應用在重新派工時能安全接手，那麼新增另一套執行管理層就必須證明有額外價值。
判斷時要問的不是「代理是否可能中斷」，因為任何服務都可能遇到故障，而是「中斷後最需要找回的狀態是什麼、遺失會造成什麼成本」。如果答案只有聊天上下文，保存對話也許就足夠；如果要接續一段數小時的工作，就需要檢查任務進度；若結果涉及交易或對外動作，重點會轉向副作用去重、狀態核對和人工介入。不同失敗原因需要不同恢復方法。
五、導入前要檢查哪些條件？
先確認持久化儲存與執行環境能否接回原工作，再逐一驗證工具的重播安全性、資料版本相容與故障後的外部狀態。 官方資料將 Pi Durable 標示為實驗性套件，API 可能變動，因此應以隔離的測試流程評估整合與維護成本。
第一項是儲存與執行環境。程序退出後要能使用相同資料庫或檔案，執行環境也要能找到當時工具需要的檔案、工作目錄或遠端資源。官方介紹列出記憶體、SQLite 與 JSONL 儲存，以及 Node 執行環境；可用的適配方式不等於團隊的正式環境已經通過驗證。若服務跑在多個容器或無伺服器環境，需要釐清哪一個程序持有儲存、其他客戶如何連接，以及程序移轉時如何避免同一工作被兩邊同時執行。
第二項是工具與外部副作用。列出每種工具可能產生的影響，標記只讀、可冪等、需去重、不可自動重跑等類別，再檢查故障時點：工具執行前、執行中、外部動作完成但結果尚未提交、結果提交後。尤其最後兩種情況，必須能透過冪等鍵或外部查詢分辨「已完成」與「尚未完成」。若沒有可核對的方法，將呼叫交回模型並不能保證流程不會留下重複操作或半完成狀態。
第三項是部署更新與文件演進。對話保存的是擴充功能名稱等識別資訊，不是整份程式碼；程序重開時需要重新安裝相同名稱的元件，待處理任務才能找到對應實作。若工具輸入格式、任務階段或文件結構改版，舊任務是否仍能被新程式解讀，應列入資料遷移計畫。這也是測試故障恢復時不能只看「資料庫打得開」的原因。
可採用小規模故障演練，逐一在模型回覆中途、唯讀工具執行中、外部寫入後但回應前，以及儲存不可用等位置中止程序。記錄恢復後工作是否重複、資料是否一致、等待中的客戶端能否取得正確狀態，以及人工如何介入。這些結果才能回答系統是否適合自身負載，不能用套件功能介紹替代。
Pi Durable 官方將套件標示為實驗性，並提醒不同發布版本間 API 可能變動。Pi 1.0 的發布也不代表這個新套件已成為成熟或通用的生產標準。團隊要評估鎖定版本、追蹤變更、回退策略與維護人力，並用實際工作負載測試儲存故障、部署重啟、工具重試和不可冪等副作用。現有公開資料主要說明設計與使用方式，無法證明其在不同環境的可靠性、效能或維運成本。
「Pi Durable 是實驗性套件，API 可能在不同版本間變更。」Earendil 官方文件
六、評估結論：從狀態遺失的原因決定方法
先盤點中斷會遺失的資料與未完成的外部操作，再決定是否需要持久化任務框架。 Pi Durable 提供一種保存檢查點和恢復任務的設計，但適用性、可靠性與導入成本仍須由目標環境驗證。
開始試用前，先挑一條中斷後確實會造成重工的流程，記下必須保存的對話、任務階段、業務資料和外部操作結果；接著逐個標註可安全重播的工具，補上冪等鍵或人工確認條件；最後在可回復的測試環境，執行中斷、重啟、版本更新及外部服務逾時情境。若測試顯示主要問題只在對話未保存，先補上對話或佇列機制可能已足夠；若任務跨越多個階段且需要一致恢復，再比較 Pi Durable 與既有執行框架的整合成本。
判斷標準應落在恢復後是否能辨認實際狀態，以及出錯時誰負責停止、重試或補償。把這兩點用可重現的故障演練驗證，才能看出持久化是否解決了原本的中斷問題，而不只是把任務紀錄留得更久。
- 對話紀錄、任務進度與外部應用狀態必須分開盤點，保存對話不等於工作可恢復。
- Pi Durable 以檢查點恢復未完成任務；工具是否重跑取決於重播安全設定與副作用設計。
- 優先用會因長時間等待、程序重啟或跨階段工作而產生高重工成本的流程做試驗。
- 套件仍屬實驗性，需在目標儲存、執行環境和工具上實測恢復能力與維護成本。
- 列出代理工作中斷時必須保留的狀態，以及每項工具可能產生的外部副作用。
- 為可重播工具設計冪等或去重機制，替不可安全重播的工具安排查核與人工介入方式。
- 在測試環境中演練程序中止、服務重啟、儲存故障和工具逾時，記錄恢復後的一致性與重複操作。
常見問題
Q1：Pi Durable 是 Pi 編碼代理本身嗎？
不是。Earendil 將 Pi Durable 描述為建置代理應用的框架，Pi 編碼代理則是另一個產品方向；官方表示新套件不取代 Pi 編碼代理。
Q2：只要使用 Pi Durable，所有工具呼叫都會自動重跑嗎？
不會。工具只有在明確標示可安全重播時，才會在程序重開後再次執行；未標記的中斷呼叫會回報模型處理。工具開發者仍須判斷外部操作能否安全重複。
Q3：Pi Durable 的工作資料放在哪裡？
依設定使用相應的儲存後端。官方文件列出記憶體、SQLite 與 JSONL；要跨程序恢復，需使用能保留資料的儲存，並在新程序重開同一份資料。
Q4：Pi Durable 已能視為正式生產環境標準嗎？
不能。官方將它標示為實驗性套件，並說明 API 可能變動。不同工作負載下的可靠性、效能與維運成本，需由導入團隊自行測試。
