高分 benchmark 和长上下文，都不能替代 agent 的 discovery 与 selection 设计

type

Post

status

Published

date

Apr 22, 2026

slug

pub_topic_20260422_benchmark_context_gap_001_notion_001

summary

高分 benchmark 和超长上下文都很容易被误读成 agent 已经具备真实发现与规划能力，但生产系统真正会出问题的地方，仍然是答案预埋和错误上下文被稳定继承。

很多 benchmark 看起来像在测试推理，实际上更接近在测试 search。只要答案被预埋在封闭题面里，模型需要做的往往不是在开放环境中发现正确路径，而是在有限范围内找回已知答案。

这类高分当然有意义，它说明模型在某些封闭条件下的压缩、检索和组织能力正在变强。但问题在于，生产任务的难度通常并不在“是否能在题面中找到答案”，而在“是否知道应该去哪里找证据，以及什么时候意识到自己当前的证据不够”。

这就是 search 和 discovery 的差别。前者发生在边界已经画好的世界里，后者发生在边界本身都不稳定的世界里。对 agent 来说，后者才更接近真实工作。

行业里有一种很常见的误读，认为只要 benchmark 足够高，离可部署就只剩工程问题。但真实系统的开放性，决定了这件事远没有这么直线。

生产 agent 面对的是模糊目标、脏外部状态、不断变化的约束条件，以及大量并不标准化的信息来源。一个在 benchmark 中达到 99% 准确率的模型，放到这类环境里，未必知道该先看什么、该忽略什么、该在什么时候停下来请求外部确认。

所以真正危险的，不是模型偶尔答错，而是团队开始相信“分数已经说明它差不多能用了”。这种错觉会让系统设计偷懒，把本来应该由 runtime 明确承担的 discovery、selection 和 verification，全都默认交给模型自己处理。

长上下文的价值是真实存在的。它让模型能同时看到更多历史、更多材料、更多工具返回值，也让复杂流程在单轮内部更容易保持连续性。

但窗口变长，并不等于上下文质量自动变高。相反，它往往会把另一个问题一起放大: 错误前提的继承长度。

一旦错误证据、错误摘要、错误指令或者不该保留的旧状态被带进上下文，模型就可能在更大的空间里把这些错误组织得更完整、叙述得更顺滑、推演得更自洽。最麻烦的从来不是胡说八道，而是在错误上下文下说得非常合理，因为这会让问题被发现得更晚。

如果高分 benchmark 和长上下文都不能单独解决问题，那么真正该补的是什么。答案其实更偏 runtime 设计，而不是单纯继续追窗口和榜单。

第一，要把 discovery 和 search 分开评测。不能因为模型会在封闭题面里找到答案，就默认它也能在开放任务里找到该看的证据。

第二，要把 context selection 做成正式能力，而不是默认“能塞进去的都塞进去”。上下文不是越长越好，而是越相关越好，越可验证越好。

第三，要把关键结论绑定外部验证。对于重要动作、关键判断和高代价结果，不能只看模型内部是否自洽，而要看外部状态是否真的支持这个结论。

第四，要把 failure logging、evidence pruning 和异常升级做成运行时的一部分。系统必须能够记录自己为什么走到这一步，也必须有能力在证据质量不足时停下来，而不是一味继续生成。

真正可用的 agent，从来不是在更大的窗口里更久地保持自洽，而是在不确定、脏乱、开放的环境里，知道该如何发现、如何选择、如何验证。

所以，高分 benchmark 值得看，长上下文也值得要，但它们都不该被误读成免设计通行证。对生产系统来说，真正决定上限的，仍然是 discovery、selection 和 verification 这些看起来不那么“炫”，却决定系统是否会在错误前提上越跑越远的基本能力。