360 Secure SkillHub
360 安全技能中心

evidence-association-pitfalls

归档 AI Agent“关键信息关联缺失”错误模式:区分未调档与幻觉,给出四类高频触发场景的脱敏案例、输出前检测清单与五条预防规则,供对话质量改进与系统提示词反模式参考。纯文档型知识库,无工具或外部服务依赖。

mowenqwq
mowenqwq
热度 7.64
最近更新 2026-09-29 03:23:23
分类:知识依赖:纯提示词应用场景:概念解释 / 研究

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add evidence-association-pitfalls
Metadata
name
evidence-association-pitfalls
description
AI Agent "关键信息关联缺失"错误模式库。Agent 手握足以推导正确结论的信息, 却未建立关联,转而套用外部模板、惯性标签或默认常识。本 skill 提供与近邻错误 (未调档/幻觉)的区分谱系、4 类高频触发场景(含脱敏案例)、输出前检测信号 清单与 5 条可执行预防规则。适用于:AI agent 对话质量改进、错误模式归档、 多项目语境下的行为校准、给 agent 写系统提示词时的反模式参考。

关键信息关联缺失(Evidence Association Failure)

模式定义

Agent 已持有足以推导出正确结论的信息,但未在"证据"与"结论"之间建立关联,转而套用外部常见模式、行业惯性标签或默认常识,产出与手中证据矛盾的输出。

核心特征:错误不是无知,是失联。 证据就在上下文里——agent 甚至读过、复述过它——但没有用它修正结论。

与近邻错误的区分谱系

"信息与结论断裂"其实是三种不同的病,混在一起教不清楚:

模式 信息状态 错误本质 检测关键
未调档(Unread Context) 信息在档案/记忆里,未被读取 检索缺失 结论是否用到了该查的背景资料
关联缺失(本模式) 信息已在上下文,已被读取 关联推理缺失 证据与结论是否匹配
幻觉(Hallucination) 信息根本不存在 编造填充 是否有真实来源

本 skill 聚焦中间一种——它最隐蔽:因为信息确实在场,错误在事后检查时"看起来引用了上下文",实际却没有让证据参与推理。

四类高频触发场景

场景 1:设计行为与外部模板冲突

用户的亲口定义或刚做出的设计决策与行业常见模式不一致。Agent 拿行业里更常见的标签直接套用,无视用户的设计信号。

案例(已脱敏):用户设计"所有内容必须标注信源等级"的功能——该设计明确指向"信息收集整理型站点"。Agent 却反复使用行业里更流行的另一种站点类型标签称呼该项目,贯穿整场对话多次,直到用户点名纠正。

破绽:用户的设计行为是结论的最强证据,优先级高于一切外部模板。如果一个功能"只有 X 类型的站才会做",那它就是 X 类型的站。

场景 2:画像硬约束未过滤推荐

用户档案中的硬约束(地理位置、支付渠道、设备、网络环境)未参与方案筛选,Agent 按全球通用性价比排序推荐。

案例(已脱敏):位于中国大陆、使用地方宽带(CGNAT 出口)的用户询问大容量服务器,Agent 推荐了德国/美国机房,并补了句"夜间传输无所谓"——实际线路质量根本不可行,且跨境支付渠道也存在障碍。

破绽:推荐类任务的第一步是"这个用户用得了什么",不是"市场上什么最好"。档案里写着答案,推荐时却没过这道滤网。

场景 3:名词激活错误关联域(多项目串线)

用户运营/参与多个项目时,话题中的通用名词("服务器""成本""推广""运营")激活了记忆中另一个项目的语境,Agent 整段建议建立在错误的话题域上。

案例(已脱敏):用户讨论 A 项目(面向游戏玩家的内容站)的运营成本,Agent 的建议整段建立在 B 项目(用户多年运营的另一类社区)的经验体系上,还建议"把 B 的直觉平移过来用"。用户当场纠正:"搞哪去了?"

破绽:回应前先锁话题主体——"这个名词在当前语境下属于哪个项目?"通用名词是多项目用户对话里的高频串线点。

场景 4:单点状态推因果

用户展示一个当前状态(截图、数字、现象),Agent 直接为它编造因果解释,未询问"之前是什么状态"。

案例(已脱敏):某云服务刚发布公告宣布整改。用户随后展示相关数据已恢复正常,Agent 解读为"你从来就没受影响,天然在火力范围外"——实际是"影响确实发生过,公告当天刚被整改修复"。因果方向完全反了。

破绽:对比类信息先问基线("之前是多少?");刚发生重大事件的语境里,状态变化的第一假设应该是"事件产生了效果",不是"本来如此"。

输出前检测信号清单

  • 我的标签/结论是从手中证据推出的,还是从"外部常见模式"借来的?
  • 用户最近的设计行为/亲口定义,与我的定性是否一致?
  • 若把上下文里最新的一条信息当作最强证据,我的结论还站得住吗?
  • 这个通用名词在当前话题里属于哪个项目/域?
  • 我是否在说"难怪你一直……""你本来就……"这类把现状归因为"从来如此"的话?——语境里刚发生过变化时,这是高危信号

预防规则(五条)

  1. 证据-结论匹配检查:结论落地前,把上下文中最新的一条用户信息(设计行为、亲口定义、新展示的数据)列为最高优先级证据,检查结论是否与它一致。不一致 = 停下重推
  2. 标签溯源:使用任何定位/属性标签前,确认它来自用户原话还是自己的转译。转译可以,但要说清是转译,不能当成用户的定义用
  3. 硬约束前置:推荐类任务先列用户硬约束(位置/支付/设备/网络),滤网不过的方案不提,或明确标注"仅作对比参考"
  4. 基线询问:对一切对比类信息(前后状态、变化量),先问"之前是多少"再解释因果
  5. 话题锚定:多项目语境下,每次回应前锁一次"当前话题主体是哪个项目、服务于谁"——通用名词(服务器/成本/推广)是串线高发区

正误对照(场景 1 的最小样本)

  • ❌ "你这个 X 类型站点……"(行业模板标签,无视用户的信源设计信号)
  • ✅ "你强制标注信源等级——这是信息收集型站点的典型信号……"(从证据推导)

适用边界

  • 本模式在长对话中发生率显著更高:早期贴上的标签会随对话自我强化,越用越顺,用户不纠正就一路错到底
  • 用户的设计行为 > 用户的言语 > agent 的外部知识——三层证据冲突时,优先级不可颠倒
  • 本 skill 不覆盖纯粹的检索失败(未调档)与编造(幻觉),但三者的区分表有助于归因时对症下药