不是更多 Agent，而是更好的控制結構 Not More Agents, but Better Control Structures

先來看一段你大概很熟悉的對話。

AI模型

「我已經仔細檢查過了，內容正確，沒有發現問題。」

好。那它真的變得比較可靠了嗎？

大型語言模型真正變得有趣，不是它「回答得更好」的那一刻，而是它開始能自己持續工作的那一刻。

回想一下這幾年的演化。一開始，AI 是聊天機器人：你問、它答、你挑毛病、改 Prompt、再問一次。接著它學會搜尋、寫程式、查資料庫；再來，它能自己規劃、執行、檢查、修正。然後任務一變複雜，一個 Agent 又忙不過來了——要有人分頭研究、有人獨立查核、有人負責分流，最後還要有人收尾。

聽起來，是不是很像一個醫療團隊？

問題也就從「Prompt 怎麼寫」，變成「這整個團隊該怎麼分工」。這就是從 Prompt Engineering、Loop Engineering，一路走到 Graph Engineering 的核心轉變。

先打個預防針：Graph 不是來取代 Loop 的。它們比較像五個各司其職的角色。

順帶一提，Graph Engineering 還是個正在成形的新詞，不是已經定案的標準。2026 年 8 月一篇 arXiv 綜述（Feng et al.）把它描述成從「單一 Agent 的個體智能」走向「多個元件協作的系統智能」。說白了，就是從「一個很聰明的人」，走向「一個很會合作的團隊」。

Chat、Workflow、Agent：方向盤在誰手上？

Anthropic 的分法很好記：Workflow 像照著導航開車，路線事先排好；Agent 則是自己看路況，決定下個路口要不要轉、要不要換條路。

所以「摘要這篇 PDF」，叫一次模型就收工。但如果是「找出這個領域近三年最重要的研究，比較方法、查核引用、做成簡報」，就得搜尋、篩選、閱讀、比較、驗證、撰寫、再檢查——到這裡，才真正進入 Agent 的地盤。

Loop 不是叫 AI 多做幾次

Anthropic 把這種模式叫 Evaluator–Optimizer：一個負責做，一個負責挑毛病，做的人照著意見改，來回幾輪。最適合那種「給得出具體回饋，就能越改越好」的任務。

重點來了：Loop 的價值不是重複，而是收斂。每多跑一輪，都要更靠近一個說得出口、驗得出來的終點。

不然呢？

沒有終點的 Loop，只是一台很認真在燒 Token 的機器。

靠得住的 Loop，要有四個零件

goal:
completed:
decisions:
evidence:
failed_attempts:
open_questions:
next_actions:

還沒有框架？一段 Prompt 先跑起來

每一輪就做這幾件事，轉到停為止：

1. DRAFT
2. CHECK
3. GAPS
4. REVISE

你正在執行一個有限次數的 Self-Checking Loop。
GOAL：[最終成果]
SUCCESS CRITERIA：
1. [可驗證條件]
2. [可驗證條件]
3. [可驗證條件]
MAX_PASSES：4
每一輪依序執行：
1. DRAFT：產生或改進目前成果。
2. CHECK：逐項檢查 SUCCESS CRITERIA，標示 PASS / FAIL / UNCERTAIN。
3. GAPS：找出最影響成果的 1–3 個缺口。
4. REVISE：只針對這些缺口修改。
5. STOP：
- 全部 PASS → DONE
- 達 MAX_PASSES → 停止，列出未解決問題
- 需要外部資訊 → REQUEST EVIDENCE
- 需要人類決策 → ESCALATE
不要因為主觀覺得「已經很好」就提前停止。

它為什麼比「請仔細檢查三次」有用？因為它把什麼叫完成、什麼時候停寫成白紙黑字。而把控制流程攤在陽光下，正是 Graph Engineering 的起點。

明明可以一次開單，為什麼要排三次隊？

想像一位病人來看門診，醫師交代：

醫門診醫師

「先去抽血，抽完再去照 X 光，照完再去做心電圖。」

病人跑了三趟、排了三次隊。可是這三件事根本不需要等彼此的結果，一次開單、同時進行就好。

我們叫 AI 做事時，也常犯一模一樣的錯。比如要它做市場研究：搜尋市場規模、分析競爭者、整理使用者評論、研究價格、驗證資料、撰寫報告。

前四項其實互不相干。只是因為我們習慣用「先做 A、再做 B、再做 C」的句子說話，它們就被硬生生排成一條隊伍。

Anthropic 也把 Parallelization 列為重要模式：子問題彼此獨立，就同時處理、再彙整結果。它自家的多代理研究系統更進一步，直接派好幾個 Agent 分頭探索不同方向。

