预取
在LLM Agent语境下，指在模型开始推理之前由外部编排层提前调用数据源API，将结果作为上下文注入prompt的数据接入策略，强调输入一致性和可控性。
时间轴 (近 90 天)
预取策略的有效性高度依赖于预测的准确性，不精确的预测会浪费带宽和GPU内存。
恰当的请求调度比预取更有效，因为调度并发请求可以自然地揭示专家需求并重叠计算与加载。
当GPU内存中存在专家缓存时，预取可能是有害的，因为随着缓存中包含的必需专家越来越多，专家预测的精度反而会下降。
在预取模式下，若预取20个字段而实际只用到5个，冗余比例高达75%。
对于高频、小字段场景，预取往往更经济；对于低频、大字段或长尾查询，MCP的按需特性更能压缩无效开销。
一个实用的判断标准是：如果某个字段在80%以上的推理中都会被用到，就预取；如果使用率低且体积大，就交给MCP。
预取模式在LLM Agent语境下指在模型开始推理之前，由外部编排层提前调用数据源API，将结果格式化后作为上下文注入prompt。
混合方案建议：小规模核心字段预取 + 按需MCP补充，以平衡可控性和灵活性。
即便拥有未来请求先知能力的Oracle预取器，在迁移流量指标上也从未战胜不做预取的方案
预取的难点在于准确率与带宽开销之间的权衡：激进预取占用带宽和缓存容量，保守预取无法隐藏远端I/O延迟
还有 1 条时间轴事件
全部知识事实 (11)
预取策略的有效性高度依赖于预测的准确性，不精确的预测会浪费带宽和GPU内存。
50%待验证恰当的请求调度比预取更有效，因为调度并发请求可以自然地揭示专家需求并重叠计算与加载。
50%待验证当GPU内存中存在专家缓存时，预取可能是有害的，因为随着缓存中包含的必需专家越来越多，专家预测的精度反而会下降。
50%待验证在预取模式下，若预取20个字段而实际只用到5个，冗余比例高达75%。
50%待验证对于高频、小字段场景，预取往往更经济；对于低频、大字段或长尾查询，MCP的按需特性更能压缩无效开销。
50%待验证一个实用的判断标准是：如果某个字段在80%以上的推理中都会被用到，就预取；如果使用率低且体积大，就交给MCP。
50%待验证预取模式在LLM Agent语境下指在模型开始推理之前，由外部编排层提前调用数据源API，将结果格式化后作为上下文注入prompt。
50%待验证混合方案建议：小规模核心字段预取 + 按需MCP补充，以平衡可控性和灵活性。
50%待验证即便拥有未来请求先知能力的Oracle预取器，在迁移流量指标上也从未战胜不做预取的方案
50%待验证预取的难点在于准确率与带宽开销之间的权衡：激进预取占用带宽和缓存容量，保守预取无法隐藏远端I/O延迟
50%待验证常见预取策略包括基于顺序检测的流式预取、基于索引叶节点遍历路径的B-Tree预取，以及利用历史查询日志训练的机器学习预取模型
50%