微軟把 Linux 變成 AI 基礎設施

我拆微軟這套 agentic stack，重點不是模型，是把 Linux、開源標準與治理一起當成 AI 基礎設施。

我最近一直在看各種 agent 架構，越看越煩。很多團隊都很會講「讓 AI 幫你做事」，Demo 也都漂亮，結果一進到真實環境就開始露餡：底層作業系統不一致、容器映像來源說不清楚、代理彼此講不同語言、出了事又沒人能追。說白了，大家很愛把聰明的那層做很花，卻把最該穩的那層做得像臨時拼的。

我用這類 open source for AI 的論述看了一陣子，心裡一直有個結：如果你連機器底下跑的是什麼都沒講清楚，那你其實不是在做 agent 平台，你是在做一個會說話的風險堆疊。這次我看到微軟在 Open Source Blog 這篇文章，才覺得終於有人把那幾層 boring 的東西講對了。

真正重要的不是發表會，是底層先站穩

「我們宣布兩個更新，分別是 Azure Linux 4.0 在 Azure Virtual Machines 上的公開預覽，以及 Azure Container Linux 的正式可用。」

翻譯一下就是：微軟現在不是把 Linux 當成隨便可替換的底座，而是直接把它放進 AI 平台的設計裡。這件事我其實很買單，因為 agent 跟雲原生工作負載都一樣，根本不在乎你的簡報做得多漂亮，它們只在乎核心行為穩不穩、映像漂不漂、補丁節奏亂不亂。

這篇文章把 Azure Linux 4.0 和 Azure Container Linux 拉出來講，不是為了炫技，而是在講一個很現實的事：如果你要讓 AI 工作負載可預測，就先讓它跑的機器可預測。前者是 Fedora 衍生、RPM 基礎的 Linux 發行版，後者則是以 Flatcar 為基底的容器最佳化系統。它們都在往更小的套件面、更穩的供應鏈、更一致的執行特性走。

我以前看過不少團隊想在通用 Linux 發行版上硬拗出「AI-ready」平台，結果就是先刪套件、再鎖映像、最後還是被 drift 打臉。這種做法很像先把地基蓋歪，再花三個月想辦法把牆扶正。你既然已經知道目標環境，幹嘛不直接用有意見的底層？

實操寫法很簡單：如果你有 Azure 工作負載，就把 node 與 container base image 當成平台決策，不是應用團隊自由選配。把 OS 選擇寫進平台文件，固定映像來源，升級流程當成基礎設施變更來測，不要把它當平常 patch Tuesday 那種可有可無的例行事。

• 把 package footprint 壓小，攻擊面自然也會小。
• 映像來源要可追溯，不要靠人腦記憶。
• Host 與 container 的假設要對齊，不然 runtime drift 會在你最忙的時候冒出來。

微軟這次押開源，不是情懷，是因為封閉堆疊很快就會卡死

這篇文章很刻意提到歷史，我覺得這不是在賣情懷，而是在補論證。文中提到 2009 年 Hyper-V driver 貢獻進 Linux kernel，接著又說 Azure 上超過三分之二的 customer cores 跑的是 Linux，還提到 Microsoft 365、GitHub、OpenAI 的 ChatGPT 背後也站在 Linux 基礎上。這些句子看起來像在自我介紹，其實是在講一件很務實的事：規模越大，越不能把基礎設施關在黑盒子裡。

我自己踩過這種坑。以前有團隊想標準化到一套 vendor-managed stack，採購簡報看起來很順，真的進到 incident review 就完全不是那回事。問題不是功能少，是你看不到失敗模式。看不到，就沒辦法一起修；沒辦法一起修，就只能一直忍。開源不會自動解決一切，但至少它讓問題可以被討論、被對齊、被往上游修。

實操寫法是：你在選 AI 或 agent 平台元件時，直接問三個問題。第一，我能不能檢視它？第二，我能不能往上游貢獻？第三，我能不能在不重寫應用的情況下換掉它？如果三題都答不出來，你買的不是基礎設施，你買的是依賴焦慮。

• 優先挑有活躍上游治理的專案。
• 看你的供應商是貢獻者還是純消費者。
• 只要 agent 會跨雲、跨 runtime，移植性就不該是附加題。

