Foundry 讓代理不必重寫就上線

以前我做代理要先重寫一輪才能上線，現在 Foundry 的做法是把框架、工具、記憶體和執行環境拆開，直接往正式環境搬。

我這陣子一直在看代理怎麼從 demo 走到正式上線，老實說，前面都很順，後面就開始卡。Notebook 裡跑得好好的東西，一進服務就變臉；工具驗證一換環境就壞；記憶體不是亂塞就是根本沒辦法持久化；追查問題時，只看到模型呼叫，完全不知道它為什麼會在半夜做出那種蠢決定。直到我讀到 Microsoft 在 Build 2026 講的 Foundry，我才覺得這篇不是在賣新玩具，而是在承認一件很煩但很真的事：代理的原型很容易，營運模型才是重頭戲。

這篇是 Tina Schuchman 寫在 Microsoft Foundry Blog 的內容，發表時間是 2026 年 6 月 2 日。我這裡沒有硬掰什麼瀏覽數、收藏數或星數，原文也沒給。我在意的是它的架構態度：從 GitHub 建、在 Foundry 跑、把代理送到使用者本來就在的地方。這種說法很直接，也剛好戳到我一直覺得不對勁的地方。

把框架當成可換零件，別把它當成終身伴侶

「Foundry 把代理框架層視為可切換的接點；你在 LangGraph、GitHub Copilot SDK，或 Claude Agent SDK 的投入都能延續。如果你要從頭開始，Microsoft Agent Framework 是我們主推的開源選擇，支援 Python 與 .NET。」

翻譯一下就是：框架不要綁死。你今天用這套，明天想換另一套，不該整個代理推倒重來。我很認同，因為我真的踩過那種坑。某套編排框架在本機看起來超順，結果一碰到正式環境就開始付學費。每加一個流程，就得先學它那套很有主見的寫法；每接一個工具，就多一層轉接器。最後你不是在做產品，你是在替框架辯護。

Foundry 的意思是，真正重要的不是框架本身，而是代理執行層、工具、記憶體和操作迴圈。你如果先從 LangGraph、GitHub Copilot SDK / Microsoft Agent Framework，或 Claude Agent SDK 起手，Microsoft 的說法是這些投資不會白費；如果你是新案子，則可以直接看 Microsoft Agent Framework。我喜歡這種姿態，因為我不想一開始就把整個產品押在某個平台最愛的抽象層上。

實操寫法很簡單：把商業邏輯和編排框架拆開。代理只暴露很窄的介面，像是任務執行、工具使用、狀態更新。提示詞、政策、路由規則都放在版本化檔案裡，不要埋在框架 callback 裡。這樣你哪天要換 harness，真正的工作邏輯才帶得走。

• 工具定義放共用 schema，不要塞在框架 callback。
• 提示詞、政策、路由規則都要版本控管。
• 從第一天就設計可遷移，別等搬家時才補救。

在編輯器裡把代理跑通，別把迭代拆成四個工具

「Foundry Toolkit for VS Code 已正式推出，讓你不用離開編輯器，就能完成專門為開發者設計的體驗。」

這句話我聽起來很舒服，因為它在處理一個老問題：寫代理、跑代理、看追蹤、部署代理，能不能不要分成四個地方？我對那種工作流真的沒耐心。你如果要一直在工具之間跳來跳去，等你回過神來，早就忘了自己剛剛到底在 debug 什麼。

Foundry Toolkit for VS Code 的方向很實際。原文提到，你可以從樣板或 GitHub Copilot 建代理、在本機測試與除錯、看完整 trace、逐步檢視行為、接 Toolboxes，然後直接從 VS Code 部署到 Foundry Agent Service。這不是花俏功能，這是把回饋迴圈縮短到還像人類能工作的程度。

我以前做過一個內部客服分流代理，程式本身沒什麼大問題，真正煩的是每改一次都得部署，才能知道工具鏈有沒有壞。結果我後來根本不想改了。這就是成本，不是算力，不是 token，而是開發者開始怕動。只要編輯器能先把 trace、工具呼叫和本機執行攤開，我就比較敢繼續往前推。

