兩種執行階段仍有較底層的差異。Mono 提供豐富的嵌入 API，讓原生 C 或 C++ 程式碼載入型別、呼叫方法並檢查 .NET 型別；CoreCLR 沒有完全對等的 API 集合。因此，依賴 Mono 嵌入 API 的特殊專案，例如某些遊戲引擎整合方式，可能需要重新設計。不過，這通常不是一般 .NET MAUI 應用會碰到的層次。
過去使用 Mono AOT 時，建置工具 mono-aot-cross 會處理應用程式的 DLL，並為各 DLL 產生對應的原生函式庫。改用 CoreCLR 後，對應的重要技術是 Ready to Run（R2R）：CrossGen2 會在建置時產生原生碼，並將其放入仍含有 IL 的 DLL。這也是啟用 Ready to Run 後，DLL 可能變大的原因。
在 Android 上，.NET MAUI 預設採用部分 Ready to Run，而非將所有程式碼都預先編譯。團隊透過具有代表性的 MAUI 應用記錄啟動時用到的方法，將資料保存為 MIBC 檔案，交給 Ready to Run 編譯器使用。如此可優先加快啟動路徑，同時避免完整預先編譯造成應用程式體積大幅增加。開發者仍可評估自己的應用，決定是否以較大的檔案換取完整 Ready to Run 可能帶來的效能收益。iOS 則因無法以相同方式使用 JIT，沒有採用 Android 的這種部分 Ready to Run 預設方案。
應用程式的封裝方式也會隨之變化。在 Android 上，.NET 組件會被放入名為 libassemblystore 的原生函式庫中，便於依裝置架構封裝與配送。使用 CoreCLR 時，其中除了 IL，也可能包含 Ready to Run 映像；一般開發者通常不需要直接處理這些內部檔案。
Native AOT 是另一條路，不等於這次的 CoreCLR 切換
Native AOT 不只是「把 Ready to Run 開得更完整」，而是另一種執行階段與建置模式。它在建置時完成編譯，不依賴 JIT，並積極移除未使用的程式碼。其成果通常是啟動更快、體積更小的應用；例如 Android 可產生一個包含執行階段與已編譯 .NET 程式碼的 .so 檔案。不過，在這場分享所述的階段，Android 上的 Native AOT 仍屬預覽功能。
John 展示了以 Samsung Galaxy A16 等裝置測試的代表性結果，涵蓋 MAUI 專案範本、加入更多控制項與圖表的範例，以及實際以 .NET MAUI 建置的 Microsoft 365 Admin 應用。在 Android 上，Mono、預設的部分 Ready to Run，以及完整 Ready to Run 的啟動表現大致可比；部分與完整 Ready to Run 哪個較快，會因應用而異。在 iOS 的測試中，展示的應用啟動時間則普遍有所改善。
體積方面，Android 的部分 Ready to Run 與原先 Mono 版本相近，完整 Ready to Run 通常會讓 APK 稍微變大；展示的 iOS 測試則呈現應用程式體積縮小的趨勢。這些結果並不保證每個應用都會相同，因此團隊希望開發者以自己的實際專案測量；若出現明顯異常，也歡迎回報以便調查。
二十年前，Y Combinator（YC）聯合創始人 Paul Graham 曾把「一個人創業」列為可能害死新創公司的頭號錯誤。如今，YC 總裁 Gary Tan 卻在播客《Lightcone》中說：「YC 自己就是獨自創業者的 YC。」這並不代表找搭檔已經過時，而是 AI 正在改變創業初期需要多少人、哪些能力最難取得。
**第二個變化，是資深創業者更能發揮優勢。**Gary Tan 說，他最近見到的一些出色創始人，年齡在三十多、四十多歲，甚至五十多歲。他舉 OpenCLAW 作者 Peter Steinberger 為例：對方四十歲，先前有十年經營公司的經驗。合夥人 Jared 指出，管理 AI 程式設計代理，在某些方面與管理人員相似：都要拆解任務、訂立標準、驗收成果，並預判容易出錯之處。這些能力往往來自長年的實務經驗。當「不會寫程式碼」或「找不到技術搭檔」不再像以前那樣難以克服，熟悉一個行業的人，也更有機會親手驗證自己的想法。
強化學習環境可以理解為 AI 的模擬考場。例如建立一套虛構的公司財務系統，放入帳本、發票和待辦事項，讓 AI 練習對帳、報稅，並依結果自動評分。要讓 AI 學會處理真實工作，除了讀取資料，還需要能反覆操作、檢驗對錯的場景；環境越貼近現實，就越有價值。機器人領域也有類似需求：有公司在各地工廠，以第一人稱視角拍攝工人的操作，再將資料提供給機器人實驗室。YC 認為，部分業者不願公開談論這門生意，正因為不想讓競爭對手注意到機會；YC 於 2016 年投資的 Scale AI，則是這個領域的早期代表。
一段談論 AI 工作方式的影片近期引發討論。原文介紹，一名網名「土豆女神」的工程師 Lauren Tan，展示了由一個 AI 協調多個 AI 代理（Agent）處理工作的做法。原文也提到「指揮 50 多個 AI」、「完成 20 多名工程師的工作量」及「公司九成以上員工都在使用」等說法；這些是原文轉述的宣稱，不能僅憑這段文字確認。
在上一篇關於 Microsoft Agent Framework 系列教學文章 "MFA014 - 多模態輸入（圖片）" 中，我們學會了使用 Microsoft Agent Framework 建立能夠處理圖片輸入的 AI 代理。讓模型接收到多模態的資料，在這裡使用的圖片，這裡的圖片將會是冰箱的照片。透過這個練習，我們了解了如何讓 AI 代理分析圖片內容並給出建議。
在完成這篇文章的練習之後，你將能夠使用 Microsoft Agent Framework 建立一個能夠處理多輪對話的 AI 代理，並了解 Responses API 與 Chat Completions 代理在多輪對話中的差異。所謂的 Chat Completion API 則是每輪都需要將完整對話歷史送給模型，服務端不會保存對話狀態。而對於 Responses API，服務端會保存對話狀態，因此每輪不需要重送完整對話歷史，且能保留上一輪的推論摘要。那麼對於使用者而言，面對問題需求的時候，該如何挑選適合的代理，就可以根據是否需要服務端保存對話歷史以及對訊息數與 Token 使用量的考量來決定。
接下來看看如何做到這樣的效果。
建立 Console 專案
開啟 Visual Studio 2026
選擇「建立新專案」
在 [建立新的專案] 視窗中，在右方清單內，找到並選擇「主控台應用程式」 項目
然後點擊右下方「下一步」按鈕
此時將會看到 [設定新的專案] 對話窗
在該對話窗的 [專案名稱] 欄位中，輸入專案名稱，例如 "csResponsesAgent"
然後點擊右下方「下一步」按鈕
接著會看到 [其他資訊] 對話窗
在這個對話窗內，確認使用底下的選項
架構：.NET 10.0 (或更新版本)
勾選 不要使用最上層陳述式 (這是我的個人習慣)
然後點擊右下方「建立」按鈕
現在，已經完成了這個 Console 主控台 專案的建立
安裝需要用到的 NuGet 套件
要完成這個第一次接觸 Microsoft Agent Framework 練習專案，需要安裝以下幾個 NuGet 套件：
Microsoft.Agents.AI.OpenAI
這個套件是微軟官方為 .NET 整合 AI 服務所提供的擴充套件，專門用於與 OpenAI 進行整合。它實現了 IChatClient 與 IEmbeddingGenerator 核心抽象介面，讓開發人員能以一致的程式碼，輕鬆串接 OpenAI 或相容的 API 端點（例如 Azure OpenAI、GitHub Models 等）。
在上面的範例程式碼中，將會展示如何使用 Responses API 代理與 Chat Completions 代理，並比較它們在處理同一個邏輯題時的行為差異。為什麼會想要這麼來比較呢?因為，這裡提供兩種類型的 API，當我們遇到問題的時候，究竟要如何選擇採用哪種 API 呢?透過這個範例，我們可以觀察到兩者在訊息傳遞、對話管理以及推論摘要上的差異，進而做出更適合的選擇。
**Explaining the puzzle setup**
I’m considering a standard puzzle with three labeled boxes: apple, orange, and mixed, but they’re all incorrectly labeled. Typical strategies involve drawing from the mixed box to find the correct fruit, but here there are four types with three fruit kinds, which complicates things. It seems like one sample isn’t enough to solve this, and I should clarify using counterexamples to support that idea while keeping the explanation concise and clear.
【reasoning effort = High】
[推論摘要]
**Solving the labeling puzzle**
I need to find a solution involving boxes labeled incorrectly with their contents. The mixed-labeled box will help identify what’s inside, which will then allow me to label the others correctly. If I draw an apple from the mixed box, I can eliminate that as a possibility for the remaining boxes, given the constraints of labeling. For instance, if I label one box correctly, I can’t have the others labeled correctly. I’ll explore all possible arrangements next.**Analyzing the box labeling puzzle**
I’m trying to determine if the arrangement A-box B, O-box M, and B-box O is valid. Drawing from the mixed box could help identify one pure box, but it might not uniquely solve the problem with three remaining boxes. To answer the user’s question about guaranteeing the correct contents of four boxes, I need to explain clearly that it’s not possible with just one draw from the mixed box. I have to demonstrate this effectively in three sentences.**Examining labeling strategies**
I need to illustrate that no strategy guarantees accurate labeling, although drawing from the mixed-labeled box seems to be the best option. If I draw an apple, I can identify the mixed box but face ambiguity with two potential assignments. To clarify, I'll label the boxes as Apple A, Orange O, Banana B, and Mixed M. If I draw an apple from M, the remaining contents could suggest two valid assignments for the other labels, which complicates things further.
[答案]
**不能保證推出四個盒子的正確內容。**例如從「混合」盒取出蘋果，可知該盒是純蘋果；但剩下仍可能是「蘋果標籤盒＝混合、橘子標籤盒＝香蕉、香蕉標籤盒＝橘子」，也可能是「蘋果標籤盒＝香蕉、橘子標籤盒＝混合、香蕉標籤盒＝橘子」，兩者都符合所有標籤貼錯，因此一次取樣不足以唯一判定。
token：輸入 118（快取 0）／輸出 652（其中推論 516）／總計 770
從上面的 Low & High 的執行結果可以看出，ReasoningEffort.Low 的推論較為簡單快速，但可能忽略一些細節，例如：無法完整展示所有可能的盒子排列，對於保證正確標籤的推論不夠全面。而 ReasoningEffort.High 則提供了更完整的分析，考慮了多種可能性，能更清楚地說明為什麼無法保證推出四個盒子的正確內容。
觀察上面的對照小結：第二輪（追問）可以發現，Responses API 只送出一則訊息，但服務端會自動帶入上一輪的完整對話歷史，因此能保留推論摘要；而 Chat Completions 代理則需要每輪重送完整對話歷史，導致訊息數增加，且無法保留上一輪的推論內容。這也說明了兩種代理在處理多輪對話時的差異：Responses API 依賴服務端保存對話，Chat Completions 則依賴本機管理對話歷史。對於 Token 使用量而言，Responses API 可能因為帶入完整對話歷史而增加輸入 token，但仍能減少訊息數；Chat Completions 則每輪都需重送完整對話歷史，訊息數增加，且無法保留推論摘要。
執行結果
現在來看看這個範例程式碼的執行結果。
在 Visual Studio 2026 下，按下 F5 鍵執行程式，將會看到程式輸出的結果。
使用的模型：gpt-5.6-luna
邏輯題：有四個盒子，標籤分別是「蘋果」「橘子」「香蕉」「混合」，但四個標籤全部貼錯了。你只能從其中一個盒子拿出一顆水果來看（不能看盒子裡面），能不能保證推出四個盒子的正確內容？請說明。
======================================================================
示範一：Responses API ＋ 推論摘要（同一道題，effort = Low vs High）
======================================================================
【reasoning effort = Low】
[推論摘要]
**Explaining the puzzle setup**
I’m considering a standard puzzle with three labeled boxes: apple, orange, and mixed, but they’re all incorrectly labeled. Typical strategies involve drawing from the mixed box to find the correct fruit, but here there are four types with three fruit kinds, which complicates things. It seems like one sample isn’t enough to solve this, and I should clarify using counterexamples to support that idea while keeping the explanation concise and clear.
[答案]
**結論：不能保證推出四個盒子的正確內容。**
應從標籤「混合」的盒子取水果，因為它不可能是混合盒，若取到蘋果，只能確定該盒是純蘋果，但其餘三盒仍可能有多種符合「全錯」的排列，例如「蘋果標籤盒」可為混合或橘子盒。
因此一次取樣所得資訊不足以唯一確定四個盒子的內容。
token：輸入 118（快取 0）／輸出 418（其中推論 295）／總計 536
【reasoning effort = High】
[推論摘要]
**Solving the labeling puzzle**
I need to find a solution involving boxes labeled incorrectly with their contents. The mixed-labeled box will help identify what’s inside, which will then allow me to label the others correctly. If I draw an apple from the mixed box, I can eliminate that as a possibility for the remaining boxes, given the constraints of labeling. For instance, if I label one box correctly, I can’t have the others labeled correctly. I’ll explore all possible arrangements next.**Analyzing the box labeling puzzle**
I’m trying to determine if the arrangement A-box B, O-box M, and B-box O is valid. Drawing from the mixed box could help identify one pure box, but it might not uniquely solve the problem with three remaining boxes. To answer the user’s question about guaranteeing the correct contents of four boxes, I need to explain clearly that it’s not possible with just one draw from the mixed box. I have to demonstrate this effectively in three sentences.**Examining labeling strategies**
I need to illustrate that no strategy guarantees accurate labeling, although drawing from the mixed-labeled box seems to be the best option. If I draw an apple, I can identify the mixed box but face ambiguity with two potential assignments. To clarify, I'll label the boxes as Apple A, Orange O, Banana B, and Mixed M. If I draw an apple from M, the remaining contents could suggest two valid assignments for the other labels, which complicates things further.
[答案]
**不能保證推出四個盒子的正確內容。**例如從「混合」盒取出蘋果，可知該盒是純蘋果；但剩下仍可能是「蘋果標籤盒＝混合、橘子標籤盒＝香蕉、香蕉標籤盒＝橘子」，也可能是「蘋果標籤盒＝香蕉、橘子標籤盒＝混合、香蕉標籤盒＝橘子」，兩者都符合所有標籤貼錯，因此一次取樣不足以唯一判定。
token：輸入 118（快取 0）／輸出 652（其中推論 516）／總計 770
======================================================================
示範二：服務端保存對話（Responses API，只傳上一輪的 response id）
======================================================================
【第一輪：原題】
[推論摘要]
**Explaining a classic puzzle**
I need to answer in traditional Chinese, starting with a clear conclusion followed by an explanation of three sentences maximum. The puzzle involves labeling where the contents are pure apple, orange, banana, or a mixed fruit, all with wrong labels. The strategy is to draw from the box labeled mixed, as it cannot contain mixed fruit, allowing identification of the true contents of the other boxes too.
[答案]
可以保證。先從標示「混合」的盒子取一顆，因標籤全錯，它不可能是混合盒，因此看到的水果即可確定該盒是對應的單一水果盒；再依「其餘標籤全錯」的條件，排除已知內容，唯一確定另外三盒的正確配置。
實際送出訊息數：1 則
帶出的對話 id ：（無）
回來後 session.ConversationId：resp_09570987efccb64b006af16ce2a45c8193bf29d2ab8c90fe24
token：輸入 118（快取 0）／輸出 172（其中推論 81）／總計 290
【第二輪：追問（不重述題目）】
[推論摘要]
（沒有收到推論摘要：Chat Completions 不提供；Responses 則在推論太短時會省略）
[答案]
應從標示「混合」的盒子拿。因為標籤全錯，該盒必定是純蘋果或純橘子；若拿到蘋果，它就是蘋果盒，標示「橘子」的盒子只能是混合盒，剩下的是橘子盒（拿到橘子時反之亦然）。
實際送出訊息數：1 則
帶出的對話 id ：resp_09570987efccb64b006af16ce2a45c8193bf29d2ab8c90fe24
回來後 session.ConversationId：resp_09570987efccb64b006af16d266f98819398624f4df0d0cb1b
token：輸入 331（快取 0）／輸出 89（其中推論 0）／總計 420
======================================================================
示範三：對照組 Chat Completions（每一輪都把整段歷史重送）
======================================================================
【第一輪：原題】
[推論摘要]
（沒有收到推論摘要：Chat Completions 不提供；Responses 則在推論太短時會省略）
[答案]
**不能保證推出四個盒子的正確內容。**
例如從「混合」盒取出蘋果，只能確定該盒是「蘋果」，但其餘仍可能是「蘋果標籤＝橘子、橘子標籤＝香蕉、香蕉標籤＝混合」，也可能是「蘋果標籤＝混合、橘子標籤＝香蕉、香蕉標籤＝橘子」，兩者都符合所有標籤貼錯。
因此一次取出一顆水果的資訊不足以唯一確定四盒內容。
實際送出訊息數：1 則
帶出的對話 id ：（無）
回來後 session.ConversationId：（無，歷史存在本機 session）
token：輸入 118（快取 0）／輸出 660（其中推論 512）／總計 778
【第二輪：追問（不重述題目）】
[推論摘要]
（沒有收到推論摘要：Chat Completions 不提供；Responses 則在推論太短時會省略）
[答案]
**應該從標籤為「混合」的盒子拿一顆水果。**
因為所有標籤都錯，「混合」盒不可能是混合；若拿出蘋果，它就是蘋果盒，接著標籤「橘子」的盒只能是混合，標籤「蘋果」的盒則是橘子。
若拿出橘子，推理對調即可，因此一定能推出三盒內容。
實際送出訊息數：3 則
帶出的對話 id ：（無）
回來後 session.ConversationId：（無，歷史存在本機 session）
token：輸入 307（快取 0）／輸出 177（其中推論 58）／總計 484
======================================================================
對照小結：第二輪（追問）
======================================================================
實際送出的訊息數：Responses = 1 則｜Chat Completions = 3 則
帶出的對話 id：Responses = 上一輪的 response id｜Chat Completions = （無）
輸入 token（其中快取）：Responses = 331（0）｜Chat Completions = 307（0）
推論 token：Responses = 0｜Chat Completions = 58
兩輪中拿到推論摘要：Responses = 是｜Chat Completions = 否
對話歷史存在哪裡：Responses = OpenAI 服務端｜Chat Completions = 本機 AgentSession
觀察：Responses 第二輪只送 1 則訊息，但服務端會把上一輪的完整內容（含推論項目）接回上下文，
所以輸入 token 照樣計費，甚至可能比 Chat Completions 多；Chat Completions 重送的只有看得見的文字，
上一輪的推論內容直接丟掉。（提示快取要前綴超過約 1,024 token 才會命中，這個範例太短所以是 0）
.png)