Agent 需要 runtime，但更需要契約

這篇最有意思的地方，是它沒有把 agent 當成一個漂亮的應用層名詞而已。微軟明講：從 cloud native 走到 AI native，是開源下一步的演化，而且 AI 也正在改變開源的建造方式。維護者已經開始用 coding agent 做 issue triage、產測試、review pull request；agentic 工具也開始接手 dependency update 和安全修補。這些都不難理解，因為這些事情本來就很適合自動化。

但麻煩從這裡開始。當 agent 真正開始做事，你就不能只問它會不會做，還要問：誰批准的？哪個 policy 管的？事後怎麼 audit？這些如果不先定義，agent 只是把混亂自動化而已。我看過太多團隊在 demo 階段很爽，等到第一次安全審查就整個卡住，因為根本沒人說得出決策路徑。

文章裡點名了幾個微軟押的元件：Semantic Kernel、AutoGen、新的 Microsoft Agent Framework，還有 Ray、NVIDIA Dynamo、A2A 協定，以及 Agent Governance Toolkit。這些名字放在一起，意思很清楚：微軟想把「agent」從會聊天的 demo 名詞，變成有生命週期、可觀測、可控管的系統。

實操寫法：你如果也在做 agent 系統，請把 runtime 跟 controls 分開。前者管規劃、執行、工具呼叫；後者管身分、權限、記錄、審核。這兩層如果硬塞在一起，等你第一次碰到資安 review，會痛到懷疑人生。

互通性不是加分題，是多代理系統的命根子

文章對 Linux Foundation 和 Agentic AI Foundation 的著墨很多。微軟說 AAIF 已經是 Linux Foundation 歷史上成長最快的專案之一，目標是定義 agent-to-agent communication、agent runtime、orchestration 的開放標準。這段我看了很有感，因為 agent 領域最容易出現的爛戲，就是每家都想發明自己的私有協定。

我見過太多「平台策略」最後變成翻譯層地獄。今天一個團隊做一個 agent，明天另一個團隊做另一個，最後整個組織要自己維護一層沒人想碰的轉接器。標準很無聊，但標準會救你。尤其當你不只一個 agent，不只一個供應商，不只一個 runtime 的時候，互通性就不是願景，是生存條件。

這篇把 AAIF 跟 CNCF 類比，我覺得很準。Kubernetes 之所以能進企業，不是因為它看起來很潮，而是因為生態系終於在周邊原語上形成共識。agent 也會走同一條路。如果它們不能跨框架、跨雲、跨語言乾淨溝通，那每個多代理部署最後都會變成客製整合案。

實操寫法：你在評估 agent 工具時，先看它講的是不是開放介面，而不是只會講自己的方言。如果你的 roadmap 會有多個團隊、不同供應商的 agent，一開始就把 protocol compatibility 當成硬需求，不要等到第二個整合案才發現自己蓋了圍牆。

• 要求 agent 之間有清楚的訊息格式與錯誤回傳規則。
• 不要接受只能在單一框架內跑的黑箱協定。
• 把跨框架互通列進平台驗收條件。

安全不是收尾工作，agent 一有自主權就得先管住

這段是我最在意的。微軟直接說，保護開源現在不是 hygiene，而是讓 AI agent 真正做事的前提。這句話比很多 AI security 的空話都實際。文章點名 OpenSSF 和 Alpha-Omega，也提到微軟做了分階段投資：先透過專家參與與自動化測試改善安全姿態，再投入第二輪去擴大可持續、以 AI 驅動的開源安全方案。它還提到 GitHub Secure Open Source Fund，每個專案提供 10,000 美元，外加三週教育、導師、工具與 check-in。

翻譯一下就是：微軟把 maintainer 當成供應鏈安全的一部分，而不是把他們當免費勞工。這點我覺得很對。你不可能靠對志願者大吼大叫來保護供應鏈，你只能把維護者當成真正的控制面，然後用資源和自動化把重複性的風險壓下去。

我自己待過那種把「安全」當季度報表的團隊，最後都很像在做道德管理，不是在做風險管理。只要 agent 開始能更新依賴、開 PR、修 container，你的信任模型就不能再靠手感。它必須從第一天就可機器讀取、可稽核、可追蹤。

