给 AI Agent 塞更多上下文，反而更蠢？她揭开了一个反直觉真相

你以为 Agent 不聪明，是因为“上下文不够多”。但在真实系统里，更多上下文往往让结果更糟。来自 Qodo 的 Nupur Sharma 用一线踩坑经验告诉你：不是模型不行，而是我们喂错了东西。

最反直觉的一刀：上下文不是越多越好

在这场分享里，Nupur Sharma 抛出了一个几乎所有 AI 工程师都会下意识反对的观点：Context 本身不是问题，乱给 Context 才是问题。她观察到一个典型的 U 型曲线——在上下文很少时，Agent 表现不好；在上下文适中时，效果最好；但一旦你开始“疯狂加料”，模型反而开始忽略中间那一大段信息。

更扎心的是，这不是主观感觉，而是他们在真实系统里做 benchmark 得出的结论。LLM 会主动“清理”它觉得不重要、甚至妨碍理解的信息，试图自己构建一套能说得通的世界观。结果就是：你精心准备的中间说明，被模型当成噪音直接丢掉。

从确定性世界走来，她为什么对 Agent 如此警惕

Nupur 的背景并不是“纯 AI 研究员”，而是 DevSecOps——一个高度确定性的工程世界：规则清晰、结果可复现、对错分明。正是这种对确定性的执念，让她在 Agent 系统里迅速意识到问题。

当 Agent 从“静态 Prompt”进化为多角色、多步骤协作时，一个新的麻烦出现了：不同 Agent 之间对上下文的理解会发生冲突。它们各自“觉得自己懂了”，但拼在一起却得不到可用结果。这不是模型能力不足，而是我们在设计时默认了一个错误前提：所有 Agent 会以同样的方式理解同一段上下文。现实狠狠打脸。

Context Optimization：不是多给，而是给对

那怎么办？Nupur 给出的方向不是“更强的模型”，而是更聪明的上下文策略。她强调，Context Optimization 并不意味着开发者要在一开始就投入大量精力写复杂规则，而是通过策略化设计，让系统自己学会：什么该保留，什么该丢弃。

这背后有一个重要判断：并不是所有决策都需要最强模型来做。她提到所谓的“orchestration paradox”——如果你用最强模型去做所有编排决策，系统复杂度和成本都会失控。相反，那些 20% 难度的决策，完全可以交给更轻量的模型处理，把重型模型留给真正需要推理深度的地方。

Judge Agent：当上下文不可避免地爆炸

在一些不可避免会产生大量上下文的场景（比如复杂代码审查），他们引入了一个“Judge Agent”。它不直接参与生成，而是负责整合、裁剪、裁决多个 Agent 的输出。

这个角色的价值在于：当你已经有了很多“看似合理、但互相打架”的结果时，Judge Agent 能把它们压缩成一个“对人类有意义”的结论。这套思路已经被用在 Qodo 的代码审查架构中，通过不断 refine 输出，让最终结果不只是正确，而是可用。

总结

这场分享真正戳中人的地方在于：它没有鼓吹更大的模型、更长的 Prompt，而是逼你重新思考 Agent 设计的基本假设。对 AI 从业者来说，最大的 takeaway 是——Agent 的智能上限，往往不是模型决定的，而是上下文管理决定的。下次你想“再加点说明试试”之前，不妨先问自己：这段信息，真的会被需要吗？还是只是让系统更混乱？未来的竞争力，很可能不在于谁能喂得最多，而在于谁能喂得最克制。

关键词： AI Agent， 上下文优化， 提示工程， 大语言模型， Agent 架构

事实核查备注： 需要核查：演讲者姓名 Nupur Sharma 的职位与公司拼写（Qodo / Kodo）；演讲中提到的 benchmark 是否有公开数据；“20% model”是否为原话或比喻；Judge Agent 是否为正式命名还是概念性描述