實操寫法：把本機 trace 檢視變成預設流程。你的代理平台如果不能在部署前看到工具呼叫、記憶體讀寫、分支決策，那你其實是在盲修。先做一個跟正式環境輸入格式一致的本機 harness，再提供一個能把同一份 artifact 丟去受管 runtime 的按鈕或指令。

• 第一版代理直接用樣板起手。
• 本機跑就要看得到 trace，不要只看 production。
• 部署動作要能從同一個編輯環境完成。

工具層不收斂，代理就會散掉

「工具就是代理做事的方法：呼叫 API、搜尋文件、執行程式碼、跟其他代理互動。」

這句其實就是整個問題本體。大部分代理不是推理不行，而是每個工具都像一個小型整合案，自己有自己的驗證、協定、重試和生命週期。你會看到團隊花很多時間把三個工具做得看起來一致，卻沒花那麼多時間讓代理真的有用。很累，而且根本不會規模化。

Microsoft 的回應是 Foundry Toolboxes。原文的說法是：把所有工具型態收斂到單一受管端點，工具只要配置一次，任何 MCP client 指向同一個 URL 就能用，認證、生命週期和治理交給 Foundry。這種話平常聽起來很無聊，直到你開始維護十幾個 connector，才會知道這叫救命。

我也在意技能 catalog 這件事。原文提到 skills 是第一級資產，會以專案範圍的 catalog 版本化，並可被任何代理當成 MCP resource 發現。這比把一堆匿名函式丟給模型好多了，因為代理拿到的是一組有名字、可治理的能力，而不是雜物抽屜。原文還提到 tool search，這也很實際，因為工具一多，模型根本不可能自己穩定挑對。

實操寫法：把工具當產品 API 管。命名要穩、版本要清楚、每個工具什麼時候該用要寫明白。不要把所有內部 endpoint 直接暴露給模型。先做一層精選過的工具目錄，再加搜尋或排序，讓代理只看到相關選項。如果你有多家工具供應來源，就先把它們包成同一個入口，別讓模型直接面對亂七八糟的差異。

我現在比較少問「模型能用哪些工具」，我會先問「這個工作最小但夠用的工具面是什麼」。這個問題一改，後面真的少很多痛苦。

• 把原始 API 包成受治理的工具層。
• 技能要像程式碼一樣版本化。
• 工具變多後，就加搜尋，不要硬塞給模型猜。

記憶體不是加分項，它就是工作本身

「記憶體會讓這些動作越來越有依據，也越做越好。」

這句話寫得很收斂，我反而覺得對。太多代理示範把記憶體做成小把戲，通常就是存一段對話紀錄，然後說自己有智慧。那不是記憶體，那只是帶著樂觀情緒的逐字稿。

原文把 Foundry Agent Service 的記憶體拆成三層：procedural memory、user memory、session memory。procedural memory 是我覺得最常被忽略的，它讓代理記住「怎麼做事」而不是只記住「做過什麼」。Microsoft 提到早期 Tau-bench 結果顯示，絕對成功率提升 7–14%，而且成本接近基準線。我不會把這數字吹成神蹟，但它至少說明 procedural memory 不是裝飾品。

user memory 很直觀，就是偏好和跨會話要保留的事實。session memory 則是短期上下文，讓一次對話不會斷掉。三層合起來，代理才不會每次重啟都像失憶。

我之前做 PR review 代理時就吃過這個虧。沒有 procedural memory 的時候，我每次都得提醒它先看測試，再看相依，再看 API 變更，最後才做摘要。後來把流程寫進 procedure，它就不需要我每次重講。這種記憶體才是真的有用，因為它改變的是輸出品質，不只是聊天長度。