實操寫法：先定 agent 能做什麼、不能做什麼，再讓它碰 production。每個 agent 產生的變更都要記錄 actor、tool、policy decision、timestamp；高風險動作要有人審；SBOM 與 provenance 檢查不能關。如果 agent 能改 code，它也能在你沒設防的時候幫你製造下一個 incident。

我最信的，其實是微軟列出的上游清單

文章最後列了一長串微軟有貢獻的專案：Kubernetes、Helm、containerd、Istio、Envoy、OpenTelemetry、ArgoCD、OPA Gatekeeper、Cilium、Dapr、KAITO、KubeFleet、Radius、Drasi、Copacetic、Dalec、Flatcar、Headlamp、Inspektor Gadget。老實說，不是每個名字都跟每個團隊有關，但這串清單很有用，因為它直接把微軟眼中的真實工作地圖攤開來了。

重點不在某個炫的 agent app，而是在底下那堆 plumbing：runtime、observability、policy、patching、dashboard。這就是我會信的地方。因為只要你真的跑過 production，就知道最常出事的不是那個會講話的層，而是下面那些沒人想碰、但一斷就全倒的層。

實操寫法：你也可以照這個方式盤點自己的 stack。把依賴的上游專案列出來，然後標記它們屬於 runtime、policy、安全、觀測、部署哪一類。如果你沒辦法一次畫完這張圖，代表你的平台比你以為的還脆。

可抄的模板

# Agentic 平台藍圖：給開源團隊直接用的版本

## 1) 底層作業系統
- 使用精簡、強化過的 Linux 發行版做 node 與 container base image。
- 固定映像來源，並公開升級策略。
- 把 host OS 變更視為平台變更，不是應用團隊的小修小補。

## 2) 執行層
- 將 agent 執行與治理分開。
- 規劃、工具呼叫、狀態管理放在同一層。
- 身分、政策、稽核、存取控制放在另一層。

## 3) 互通性
- 要求 agent-to-agent communication 使用開放介面與標準協定。
- 除非能清楚轉譯，否則不要用供應商私有訊息格式。
- 文件要寫清楚 agent 如何跨框架、跨雲、跨語言移動。

## 4) 安全控制
- 所有 agent 產生的變更都要有 provenance。
- 記錄每次動作的 actor、tool、policy decision、timestamp。
- 高風險操作一律要人類審核。
- 部署前先跑 SBOM、依賴掃描、映像檢查。

## 5) 上游策略
- 優先選擇有活躍上游治理的專案。
- 修補要回饋上游，不要默默分叉。
- 依 runtime、policy、安全、觀測、部署五類維護依賴地圖。

## 6) 驗收清單
- 我能不能檢視它？
- 我能不能往上游貢獻？
- 我能不能在不重寫應用的情況下換掉它？
- 我能不能在事後稽核每一次 agent 動作？
- 多個 agent 能不能不用客製轉接器就互通？

## 7) 可直接貼進文件的 policy 範本

agent_platform:
  base_os:
    distro: hardened-linux
    image_source: pinned
    upgrade_policy: platform-managed
  runtime:
    execution: isolated
    governance: separate
    identity: required
    audit_logging: enabled
  interoperability:
    protocol: open_standard
    vendor_lock_in: avoid
    cross_framework_support: required
  security:
    provenance: required
    sbom: required
    human_approval_for_high_risk: true
    dependency_scanning: required
  upstream:
    prefer_open_governance: true
    contribute_back: true
    maintain_dependency_map: true

如果是我明天要推 agentic system，我會先拿這份模板去改，再把 placeholder 換成自己實際用的技術。重點不是照抄微軟的產品，而是抄它的操作邏輯：底層先硬起來、介面先開出來、治理先寫清楚、上游先顧好。

這種東西看起來不性感，但真的能活。對我來說，這比任何「AI 會改變一切」的口號都實在。

來源致謝：本文主要拆解自 Microsoft Open Source Blog 的 From open source to agentic systems: Microsoft at Open Source Summit North America 2026，以及文中連結到的 Semantic Kernel、AutoGen、Microsoft Agent Framework 等公開資料；上面的模板與白話拆解是我自己的整理與延伸。