嗨，我係 Lena。我望住大家點樣傾 agentic workflow 都有一段時間。每個人用呢個詞嘅姿勢都唔太一樣——而且講真，我自己都用咗比想承認多嘅時間先搞清楚，一個 agentic workflow 同一個普通 AI agent 或者一條基本自動化鏈，究竟差喺邊。
呢篇係我嘗試將而家呢片圖景擺出嚟講：有邊幾種子類型、之間點揀、喺 production 度邊啲行得通、又喺邊啲位崩。如果你而家用 agent 砌嘢、又喺度諗究竟揀邊種 workflow 架構先真係夾你個問題，呢篇文章應該可以幫你少行幾段冤枉路。
一句話定義
一句講清 agentic workflow
Agentic workflow 係呢樣嘅系統：AI 模型自己決定下一步做乜、call 邊啲工具、評估結果、然後繼續行落去——橫跨多個步驟、對流程本身有某程度嘅自主權。
就咁。關鍵字係對流程嘅自主權。模型唔係淨係答問題。佢喺度決定點樣拆呢個問題、揀邊啲工具用、按照返嚟嘅嘢做調整。
點解呢個詞喺 2026 仲咁亂
事情係咁——「agentic workflow」呢個詞而家覆蓋嘅範圍，由一條帶條件分支嘅兩步鏈，去到一整套帶共享 memory、自我糾正 loop 嘅多 agent 系統，全部都塞晒入嚟。Anthropic 嘅 building effective agents 嗰份指南做咗一個有用嘅區分：workflow 係 LLM 喺預先定義好嘅 code path 度被編排嘅系統，agent 就係動態自己決定流程嘅系統。但實際上，大多數 production 系統都係住喺兩者中間。
我第一次睇到呢個區分，停咗一陣。佢喺紙上睇住好乾淨，但我見親嗰啲系統，冇一個係可以乾淨地塞入任何一個 box 入面嘅。
Agentic workflow 嘅形態圖譜
唔係所有 agentic workflow 都係同一種砌法。呢啲差異喺你決定要造乜嘅時候好重要——更要緊嘅係，會決定你造出嚟嘅嘢喺 production 度撐唔撐到。
線性 workflow
最簡單嘅形態。任務 A 餵畀任務 B，再到任務 C。每一步係一個有工具 access 嘅 LLM call，但序列係預先定好嘅。諗下：抽取 → 分析 → 總結。自主度低、可預測性高。 啱用喺文件處理、資料抽取 pipeline，以及任何步驟唔會變嘅場景。
分支 workflow
系統喺一個或者多個點做 routing 決策。「如果 input 係 support ticket，行左；如果係 sales inquiry，行右。」Routing 可以係 LLM 驅動，又可以係規則驅動。大部分團隊由 basic chain 升級嘅時候，係由呢度開始嘅。LangGraph 呢類 framework 用 graph-based 嘅 state management 同條件邊將呢個 pattern 做得好顯式。
自我糾正 workflow
呢度先至開始真係有意思。系統跑完一個任務，對自己嘅 output 做評估，如果結果過唔到校驗就 loop 返去重試或修訂。 本質上係一個 evaluator-optimizer loop。我喺 code generation 度見過呢個 pattern 用得好密——一個模型寫、另一個審，反覆 iterate 直到 reviewer 滿意為止。陷阱係：冇靠譜嘅退出條件，呢類 loop 會無止境噉燒 token。
多 agent workflow
多個專門化嘅 agent 喺問題嘅唔同部分做嘢，由一個 orchestrator 協調。Anthropic 講佢哋嘅多 agent 研究系統用嘅就係呢個 pattern——一個 lead researcher 將子任務 delegate 畀專門嘅 subagent 並行跑。Orchestrator-worker pattern 好強，但會引入真實嘅協調複雜度：agent 可能做重複嘢、漏關鍵部分、又或者喺 delegate 唔精確嘅情況下互相撞。
Human-in-the-loop workflow
上面任一種 pattern，加上明確嘅檢查點，由人去審、批、或重定向之後系統先繼續。呢個唔係另一種架構，更似係你疊喺其他架構上面嘅一個約束層。對高風險領域嚟講冇得傾——金融決策、法律審核，任何錯一步就會有真實後果嘅場景。
Agentic workflow 同 agent、自動化嘅分別
Workflow vs agent
Workflow 有結構。即使係 adaptive，都係一段被設計過嘅流，有定義好嘅步驟同過渡。Agent 更開放——佢自己決定做乜、幾時做、點做，預定義結構降到最低。大多數 production 系統係 workflow、唔係純 agent，因為純 agent 更難 debug、更難預測、更難控制。
Agentic workflow vs RPA
傳統 RPA 跟嘅係嚴格、規則式嘅 script。佢喺固定次序度撳掣。Agentic workflow 可以解析非結構化 input、做判斷、喺資料同預期唔夾嘅時候自我調整。 RPA 一旦 UI 變咗就會壞。Agentic workflow 都會壞，但壞嘅模式唔同、有時更隱蔽——但佢處理變化嘅能力強好多。
Agentic workflow vs no-code 自動化
Zapier、Make 呢類 no-code 工具將 trigger-action 嘅 pattern 處理得好好。但佢哋係 stateless 嘅、又冇推理。Agentic workflow 可以跨步驟持住 context、根據中間結果做條件性決定、處理嗰啲需要理解力（而唔係淨係 routing）嘅任務。Model Context Protocol (MCP) 喺度值得提一句：佢將 AI 應用點同外部工具同資料源連接呢件事標準化，而越嚟越多 agentic workflow 底下接嘅就係呢層結締組織。
按 use case 睇嘅真實例子
Coding：Agent 寫 code → 跑 test → 讀 error → 修 → 再跑。自我糾正 loop。呢個大概係目前 production 度最成熟嘅 agentic workflow pattern。
研究：Orchestrator 將研究問題拆做子任務 → 並行嘅 subagent 喺唔同來源搜尋 → 結果畀綜合。關鍵挑戰係去重，同「幾時應該停止鑽落去」。
文件處理：由 PDF 抽欄位 → 對住 schema 校驗 → 標記異常 → routing 畀人審。線性加校驗步驟嘅分支。
Support：將入嚟嘅 ticket 分類 → 拎相關文件 → 起 draft → 校 tone 同準確性 → 發送或者升級。帶 draft 自我糾正層嘅分支 workflow。
運維：監控系統 metrics → 偵測異常 → 診斷可能成因 → 提出修復建議 → 等審批 → 執行。呢度 human-in-the-loop 係關鍵。
決策圖：你應該揀邊種 workflow
……答案有啲出人意表——唔係「揀最複雜嗰個」。剛好相反。下面係一個快速 framework：
| 因素 | 線性 | 分支 | 自我糾正 | 多 agent |
|---|---|---|---|---|
| 任務穩定性 | 步驟幾乎唔變 | input 變、步驟唔變 | output 質量浮動 | 子任務互相獨立 |
| 工具風險 | 低——唯讀工具 | 中——有寫操作 | 中——可重試 | 高——要 isolation |
| 審核需求 | 低 | 中 | 中至高 | 高 |
| Memory 要求 | 極低 | 適中 | 適中（loop state） | 高（跨 agent context） |
由能安全處理你個任務嘅最簡單架構開始。 一個跑得起嘅線性 workflow，勝過一個間中喺協調上幻覺嘅多 agent 系統。Google 嘅 Agent2Agent (A2A) 協議 喺度推動多 agent 協調嘅標準化，但對大多數團隊嚟講而家嘅現實係：只有當子任務真係互相獨立、可以並行嗰時，多 agent 系統嘅 overhead 先至划得來。
點解 agentic workflow 喺 production 度會崩
呢部分係我反覆翻番轉嚟諗嘅。我見過嗰啲 demo 階段靚到飛起嘅 workflow，真實跑一個禮拜就散晒。失敗模式夠一致，可以列出嚟：
Context 漂移。 長時間運行嘅任務度，模型會慢慢失去對早期 context 嘅把握，開始做出同三步之前嘅決定矛盾嘅判斷。Token 上限係真嘅，而大多數 workflow 喺 context 修剪上面做得唔夠好。CIO 對 agentic AI 喺工程領域嘅分析將呢點列為核心挑戰——跨多步嘅持續執行需要嘅係刻意嘅 context 架構，唔係淨係更長嘅 context window。
工具失敗。 API 掛咗。撞到限流。回應格式變咗。一個對工具失敗冇 graceful handling 嘅 workflow，會將一次 API timeout 放大成一次完整失敗。大多數團隊喺 retry 邏輯同 fallback path 上嘅投入都唔夠。
校驗薄弱。 Workflow 跑完咗、出咗 output、冇人去 check output 究竟好唔好。自我糾正 workflow 可以幫到手，但前提係 evaluator 真係識得捉到 generator 犯嘅錯。我見過嗰種 setup：evaluator 因為 prompt 寫得唔夠精確，直接乜都點頭放行。
修復冇得重用。 呢條好微妙，但放長嚟睇可能係代價最大嘅。Agent 撞到一個問題，人去修咗，修法蒸發。下個禮拜，同一個問題、同一輪人手介入。嗰次成功嘅修復從來冇被沉澱成可以重用嘅嘢。 冇任何機制將一次一次性嘅修正變成持續嘅改進。Workflow 唔會由自己歷史度學——佢淨係 reset。
我而家都仲未完全諗清楚，呢件事喺基礎建設層面嘅正確解法係點樣。但我覺得有條 pattern 係關鍵：如果你個 workflow 反覆撞同一個失敗、你又反覆手動打補丁——你撞到嘅唔係 workflow 問題，係能力繼承問題：成功嘅修復要變成系統嘅一部分，唔係停留喺某個人嘅腦袋入面。
呢個亦都係我哋做 evomap.ai 嘅起因。我哋一直喺度睇住 agent 解決真實問題——debug、test、寫文檔——然後到下一次跑嘅時候，佢哋啱啱搞清楚嘅所有嘢又冇晒。所以我哋開始問：如果嗰啲已經行得通嘅修復，可以被打包、分享，再畀其他 agent 自動繼承，又會點？呢個就係我哋 Genome Evolution Protocol 嘅核心諗法——唔係要整個更聰明嘅模型，係要確保一個 agent 辛苦得返嚟嘅方案，唔會蒸發。如果你都被嗰個「修-唔記得-再修」嘅 loop 拖住，將你嘅問題拋出嚟睇有咩答案，可能值得一試。
FAQ
Agentic workflow 究竟係乜？同普通 AI agent 或簡單自動化有咩分別？
Agentic workflow 坐喺硬性自動化同完全自主 agent 中間。佢有預定義結構（步驟、過渡、檢查點），但喺嗰個結構裏面將決策權畀咗 AI 模型。普通自動化跟住固定規則。純 agent 自己決定一切。Agentic workflow 畀模型喺已定義階段裏面點樣完成嘅自主權，成個流係由人類設計嘅。
2026 年最實用嘅 agentic workflow 真實例子有邊啲？
帶自我糾正嘅 code 生成、多源研究綜合、帶校驗嘅文件抽取、帶質量檢查嘅客戶 support 起 draft、帶 human-in-the-loop 修復嘅運維監控。共通主線係：嗰啲需要多步、用工具、再加某種形式嘅 output 評估先至可以交付結果嘅任務。
Agentic workflow 點處理 memory、context 同多步任務？
短期 context 通常透過模型嘅 context window 管理——對話歷史同 tool 結果以 message 形式流過去。對更長嘅 workflow，團隊用外部 state store：資料庫、檔案、又或者專門嘅 memory 系統，將資訊跨步驟咁持久化。多 agent 系統好多時用一個所有 agent 都可以讀寫嘅 shared state object。Context 管理仲係呢個領域最難嘅工程問題之一。
Previous Posts:
- 想對現代 agent 系統喺本文討論嘅 workflow pattern 底下嘅分層有更清楚嘅圖景？呢篇拆 OpenHarness、GEP 同 agent stack layers 嘅文章直接駁去架構嘅一面：OpenHarness and GEP Agent Stack Layers
- 上面提到嘅「workflow vs 能力繼承」問題，喺對比可重用 skill 同可重用 procedural asset 嘅時候會更明顯：Agent Skills vs GEP Assets Real Difference
- 如果本文嘅自我糾正同 orchestration pattern 戳到你，呢篇關於 agent execution chains 同 hooks 嘅文章係順勢嘅下一讀：Agent Hooks AI Execution Chains
- Agentic workflow 喺 production 度最大嘅失敗模式之一，係修復冇辦法跨 run 保留落嚟。呢篇文章將呢條學習鴻溝挖得更深：ARC AGI 3 Agent Learning Gap GEP
- 如果你而家評緊 memory、orchestration、workflow 持久化嘅實用 framework，呢篇對 Mem0、LangGraph、CrewAI 同 harness 工程模式嘅比較係呢篇之後嘅自然延伸：Harness Engineering Mem0 LangGraph CrewAI
