Claude Opus 5 代理工作流 — 長任務自動化的實戰配置

由 FeiYueh 親自審稿驗證 · 最後更新於 2026-10-05

Opus 5 代理（agent）能不能跑完幾個小時的長任務，關鍵不在模型本身，而在任務外面的架構：拆成可驗收的小步、把狀態寫進檔案、限制工具權限、設好自動檢查點。Anthropic 表示 Opus 5 可以連續工作數小時甚至一整晚，會自己繞過障礙、從錯誤中恢復。不過模型越能長時間自主執行，出錯後沒人發現、一路錯下去的代

Opus 5 代理（agent）能不能跑完幾個小時的長任務，關鍵不在模型本身，而在任務外面的架構：拆成可驗收的小步、把狀態寫進檔案、限制工具權限、設好自動檢查點。Anthropic 表示 Opus 5 可以連續工作數小時甚至一整晚，會自己繞過障礙、從錯誤中恢復。不過模型越能長時間自主執行，出錯後沒人發現、一路錯下去的代價也越高。所以配置的重點是讓錯誤早點浮出來，而不是讓代理跑得更久。 Opus 5 的定位：專為長時間多步驟任務設計 Opus 5 是 Anthropic 主打長時間代理任務的旗艦模型，重點是撐過大量工具呼叫、反覆修改和多步驟執行。 Claude Opus 5 於 2026 年 7 月 24 日發布，在 Frontier-Bench v0.1 上的表現是 Opus 4.8 的兩倍以上，而且每個任務的成本更低（來源：Anthropic） 。在考驗新問題解決能力的 ARC-AGI 3 上，Anthropic 公布的 Opus 5 分數是第二名模型的三倍。 這種能力提升不是單一事件，而是有長期趨勢可循。 AI 能以 50% 成功率完成的任務長度，過去 6 年約每 7 個月翻倍（來源：METR，2025 年 3 月） 。換句話說，一年前需要人盯著、每 20 分鐘介入一次的流程，現在已經可以設計成數小時無人值守。但任務越長，中間任何一步的小錯誤都會被放大，因此下面每個配置都是為了「讓錯誤早點浮現」。 價格方面， Opus 5 的 API 定價從每百萬輸入 token 5 美元、每百萬輸出 token 25 美元起（來源：AWS 官方部落格） ，可透過 Claude Platform、Amazon Bedrock、Google Cloud 與 Microsoft Foundry 使用。 架構原則：先選「工作流」，不夠才用「代理」 長任務自動化的第一個決定，是流程的哪些部分要寫死、哪些交給模型自己判斷。Anthropic 在工程文章 Building effective agents 中把兩者分開： 工作流（workflow） 是用預先寫好的程式路徑串接 LLM 呼叫； 代理（agent） 則由模型自己決定下一步要用什麼工具。文章建議從最簡單的方案開始，只有在步驟數量無法預先決定時才升級成代理。 適合寫死成工作流的部分 固定順序的流水線：抓資料 → 清洗 → 產生報表 → 寄送 有明確格式的轉換：翻譯成 5 種語言、將 Markdown 轉成 HTML 排程觸發的批次作業：每天 08:00 發一篇排程文章 適合交給 Opus 5 代理自主判斷的部分 除錯：錯誤原因事先不知道，需要邊查邊縮小範圍 跨多個檔案的重構：需要先讀懂依賴關係才能決定改動順序 研究型任務：要搜尋幾次、讀哪些來源，都取決於中途的發現 實務上最穩的組合是用 工作流當外殼、代理當節點 ：外層程式控制階段切換與驗收，只在「需要判斷」的節點呼叫 Opus 5 代理。這樣就算代理在某個節點失敗，外層也能直接重試那一段，不必整個任務重跑。 實戰配置一：用子代理分工與控制成本 多代理架構在研究類任務上有明確的效果，但 token 消耗也會大幅增加。 Anthropic 的內部研究評測中，由 Opus 4 擔任主代理、Sonnet 4 擔任子代理的多代理系統，表現比單一 Opus 4 代理高出 90.2%；但多代理系統的 token 用量約為一般對話的 15 倍（來源：Anthropic Engineering，2025 年 6 月） 。 這組數據直接決定了配置方式： Opus 5 放在主代理（負責規劃與驗收），大量讀檔、搜尋、格式轉換交給較便宜的模型 。以 Claude Code 為例，可以在 .claude/agents/ 目錄下定義子代理，並分別指定模型與可用工具： 搜尋型子代理 ：只給 Read、Grep、Glob 等唯讀工具，選用 Haiku 4.5 或 Sonnet 5，回報時只交結論和「檔案:行號」，不貼整段程式碼。 實作型子代理 ：給 Edit、Write 權限，但限定處理 1–2 個檔案。 審查型子代理 ：只能讀、不能改，而且必須跟實作者是不同的代理實例，避免「自己驗收自己」。 子代理最大的價值是隔離上下文，而不只是平行處理：子代理讀了 50 個檔案，主代理只收到 20 行摘要，主代理的上下文就能撐完整個長任務。 實戰配置二：把狀態寫進檔案，不要只放在上下文 長任務失敗最常見的原因是「上下文腐化（context rot）」：對話越長，模型對早期資訊的注意力越分散。Anthropic 在 Effective context engineering for AI agents 中建議的解法有三種：壓縮（compaction）、結構化筆記、子代理隔離。 結構化筆記

由 FeiYueh 親自審稿驗證 · 最後更新於 2026-10-05. Independently maintained — not AI-generated boilerplate.