用户请求进入后，诊断 Skill 的完整流程是什么？

核心回答

一条完整诊断链路应是：明确对象与现象 → 路由并加载诊断方法 → 获取实际证据 → 构造和验证假设 → 形成有依据的结论与后续建议。Skill保存可复用方法，Agent决定本轮如何使用，工具读取真实系统数据，运行时管理状态和边界。

在故障诊断、风控归因与LogID全链路排查场景中，不能只讲“匹配到Skill然后调用大模型”，还要说明日志是否完整、结论如何验证，以及没有证据时怎样收敛。

请求进入后怎样走

确定任务范围。 从用户输入提取对象、现象、时间窗口、环境和已有标识，结合可信身份确定可读范围。缺失条件若能从当前请求或工具获得就先补齐，只有影响诊断的关键歧义才询问。

路由与加载。 根据能力目录选诊断Skill，加载相关正文和必要资源；同时保留其他候选或通用排查分支。模糊现象可能跨服务、存储和客户端，不应在第一层分类后永久排除其他方向。

获取证据。 按LogID、TraceID、业务对象ID和时间窗口查询日志、指标、链路、配置或近期变更，记录来源和采集时间。处理分页、时间偏差、采样和服务边界；一次查询成功不等于日志完整，缺少关键环节要明确标记。

建立假设并验证。 将观察与推断分开，例如“下游返回超时”是观察，“数据库锁等待导致”是待验证假设。优先查能区分候选原因的证据，必要时扩大范围；知识库提供排查方法与已知模式，不能替代这次事件的真实数据。

汇总交付。 输出现象、影响范围、证据支持的原因、排除的候选和建议动作；不确定时给出具体缺口与下一项有效检查。结论引用对应日志或指标，避免靠摘要反复自证。

执行中如何控制

用任务状态保存已查对象、证据引用、假设、失败和下一步，长日志存外部，主上下文只保留相关片段与回读位置。工具失败时按类型处理，连续重复查询没有新信息时调整或停止，设定时间和调用预算。

默认诊断可以先读证据；若用户任务包含实际修复，再按资源和动作范围执行。技能说明不能自行授予读取敏感数据或修改生产系统的权利，后端仍检查身份与对象范围；结果只包含任务所需信息。

如何确认诊断有效

用真实或可信复现的故障Case评估，不仅看路由和工具选择，还检查根因是否与证据一致、关键环节是否遗漏、建议能否解决问题。标准答案应由领域人员核对，允许多条有效排查路径。

分别观察误归因、证据完整度、无依据结论、任务完成、成本与耗时。技术亮点是将可复用排查方法与本次事件证据连接起来，让每个结论可追溯、每次探索有目的。

对应教程

参考资料