Sourcegraph 新方案：用更少 LLM 上下文做代码迁移

随着企业扩大 AI 使用规模，Token 成本正受到严格审视。企业迫切希望借助 AI 来实现代码库的现代化改造，但失控的 Token 用量可能很快导致大型项目的成本高到令人望而却步。迁移和代码库审计类任务的风险尤其高——这类任务通常需要扫描数千个文件，而把所有中间数据一股脑塞进 LLM 的上下文窗口，简直就是成本膨胀和性能稀释的导火索。

朴素 Agent 工作流的弊病

标准 AI Agent 工作流往往将 LLM 视为任务每个步骤的唯一处理器。它们将海量数据直接拉入上下文窗口，指望模型能从噪声中筛选出信号。然而，更多上下文并不总是等同于更好的上下文。在执行迁移或审计任务时，你通常需要的是一个结构化、干净的最终结果，而不是扫描每个文件时那些原始、杂乱的中间细节。

为此，Deep Search 可以在围绕 Sourcegraph 搜索 API 的沙盒环境中运行脚本。Deep Search 不将每条中间搜索结果都喂给 LLM，而是承担起繁重的工作：它可以执行多次搜索、交叉引用数据、过滤发现项、计算汇总值，甚至生成结构化的产物（如 CSV、JSON 或 SVG 报告）。这样 LLM 收到的就只是聚合后的发现结果和最终产物，保持上下文窗口的专注与高效。

这为何改变了经济学

通过将处理工作卸载到沙盒中，你获得了三个关键优势：

• 你只需为高层洞察付费，而无需为扫描每个文件的中间处理过程付费。
• 模型不会被数千行无关的文件内容分散注意力。
• 你获得的是可靠、结构化的数据，团队可以直接基于此开展工作。

主要用例：迁移

设想一个常见的迁移场景：将服务从 old/package 迁移到 new/package。使用 Deep Search，你可以请求对仍然导入旧包的所有仓库进行完整审计。Deep Search 扫描代码库，识别相关文件，然后生成一份干净的 CSV 检查清单。你的团队随后可以打开该文件并开始迁移流程，同时确信这份报告是全面且准确的。

次要价值：更好的上下文质量

这一优势远超成本节约本身。由于 Deep Search 只向 LLM 传递相关数据，模型得以专注于综合结论，而不是充当数据处理器。这提高了获得更有用、更准确输出的概率。

对于任何搜索驱动的产物生成，Deep Search 都表现出强大能力：

• 资产清单：追踪共享服务在整个组织中的消费情况。
• 代码健康度：识别使用过时或存在漏洞的依赖项的仓库（如 Log4j 版本 < 2.17）。
• 交叉引用：跨模式比较实现，以发现不一致之处。

结论

随着 AI 应用的成熟，Token 效率正成为工程负责人关键的采购考量因素。Deep Search 的评估器为降低成本同时提升 AI 辅助开发质量，提供了一个切实可行的架构解决方案。如果你正在规划大规模迁移或审计，是时候超越标准 Agent 工作流，让 Deep Search 来处理规模问题了。

特别感谢 Justin Dorfman 和 Stephanie Jarmak 对本博客文章的贡献。

Unblock your organization. Ship faster.

With Sourcegraph, the code understanding platform for enterprise.