为编程模型提供正确的上下文

作者将编程智能体的上下文构建定义为一个严格的 Token 预算问题，而非简单的检索问题。由于代码的 Token 化率约为 3 字符/Token（约 10 Token/行），即使是 1M Token 的窗口也只能覆盖 100 万行代码库的 10% 左右。解决方案是发送签名（路径 + 导出符号）而非完整正文，从而将 Token 成本降低 10-100 倍。由于扁平的签名索引仍可能超出预算，因此必须通过基于图的传播（在导入图上运行 PageRank）进行排序，并以任务提及的文件作为种子，从而捕捉词法搜索会遗漏的依赖关系。剩余预算按优先级自顶向下分配：核心文件提供完整正文，次级文件提供签名，其余则不提供。高价值上下文包括：带有精确输出的失败测试、需要修改的 2-3 个文件、它们之间的接口、一个现有的模式示例以及版本锁定。主要的 Token 浪费源于：生成的文件/锁文件/压缩文件（需要明确的忽略列表）、重复的文件包含（按路径去重并保留最新版）以及过时的聊天历史。排序同样至关重要：Liu 等人 (2023) 的研究表明检索准确率呈 U 型分布，因此指令和失败测试应放在最后，大宗参考资料放在中间。这种排序还符合 Prompt 缓存机制——稳定的前缀（仓库指令、签名索引）在前，半稳定内容（任务文件）在中，易变内容（对话记录、指令）在后。缓存行为因供应商而异，需通过单次请求的缓存报告进行验证。