實操寫法：先按壽命和用途切記憶體。暫時對話上下文、使用者偏好、可重複流程，三者不要混在同一包。接著替有順序要求或合規要求的工作加上 procedural layer。千萬不要把所有東西塞進一個 blob，再期待檢索系統幫你整理，通常不會。

如果你的代理是要重複做事，記憶體就該記方法，不只是事實。這差很多。

正式環境要隔離執行，不要只靠一支希望很大的 script

「每個 session 都在自己的 sandbox 裡執行，彼此隔離，包含獨立的運算、記憶體和檔案系統。」

這句話其實很樸素，但我很買單。因為一旦代理可以跑程式、碰檔案、呼叫 API、還持有狀態，你就需要隔離。你需要可預測的 runtime。你需要一個地方，讓某個 session 出包時不會污染下一個 session。Notebook 不是那個地方，cron job 也不是，正式的代理 runtime 才是。

Foundry Agent Service 被當成正式代理的受管 runtime，而且是 framework-agnostic。這點我很在意，因為它代表 runtime 不想搶你的編排選擇，它想接手那些無聊但必要的事：sandbox、狀態、擴展性。原文也提到它支援 Responses API 的有狀態互動，以及 Invocations protocol 的 schema-free pass-through 情境。

這種彈性很有價值，因為你可能真的會有不同技術棧混在一起的代理。原文直接點名 Microsoft Agent Framework、GitHub Copilot SDK、LangGraph 等 SDK。我喜歡這點，因為我看過太多平台要求你先重寫，才願意幫你托管。那不是平台策略，那是收過路費。

實操寫法：讓執行環境可以換。檔案系統假設要寫清楚，狀態要能序列化，重試最好是冪等，長任務要有持久化 checkpoint。不要假設代理一定是一個單輪聊天，原文也提到長時間自主代理和 routine，這才是實際工作長相：監看、等待、恢復、執行、回報。

如果 runtime 不能處理這種節奏，它就還沒碰到真正的生產環境。

把代理送進工作現場，別只做另一個展示頁

「可以發佈到 Microsoft Teams 和 Microsoft 365 Copilot。」

翻譯一下就是：讓代理出現在大家本來就在工作的地方，不要叫使用者再開一個新 app、學一套新習慣。我對這點很有感。內部工具常常死得很安靜，原因不是不好用，而是太麻煩。只要代理有價值但入口很卡，它最後就只會變成 demo，不會變成產品。

Build 的內容提到，託管代理可以發佈到 Microsoft Teams 和 Microsoft 365 Copilot。這不只是分發，這是採用策略。代理直接待在協作場域裡，請求、文件、會議、決策都在那裡，使用者比較不需要改行為。

還有一個我很在意的次級效果：當代理待在既有工作場景裡，你比較容易看見它到底有沒有人用。你不用猜大家有沒有記得一個額外網址。不是在那個場景裡被用到，就是沒被用到，訊號很乾淨。

實操寫法：先決定交付面，再來煩提示詞。你的使用者如果本來就在聊天、文件或工單系統裡，那就先往那裡送。互動模式要跟實際工作位置一致，然後保留把事情交給真人接手的能力，不要讓上下文斷掉。

如果你是做企業場景，分發本來就是架構的一部分。忽略它，最後很容易變成技術上沒問題、但沒人碰的代理。

把代理當系統營運，不要當一次性作品

「Foundry Agent Service 提供追蹤與評估，還有 agent optimizer，形成一個封閉迴圈，把 production failure 變成可排序、可審查的代理改善項目。」

這段是我最在意的，因為大多數團隊在這裡還在即興演出。代理一旦上線，你就得知道它做了什麼、為什麼那樣做、要怎麼修，而且不能靠猜。追蹤如果只停在模型呼叫邊界，你根本沒看到系統真正怎麼運作。

Microsoft 的操作故事是 tracing 加 evaluation 再加 optimizer。白話就是：把發生過的事記下來、替它打分、再把失敗案例回灌到改善流程。我喜歡「可排序、可審查」這個說法，因為它代表人還是要在場。很好，應該要這樣。我不想讓 optimizer 偷偷把代理改掉，卻連修改紀錄都沒有。

