2026 年 6 月 2 日，微軟 Responsible AI 團隊開源了 ASSERT（Adaptive Spec-driven Scoring for Evaluation and Regression Testing）框架：開發者用自然語言寫下系統該有的行為，它就自動生成測試情境、執行並計分。框架以 MIT 授權上架 GitHub，CLI 套件名為 assert-ai。
它鎖定的痛點，每個在出 AI 功能的團隊都遇過：實驗室有針對安全、合規、諂媚與對齊的通用評測，但公司真正要驗證的是「代理在我自己的產品情境裡有沒有守規矩」——這件事通用基準測不到。ASSERT 想把這件事從手工活變成例行公事。
什麼是 ASSERT
ASSERT 由微軟 Responsible AI 組織的產品、科學、工程與設計團隊打造，定位為「需求驅動」的評測工具。輸入不一定是精心撰寫的規格文件：可以直接指向產品需求文件（PRD）、威脅模型，甚至一次事故報告。使用時機覆蓋開發中、部署後與持續監控三個階段。
從文字規格到測試套件
流程可以拆成四步：開發者以高階自然語言描述目標、政策與行為邊界；ASSERT 把它轉成結構化的「可接受／不可接受行為」清單；接著生成問題情境與測試案例（含單輪與多輪對話），對目標系統執行；最後由 LLM 評審依政策對話評分。執行過程會記錄中間動作與工具呼叫路徑，讓你看得出「從哪一步開始出錯」，而不只是「錯了」。開發者也可以額外提供系統情境、工具與限制條件來客製評測。
TechCrunch 舉的例子很具體：一個文件研究代理不得寄信給公司外部人員、機密資訊只能提供給 C 級主管、摘要必須簡潔並保留前文脈絡——ASSERT 會針對每一條生成測試，驗證系統持續合規。
指標、沙箱與 CI 把關
ASSERT 回報兩個核心指標：「不可允許行為違規」（傷害面，代理做了絕不能做的事）與「可允許行為違規」（權衡面，該做而沒做好），把兩種失敗分開計分，避免一個總分蓋掉問題的性質。
整合面相當廣：透過 LiteLLM 支援超過 100 個模型端點；透過 OpenInference/OTel 追蹤接入 LangGraph、CrewAI、AutoGen 等代理框架；內建 Docker 沙箱，安全地測試高風險工具呼叫；附帶涵蓋安全、公平性與代理失敗模式的行為預設庫。評測產物是本地優先的 JSON/JSONL 檔案，附網頁檢視器，並提供 GitHub Action 在 CI 做回歸把關。入口有兩種：給 Claude Code、Copilot、Cursor 等編碼助理使用的引導式 skill，或手動 CLI。它甚至能在真實失敗的基礎上生成治理政策（ACS 步驟），再重跑評測量化改善幅度。
為什麼是現在
微軟 Responsible AI 產品長 Sarah Bird 講得很直白：「我們學到的一件事是，評測對做出好決策絕對關鍵。」不了解系統行為，「就很難知道它有沒有達到組織的標準」，而可信賴的系統需要在「更多維度」上做應用層級的評測。
背景是整個產業正轉向可重複測試與回歸檢查：Stanford 的 HELM、MLCommons 的 AILuminate 與 METR 的評測撐起公共基準那一側，ASSERT 補的是應用這一側。repo 說明其方法沿用 Agarwal 等人 2026 年的論文，管線設計則參考 Anthropic 開源的 Bloom 與 Petri 行為評測框架。
對開發者的實際意義
三個實際影響。第一，行為驗證左移：開發期就用規格生成測試，而不是上線後靠客訴才發現代理寄錯信。第二，評測產物是檔案：JSON/JSONL 加上 CI gate，讓「代理還守不守政策」變成可 diff、可 review 的檢查項。第三，它補充而非取代公開基準：通用評測回答「模型好不好」，ASSERT 回答「它在我的產品裡守不守規矩」——兩層都需要，而後者一直最缺順手的工具。
參考來源
- New Microsoft tool lets devs spin up AI behavior tests using text descriptions — TechCrunch
- responsibleai/ASSERT — GitHub
- AILuminate — MLCommons
本文由 AI 協助自上述來源整理，經人工審核後發布。