Demo 會動只是起點：Agent 開發者近兩年踩出來的五道工程題

（2026 年 9 月 22 日，一位在企業內做 Agent 開發的工程師在掘金發表了近兩年的實作復盤。這篇文章近期又在技術圈被轉發討論，原因不難理解：越來越多公司正從「做一個 AI 助手 Demo」走向「讓它上線跑業務」，而兩者之間的距離，正是這篇心得的主題。）

文｜何柏

做 Agent 最好看的瞬間，是 Demo 第一次跑通的時候。模型聽懂了需求，自己挑了工具，吐出一段像模像樣的結果，會議室裡所有人都點頭。

頭痛從第二階段開始。使用者換了一種問法，前面的脈絡全丟了；工具回了一個語焉不詳的錯誤，Agent 開始亂槍打鳥；改了一句提示詞，A 場景好了，B 場景壞了；上線第二天，帳單和延遲一起爆表。

這篇心得的核心判斷很樸素：框架解決的是膠水問題，怎麼呼叫模型、怎麼註冊工具、怎麼組訊息；真正難的是框架底下的工程題。不論用 LangChain、LangGraph、Spring AI 或自研迴圈，這些題目一題都少不了。就算用上字節的 DeeerFlow 這類把部分工程問題包掉的開源框架，最終面對實際業務時，開發者還是得自己接手。

這也是它值得非工程師讀的原因。它講的其實是任何一套要上線的軟體系統都會遇到的老問題，只是被大模型的不可預測性放大了。

狀態：難在會丟，也難在會衝突

第一道題是上下文。難點不在寫提示詞，而在於 Agent 的上下文並非一份聊天記錄，而是一個隨任務推進不斷變動的執行期狀態。

作者舉的例子很生活化。一個汽車門市銷量助手，使用者先問「上海上週銷量多少」，接著說「那杭州呢」。人一聽就懂：繼承「上週」和「銷量」，只把城市換掉。但如果系統只把「那杭州呢」這一句丟給模型，模型既不知道要查銷量，也不知道時間範圍。

很多人的直覺是把更多歷史資料塞進去。短期有效，長期會生出麻煩：關鍵資訊留在舊對話裡沒被繼承；系統規則說只能查最近三十天，歷史裡卻留著使用者查過去年資料的痕跡，兩邊打架；工具回傳、檢索片段、執行日誌全塞進上下文，模型反而找不到重點，像把整櫃文件倒扣在桌上要人找一張發票。

作者的解法是程式設計裡的老套路：維護一個明確的查詢狀態物件，城市、日期、指標各佔一個欄位。使用者說「那杭州呢」，只更新城市欄位，其他不動。流程拆成四步：模型讀最近對話加當前狀態，輸出結構化意圖；程式驗證城市、日期、指標是否合法；只合併允許變動的欄位；用新狀態去查資料。

一句話總結：程式維護狀態，模型解析意圖。分工清楚，責任才落得了地。

工具：把概率系統接到確定性介面上

第二道題是工具呼叫。看起來只是讓模型呼叫函式，麻煩全在失敗場景。模型可能傳出「魔都」這種口語別名當城市參數，資料庫裡沒有這個值；參數格式不對；介面逾時。模型的輸出是概率性的，工具的介面是確定性的，兩邊之間需要一層翻譯與護欄：參數校驗、別名對照、錯誤訊息改寫成模型看得懂的提示，讓它有機會自我修正而不是開始亂試。

這層道理對所有接外部系統的開發都熟悉，差別在於傳統系統的呼叫者是另一段可靠的程式碼，Agent 的呼叫者是一個會自信地犯錯的模型。

錯誤、回歸與帳單：三道收尾的題

剩下的三道題，本質都是紀律問題。

錯誤恢復：工具失敗時要能重試、降級或明確告訴使用者辦不到，不能讓 Agent 陷入無限循環式的嘗試。效果回歸：提示詞一改，過去能跑通的案例可能全壞，需要像寫測試一樣維護一套評估案例集，每次變動都跑一遍。延遲與成本：多輪工具呼叫疊加起來，回應時間和帳單都會超出預期，需要在模型選擇、快取、流程裁剪上做取捨。

這三件事沒有捷徑，它們就是軟體工程本身。這也是為什麼這篇心得會被反覆轉發：它把「做 AI 應用」從神祕的模型魔法，拉回到每一個寫過系統的人都認得的日常。這與我們先前在AI 崗位三輪面試的篩選邏輯裡看到的趨勢一致，企業要的不只是會呼叫模型的人，而是能把概率性的模型接進確定性業務系統的工程師。

一般工作者能帶走什麼

就算不寫程式，這五道題也提供了一個有用的檢核清單。當公司宣布要導入 AI 助手，值得問的問題是：它記得住上一輪對話裡的關鍵條件嗎？它填錯表格欄位時系統會擋下來嗎？出錯時它會承認還是硬拗？改版之後有人重測舊功能嗎？每個月帳單預估是多少？

Demo 展示的是模型的能力上限，上線考驗的是工程的底部扎不扎實。這篇近兩年的復盤給出的答案很實在：上限每天都在漲，底部卻只能靠人一吋一吋築起來。