三塊積木：Node、Edge、State

• Node誰負責做什麼LLM、Agent、搜尋工具、一段 Python、一句 SQL、一支 API、一次人工審核都算。一個樸實無華的 deduplicate() 也是 Node。
• Edge什麼條件下，往哪裡走不只是箭頭，而是「我需要你的結果」這層依賴。PASS 就發布，FAIL 就退回修改。
• State大家共同知道什麼查詢、來源、發現、草稿、改了幾輪……整個任務的共用白板。

LangGraph 的 Graph API 用的也是這套積木：State 存狀態、Node 做事、Edge 決定下一步，可以是固定路線，也可以依條件分流。

{
"query": "...",
"sources": [],
"findings": [],
"verified_findings": [],
"draft": "",
"revision_count": 2
}

好的架構，不是讓每個 Agent 都去翻整本聊天紀錄，而是每個 Node 只拿到它真正需要的那幾格。就像照會單只附上相關的檢驗數據，不會把病人十年的病歷全部影印過去。資訊給得剛剛好，Context 才不會被污染。

這支箭頭，真的存在嗎？

畫完 Graph，拿每一支箭頭來做個小測驗：

把前一個 Node 的輸出拿掉，下一個 Node 還能照常工作嗎？

如果答案是「可以」，恭喜，你抓到一條假依賴。

比如「先研究 Apple，再研究 Samsung」。研究 Samsung，需要先知道 Apple 的結果嗎？通常不用。

為什麼這件事這麼重要？因為 Graph 跑多久，看的是 Critical Path，也就是最長的那一條路，而不是 Node 有幾個。

就像煮一桌年菜：煮飯 20 分鐘、炒菜 25 分鐘、燉湯 30 分鐘。一道煮完才煮下一道，要 75 分鐘；三口爐同時開火，大約 30 分鐘就能開飯。什麼時候上桌，取決於最慢的那鍋湯。

AI 任務也是同一套算術：

所以 Graph Engineering 有一大半的功夫，其實都在問同一個問題：

哪些事情，根本不用排隊？

最好用的套路：Fan-out → Reduce → Verify → Synthesize

如果這篇文章只能記住一張圖，就記這張。翻成白話是：分頭找、合起來、驗一驗、寫出來。

文獻搜尋、市場研究、程式碼審查、資料抽取、事件檢討、多模型判讀，幾乎都能套。

angles = ["競爭者與定價", "使用者負評", "尚未滿足的需求"]
# FAN-OUT
raw = run_parallel([research_agent(a) for a in angles])
# REDUCE（交給程式）
findings = deduplicate(flatten(raw))
# VERIFY
verdicts = run_parallel([verifier(f) for f in findings])
survivors = [f for f, v in zip(findings, verdicts) if v == "keep"]
# SYNTHESIZE
report = synthesis_agent(survivors)

仔細看分工：

程式寫得出來的事，不要花錢請 LLM 用猜的。

自己出的考卷，別自己改

讓同一個模型寫完答案，再問它「你剛剛有沒有錯？」有用嗎？有一點。它能抓到一些粗心，但真正的盲點，往往還待在原地。

道理跟自己出考卷、自己改考卷一樣：出題時沒想到的，改卷時通常也想不到。

重要的任務要拆開：Generator 產出成果，交給另一個 Verifier 查核。Verifier 手上只拿要檢查的主張、必要的證據、評分規則，不去讀 Generator 一路怎麼想的，免得被帶著走、犯下同一個錯。

但也別把 Verifier 神化。如果兩邊讀的是同一份錯誤資料、信的是同一個假設、手上又沒有外部 Ground Truth，它們會非常有默契地一起錯。

所以該問的從來不是「我用了幾個 Agent」，而是：

錯誤的來源，真的彼此獨立嗎？

檢傷分級：不是每個案件都要推進急救室

急診不會把每個病人都推進急救室。檢傷先判斷嚴重程度，再依分級走不同動線；拿不準的時候，寧可往高一級分。

Agent 系統也需要這樣的分流：

判斷風險這件事，可以交給 LLM：

{ "risk": "high", "reason": "涉及高風險醫療決策" }

但病人最後送去哪一區，要由程式說了算：

switch (result.risk) {
case "low":    return runCheapPath();
case "medium": return runStandardPath();
case "high":   return runVerifiedPath();
default:       return runVerifiedPath(); // 判斷不出來，就走最保守的路
}

注意最後那行 default ：判斷不出來，就走最保守的那條路，跟檢傷的邏輯一模一樣。

讓 LLM 判斷語意，讓程式掌握控制權。

有了 Graph，Loop 還活得好好的

