Cloudflare 推出了用于监控 Cloudflare Workers 内部错误的 Issues 功能，目前已开放公开测试。该功能会将反复出现的失败汇总为一个问题，然后允许将其详细信息发送给编程代理，以继续调查、提出修复方案并创建拉取请求。
Cloudflare 针对的是生产故障处理流程中的一个实际缺口：代理能够查询监控数据、浏览代码仓库、编写测试并修改代码，但串联这些步骤仍需要人工介入，以收集日志和追踪信息，并确认多个失败是否由同一个故障引起。
Issues 监控什么？
该功能在 Workers 环境内部运行，不要求安装 SDK 或为应用添加包装层。启用后，它会记录未处理的异常、失败的调用、5xx 类 HTTP 响应，以及 console.log() 和 console.error() 的输出，还会记录包含调用栈的日志。此外，它还会监测告警触发反复发生以及在循环中写入大量日志的情况。
Issues 不会将每个失败请求作为独立状态展示，而是汇总相似错误，并说明其首次出现时间、发生次数以及发生率是否正在上升。它会展示问题、可用时显示调用栈、之前和之后的日志与追踪信息、Worker 版本、请求详情以及问题随时间的趋势。
为调查添加应用上下文
开发者可以使用 Workers 环境中内置的 OpenTelemetry 接口，附加用户、账户和会话等标识符。这些数据会与每个 occurrence 一同显示，从而帮助确定故障是否集中在某个特定账户或会话中，然后再将其发送给代理。
从监控面板到编程代理
可以配置 Automation，在问题出现次数超过特定阈值或在一段平静期后再次出现时触发发送。Cloudflare 支持通过 routine ID 和 token 连接 Claude Code，通过 webhook 地址连接 Cursor，以及通过 API token 和组织标识符连接 Devin，此外还支持通用 webhook、聊天系统和事件管理系统。
发送的上下文包括失败摘要、异常、与源代码关联后的调用栈、日志和追踪信息、Worker 版本，以及开发者添加的应用上下文。为了开展更深入的调查，还可以单独将代理连接到 Cloudflare MCP，以查询相关日志和追踪信息，提出代码和测试修改建议，并创建拉取请求。
实际会发生什么变化？
Issues 减少了从发现故障到调查故障之间的手动步骤，但不会使修复完全自动化。拉取请求的审核、变更的部署以及将问题置于已解决状态，仍由团队掌控。此外，结果质量取决于应用添加的上下文以及所选择的运行设置和阈值。
Cloudflare 在 Workflows 上测试了该功能。Workflows 是一种基于 Workers、面向长时间运行和多步骤应用的组件。在一天之内，自动化发现了两个问题：控制平面迁移期间因与外键相关的 SQLite 错误导致的重试循环，以及由于超过 Workers 子请求限制而未完成的删除操作。自动化将这两个问题发送给了 Cloudflare OS，后者追踪了 Workflows 代码中的错误并提出了两项修复方案。
要开始使用，必须在 wrangler.jsonc 文件中启用 observability.issues.enabled，然后从 Cloudflare 面板设置第一个 Automation，以选择问题的目标，可以是代理、webhook、事件管理工具或聊天平台。