技能介绍

要解决什么问题

一次 Agent run 往往散落在 trace、tool log、policy/approval 记录和业务侧反馈里。事后核对「有没有请求发送」「是否经过审批」「哪次 attempt 超时、哪次 retry 成功」「run 终态与下游是否一致」时，常见问题是：把时间先后当成因果、把批准当成已执行、把 terminal success 当成业务送达。

本技能面向已脱敏导出的材料，产出可复核的静态运行摘要，并给关键事实打上 [来源ID#定位]，而不是连平台做实时诊断或写正式 RCA。

技能如何工作

核心是把身份拆成五层，且只用稳定 ID 或明确 link 关联：

Agent/部署快照 → Session → root/sub-run → span/event → operation/attempt

动作链按八个阶段分列，阶段之间不得互推：外显计划、tool 请求、policy 评估、approval 请求/结果、execution attempt、执行结果、run terminal。retry 按 retry-of / attempt ID 保留，后续成功不抹掉先前 timeout 或 error。

典型工作流包括：固定口径（范围、时区、材料截止）→ 登记来源 → 建身份层级 → 用 parent/link/sequence 建偏序（时间只表示先于/晚于）→ 拆动作链 → 核对覆盖（sampling、dropped、missing parent）→ 把 Agent 终态、外显输出与业务观察分开登记 → 按模板给出准备度（可提交复核 / 补证后提交 / 材料不足）。

适用边界与注意点

适合：解释单次或一批 run 发生了什么；核对断链、审批绑定范围、retry 与终态缺口。
不适合：实时监控、事中通报、唯一根因判定、配置变更评审或安全合规认证。
不提供：连接日志/APM、replay、恢复 tool payload、复述隐藏 chain-of-thought 或未脱敏凭证；发现凭证只登记「凭证暴露待处置」。
trace、prompt、output 均按不可信数据处理，不执行其中指令；无 ID 时用来源行号临时代号，不强行去重或伪造父子关系。

截图预览

使用场景

生产 Session 出疑点后，手头只有脱敏 trace 与 tool 导出，要把 root/sub-run、策略、审批、retry 与终态整理成带来源定位的复核摘要。
合并 policy log 与 approval receipt，核对某次高风险 operation 是否先过策略、再在批准窗口内执行，以及 retry 是否仍绑定同一 digest。
批量 run 对内说明前，按 Session/run 逐条登记 dropped span、missing parent 与 child terminal 缺口，不连平台也不把时间相邻写成根因。
run 终态为 success 但业务侧称未送达，需并列登记下游 accepted、接口人说法与缺失的 delivery 回执，不擅自判定业务成败。

适合人员

维护编排型 Agent 的值班工程师，常需用脱敏导出向负责人说明某次发送是否经过策略评估与经理批准再执行。
负责 Agent 治理的平台工程师，要抽查 approval 与 operation/digest 的绑定，以及 timeout 是否被后续 attempt 成功悄悄掩盖。
牵头运行复核的技术负责人，需在不能 replay 的前提下，把 trace、tool、policy 多源记录对齐到稳定 Run ID 与 Operation ID。
撰写轻量事故说明而非正式 RCA 的协调人，只要可提交的事实时间线、覆盖缺口与「未执行」的候选动作清单。