最後更新：2026 年 10 月 22 日
資料截點：2026-10-22 12:00（台北時間）
重點先講：微軟的 Go Agent 框架 v0.2.0 已加入向量搜尋與跨對話記憶。現在 Go 開發者可以建立會檢索舊資料的 AI Agent，但記得住資料，不代表每次都能正確回答。
10 月 20 日，Microsoft Agent Framework for Go 發布 v0.2.0。這次更新最值得留意的，是官方把 Embeddings、Vector Store 和 Conversation Memory 整合進 Go Agent 的開發流程。
以前要讓 AI 客服記住顧客上星期說過的話，開發者通常需要自己接上資料庫、設計向量搜尋，再把找到的資訊放回提示詞。現在微軟提供了一組共同介面，讓這幾件事更容易組合。
但我認為，評估這次更新的重點應放在兩個問題：第一，舊資料能否正確被搜尋出來？第二，搜尋出來的資料，是否能安全而準確地提供給 Agent？
一句話結論：Microsoft Agent Framework for Go v0.2.0 適合想使用 Go 建立具備 RAG 與跨對話記憶能力的開發者；目前仍屬 Public Preview，適合先以測試專案驗證，再決定是否用於正式服務。
Microsoft Agent Framework for Go 是什麼？
Microsoft Agent Framework 是微軟推出的 AI Agent 開發框架。Go 版本讓開發者可以使用 Go 語言建立 AI Agent、定義工具、處理對話狀態，以及編排多步驟工作流程。
這裡的 Agent，是指能接收任務、呼叫模型及工具，並依照程式設定完成工作的軟體系統。
它和一般聊天機器人的差別，在於開發者可以把資料查詢、工作流程、外部工具以及操作權限納入同一套應用程式架構。
例如，一個售後服務 Agent 需要完成以下工作：
- 讀取使用者當前問題。
- 查詢商品的保固文件。
- 搜尋這位使用者過去的維修紀錄。
- 根據取得的資料產生回答。
- 必要時呼叫工單工具，交由真人處理。
其中，前三項工作都與資料和上下文有關。v0.2.0 新增的 Embeddings、Vector Store 和 Memory 功能，正是要降低這些功能的整合成本。
v0.2.0 到底更新了什麼？
根據官方 GitHub Releases，v0.2.0 發布於 2026 年 10 月 20 日 15:58 UTC，換算為台北時間是同一天 23:58。官方將此版本標記為 Pre-release。
本次更新至少有六個值得留意的技術方向。
| 功能 | 用途 | 使用時要注意什麼 |
|---|---|---|
| Embedding API | 把文字轉成可比較的向量表示 | 需要相容的 Embedding 模型 |
| Vector Store | 儲存、查詢及管理向量資料 | 資料更新與索引管理仍需設計 |
| In-memory Store | 快速建立本機原型 | 記憶體內資料不能直接視為永久保存 |
| Azure AI Search | 使用 Azure 搜尋服務進行向量及混合檢索 | 涉及雲端資源、權限與費用 |
| Azure Cosmos DB | 透過雲端資料庫保存及檢索資料 | 需要考慮分區、容量和存取控制 |
| Conversation Memory | 搜尋與目前問題相關的舊對話 | 跨對話召回需要正確設定資料範圍 |
官方也加入 Text-search Context Provider、Chat-history Memory Provider，以及可組合常見 Agent 功能的 Harness。
此外，這個版本還改善工具核准流程、模型提供者整合，以及 OpenTelemetry 相關追蹤能力。
對一般應用程式開發者而言，最直觀的變化，是可以透過較一致的資料介面完成不同的檢索工作。
AI Agent 的「記憶」實際上怎麼運作？
先釐清一個容易誤解的地方：Agent 能搜尋以前的對話，並不表示語言模型已經重新訓練。
多數 RAG 與向量記憶工作流，是透過額外的資料儲存與檢索機制提供上下文。
可以把它想成一名客服人員。客服並沒有把每位顧客的資料全部背下來，而是在接到電話時，先查詢系統中的相關紀錄。
模型扮演客服人員，向量資料庫則提供可以搜尋的紀錄。
第一步：把有用資訊存成可檢索的資料
假設使用者第一次聯絡客服時表示：
「我買的筆記型電腦是 X200，平常使用 Windows，電池最近只能撐兩小時。」
應用程式可以先整理出適合保存的資料，例如裝置型號、作業系統與問題描述。
接著使用 Embedding 模型把文字轉換成向量，並將向量與原始資料、使用者識別碼、建立時間等中繼資料一起儲存。
這個過程中的 Embedding，可以理解為一種將文字轉成數值表示的方法。語意相關的文字，有機會在向量空間中形成可供搜尋的關係。
然而，向量相似度不等於事實正確性。資料本身如果有錯，或者文字被切割得不合理，後面的檢索結果仍然可能不可靠。
第二步：收到新問題時搜尋相關紀錄
幾天後，使用者再次詢問：
「上次那台電腦的電池問題，有新的處理方式嗎？」
如果 Agent 只讀到這句話，就不一定知道「那台電腦」指的是哪個型號。
具備記憶檢索功能的應用程式，可以先把新問題轉換成搜尋查詢，再從允許讀取的舊紀錄中找出相關資料。
例如搜尋結果可能包含：
- 裝置型號：X200。
- 使用環境：Windows。
- 先前問題：電池續航約兩小時。
- 紀錄類型：使用者先前提供的資訊。
這是預期工作流程的示意，並非本篇已執行的測試結果。
真正的檢索品質還取決於 Embedding 模型、距離計算方式、搜尋門檻、資料切分、過濾條件以及紀錄是否仍然有效。
第三步：把檢索結果放回 Agent 上下文
搜尋完成後，應用程式將相關紀錄交給模型，讓它在回答時參考。
此時模型可以理解使用者提到的是 X200，而不必要求使用者重新描述所有背景。
完整的資料流可以寫成：
使用者輸入問題
↓
產生搜尋查詢／Embedding
↓
檢查使用者與 Session 權限
↓
向量資料庫搜尋相關紀錄
↓
過濾、排序及整理搜尋結果
↓
回填 Agent 上下文
↓
模型產生回答
↓
驗證與記錄結果這也說明為什麼記憶系統需要工程設計。它會影響 AI 讀到哪些資訊，但不能直接保證 AI 的答案正確。
Go 開發者怎麼開始安裝 v0.2.0？
官方 Release 明確指出，此版本需要 Go 1.26 或更新版本。
如果已經有 Go 開發環境，可以先在終端機檢查版本：
go version確認版本符合要求後，建立一個獨立的測試專案：
mkdir agent-memory-lab
cd agent-memory-lab
go mod init example.com/agent-memory-lab接著安裝指定版本：
go get github.com/microsoft/agent-framework-go@v0.2.0這條安裝指令來自官方 v0.2.0 Release。
指定版本的好處，是團隊在不同時間建立測試環境時，可以減少因為依賴版本更新而出現的差異。
不過，安裝成功只代表程式取得套件，尚未完成模型連線、Embedding 產生器設定及向量資料庫配置。
因此，第一次上手不宜直接將真實顧客資料放入系統。
如何用三個步驟驗證 Go Agent 的記憶功能？
我會把第一輪測試範圍縮小：先用少量假資料確認「寫入、搜尋、回填」三個動作，再考慮接上雲端資料庫。
以下是依官方提供的 API 能力整理的實作路線。這是一份驗收流程，而非已在本篇環境跑通的完整程式。
步驟一：先建立 In-memory 檢索原型
在官方範例中找到 In-memory Vector Search 相關程式，確認如何建立 Collection、定義紀錄欄位，以及設定 Embedding Generator。
第一輪只需要三筆假資料：
- 測試使用者 A：偏好繁體中文。
- 測試使用者 A：電腦型號 X200。
- 測試使用者 B：電腦型號 Z500。
儲存時應保留使用者範圍，避免單純依照語意相似度搜尋而讀到其他人的資料。
官方的 In-memory Connector 支援精確向量搜尋、批次 Embedding，以及 JSON 快照匯出與匯入。
但它主要適合原型開發與測試。若需要跨程序或長期保存資料，必須另外設計持久化方案。
步驟二：測試能否搜尋到正確資料
先輸入「我的電腦是什麼型號？」並檢查搜尋結果。
在使用者 A 的權限範圍內，預期應讀取 X200 的紀錄，而不是使用者 B 的 Z500。
除了正常案例，還需要刻意測試以下情況：
- 完全沒有相關紀錄時，是否能回覆不知道。
- 兩筆紀錄互相矛盾時，是否能標明不確定性。
- 其他使用者的資料是否被排除。
- 搜尋內容含有惡意指令時，Agent 是否會錯誤執行。
尤其最後一項很重要。從向量資料庫取回的文字是資料，不應自動被提升為最高優先權的操作指令。
步驟三：重新開始對話，驗證記憶是否保留
完成第一次互動後，重新建立一個對話 Session，再詢問先前的設備資訊。
如果程式使用 Chat-history Memory Provider，並把記憶儲存在可跨 Session 讀取的資料範圍內，便可以測試不同對話之間的召回行為。
但是，如果使用的儲存方式只存在程序記憶體中，並且重新啟動後沒有載入先前的快照，就不能期待舊資料自動保留。
測試時應同時記錄：
- 原始使用者問題。
- 檢索到的紀錄識別碼。
- 搜尋結果的使用者與 Session 範圍。
- 實際回填給模型的文字。
- 模型最終回答。
- 答案是否引用了正確來源。
這些紀錄比只檢查「AI 看起來有沒有記住」更有用，因為它們能幫助開發者定位錯誤究竟發生在儲存、檢索還是生成階段。
In-memory、Azure AI Search 和 Cosmos DB 怎麼選？
v0.2.0 的一個重要設計，是提供共同的向量資料介面，讓開發者能針對不同儲存服務建立應用程式。
不過，共同介面不代表更換資料庫時完全不需要調整設定、索引與查詢行為。
| 方案 | 主要用途 | 優點 | 限制 |
|---|---|---|---|
| In-memory Store | 本機實驗、小型原型 | 不必先部署額外搜尋服務 | 需要額外處理持久化及程序生命週期 |
| Azure AI Search | 文件與知識庫檢索 | 支援向量、全文及混合搜尋 | 涉及雲端費用、索引管理與存取權限 |
| Azure Cosmos DB | 結合應用程式資料與向量檢索 | 可在資料庫層管理紀錄及相關查詢 | 需要設計分區、索引、容量及資料治理 |
如果只是想了解 Agent Memory 的基本原理，可以從 In-memory 開始。
如果已經有 Azure 搜尋基礎設施，則可以研究 Azure AI Search 的 Connector。
若應用程式本來就使用 Cosmos DB，則可以評估是否將向量記憶納入現有資料架構。
三者的實際效能與費用，仍需要使用相同資料集及工作負載測量。本文沒有這三種服務的基準測試，因此不作速度排名。
Microsoft Agent Framework 與 Agent Lightning 有什麼不同？
兩個專案都與微軟及 AI Agent 有關，但工作重點並不相同。
| 比較面向 | Agent Framework for Go | Agent Lightning |
|---|---|---|
| 主要目的 | 建立與編排 Agent 工作流程 | 利用執行回饋改善 Agent 行為 |
| 本篇重點 | Embedding、檢索、記憶 | 訓練及優化流程 |
| 主要問題 | Agent 如何取得相關上下文？ | Agent 如何從任務結果中改善？ |
| 適用階段 | 應用程式架構與功能開發 | 行為優化與實驗評估 |
例如，一個客服 Agent 因為找不到舊維修紀錄而回答錯誤，首先需要處理檢索資料的問題。
但如果它已經取得正確紀錄，仍然經常選錯處理方式，就可能需要進一步研究評估與訓練方法。
兩種技術可以出現在同一個更大的系統中，但不能把它們視為可以直接互換的套件。
更多 Agent Lightning 的內容，可參考本站文章：Microsoft Agent Lightning 訓練與回饋流程教學。
這套 AI 記憶機制有哪五個實際風險？
一、找到相似資料，不代表找到正確資料
向量搜尋偏重語意相關性。如果不同客戶使用相似措辭，資料庫可能同時存在多筆相似紀錄。
因此，搜尋結果應結合使用者識別、時間、來源與業務條件過濾，而不能只依賴相似度分數。
二、有記憶功能，不代表一定會記住
記憶能否跨對話使用，取決於資料儲存、檢索觸發條件及 Session 設定。
如果沒有成功寫入，或搜尋結果未能回填，模型仍可能無法使用過去的資訊。
三、記住錯誤資訊，可能持續影響回答
使用者的偏好、設備與需求都可能改變。記憶系統需要提供更新、刪除及處理矛盾紀錄的方法。
尤其是涉及訂單、醫療、財務或個人資料的系統，不宜直接把歷史對話當成永遠有效的事實。
四、跨 Session 記憶可能放大隱私問題
官方 Memory Provider 支援按照 Application、Agent、User 及 Session 等範圍組織資料。
開發者必須明確設定資料隔離與授權，並測試不同使用者之間是否會發生資訊交叉。
如果使用 Azure 或其他外部服務，也需要確認資料傳輸位置、保留政策、刪除機制與相關費用。
五、Preview 版本可能發生 API 變動
官方把 v0.2.0 標示為 Pre-release，整個 Go Framework 也仍處於 Public Preview。
這表示在未來升級時，程式介面或部分功能行為可能改變。
需要長期維護的專案，應固定依賴版本，記錄已驗證的 API 行為，並在升級前重新執行測試。
使用這套框架要花多少錢？
Microsoft Agent Framework for Go 的 GitHub 倉庫採 MIT License，這讓開發者可以依照授權條款取得、修改及使用框架程式碼。
但開源框架不等於整套 AI 應用完全沒有成本。
實際運行可能涉及以下費用：
- 語言模型 API 的輸入與輸出 Token。
- Embedding 模型的文字向量化請求。
- 雲端向量搜尋與資料儲存服務。
- 伺服器、日誌、監控及網路流量。
- 資料保留、備份與安全管理。
成本可以先用下列方式拆開：
總運行成本 =
語言模型費用
+ Embedding 費用
+ 向量儲存與查詢費用
+ 應用程式基礎設施費用
+ 維運與監控成本資料量較小的原型，可以先使用 In-memory Store 避免立即部署外部向量服務，但模型 API 及開發環境的成本仍然存在。
本文未取得同一時間點、同一地區及相同工作負載下的各項實際報價，因此不填入未經核實的月費金額。正式估算應以使用的模型提供者及 Azure 官方計價資訊為準。
哪些人適合使用 Microsoft Agent Framework for Go？
| 使用族群 | 適合程度 | 原因 |
|---|---|---|
| 已有 Go 後端的開發團隊 | 適合評估 | 可以沿用既有語言與工程工具 |
| 需要跨對話客服記憶的團隊 | 適合原型測試 | 可以驗證對話儲存與語意召回 |
| 需要企業文件 RAG 的團隊 | 適合評估 | 可研究 Text Search 與外部向量儲存整合 |
| 完全沒有程式基礎的新手 | 入門門檻較高 | 仍需要 Go、模型 API 和資料庫基本概念 |
| 要求穩定正式版 API 的企業 | 需要審慎評估 | 目前仍處於 Public Preview |
如果只是希望在電腦上與 AI 聊天，不需要專門建立 Agent Framework 專案。
如果已經使用 Go 開發後端服務，並且需要可自訂的工具、工作流或記憶檢索，這個版本就有實際研究價值。
從接案或企業開發角度來看，這類技術比較適合用於建立可維護的客服、知識查詢、內部文件問答或業務流程系統，而不是把「AI 會記住事情」當成可以直接交付的產品成果。
客戶真正需要驗收的，是資料查得準不準、能否正確控制權限、系統出錯時是否可追蹤，以及長期成本是否可控。
如果不使用 Microsoft Agent Framework，還有哪些替代方案？
若團隊使用 Python，或希望研究其他 Agent 工作流設計，也可以比較現有的 Agent 框架。
| 工具 | 主要方向 | 適合情境 |
|---|---|---|
| Microsoft Agent Framework for Go | Go Agent 與工作流程 | 既有 Go 專案及 Microsoft 整合需求 |
| LangGraph | 具狀態的 Agent 工作流編排 | 需要細緻控制工作流程與狀態 |
| RAGFlow | 文件理解與知識檢索系統 | 以文件問答為主要需求 |
這些工具處理的問題並不完全相同，也不代表更換框架後就能直接沿用原有程式碼。
可以延伸參考本站的 LangGraph AI Agent 框架教學，以及 RAGFlow 開源 RAG 引擎入門。
常見問題 FAQ
Microsoft Agent Framework for Go v0.2.0 已經是正式穩定版嗎？
不是。官方 Releases 標示 v0.2.0 為 Pre-release，Go Framework 目前仍是 Public Preview，API 及功能可能持續調整。
使用 Agent Memory 會讓模型真正學會新知識嗎？
不會自動更新模型參數。這裡的記憶主要透過資料儲存及檢索，在模型執行時提供相關上下文。
一定要使用 Azure AI Search 嗎？
不需要。官方同時提供 In-memory 儲存實作，以及 Azure Cosmos DB 等整合方式。不同服務的持久化能力、查詢方式及成本需要分別評估。
不會寫程式也能使用嗎？
可以先理解本文的記憶與 RAG 流程，但若要真正建立 Go Agent，仍需要 Go 語言、套件管理、模型連線及資料庫操作等基本能力。
這個框架適合拿來處理真實個資嗎？
是否適合取決於應用程式的安全設計、資料保護要求及部署環境。框架提供的記憶功能本身不能取代身分驗證、資料授權、隱私管理與合規審查。
結論：現在需要升級到 v0.2.0 嗎？
我的判斷是，對正在使用 Go 建立 Agent 的開發團隊，v0.2.0 提供了一個值得驗證的新方向。
它讓 Embedding、向量資料、搜尋上下文以及對話記憶更容易整合進同一套 Agent 應用程式。
但如果現有系統已經穩定運行，沒有明確的跨對話檢索需求，就不必只因為發布新版本而立即改動架構。
第一輪驗收可以集中在五件事：
- 確認 Go 版本與相依套件符合要求。
- 使用假資料建立 In-memory 原型。
- 測試同一使用者的跨 Session 召回。
- 確認不同使用者之間的資料隔離。
- 評估持久化、API 變更、費用與維護成本。
一個能可靠找到正確紀錄的 Agent，比一個聲稱「永遠不會忘記」的 Agent 更有實際價值。
資料來源
- Microsoft Agent Framework for Go — GitHub Releases（v0.2.0）
- Microsoft Agent Framework for Go — 官方 GitHub Repository
- Microsoft Agent Framework for Go — 官方範例程式
- Microsoft Agent Framework for Go — Embedding 套件
- Microsoft Agent Framework for Go — Vector Data 套件
資料來源與驗證說明：本文以 2026 年 10 月 22 日 12:00（台北時間）為資料截點，功能資訊依 Microsoft 官方 GitHub Release 與 Repository 文件整理。教學案例屬架構及驗收示意，未宣稱已完成本機實測。工具版本、API、支援能力及計價可能在截點後改變，實際部署前應重新核對官方文件。
利益揭露：本文未使用交易所邀請連結或工具返佣連結，亦未因本文內容收取相關工具廠商的推薦報酬。
免責聲明：本文僅供 AI 開發技術研究與教育用途，不構成任何產品安全、效能、商業適用性或法規符合性的保證。正式使用涉及個人資料或敏感資訊的 Agent 系統前，應完成安全測試、資料權限檢查、隱私評估與必要的法務審查。
發佈留言