搞懂 AI 智能體，這 10 個概念就夠了
整理版優先睇
搞懂 AI 智能體核心概念：從 MCP 到運行時編排，10 個系統設計要點
呢篇文章係作者基於自己開發 AI 智能體嘅經驗，佢試過智能體無限循環燒咗 47 美元 API 費用，所以決定梳理出 10 個必須掌握嘅系統概念。作者認為，要將智能體由 Demo 變成生產系統，關鍵唔係揀 LLM 或者寫提示詞，而係理解底層系統架構，令智能體喺冇人監管下可靠完成工作。
整體嚟講，呢 10 個概念涵蓋咗工具集成（MCP）、推理循環、記憶、護欄、工具發現、錯誤恢復、人類參與、上下文工程、狀態管理同運行時編排。每個概念都解決緊一個常見問題，例如 MCP 標準化工具接口，護欄防止錯誤執行，記憶令智能體記得用戶偏好。作者建議從 MCP 同工具發現開始，逐步加入其他概念，唔好一次過搞曬。
- 結論：智能體嘅系統架構比 LLM 選擇更重要，理解呢 10 個概念先可以避免生產環境常見問題。
- 方法：MCP 協議類似 USB 接口，將工具集成標準化，無需為每個服務重寫代碼。
- 差異：演示用嘅智能體同生產系統嘅最大分別在於錯誤恢復、狀態管理同護欄——Demo 唔會考慮呢啲邊緣情況。
- 啟發：護欄同人類參與係防止災難嘅關鍵，應該對高風險決策加入人工審批，低風險行動自動執行。
- 可行動點：由 MCP 同工具發現開始構建基礎，逐步加入記憶、護欄、錯誤恢復等功能，唔好一次過搞曬。
基礎架構：工具集成與自動發現
MCP（模型上下文協議）係智能體嘅「USB 接口」，將唔同工具嘅集成標準化。你只需要搭建 MCP 服務器，每個服務器暴露工具同清晰描述，智能體就可以自動發現並使用，唔使為 Gmail、Notion 呢啲服務各自寫一套集成代碼。
MCP 協議可以令智能體喺運行時自動學習新功能，而唔需要修改智能體代碼
工具發現就係呢個概念嘅延伸：當你新加一個日曆 MCP 服務器，智能體會自動讀取「create_event」呢類功能描述，下次用戶要求「安排團隊會議」佢就識得用。
智能體行為：推理、記憶與上下文
推理循環係智能體解決問題嘅核心機制：思考要做咩、執行行動、觀察結果、再思考下一步，重複直到任務完成。呢個循環令智能體可以喺第一種方法失敗時自行調整，唔會直接崩潰。
推理循環令智能體能夠根據觀察結果動態調整下一步
記憶分短期同長期：短期保留當前對話，令智能體可以參考「頭先提到嘅文檔」；長期跨會話儲存用戶偏好，例如「更喜歡上午 10 點前嘅會議」，令智能體感覺真係識得你。
短期記憶用於保持對話連貫，長期記憶用於記錄用戶偏好
上下文工程係決策前收集相關資訊，包括對話歷史、記憶、系統狀態、時間天氣等。提供完整上下文，智能體先會做出合理判斷；冇上下文，就只能亂估。
上下文工程確保智能體擁有做出正確決策所需嘅全部資訊
可靠性與安全性：護欄、錯誤恢復、人類參與
護欄係行動前嘅驗證檢查，例如確認用戶權限、參數合理性、輸出敏感數據。佢哋似安全網，喺錯誤造成損害之前攔住。
護欄可以避免智能體誤刪 50,000 條記錄，因為佢會標記可疑操作並要求確認
錯誤恢復分類處理錯誤：網絡超時就重試（等 2 秒、4 秒、8 秒），缺少資訊就問用戶，認證失敗就記低日誌。優雅失敗令用戶感覺唔到問題，或者得到清晰溝通。
錯誤恢復令智能體喺 API 超時時自動重試，用戶甚至唔知出過事
人類參與唔係微觀管理，而係識別高風險決策（例如回覆客戶投訴）並請求人工審批，低風險行動則自動執行。咁樣可以保持控制，又唔使成日睇實。
人類參與將高風險決策路由到人工審批，低風險行動自動化
運行管理：狀態管理與運行時編排
狀態管理追蹤多步驟任務嘅進度：計劃中、進行中、等待輸入、已完成等。冇佢，智能體處理唔到複雜項目，因為會失去目標重新開始。
狀態管理將「研究競爭對手」呢類任務拆分為子任務並追蹤每個嘅狀態
運行時編排係基礎設施層，管理智能體點樣監聽多個輸入來源（Slack、定時任務、webhook），處理優雅關閉同資源限制。佢確保智能體可以響應事件、喺重啟後恢復、並防止失控。
運行時編排強制執行資源限制，例如每個任務最多 5 分鐘或 50 次 API 調用
優雅關閉保存進行中任務嘅狀態，新版本啟動後從斷點繼續
由 MCP 插件系統到運行時編排，呢篇文章用可視化方式解釋咗構建生產級 AI 智能體一定要掌握嘅 10 個核心概念，幫你將 AI Demo 變成真正可靠嘅生產系統。原文：10 AI Agent Concepts Every Developer Must Master in 2026 ( With Visual Explanation)[1]
你肯定遇過咁嘅情況：開一個新嘅 AI 智能體項目，測試嗰陣一切正常，然後用戶叫佢「睇我嘅日曆，預訂下個禮拜去奧斯汀最平嘅機票」，結果佢直接……死咗？仲衰嘅，佢因為讀錯工具輸出，訂咗一張去澳洲嘅機票？
我經歷過。三個月前，睇住個智能體無限循環，不停嘗試抓取一個要登入嘅頁面。佢喺我發現並終止之前，已經燒咗 47 美金嘅 API 調用費用。
AI 智能體唔止係揀啱嘅 LLM 或者寫聰明嘅提示詞，核心在於理解基礎系統架構，令到智能體喺冇人監督嘅情況下完成實際工作並保持可靠。
可以令團隊眼前一亮嘅演示，同每個禮拜慳 10 個鐘嘅生產級智能體，分別就係呢 10 個概念。
呢篇文章會分享嗰啲喺整第一個智能體之前要知道嘅真相，呢啲就係構建 AI 系統時真正重要嘅嘢。
1. MCP：通用插件系統
你想個智能體讀取 Gmail、更新 Notion 同查詢數據庫。一般情況下，要為每個服務寫自定義集成代碼：解析 Gmail API、梳理 Notion 認證、寫 SQL 連接邏輯，三個獨立系統就要維護三個唔同嘅代碼庫。
MCP（模型上下文協議）通過創建一種標準令智能體同任意工具互動，解決咗呢個問題。佢就好似 AI 領域嘅 USB 接口。你唔使為手機上嘅每個 app 配備唔同嘅接口。呢度嘅概念係一樣嘅。
搭建 MCP 服務器，每個服務器暴露工具，並清晰描述佢哋嘅功能同所需輸入。
智能體連接到呢啲服務器，自動發現可用工具。想加 Stripe 支付？只要啟動 Stripe 嘅 MCP 服務器，智能體即刻就知道點樣向客戶收費，完全唔使改任何智能體代碼。
示例： 運行一個暴露「send_email」函數嘅 MCP 服務器，服務器描述為「向指定地址發送帶主題同正文嘅電子郵件」，智能體可以喺工具列表中見到。當用戶話「將報告 send 去 john@company.com」時，智能體用正確嘅參數調用該函數。下次你加一個「search_github」服務器，智能體亦會發現並開始使用，而唔使改代碼。
2. 推理循環（The Reasoning Loop）：思考、行動、觀察，重複
大部分開發者將 LLM 當作簡單函數：問問題，得到答案，結束。但真實嘅任務唔係一次過完成嘅，要根據發生嘅情況嚟調整。
推理循環就係智能體解決問題嘅實際方式。
智能體諗嚇要做咩，執行嗰個行動，觀察發生咗咩事，然後再諗嚇個方法有冇效，下一步要試咩。呢個循環重複直到任務完成。
示例： 叫智能體揾競爭對手嘅定價。佢諗：「我去佢哋網站睇嚇」，去個網站，得到 404 錯誤。佢觀察到：「網頁唔存在」。再諗：「咁我試嚇主頁啦」，揾到主頁，定位到定價連結，跟進並提取數據。每一步都建基於前一個結果。智能體喺第一種方法失敗時識得調整，而唔係直接死機。
3. 記憶（Memory）：短期同長期上下文
你嘅智能體同用戶傾咗一次計。三個鐘之後，用戶話「send 我哋頭先講嘅嗰封 email」，智能體完全唔知邊封 email，因為對話歷史已經冇咗。
短期記憶將當前對話保留喺上下文中。當你話「我頭先講嘅嗰份文件」時，智能體可以回顧對話歷史，揾到你講緊邊份文件。 長期記憶跨會話儲存事實，包括用戶偏好、過去決策、學到嘅資訊。呢個會令智能體感覺佢真係識得你，而唔係每次都由頭開始。
示例： 用戶話「我更鍾意晏晝 10 點前嘅會議」。你將佢儲存喺綁定用戶 ID 嘅長期記憶度。下個禮拜，用戶話「安排一個同 Sarah 嘅會議」。智能體檢查記憶，見到偏好上午，所以建議上午 9 點時段。冇記憶嘅話，佢會亂推薦時間，用戶每次都要重複講一次偏好。
4. 護欄（Guardrails）：行動前驗證
智能體想刪除文件，LLM 確信呢個係用戶要求嘅。但如果佢錯咗呢？如果要刪除嘅係生產數據而唔係測試文件呢？
護欄係喺任何行動執行前運行嘅驗證檢查。佢哋驗證權限、檢查參數係咪合理，並掃描輸出中嘅敏感數據。將佢哋諗成係喺錯誤造成損害之前捉住錯誤嘅安全網。
示例： 用戶話「清理舊嘅測試數據」。你嘅智能體將佢解釋為刪除 50,000 條數據庫紀錄。執行前，護欄檢查：呢個用戶有刪除權限嗎？對於「舊測試數據」嚟講，50,000 條紀錄合理嗎？護欄將佢標記為可疑並要求用戶確認。結果用戶本意係刪除 50 條紀錄，唔係 50,000 條，從而避免咗一場災難。
5. 工具發現（Tool Discovery）：自動學習新能力
你可以將工具列表硬編碼入智能體度，但如果下個月你想加 Jira 集成，就要更新智能體代碼、重新部署並再次測試曬所有嘢。呢個好脆弱，亦冇辦法擴展。
工具發現係指智能體喺運行時就可以搞清楚佢能夠做啲咩。工具通過清晰嘅文件描述自身，智能體讀取呢啲描述，加新工具後自動學習點樣用。
示例： 你嘅智能體已經喺生產環境運行。你通過部署 MCP 服務器加咗新嘅日曆集成，呢個服務器暴露「create_event」同「list_events」函數並附帶描述。下次有人要求「安排團隊會議」，智能體就可以喺可用列表中見到日曆工具，讀取佢哋嘅功能並正確使用。唔使改智能體代碼，佢自己能夠發現新能力。
6. 錯誤恢復（Error Recovery）：優雅失敗
API 會超時，服務會死機，用戶會俾唔清晰嘅指令。智能體一定會遇到錯誤，問題係佢會死機定係智能處理。
錯誤恢復在於對問題分類並做出適當回應：網絡超時時嘗試重試，缺少資訊時向用戶提問，認證失敗時記錄清晰日誌。
示例： 智能體嘗試發送 email，SMTP 服務器超時。佢冇死機，而係等 2 秒後重試。仲係失敗，再等 4 秒重試，第三次成功咗。用戶根本唔知有問題。另一種情況：超時一直發生。三次嘗試後，智能體同用戶講：「郵件服務而家死咗。我已經保存咗你嘅草稿，10 分鐘後重試。」清晰溝通發生咗咩事，同埋正在採取咩措施。
7. 人類參與（Human in the Loop）：知道幾時要問
完全自主聽落唔錯，直到智能體喺公司 Twitter 賬號出咗尷尬內容。有啲決策喺執行前需要人類判斷。
人類參與唔係微觀管理每個動作，而係識別高風險決策並交俾人工審批，同時讓低風險行動自動執行。
示例： 你嘅社交媒體智能體自動起草並出 post，日常更新做得好順。但當佢起草對客戶產品缺陷投訴嘅回覆時，會暫停並發通知：「我起草咗呢篇回覆，應該出嗎？」你審核後做咗小修改並批准出，智能體就出咗。高風險行動得到審核，低風險行動自動完成，唔需要一直睇實就可以保持控制。
8. 上下文工程（Context Engineering）：提供正確資訊
你擁有最聰明嘅 LLM 同完美嘅工具，但智能體卻做咗奇怪嘅決策。點解？因為佢冇正確嘅資訊可用。
上下文工程就係為每個決策收集相關資訊。唔止係對話歷史，仲包括來自記憶嘅用戶偏好、當前系統狀態，以及時間日期等環境事實。
示例： 用戶問「我應該重新安排聽日嘅户外會議嗎？」壞上下文：只有問題本身。好上下文：問題、聽日天氣預報（70% 落雨概率）、用戶日曆顯示嘅户外團建活動、用戶過去避免雨天延誤嘅偏好，以及可用嘅室內備用會議室。有咗完整上下文，智能體建議搬到 B 會議廳並俾出可靠推理。冇上下文，智能體只能靠估。
9. 狀態管理（State Management）：跟蹤複雜任務
用戶唔會只問簡單問題，而係會執行耗時幾個鐘甚至幾日嘅多步驟項目，而智能體需要跟蹤目前處於流程嘅邊個位置。
狀態管理用嚟跟蹤計劃咗啲咩、咩正在進行中、咩等緊輸入、咩已經完成。冇咗佢，智能體冇辦法處理任何比單次查詢更複雜嘅任務。
示例： 用戶話「研究我哋嘅前 5 名競爭對手並創建對比表格」。智能體將佢拆分做子任務：第一步：識別競爭對手（進行中），第二步：研究每個競爭對手（計劃中，等第一步完成），第三步：創建表格（計劃中，等第二步完成）。智能體逐步處理，跟蹤每個任務嘅狀態。如果需要用戶輸入（「邊啲指標最重要？」），佢會將該子任務標記為等待，問問題，然後繼續處理其他嘢。當你答咗之後，佢會由中斷嘅地方繼續。冇狀態跟蹤，智能體會失去目標並重新開始。
10. 運行時編排（Runtime Orchestration）：管理執行環境
智能體唔止係運行一次嘅腳本，而係一個需要回應事件、處理多個任務、喺重開後恢復，並喺資源限制內運行嘅系統。
運行時編排係基礎設施層，負責管理智能體點樣監聽唔同來源嘅輸入、處理優雅關閉、提供對當前行為嘅可見性，以及強制執行限制防止失控。
示例： 你嘅智能體監聽三個輸入來源：Slack 消息、定時任務同 webhook 回調。事件隊列將每個請求路由到正確嘅處理程序。用戶傳送緊急 Slack 消息，即刻得到回應。定時報告喺背景運行。當你部署新版本時，關閉處理程序保存所有進行中任務嘅狀態。新版本啟動，加載呢啲狀態並由斷點繼續。同時，資源限制確保任何單個任務運行唔超過 5 分鐘或發起超過 50 次 API 調用。分佈式追蹤能夠喺出問題時準確顯示發生咗咩事。
幾時用每個概念：決策指南
由零開始？ 由 MCP 同工具發現開始。構建基礎，令加新能力變得容易。唔好硬編碼集成，之後會後悔。
測試正常，生產失敗？ 加護欄同錯誤恢復。執行前驗證，瞬態故障重試。生產環境包含所有測試遺漏嘅邊緣情況。
智能體忘記嘢或者睇落好蠢？ 實現記憶。短期記憶用於對話，長期記憶用於持久事實。上下文工程確保你喺決策時提供正確資訊。
任務卡住或者耗時太長？ 檢查推理循環同狀態管理。將複雜請求拆分做可跟蹤嘅子任務。等智能體喺計劃唔及變化時能夠適應。
擔心安全性？ 加倍關注護欄同人類參與。由保守開始，當你對智能體處理能力建立信任後先擴大自主權。
提示詞冇問題但決策錯誤？ 修復上下文工程。確保智能體見到相關嘅用戶偏好、系統狀態同環境事實。記錄提供嘅上下文，方便除錯。
部署同監控問題？ 專注運行時編排。事件處理、優雅關閉、可觀測性、資源限制。你冇辦法修復睇唔到嘅問題。
需要快速集成大量服務？ 使用 MCP 服務器。一個協議支援無限工具。唔使再為每個新服務重寫集成代碼。
API credits 燒得太快？ 加資源限制。限制每個任務嘅執行時間同 API 調用次數。快啲失敗，而唔係倒曬個預算。
用戶唔信任？ 將高風險決策嘅人工審批同其他所有情況嘅可靠錯誤恢復結合。透明度建立信任。展示智能體做緊咩，點解咁做。
參考表：實現檢查清單
MCP 設置： 安裝 SDK。創建定義工具為函數嘅服務器文件。為每個工具寫清晰描述，解釋功能同使用時機。包含參數類型。將智能體連接到服務器。測試工具能夠被自動發現。
推理循環： 構建一個運行直到任務完成嘅 while 循環。LLM 決定下一步行動。執行該行動。將結果回饋俾 LLM。等佢觀察並決定下一步。重複。記錄每次迭代方便除錯。
記憶系統： 創建對話歷史（短期）數據庫表。另一個表存放用戶偏好同學到嘅事實（長期）。組裝上下文時查詢記憶。加嵌入語義搜索提高召回率。定期清理舊對話。
護欄： 喺每個行動前運行驗證函數。檢查用戶權限。驗證參數合理。掃描輸出中嘅敏感數據。如果檢查失敗，阻止並記錄。返回清晰錯誤解釋原因。
工具發現： 註冊表喺運行時列出所有可用工具。每個工具都有名稱、描述同參數模式。喺系統提示中將註冊表傳遞俾智能體。加新工具後自動出現。智能體唔使改代碼就能學會使用。
錯誤恢復： 將工具調用包裝喺錯誤處理中。分類做瞬態錯誤、用戶可修復錯誤或致命錯誤。延遲重試瞬態錯誤（2s、4s、8s）。向用戶詢問缺失資訊。清晰記錄並解釋致命錯誤。主方法失敗時有後備選項。
人工批准： 按置信度同風險對決策打分。高風險或低置信度需要批准。低風險自動進行。異步實現等智能體喺等待時可以處理其他任務。記錄所有批准。根據模式調整閾值。
上下文組裝： 喺每個決策前收集資訊嘅函數。最近對話消息。來自記憶嘅相關用戶偏好。當前時間同時區。可用工具。相關過去互動嘅語義搜索。按相關性過濾。記錄組裝好嘅上下文。
狀態跟蹤： 定義任務狀態（計劃中、進行中、等待、阻塞、已完成、失敗）。將當前狀態儲存喺數據庫中。分別跟蹤子任務。積累結果時保存。狀態變化時更新數據庫。重開時加載以恢復任務。
運行時基礎設施： 事件隊列監聽多個來源。路由到同步或異步處理程序。終止時關閉處理程序保存狀態。分佈式追蹤跟蹤決策同工具調用。對每個任務嘅時間同 API 調用進行資源限制。監控錯誤率同持續時間。異常時告警。
總結
揀一個概念，今日就嚟整啲細微嘢。
如果厭倦咗重寫集成，由 MCP 開始。如果智能體成日唔記得上下文，加記憶。如果擔心可能出問題，實現護欄。
唔好試嚇一次過整曬所有嘢。掌握一個，發佈，然後繼續下一個。
10 AI Agent Concepts Every Developer Must Master in 2026 ( With Visual Explanation): https://pub.towardsai.net/10-ai-agent-concepts-every-developer-must-master-in-2026-with-visual-explanation-219241637c04
從 MCP 插件系統到運行時編排，本文用可視化方式講解了構建生產級 AI 智能體必須掌握的 10 個核心概念，幫你把 AI Demo 變成真正可靠的生產系統。原文：10 AI Agent Concepts Every Developer Must Master in 2026 ( With Visual Explanation))[1]
你肯定遇到過這種情況：新建一個 AI 智能體項目，測試時一切正常，然後用戶讓它"查看我的日曆，預訂下週去奧斯汀最便宜的航班"，結果它直接……僵住了？更糟的是，它因為誤讀工具輸出，訂了一張去澳大利亞的機票？
我經歷過。三個月前，看着智能體無限循環，一直嘗試抓取一個需要登錄的頁面。它在我發現並終止前，已經燒了 47 美元的 API 調用費用。
AI 智能體不只是選擇合適的 LLM 或編寫巧妙的提示詞，核心在於理解基礎系統架構，讓智能體在無人監督的情況下完成實際工作並保持可靠。
能驚豔團隊的演示，和每週節省 10 小時的生產級智能體，差別就在於這 10 個概念。
本文將分享那些在構建第一個智能體之前需要知道的真相，這些都是構建 AI 系統時真正重要的東西。
1. MCP：通用插件系統
你希望智能體讀取 Gmail、更新 Notion 並查詢數據庫。通常情況下，需要為每個服務編寫自定義集成代碼：解析 Gmail API、梳理 Notion 認證、編寫 SQL 連接邏輯，三個獨立系統就需要維護三個不同的代碼庫。
MCP（模型上下文協議）通過創建一種標準讓智能體與任意工具交互，解決了這個問題。它就像 AI 領域的 USB 接口。你不需要為手機上的每個應用配備不同的接口。這裏的理念是一樣的。
搭建 MCP 服務器，每個服務器暴露工具，並清晰描述它們的功能和所需輸入。
智能體連接到這些服務器，自動發現可用工具。想添加 Stripe 支付？只需啓動 Stripe 的 MCP 服務器，智能體立即就能知道如何向客戶收費，而無需修改任何智能體代碼。
示例： 運行一個暴露"send_email"函數的 MCP 服務器，服務器描述為"向指定地址發送帶主題和正文的電子郵件"，智能體可以在工具列表中看到。當用戶說"把報告發給 john@company.com"時，智能體使用正確的參數調用該函數。下次你添加一個"search_github"服務器，智能體也能發現並開始使用，而無需修改代碼。
2. 推理循環（The Reasoning Loop）：思考、行動、觀察，重複
大多數開發者把 LLM 當作簡單函數：問問題，獲得答案，結束。但真實的任務不是一次性完成的，需要根據發生的情況進行調整。
推理循環是智能體解決問題的實際方式。
智能體思考該做什麼，執行該行動，觀察發生了什麼，然後再次思考該方法是否有效，下一步該嘗試什麼。這個循環重複直到任務完成。
示例： 讓智能體查找競爭對手的定價。它想："我去他們網站看看"，訪問網站，得到 404 錯誤。它觀察到："頁面不存在"。再次思考："那我試試主頁"，找到主頁，定位到定價連結，跟進並提取數據。每一步都建立在前一個結果的基礎上。智能體在第一種方法失敗時進行了調整，而不是直接崩潰。
3. 記憶（Memory）：短期和長期上下文
你的智能體和用戶進行了一次對話。三小時後，用戶說"發送我們剛才談到的那封郵件"，智能體完全不知道說的是哪封郵件，因為對話歷史已經丟失了。
短期記憶將當前對話保留在上下文中。當你說"我剛才提到的那份文檔"時，智能體可以回顧對話歷史，找到你指的是哪份文檔。 長期記憶跨會話存儲事實，包括用戶偏好、過去決策、學到的信息。這會讓智能體感覺它真的認識你，而不是每次都從頭開始。
示例： 用戶說"我更喜歡上午 10 點前的會議"。你將其存儲在綁定用戶 ID 的長期記憶中。下週，用戶說"安排一個和 Sarah 的會議"。智能體檢查記憶，看到偏好上午，因此建議上午 9 點時段。沒有記憶的話，它會隨機推薦時間，用戶每次都得重複說一遍偏好。
4. 護欄（Guardrails）：行動前驗證
智能體想要刪除文件，LLM 確信這是用戶要求的。但如果它錯了怎麼辦？如果它要刪除的是生產數據而不是測試文件怎麼辦？
護欄是在任何行動執行前運行的驗證檢查。它們驗證權限、檢查參數是否合理，並掃描輸出中的敏感數據。把它們看作在錯誤造成損害之前捕捉錯誤的安全網。
示例： 用戶說"清理舊的測試數據"。你的智能體將其解釋為刪除 50,000 條數據庫記錄。執行前，護欄檢查：這個用戶刪除權限嗎？對於"舊測試數據"來說，50,000 條記錄合理嗎？護欄將其標記為可疑並要求用戶確認。結果用戶本意是刪除 50 條記錄，不是 50,000 條，從而避免了一場災難。
5. 工具發現（Tool Discovery）：自動學習新能力
你可以把工具列表硬編碼到智能體中，但如果下個月你想添加 Jira 集成，就需要更新智能體代碼、重新部署並再次測試所有內容。這很脆弱，也無法擴展。
工具發現意味着智能體在運行時就能弄清楚它能做什麼。工具通過清晰的文檔描述自身，智能體讀取這些描述，添加新工具後自動學習如何使用。
示例： 你的智能體已經在生產環境運行。你通過部署 MCP 服務器添加了新的日曆集成，該服務器暴露"create_event"和"list_events"函數並附帶描述。下次有人要求"安排團隊會議"，智能體就可以在可用列表中看到日曆工具，讀取它們的功能並正確使用。不需要修改智能體代碼，它自己能夠發現新能力。
6. 錯誤恢復（Error Recovery）：優雅失敗
API 會超時，服務會宕機，用戶會給出不清晰的指令。智能體一定會遇到錯誤，問題在於它會崩潰還是智能處理。
錯誤恢復在於對問題分類並做出適當響應：網絡超時時嘗試重試，缺少信息時向用戶提問，認證失敗時記錄清晰日誌。
示例： 智能嘗試發送電子郵件，SMTP 服務器超時。它沒有崩潰，而是等待 2 秒後重試。還是失敗，再等 4 秒重試，第三次成功了。用戶根本不知道出了問題。另一種情況：超時一直髮生。三次嘗試後，智能體告訴用戶："郵件服務現在宕機了。我已經保存了你的草稿，10 分鐘後重試。"清晰溝通發生了什麼，以及正在採取什麼措施。
7. 人類參與（Human in the Loop）：知道何時該提問
完全自主聽起來不錯，直到智能體在公司 Twitter 賬號發佈了尷尬內容。有些決策在執行前需要人類判斷。
人類參與不是對每個動作微觀管理，而在於識別高風險決策並路由給人工批准，同時讓低風險行動自動執行。
示例： 你的社交媒體智能體自動起草併發布帖子，日常更新運行得很好。但當它起草對客戶產品缺陷投訴的回覆時，會暫停併發送通知："我起草了這篇回覆，應該發佈嗎？"你審核後做了小修改並批准發佈，智能體進行了發佈。高風險行動得到審核，低風險行動自動完成，不需要一直盯着就能保持控制。
8. 上下文工程（Context Engineering）：提供正確信息
你擁有最聰明的 LLM 和完美的工具，但智能體卻做出了奇怪的決策。為什麼？因為它沒有正確的信息可用。
上下文工程就是為每個決策收集相關信息。不只是對話歷史，還包括來自記憶的用戶偏好、當前系統狀態，以及時間日期等環境事實。
示例： 用戶問"我應該重新安排明天的户外會議嗎？"壞上下文：只有問題本身。好上下文：問題、明天天氣預報（70% 降雨概率）、用戶日曆顯示的户外團建活動、用戶過去避免雨天延誤的偏好，以及可用的室內備用會議室。有了完整上下文，智能體建議搬到 B 會議廳並給出可靠推理。沒有上下文，智能體只能瞎猜。
9. 狀態管理（State Management）：跟蹤複雜任務
用戶不會只問簡單問題，而是會執行耗時數小時甚至數天的多步驟項目，而智能體需要跟蹤當前處於流程的哪個位置。
狀態管理用於跟蹤計劃了什麼、什麼在進行中、什麼在等待輸入、什麼已經完成的方式。沒有它，智能體無法處理任何比單次查詢更復雜的任務。
示例： 用戶說"研究我們的前 5 名競爭對手並創建對比表格"。智能體將其拆分為子任務：第一步：識別競爭對手（進行中），第二步：研究每個競爭對手（計劃中，等待第一步完成），第三步：創建表格（計劃中，等待第二步完成）。智能體逐步處理，跟蹤每個任務的狀態。如果需要用戶輸入（"哪些指標最重要？"），它會將該子任務標記為等待，提問，然後繼續處理其他事情。當你回答後，它會從打斷的地方繼續。沒有狀態跟蹤，智能體會失去目標並重新開始。
10. 運行時編排（Runtime Orchestration）：管理執行環境
智能體不只是運行一次的腳本，而是一個需要響應事件、處理多個任務、在重啓後恢復，並在資源限制內運行的系統。
運行時編排是基礎設施層，負責管理智能體如何監聽不同來源的輸入、處理優雅關閉、提供對當前行為的可見性，以及強制執行限制防止失控。
示例： 你的智能體監聽三個輸入來源：Slack 消息、定時任務和 webhook 回調。事件隊列將每個請求路由到正確的處理程序。用戶發送緊急 Slack 消息，立即得到響應。定時報告在後台運行。當你部署新版本時，關閉處理程序保存所有進行中任務的狀態。新版本啓動，加載這些狀態並從斷點繼續。同時，資源限制確保任何單個任務運行不超過 5 分鐘或發起超過 50 次 API 調用。分佈式追蹤能在出問題時準確顯示發生了什麼。
何時使用每個概念：決策指南
從零開始？ 從 MCP 和工具發現開始。構建基礎，讓添加新能力變得容易。不要硬編碼集成，後面會後悔的。
測試正常，生產失敗？ 添加護欄和錯誤恢復。執行前驗證，瞬態故障重試。生產環境包含所有測試遺漏的邊緣情況。
智能體忘記事情或看起來很笨？ 實現記憶。短期記憶用於對話，長期記憶用於持久事實。上下文工程確保你在決策時提供正確信息。
任務卡住或耗時太長？ 檢查推理循環和狀態管理。將複雜請求拆分為可跟蹤的子任務。讓智能體在計劃不如變化時能夠適應。
擔心安全性？ 加倍關注護欄和人類參與。從保守開始，當你對智能體處理能力建立信任後再擴大自主權。
提示詞沒問題但決策錯誤？ 修復上下文工程。確保智能體看到相關的用戶偏好、系統狀態和環境事實。記錄提供的上下文，方便調試。
部署和監控問題？ 專注運行時編排。事件處理、優雅關閉、可觀測性、資源限制。你無法修復看不到的問題。
需要快速集成大量服務？ 使用 MCP 服務器。一個協議支持無限工具。不用再為每個新服務重寫集成代碼。
API credits 燒得太快？ 添加資源限制。限制每個任務的執行時間和 API 調用次數。快速失敗，而不是掏空預算。
用戶不信任？ 將高風險決策的人工審批和其他所有情況的可靠錯誤恢復相結合。透明度建立信任。展示智能體在做什麼，為什麼這麼做。
參考表：實現檢查清單
MCP 設置： 安裝 SDK。創建定義工具為函數的服務器文件。為每個工具編寫清晰描述，解釋功能和使用時機。包含參數類型。將智能體連接到服務器。測試工具能被自動發現。
推理循環： 構建一個運行直到任務完成的 while 循環。LLM 決定下一步行動。執行該行動。將結果反饋給 LLM。讓它觀察並決定下一步。重複。記錄每次迭代方便調試。
記憶系統： 創建對話歷史（短期）數據庫表。另一個表存放用戶偏好和學到的事實（長期）。組裝上下文時查詢記憶。添加嵌入語義搜索提高召回率。定期清理舊對話。
護欄： 在每個行動前運行驗證函數。檢查用戶權限。驗證參數合理。掃描輸出中的敏感數據。如果檢查失敗，阻止並記錄。返回清晰錯誤解釋原因。
工具發現： 註冊表在運行時列出所有可用工具。每個工具都有名稱、描述和參數模式。在系統提示中將註冊表傳遞給智能體。添加新工具後自動出現。智能體無需修改代碼就能學會使用。
錯誤恢復： 將工具調用包裝在錯誤處理中。分類為瞬態錯誤、用戶可修復錯誤或致命錯誤。延遲重試瞬態錯誤（2s、4s、8s）。向用戶詢問缺失信息。清晰記錄並解釋致命錯誤。主方法失敗時有後備選項。
人工批准： 按置信度和風險對決策打分。高風險或低置信度需要批准。低風險自動進行。異步實現讓智能體在等待時可以處理其他任務。記錄所有批准。根據模式調整閾值。
上下文組裝： 在每個決策前收集信息的函數。最近對話消息。來自記憶的相關用戶偏好。當前時間和時區。可用工具。相關過去交互的語義搜索。按相關性過濾。記錄組裝好的上下文。
狀態跟蹤： 定義任務狀態（計劃中、進行中、等待、阻塞、已完成、失敗）。將當前狀態存儲在數據庫中。分別跟蹤子任務。積累結果時保存。狀態變化時更新數據庫。重啓時加載以恢復任務。
運行時基礎設施： 事件隊列監聽多個來源。路由到同步或異步處理程序。終止時關閉處理程序保存狀態。分佈式追蹤跟蹤決策和工具調用。對每個任務的時間和 API 調用進行資源限制。監控錯誤率和持續時間。異常時告警。
總結
選一個概念，今天就來構建點小東西。
如果厭倦了重寫集成，從 MCP 開始。如果智能體總是忘記上下文，添加記憶。如果擔心可能出問題，實現護欄。
不要試圖一下子構建所有東西。掌握一個，發佈，然後繼續下一個。
10 AI Agent Concepts Every Developer Must Master in 2026 ( With Visual Explanation)): https://pub.towardsai.net/10-ai-agent-concepts-every-developer-must-master-in-2026-with-visual-explanation-219241637c04