概览
每个人都同意事后复盘应该不追责，而大多数并没有做到。这不是出于恶意：半夜里，「17:40 那次配置推送」是最容易写出来的一句真话，而一旦有个人出现在文档上，这份文档就不再是关于系统的了。
这个智能体不能点名任何人。它从你的日志、告警和聊天记录重建时间线，把实际发生了什么和当时人们相信什么分开，并提出那些能找到系统性成因的问题——为什么告警没有触发，为什么回滚花了九分钟，为什么那个配置一开始就能未经复核被推上去。
它的行动项具体且可检验，并且会标出哪些其实只是愿望。「更小心一点」不是行动项；「生产环境配置变更必须复核」才是。它还把已知和假定分开，这样下个月不会有人把文档里的一个推测当成既定事实。
价值
当天就写完
一周之后写的复盘，是一次重构。
可以放心传阅
里面没有任何一句能被读成指控。
真能改变什么的行动项
可检验的条目，而不是一堆决心。
功能说明
不能点名任何人
这是一条硬规则，不是语气偏好。它只提角色和系统，而这正是它做到不追责的原因。
把事实和当时的判断分开
什么是真的，以及处置人员当时以为是什么。两者都重要，而把它们混在一起就是传说产生的方式。
找系统性成因
不是什么触发了它——而是什么让一个触发因素足以造成一次故障。
可检验的行动项
每一条都有一个负责角色，以及一个检验它是否奏效的方法。「更小心一点」会被标为愿望。
检测与恢复的缺口
过了多久才有人知道，以及是什么让恢复比它本该的更慢。
标出未知
一个未解的问题是一条发现，而不是一个需要用推测去填的洞。
这会改变什么
这会如何改变你的一周
- 它接手的工作
- 把一个事故频道变成一份带成因和行动项的文档。
- 目前由谁完成
- 半夜里的一名工程师，或者一周后凭记忆写的人。
- 多久一次
- 每一次事故。
- 通常的人工投入
- 趁一切还新鲜时认真做一次复盘，要半天。
为什么偏偏是IT 与服务管理。它不能点名任何人。如果一名工程师能独自造成这次故障，那是系统允许了它——而这正是能防止下一次的那条发现。
无人值守运行
由你或某个事件启动，然后自行完成。没有什么需要等人坐到工位前。
每一次都是同一标准
第两百件与第一件用同一把尺子衡量。一致性正是人做不到长期保持的部分。
它无法自行采取行动
事故复盘代理 没有任何发送、支出或承诺的途径。正是这个限制，让依据它的输出行动是安全的。
运行方式
该智能体通过 PROMIVO 运行时在服务器端运行。每次运行都会逐步记录，每次工具调用在执行前都会进行权限检查。
- 1输入按智能体的输入结构进行校验
- 2模型claude-sonnet-5，并自动回退
- 3工具extract_structured_data
- 4权限自动执行 READ 级操作；更高的等待你批准
- 5输出符合输出结构的结构化结果
- 6日志记录 token、耗时和每一个步骤
演示
演示数据Illustrative sample output, abridged.
输入
{
"severity": "SEV2",
"timeline": "…",
"incidentReference": "INC-402"
}输出
{
"summary": "A configuration change reduced the connection pool below what peak traffic required. Requests queued, then timed out. Service was restored by reverting the change.",
"escalate": false,
"unknowns": [
"Why the pool size was reduced. The record does not say, and the change carried no description."
],
"disclaimer": "Blameless by construction: roles and systems only, never a person, and no finding attributes cause to human error. Actions are proposals; nothing has been changed.",
"actionItems": [
{
"action": "Require review for production configuration changes.",
"status": "actionable",
"ownerRole": "Platform team",
"testForSuccess": "An unreviewed config change is rejected in a test attempt."
},
{
"action": "Be more careful with configuration.",
"status": "not-actionable",
"ownerRole": "—",
"testForSuccess": "None possible."
}
],
"recoveryGap": "9 minutes of the 14-minute recovery was the redeploy. A config rollback would have been under a minute.",
"detectionGap": "23 minutes from first failed request to anyone knowing. The signal came from customers, not monitoring.",
"contributingConditions": [
"Production configuration could be changed without review.",
"No alert existed on connection pool saturation, so the first signal was customer reports.",
"The revert path required a full redeploy rather than a configuration rollback."
]
}使用条件
集成
无需集成。
开始之前
- 事故时间线——告警、日志、聊天记录、发布历史
- 需要 入门版 套餐或更高
使用场景
一次故障之后
几分钟内把事故频道变成一份文档。
反复出现的事故
找出前三次复盘都漏掉的那个成因。
面向客户的说明
为你要告诉客户的内容提供事实依据，不含内部细节。
价格
常见问题
为什么它不肯说是谁造成的？
因为如果一个人能独自造成一次故障，那是系统允许了它，而这才是那条发现。点名会让调查提前结束，并教会其余所有人在下一次事故里少说话。
它能写面向客户的通告吗？
它可以起草事实依据，不含内部系统细节。是否以及如何对外沟通一次事故，是一项带有商业和法律分量的决定，留给人。
如果时间线不完整呢？
它把缺口标为未知，并列出该去核查什么。一份中间被自信编造出来的复盘，比一份诚实带洞的更糟。
评价
客户运行过该智能体后，评价功能将开放。
需要这个智能体换一种做法？
告诉我们要改什么，我们的团队会为您的业务规划一个定制版本。
定制此智能体