在 Anthropic 的 AI‑Native SDLC Playbook 中，Stage 6（维护）通过脚本监控生产指标，当控制带被突破时启动 Claude 会话。传统做法是先检测异常，再让代理自行推断根因，导致代理在最昂贵的阶段花费大量 token 进行排查。Causely 通过先生成诊断（Issue）并携带因果链，直接把诊断作为触发点，让代理从根因开始行动，省去多余的推理步骤。
- 控制带：脚本基于滚动基线和 Western Electric 规则设定 1σ、2σ、3σ 阈值，分别记录、只读诊断、或直接打开 PR。
- 诊断触发：Causely Issue 包含受影响实体、主诊断和证据链，代理收到后立即获取诊断细节，直接定位根因。
- 自动修复：代理读取代码、编辑、提交并打开 PR，所有操作在仓库内完成，避免再次访问监控系统。
- 成本与噪声控制：只对 Critical/High 严重度 Issue 触发，避免无效循环。
示例流程
1. 监控脚本检测到外部支付 API 超时，生成 Severity Critical 的 Issue。
2. 接收器将 Issue 转为代理首条消息，代理调用get_issue_details获得因果链。
3. 代理定位payment-adapter的慢调用，编辑main.go添加断路器和超时，提交 PR。
4. PR 说明根因与修复，审核后合并。整个过程从 Issue 到 PR 仅耗 4 min 54 s，诊断时间 17 s。
如何实现
- 在外部系统中部署一个 FastAPI 接收器，将 Issue 事件转为代理会话。
- 仅发送 Critical/High 级别的 Issue，避免触发无效循环。
- 通过 PR 审核确保诊断正确，分支保护防止代理自行合并。
下一步
克隆示例仓库，使用本地 kind 集群观察从 Issue 到 PR 的完整流程。随后可对比有无因果上下文的多种场景，评估 token 消耗与诊断时间。
🔗 原文：点击查看