Graph Engineering 是什麼？別把 Agent 編排圖與知識圖譜混在一起
從一份社群流傳的 Graph Engineering PDF 出發，釐清 Agent 工作流程圖與知識圖譜的差別，並說明多代理系統何時需要兩種圖、何時只會增加不必要的維護與評估成本。
目錄+
2026 年 7 月，一則 X 貼文把一份 12 頁 PDF 稱為多代理系統的「Graph Engineering」指南，並用一句很有吸引力的流程總結：Extract → Resolve → Assemble → Query → Repeat。這個框架確實適合拿來思考 Agent 的長期記憶，但在採用之前，得先把來源和名詞拆清楚。
最重要的查證結果是：這份 PDF 的封面已明載它是 2026 年 7 月的獨立整理材料，未獲 Anthropic 背書，也不代表 Anthropic 官方立場。目前找得到的一手技術來源，是 Anthropic 公開的 Knowledge Graph Cookbook、Agent 架構文章與 Claude API 文件。換句話說，PDF 可以當成閱讀地圖，技術判斷仍應回到官方範例與自己的測試。
這個澄清不會削弱主題，反而讓問題更精準：當多個 Agent 要共享資訊時，我們到底在設計哪一種「圖」？
同樣叫 Graph，其實在回答兩個問題
Agent 系統裡最常被混用的是 Task／Workflow Graph 與 Knowledge Graph。
Task Graph 回答的是「接下來做什麼」。節點可能是 planner、researcher、writer、reviewer；邊代表交接、條件分支、重試或結束。它管理執行順序、狀態與錯誤恢復，也就是 orchestration。像 Claude Code Dynamic Workflows 裡的 implementer、verifier、fixer，就是典型的工作流程角色。
Knowledge Graph 回答的是「我們知道什麼，以及這些事物如何相關」。節點是人物、公司、產品、文件或事件；邊是任職、投資、依賴、引用等有語意的關係。它管理實體識別、跨文件連結、證據與時間。若想先看實際的 graph memory 產品形態，可對照 GBrain 的 Knowledge Graph 記憶設計。
| 比較面向 | Task／Workflow Graph | Knowledge Graph |
|---|---|---|
| 核心問題 | 下一步由誰做、何時做 | 哪些實體彼此有什麼關係 |
| 節點 | Agent、工具、任務、狀態 | 人物、組織、文件、事件、概念 |
| 邊 | 轉移、條件、重試、依賴 | founded、works_at、cites、depends_on |
| 主要讀者 | orchestrator、runtime | researcher、retriever、answer agent |
| 常見失敗 | 死循環、重複派工、狀態遺失 | 同名誤合併、關係誤寫、證據失聯 |
| 更新時機 | 每次任務執行 | 新來源進入或舊事實失效時 |
把兩者都翻成「Agent Graph」，就很容易做錯架構。例如把每一個 workflow checkpoint 都塞進知識圖譜，結果是查詢充滿暫時性狀態；反過來，把實體關係只留在某個 Agent 的 checkpoint，下一次執行又得重新抽取，無法形成可重用記憶。
Graph Engineering 不是把所有資料都畫成圖
如果要給 Graph Engineering 一個實用定義，可以把它理解為：針對圖資料的生命週期做工程，而不只是選一套 graph database。
它至少包含四個層次。
第一層是 schema：系統允許哪些實體類型與關係？works_at 是否有方向？同一關係能不能同時存在不同時間區間？如果 schema 只靠 prompt 裡的一段自然語言，兩個 Agent 很快就會寫出不同拼法。
第二層是 identity：來源裡的「Anthropic」「Anthropic PBC」和代名詞「該公司」是否指向同一節點？Entity Resolution 做錯時，之後的 multi-hop query 即使 SQL 完全正確，也只會更有效率地回傳錯誤答案。
第三層是 provenance：每一條關係來自哪份文件、哪段文字、哪一次抽取？Structured Output 可以確保 JSON 符合 schema，卻不能保證內容符合原文。沒有證據指標，就沒有辦法讓 reviewer 或使用者檢查。
第四層是 operations：新文件進來時要全量重建還是增量更新？舊關係失效時是刪除、覆寫，還是補上 valid_to？prompt、模型或 schema 升級後，要如何知道品質變好而不是只是產生更多邊？這些才是「Engineering」真正困難的地方。
Extract → Resolve → Assemble → Query 各自在做什麼
Anthropic 公開 cookbook 示範的主幹可以整理成四步。
Extract 從非結構化文字辨識實體與候選關係。輸出應該受 schema 約束，也應保留原文證據，不能只留下模型改寫後的句子。
Resolve 把不同文件的 mention 對到 canonical entity。這一步不能只看字串相似度；同名不同人、公司更名、縮寫與跨語言名稱都需要保守處理。無法確定時，暫時分開通常比錯誤合併安全。
Assemble 把通過驗證的節點、關係、來源與時間寫入持久層。組裝不是單純 insert：還要處理重複匯入、版本、owner 邊界與同一來源重跑。
Query 從一個或多個 seed entity 展開有限深度的子圖，再把相關證據交給回答 Agent。真正安全的做法是限制 hop 數、回傳 relation ID 與 evidence，而不是把整張圖直接塞進 context。
PDF 增加的 Repeat 很適合當成第五步，但它不是「不停重跑」：它應該是有條件的更新與評估回路。新來源、人工修正、schema 版本或 gold set 結果改變時才觸發，並保留前後版本供追蹤。
Extract 與 Resolve 這兩段最吃算力：實體抽取要跑模型推論，解析要反覆比對。本地驗證流程時，麗臺 RTX PRO 4000 Blackwell 的 32GB VRAM 足以同時放下抽取模型與向量索引。
兩張圖如何在多代理系統裡合作
假設你有一個市場研究系統。Orchestrator 先建立工作流程：公司研究 Agent、人物研究 Agent、來源核對 Agent 可以並行；最後由 synthesis Agent 整理。這是 Task Graph。
研究 Agent 讀到文件後，不直接互相傳遞一大包聊天紀錄，而是產生候選實體、關係與證據。Resolver 對齊 identity，writer 寫入共享圖譜。後續 Agent 查詢同一家公司時，可以取得已解析的關係與原始證據。這是 Knowledge Graph。
兩張圖之間最好只有幾個清楚的動作：extract_candidates、resolve_entities、persist_graph、query_subgraph。工作流程知道這些工具成功或失敗，卻不需要理解每張資料表；知識圖譜保存可重用事實，卻不負責決定下一個 Agent 是誰。
Anthropic 的多代理研究系統也提醒了一個現實：多 Agent 適合可平行、資訊量大而且價值足以支付成本的任務；依賴高度緊密的工作，未必適合拆成很多 Agent。圖譜同樣不是多 Agent 的入場券，而是一個在特定查詢型態下才值得承擔的資料層。
什麼情況先不要導入 Knowledge Graph
以下情況通常先用更簡單的方案：
- 只要保存同一次執行的進度：用 checkpoint。
- 只要找語意相近段落並附來源：先用 RAG。
- 資料有明確主鍵且查詢固定：一般關聯式資料表更直接。
- 文件少、關係不跨來源、沒有多跳問題：在應用層整理即可。
- 團隊還沒有 gold set、版本與人工修正流程：先建立評估，再增加資料結構。
知識圖譜真正有優勢的場景，是問題必須沿關係走兩步以上，例如「某產品依賴哪些供應商，而這些供應商又受哪些政策事件影響」；或同一實體跨很多來源出現，且答案必須說明每條關係從哪裡來。若需求只是「找與這段話最相近的文件」，向量搜尋通常更省事。
一份可執行的設計檢查表
在建立 graph memory 前，先回答以下問題：
- 系統要解的是執行順序，還是跨文件關係？若兩者都有，明確分成兩張圖。
- 每種實體和關係的 schema、方向與時間語意是什麼？
- Entity Resolution 無法確定時，預設合併還是分開？建議分開並標記待審。
- 每條關係能否回到 source、quote、run、prompt 與 schema version？
- query 最多走幾 hops？找不到證據時是否明確拒答？
- 哪些 gold cases 可以偵測 over-merge、under-merge 與錯誤關係？
- 新版本能否重跑而不產生重複資料，並比較更新前後結果？
這套檢查表比「該選哪一套 graph database」更早，也更重要。資料庫只負責儲存與查詢；你仍要為 identity、evidence、時間與評估做決定。
下一篇會把記憶系統拆成 Context、Checkpoint、RAG 與 Knowledge Graph 四層，提供更直接的選型方式。如果你想先看相近的混合搜尋案例，也可以參考 OpenSpace 的 Graph RAG 知識庫。完整的 Claude＋Supabase 實作則放在訂閱教學：建立可追溯的多代理共享記憶。
來源與延伸閱讀
- 原始分享的 Graph Engineering PDF：獨立整理材料，封面明載未獲 Anthropic 背書。
- Anthropic Knowledge Graph Cookbook：Extract、Resolve、Assemble 與 multi-hop query 範例。
- Anthropic：Building Effective Agents：workflow、agent 與「先從簡單系統開始」的原則。
- Anthropic：How we built our multi-agent research system：orchestrator-worker、共享記憶與 multi-agent 評估經驗。
常見問題
Graph Engineering 是新的技術嗎？
它比較像一個工程視角，而不是突然出現的新資料結構。實務上是在同一套系統裡設計工作流程圖、知識圖譜、更新規則與評估方法，並讓每一種圖只負責適合自己的問題。
Agent Graph 和 Knowledge Graph 可以一起使用嗎？
可以。工作流程圖決定哪個 Agent 何時執行，知識圖譜提供跨任務可重用的實體、關係與證據。關鍵是用少量、明確的讀寫介面連接，而不是把它們合併成一張萬能圖。
只有一個 Agent 也需要 Graph Engineering 嗎？
不一定。若任務短、資料量小、沒有跨文件關係查詢，普通資料庫、checkpoint 或 RAG 通常更簡單；只有當關係、溯源與更新成本成為核心問題時，才值得引入知識圖譜。
利益揭露：本文含聯盟連結，透過連結購買我可能取得少量分潤，不影響你的價格與本文內容。