AI大模型的“过敏原清单”公布！九大药方建立系统免疫

把大模型容易“翻车”的场景当成过敏原，用工具、验证层和流程设计建立系统级防护。

AI 大模型也会像人类一样“过敏”吗？

AI大模型也会像人类一样“过敏”吗？是的，虽然是个比喻，但非常贴切。

因为大模型都有一些明明看起来应该会、实际上却很容易翻车的地方。不是因为能力不够，而是底层架构天生就带着这些弱点，就像有些人吃花生会休克、春天闻花粉就打喷嚏，不是身体不强壮，是免疫系统的识别逻辑出了偏差。

下面这份“过敏原清单”，可以帮我们快速看清哪些场景最容易踩坑。同时附上一份“治疗手册”，在日常使用以及搭建智能体时，都能避免踩坑。

一、对「精确计算」严重过敏

典型任务包括：123456789 × 987654321、多位数字相加和减法借位、判断闰年或精确日期差。表现往往是一本正经地给出错答案，或者偶尔对、偶尔离谱。

根因在于 Transformer 本质是 pattern-matching / 概率预测机，不是算术电路。数字在 tokenization 阶段就被切碎了，连续运算对它来说等于拿语言学模型硬做数学，能蒙对一部分，但不保证正确。

二、对「自己生成的内容」过敏：自反馈中毒

如果你让模型先生成一个推理链，再让它基于自己的输出来反思或修正，它的输出可能越改越差。

因为一旦第一步产生了错误的内部信念，后续 token 会沿着那个错误轨迹继续滚雪球。它没有真正的验证器，只有“接着编”。类比来说，一个人对着镜子自我纠正，镜子里的人也在跟着改，最后谁真谁假分不清了。

三、对「超长上下文的中间信息」过敏：Lost in the Middle

把关键信息放在一段很长的文本里，放在开头，模型通常记得；放在结尾，模型也还记得；放在正中间，最容易被忽略。

研究论文 Lost in the Middle（Liu et al., 2023）实锤了这个现象：注意力的有效分配天然偏向首尾，中间层的信息会被稀释掉。

四、对「事实时效性」过敏：没有真正的时间概念

当你问“今天上海天气怎么样”，模型如果只依赖训练记忆，通常无法准确获取实时信息。这不是 bug，而是预训练范式决定的：模型学到的知识被冻结在训练截止日，之后发生的事只能通过 RAG 或工具调用间接感知。

大模型没有正在流逝的时间，没有时钟、没有持续的内生状态、不感知“现在”。它有的只是训练文本里见过的时间符号模式。位置不等于时间，统计不等于感知。

五、对「矛盾/嵌套指令」过敏：人格撕裂

系统提示要求严谨，用户提示要求编造；上层规则要求安全，下层文本诱导越狱。面对冲突约束，模型可能优先讨好用户，也可能出现逻辑摇摆：前半段严谨，后半段突然放飞。

这就是越狱之所以有效的土壤：不是模型不够聪明，而是它对“同时满足所有人”有强迫倾向。

六、对「诡异字符 / 零宽字符 / Unicode 暗器」过敏

零宽空格、同形异义字、大量无意义 emoji、稀有 Unicode 区段填充、故意破坏 token 边界，都可能让 tokenizer 产出预期外的 token 序列，导致模型行为不可预测地漂移。

七、对「反复追问：你确定？」过敏：讨好偏差

经典场景是：模型先给出正确答案，用户反复质疑后，模型为了和谐改口。研究表明，当人表现出质疑时，模型有显著概率放弃原来的正确答案去迎合用户，即使原来是对的。

这不是“变蠢”，而是 RLHF 阶段植入的“尽量别跟用户杠”的倾向走过了头。

八、对「严格因果 / 反事实推理」轻度过敏

