我以為搞定RAG，就等於掌握了LLM應用的要訣………。
事實上，當我著手建構Agent時才明白，RAG只是在為「大腦」增加「腦容量」，而Agent是在把一個「數位靈魂」賦予整個神經系統。
排程、記憶、工具呼叫，這三道魔王關背後是無盡的挑戰。
本文又是一個工程團隊的心酸血淚史，在下把這個故事公諸於眾，就是希望不要再有人跌死在散兵坑裡了，畢竟折損的英雄只能是一坯黃土….。
自從上次被RAG專案按在地上摩擦之後，我們Team立志發憤圖強的掌握了「Chunk切分」、「混合檢索」和Re-rank這些「絕世武功」之後，團隊內部信心開始高漲，一度以為LLM的應用已經難不倒我們了。客戶也對我們刮目相看，馬上又開出新的菜單，對著我們的軟體研發經理說：「郭經理啊，知識庫Agent幹得不錯！現在，我們要來個大的!! 實現一個「企業級AI Agent」，把我們的OA審核、IT維運、客戶商機跟進，這些流程都串起來，實現『無人化』操作！」。
哇!!，「無人化」！團隊的熱情又一次沸騰了。如果說RAG是給「大腦」擴大了腦容量，那Agent就是給大腦接上了手和腳啊！這不就是我們夢寐以求的，用程式碼改變世界的時刻嗎？
我自信滿滿地打開了Lang Chain/Llama Index的Agent模組，心想：不就是「RAG + Tool呼叫」嘛，在RAG的基礎上，多給它幾個API，多寫幾個if-else，這種事，小Case！
然而，事情絕對不是我想像的那麼簡單，沒想到Agent工程背後直接就是魔王關，而且一次就遇到魔王三兄弟……..。
第一關：從「單一思維邏輯」到「排程修羅場」，我的Agent像個精神分裂患者!!
我的第一個Agent，是做一個「自動處理IT報修」的流程。邏輯很簡單：用LLM理解用戶的報修（比如「我電腦上不了網了」）。呼叫工具A（知識庫RAG）查一下有沒有類似的解決方案。如果沒有類似案例，則呼叫工具B（企業IT系統API）建立一個報修單。
我用了最經典的ReAct（Reason + Act）模式，讓Agent一步步思考、一步步行動。Demo跑得飛快，我再次露出了「英雄式」的微笑。
然後，內部測試開始了。用戶A說：「我好像上不了網，但又好像可以，你幫我看看是不是DNS的問題，如果不是，再幫我查查上週那個『KB-305 Patch』有沒有影響，實在不行再報修。」用戶B同時報修：「我的VPN連不上了！」結果我的Agent當場當機。
面對用戶A那「既要...又要...還要...」的複雜指令，我的ReAct Agent直接陷入了無限迴圈，在「查DNS」和「查Patch」之間反覆跳轉，最後把上下文Token耗盡，光榮犧牲。結果面對用戶B時，它還在處理A的工單，完全沒辦法處理有任何產出。
果不其然，我被客戶的CTO叫到辦公室，他指著我的架構圖發出了靈魂拷問：「你這個Agent只會一條路走到底嗎？它不懂規劃和選擇？ReAct、CodeAct、Self-Reflection這些模式，你告訴我它們有什麼區別，你為什麼選ReAct？」 我這才知道，原來Agent不是只有一種邏輯。對於複雜任務，需要Planner-style的「Agent」預先生成一個計劃(比如一個 DAG - Directed Acyclic Graph任務圖)，再讓執行者（Executor）去按步就班的完成。對於需要自我除錯的任務，Self-Reflection（自我反思）模式能讓Agent在執行失敗後，自己分析原因並修正計劃。而我選ReAct，純粹因為它最簡單。「兩個任務同時進來，你的Agent就掛了？任務拆分、衝突協調、上下文隔離呢？你的任務排程呢？失敗了能Roll-Back嗎？」 我瞬間傻掉。我壓根沒想過這些。我以為Agent是單執行緒的超級賽亞人，沒想到它只是個需要精密排程的普通工人。我這才意識到，我需要的不是一個「Agent」，而是一個Agent排程系統。一個能將複雜任務分解成DAG，能處理並行緒，能在任務失敗時精准Roll-Back到上一個狀態的「中樞神經」。
那一刻，我感覺自己不是在做AI，而是在從零開始手寫一個分散式的任務排程框架，只不過工人是「號稱」能飛天遁地的LLM。
第二關：從「臨時記憶」到「記憶工廠」
話說我的Agent得了健忘症還總被汙染!，我忍著痛，開始設計任務排程和多Agent架構。這時，第二個大魔王出現了——Memory（記憶）。
為了讓Agent記住對話歷史，我給它掛了個ConversationBufferMemory。結果，上下文視窗很快就被閒聊灌滿了，真正有用的資訊反而被擠了出去。更要命的是，當Agent呼叫工具時，工具傳回的大段JSON，結果也被塞進了Memory，嚴重汙染了後續的推理。它就像一個腦子裡塞滿了日誌和程式碼的病人，已經無法正常思考。
記得曾經請教一個資深的大神時，他輕描淡寫地問我：「當你說『掛載了memory』，你指的是哪種？」是Scratchpad的上下文補全？ （我用的就是這個，簡單粗暴）還是Embedding + Search的Semantic Memory？ （能檢索長期、相關的記憶，而不是一股腦全塞進去）還是具備寫入、更新、清理能力的長期記憶系統？ （比如Agentic Memory，能讓Agent像人一樣形成、鞏固和遺忘記憶）「Memory和Tool同時干擾上下文，你怎麼解決的？」他一連串的問題砸得我頭暈眼花：Prompt壓縮？Cache？Embedding過濾？還是獨立的MemoryController？我終於明白，Agent的Memory根本不是一個簡單的聊天記錄…它是一個複雜的「認知系統」。
我需要一個Memory Controller，像大腦的海馬體一樣，決定哪些是需要丟棄的瞬時記憶，哪些是需要存入向量庫的語義記憶，哪些是需要結構化儲存的長期關鍵資訊（比如KV-based Memory）。而我，之前只是給了它一個容量無限但沒有整理功能的「垃圾桶」。
第三關：從「靜態工具箱」到「可插拔系統」。我最初的做法，是把工具的Schema寫死在程式碼裡，然後在Prompt裡手動拼接：「你可以使用以下工具：[Tool_A_Description], [Tool_B_Description]...」。這作法在工具少的時候還能頂一下，但當公司幾十個API都想接進來時，我的Prompt變得比老太婆的裹腳布還長。
而且一旦工具的介面變了，我就得去改程式碼和Prompt，那真是苦不堪言。更恐怖的是，Agent經常會「用錯工具」或者「不會用工具」。它會給一個只需要字串的參數，硬塞一個JSON進去，導致工具呼叫失敗。失敗後，它只會傻傻地回答：「對不起，我無法完成任務。」這時，我才從一個真正做過生產級Agent的架構師那裡學到，業界的玩法已經進化了：
A.工具注入： 高級的Agent系統，工具是動態註冊和發現的，而不是寫死的。
B.參數對齊： 根本不是靠Prompt拼接，而是通過Structured Output（結構化輸出），讓LLM生成與工具介面Schema完全對齊的JSON，實現自動呼叫。
C.工具路由（Tool Router）： 在眾多工具中，需要一個獨立的「工具選擇器」或者一個更小的模型，來決定當前步驟最應該呼叫哪個工具，而不是讓主LLM去猜。
D.容錯與回溯（Fallback）： 工具呼叫失敗，不能直接放棄。系統必須有重試、使用備用工具、或者向用戶澄清問題的Fallback策略。
我這才恍然大悟：我之前做的，只是在「呼叫工具」。而企業需要的，是建構一個「可插拔、可配置、高容錯的工具執行系統」。這二者的差距，就像是拿著螺絲起子擰螺絲和設計一條全自動的工業生產線的區別。
最後的拷問：你的Agent，能上線嗎？當我焦頭爛額地在「排程」、「記憶」、「工具」這三重門裡掙扎時，關於效能、可觀測性、安全性的現實問題也接踵而至。
「你的Agent為什麼這麼慢？」 我不知道，是因為Token太多？檢索太慢？還是工具鏈路太長？我沒做過Tracing，沒用過LangSmith或OpenAgentMonitor之類的工具去診斷鏈路。
「你的Agent安全嗎？」 我沒想過。Prompt注入、資料越權、Token濫用……一個惡意的提問，就可能讓Agent呼叫高權限API，殺了資料庫然後跑路。我沒有設計存取邊界和稽核日誌。……走到今天，我終於深刻理解了Agent工程的本質。它根本不是「LLM + 幾個工具」的簡單組合。它是以LLM為核心的、全新的軟體工程典範-Agentic Engineering。它要求我們成為一個矛盾的結合體：既要像AI研究員一樣，理解模型的行為邊界和推理模式；又要像一個最資深的系統架構師，去設計一個有行為邊界、結構清晰、狀態穩定、可容錯、可觀測、高安全的分散式智慧系統。
現在，如果再有人問我Agent是什麼，我不會再輕飄飄地回答「AI助理」。我會說，它是一個披著AI外衣的「系統工程」。而我，就是那個正在坑底，試圖為這個時而天才、時而智障的「數位員工」搭建一個安全、穩定、高效的「辦公室」的卑微工程師。路漫漫其修遠兮，我的頭髮，可能真的保不住了。