Nexus：让智能体不必每轮重读工具说明书

导语

在 MCP 等工具调用框架中，智能体每轮对话都可能重新处理一批冗长的工具 schema。工具数量增加后，预填充阶段的计算和上下文占用会迅速成为 time-to-first-token（TTFT）的主要瓶颈。Nexus 试图把“找到该用哪个工具”和“理解全部工具说明”拆开，从而减少不必要的 schema 计算。

核心做法

• 先检索，后生成参数。 Nexus 建立 INT8 语义查找缓冲区（SLB），并用经过校准的交叉编码器 margin gate 筛选工具。模型不再每轮把整个工具注册表放入主上下文，而是根据请求检索候选项。
• 使用压缩签名。 参数生成依赖工具的文本签名，而不是依赖拼接进上下文的完整 KV-cache。该签名的中位长度约为 19 个 token，因此可以显著减少主上下文中的 schema 内容。
• 将 KV 拼接作为辅助路径。 对已经编译的 schema KV block，Nexus 尝试直接移植到当前上下文。但这条路径并非无条件安全：RoPE 会让不同位置的相位发生变化，偏离原锚点后可能破坏注意力结果。
• 出现风险时逐步修复。 当上下文深度超过 P=256，系统采用深度自适应的后缀重新解码；必要时升级为完整重预填充。这里的“永不退化”主要指输出保真度，而不是延迟始终更低。

实验读数与边界

在 Qwen2.5-14B-Instruct Q4_K_M、Apple Silicon 统一内存环境中，检索式路由在工具规模扩展到 250 个时，准确率仍接近 89%；相比完整 schema 重预填充，首个参数 token 提前到来约 1.66 倍，主上下文 token 约减少 80%。同样的规模下，简单拼接全部 schema 已无法容纳于上下文窗口。

KV 拼接在中等深度可以带来约 1.1 至 1.7 倍 TTFT 加速，但随着上下文变深，优势会收窄至与基线相当。修复机制还能保持 top-1 输出一致性，KL 散度接近 0，不过个别阶段延迟可能先降至基线的 0.98 倍。论文还报告，单纯依赖无参考 drift gate 预测位置漂移并不可靠，Spearman 相关系数只有 0.193。

意义与影响

Nexus 的关键价值不在于证明 KV-cache 可以随意搬运，而在于给出了更稳妥的优先级：工具路由应尽量与完整 schema 预填充解耦，KV 拼接则应被视为有明确边界、需要回退机制的优化。对于拥有大型工具注册表的智能体，这种设计可能降低 TTFT 和上下文压力；但其数字表现来自单一模型、量化配置与硬件组合，不能直接外推到其他模型。未来评估还需要覆盖不同 RoPE 实现、上下文长度、模型规模和真实工具调用分布。

arXiv