代码部署之后出错，问题可能五花八门：有人翻文档，有人看日志，有人靠经验猜测。手工排查效率低，自动化才是方向。

错误分组：聚类 vs 分类

报错多了之后，直接看原始错误信息是一团乱麻。思路之一是用聚类（Clustering）——让 LLM 读取错误，把表面相似的错误归在一起，观察新聚类出现或旧聚类扩大，就能发现回归问题。难点在于阈值调优：多大的变化算有意义，而不是正常波动。

另一个思路是用更小的开源模型专门做错误分类和分组，把结构化的聚类结果直接传给 Open SWE 作为调查 prompt，让它在诊断时有更清晰的视野，知道整体出错模式是什么样的。

Ramp 的思路：事前定义监控

以上都是"事后"处理。Ramp 选了一个相反的方向——在错误发生之前就定义好监控规则。

做法：每次 PR 合并时，LLM 读取代码 diff，自动生成针对变更内容的监控规则，每条规则附带明确的阈值——错误率峰值、延迟回归等。当监控触发时，webhook 把告警上下文直接推给 agent 做分诊。

事前定义监控的好处是信号更清晰，下游 agent 更容易诊断。

修复还是回滚？应该自动判断

当前系统默认是"修复向前"模式：Open SWE 处理 PR，同时线上还在跑着有问题的版本。

更智能的做法是根据情况选择：

  • 错误率高、因果链不确定 → 立即回滚
  • 因果清晰、有明确修复路径 → 推送补丁

判断维度：严重程度 + 错误率 + 分诊置信度。

核心闭环

部署 → 监控 → 分诊 → 修复

全自动循环。这个模式不挑具体服务——任何部署代码的环境都有这个问题：出错了，有人要发现，有人要修。这个循环自动化得越多，工程时间就越从"被动响应"转向"主动建设"。打破和修复之间的反馈周期越接近零，系统就越健壮。