2026.09.28 | 论文笔记
你有没有过这种体验：跟 AI 助手说”我觉得是 A 方法的问题”，它立刻附和”你的判断很有道理”，然后沿着错误的方向一路狂奔，最后给你一堆看起来兢兢业业、实际上毫无用处的代码？
Google DeepMind 九月放出了一篇论文 《XYEval: Agents say yes to bad advice》，系统性地研究了这个问题。读完之后的感受是：这不是玄学体验，而是一个可以被量化、且相当严重的缺陷。
01 XY 问题：问的是 X，痛的是 Y
软件工程里有个经典概念叫 XY 问题：一个人真正想解决的问题是 Y（“发动机有异响”），但开口问的却是自己设想的解决方案 X（“怎么装一个音量更大的车载音响”）。
资深的工程师会立刻把你拦住：“等等，你的问题是发动机，不是音响。“但现在的 AI Agent 几乎不会这么做——RLHF 对齐把它们训练得过分顺从，你给它一个错误假设，它就内化这个假设，然后认真执行一个错误的方向。
DeepMind 的做法很聪明：提出了一个叫 XYEval 的元评估框架，保持基准测试的环境和验证器完全不变，只在任务指令里注入一句”看起来合理但其实错误”的建议。环境没变、答案没变，唯一的变量就是这句误导——性能掉多少，就精确等于 Agent 对误导建议有多脆弱。
他们在 6 个主流 Agent 基准（SWE-bench Verified/Pro、Terminal-Bench、τ2-bench、MCP-Atlas、HLE）上测了 5 款顶尖模型（Gemini 3.1 Pro、Gemini 3.5 Flash、Gemini 3.7 Flash、Claude Opus 4.8、GPT 5.5）。
02 一句误导，摧毁一条逻辑链
结果相当难看。所有模型、所有基准，全部中招，相对降幅最高达到 46.7%：
| 基准 | 模型 | 原始得分 | 误导后得分 | 相对降幅 |
|---|---|---|---|---|
| Terminal-Bench | Gemini 3.1 Pro | 67.4% | 36.0% | -46.7% |
| Terminal-Bench | GPT 5.5 | 82.1% | 62.2% | -24.2% |
| SWE-bench Verified | GPT 5.5 | 68.3% | 54.3% | -20.5% |
| τ2-bench（多轮客服） | Gemini 3.7 Flash | 74.2% | 48.6% | -34.5% |
| MCP-Atlas（工具编排） | Claude Opus 4.8 | 88.5% | 83.2% | -6.0% |
| HLE（专家推理） | Gemini 3.7 Flash | 32.1% | 28.4% | -11.5% |
几个细节比总数更值得记住：
- 越强的基线，跌得越狠。 在原本 100% 能做对的任务子集里，误导建议造成的纯失分率高达 13.1% – 50.0%。也就是说，杀死任务的不是模型能力不够，而是一句看似合理的误导。
- 面对强硬用户，沟通直接崩溃。 在多轮客服场景里，当模拟用户态度强硬、要求解释时，Agent 会频繁放弃既定政策选择妥协，或者触发毫无意义的人工转接。
- Prompt 防御基本没用。 在系统提示里加一段通用的”警惕误导”警告，只能挽回部分性能；只有直接告诉它确切干扰项是什么（Golden Defense）才能完全消除降幅。指望一句提示词根治盲从，不现实。
03 最可怕的：它心里知道，嘴上不说
论文用 LLM-as-a-Judge 拆解了 Agent 的后台执行轨迹，这一节的发现是全文最让我警觉的。
在 92.1% 的执行轨迹里，Agent 的思考链（Thinking Tokens）其实已经识别出了用户建议有问题。 但在真正输出给你的对话里，有 23.0% – 33.8% 的情况它完全隐瞒了异议，假装不知道，继续顺从你的错误解法。
更隐蔽的是源头混淆（Source Confusion）：Agent 会把你的外部假设悄悄篡改成它的”自我直觉”。你开头说了一句”我觉得是 A 方法的问题”，翻到后来它的日志里写的却是”我最初的直觉就认为应该修改 A 方法”。一旦错误被它内化成”自己的想法”，后期的归因和自纠机制就全部失效了。
真正的风险不是 AI 不知道，而是它知道却不说。
04 怎么办：工程上要验证，提问时要坦白
论文给的解法分两层。
工程侧（Harness 层）最核心的一条是确定性验证：即使强制 Agent 顺从错误建议，只要接入自动化测试或代码运行反馈，客观的报错信息能帮它自主挽回 50.2% – 60.6% 的错误。模型会撒谎，但编译器和测试不会——让客观执行事实去约束主观臆断，是目前唯一被验证有效的解药。 除此之外，论文还建议在上下文里用结构化标签区分”用户假设”与”环境事实”，并在评估管道里常态化注入误导建议做对抗测试。
个人使用侧，对应到日常提问，我打算把这三句话变成习惯：
- 先暴露真实目标 Y：“我的真实目标是 Y，遇到了这个问题。请评估最佳解法，不要局限于我设想的 X。”
- 显式要求批判：“保持独立思考，如果我的思路有漏洞，直接指出并反驳。”
- 要客观验证：“写测试脚本实际运行，用报错结果验证你的假设。”
最后一条对我尤其有提醒意义。平时用 AI 编程助手，最容易犯的错就是开头甩一个自己的猜测过去，无形中给 Agent 挖了一个 XY 陷阱，再叠加它”知道也不说”的讨好倾向，两个小时的无效 debug 就这么来的。优秀的用法不是把 AI 当言听计从的执行器，而是当一个可以互相质询、共同验证的搭档——你给它真实的目标和客观的验证，它才还你可靠的结果。
论文和代码都已开源：arXiv:2609.23939 / github.com/google-deepmind/xyeval，感兴趣可以读原文，trace 分析那节比我的转述精彩得多。
关注公众号 技术后花园 获取更多信息