无限代码上下文：企业级规模的 AI 编码

企业软件开发正处于一个尴尬的境地。目前最好的 AI 编码工具是为单个开发者设计的，但真正的企业级工作意味着要驾驭数百万行代码的代码库、错综复杂的依赖链，以及任何单一提示都无法捕捉到的机构惯例。Blitzy 的赌注是，解决上下文问题，而不是模型能力，才能大规模地释放 AI 驱动的企业开发。

本期节目

Nathan Labenz 在 Cognitive Revolution 节目中采访了 Blitzy 的 CEO Brian Elliott 和 CTO Sid Pardeshi。这是一次技术含量很高的深度访谈，时长两小时，深入探讨了 Blitzy 如何构建一个系统，该系统可以摄取整个企业代码库，动态生成专门的代理，并自主完成大型软件项目。前企业软件高管 Brian 负责产品和业务叙述。曾在 NVIDIA 担任多产发明家的 Sid 则深入探讨了架构细节。对话涵盖了从基于图的代码表示到模型选择策略，再到按每行代码 20 美分收费的经济学等方方面面。

上下文是瓶颈，而非智能

Blitzy 的核心论点是：前沿模型的能力与它们在企业环境中实际交付的成果之间的差距，几乎完全是一个上下文问题。Brian 直言不讳地表示，如果你能很好地解决上下文工程问题，你就能获得“无需 AGI 的 AGI 效应”。

他们的系统可以摄取 1 亿行或更多行的代码库。不是通过总结或将它们嵌入到向量存储中，而是通过构建代码库的完整图表示，映射每个函数调用、每个依赖项、每个命名约定、每个架构模式。当任务进来时，系统不会搜索“相关代码”，而是遍历图来了解哪些文件、函数和模式对该特定任务至关重要，然后构建一个上下文窗口，为模型提供它需要的一切，而不多余。

“We use all of that to create context windows that give the model the highest chance of getting the output right the first time.” 我们利用所有这些来创建上下文窗口，使模型有最高的几率第一次就得到正确的输出。

这并不是通常意义上的检索增强生成（RAG）。RAG 通常通过语义相似性检索文本块。Blitzy 的方法是结构性的：它理解代码库的拓扑结构。如果你要修改一个函数，它知道哪些其他函数调用它，哪些测试覆盖它，哪些 API 契约它必须遵守。

构建代理的代理

Blitzy 系统在架构上最具创新性的部分是 Brian 称之为“动态工具”的东西。Blitzy 不是预先定义一组具有固定提示和固定工具的代理，而是即时生成代理。一个编排代理查看任务，检查相关的代码上下文，然后为将实际执行工作的 worker 代理编写提示并选择工具。

这意味着系统的行为不是硬编码的。涉及 React 前端的任务会获得配置了 React 特定提示和验证工具的代理。涉及 Python 微服务的任务会获得完全不同的代理配置。编排器本身就是一个代理，因此整个系统是递归的：代理构建代理，每个代理都针对特定工作片段进行定制。

Brian 估计他们有大约 78 个不同的代理模板，但实际的行为空间要大得多，因为每个代理的提示都是根据代码上下文和任务要求动态组成的。

模型动物园

Blitzy 不会押注于单一模型。他们运行 Sid 描述的“模型动物园”，根据他们在内部维护的基准，为不同的子任务选择不同的模型。

选择逻辑是细粒度的。对于规划任务，他们可能会使用一个模型。对于特定语言的代码生成，则使用另一个模型。对于代码审查和验证，则使用第三个模型。他们在模型之间进行交叉检查：如果两个独立的模型对代码更改达成一致，则置信度会提高。如果它们不同意，系统会标记它以进行更深入的分析或人工审查。

他们在模型选择中优先考虑三个属性：原始推理能力、指令遵循（模型是否真正按照你的要求执行？）以及上下文窗口利用率（模型在 10 万+ token 时是否能优雅地降级？）。Brian 指出，模型在这些轴上的优势通常差异很大，因此最佳选择因任务而异。

