Cloudflare 於九月三十日宣布，為 Workers 內建錯誤監控功能 Issues 並進入公開測試：可把重複例外、五字頭回應與錯誤日誌自動歸組成單一問題，並把堆疊、日誌、追蹤與 Worker 版本一併送到已設定的編碼代理。官方稱自家 Workflows 團隊啟用後一日內發現並修復兩個生產缺陷。來源真實性已核對 Cloudflare 官方博客與開發者文件。

對正在把無伺服器工作負載與編碼代理串起來的香港與亞洲團隊，重點在於「可觀測性與修復閉環」：少了結構化交接，代理只能在原始遙測裡自行拼湊脈絡；Issues 把這段人工缺口產品化。

Cloudflare／官方：Workers 推出 Issues 公開測試——錯誤自動歸組並直送編碼代理；一日內自修兩個 Workflows 缺陷

Cloudflare 於二零二六年九月三十日在官方博客發布〈Detect and send production issues straight to your agent〉，推出 Workers 運行時內建的 Issues（公開測試）。功能可將重複例外、失敗調用、HTTP 五字頭回應與含堆疊的日誌歸組為單一「問題」，並經 Automations 把診斷脈絡送到 Claude Code、Cursor、Devin 或通用 webhook。官方以自研 Workflows 服務為例，稱啟用當日即發現遷移重試迴圈與刪除流程未完成兩類缺陷並完成修復。本文已核對官方博文與 developers.cloudflare.com 可觀測性文件，來源真實性已驗證。

一、核心事件：從遙測到代理修復的結構化交接

技術細節

官方指出，編碼代理已能查詢可觀測資料、瀏覽程式庫、改碼、寫測試並開拉取請求，但「辨識同一缺陷的重複失敗 → 收集相關日誌與追蹤 → 交給代理 → 驗證修復是否生效」仍多靠人手。Issues 目標是把這段交接產品化。

啟用方式為在 Wrangler 設定把 observability.issues.enabled 設為 true；Issues 建於 Workers 運行時，無需額外 SDK 或應用包裝。啟用後會記錄未捕捉例外、失敗調用、HTTP 5xx、console.log／console.error 輸出，以及含堆疊的日誌，並可標示失控的 alarm 與迴圈內大量寫日誌等情況。

同一缺陷在不同請求上會有不同 request ID，但根因相同；Issues 將它們歸組，並顯示首次出現時間、發生次數與是否加劇。開啟單一問題時可見錯誤、（如有）原始碼對映堆疊、前後日誌與追蹤、Worker 版本、請求細節與趨勢。

應用層脈絡方面，Cloudflare 可捕捉 Worker 內發生之事，但不知哪些用戶、帳戶或工作階段對業務重要。開發者可用運行時內建 OpenTelemetry API（cloudflare:workers 的 tracing）為作用中 span 加上 user.id、account.id、session.id 等屬性，這些識別碼會隨每次發生一併出現，方便判斷失敗是否集中於單一帳戶或工作階段，再交代理處理。

Automations 可依發生次數門檻或「沉寂後再現」觸發，目的地包括：內建編碼代理（Claude Code 需 routine ID 與 token；Cursor 需 automation webhook URL；Devin 需 API token 與 organization ID）、通用 HTTPS webhook，以及聊天／事故管理通知。送出內容含失敗摘要與診斷脈絡（例外、錯誤、原始碼對映堆疊、前後日誌與追蹤、Worker 版本與自行加入的應用脈絡）。更深調查可另接 Cloudflare MCP，讓代理查相關日誌與追蹤後提出程式與測試變更並開拉取請求；上線與否仍由人審核。

二、技術原理深度解析

Issues 本質是把「錯誤訊號 → 歸組 → 豐富脈絡 → 觸發代理工作流」做成平台能力，而不是再塞一個僅供人看的儀表板。歸組解決告警疲勞：數千筆不同 request ID 的失敗若各自跳票，人與代理都會被噪音淹沒；合併成單一問題後，代理才有穩定的調查單位。

內建於運行時、零 SDK，降低「忘記埋點就看不見」的導入摩擦，但也意味著覆蓋範圍綁定 Workers 執行模型——非 Workers 負載仍需其他可觀測堆疊。OpenTelemetry 屬性則補上業務語義：沒有用戶／帳戶維度，代理容易把平台層錯誤與單一租戶資料問題混為一談。

