Cloudflare 開放 MoQ Relay 佈建 API，讓開發者自架隔離式即時媒體轉發節點
Cloudflare Engineering Blog · 2026-07-31
背景：什麼是 MoQ
MoQ（Media over QUIC）是 IETF moq 工作小組正在制定的開放標準，全名協定草案為 draft-ietf-moq-transport-19，隸屬於 Apps & Realtime（ART）領域。它的核心概念是一個跑在 QUIC／WebTransport 之上的 publish/subscribe 協定，發布端把資料切成具名的 track，由中繼站（relay）轉發給訂閱端，relay 本身不需要解析內容即可完成 fan-out。因為建立在 QUIC 之上，MoQ 能利用多路串流、datagram、優先權與部分可靠傳輸等特性，讓直播影音、視訊通話、即時訊息等場景取得比傳統 RTMP／HLS 更低的延遲。
在這次公告之前，Cloudflare 只提供一個無驗證的公開測試端點，任何人都能連上去 publish 或 subscribe，這對正式環境完全不適用——因為沒有辦法限制誰能發布、誰能訂閱，也就無法做到內容隔離與存取控管。
核心改動：Relay 佈建 API
Cloudflare 這次推出的佈建 API（Provisioning API）讓開發者可以在 Cloudflare 全球網路上建立彼此隔離的 relay 實例，並各自簽發專屬 token。主要能力包括：
- 建立獨立的 relay 命名空間（namespace），避免不同應用的串流互相混雜
- 為發布端與訂閱端分別核發 token，設定
publish、subscribe或兩者皆可的權限 - 為 token 設定到期時間，並可個別撤銷
- 透過 Anycast 端點即時部署，不需選擇區域或規劃容量
技術上，佈建出來的 relay 並非獨立的 VM 或 container，而是在既有基礎設施上開出的隔離 scope（類似虛擬主機的概念），因此建立速度接近即時。呼叫方式是標準 REST API：
curl -X POST \
"https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/moq/relays" \
-H "Authorization: Bearer $API_TOKEN" \
-d '{"name": "Production Relay"}'回應會附上 relay 的 UID，以及預設產生的 publish+subscribe 與 subscribe-only 兩組 token。實際收送資料則交給開源工具 moq-rs，發布端範例如下：
ffmpeg ... | moq-pub --name my-namespace \
"https://draft-16.cloudflare.mediaoverquic.com/<token>"規格細節：draft-14 與 draft-16 的差異
Cloudflare 目前同時支援 draft-14 與 draft-16 兩版協定草案（IETF 標準草案本身已推進至 draft-19，Cloudflare 尚未跟進到最新版）。draft-16 新增了兩個對應用開發者有感的訊息型別：PUBLISH 讓發布端可以在還沒有任何訂閱者出現前就先送出 track，SUBSCRIBE_NAMESPACE 則允許訂閱端一次訂閱某個命名空間底下的所有 track，未來新增的 track 也會自動涵蓋在內，不必逐一訂閱。佈建模型本身則參考了另一份草案 draft-englishm-moq-cdn-provisioning，說明 relay 應如何被 CDN 業者佈建與管理。
影響範圍
這個 API 目前處於 beta 階段，免費使用且未公告結束日期，可透過 REST API 或 Cloudflare Dashboard（Media > Realtime > MoQ Relay）操作。對需要低延遲直播、多方視訊或即時協作應用的團隊而言，這代表不必再依賴 Cloudflare 的公開測試端點，也不必自建跨區域的 relay 集群，就能取得具備存取控管的正式環境基礎設施。由於 MoQ 協定本身仍在 IETF 草案階段快速演進，採用者需留意 Cloudflare 的實作版本（draft-14／draft-16）與最新草案（draft-19）之間可能存在的行為差異。
原始來源：Cloudflare Blog: An API for MoQ、IETF draft-ietf-moq-transport
Microsoft Agent Framework 的 Harness 正式釋出，補齊 Agent 的執行骨架
Microsoft Agent Framework Blog · 2026-07-31
背景：什麼是 Agent Harness
語言模型本身只能生成文字，若要讓它具備呼叫工具、維持記憶、持久化執行狀態、進行多步驟規劃等能力，需要一層額外的骨架把模型包裝成真正能自主運作的 agent，這層骨架就是所謂的 agent harness。Microsoft Agent Framework 團隊在 7 月 22 日的部落格文章中，由 Principal Software Engineer Wes Steyn 宣布 Harness 功能正式釋出（GA），文章標題稱其為「an agent harness is the scaffolding that turns a language model into an agent」。
核心改動：Harness 提供的能力
Harness 是一套開箱即用（batteries-included）的執行環境，把 chat client 包裝成一個完整的 agent pipeline，鎖定的場景是自主、長時間運行的任務。它內建的功能包括：
- 可設定迭代上限的 function invocation（工具呼叫）
- 每次 service call 都做歷史持久化，支援當機後復原
- context window 管理（自動壓縮對話歷史）
- 透過 todo list 與 mode provider 做規劃與執行追蹤
- file memory：跨 session 保存筆記
- skills discovery：載入打包好的領域知識
- 網頁搜尋整合
- 工具核可機制（standing rules ＋ 啟發式自動核可）
- 內建 OpenTelemetry 遙測
從版本歷程來看，這次 GA 是一步步從 experimental 走到 stable：Python 套件 agent-framework 在 1.11.0（7 月 10 日）先加入 harness agent 的訊息注入 middleware，1.12.0（7 月 21 日）才把 create_harness_agent 從 experimental 畢業為 stable，並把 FileAccessProvider 改為 harness agent 的選配項目。.NET 對應的 Microsoft.Agents.AI 套件則在 1.14.0（7 月 21 日）將 HarnessAgent 標記為 [BREAKING] 畢業變更。截至 7 月 30 日，最新版本為 Python 1.13.0、.NET 1.16.0。
規格細節：程式碼與範例位置
官方在 Python 與 .NET 都提供了最小化範例，開發者只需提供 instructions 與自訂工具，其餘的迭代、記憶、狀態管理都交給框架處理。範例程式碼分別放在 GitHub 倉庫的 /python/samples/02-agents/harness 與 /dotnet/samples/02-agents/Harness 目錄下，文件則收錄在 Microsoft Learn 的 Agent Harnesses 章節。
值得注意的是，並非所有功能都已 GA：background agents、file access tools、looping automation、shell tooling 目前仍標示為 preview，使用時框架會顯示警告訊息，代表 API 介面未來仍可能調整。
影響範圍
對正在用 Microsoft Agent Framework 建置 agent 應用的團隊來說，Harness GA 代表可以把原本各自手刻的工具呼叫迴圈、狀態持久化、上下文壓縮等重複邏輯，換成官方維護且有明確版本號的元件。由於 .NET 端的 HarnessAgent 畢業伴隨 breaking change，已在用 preview 版本的專案升級時需要檢查介面異動；Python 端則相對平滑，主要是把呼叫方式從 experimental API 換成正式 API。
原始來源：Microsoft Agent Framework Blog: Harness is now released、GitHub: microsoft/agent-framework Releases
Google Gemini Enterprise Agent Platform 的 Agent／Model 評測功能正式 GA
Google Developers Blog · 2026-07-31
背景：什麼是 Agent／Model Evaluations
在 agent 開發流程中，「evaluation（評測）」指的是用一套一致的量化指標，去衡量某個 agent 或底層模型在特定任務上的表現，藉此比較不同版本或不同模型的優劣，而不是靠肉眼抽查對話紀錄。Google 這次宣布 Gemini Enterprise Agent Platform 的 Agent and Model Evaluations 功能正式 GA，讓開發流程與正式環境都能用同一套指標追蹤品質。
核心改動：評測指標與框架
平台內建超過 20 種現成指標，涵蓋三個層級：
- 計算式指標：摘要用
ROUGE、翻譯用BLEU／MetricX／COMET、問答用 exact match - 適應式評分規則（adaptive rubrics）：針對 Task Success、Tool Use Quality、Safety、Hallucination、Grounding 等維度做 case-specific 的 pass/fail 判定
- 自訂指標：可寫 Python 函式，或以 LLM-as-a-judge 方式註冊自訂的
custom LLM metric
開發階段的核心是實驗框架（Experiment Framework），支援本機與伺服器端兩種執行模式，並與三個子系統整合：case generation 用來自動產生評測資料集雛型、user simulator 可以在不寫死每一句對話的情況下模擬多輪互動、environment simulator 則用來替代 agent 實際呼叫的外部系統，讓評測不需要真的打到正式服務。
規格細節：正式環境的持續監控
GA 的另一個重點是正式環境的線上評測（online evaluation）：可以直接對正式流量做連續評測，產生 score-over-time 圖表並在指標下滑時觸發 drift alert，不需要另外自建資料管線。開發者可以透過以下任一入口使用這些能力：
- Agent Platform SDK（
evaluation-genai-sdk教學） - REST API
agents-cli命令列工具- ADK（Agent Development Kit）框架
- Evals Worksheet 網頁介面
計費方式沿用既有規則：使用 LLM 作為評分依據的指標會依標準模型呼叫費率計費，另加上儲存產出物用的 Cloud Storage 費用；純計算式或程式碼型指標則不額外收費。
影響範圍
對已在用 Gemini Enterprise Agent Platform（前身包含 Vertex AI Agent Builder 系列工具）building agent 的團隊來說，GA 代表可以把評測納入 CI 流程，在每次改動 prompt 或換模型時用同一組指標比較效果，而不必自己維護一套評分腳本。由於 online evaluation 直接掛在正式流量上，對於已上線且需要長期追蹤品質衰退（drift）的 agent 應用尤其實用，可及早透過 drift alert 發現模型或使用情境變化造成的表現滑落。
原始來源：Google Developers Blog: Agent and Model Evaluations GA、Google Cloud Docs: Agent and model evaluations