Cloudflare Workers 新增 Issues 功能:检测并直接将生产问题发送给 Agent
Detect and send production issues straight to your agent
Cloudflare Workers 新增了 Issues 功能,可自动检测生产错误并将完整上下文发送给 Agent,帮助快速定位并修复问题。
Issues 能将重复异常、5xx 响应和错误日志聚合为单一问题,并通过 Automations 将错误摘要、堆栈、日志、跟踪及 Worker 版本推送给配置好的 Agent。
文章阐述 Cloudflare Workers 新增的 Issues 功能,说明如何将错误自动推送给 Agent 并通过自动化流程快速定位并修复问题,并在部署前进行差异检查,确保修复安全。
随着智能体(agent)协助我们构建更复杂的应用程序,人类和智能体都需要更好的方式来掌控生产环境中出现的问题。编码智能体已经能够查询可观测性数据、浏览代码库、修改代码、编写测试并提交拉取请求(pull request)。目前仍然需要人工手动完成的是将这些步骤串联起来:识别出重复的故障源自同一个 Bug、收集相关的日志与链路追踪、将这些上下文发送给智能体,并检查修复是否生效。如果没有这种结构化的交接,智能体在调查之前就必须搜索原始遥测数据来重建故障的范围和上下文。
今天,我们推出 Cloudflare Workers 内置错误监控功能 Issues(现已开放公测!),以简化这一工作流程。Issues 可以:
- 将重复的异常、5xx 响应和错误日志归类到一个问题中。
- 将错误、堆栈追踪、日志、链路追踪和 Worker 版本发送给配置好的编码智能体。
- 触发智能体配置的工作流程——从分类问题到查询更多数据再到开启拉取请求。
使用以下针对智能体的提示词以及 CF CLI 修复你的第一个问题,或者查看 文档 以开始使用:
复制提示词:为 cf 设置
Set up cf: https://developers.cloudflare.com/cf/. Enable Issues for this Worker in cloudflare.config.ts; show the diff and ask before deploying. After approved deployment, wait 1 minute, then find the most frequent issue and retrieve an occurrence using its returned ID:
cf observability issues list --order-by count --order desc --per-page 1
cf observability issues occurrences <ISSUE_ID> --per-page 1
If no issues exist, report that. Otherwise, diagnose from the details, fix locally, run relevant checks, and show the diff and results. Ask before deploying the fix.自动捕获故障
只需一行配置,你就可以开始接收 Worker 上检测到的 Issues,无需额外的代码埋点。Issues 内置于 Workers 运行时中,因此无需安装 SDK 或添加应用程序包装器。
一旦启用,Issues 会记录未捕获的异常、失败的调用、HTTP 5xx 响应、console.log() 和 console.error() 的输出,以及包含堆栈追踪的日志。它还会标记失控的定时器条件以及在循环内部写入大量日志的代码。
设想有一个 Worker,其处理程序在部署后开始抛出错误。每次失败的请求都有不同的请求 ID,但它们都源自同一个 Bug。Issues 会将它们归类在一起,并显示错误首次出现的时间、发生的次数以及它是否变得更加频繁。
当你打开一个问题时,你可以看到错误、可用的堆栈追踪、导致该错误的日志和链路追踪、Worker 版本、请求详情以及该问题随时间变化的趋势,如下所示:
为你的智能体提供错误上下文
Cloudflare 可以捕获 Worker 内部发生的情况,但它并不知道哪些用户、账户或会话对你的应用程序至关重要。使用 Worker 运行时内置的 OpenTelemetry API 来添加这些标识符,无需安装其他包:
这些标识符会随着每一次发生而显示。在这个问题中,你现在可以在将问题发送给智能体之前,查看故障是否集中在某个账户或会话中。
将检测到的问题发送给你的智能体
问题不再需要一直停留在仪表板中,等待某人复制堆栈追踪并将其粘贴到提示词中。只需配置一次自动化,当问题跨越发生阈值或在平静期后再次出现时,Issues 就会通过 Automations 直接将它发送给你的智能体。你可以选择自动化何时运行以及问题应该去往何处。
这可以通过以下方式实现:
- 内置编码代理: 将 Claude Code 与例程 ID 和令牌连接,Cursor 与自动化 webhook URL 连接,或 Devin 与 API 令牌和组织 ID 连接。
- 通用 Webhook:将问题上下文发送到您自己的代理或 HTTPS 端点。
- 聊天与事件管理:通过聊天或值班工作流通知您的团队。
当自动化运行时,Issues 会发送与问题一起捕获的失败摘要和诊断上下文——异常、错误、源映射堆栈跟踪、前后日志和跟踪、Worker 版本,以及您添加的应用程序上下文。若需更深入调查,您可以单独将代理连接到 Cloudflare MCP ,让代理查询相关日志和跟踪,从而提出代码和测试更改并打开拉取请求。
您可以控制哪些内容进入生产环境:审查拉取请求,部署修复,并标记问题已解决。
Issues 如何在一天内发现并解决两个 Workflows 错误
Cloudflare Workflows,一种驱动长时间运行、多步骤应用的原语,完全构建在 Workers 平台上。
在后台,其服务跟踪步骤、重试和已保存状态。这使得 Workflows 成为在我们自己的生产系统上测试 Issues 的有用场所。在开启后的一天内,团队发现了隐藏在大量流量中的两个异常问题。
- 迁移卡在重试循环中: Workflows 控制平面迁移在尝试在边缘案例中应用迁移时反复遇到 SQLite 外键错误。Issues 使 Workflows 团队能够识别问题并修复。
- 删除过程从未完成: Workflows 发现,在删除 Workflow 实例时,存在一个边缘案例,可能超出 Workers 子请求限制并导致删除未完成。Issues 帮助 Workflows 团队识别问题并修复。
与其让团队连接数千个独立的遥测和用户报告,不如让他们的自动化设置将这些问题直接发送到 Cloudflare OS,后者将错误追踪到 Workflows 代码并为两个问题提出修复方案。
开始使用
准备好看看 Issues 在您的应用中发现了什么吗?开始使用:
- 在您的
wrangler.jsonc文件中将observability.issues.enabled设置为true - 在 Cloudflare 仪表盘 设置您的第一个自动化,以将问题发送到您选择的目标,无论是代理、Webhook、事件管理工具还是聊天平台。
Source: cloudflare blog · blog.cloudflare.com