如何理解上下文条数、Token 与字节预算？

项目版本说明

这些问答整合历史设计与实现资料；当前 main 分支 README 以工作包描述建设状态。具体能力、实验数据与设计目标的边界见项目状态与证据。

标准回答

召回结果需要适应客户端和模型上下文限制。EachOf 在 Core 层控制条数、估计 Token 与序列化字节等预算，使 MCP、SDK 和其他入口遵循一致投影策略。排序前的候选数量与最终输出条数不是同一个参数。

当前 Token 估计不是所有模型的精确 tokenizer，中文、代码和特殊符号可能产生误差。因此需要保留安全余量和硬字节约束，客户端仍应按照实际模型窗口核算。不能把估计的 8000 Token 理解为任意模型精确接受 8000。

整条内容保留更有利于维护来源和意义；过长条目可被拒绝、单独处理或按明确策略压缩。报告应说明哪些候选因预算未进入结果，避免把裁剪误判为召回失败。摘要或压缩本身若由模型执行，也需要重新处理来源与可信边界。

额外内容可能引入噪声、冲突与截断，使真正相关的信息失去预算。应联合评价任务质量、成本和候选覆盖。

可能切掉来源、状态或关键句；如果必须二次裁剪，应显式定义协议，不能无声改变 Core 已经组织的含义。