微軟如何以 AI 代理人重構軟體開發生命週期
Microsoft Developer Blog · 2026-06-25
背景
微軟在 2026 年 6 月 25 日發布工程策略報告，公開其內部「Customer Zero」計畫的執行細節。整個轉型核心是從「軟體工廠」轉向「AI 與代理人工廠」，以代理人工作流程重新定義規劃、開發、安全、維運到現代化的五大環節。超過 90% 的微軟開發人員已在日常工作中使用 GitHub Copilot。
核心改動
微軟將工程工作分為四個前沿目標：以代理人工作流程重新架構軟體生命週期、讓開發人員與代理人並肩協作、將安全與合規內建到工程平台，以及建立高生產力的開發者體驗。關鍵策略是把「模糊需求」轉化為「明確意圖」，以規格（specification）作為單一事實來源，再由代理人負責產生程式碼、PR、安全修補與框架升級。
在 PR 層面，90% 的 PR 已由 AI 代碼審查覆蓋，完成速度提升逾 10%。針對 SDK 遷移任務，專用代理人在數百個儲存庫中達到 80–90% 的自動化準確率，減少了 55% 的人工開發負擔。
規格細節
報告揭露三個落地案例：Azure SRE Agent 自動化處理維運事件調查與補救流程，累計節省超過 50,000 開發人員小時；1ES Security 以代理人進行大規模安全合規掃描；Azure Networking Operations 以 AI 代理人替代部分人工網路事件處理流程。三個案例均強調代理人承接的是重複性、低差異化工作，而非取代工程決策。
影響範圍
調查顯示 62% 的開發人員回報工作滿意度提升，88% 表示任務吞吐量增加。這份報告被微軟定位為可供外部組織參考的工程轉型藍圖，明確點出「從 undifferentiated code 到 unambiguous intent」是代理人化工程的核心路徑，而非單純導入 AI 工具。
Aura Frames 如何以 8 個 PostgreSQL 主庫撐過每小時 4100 萬請求的聖誕尖峰
andyatkinson.com · 2026-06-26
原本的問題
2024 年聖誕節，Aura Frames API 因 RDS PostgreSQL 14.1 的複製槽（replication slot）設計導致 WAL 日誌無限累積、Dedicated Log Volume 爆滿，造成長達三小時的斷線。單一主庫規格已達 db.r7i.48xlarge（192 vCPU、1.5 TB RAM），垂直擴展已觸及 AWS RDS 天花板，無法再透過升級機型解決問題。
採用的方法
工程團隊選擇「整表水平切分」（whole-table sharding）：將寫入量最高的 10 張資料表分散到 7 個新主庫，合計 8 個 PostgreSQL 主庫，各庫保持相同 schema，並透過實體複製（physical replication）完成資料遷移，資料庫版本同步升級至 PostgreSQL 17.6。
Rails 層面的核心改動是啟用 disable_joins: true（Rails 7.0 新增），將跨庫 JOIN 自動拆解為多次 SELECT。所有跨庫 scope 合併與 has_and_belongs_to_many 關聯都必須重構為 has_many :through 才能支援此模式。讀取優化採用 keyset pagination 取代 LIMIT/OFFSET，寫入優化透過 upsert_all() 的 :on_duplicate 參數執行批次 upsert。
快取層以 Memcached 加 HAProxy 處理每用戶計數器與環境變數；本地開發以單一 Docker PostgreSQL 容器模擬 8 個獨立 schema，確保跨庫邊界檢查在開發階段即可執行，避免問題推遲至生產環境才被發現。
實際效果
2025 年聖誕節尖峰期間達到每小時 4,100 萬 HTTP 請求（約 11,400 req/s），全庫峰值達 226,000 TPS，平均查詢時間 25 微秒，持續維持 10 萬 TPS 以上超過 10 小時，Aura Frames 同期登上美國與加拿大 App Store 排行榜第一名。
原始來源：andyatkinson.com（Part 2）、PostgreSQL Scaling Retrospective（Part 1）
Dropbox 如何以 DSPy 讓 AI 評測訊號直接驅動 Dash Chat 回答品質
Dropbox Engineering · 2026-06-25
原本的問題
Dropbox Dash chat agent 的回答品質依賴人工評測，規模有限且難以系統化。LLM 評測者（judge）與人類評分之間的偏差問題無法解決，評測訊號便無法有效回饋給 agent 做自動化改善，手動調整提示（prompt）既耗時又難以跨模型遷移。
採用的方法
工程師以五個維度評估 agent 回答：使用者意圖對齊、語意相關性、工具使用、指令遵循、上下文選取，人工評測者以 1–5 分打分並記錄失敗原因代碼。接著使用 DSPy 框架的 GEPA 與 MIPROv2 優化算法進行兩階段自動化：第一階段以人工標注樣本校準 LLM judge，使評分分布對齊人類判斷；第二階段將校準後的 judge 評分作為訊號，自動優化 chat agent 的系統提示。
GEPA 針對每個模型分歧樣本生成結構化回饋，包含分差大小、方向與推理依據，再透過迭代精煉提示。整個流程形成閉環：人工標注改善 judge，judge 提供可擴展的評測訊號，評測訊號再改善 agent。切換底層模型時只需重新跑優化流程，無需人工重寫提示。
實際效果
部署後，不完整回答減少 26%，遺漏關鍵資訊的比例下降 13%，token 用量降低 5.4%，平均回答長度縮短 9.8%，整體品質未因精簡而下滑。此方法的核心優勢在於：評測者校準與 agent 提示優化均以相同的 DSPy 框架實作，系統化的優化循環取代了憑直覺手動調整提示的工作模式。