AI 知識
讓長任務從安全位置接著做
當 AI 只能回答問題時，中斷通常不算大事。頁面重新整理，頂多再問一次。
但 Agent 不一樣。它可能需要讀資料、呼叫工具、整理多個步驟，等一個結果回來再繼續。做到一半斷線時，真正的問題不是「模型會不會再回答一次」，而是：它到底做到哪裡了？哪些事已經完成？哪些事不能再做一次？
這就是 Agent runtime，也常被稱為 harness，開始變得重要的原因。
模型會想，不等於任務能持續
語言模型負責理解、推理與決定下一步；但讓 Agent 真正跑起來的，還有另一層 runtime。它管理 session、把模型的決定交給工具執行、收回結果，再讓 Agent 繼續下一輪。
這一層很像任務的記錄員與交通指揮：不是替模型思考，卻決定任務中斷後還能不能被理解、被恢復、被安全地完成。
如果沒有可靠的 runtime，Agent 很容易遇到一個尷尬情境：模型知道下一步該做什麼，系統卻不知道前一步是否真的完成。
「重新開始」和「接著做」差在哪裡
想像一個 Agent 正在進行多步任務：先找資料，再整理內容，最後等待工具回傳結果。程序在中間中斷後，最危險的處理方式就是把整段任務當作沒發生過。
原因很簡單：有些事情可能已經完成，只是回應還沒被系統記下來。此時直接重跑，會讓同一個動作出現第二次。
更可靠的做法是保留三類資訊：
- 工作從哪裡開始：這次任務的目標與起始狀態。
- 已經發生了什麼：工具呼叫、收到的結果、等待中的工作與中止紀錄。
- 下一個安全位置：恢復時要接哪一步，而不是猜一個新的開頭。
這也是為什麼成熟的 Agent 設計會把「接受任務」和「實際執行」分開記錄。任務先被可靠地登記，之後即使程序重啟，也能從留下的狀態判斷該繼續、等待、取消，或明確失敗。
斷線後，系統真正要回答的三個問題
1. 這一步完成了嗎？
如果答案是已完成，就不該再跑一次；如果答案是未完成，才考慮重試；如果答案是不知道，系統更不能假裝知道。
「不知道」看起來不漂亮，卻是可靠設計的重要誠實。對結果未知的外部動作，系統需要用可辨識的工作 ID、可去重的流程或人工確認，避免把不確定直接變成重複。
2. 要從哪裡接回來？
恢復不是再送一次原始指令。好的恢復流程會從最後一個安全 checkpoint 往下走：該補的紀錄補上，該等待的結果繼續等，該重新嘗試的只有尚未完成的那一段。
這讓 Agent 的工作比較像接力，而不是每次掉棒就回到起跑線。
3. 可以同時做幾件事？
並行能讓 Agent 同時處理不同工作，但不能讓同一段狀態被多個動作隨意改寫。一種常見的設計，是把任務分成多條獨立工作線；每條線同一時間只處理一件事，彼此可以並行，但共享紀錄仍有一致的寫入順序。
這個原則沒有聽起來那麼炫，卻能避免「兩個地方都以為自己是最新狀態」的混亂。
為什麼這是下一個 Agent 體驗門檻
我們很快會習慣 Agent 能搜尋、整理、寫草稿、協調工具。接下來真正拉開差距的，會是它在長任務裡是否可靠：
- 中斷後不用把背景從頭交代。
- 等待中的工作不會憑空消失。
- 已完成的步驟不會因重啟而無意義地重做。
- 任務變複雜時，系統仍知道現在輪到誰、下一步是什麼。
模型越強，越不能只看它單次回答得多漂亮。能不能把一串動作留下可恢復的脈絡，才決定 Agent 是一次性的展示，還是能陪你把長任務做完的工具。
查證摘要
- VS Code 將 agent harness 定義為管理 session、工具呼叫與 agent loop 的 runtime，並明確區分 harness、執行環境、角色與模型。
- 一份公開的 Durable AgentHarness 設計則把「可恢復的任務紀錄」、「多條可並行但各自序列化的工作線」與「中斷後從安全邊界恢復」列為核心目標。
- 本文只說明非操作性的可靠性原則；不主張所有 Agent 已具備這些能力，也不保證外部動作可被完全去重。