微軟工程團隊提出 Agentic AI 驗證框架:分級查核取代人工全文審查
Microsoft DevBlogs · 2026-08-29
微軟 Azure 工程團隊在 8/29 發布的文章中,針對應用程式現代化(尤其是 COBOL 遷移)場景提出一套agentic AI 輸出驗證框架。文章舉的例子是:一個 agent 在五分鐘內產出超過 2,500 字的 COBOL 逆向工程文件,人類專家實務上只能抽查開頭幾段,中段到結尾是否有幻覺、誤解或遺漏,完全無從得知。
原本的問題
團隊將 agentic AI 輸出的失敗模式歸納成三種:遺漏(miss,內容技術上沒有錯但不完整)、幻覺(hallucination,講得煞有其事但其實是假的)、以及誤解(misinterpretation,指令含糊導致 agent 交出方向錯誤的結果)。這三種模式的共通點是輸出看起來都「很合理」,單靠人工閱讀很難分辨。
核心問題在於產出速度與查核速度的落差——agent 生成內容的速度遠超過人類逐字驗證的速度,傳統「找專家 review 一下」的品質保證方式在這種規模下已經失效。
採用的方法
框架把驗證工作拆成三個角色:人類(領域知識)、AI(模式辨識)、決定性工具(deterministic tools,結果可重現)。三者兩兩配對都各有侷限,因此任何一項品質檢查都必須明確回答六個問題:檢查什麼、建置成本多少、誰來執行、能證明什麼、產出什麼具體結果、有哪些現成工具可用。
文章給出兩條分級查核路徑,一條是逆向工程(0a/0b 到 5 級,從實體完整性一路到正式環境的執行追蹤比對),一條是程式碼生成(0a-c 到 6 級,從編譯、linting、資安掃描一路到 shadow run)。
| 層級 | 逆向工程驗證 | 程式碼生成驗證 |
|---|---|---|
| 0 | 實體完整性、文件規範 | 編譯、linting、資安掃描 |
| 1-2 | 專家確認(範圍逐步擴大) | 單元測試、整合測試 |
| 3+ | 正式環境執行追蹤比對 | 資料驗證、效能 SLA、shadow run |
其中一條硬性原則是:沒有產出具體結果的檢查不算檢查。人工 review 若只給「看起來沒問題」這種評語,不構成有效的驗證紀錄,必須產出像「已標註的商業規則清單」這種可追溯的產出物。文中提及的落地工具包括 SonarQube、AppCAT、COBOL-REKT、CAST 做逆向工程與程式碼品質掃描,以及 JUnit/pytest/Jest、Testcontainers、WireMock、k6、Playwright 等測試與監控工具鏈。
實際效果
這篇文章延續同團隊今年稍早發布的應用程式現代化現況分析,當時的結論是 agentic AI 不會自動完成現代化,只是把人力從「動手改」轉移到「訂規格與審核」。這次的驗證框架把那個結論具體化成可執行的分級查核表——重點不在於用更強的模型減少幻覺,而是先承認幻覺一定會發生,再設計出能攔住它的分層機制。
原始來源:Only believe what you can validate、The realities of application modernization with agentic AI
EVE Online 啟動 Python 3 遷移:240 萬行 Stackless Python 程式碼的十六年包袱
CCP Games (Fenris Creations) · 2026-08-25
CCP Games(現以 Fenris Creations 名義營運)在 8/25 於官網公告,EVE Online 伺服器端程式碼開始從 Python 2.7 遷移到 Python 3,初步變更已部署到正式伺服器 Tranquility。EVE Online 自 2003 年上線就跑在 Stackless Python 上,2010 年切到 2.7 之後就再也沒升級過語言版本,一停就是十六年。
原本的問題
這次要動的是240 萬行、約 20,000 個檔案的伺服器程式碼,涵蓋跳蟲洞、市場掛單、艦隊戰鬥等所有遊戲內系統,而且是建立在 Stackless Python 之上——這是用 tasklet 取代 thread 的輕量併發變體,單一伺服器節點才能同時撐起數千條連線。團隊盤點後把問題分成兩類。
| 問題類型 | 行數 | 說明 |
|---|---|---|
| 語法層級阻擋 | ~3,300 行 | 無法直接在 Python 3 解析 |
| — 舊式 print 陳述式 | ~1,500 行 | print x 型態 |
| — long 型別字面值 | ~800 行 | 如 123L |
| — 舊式 except 語法 | ~600 行 | except E, e: |
— <> 運算子 | ~50 行 | Python 3 已移除 |
| 行為差異 | ~20,000 行 | 兩版都能編譯但執行結果不同 |
行為差異這一類更麻煩,因為程式碼在 Python 2 和 3 下都能編譯通過,卻可能跑出不同結果,只能靠人工逐行檢視。團隊舉的典型例子是整數除法:1 / 2 在 Python 2 回傳 0,在 Python 3 回傳 0.5。在 EVE 裡,這類運算可能對應到傷害計算、貨幣或座標,算錯不會噴例外,只會悄悄跑出錯的數字。
採用的方法
遷移策略分兩個階段。第一階段先讓程式碼同時相容 Python 2.7 與 Python 3,不改變現有 2.7 的執行結果;第二階段才處理前述兩萬行行為差異,需要人工介入確認。工具鏈上混用官方 2to3 與 Python-Future 的 Futurize 做自動化改寫,外加內部客製工具處理 EVE 特有的模式。
Futurize 本身也分兩階段跑:stage1 只做不破壞 Python 2 相容性的「安全」修正(例如把 except E, e: 轉成 except E as e:、print 陳述式轉成函式呼叫),stage2 才引入 future 套件讓程式碼寫成 Python 3 風格但仍能在 Python 2 上跑。每一輪自動改寫後,團隊會用真正的 Python 2.7 與 Python 3 直譯器分別編譯驗證,而不是只信任工具輸出。
# Python 2 (原始)
except Exception, e:
print "damage:", dmg / 2
# Python 3 相容寫法(第一階段目標)
except Exception as e:
print("damage:", dmg / 2) # 注意: dmg/2 在 py2/py3 行為不同,列入第二階段複查
實際效果
社群測試已於 2026 年 7 月在測試伺服器 Singularity 上進行,8/25 起初步變更正式上線到 Tranquility。團隊也提到姊妹作 EVE Frontier 已完成 Carbon 引擎的 Python 3 遷移,證明這條路線可行。官方對這次遷移的成功定義很低調:「除了偶爾感覺跑得比較順之外,玩家應該完全不會注意到任何變化」,任務後端(agent mission backend)也已在為後續遷移做準備。