有人以為有了 Graph 就不需要 Loop。其實 Verify 沒過就退回 Revise，這本身就是 Graph 裡的一個迴圈。

另一種常見的迴圈是收斂式搜尋，用在不知道要找幾輪的任務，例如「找出某疾病所有重要的臨床試驗」。

做過文獻回顧的人一定懂這種痛：某篇文章讀完判定不相關，卻沒記下來；換個關鍵字，它又冒出來，你又從頭讀了一遍。

Agent 也會這樣。所以要維護的是 SEEN （看過的），而不只是 ACCEPTED （收下的）。被淘汰的資料也要記進 SEEN ，否則系統會陷入「找到、丟掉、再找到、再丟掉」的鬼打牆。

所以這幾個概念，不是新技術把舊技術踢下台，而是一層疊一層，各自顧好自己那一段。Graph 真正多出來的，是對整個團隊怎麼協作的掌控。

算帳時間：看整張 Graph，不只看 Token

總成本 ≈ Σ 各 Node 成本 + 工具成本 + 重試成本
延遲   ≈ Critical Path 的長度

這裡有個常見誤會：平行化能讓你少等一點，卻不一定讓你少花一點。多派幾個 Worker，帳單可能反而更長。

所以別問「能不能多開幾個 Agent」，要問：多開這一個，換來的資訊值不值這個錢？

• Model Tiering殺雞不用牛刀

  分類、抽取、格式轉換、找重複候選這種粗活，交給小模型；複雜推理、裁決、驗證、最後統整，才請出高能力模型。

• Early Exit夠了就收手

  證據夠了、信心過了門檻，就停止搜尋，不必再多翻十篇大同小異的資料。

• Barrier 只在必要時設不必全員到齊

  只有全域排序、全域去重、跨文件比較，才需要等所有 Worker 回來；其他結果，完成一份就先往下送一份。

什麼時候，千萬別做 Graph

Graph 很迷人，迷人到很容易被濫用。

「整理這篇文章」，叫一次模型就夠；「寫、檢查、修改」，一個 Loop 就搞定。為了煮一碗泡麵蓋一條產線，只會把事情越弄越複雜。

真正值得動用 Graph 的，是這些情況：

• 有好幾件獨立的工作可以同時做
• 不同任務要用不同的工具或模型
• 有清楚的分流規則，或某些步驟需要獨立查核
• 有權限與風險邊界，或需要人類中途介入
• 失敗時只想重做一小段，需要保存 State
• 任務長到塞不進單一 Context

Anthropic 的建議很務實：先用最簡單、可以組合的做法，真的需要時才加複雜度。Agent 系統本質上，就是拿成本和延遲去換更強的任務能力。如果整篇文章只能帶走一句話，大概就是這句：

先用最簡單的架構。真的需要，才加複雜度。

上線前，先問自己這幾題

• 架構每一支箭頭，都是真的「我需要你的結果」嗎？能同時做的事，是不是還在排隊？每個 Node 是不是只負責一件事？
• State存的是事實與決策，還是一整坨聊天紀錄？每個 Node 是不是只看到它需要的 Context？中途斷掉，能從 Checkpoint 接著跑嗎？
• 驗證程式驗得了的，是不是都交給程式了？高風險輸出有獨立查核嗎？Verifier 拿得到外部證據嗎？
• Loop成功條件、MAX_ITERATIONS、Token 預算，三樣都寫清楚了嗎？連續沒進步時，它會自己停下來嗎？
• 營運工具失敗能重試嗎？重試會不會重複寫入（idempotency）？高風險操作，有人類按下核准鍵嗎？
• 成本小模型搞得定的 Node，是不是還在用昂貴的模型？平行化是真的縮短了 Critical Path，還是只是多打了幾次 API？每個 Node 的成功率、延遲與成本，都有記錄嗎？

不是更多 Agent，而是更好的控制結構

從 Chat 到 Agent，AI 開始自己決定下一步。
加上 Loop，它學會跌倒了自己爬起來。
走到 Graph，我們開始設計一整個團隊怎麼分工合作。

成熟的 Agent 架構，不是把十個模型串在一起，也不是讓模型無止盡地反省自己，而是心裡有數：

什麼交給 LLM 判斷，什麼交給程式決定；
什麼得排隊，什麼能同時做；
什麼資訊要共享，什麼 Context 要隔開；
什麼可以放手讓它跑，什麼時候一定要踩煞車。

我們正在從 Engineering the Prompt，走向 Engineering the System Around the Model。

「Graph」這個詞新不新，其實不是重點。重點是，當 Agent 真的開始替我們上班，模型聰不聰明已經不是唯一的問題：

這整個團隊怎麼被組織起來，才決定它靠不靠得住。