概览
每个工程组织都做事故复盘，却几乎没有一个做上一层的分析：把许多次事故放在一起看，究竟是哪一类变更在反复引发它们？一次复盘修好一个 bug。五十次放在一起读，才显出「什么样的变更会弄坏这套系统」的形状。
那个形状总是具体的，而且通常出人意料。不是「我们需要更多测试」，而是：碰某个服务的变更，出问题的概率是其他变更的四倍。周四下午四点之后的发布，占了三分之一的事故。凡是把数据库结构迁移和应用代码打包在一起的变更，都需要回滚过。真正出事的变更是那些没有关联工单的——因为那些正是紧急的。
业界收敛到了四项交付指标，团队照着报，却从不追问自己那个数字背后是什么。变更失败率 18% 是一个事实；是哪些变更让它成为 18%，才是你能着手的东西。
这个智能体把事故与变更放在一起读，报告其中的模式，并为每一类指出本可以拦住它的那个具体控制措施——一项测试、一道闸门、一条迁移策略、一个发布时间窗。它刻意不是一件追责工具：结论针对的是变更的类别，绝不针对是谁写的。按工程师个人统计的失败率表，一个月之内就不会再被诚实使用，因为人们会开始管理这个指标，而不是管理风险。
价值
一个你挪得动的失败率
因为你知道是哪些变更让它变成这样。
对准真实风险的控制措施
而不是在所有事情上平均地加流程。
同一原因引发的事故变少
而这是唯一重要的衡量标准。
功能说明
跨事故读，而不是一次读一件
一次复盘修好一个 bug。五十次一起读，才显出什么在弄坏这套系统。
找出变更的类别，而不是找出谁
结构迁移和代码打包在一起。没有关联工单的发布。具体，而且一条规则就能修。
指出本可拦住它的控制措施
一项测试、一道闸门、一条迁移策略、一个发布时间窗。而不是「更多测试」。
用停机时间为这类模式定价
按类别统计事故数、分钟数和回滚次数，让修复有个可支撑的理由。
找出没有工单的变更
那些紧急的变更。通常正是出事的那些，也是没人愿意去看的那个模式。
绝不给工程师排名
按个人统计的失败率表一个月内就会被博弈，并终结这项分析所依赖的诚实上报。
这会改变什么
这会如何改变你的一周
- 它接手的工作
- 把许多次事故放在一起读，找出是哪些变更在反复引发它们。
- 目前由谁完成
- 没有人。复盘一次只看一件事故。
- 多久一次
- 最好也就一个季度一次。
- 通常的人工投入
- 把整段时期内的每一次事故与变更元数据做关联。
为什么偏偏是软件与工程。团队照着报变更失败率，却从不追问自己那个数字背后是什么。答案从来不是「更多测试」——而是某一类具体的变更，一条规则就能修。
无人值守运行
由你或某个事件启动，然后自行完成。没有什么需要等人坐到工位前。
每一次都是同一标准
第两百件与第一件用同一把尺子衡量。一致性正是人做不到长期保持的部分。
它无法自行采取行动
变更失败分析代理 没有任何发送、支出或承诺的途径。正是这个限制，让依据它的输出行动是安全的。
运行方式
该智能体通过 PROMIVO 运行时在服务器端运行。每次运行都会逐步记录，每次工具调用在执行前都会进行权限检查。
- 1输入按智能体的输入结构进行校验
- 2模型claude-opus-5，并自动回退
- 3工具extract_structured_data
- 4权限自动执行 READ 级操作；更高的等待你批准
- 5输出符合输出结构的结构化结果
- 6日志记录 token、耗时和每一个步骤
演示
演示数据Illustrative sample output, abridged.
输入
{
"period": "H1 2026",
"changes": [],
"incidents": [],
"minimumSample": 5
}输出
{
"dataGaps": [
"19% of incidents have no linked change, so they are excluded from every rate above."
],
"escalate": true,
"patterns": [
{
"changes": 31,
"control": "Require migrations to ship as their own change, ahead of the code that uses them. A pipeline rule, not a review guideline.",
"incidents": 11,
"changeClass": "Schema migration bundled with application code",
"failureRate": 35.5,
"relationship": "causal-in-record",
"impactMinutes": 1840,
"versusBaseline": "8.7x the baseline rate.",
"controlWouldNotCatch": "A migration that is itself wrong. This splits the blast radius; it does not validate the migration."
},
{
"changes": 96,
"control": "A deploy window. Note the caveat: these may fail more because fewer people are available to catch them, not because the changes are worse. Impact minutes support that reading.",
"incidents": 14,
"changeClass": "Deploys after 16:00 local on the last working day of the week",
"failureRate": 14.6,
"relationship": "correlation-only",
"impactMinutes": 2960,
"versusBaseline": "3.6x the baseline rate.",
"controlWouldNotCatch": "Anything about change quality — this is about who is around when it breaks."
}
],
"disclaimer": "An analysis of your own incident and change records. No pipeline or repository was accessed or modified, no individual is named or ranked, and patterns marked correlation-only are not claims about cause.",
"repeatCauses": [
"Connection pool exhaustion on the billing service has caused 3 incidents, one after its postmortem was closed. That is a finding about the fix rather than the changes."
],
"sampleTooSmall": [
"Config-only changes: 2 incidents. Not enough to conclude anything, and reported as such."
],
"escalationReason": "Bundled migrations fail at 8.7 times the baseline rate, and one cause has recurred after its postmortem was closed.",
"baselineFailureRate": 4.1
}使用条件
集成
无需集成。
开始之前
- 事故记录，含时间、严重程度以及各自的诱因变更（如果已知）
- 变更与发布历史，含服务、类型、规模和时间
- 需要 全量访问 套餐或更高
使用场景
季度可靠性回顾
你早就在报的那些数字背后的模式。
糟糕的一个月之后
这些事故是否有共同的原因。
在加流程之前
一道闸门在哪里真正划得来。
平台投入的立项依据
哪个服务值得重写，附带证据。
价格
常见问题
它会指出是谁引发了事故吗？
不会，这是刻意的。按工程师个人统计的失败率表一个月内就会被博弈，并摧毁这项分析所依赖的诚实事故上报。结论针对的是变更的类别。
它需要我们的源代码吗？
不需要。它依据事故记录和变更元数据工作——服务、规模、时间、类型、是否回滚。模式在元数据里，不在代码差异里。
它会改我们的流水线吗？
不会。它没有你的流水线或代码仓库的访问权限，它推荐控制措施，而不是去实施它们。
评价
客户运行过该智能体后，评价功能将开放。
需要这个智能体换一种做法？
告诉我们要改什么，我们的团队会为您的业务规划一个定制版本。
定制此智能体