交叉检查方法对于安全敏感的代码尤其有趣。Sid 描述了使用一个模型生成代码，并使用不同的模型系列来审计它，其理论是不同的训练分布会产生不同的盲点。

内存优于微调

对话中反复出现的一个主题是 Blitzy 偏爱内存系统而不是微调。他们的论点是：微调成本高昂、迭代速度慢，并且会产生特定于模型的锁定。内存以结构化上下文的形式存储，并注入到提示中，从而实现类似的定制效果，同时保持模型无关性并可立即更新。

他们的内存系统捕获了多个层：

• 代码库约定：从现有代码中提取的命名模式、架构规则、样式偏好
• 项目历史：已进行了哪些更改，在以前的任务中建立了哪些模式
• 错误模式：当系统出错并且人工纠正它时，该纠正将成为内存，以防止将来出现相同的错误

“We’ve always been memory-forward. We believe that memory is going to be more important than fine-tuning for most enterprise use cases.” 我们一直以记忆优先。我们认为，对于大多数企业用例来说，记忆将比微调更重要。

这是对前沿模型持续改进的押注。如果基础模型不断改进，内存可以让你进行定制，而无需重新训练的维护成本。如果你需要基础模型根本不具备的功能，那么微调更有意义，但 Brian 认为前沿模型已经具备原始能力，它们只需要正确的上下文。

大规模规划

对于大型项目，Blitzy 将工作分解为 Brian 称之为“规划树”的东西。一个顶层规划器将项目分解为模块，每个模块分解为任务，每个任务分解为子任务。对于主要的现代化项目，该树可以深入 4-5 层。

关键的见解是，规划和执行是交织在一起的，而不是顺序的。当代理完成较低级别的任务时，结果会反馈到规划器中，规划器可以调整剩余的计划。如果代理发现某个 API 的行为与文档记录不符，规划器可以重组依赖于该 API 的下游任务。

并行性是激进的。独立的子任务并发运行，系统跟踪依赖项以确保在重要时保持正确的顺序。Brian 描述了数百个代理同时在代码库的不同部分工作的项目，其中一个协调层可以防止冲突（例如，两个代理修改同一个文件）。

每行 20 美分和最后的 20%

Blitzy 对生成的每行代码收取大约 20 美分的费用，Brian 认为这比让人工工程师编写代码便宜大约 100 倍。该定价反映了他们对输出质量的信心，以及他们将 AI 生成的代码作为企业开发的商品投入的目标。

但他们对局限性也很坦诚。他们目前的系统可以自主完成主要企业项目中大约 80% 的任务。剩下的 20% 需要人工干预，通常是因为任务涉及模糊的需求、新颖的架构决策或代码库上下文无法完全解决的边缘情况。

Brian 认为，实现 99% 以上的自主完成率主要是一个上下文和内存问题，而不是模型能力问题。更好的内存意味着更少的重复错误。更好的上下文意味着更少的模糊情况。更好的规划意味着系统可以更早地发现集成问题，而不是在最后。

奇怪的行为和评判者

Nathan 将对话引向 AI 可靠性，Sid 分享了他们在规模化过程中观察到的几个奇怪的模型行为示例：

幻觉 API：模型有时会生成对代码库中不存在的函数的调用，通常“发明”听起来合理的函数名称，这些名称遵循命名约定，但没有实现。他们基于图的验证通过对照实际代码库图检查每个函数调用来捕获这一点。

风格漂移：在长时间的生成会话中，模型逐渐偏离代码库的风格约定。他们的解决方案是定期进行“风格锚定”，系统将代码库中的风格示例重新注入到上下文窗口中。

自信的错误：模型偶尔会生成语法正确、逻辑连贯但在业务逻辑中完全错误的代码。这些是最难自动捕获的，也是他们使用跨模型验证的主要原因。

他们构建了他们称之为“评判者”模型，这些是独立的代理，其唯一的工作是评估生成代理的输出。评判者有他们自己专门的提示，这些提示侧重于常见的失败模式，他们可以在代码提交之前标记问题。