官方自述的 Workflows 案例說明價值假設：控制平面遷移在邊角情況反覆撞上 SQLite 外鍵錯誤；刪除 Workflow 實例時在邊角情況超出 Workers 子請求上限而無法完成。兩案都藏在大量流量裡，靠自動化把問題直送 Cloudflare OS（其內部代理／工具鏈）並提出修復。這驗證「生產缺陷 → 代理」路徑在自家系統可行，但對外客戶仍須自行設定 Automations、代理權限與拉取請求審查政策。

對防禦與營運而言，應同步思考：誰能配置「直送代理」、代理可否寫入生產分支、敏感日誌是否進提示詞，以及誤報導致的無意義拉取請求成本。Issues 縮短平均偵測與調查時間，並不自動等於可無人值守上線。

四、日常應用場景

1. 開發者與技術團隊

在 Workers／Pages Functions 專案打開 Issues，並為暫存或正式環境設發生次數門檻；先接到聊天頻道作人審，穩定後再接到 Cursor 或 Claude Code 例行工作流。對編碼代理自動開的拉取請求，強制要求測試與人工合併，避免「代理修好又引入回歸」。

2. 企業與隱私敏感行業

金融、醫療與政府相關系統若在邊緣執行身份或交易邏輯，應在送代理前以屬性與日誌紅線過濾個資與机密；優先保留錯誤類型、版本與匿名化帳戶雜湊。事故管理工具可與 webhook 並接，讓值班與代理調查平行進行。

3. 一般用戶

終端用戶不會直接操作 Issues，但會感受到「缺陷更快被定位與修復」。對使用建於 Workers 上的應用而言，平台可觀測性提升有助縮短故障窗口；使用者仍應透過官方狀態頁與應用內通知了解服務狀況。

4. 香港與亞洲市場視角

香港金融科技、電商與 Sabre／自建 API 閘道團隊日益採用邊緣運算與編碼代理。Issues 這類「生產訊號回流代理」能力，與本地對資料出境、日誌留存與變更審批的合規期望需一併設計：代理可在香港或指定區域的開發環境提案，合併與部署仍走既有變更管理。亞洲多時區值班亦可把夜間重複五字頭自動交代理起草修復、日間工程師覆核，降低跟進延遲。

五、專業評價與潛在考量

優勢

官方產品、運行時內建，導入成本低於另架錯誤監控再手抄堆疊給代理。
歸組與 Automations 直送代理，對準代理編程時代真正的營運瓶頸。
以自家 Workflows 一日兩缺陷作存在證明，敘事具體。
支援主流編碼代理與通用 webhook，避免單一供應商鎖定於通知層。

需要留意的地方

仍為公開測試，行為、配額與計費細節以官方文件後續更新為準。
Issues 協助發現缺陷，並不取代發布紀律、金絲雀與回滾；代理提案仍須測試與人工合併。
直送代理放大提示詞注入與敏感遙測外流風險，需權限最小化與審查閘道。
非 Workers 堆疊無法單靠此功能覆蓋；多雲企業仍需統一事件模型。

結語

Cloudflare 把 Workers 的錯誤監控做成「可交給編碼代理的問題物件」，標誌無伺服器平台與代理工作流正在收斂成同一條營運閉環。對香港團隊而言，現在就盤點邊緣工作負載的可觀測性設定、代理自動化邊界與拉取請求審查，比等到告警爆炸再人手貼堆疊更實用。

若需要在香港落地私有化大語言模型、編碼代理工作流或企業 AI 自動化，可參考 YSK Limited 的私有 LLM 與 AI 自動化服務（資料可留港、年費方案官網刊起）：https://ysk.hk/services/ai-automation

參考來源

Cloudflare, “Detect and send production issues straight to your agent”, 2026-09-30 — https://blog.cloudflare.com/real-time-issue-detection/
Cloudflare Docs, Workers Observability — Issues — https://developers.cloudflare.com/workers/observability/issues/
YSK Limited 私有 LLM 與 AI 自動化 — https://ysk.hk/services/ai-automation