自架 Agent 的五道牆

動手前先講一個最重要的觀念。Chat 就是你問、它答,背後只有一顆語言模型。而 Agent,是在 chat 之外多掛了工具,而且模型會自己判斷什麼時候該去用哪個工具。這句話是整集的骨架:一個沒有工具的 agent,只是換了個殼的聊天機器人。接下來的每一道牆,其實都是「讓模型真的去用工具」這件事,在不同地方壞掉。

我的目標很單純。用一個自己架的對話平台,好處是非技術的人只要開瀏覽器打字,底層要換雲端還是本機模型,全在後台調。然後掛一顆語言模型當大腦,再給它一個網路搜尋工具。設定好之後,理論上我問天氣,它就會自己去搜。理論上啦。實際上,第一道牆馬上就來了。

第一顆大腦我用免費的雲端模型。純聊天完全沒問題,一秒就回。可是我一把它升級成帶工具的 Agent,對話就回我一片空白。翻到後台的錯誤訊息,真相很清楚:它說這次請求太大,超過了每分鐘的 token 上限,直接被擋下來。免費方案每分鐘只給八千個 token,但我這個帶工具的請求,居然要兩萬六。超標三倍。

為什麼多了工具,請求就大這麼多?關鍵在這裡:每一個工具,都有一份告訴模型「你怎麼用我」的說明書,而這份說明書,會整份塞進送給模型的請求裡。你掛越多工具,說明書就疊越厚,加上模型自己的思考骨架,一下就把免費的額度撐爆。所以才會出現「純聊天好好的,一帶工具就破表」這種怪現象。

想解第一道牆,我去調一個叫「最大輸出長度」的參數,結果掉進第二道牆。這個參數設太小,模型光是「想」就把額度用光了,還沒開口就沒空間,回你空白。設太大呢,系統會幫你「預留」那麼多空間,而這個預留也算進請求量,又撞上限被擋。打個比方,這個預留就像訂位:兩個人吃飯,你卻訂了一萬個位子,餐廳當然直接拒收你。得抓到一個剛剛好的值,才不會左邊掉空白、右邊撞牆。

免費雲端帶不動,那我換成自己機器上的模型,至少沒有每分鐘額度這回事。好消息是,它真的去呼叫了工具,也真的查到台北天氣的資料。壞消息是,它太慢了。我從後台量它每一輪的時間:在沒有顯示卡、純靠 CPU 的機器上,光是一輪推理就要五到七分鐘。而一個 agent 至少要跑兩輪:先決定去查,查回來再寫答案。整條加起來十幾分鐘,遠遠超過連線願意等的時間,中途就被切斷了。

這道牆最讓人惋惜。我去查資料庫,發現它其實把最難的部分做對了:真的呼叫了搜尋工具,也真的拿到了真實的天氣資料。問題出在最後一步,它在把資料整理成答案的時候,連線就被時間砍斷了,所以資料庫裡存下來的最終答案,是空的。它不是不會做事,是慢到來不及把事做完。

第四道牆,是我覺得最危險的一道。我換回反應快的雲端模型,用一句很鬆的指令叫它幫我查。這次它秒回,而且吐給我一張無懈可擊的天氣表:早上幾度、下午幾度、降雨機率多少、濕度多少、風向如何,漂亮到我差點就相信了。但我心裡有個疑問:它真的查了嗎?還是它在編?我決定去查後台。

後台有三個地方會露餡。第一,agent 的工具執行紀錄是空的 —— 它根本沒真的去查。第二,這次送給模型的資料量小得可疑;如果真查到東西,搜尋結果會塞回去、量會大很多。第三,它只花兩秒就回了,根本沒有「先查、等結果、再回答」那兩輪的時間。三個證據交叉起來,結論很硬:那張漂亮的天氣表,整個是它憑記憶編出來的假數字。這就是 agent 最危險的坑,假裝用了工具。畫面完美,不等於它真的做了事。

第五道牆有點狼狽。我在切換模型的過程中,一度把整台機器搞到對外掛掉。查下去是記憶體爆了:一顆大模型、一顆小模型、對話平台,再加上機器上原本就在跑的一堆服務,把記憶體整個塞滿,系統只好瘋狂把東西搬到硬碟上,慢到所有服務都回不了話。這不是程式的錯,是硬體的天花板:一台什麼都在跑的共用機器,本來就扛不住這麼多大模型。

踩完這些坑,我學到一件反直覺的事:提示詞裡如果把工具的名字寫死,反而可能讓模型回空白 —— 因為你寫的名字跟系統裡真正的函數名對不上。正確的寫法,是描述你要它做的「行為」:遇到會變動的即時資訊,就先上網搜尋最新資料再回答,工具讓平台自己去配對。而最實用的一招,是要求它回答時附上來源網址。真的查過,才貼得出真網址;用編的,它貼不出來 —— 這一條就是最好的測謊器。

把五道牆串起來,結論其實很乾脆:agent 要真的做事,免費的雲端額度帶不動;而沒有顯示卡的本機,又慢到撐不完一整輪思考。中間沒有免費的午餐。你要嘛付費把雲端的額度解開,要嘛老實去準備一台有顯示卡的機器。這也正是為什麼,想在自己家裡認真跑 agent 的人,最後都會走向「買一台專用機器」這條路。

最後留給你一句話:做 agent,不要只看畫面,要看紀錄。一個 agent 可以給你一張無懈可擊的表,底下卻什麼都沒查。上線前,養成去看它「到底有沒有真的呼叫工具」的習慣 —— 這一個動作,會幫你擋掉最貴的那種錯:拿著編出來的數據,去做真的決策。