推理预算和自主性

一个有趣的运营细节：Blitzy 为不同的任务分配“推理预算”。简单、定义明确的任务（在整个代码库中重命名变量）会获得较小的推理预算，这意味着更便宜、更快的模型调用。复杂的任务（构建一个与 15 个现有服务集成的新的微服务）会获得较大的推理预算，这意味着更昂贵的模型、更多的交叉检查和更多的规划迭代。

预算分配本身是自动化的。一个初始分类器代理查看任务描述和相关的代码上下文，然后分配一个预算层。Brian 指出，这是他们最具影响力的优化之一：在重要的地方花费推理计算，并在不重要的地方节省它。

这与他们更广泛的自主性理念相关。他们并不旨在在每个任务上实现完全自主。相反，他们希望系统在可以确信的情况下实现最大程度的自主，并在无法确信的情况下尽早升级到人工。最糟糕的结果是系统花费数小时走错路，然后才寻求帮助。

“We’d rather the system say ‘I see two valid approaches here, which do you prefer?’ than silently pick one and have to redo everything.” 我们宁愿系统说”我在这里看到了两种有效的方法，你更喜欢哪一种？”，也不愿默默地选择一种然后不得不重做一切。

AI 生成代码的安全性

Sid 直接解决了安全性问题。他们的方法有多个层：静态分析工具在所有生成的代码上运行，跨模型审计捕获单模型生成遗漏的模式，并且他们维护一个已知漏洞模式库，该库会针对每个输出进行检查。

他们还在沙盒环境中运行生成的代码，然后再触及实际的代码库，检查意外行为，例如网络调用、预期路径之外的文件系统访问或资源消耗异常。

Brian 指出，根据他们的经验，AI 生成的代码的漏洞率与人工编写的代码大致相当，但漏洞的类型不同。AI 往往擅长避免常见的注入攻击（它在训练数据中看到了这些模式），但偶尔会在身份验证流程或访问控制中引入细微的逻辑错误，人工审查员可以通过推理业务逻辑来捕获这些错误。

软件工作的未来

对话以一种令人惊讶的细致入微的方式结束，讨论了这对软件工程师意味着什么。Brian 并没有预测大规模失业。相反，他看到了一种向他称之为“规范工程”的转变：精确描述你希望系统做什么的能力变得比编写执行它的代码的能力更有价值。

Sid 补充说，深入的系统知识变得更有价值，而不是更少。了解数据库内部结构、网络协议或安全模型的人可以指定 AI 能够很好地完成的任务。只了解表面编码模式的人会发现 AI 可以完成完全相同的表面工作。

他们都预测软件项目的数量将大幅增加，因为成本会大幅下降，这意味着对能够设想、指定和验证软件系统的人的总需求会增加，即使每个项目对动手编码的需求会减少。

一些观察

这是一集赞助节目，Brian 和 Sid 显然在推销他们的产品，但技术深度是真实的。对话揭示了一个团队，他们在企业 AI 部署的细节上花费了大量时间，并且有非显而易见的观点。

• “上下文优于微调”的论点是一个强有力的赌注，它与模型格局的演变方式相一致。如果前沿模型不断改进，那么注入正确上下文的系统将优于在昨天的模型上进行微调的系统。
• 动态代理架构（代理生成代理）是企业用例组合爆炸的一个优雅解决方案。你无法为语言、框架和业务领域的每种组合预先构建一个代理。但是你可以构建一个构建正确代理的代理。
• “推理预算”的概念值得更广泛的采用。大多数 AI 编码系统在琐碎和复杂的任务上花费相同的计算量，这既浪费又不是最佳的。
• 他们对“最后的 20%”的坦诚令人耳目一新。诚实的框架不是“AI 取代开发人员”，而是“AI 处理 80% 的定义明确的工作，从而将人类解放出来，去做需要判断的 20% 的工作。”
• 跨模型验证安全方法非常聪明。使用不同的模型系列作为独立的审计员利用了不同的训练分布会产生不同的盲点这一事实。