Appearance
別再堆 Pipeline 了，該做的是 Agent：一篇談 LLM 系統設計取捨的文章
原文連結：https://seangoedecke.com/build-agents-not-pipelines/
文章說明
這篇文章討論的是一個近來很常被問到的工程問題：做 LLM 產品時，到底應該把流程寫死成 pipeline，還是給模型工具與回合控制，讓它以 agent 的方式自己找上下文、自己決定步驟？作者不是空談概念，而是從可預測性、上下文組裝、成本、安全性與未來適應性逐點比較。
內容介紹
作者首先給出一個非常清楚的區分。pipeline 的本質，是由程式碼決定控制流程，模型只負責某一個步驟；agent 則是把工具交給模型，讓模型自己管理控制流程。前者像傳統函式式流程，後者更像一個可自我迭代的問題求解者。
他承認 pipeline 的優勢很直接：較容易預測 latency、成本與上下文大小，因此適合大規模、嚴格受限、必須控制 GPU 預算的任務，也比較適合本地小模型環境。但作者認為，真實世界中最難的問題往往不是推理本身，而是「怎麼收齊足夠上下文」。在這一點上，agent 幾乎天然佔優，因為它可以在過程中意識到自己缺什麼，再去搜尋、讀檔、拉資料，而不是要求工程師事先完美組裝 prompt。
文章對 RAG 的評價也很尖銳。作者認為，2023 到 2024 年很多人以為 semantic search 和向量檢索會自動解決上下文收集問題，但實際結果並沒有。原因在於「找出哪些資訊和問題真正相關」本身就是一個很難的任務，不見得比最後生成答案簡單。因此，與其寄望離線索引一次搞定，不如讓 agent 用比較接近人類的方式做 plain-text search，再一步步收斂。
安全與可讀性方面，作者的立場也頗鮮明。他不同意「workflow 一定比較安全」這種常見說法，因為不論是 pipeline 還是 agent，只要模型會根據外部內容採取行動，就都需要工具權限約束、輸入淨化與人工審核。兩者真正差別更多在於 legibility 與資源控制，而不是本質上的安全無虞。
文章最後提出幾條實用判準：如果你需要嚴格控制上下文大小、GPU 成本或依賴 local model，就偏向 pipeline；如果你無法確定能一次備齊上下文，或任務本身很難、需要動態探索，那就應該選 agent。作者甚至進一步說，現在他看到很多團隊從 pipeline 遷往 agent，卻很少看到反向遷移。
你可以帶走的重點
LLM 系統設計的關鍵難題，常常不是生成，而是上下文蒐集。
pipeline 的優勢在可控與可預測，agent 的優勢在彈性與解題能力。
RAG 不是萬靈丹，因為「找對上下文」本身就是高難度問題。
當任務複雜到無法預先決定每一步時，agent 通常比 pipeline 更實際。
真正的安全設計來自工具邊界與審核機制，而不是名稱叫 workflow 還是 agent。
適合誰閱讀
- 正在設計 AI agent、工作流或多步推理系統的工程師
- 想理解 pipeline、RAG、agent 取捨的產品與技術主管
- 常在實務上糾結「該讓模型自己找資料，還是我先餵好」的開發者