Cloudflare 推出 Cache Response Rules，在回應階段修正來源站送錯的快取標頭
Cloudflare Blog · 2026-07-23
Cloudflare 於 2026-07-23 發表 Cache Response Rules，鎖定一類長期無解的快取問題：許多快取失效並非請求端能處理，而是要等來源伺服器回應之後才會顯現。文章開宗明義：「來源站主導快取行為……如果來源站設錯了,快取就只是裝飾品。」
原本的問題
常見的來源站失誤包括：靜態資源（.js、.css 等）被夾帶了不必要的 Set-Cookie 標頭而無法被快取、來源對本可快取的內容送出 Cache-Control: no-cache、過度激進的 ETag 造成不必要的重新驗證，以及原本設計給瀏覽器的快取指令被誤用在 CDN 層。這些問題「都無法在請求階段解決」，因為問題根源在回應內容本身。
採用的方法
Cache Response Rules 運作在一個新的回應階段——來源站已經回應、但內容尚未進入 Cloudflare 快取之前的時間點。支援三種動作：
- 剝除阻擋快取的標頭（
Set-Cookie、ETag、Last-Modified） - 管理快取標籤（轉換 surrogate key，或增刪標籤以支援依標籤清除快取）
- 改寫
Cache-Control指令，並可用cloudflare_only旗標讓瀏覽器快取時間與 CDN 快取時間脫鉤
實際效果
功能已對所有方案開放，可透過 dashboard 或 /zones/{zone_id}/rulesets/phases/http_response_cache_settings/entrypoint API 設定。官方舉的典型案例：靜態資源被 session middleware 意外夾帶 Set-Cookie 導致完全無法快取，過去只能改來源程式碼，現在直接在邊緣剝除該標頭即可讓內容變成可快取。
微軟 Agent Framework Declarative Workflows 1.0：多代理編排從程式碼搬進 YAML
Microsoft DevBlogs · 2026-07-23
微軟 2026-07-23 宣布 Python 與 .NET 兩個 SDK 的 Agent Framework Declarative Workflows 同步達到 1.0 穩定版——agent-framework-declarative（Python）與 Microsoft.Agents.AI.Workflows.Declarative（.NET）套件，讓多代理系統的編排邏輯改用 YAML 設定檔描述，不再寫死在應用程式碼裡。
原本的問題
傳統多代理應用把代理呼叫順序、分支邏輯、交接規則等編排細節直接寫進程式邏輯，這讓工作流程難以審閱、難以版本控管，任何調整都得改程式碼、跑測試、重新部署，非開發人員完全無法參與流程調整。
採用的方法
Declarative Workflows 把編排邏輯與商業邏輯分離。官方範例是一個支援台前的路由工作流程：
kind: Workflow
trigger:
kind: OnConversationStart
id: support_router
actions:
- kind: InvokeAzureAgent
id: triage
conversationId: =System.ConversationId
agent:
name: TriageAgent依照分類結果有條件地呼叫對應的專家代理，整段路由邏輯完全用 YAML 宣告，不需要改動應用程式主體。
實際效果
官方強調宣告式工作流程可以「與程式碼優先（code-first）方案一樣執行、串流與組合」，沒有效能折損。這與同週 HashiCorp 把 Terraform 編排收攏進 Stacks、Docker 主張執行期治理是同一個方向：把原本散落在程式碼或腳本裡的編排與治理邏輯，收攏成可審閱、可版本控管的宣告式設定。