Stage 7.5 — 進階 Agentic 選擇：有證據才增加複雜度¶
← 先回到 Stage 7 — Agent 上線工程：若你還不能用 Eval、Trace、Approval 與 Recovery 證明系統可測、可看、可停、可恢復，先不要增加本章的進階做法。
Stage 7.5 不是更多名詞的收藏櫃。它只回答一個問題：哪個已重現的失敗，值得你多加一層檢查、故障測試、自主權分級或 Harness 元件？
預設答案是「先不加」。先量單一 Agent 的 baseline；只有新做法在同一組 Eval 中帶來可重現改善，才保留它。
🎯 完成這一關後，你能做什麼¶
- 用白話說清楚四個進階概念，以及它們各自處理哪種失敗。
- 從短選擇表挑出一個候選做法，不把所有模式一次裝上。
- 用 baseline、同一組 Eval、成本與安全結果決定是否保留複雜度。
- 對 Harness 元件做 Keep／Simplify／Remove 判斷，並保留回復方法。
🚪 最短進入條件¶
完成 Stage 7，並已經有一組能重跑的 Eval cases、停止條件與單一 Agent baseline。這一關不要求寫程式，也不要求購買 API 或公開模型的私人 Chain-of-Thought。
資料查核：2026-09-13 UTC。
📚 必修閱讀¶
先讀三份；每份都對應本章的一個決定：
- Anthropic — Building Effective Agents：先用最簡單的 workflow；只有能證明分工有價值時才增加 Agent。
- Anthropic — Demystifying Evals for AI Agents：把失敗變成可重跑案例，再比較 Outcome、Trajectory、成本與穩定性。
- OpenAI — Harness Engineering：看真實 codebase 如何用清楚邊界、文件與機械 gate 幫 Agent 穩定工作；這是一個案例，不是所有系統的唯一架構。
🔑 先認識四個進階核心詞¶
先看白話總覽，知道哪種問題才需要哪個詞。表格下面的四段會再補上限制與來源，不把進階概念縮成一句口號。
| 先處理什麼 | 核心詞 | 五歲也能懂的說法 | 何時使用／技術界線 |
|---|---|---|---|
| 先找出真正的問題 | Evaluator–Optimizer／Agent-as-Judge（評估者—優化者／由 Agent 評分） | 一個做，一個照清單檢查 | 內容需要判斷品質時才用；Judge 也會犯錯，不能單獨決定真相 |
| Failure Injection／Chaos Eval（故障注入／混沌評測） | 故意拔掉一塊小積木，看房子會不會安全停下 | 只在隔離環境製造可控制的小故障；不能拿真實資料隨意做實驗 | |
| 再控制新增的複雜度 | Autonomy Gradients／Trust Layers（自主權梯度／信任層級） | 事情越危險，AI 可以自己走的路越短 | 依風險縮小權限；付款、刪除、發布或外部訊息要先問人 |
| Model–Harness Fit（模型—Harness 適配） | 換了新引擎，就一次拿掉一個零件再重考 | 用同一組 Eval 決定元件要保留、簡化或移除；安全責任不能因模型變強就刪掉 |
下面不是另一份名詞清單；它只補充每個做法何時有用，以及最容易踩到的界線。
1. 先讓另一個檢查者照規則挑錯¶
Evaluator–Optimizer／Agent-as-Judge（評估者—優化者／由 Agent 評分）：一個角色產生成果，另一個角色按照明確 rubric 找出問題；產生者只在有新證據時做有界修正。
它適合「答案不只對或錯，還要判斷完整性、忠實度或寫作品質」的任務。Judge 也會犯錯，因此不能讓它單獨決定真相。至少搭配固定案例、可程式化檢查、人工抽樣與修正次數上限。
Constitutional AI 是 principle-based training／critique 方法，不等於所有 runtime LLM judge。研究入口：Constitutional AI paper。
2. 故意弄壞一小塊，確認系統會安全停下¶
Failure Injection／Chaos Eval（故障注入／混沌評測）：主動製造可控制、可復原的小故障，例如 timeout、舊資料、壞格式或工具不可用，再檢查停止、降級與復原是否符合預期。
「Failure Injection／Chaos Eval」是本章採用的編輯／社群統稱，不是跨供應商公認標準名稱。先在隔離環境測最小故障，不能隨意在真實 production 資料上製造事故。設計方法可先看 Anthropic — Demystifying Evals。
3. 風險越高，Agent 能自己決定的範圍越小¶
Autonomy Gradients／Trust Layers（自主權梯度／信任層級）：按任務風險分配不同程度的自主權。唯讀查詢可以自動執行；付款、刪除、發布或外部訊息則先提出方案，再由人核准。
「Autonomy Gradients／Trust Layers」也是本章採用的編輯／社群統稱，不是單一正式標準。常見階梯是 suggest → propose → execute，但實際層數由風險、權限與責任人決定，不由模型自評決定。
4. 模型變強後，重新證明每個外加步驟是否還值得¶
Model–Harness Fit（模型—Harness 適配）：換模型或版本後，一次拿一個 Harness 元件做刪除測試，用同一組品質、安全、成本與延遲 Eval 決定保留、簡化或移除。
「Model–Harness Fit」是本章的編輯簡稱，不是公認標準術語。它不代表用模型取代權限、sandbox、audit log、人工核准或 rollback；這些是長期責任，不能因模型升級就直接刪除。
🧭 其他模式：看到這種證據才選¶
| 候選模式 | 白話說法 | 先看到什麼證據 | 官方／原始入口 |
|---|---|---|---|
| Parallel Exploration（平行探索） | 同時試幾條互不依賴的路，再比較 | 問題真的能分開，且增加的成本與合併工作小於品質或時間收益 | Anthropic parallelization workflow |
| Hierarchical Delegation（階層式委派） | 大工作逐層拆給較小角色 | 單一 context 放不下，或子任務有清楚輸入、輸出與驗收人 | Anthropic orchestrator-workers；新 Microsoft 專案可從 Microsoft Agent Framework 開始，AutoGen 已進入 maintenance mode |
| Multi-Agent Handoff（多 Agent 交接） | 把控制權、必要資料與完成證據一起交棒 | 不同角色必須直接接手，而且交接後的錯誤率低於單一 Agent baseline | OpenAI Agents SDK orchestration |
| Plan–Act–Reflect（規劃—行動—回看） | 先計畫、執行、讀證據，再有限次修正 | 測試或 grader 能指出可修正失敗；不是只把同一句話再試一次 | Reflexion |
| Dynamic Workflows（動態工作流程） | 讓 Agent 寫出可重跑的分工 script | 任務可平行、可重跑，而且固定 workflow 不足以表達當次分工 | Claude Code Dynamic Workflows |
🧪 最小決策紀錄：加之前先填完¶
已重現的失敗：哪個 case 失敗？Outcome 或 Trajectory 哪裡不合格？
單一 Agent baseline：品質、成本、延遲、安全結果是多少？
只加的一個做法：它要防住哪個失敗？
接受門檻：同一組 Eval 至少改善什麼，而且不能犧牲什麼？
停止／回復：沒改善、變貴或變危險時，怎麼撤掉？
如果第一行沒有證據，先補 Eval case；如果第四、五行寫不出來，先不要增加複雜度。
⚖️ Model–Harness Fit：用 Eval 決定保留、簡化或移除¶
模型變強時，某個重複提醒 prompt、context reset 或額外 planner／reviewer 可能不再需要。一次只改一個元件，其他 task、資料、工具、環境、grader 與門檻保持相同，再比較多次 trials。
| 決定 | 你看到的證據 | 下一步 |
|---|---|---|
| 保留 Keep | 拿掉後，同一個可重現失敗又回來，或安全門檻退步 | 放回去，記下它防住的 case 與版本 |
| 簡化 Simplify | 保護仍有用，但較少步驟也能通過同一組 Eval | 一次再少一個步驟，重跑相同 trials |
| 移除 Remove | 刪除測試通過，品質與安全未退步，成本或延遲相同或更好 | 移除後持續監測，保留可驗證的回復方法 |
| 先分哪一類 | 例子 | 判斷邊界 |
|---|---|---|
| 可能補某代模型弱點的元件 | context reset、重複提醒 prompt、額外 planner／reviewer | 模型變更時可以做刪除測試，但只能由同一組 Eval 決定 |
| 長期安全責任 | 最小權限、sandbox、audit log、人工核准、rollback | 實作可以更換；責任不能靠「模型變強」直接刪除 |
⏳ 展開：Bitter Lesson、人機分工與刪除測試的限制
每加一層，記錄三件事：哪個可重現失敗需要它、哪個 Eval 證明它有效、哪個刪除測試能證明它已不再需要。
這和 Rich Sutton 的 The Bitter Lesson 相呼應，但不是該文章直接提出的 Agent Harness 定律。
Anthropic 對 2025-10 到 2026-04 Claude Code 使用資料的分析，平均觀察到使用者做約 70% planning decisions，而 Claude 做約 80% execution decisions。這是特定產品與資料集的觀察，不是每個團隊都應硬套的比例。可帶走的是：人負責目的、邊界與驗收；Agent 負責範圍內的執行。來源：How Claude Code is used in practice。
🔀 Dynamic Workflows — 當 Agent 把分工寫成可重跑的 script¶
這是 Claude Code 的 Agent orchestration 功能，不是模型，也不是 OpenRouter、Airflow 或 n8n 的替代品。只有任務能安全 fan out、結果可比較，而且重跑有價值時才選它。
展開：現行版本、機制、限制與安全邊界
- 目前條件：現行官方文件列出所有付費方案、Anthropic API，以及 Amazon Bedrock、Google Cloud Agent Platform、Microsoft Foundry。Pro 可從
/config啟用。 - 怎麼運作：Claude 產生 JavaScript orchestration script，由背景 runtime 執行；中間結果留在 script 變數，最後結果才回到對話 context。
- 怎麼啟動：明確要求
use a workflow／run a workflow，或使用ultracode。/effort ultracode需要 v2.1.203+ 且模型支援xhigheffort。 - 現行上限：最多 16 個 concurrent agents、每次 run 累計 1,000 個。這是防 runaway 的上限，不是建議你每次都用滿。
- 安全邊界：subagent 的工具仍受 permission 與 sandbox 規則約束；workflow 本身沒有任意 shell／filesystem access。長 run 會用更多 token，啟動前仍要看 phase 與成本。
- 限制：run 中不能插入一般使用者輸入；共享狀態很多或只需一個 Agent 的工作，不適合 fan out。
2026-05-28 的發布公告把它稱為 research preview，並和 Opus 4.8 同日公布；這只是一段歷史，不代表今天綁定 Opus 4.8。現行規則以 Dynamic Workflows docs 為準。
🔬 深讀時才需要的證據與失敗案例¶
🧯 展開：三個案例教了什麼，以及如何避免讀錯
- 分工後風格對不上：Cognition 的 Flappy Bird 案例提醒，多個 subagent 若拿不到共同背景，最後很難拼在一起。來源：Don’t Build Multi-Agents。
- 研究 Agent 補進未驗證推測：Anthropic 的 Research 系統用 source quality、引用與 evaluator 改善 speculative leap。來源：How we built our multi-agent research system。
- 文字規則沒有變成機械防線：2025-07 的 Replit production database 事件是第三方記錄案例；它提醒 permission gate 的重要性，但不代表所有產品或版本都會發生相同行為。來源：AI Incident Database #1152 與 The Register 報導。
事故不會自動變成最佳實踐。只有把教訓寫成權限、測試、review 與 recovery gate，系統才真的改變。
⚖️ 展開：怎麼讀 Agent benchmark，才不會被單一分數騙
Agent benchmark 同時量到模型、prompt、tool、harness、硬體、timeout 與 grader。比較時至少固定 task、scaffold、工具、資料與環境；重跑多次；分開 infrastructure error 與解題失敗；使用 held-out cases；並讓 Judge 搭配 deterministic checks 與人工抽樣。
Anthropic 2026 的研究顯示，基礎設施差異可能大到超過排行榜模型間的差距；因此小幅領先不等於穩定較強。來源：Quantifying infrastructure noise in agentic coding evals 與 Demystifying Evals。
🎯 精選閱讀：先挑一條¶
- Anthropic — Building Effective Agents ⭐⭐⭐⭐⭐：第一次讀進階 Agent pattern，先從這篇開始。
- OpenAI — Harness Engineering ⭐⭐⭐⭐⭐：看邊界、文件與機械 gate 怎麼放進真實 codebase。
- Anthropic — Demystifying Evals for AI Agents ⭐⭐⭐⭐⭐：想知道怎麼驗收 Agent，先讀這篇。
- Microsoft Agent Framework ⭐⭐⭐⭐⭐：要看現行 Microsoft multi-agent／workflow 實作；不要從 maintenance-mode AutoGen 開新專案。
- datawhalechina/hello-agents ⭐⭐⭐⭐⭐：想用中文把概念接到完整實作。
📚 完整學習資源與限制¶
| 分類 | 資源 | 適合讀什麼 | 編輯評分 | 限制／狀態 |
|---|---|---|---|---|
| 基本設計與 Context | Anthropic — Building Effective Agents | Workflow、Agent 與常用 pattern | ⭐⭐⭐⭐⭐ | 2024 foundation；不是最新產品清單 |
| Effective Context Engineering | 怎麼挑 context，不把視窗塞滿 | ⭐⭐⭐⭐⭐ | 供應商文章；原則可跨模型使用 | |
| OpenAI Harness Engineering | 可讀 codebase、SoR、invariant | ⭐⭐⭐⭐⭐ | 單一 OpenAI codebase case study | |
| Effective Harnesses for Long-running Agents | 跨 session artifact 與增量進度 | ⭐⭐⭐⭐ | 特定 coding harness 實驗 | |
| Harness Design for Long-running Apps | Planner／Generator／Evaluator | ⭐⭐⭐⭐ | 2026 Labs case study，不是唯一架構 | |
| Orchestration／Contracts | Anthropic Multi-Agent Research System | Orchestrator-workers production lessons | ⭐⭐⭐⭐⭐ | 最適合 breadth-first research；token 開銷高 |
| LangGraph | Stateful graph、checkpoint、HITL | ⭐⭐⭐⭐ | 低階框架；要自己設計 state 與 Eval | |
| Microsoft Agent Framework | Python／.NET Agent 與 workflow | ⭐⭐⭐⭐⭐ | AutoGen／Semantic Kernel 的現行後繼入口 | |
| OpenAI Agents SDK Sandbox Agents | Workspace、session、snapshot、sandbox | ⭐⭐⭐⭐ | Beta；介面仍可能變 | |
| Claude Code Dynamic Workflows | Agent-authored、可重跑的 orchestration | ⭐⭐⭐⭐ | Claude Code 功能；高 token、非通用 workflow engine | |
| Eval／Resilience | Demystifying Evals for AI Agents | Capability、regression 與 transcript Eval | ⭐⭐⭐⭐⭐ | 先從小而能重現的 failure set 開始 |
| Infrastructure Noise in Agentic Evals | 硬體與環境如何扭曲分數 | ⭐⭐⭐⭐ | 特定 benchmark 實驗；不要外推精確幅度 | |
| Best Practices for Rigorous Agentic Benchmarks | Task、reward 與環境設計缺陷 | ⭐⭐⭐⭐ | 研究 paper；需搭配 benchmark 現行版本 | |
| tau2-bench | Tool-Agent-User interaction 與 pass^k | ⭐⭐⭐⭐ | Benchmark 不是 production SLA | |
| SWE-bench | 真實 GitHub issue 的 coding Eval | ⭐⭐⭐⭐⭐ | 分數受 harness、版本與環境影響 | |
| Research patterns | ReAct | Reasoning／Action／Observation loop | ⭐⭐⭐⭐⭐ | 教可觀察行動，不要求公開私人 CoT |
| Reflexion | Feedback 後修正策略 | ⭐⭐⭐⭐ | 研究設定不等於每個 production loop | |
| Constitutional AI | Principle-based critique 與 revision | ⭐⭐⭐⭐ | 訓練方法；不能直接等同 LLM-as-judge | |
| CAMEL | Role-playing multi-agent research | ⭐⭐⭐ | 研究原型；高風險責任仍需固定 owner | |
| DSPy | Typed signatures、program optimization | ⭐⭐⭐⭐ | 框架持續更新；先鎖版本與 Eval | |
| 中文／動手入口 | datawhalechina/hello-agents | 中文完整 Agent 教材 | ⭐⭐⭐⭐⭐ | 篇幅長；按本章概念挑章節 |
| Microsoft AI Agents for Beginners | 18 課 Agent 入門與多語教材 | ⭐⭐⭐⭐ | 供應商範例較多；先看概念再選 SDK | |
| LangChain Deep Agents | Planning、subagent、filesystem harness | ⭐⭐⭐⭐ | 較高階抽象；不是所有任務都需要 | |
| 李宏毅生成式 AI 課程 | 中文課程與研究背景 | ⭐⭐⭐⭐⭐ | 依年份挑主題；產品介面仍查官方 docs |
✅ 完成檢查¶
- 我能用白話解釋四個進階概念，並說出三個編輯／社群命名的邊界。
- 我先有單一 Agent baseline 與可重跑失敗，才從選擇表增加一個模式。
- 我會用同一組 Eval 比較品質、安全、成本與延遲，不只看一次漂亮回答。
- 我能對一個 Harness 元件做 Keep／Simplify／Remove 決定，並指出證據與回復方法。
- 我知道 Judge 也要被檢查，故障注入先在隔離環境做，高風險動作不由模型自行升級權限。
五項都能做到，就進入 Stage 8 — Agent 操作介面。如果還沒有 baseline 或失敗證據，先回到 Stage 7 補齊，而不是再加一個 Agent。