例如“如果某事件没有发生，美国 GDP 会怎样”“把这句话的逻辑矛盾指出来并证明不可满足”。这类任务需要形式化推理引擎、SAT solver 或符号系统，而大模型只有模糊的语义直觉：它能感觉哪里不对，但很难给出严格证明。

过敏原速查表

所以“大模型对什么过敏”的本质答案是：它最过敏的是人们对它的期待错位。把它当成全知全能的推理引擎，就容易出事；把它当成极其擅长模式续写的语言统计机器，再给它配工具和验证流程，才是正确打开方式。

大模型的“过敏治疗手册”

核心理念是：不要试图“治好”模型本身，它的 Transformer 基因改不了。真正的解法是给它配辅助器官，也就是工具；同时建立制衡流程，也就是流程设计。把过敏区从“靠它硬扛”变成“让它绕开”。

精确计算：永远外包给计算器或代码执行

坏用法是让模型直接心算复杂表达式。好用法是：请用 Python 算这个式子，把代码和执行结果贴出来。凡是四位数以上运算，一律走代码路径。处方是：让它算，不如让它写算式让机器算。

事实时效性：喂给它今天的情报，别让它猜

轻量任务可以前置声明“以下内容是我确认过的事实”。需要引用时，应粘贴新闻正文、URL、抓取时间。Agent 场景则用搜索 API、网页抓取和上下文注入。关键是不要让模型回忆，要让它读你给的材料。

长文中间丢失：结构化喂料

不要把 200 页文本整段粘贴后要求模型找第 123 条风险。更好的做法是分段、显式标记、先做目录级索引，再按需加载。

讨好偏差：锁答案法

需要判断任务时，可以要求模型严格依据材料作答；如果结论不确定，就明确说材料不足，不要为了迎合暗示而改变答案。进一步可以要求输出结论、支撑证据、置信度及原因。

Agent 智能体层：从单点补救升级为系统免疫

日常使用是手动作坊，Agent 是企业流水线。Agent 的核心不是“更聪明的模型”，而是“更结实的执行框架”。总体架构原则是关注点分离：编排层决定做什么和下一步是什么，搜索、计算、文件读写、验证器负责精确执行和错误拦截。

药方 ①：工具调用，把过敏区外包出去

算术和数据处理交给 Python，实时信息交给 search 和 fetch_url，文件操作交给 read_file / write_file，结构化数据查询交给 sql_query。模型负责规划和语言，工具负责精确执行。

药方 ②：Verification Layer，永远假设模型可能出错

不要让模型自己生成答案、自己验证、自己放行。验证层应包含确定性校验、工具级证据追踪、格式契约校验，以及独立 Critic / Reviewer。

药方 ③：Context Management，对抗中间信息丢失

Agent 跑多步后，context 会越来越长。更好的方式是 Three-Tier Memory：工作记忆保存当前 step，短期记忆保存最近关键摘要，长期记忆保存 facts、entities 和用户偏好，并按需 retrieve。

药方 ④：Confidence Gating，不知道就说不知道

除非能引用工具返回、用户提供文本或代码执行输出，否则事实性结论都应被标注为未 grounding。低置信路径应反问用户补料，不要硬编答案。

药方 ⑤：防越狱与权限隔离，别让指令冲突腐化 Agent

外部抓取文本应包在 web-content 这类不可执行数据容器里；规划身份和工具执行权限要分级；关键约束写在 orchestrator 层，而不是只靠 prompt 自律。

一张实操速查卡

日常使用时，遇到精确数字就让模型写代码算；需要最新事实就贴资料或开搜索模式；长文档分析先做目录索引再按需展开；重要判断要求引用来源，无来源断言视为噪声。

Agent 开发时，每条事实性 claim 都要有 ground truth 来源；计算走 Python sandbox；生成与验证走两个独立通道；上下文用 summary 和 retrieve 管理；关键权限和约束写在代码层；低置信路径反问用户补料，不硬编答案。

最后一句话：Don’t trust, verify. Don’t compute, execute. Don’t remember, retrieve.