這跟我以前做服務除錯的經驗一樣。如果你不能端到端追一個請求，你不是在營運系統，你是在祈禱。代理更麻煩，因為模型會分支、會呼叫工具、還會跨時間帶著狀態走。沒有一個把 failure 接回 fix 的迴圈， production bug 只會變成口耳相傳的都市傳說。

實操寫法：每個重要步驟都要打點。記工具選擇、工具輸入、工具輸出、記憶體讀寫、分支決策和重試。替壞掉的 run 建一個 review queue。然後把 evaluation 放進 release 流程，不要事後才補。如果一個提示詞、技能或工具改動只讓單一指標變好，卻把別的地方搞爛，你要在上線前看見它。

我講白一點：如果你還沒在接近正式環境的條件下評估代理，你就別急著叫它 production agent。

可抄的模板

# 代理上線作業模板（Foundry 風格，可直接改成你自己的堆疊）

## 1) 讓框架可以換
- 編排框架：`Microsoft Agent Framework` / `LangGraph` / `Claude Agent SDK`
- 商業邏輯獨立於框架 callback
- 提示詞、政策、路由規則都放在版本化檔案

## 2) 定義窄一點的代理介面
- 輸入：任務、使用者上下文、session ID
- 輸出：結構化結果、工具 trace、信心分數、下一步動作
- 狀態：明確、可序列化、可恢復

## 3) 把工具統一在同一層
- 所有工具經過單一 catalog 或 endpoint
- 每個工具與技能都要版本化
- catalog 變多後再加搜尋或排序
- 認證、重試、治理都放在工具層，不要塞進 prompt

## 4) 記憶體按壽命切開
- session memory：只管當前對話
- user memory：長期偏好與事實
- procedural memory：固定流程與步驟順序

## 5) 本機先跑 trace
- 本機執行時要看得到：
  - 工具呼叫
  - 記憶體讀寫
  - 分支決策
  - 重試
  - 最終輸出
- 先 debug 再部署，不要反過來

## 6) 部署到隔離 runtime
- 一個 session 一個 sandbox
- 獨立運算、記憶體、檔案系統
- 重試要冪等
- 長任務要有持久化 checkpoint

## 7) 發佈到使用者本來就在的地方
- Teams
- Microsoft 365 Copilot
- 或你產品的主要工作場景

## 8) 用回饋迴圈營運
- production trace 要留
- 壞掉的 run 要 review
- 輸出要跑 evaluation set
- 修正結果要回灌到 prompt、工具、記憶體或路由

## 9) Release 檢查表
- [ ] 工具 schema 已版本化
- [ ] 記憶體邊界已寫清楚
- [ ] 本機 trace 與正式環境 trace 對得上
- [ ] runtime 隔離已驗證
- [ ] 上線前後都有 evaluation
- [ ] prompt、工具、技能都有 rollback 路徑

## 10) 專案骨架

agent/
  prompts/
    system.md
    routing.md
  tools/
    catalog.yaml
    schemas/
  memory/
    session.md
    user.md
    procedural.md
  eval/
    golden-cases.json
    scoring.md
  runtime/
    sandbox.md
    checkpoints.md
  ops/
    trace-review.md
    release-checklist.md

這份模板是我根據 Microsoft 在 Build 2026 文章裡丟出的模式整理出來的，但結構和寫法是我自己重新拼的。你可以把它當成一個通用的代理營運模型，不用照抄 Microsoft 的產品文件。先拿去改成你自己的框架、工具層和 runtime，再慢慢補細節。

原始來源是 Microsoft Foundry Blog 這篇由 Tina Schuchman 撰寫的文章。我這篇是基於它的拆解與延伸，另外引用了 LangGraph、Microsoft Agent Framework、Foundry Toolboxes、Foundry Agent Service 等官方文件。