Forward Future Loop 004：自动化生产错误排查工作流

Loop 004 是 Forward Future 平台上一个面向生产环境错误排查的自动化工作流。它把"定期审查生产日志 → 定位可行动错误 → 追踪根因 → 修复并验证 → 提交 PR 或结束"这一系列动作，压缩成一个可以直接复制使用的 prompt。

这个 Loop 是做什么的

The production error sweep 是一个定时运行的生产日志审查流程。它的目标是：

• 主动扫描生产日志中的错误；
• 只关注"可以采取行动"的问题；
• 追踪到根因；
• 修复并验证修复是否有效；
• 如果没有可行动的错误，就干净地停止，不做任何改动。

本质上，它是一个"生产环境健康检查 + 自动修复"的 agentic 工作流。

核心 Prompt

Review our production logs for errors. If you find an actionable issue, trace it to its root cause, fix it, verify the fix, and open a pull request. If no actionable errors are present, stop without making changes.

验证条件

• 可行动的生产错误已被修复并验证。
• 结束时要么提交了一个 pull request，要么在没有可行动错误时干净停止。

使用场景

这个 Loop 适合以下场景：

• 每天早上或每周一次自动扫描生产日志，防止错误堆积。
• 在发布新版本后，自动检查是否引入了新的生产错误。
• 作为 on-call 的辅助工具，先由 agent 过滤一遍日志，再把真正需要人工介入的问题留下来。
• 维护长期运行的服务时，持续清理低优先级但反复出现的错误。

工作流拆解

第一步：获取生产日志

Loop 需要访问生产日志源。具体实现取决于你的技术栈：

• Cloudflare：通过 Observability MCP 或 Workers Logs 读取。
• AWS：CloudWatch Logs。
• GCP：Cloud Logging。
• Vercel：Function Logs。
• 自建：Loki、Grafana、ELK、Datadog 等。

关键是对 AI 说明日志格式、时间范围和过滤条件。例如：

查看过去 24 小时 production 环境的 ERROR 和 FATAL 级别日志，排除已知的 404 和 health-check 超时。

第二步：识别可行动的错误

不是所有错误都值得修。需要让 AI 判断：

• 这个错误是否反复出现？
• 是否有明确的堆栈信息或请求上下文？
• 是否影响用户？
• 是否属于已知问题或外部依赖抖动？

如果错误只是偶发的网络抖动、第三方服务超时、或者没有足够上下文，应该标记为不可行动，跳过。

第三步：追踪根因

对可行动的错误，AI 需要：

1. 根据堆栈定位代码位置。
2. 查看相关 commit 历史，判断是何时引入的。
3. 分析请求路径，找到触发条件。
4. 如果涉及外部依赖，检查依赖状态和配置。

这一步通常需要 AI 读取代码库、查询日志、调用 observability 工具，甚至运行测试复现问题。

第四步：修复

修复应该是最小化的。原则：

• 只改与这个错误相关的代码。
• 不要顺手重构。
• 优先修复边界条件、异常处理、配置错误。
• 如果是上游 bug，考虑升级依赖或加 workaround。

第五步：验证

验证方式可以包括：

• 运行相关单元测试和集成测试。
• 在本地或 staging 复现错误并确认修复后不再出现。
• 如果是日志类错误，确认新的日志中不再出现相同错误模式。

第六步：提交 PR 或停止

如果有修复：

• 生成清晰的 commit message 和 PR 描述，说明错误现象、根因和修复方案。
• 提交 pull request，等待人工 review。

如果没有可行动错误：

• 直接停止，不做任何改动，可以输出一份"今日无异常"的摘要。

接入方式

Forward Future 的 Loop 可以通过以下方式使用：

Hosted by here.now

访问 forwardfuture.ai 的 Loop Library，找到 Loop 004，复制 prompt 到你自己的 agent 环境中运行。你也可以根据自���栈调整日志获取和工具调用的部分。

为什么这个 Loop 有价值

生产环境里，小错误如果不及时处理，会逐渐堆积成技术债务。人工每天看日志很枯燥，而且容易遗漏。把这个流程交给 agent 后：

• 错误不会被遗忘。
• 只有真正需要人看的问题才会到人。
• 修复和验证过程有迹可循。
• 团队可以把精力放在新产品功能上，而不是反复清理日志。

注意事项

• 权限控制：这个 Loop 会读取生产日志、修改代码、提交 PR。运行前确保 agent 只有必要的最小权限。
• 误修复风险：AI 可能把症状当根因。PR 必须经过人工 review，不要自动合并。
• 日志噪音：提前配置好过滤规则，避免 agent 在大量无关错误中浪费时间。
• 验证环境：尽量在 staging 或本地复现问题，不要直接在生产环境测试修复。
• 循环频率：建议每天或每周运行一次，太频繁会消耗大量 token 和 API 额度。

项目链接

• Forward Future 官网：https://forwardfuture.ai
• Loop Library：https://forwardfuture.ai/loops
• 作者 Matthew Berman 的 Loop 004 页面