凌晨一點，Coding Agent 還在跑。它已經改了 12 個檔案，測試紅過兩次，現在停在第三輪修正。啟動任務的人下線了，另一位工程師打開 session，對話紀錄一行不少，卻沒人敢按下 Continue。
接手者真正缺的是幾個很具體的答案：目前這批修改從哪個 commit 開始，最後通過哪一個檢查，哪些動作可以安全重跑。Agent 還有權限碰哪些路徑？繼續執行會不會直接部署，或再燒掉一筆額外用量？對話紀錄通常回答不了這些事。
Session 可以續接，不代表工作可以接手。
當 Coding Agent 從一次性的問答工具，變成能跨視窗、跨應用持續運作的 session，團隊需要管理的也不再只有 prompt。它更像一個短命但真的會動手的服務：有負責人、有狀態、有執行預算，也要有交接方法。
GitHub 在 2026 年 8 月整理的 VS Code Copilot 更新裡，已經把 agent session 當成可管理的工作單位。Agents window 可以整理 session、查看 prompt 與檔案變更、續接外部的 Copilot 或 Claude session，也能讓多個 VS Code 視窗連到同一個 session。介面甚至會列出不同模型的 token usage。
這些功能解決了「工作狀態放在哪裡」的一部分，卻沒有替團隊回答「誰對這個狀態負責」。看得到 diff，不等於知道 diff 是否可信；看得到 token 數量，也不等於知道預算該在哪裡停。
GitHub 另一份變更預告把這件事說得更明白。官方表示，不早於 2026 年 9 月 28 日，部分 Copilot 體驗與政策會陸續統一，內容涉及 agent session、聊天資料保留、sandbox、code review effort 與計費。這些變更在本文完成時仍是預告，不能當成所有功能都已全面生效。不過它已經透露一件事：Agent 的工作介面與管理政策正在綁得更緊。
一份分析 2021 年 1 月到 2026 年 6 月 VS Code GitHub issues 的預印本，也從 25,227 筆過濾後的討論中看到類似摩擦。開發者談的不只有生成品質，還包括 agent management、configuration、reliability、authentication 與 billing。這份資料只來自 VS Code 的 issue tracker，不能代表整個產業；但拿來提醒團隊別只盯著模型能力，已經很夠用了。
Coding Agent 上線時，我會要求每個可持續執行的 session 留下一份小型 contract。下面這份不是 GitHub 官方 schema，只是一個團隊可以自行落地的起點。它不需要做成另一套大型平台，甚至可以先是一個跟著工作目錄走的 YAML 檔。值班的人不用重讀幾百輪對話，也能找到最後一個可信狀態。
ryanvale
session_id: checkout-refactor-0911
status: waiting-for-human
session_owner: alice
task_scope:
goal: "拆分 checkout 驗證流程"
allowed_paths: ["src/checkout/**", "tests/checkout/**"]
authority_budget:
allowed_tools: ["editor", "test-runner", "git-diff"]
forbidden_actions: ["merge", "deploy", "read-secrets"]
evidence_checkpoint:
base_commit: "8f31c2a"
changed_files: "artifacts/changed-files.txt"
last_verified_command: "pnpm test checkout"
result: "18 passed, 1 failed"
artifacts: ["artifacts/checkout-test.log"]
stop_condition: "同一測試失敗兩次，或需要修改 allowed_paths 以外的檔案"
takeover_trigger: "owner 離線、預算用完，或發現不可逆動作"
retention_and_cost_budget:
expires_at: "2026-09-12T09:00:00+08:00"
max_additional_tokens: 50000
這份 contract 裡，session_owner 指的是對這次執行結果負責的人，未必是最後一個打字的人。Owner 離線不代表 session 必須立刻終止，但系統要因此觸發交接，不能假裝責任仍在線上。
task_scope 與 authority_budget 也要分開。前者限制 Agent 要完成什麼、能改哪裡；後者限制它可以呼叫哪些工具，以及哪些動作一律禁止。只寫「修好 checkout」太寬，因為 Agent 可能為了讓測試變綠，順手改到付款模組、CI 設定，甚至測試本身。
evidence_checkpoint 則是整份 contract 最值得先做的欄位。它至少要留下 base commit、實際變更檔案、最後執行且可重現的檢查，以及原始輸出位置。摘要可以幫人快速閱讀，但不能取代證據。Agent 說「測試大致通過」沒有用；18 passed, 1 failed 和完整 log 才能讓下一個人接著判斷。
stop_condition、takeover_trigger 與 retention_and_cost_budget 把「何時不要再做」寫清楚。這比再補一段聰明的 prompt 更有用。很多失控跟 Agent 會不會修無關；同一個失敗被包成不同嘗試反覆執行，時間、token 和人工審查量就一起超支了。
聊天紀錄回答的是「剛才說過什麼」，return point 回答的是「現在可以從哪裡安全繼續」。兩者差很多。
我傾向先把 session 壓成三種操作狀態：
running：Owner 仍在線，執行沒有超出 scope 與 budget，最新 checkpoint 可以重現。waiting-for-human：碰到權限、風險、成本或證據缺口，Agent 不應自行 retry。safe-to-resume：已留下完整 return point，另一位操作者可以確認後接手。safe-to-resume 只表示交接資料足夠，不保證程式已經沒問題。只要 base commit、changed files、最後驗證指令或 open risk 缺一項，狀態就不該是 safe。讓 Agent 多跑一次，也補不回缺掉的脈絡。
這裡也值得把 summary 和 evidence 分開。Summary 可以寫：「checkout 驗證拆成兩層，剩下一個時區測試失敗。」Evidence 則必須指向 commit、diff、指令與 log。前者讓人知道要看哪裡，後者才讓人知道該不該相信。
真正接手一個 session 時，我會照固定順序做四件事。
先確認目前 workspace 的 base commit 跟 contract 一致。接著對照 changed files 閱讀 diff，確認修改沒有越過 scope。第三步是檢查最後一個驗證指令是否可重現、是否沒有外部副作用，再由接手者親自跑一次。最後才看 open risk，決定下一個可逆動作。
任何一步對不上，就把狀態退回 waiting-for-human。不要讓新接手的人用「再跑一次看看」猜測舊 session 的狀態，因為 retry 可能覆寫 log、改變測試資料，或讓第三方 API 再執行一次。越是長時間運作的 Agent，越需要保留失敗現場。
這套流程看起來保守，實際上會讓交接更快。你不必從第一句 prompt 考古，只要驗證 contract 指向的幾個事實，就能決定繼續、回退或關閉 session。
台灣已經有實作活動把 Agent Mode、MCP 與 Agentic Workflows 放進同一套工作坊。工具教學當然有用，但團隊真的準備上線時，選哪個模型只是清單前半段。
後半段要問的是：誰擁有 session？政策由誰設定？資料保留多久？額外用量在哪裡停？哪一種變更一定要人工 review？原 Owner 離線或執行失敗時，誰能在不破壞現場的情況下接手？
我會用一個很土但有效的標準驗收：找一位沒有參與這次任務的工程師，給他五分鐘。如果他能說出目前 base、已改範圍、最後一筆可靠證據、尚未排除的風險，以及下一個可逆動作，這個 session 才算可交接。
Coding Agent 流程成熟到什麼程度，可以留到隔天早上再驗收。換一個人坐下來，如果他仍能立刻說出工作停在哪裡、證據是什麼，以及下一步是否可逆，這一晚才不算只留下沒人敢碰的 session。
iThome鐵人賽
看影片追技術