對於許多 .NET 工程師來說，尤其是剛接手大型專案的 Junior 工程師來說，最痛苦的時刻之一就是面對 CI（持續整合）環境中失敗的 Build 錯誤。通常我們得下載巨大的二進位日誌（Binlog），開啟 Structured Log Viewer 慢慢捲動，試圖在數千行日誌中找出那個導致失敗的 Target 或 Task。
微軟近期分享了如何利用 Model Context Protocol（MCP）將這種繁瑣的診斷過程自動化，讓 AI 代理人（Agent）直接在 GitHub Actions 中分析 Binlog，並在 Pull Request（PR）中直接告訴你錯誤原因與修正建議。
什麼是 MCP 與 Binlog
在進入實作前，需要先理解兩個核心概念。首先是 Binlog（Binary Log），這是 MSBuild 產生的二進位格式日誌（透過 dotnet build /bl 產生），它記錄了建置過程中的所有細節，比一般的文字日誌更結構化且完整。
其次是 MCP（Model Context Protocol），這是一個開放標準，旨在讓 AI 模型能以統一的方式存取外部工具和數據。簡單來說，MCP 就像是為 AI 準備的 API 接口，讓 AI 不再只是靠預訓練的知識在猜測，而是能實際調用工具去讀取檔案、查詢資料庫或分析日誌。
將診斷流程移入 CI 管道
以往 AI 助手分析日誌需要工程師手動上傳檔案，但現在透過 GitHub Agentic Workflows，這個過程可以完全自動化。
運作流程如下：當 PR 的建置失敗時，系統會自動啟動一個運行在容器中的 Binlog MCP Server。這個伺服器會讀取建置產出的 Binlog 檔案，並將其提供給 AI Agent。Agent 會根據失敗情況，自動調用一系列診斷工具（例如 binlog_overview 確認失敗位置，再用 binlog_errors 抓取具體錯誤），最後直接在 PR 下方留言，指出錯誤的文件、行號，甚至提供可以直接套用的修正建議。
這種做法將診斷從 只有專家才能處理 的黑盒子，轉化為 任何人都能快速理解 的自然語言說明，大幅降低了 Junior 工程師被建置錯誤卡住的時間。
超越簡單查詢：強大的診斷工具集
Binlog MCP Server 提供的不僅僅是錯誤搜尋，它包含了 30 多個專業工具，涵蓋了建置診斷的各個面向：
針對執行邏輯的工具：例如 binlog_target_reasons 可以解釋為什麼某個 Target 被執行或跳過，解決那些為什麼每次都要重新建置的疑惑。
針對環境差異的工具：binlog_compare_property 可以比對兩個不同環境（例如你的筆電與 CI 伺服器）的屬性設定，快速找出導致 我在本地端沒問題 的設定差異。
針對效能分析的工具：binlog_expensive_analyzers 能列出最耗時的 Roslyn 分析器或來源產生器，幫助團隊優化建置速度。
針對依賴關係的工具：binlog_build_graph 可以分析專案依賴圖與關鍵路徑，找出影響建置時間的瓶頸。
實務影響與效能提升
根據微軟的評估數據，引入 Binlog MCP 工具後的 AI 診斷表現有顯著提升。與沒有工具的純 AI 分析相比，使用 MCP 伺服器的配置在平均得分提高的同時，診斷時間縮短了約 44%。
這是因為 AI 不再需要閱讀海量的原始文字日誌，而是透過結構化的工具直接獲取關鍵資訊。這不僅降低了 Token 的消耗（成本更低），也減少了 AI 產生幻覺（Hallucination）的機會。
如何開始嘗試
如果你想在自己的專案中嘗試，可以從以下步驟開始：
首先，在執行建置指令時加上 /bl 參數，例如 dotnet build /bl，產生二進位日誌。
其次，在 Visual Studio 或 VS Code 中安裝 dotnet-msbuild 插件，這讓你可以直接在編輯器中使用 AI 助手來分析該日誌。
最後，若要將其導入 CI，可以參考 microsoft/testfx 儲存庫的實作模式，將 Binlog MCP Server 容器化並整合進 GitHub 工作流中。
總結來說，MCP 將 AI 的能力從單純的聊天視窗，延伸到了開發流程的基礎設施中。它讓建置診斷從一種 經驗導向 的技能，變成了一種 自動化 的服務。
來源：devblogs.microsoft.com - MCP Beyond the Chat Window: Build Diagnostics in CI
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。