Agentic-Workflow
一句話定義
把 Prompt-Engineering、Context-Engineering、RAG、記憶、工具與多步驟決策組合成有結構的工作流程，讓 LLM 從「會回答」變成「能在邊界內完成任務」的 AI 系統設計方法。
核心要點
為什麼不用「AI Agent」一詞
2026-05-13-Stanford-AI系統課程 提到，Andrew Ng 使用 agentic workflow 是為了避開「AI Agent」一詞被過度泛化：有人把長 prompt 叫 agent，也有人把複雜 multi-agent 系統叫 agent。Agentic workflow 比較精確地指向「一組提示詞、工具、context 與元件被編排成可運作流程」。
這個定義與 Agent 不衝突：Agent 偏「LLM 動態決定流程與工具使用」；本頁偏「把 agentic 能力落成工作流與產品系統」。
傳統軟體 vs agentic 系統
| 面向 | 傳統軟體 | Agentic 系統 |
|---|---|---|
| 資料 | 結構化資料、表單、資料庫 | 自由文本、圖片、音訊、非固定格式輸入 |
| 邏輯 | deterministic，同 input 同 output | fuzzy，同 input 可能因 context 與模型狀態產生不同輸出 |
| 架構心態 | 工程師精確控制每一步路徑 | 像 manager 一樣給目標、限制與邊界 |
| 測試 | 可重現、可窮舉較多狀況 | 迭代探索式，依賴 LLM-Evaluation 與 error analysis |
核心紀律：能 deterministic 解的問題先 deterministic 解；剩下 fuzzy 的部分才交給 LLM，並加上護欄。例如選擇題可用標準答案算分；語音回答理解度才交給 LLM 判斷，且要提供申訴 / 真人審查等 fallback。
三個核心元件
| 元件 | 職責 | 對應概念 |
|---|---|---|
| Prompts | 告訴模型角色、任務、限制與輸出格式 | Prompt-Engineering / Prompt-Chaining |
| Context Management | 決定此刻要讓模型看到哪些資訊 | Context-Engineering / Agent-Memory / RAG |
| Tools | 讓模型查資料或採取行動 | Model-Context-Protocol / Agent-Computer-Interface |
Context Management 的一句話版本是：把對的資訊在對的時間提供給 agent。它可以包含 working memory、archival memory、RAG 檢索結果、對話歷史、工具輸出與壓縮摘要。
三層自主性
| 層級 | 設計 | 優點 | 風險 |
|---|---|---|---|
| Hardcoded steps | 步驟順序寫死，LLM 只處理其中某些判斷 | 安全、可預測、易 debug | 遇到預期外情境會卡住 |
| Hardcoded tools | 工具集固定，但 agent 自行決定步驟與工具組合 | 可控又有彈性；常見 production 起點 | 仍需限制工具範圍與建立 eval |
| Fully autonomous | agent 自己決定步驟，甚至自己創工具或寫 code | 能力最強 | 行為不可預測，需高強度 guardrail |
影片建議 production 起點通常是 hardcoded tools：工具範圍可控，但讓 agent 在流程內做有限度判斷。
從人工流程開始做 task decomposition
客服改地址案例可拆成：
- 抽出 intent、order ID、新地址。
- 查客戶 / 訂單紀錄。
- 查公司政策與出貨狀態。
- 根據前面資訊起草回信。
- 呼叫 email 工具送出。
這個拆解先回答「人類怎麼做」，再決定每一步用 deterministic code、LLM one-shot、RAG、database tool 或 email tool。Agentic workflow 的設計工作不是直接選框架，而是把大任務拆成可被工具與評估覆蓋的小任務。
人類端鏈路思維
2026-05-29-Benzi-AI編程改造生活 從一般使用者角度補上一個詞：鏈路思維。人作為 AI 指揮官，要能看到一串任務，而不是只看到單個任務。
影片的動畫場景案例可拆成：
- 讓 AI 下載參考影片。
- 用截圖與視覺模型分析動畫結構。
- 用 Remotion 類技能把動畫結構轉成影片程式碼。
這不是新的 workflow pattern，而是 Prompt-Chaining / Orchestrator-Workers 在個人工作流中的心智模型：任務能否被 AI 放大，取決於人能否把目標切成可交接、可驗證、可串接的環節。這也通往 普通人的老闆化：人不只執行任務，也要設計任務鏈。
Deep Agent 能力清單與框架選型
2026-07-06-Harness-1-Deep-Agent能力 把常見 Deep Agent 能力整理成六項：Plan / Todos、Filesystem / Bash、Sub-Agent、Memory、Skills、以及 MCP / Browser / Computer Use 等外部工具。這些能力對應本頁的 prompts / context / tools / memory 編排，但它們只解決「能不能做」，不保證「做得對」。
2026-07-06-Harness-9-Agent框架選型 進一步把自建 agent 框架分成兩條路：
| 路線 | 適合場景 | 取捨 |
|---|---|---|
| 全套 Deep Agent 起步 | 內部開發、自用、團隊通用 coding harness、outer loop 疊加 | 起點高，原廠 prompt / tool loop 已調好；但底層較難 debug，成本與 context 較重 |
| 基礎構建 | 特定垂直場景、B2C 大量使用者、成本 / 延遲敏感產品 | 起點低，要自己設計 prompt / tools / eval；但能貼任務分布移除無用能力，可控性更高 |
這補強本頁的 production 判斷：agentic workflow 不該一開始就追求「通用深代理」，而是先問任務是否真的需要完整 Deep Agent 能力；垂直 agent 往往應從精簡工具、明確驗證與可觀測流程開始。
Coding agent runtime 模式也是 workflow 選型
2026-08-18-DeepSeek-Harness四種模式 把 coding agent 的工作模式拆成 Standard / PTC / Minimal / Creator，補上一個更貼近日常操作的判斷：同一個 agentic workflow 產品裡，使用者仍需要依任務形狀選 runtime。
- 探索型任務需要 Standard 這類完整 agent，讓 agent 自己搜尋、讀檔、試錯與修正。
- 大量重複 / 結構化任務可用 PTC 這類「模型先寫程式、harness 一次執行」的模式，把多個工具步驟壓成一次批處理。
- 明確短任務可用 Minimal，減少工具 schema 與固定 prompt 成本，但前提是任務不需要 Web、Skills、Subagent 或複雜 workflow。
- 創作 agent / preset 本身才需要 Creator；這已經是 meta-workflow，權限邊界比一般 coding task 更重要。
這讓 workflow 選型從「要不要 agent / 要不要 multi-agent」再細分到「這次任務需要多完整的 harness」。能力越多不必然越好；真正的目標是讓任務的不確定性、驗證方式、成本與權限邊界匹配。
Multi-agent 是 workflow 的延伸，不是預設答案
Parallelization 與 multi-agent 的理由主要是：
- 平行處理：航班、飯店、天氣這類互不依賴子任務可同時跑。
- 復用：design agent 可給行銷與產品團隊共用。
但若一個 agent 足以完成任務，硬上 multi-agent 只會增加複雜度。較健康的心智模型是：每個 agent 對外暴露 tool-like interface，其他 agent 像呼叫工具一樣呼叫它；這與 Model-Context-Protocol / Agent2Agent 的接口化方向相連。
與 Agentic Engineering 的邊界
2026-05-18-Karpathy-Software-3-Agentic-Engineering 補上一個相鄰但更偏工程責任的詞：Agentic-Engineering。
- Agentic Workflow：把 prompts、context、tools、memory、RAG、eval 編排成能完成任務的流程。
- Agentic Engineering：設計 spec、metric、限制、預算與 rollback，讓 agent 在安全邊界裡大量試錯。
換言之，本頁回答「AI 系統流程怎麼組」；Agentic-Engineering 回答「工程師如何把這些流程變成可驗證、可回滾、可維護的工作環境」。
Goal mode：把 workflow 推到長任務
2026-05-25-Gary-Chen-AI-Agent-27小時-Goal功能 把 /goal 類功能視為 long-running agent 的產品化形態：使用者不再每幾分鐘回來催促，而是先定義 Goal-Prompt，讓 agent 在 outcome、verification、constraints、iteration policy 與 error handling 內持續執行。
這讓 agentic workflow 多了一個管理視角：agent 不只要會拆任務和用工具，還要知道什麼時候繼續、什麼時候停止、什麼時候把卡點回報給人。沒有這層完成定義，long-running task 只是更長的互動式對話，仍會佔用人的注意力。
與其他概念的關係
- 父層：Augmented-LLM 提供 retrieval / tools / memory 三類基本能力；本頁描述如何把這些能力編排成工作流程。
- 相鄰：Agent 描述自主程度與 workflow vs agent 的邊界；本頁描述更偏產品 / production 的落地流程。
- 工具層：Model-Context-Protocol 可把資料源、API 與工具標準化接入；Agent2Agent 則延伸到 agent-to-agent 協作。
- 品質層：LLM-Evaluation 是 agentic workflow 上線前後的核心配套；沒有 eval，fuzzy 系統無法穩定迭代。
- 上層工程方法：Agentic-Engineering 把 workflow 放進 spec / metric / rollback / time budget 的工程環境，讓 agent 能被大規模並行使用而不失控。
- 對位 Harness-Engineering：Harness 是讓 agent 能工作的一整套馬具；agentic workflow 是 harness 在任務流程層的具體編排。
- 可由 Prompt-Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer 等 patterns 組成，但不等於任一單一 pattern。
- 與 普通人的老闆化：本頁是系統 / workflow 的設計方法；普通人的老闆化是個人工作身份被推向 workflow 指揮與工具調度的社會層結果。
相關來源
- 2026-08-18-DeepSeek-Harness四種模式 — 補入 coding agent runtime 模式選型：探索任務用完整 agent、批處理用 PTC、明確短任務用 Minimal、agent 創作用 Creator
- 2026-05-13-Stanford-AI系統課程 — Andrew Ng / Stanford 語境的 agentic workflow 定義、傳統軟體 vs agentic 系統四差異、三元件、三層自主性、客服 agent case study
- 2026-05-18-Karpathy-Software-3-Agentic-Engineering — 補入 Agentic Workflow 與 Agentic Engineering 的邊界：流程編排 vs 可驗證試錯環境
- 2026-05-25-Gary-Chen-AI-Agent-27小時-Goal功能 — 補入
/goal類 long-running agent 功能：goal prompt、評審迭代與停損規則 - 2026-04-28-Anthropic-Building-Effective-Agents — 5 agentic workflow patterns 與 agent / workflow 分界
- 2026-05-02-Agent神文沒告訴你的事 — 從 API call → workflow → agent → tools → context → memory → observability 的升級時機紀律
- 2026-05-29-Benzi-AI編程改造生活 — 補入一般人「鏈路思維」：能否把下載、分析、生成、驗證、回饋串成可委派任務鏈，是 AI 放大工作的前置能力。
備註
建頁理由：vault 已有 Agent 與 Agent複雜度演化，但缺少 Andrew Ng / Stanford 語境中「agentic workflow = 把 LLM 能力組成生產系統」的入口頁。本頁把 deterministic / fuzzy 分工、task decomposition、tools / context / prompts 三元件與 eval 配套收成一個 reusable system-design 錨點。