上下文越多，未必越好
智能体跑起来，总有一堆「常驻上下文」：项目约定、AGENTS.md、历史决策、工具说明。直觉是越多越全越好。可 arXiv 2610.11007 这篇论文把「常驻上下文择优」形式化为一个带容量约束的组合优化问题——capacitated assortment problem，结论有点反直觉：把相关材料全 append 进去，效果可能比精心挑出的子集差到任意大。
作者关注的是 Harness 设计里一个被忽略的环节。大家忙着接更多工具、存更长记忆，却很少问：当上下文窗口有限、而候选材料无穷时，到底该让哪些常驻？论文把这个问题建模成在容量上限下选一个子集，使智能体在该上下文下的期望表现最优，并给出求解思路。
从玄学变成可优化的目标
价值不在某个具体数字，而在把「上下文管理」从经验活变成可优化的目标。过去我们靠手感把资料堆进系统提示，现在可以像做资源调度一样，对每份材料算边际贡献、在预算内挑最优组合。这对长程智能体尤其关键：任务跑几个小时，早期塞错的冗余会一直占着窗口、稀释真正相关的信号。
当然论文也留了口子：最优子集依赖对「哪份材料有用」的估计，估计错了照样翻车；而且材料之间有关联，挑 A 不挑 B 可能破坏互补。所以它不是「少即是多」的万能证，而是提醒工程团队——上下文是一道需要主动设计的阀门，不是无脑扩容就能解决的瓶颈。
对做 Agent 框架的人，这等于把 AGENTS.md 从「写给人看的约定」升级成「给选择器排的优先级表」。哪些常驻、按什么顺序、预算给多少，都该成为 Harness 的一等参数，而不是写死在提示词里的堆砌。