# 一個下午就能做出 Agent 演示，為什麼一上線就死？16 年架構師說：演示根本不是產品 這是 Mahmoud Zalt 在 2026 年 10 月 2… · @swordBluesy · TwKit

@swordBluesy

# 一個下午就能做出 Agent 演示，為什麼一上線就死？16 年架構師說：演示根本不是產品 這是 Mahmoud Zalt 在 2026 年 10 月 21 日發的實作文章，標題直譯是《AI Agent 是怎麼做出來的：一步一步的流程》（14 天放寬內，發文日期已註明）。先把結論放在前面，因為它反常識： **Agent 演示人人一個下午就能做出來，但能活過真實流量的 Agent，難的根本不是模型和程式碼，而是前面被跳過的那些步驟——定範圍、做評測、加護欄、留觀測。跳過任何一步，專案不是變快，是在後面等著 stall（卡住）。** 先說清詞。**Agent（代理）**，不是一問一答的聊天機器人，而是一個會循環「觀察、決策、行動」的程式：模型看現狀、定下一步、調工具幹活、看結果、再循環，直到任務完成或撞到停止規則。**編排（orchestration）**，是決定這個循環什麼時候跑、什麼時候分支、什麼時候交給別的 Agent、什麼時候停下來問人的那層控制邏輯。**護欄（guardrail）**，是限制 Agent 能幹什麼、不能幹什麼的硬約束。**評測（eval）**，是一套固定測試題，用來判斷改動是變好還是變壞。**可觀測性（observability）**，是把每一步、每次工具呼叫、每個決策都記下來，出事時能重建現場。 一個真實例子：作者 16 年做生產軟體的經驗裡，最常見的劇本是——一個能幹的模型加兩三個工具，一個下午就演示得很驚豔；可一上真實流量，範圍不斷膨脹、工具沒有權限邊界、改動全憑感覺、出了問題沒人說得清為什麼，專案就卡在那裡。 他們還點名了一種「眼熟的路線」：先做一個厲害的演示，再想著以後補測試、補護欄、補日誌。作者的拆台很直接：**演示證明的只是「有一次跑通了」，產品要證明的是「沒人盯著的時候也一直跑得通」**。 先把話說全：不是每個專案都要全套重型流程。滿足下面任何一條，輕量起步就夠： - 只在內部試用，不碰客戶和錢； - 工具全是唯讀查詢，改不了任何資料； - 隨時可以關掉，出錯也沒有真實損失。 ## 一、Agent 專案四種翻車方式 - **範圍膨脹**：一開始說好只做一件事，做著做著變成十件事，最後沒有一件事是可靠的。 - **工具沒有權限邊界**：模型一次判斷失誤，就能造成真實損害——刪資料、發錯信、花掉預算。 - **沒有評測集**：每次改提示詞、換模型，都不知道是變好還是變壞，全憑感覺。 - **沒有可觀測性**：Agent 在客戶面前出錯，團隊沒人能解釋它當時為什麼這麼幹。 ## 二、替代方案：八個階段按順序做 作者的流程是線性的，因為每一步都假設上一步已經站穩： 1. **定範圍**：只定一個工作，寫清輸入是什麼、什麼叫完成、什麼絕對不許幹。一個只做一件事、做得穩的 Agent，勝過做十件事、件件不可靠的 Agent。 2. **選模型後端**：按任務、延遲預算、每次呼叫成本、資料存放要求來選，這是可以測試的決定，不是品牌偏好。 3. **給工具**：把能幹的動作寫成函式讓模型呼叫——查資料庫、發郵件、調內部介面。整合外部系統時，MCP（給 Agent 接外部工具和資料的統一協議）伺服器就是接線的地方。 4. **加記憶與檢索**：短期記憶負責一輪任務內的上下文；檢索（RAG，用檢索到的文件現查現答的做法）負責在需要時拉進正確文件，別讓模型憑過期的訓練記憶瞎猜。 5. **編排**：決定什麼時候循環、什麼時候分支、什麼時候交給另一個 Agent、什麼時候停下來問人。編排是腳本和系統的分界線。 6. **加護欄與評測**：驗證輸入輸出、約束工具能力、用固定測試題打分，確保每次改動都有分數可對。 7. **做可觀測與治理**：每一步、每次工具呼叫、每個決策都帶追蹤編號記下來。看不見的東西，修不了。 8. **交接**：寫文件、交程式碼、交運維手冊，讓接手的團隊不用作者在場也能運作。 ## 三、目標形態：模型只是系統裡的一個零件 作者對目標形態的定性很硬：**把模型當成大系統裡的一個組件，而不是整個系統**。範圍收得緊、工具和檢索接得有意識、評測和觀測投得早——這三件，才是演示和產品的分界線。 ## 四、遷移三步走：從演示走到生產 ### 第一步：先鎖範圍和架構 動手寫程式之前，先用一個短的發現階段把範圍和架構定死：輸入、完成標準、禁區清單。這一步花幾天，能省下後面幾週的返工。 ### 第二步：按生產標準補評測和護欄 評測集不用大，固定題目、覆蓋髒案例（模糊提問、錯誤編號、應該拒絕的請求）就行。護欄先從最危險的動作下手：花錢、刪資料、對外發送，全部要人工批准。 ### 第三步：上線前先讓別人能接手 文件、追蹤日誌、運維手冊三件齊了，才算能交接。作者原話的意思是：生產就緒的證明，是「沒人盯著也能一直跑」，不是「演示那天跑通了」。 ## 五、多個團隊怎麼共建同一個 Agent 作者把 Agent 開發拆成幾塊分工：Agent 系統、檢索、MCP 整合、模型後端、可觀測與治理、平滑交接。每一塊都要有負責人，否則評測沒人維護、護欄沒人更新，日誌沒人看——系統越跑越髒，最後還是回到「沒人說得清為什麼出錯」。 ## 六、官方工具包：這篇沒有，作者給的是驗收清單 原文不是某家廠商的工具箱，沒有列出專用工具；它給的是一張驗收清單，照著打勾就能判斷自己的 Agent 離生產還差幾步：固定評測集上的行為可預測、工具能力有護欄限制、任何決策都能追蹤、有人能接手運維。缺任何一項，都不算生產就緒。 ## 結尾：原則比架構重要 框架省的是循環和接線的力氣，不是可靠性的力氣。**原則比架構重要——範圍、評測、護欄、觀測這四件，跟你用哪個框架無關，缺了哪件，換哪個框架都一樣會死。** 可重複的動作規則是：下次做 Agent 之前，先寫一句話定範圍、列十條髒案例當評測、給危險動作加人工批准、給每次呼叫留追蹤編號——四件做完再寫主循環。 原文連結：https://zalt.me/blog/how-ai-agents-are-built 原文：Mahmoud Zalt（由 S1哥 編譯） ## S1哥觀點 這篇最狠的地方，是它不給你任何新技術，只把順序擺正：演示在前、生產在後，中間隔著的根本不是更強的模型，是你願不願意為無聊的環節付錢——評測、護欄、日誌，全是演示裡看不見、老闆不想付錢的東西。 我站這一邊：一個 Agent 敢不敢上線，不看它演示那天多驚豔，看它出錯那天你能不能在十分鐘內說清它幹了什麼。說不清的 Agent，就是一顆不知道什麼時候炸的雷，演示越好看，炸起來越難看。 所以問一句：你手上的 Agent，有固定評測集嗎？還是每次改完都憑感覺說「好像變好了」？評論區報一下，你敢不敢把評測分數貼出來。

曝光 74 · 评论 1 · 点赞 1 · 书签 0