为 LLM Agent 策展常驻上下文：带删失反馈的容量约束选品模型

这篇 arXiv 论文研究 LLM Agent 每次会话开头加载的固定上下文文件（如 AGENTS.md）。作者指出，文件中的每个 token 在后续每轮都被重复计费，文件变大还会降低性能，但实践中策展人往往只做追加。论文将上下文策展建模为带容量约束的选品问题，给出最优文件规模上界，并分析反馈被删失时的增删决策。

此前上下文文件多靠人工或自动追加维护，缺乏对规模上限和增删时机的定量依据。该论文把常驻上下文当作受注意力容量约束的选品问题，并指出反馈只在缺失指令造成损害时才可观测，为“该放多少、何时加、何时删”提供了可分析框架。

指令占用有限注意力容量，新增指令不会提升其他指令的遵从度，保留指令则带来每会话固定开销，因此存在与候选数量无关的最优文件规模上界。反馈被删失：已加载指令的利弊可观测，未加载指令只在缺失导致损害时产生反馈。由此，删除被 Agent 忽略的指令可能误删有用指令，论文刻画了添加指令前应收集的证据量，并在人工审查编辑数受限时给出遗憾界。

对使用常驻上下文文件的 Agent 产品，这意味着不能只靠追加维护：需要按 token 预算做取舍，记录指令的独立价值，并谨慎处理“被忽略即删除”的启发式。研发上可把上下文文件当作可评估、可淘汰的资产，而非不断增长的文档。

• 在 Agent 产品中引入上下文文件 token 预算与定期剪枝流程，替代只追加的维护方式。
• 记录每条常驻指令的单独价值与触发场景，为增删决策建立可回看的证据日志。
• 对“删除后造成损害”的案例做回归监控，避免因 Agent 忽略而误删有用指令。
• 将人工审查编辑量作为约束，优先复核影响面大、证据不足的上下文改动。

• 论文提到的经验实验具体设置与结果如何，是否覆盖真实生产 Agent 的上下文文件？
• 最优文件规模上界在实际 Agent 任务中如何估计，需要哪些输入参数？
• 删失反馈下的证据阈值和遗憾界在非论文复现环境中是否可操作？
• 除 AGENTS.md 之外，该模型是否适用于其他常驻上下文形式？