整理約 20 個來源、分類約 30 則客戶訊息、修改程式碼並執行測試，以及讀取客戶資料後準備回覆，都是這一課所說的「長任務」。判斷重點不是經過幾分鐘，而是工作形狀：輸入很多、包含多個彼此相依的步驟、途中可能重試或遇到資料變動，而且只看最後答案不足以安全驗收。
這類任務開始後，AI 可能持續讀取資料、重建上下文，遇到失敗便自動重試。幾輪之後，沒有人能立即回答三個問題：已經花了多少、應該在哪一步停止，以及最後由誰負責驗收。對小團隊來說，真正的風險不是模型能不能多跑幾步，而是工作範圍不斷擴大，成本與責任卻沒有明確邊界。
Grok 4.5 這類新模型，會讓原本太貴、太慢或容易中斷的長任務看起來更值得嘗試。SpaceXAI 發表 Grok 4.5 後，TechCrunch 與 Engadget 都把焦點放在模型能力、價格定位，以及 coding（程式開發）／agentic work（AI 負責多步驟任務）的應用想像上。但無論採用哪個模型，小團隊都不該先從 benchmark（模型基準測試）或「可以跑多久」開始決定。
更實際的起點，是先界定每一類任務可以消耗多少 token、保留多少上下文、重試幾次，以及何時必須交給人工批准。token 是模型切分與處理文字時使用的基本單位，使用量會影響成本與上下文容量；agent 則可先理解成會自行連續執行多個任務步驟的 AI 助手。當兩者結合，沒有上限的讀取、修改與重試，很容易把一次試跑變成無人掌握的持續支出。
因此，研究摘要、文件整理、程式修改與客服草稿不能只用「都交給 AI 跑久一點」來規劃。它們需要不同的任務級別、停止條件與驗收責任；模型能力再強，也不能代替團隊事先定義這些界線。
這一課不評測 Grok 4.5，也不替任何模型背書。我們要做的是一件更耐用的事：在你把任何長任務模型接進團隊 workflow（一連串固定交接步驟）前，先設定一張可以直接套用的 token 與成本上限表。
In this lesson
你會帶走三件事：
- 一張「任務分層 × 上限設定」決策表，用來決定哪些任務可以自動跑、哪些必須人工批准。
- 一個 5 步驟接入流程，避免一開始就把長任務 agent 放進正式資料與發布流程。
- 一張 AI 整理卡，讓你可以把自己的任務清單丟給 AI，請它幫你產生第一版成本護欄。
先分清楚：長任務 AI 不是單一開關
很多團隊在試新模型時，會把問題問成：「這個模型要不要開給大家用？」
這種問法太粗。比較好的問法是：「哪一類任務可以讓它自動跑到結束？哪一類任務只能跑到草稿？哪一類任務每一步都要人確認？」
例如，同樣是 AI agent：
- 幫你整理 20 篇公開資料，輸出研究摘要，是一種任務。
- 幫你改程式碼儲存庫裡的程式碼，開 pull request（提交程式變更後經由審核合併），是另一種任務。
- 幫你讀客戶資料、寄出回覆、更新 CRM（客戶關係管理系統），又是完全不同的風險層級。
如果你正在讓 agent 寫程式，可以搭配看這篇：讓 AI agent 寫程式前，先把檢查點放進任務裡。那篇處理「任務中要放哪些停點」，這篇則補上「每個停點前最多可以花多少 token、多少錢、重試幾次」。
一張表決定：任務可以跑多遠、花多少、何時停
下面這張表可以直接拿去開會用。它提供的是一組起始門檻，不是固定答案。你可以先用保守版本跑兩週，再依實際成本調整。
本表格裡的「一次任務執行」是從第一個請求到任務停止或完成，會包含同一任務中的每一次模型呼叫。token 用量為整段過程所有輸入與輸出 token 的累加值。重試不會重新拿到新預算，必須仍然受同一個總 token 上限與總成本上限約束。
| 任務層級＋例子 | 執行上限 | 停止點＋人工責任 |
|---|---|---|
| L1：低風險草稿（會議逐字稿整理、公開文章摘要、內部文件改寫） | 20,000 tokens / US$1 / max 1 retry；所有重試共用同一個累積 token 與總成本上限 | 輸出要寄給外部或貼到公開頁面前，由負責人審核並批准 |
| L2：中風險分析（競品資料整理、客服案例分類、規格文件比對） | 60,000 tokens / US$5 / max 2 retries；所有重試共用同一個累積 token 與總成本上限 | 需要影響產品決策、客戶承諾或排程時，由負責人批准 |
| L3：高風險變更（修改程式碼、批次改資料、產生合約或政策草稿） | 100,000 tokens / US$10 / max 1 retry；所有重試共用同一個累積 token 與總成本上限 | 寫入程式碼儲存庫、資料庫、合約、付款或權限系統前停止；由負責人檢查修改前後差異、測試結果、影響範圍，以及失敗時如何還原 |
| L4：建議／草稿專用（刪除資料、寄出正式通知、改帳務、批准退款、升級權限） | 20,000 tokens / US$1（建議／草稿） / max 0 retries；自動副作用權限：無 | 一旦涉及刪除、付款、正式通知、權限升級就停止；副作用執行權限與副作用執行預算皆為零，由負責人審核建議後親自執行 |
這張表有幾個重點。
第一，token 上限和成本上限要同時存在。只設成本上限，可能會讓模型在便宜但超長的上下文裡讀進太多資料；只設 token 上限，可能遇到高價模型時仍然超支。兩個上限一起設，才比較不會失控。
第二，重試要算進預算。很多長任務 agent 的花費往往來自失敗後自動重試、重新搜尋、重新整理上下文。若你允許 L2 任務重試 2 次，所有嘗試都必須在同一個總 token 上限與總成本上限內完成；一旦任一上限命中，任務就要停止。
第三，L4 不該被包成「只要加一句確認字句」。刪除資料、付款、正式通知、權限升級等不可逆後果牽涉到的任務，不應交由 AI 自動完成。AI 可以在獨立的建議／草稿上限內整理選項與產生草稿；但凡涉及刪除、付款、正式通知或權限升級，副作用執行權限與副作用執行預算都必須是零。最終操作由負責人審核後親自執行。
如果你的 agent 還會碰到身份、權限、理由與後果判斷，可以接著看：AI agent 授權四問表：身份、權限、理由、後果。成本護欄管「花多少」，授權護欄管「能做什麼」。兩個要一起存在。
5 步驟接進小團隊工作流
有了上限表，下一步不要立刻開放給全公司，先用一條小路徑試跑。以下流程適合 3 到 20 人的小團隊，尤其是還沒有專職 AI 基盤團隊的情境。
1. 先挑一個「輸出可檢查」的長任務
第一個任務不要選「幫我變聰明一點」這種結果模糊的需求。請選輸出可檢查、失敗可回收的任務，例如：
- 把 15 份公開文件整理成一頁摘要。
- 把 30 則客服訊息分成 5 類，並列出每類 3 個代表案例。
- 讀一個小型 pull request，列出可能需要人工看的檔案。
- 將內部 SOP 改寫成新人版，但不直接發布。
判斷標準很簡單：如果輸出錯了，你能不能在 10 分鐘內看出來？如果不能，這不是第一個試點任務。
2. 替任務寫明「最多讀什麼」
長任務很容易把上下文吃滿。上下文可以理解成 AI 當下能讀到、記住並用來推理的材料。它讀得越多，不一定越準；資料範圍不清楚時，反而更容易混入過期資訊或無關內容。
你可以在任務規格中明寫：
- 只能讀指定資料夾或指定 URL。
- 單次最多讀 10 個檔案。
- 每個檔案只讀標題、摘要、最近 30 行變更，除非負責人批准。
- 不得讀客戶個資、金流資料、密鑰、內部薪資或合約原文。
這些限制比「請小心處理」有用，因為 agent 可以被程式化地擋下來。
3. 設定 dry-run 與正式執行的差別
dry-run（無變更資料與不發布的試跑）是先試跑但不真的改資料或發布。長任務 agent 第一次進工作流時，預設應該只能 dry-run。
例如 coding agent 可以：
- 讀 issue（指定待處理任務或需求單）。
- 找相關檔案。
- 提出修改計畫。
- 產生 patch 草稿（對應變更草案）。
- 跑測試建議。
但不能直接：
- push 到主分支。
- 合併 pull request。
- 改 production config（正式環境設定）。
- 發布套件。
文件 agent 也一樣。它可以產生草稿與差異摘要，但不能直接覆蓋正式文件。當你把 dry-run 結果看過 5 到 10 次，且失敗樣態可預期，再考慮開放下一步。
4. 把「停止條件」寫成 if–then
停止條件不要寫成抽象提醒。請寫成 if–then：
- 如果單次任務預估超過該任務階層核定的 token 或成本上限，就先輸出計畫，不進入完整執行；例如 L2 的核定上限是 60,000 tokens，應在預估達到該值前停下來，由負責人決定是否縮小範圍。
- 如果任務已達該層級核定的重試上限仍未完成，就立即停止，記錄最後一次錯誤，並請負責人決定要縮小範圍、改用其他方法，或結束任務。例如 L1 與 L3 重試 1 次後仍失敗就停止；L2 最多可重試 2 次；L4 不得自動重試。
- 如果需要讀取未列在 allowlist（可存取資料來源清單） 的資料來源，就停止並列出原因。
- 如果輸出會改變外部使用者可見內容，就停在草稿狀態。
- 如果任務中出現付款、刪除、權限升級或正式承諾，就只產生建議，不執行。
這些句子可以放進 agent 的 system prompt（模型在執行時載入的系統指令），提醒模型何時應主動停下；但提示詞不是硬性計費器、權限系統或可靠的停止開關。真正的 token、成本與重試上限，必須由模型外的工作流控制器強制執行：控制器累計每次呼叫回報的輸入／輸出 token、工具費用與重試次數，並在下一次呼叫前檢查剩餘預算。若剩餘額不足以容納下一次呼叫，就不再送出請求，只回傳目前結果與待人工決定事項。刪除、付款、正式寄送、發布與權限升級則應直接不授予執行憑證，而不是只在提示詞裡寫「不要做」。
5. 每週只調一個旋鈕
試跑後，你會看到幾種常見結果：
- 任務常常還沒完成就撞到 token 上限。
- 成本很低，但人工驗收花太久。
- 重試次數太多，總成本變得不可預測。
- 低風險任務被擋太多，高風險任務反而太容易進下一步。
請不要一次調全部。每週只調一個旋鈕，例如：
- L1 token 上限從 20,000 調到 30,000。
- L2 重試上限從 2 次降到 1 次。
- L3 從「可產生 patch」改成「只能產生修改計畫」。
- 外部發布前新增一個負責人確認欄位。
小團隊最大的優勢通常來自能很快看見哪個上限太緊、哪個停點太鬆。一次只調一個旋鈕，才知道哪個改動有效。
常見錯誤：把便宜模型當成免費員工
當模型價格下降，團隊很容易犯三個錯。
第一個錯，是只看單次 API 價格。API 是系統和系統之間交換資料的接口。對長任務來說，API 單價只是其中一部分；真正的總成本還包含上下文整理、重試、人工驗收、錯誤修復，以及任務卡住時的排查時間。
第二個錯，是把所有任務都丟進同一個 queue。queue 是待處理清單／排隊中的任務。如果低風險摘要、高風險程式修改、正式客戶回覆都在同一條 queue 裡，agent 很難用同一套規則安全處理。請至少分成「草稿」、「分析」、「變更」、「不可自動完成」四類。
第三個錯，是沒有留下可追溯紀錄。你不需要一開始就做很重的稽核系統，但至少要記錄：任務名稱、模型、輸入資料範圍、token 用量、估算成本、是否重試、最後由誰批准。沒有這些紀錄，兩週後你只會知道「好像有點貴」，卻不知道是哪一類任務在燒錢。
小團隊的第一個可執行版本
如果你今天只能做一件事，請建立一份「長任務 AI 任務申請卡」。不需要買新工具，用 Notion、Google Sheet、Linear、GitHub issue template 都可以。
欄位建議如下：
- 任務名稱：例如「整理 15 份競品公告」。
- 任務層級：L1、L2、L3 或 L4。
- 允許讀取的資料：列出資料夾、URL 或文件名稱。
- 禁止讀取的資料：例如客戶個資、金流、密鑰、內部薪資或合約原文。
- 上下文上限：例如單次最多讀 10 個檔案、每個檔案只讀最近 30 行變更，或最多 40,000 個輸入 tokens。若超出，先產出摘要再請負責人決定是否繼續。
- token 上限：填入表格中的起始值。
- 單次成本上限：填入表格中的起始值。
- 重試上限：0、1 或 2 次。
- 停止條件：至少 3 個 if–then。
- 負責人：誰負責驗收與批准下一步。
- 輸出狀態：只能是草稿、建議、patch、正式執行之一。
這張卡的目的不是增加行政流程；它要讓每個人知道：AI 可以跑到哪裡，哪裡要停，誰要看，花費超過多少就不能繼續。
AI 整理卡
你可以把下面這段直接交給 AI，請它幫你替某一類長任務產生第一版上限。使用時，把方括號改成你的實際情境。
你是我們小團隊的 AI 工作流設計助理。請幫我為以下長任務建立 token、成本、重試與人工批准上限。
任務名稱：[例如：整理每週競品公告]
任務目標：[輸出一頁摘要、分類表、修改計畫、客服草稿等]
可讀資料：[列出資料夾、URL、文件類型]
不可讀資料：[個資、金流、密鑰、合約、未公開財務資料等]
輸出是否會對外可見：[是／否]
是否會修改程式碼、資料庫、權限或付款狀態：[是／否]
團隊可接受的單次人工驗收時間：[例如 10 分鐘]
請輸出：
1. 建議任務層級：L1／L2／L3／L4，並說明理由。
2. 單次 token 上限與單次成本上限。
3. 重試上限。
4. 上下文上限：例如單次最多讀 10 份檔案、每份只看最近 30 行變更，或最多 40,000 個輸入 token；超出時先摘要再請負責人決定是否繼續。
5. 至少 3 個 if–then 停止條件。
6. 何者只可 dry-run，何者可在負責人核准後進入正式執行。
7. 一份最小任務申請卡欄位。
8. 寫給模型看的停止提醒。
9. 由模型外工作流控制器強制執行的 token／成本／重試檢查。
10. 必須從工具權限層移除的副作用能力。
限制：
- 不要假設你可以讀取未列出的資料。
- 不要建議自動刪除資料、付款、寄出正式通知或升級權限。
- 不要把 system prompt 視為硬性成本計量器或權限控制。
- 如果資訊不足，請列出需要負責人補充的問題，而不是直接放行。
整理卡用完後，不要直接把 AI 的答案當成政策。請找一位負責人看過，至少確認三件事：資料範圍是否正確、停止條件是否明確、成本上限是否符合你們的實際預算。
用日常來理解
- 搬家前，三個朋友看著房內的三個紙箱，覺得今天應該能輕鬆整理完。
- 他們打開衣櫥與層架後，才發現裡面還有遠比預期更多的物品。
- 三個人先停下來，把今天的範圍縮成一張簡單的三項清單，只處理已共同確認的內容。
- 他們封好清單上約定的紙箱，其餘物品則整齊留在原處，等下次再繼續。
參考來源
xAI official blog：Introducing Grok 4.5 — https://x.ai/news/grok-4-5（2026-07-08）
TechCrunch：SpaceXAI releases Grok 4.5, which Elon describes as an ‘Opus-class model’ — https://techcrunch.com/2026/07/08/spacexai-releases-grok-4-5-which-elon-describes-as-an-opus-class-model/（2026-07-08）
Engadget：SpaceXAI Launches Grok 4.5, Its First Built With Cursor’s Help — https://www.engadget.com/2211260/spacex-ai-grok-4-5-cursor/（2026-07-09）
