技能介绍

它解决什么问题

大模型生成内容时，"自信地编造"是工程上无法根除的现象——幻觉在数学上不可避免，但可以被层层拦截。当 Agent 输出医疗、金融、法律等 YMYL 场景的高风险回答，或下游 skill 委派事实性任务时，缺少一个可审计的验证环节：回答到底有几成把握、每句话的依据来自哪里、多个模型意见不一致时听谁的。本技能补的就是这一环。

核心能力与执行流程

执行入口一旦激活，第零步必须是版本检查，随后按模式分流：VERIFY_EXECUTE（深度验证）、VERIFY_QUERY（历史查询）、VERIFY_ADMIN（管理信源/校准/模型池）。核心是四道防线，命中即须完整走完：

防线一·置信度评估：计算 VC（模型自评）+ SC（多次采样一致度）+ CC（按历史 ECE 校准）三层置信度，加权公式 0.4×VC + 0.3×SC + 0.3×CC。
防线二·事实源验证：RAG 检索 T1–T4 分级信源（权威事实权重 1.0，论坛匿名内容仅 0.2），逐句生成 [1][2] 式引用归因，只有 T1/T2 支撑才能标记 verified。
防线三·多模型交叉验证：要求 ≥2 家供应商 + ≥1 个开源模型异构并行，按 UAF 加权融合，强/弱共识放行，分歧触发防线四。
防线四·自我反思修正：CoVe → Reflexion → Critique-Refine 最多 3 轮，修订后仍不达标即走兜底——拒答或转人审，而不是硬着头皮交付。

每个段落同时标注知识类型（known / computed / inferred / iframe / common / guess），与置信度共同决定放行策略；guess 类型永远不会仅凭置信度单独放行。

适用边界与注意点

它是横向方法论层，不认领意图识别（交给 tri-intent），也不生成内容、不缓存结果。独立使用时需先检测上游 tri-intent 快照是否可用；没有快照就降级为基础模式，精度会下降。遵循最小化原则，只验证任务要点范围内的内容，范围扩大必须先与用户确认。验证产物（verify.md、sources.md、alignment.md 等）让每一步有据可查，适合集成到高风险问答链路，但对纯闲聊场景是过度设计。