超越grep：为何需要上下文丰富的AI编码工具

# 超越grep：为何需要富上下文的AI编码工具链 来源：https://arstechnica.com/ai/2026/07/beyond-grep-the-case-for-a-context-rich-ai-coding-harness/ Augment Code的Vinay Perneti谈模型、工具链和上下文。 Augment Code工程副总裁Vinay Perneti在演讲中发言。图片来源：Augment Code 目前市面上有许多AI编码应用，虽然大语言模型及其驱动的智能体令人印象深刻，但AI辅助开发领域近期许多最新进展并非仅仅来自模型本身，还来自管理这些模型的软件。 今年初夏，我曾与Anthropic旗下Claude Code的产品负责人Cat Wu交流过该公司构建这类软件的方法。 在我们的对话中，Wu反复强调同一个观点：Anthropic的模型（以及其主要竞争对手的模型）改进速度如此之快，以至于预先规划太久或围绕它们构建主观或限制性功能意义不大。相反，Claude Code产品团队试图维持他们所谓的“精简工具链”（lean harness）。 工具链是围绕一个或多个AI模型构建的软件，它决定了模型的使用方式：模型能看到什么、能采取什么行动、以及如何与代码库交互。你可以把它想象成模型与开发者实际项目之间的一层中间件。 这并不是说Claude Code作为一个应用和工具链没有任何主观功能或设计选择，但其产品团队似乎更倾向于相信模型在未来一年的发展方向。 然而，除了Claude Code之外，还有其他工具链。比如OpenAI的Codex、Google的Antigravity、OpenCode等开源替代方案，以及Cursor或Augment Code等初创公司的选择。每种工具链在模型如何或应该如何用于智能体工作流方面，都有不同的功能、侧重点或理念。 Claude Code的一个关键选择是：默认避免采用预先为代码库构建结构化上下文的方法。 “根据评估结果，我们没有看到这些方法带来可测量的变化，”她在谈到这些方法时说，“而且我认为我们总体上倾向于发布更精简的工具链，自带较少的主观工具，让开发者自己添加他们想要的功能。” Augment Code则做出了截然不同的押注，尽管两家公司不一定在测试相同的干预措施或优化相同的目标；Augment的产品使用嵌入（embeddings）、检索模型和向量数据库对仓库进行预索引，然后检索概念上相关的代码。为了了解这场讨论的另一面，我与Augment Code工程副总裁Vinay Perneti进行了交谈。 Perneti简要介绍了Augment Code的不同方法，阐述了他所在团队对这些优势的评估，回应了支持精简工具链的一些论点，并就开发者对AI工具和更广泛的智能体工作流的某些担忧分享了自己的看法。 ## 与Vinay Perneti的对话 *本采访经过编辑，以追求简洁明了。* ***Ars Technica**：能否解释一下Augment Code的上下文引擎是如何工作的？* **Vinay Perneti**：那么，退一步讲，一个特定开发者想要实现什么？他们想要完成一个特定的任务，然后把它交给一个智能体。而当前智能体的一个有趣之处在于，它们的上下文窗口有限，每次都需要去获取完成该任务所需的所有上下文，然后进行处理。 有两种获取上下文的方法。一种是基于grep的。Claude Code、Codex和其他智能体都采用了这种方式。第二种是语义检索。对Augment来说，我们一直走的是语义路线，我来描述一下它的构建块。 我认为有两个核心部分。一是我们在系统中使用了一对嵌入和检索模型，二是一个向量数据库以及一个高度优化的后端系统，使得可以在亚毫秒级时间内完成检索。 ***Ars**：这种方法在某种代码库上是否比另一种更有优势？* **Perneti**：是的，实际上它的优势体现在大型、私有的代码库中。我为什么这么说呢？ 对于所有公共的开源仓库，大多数基准测试都是在其上运行的，每个模型基本上都已经记住了这些仓库。这些模型足够大，以至于它们能够记住整个仓库。所以当你试图完成某项任务时，模型基本已经知道该去哪里找，从而能快速得到结果。 而当你在一个私有仓库中操作时，模型从未见过那个仓库。此时，找到结果的迭代循环就会长得多，对吧？如果你对整个私有仓库有语义理解，那么你提出一个问题，就能更快地得到那些结果。 ***Ars**：人们担心代币效率。这种语义方法是否有助于改善这一点？* **Perneti**：我们在某些情况下确实看到了效果。事实上，我们发布了一篇博文——我们在Terminal-Bench上测试了Claude Code和Augment Code，使用相同的模型。我们以相近的准确率完成了任务，但效率比Claude Code高出33%。所以我认为，这在更有效地利用代币方面确实有所体现，因为你没有在探索方面花费那么多时间。 ***Ars**：Anthropic告诉我，Claude Code在评估中并未看到包含更多语义代码导航工具带来的可测量增益。但我看到你们的博客，你们发布的基准测试和其他说法则认为这种方法确实有帮助。当你们这么说时，你们衡量的是不同的东西，还是他们的评估遗漏了什么？* **Perneti**：好问题。我不知道他们具体使用了什么检索引擎，而且我认为人们经常犯的另一个错误是，并不是所有检索系统都一样，就像不是所有数据库都一样，对吧？我的意思是，协同工作的模型和系统，也就是上下文引擎，对结果质量也有很大影响。 例如，在Augment，我们在公司成立之初（2022年，早于ChatGPT）就花了大约18个月，主要针对大型代码库研究检索和嵌入模型。因此，我们在研究上投入了大量精力，以确定当你想实现某个特定结果时，应该将哪些正确的代码片段放入这个嵌入空间中。所有这些都编码到了我们的检索模型中。 并且，以非常、非常快的方式做到这一点，就是我们围绕它构建的系统。所以，当有人说‘嘿，我试过Claude Code搭配RAG实现，但没有看到好处’，那是因为具体的实现和上下文引擎是非常、非常不同的，这样说你能理解吗？ ***Ars**：有一种观点认为，模型改进如此之快，以至于基于任何假设来构建任何东西都没有意义。这就是支持超级精简工具链或不进行任何这类预构建的论点——只是因为你不知道六个月或十二个月后情况会怎样，毕竟呈指数级增长。你怎么看？* **Perneti**：这一点很有道理，但我认为你需要从几个不同的角度来思考。 在Augment，我们一直以来的想法是，要获得更高质量的结果，需要两个要素：智能（intelligence）和上下文（context）。当模型变得非常好时，智能无疑会呈指数级提升。但仅仅因为它们更智能，并不意味着它们就拥有了上下文。 现在，一个人可以通过消耗代币来获取他们想要的上下文。这就引出了第二个维度，也就是目前所有工程领导者都在关注的问题：成本。你的代币预算中有多少用于收集上下文和产生正确的结果？你是否以正确的方式使用模型来获得最高质量的结果？ 我认为这就是工具链设计和上下文发挥作用的地方。所以对我来说，这是智能和上下文的组合，然后就是一个系统工程问题：如何将适当的精力投入到这些垂直领域中，从而以最低的成本获得最优的结果？ ***Ars**：我们有不少读者对AI在软件开发中的应用持怀疑态度。我注意到两个特别常见的反对意见。**一是他们仍然觉得无法足够信任这些系统，认为它们会产生不值得冒的技术债务。二是这些智能体工作流太昂贵了。**你怎么看？* **Perneti**：我会涉及这两点。让我先为这两点做个铺垫。我认为我希望大家都同意的一个基本事实是，模型正在以指数级速度持续改进。所以无论你在做什么，你都希望顺应这种指数增长，以便理解事物的发展方向，并让自己从中受益。 回到你关于信任、验证和技术债务的问题。如果你把这个问题看作是‘我把任务交给智能体然后就走开’，那确实是有问题的。但这不是它运作的方式，这就是为什么我要指出，这是人类团队与智能体团队协作，在许多环节人类仍然更适合做出判断，对吧？规格评审就是一个例子。我们发现智能体实际上不擅长编写规格说明。因此，你必须与智能体密切合作，引导它写出高质量、高标准的规格说明。但一旦你有了规格说明，我们就到了一个位置，它们非常擅长执行。所以不利用这一点是没有意义的。 第二件事……顺便说一句，技术债务实际上是非常真实的。我们在Augment内部注意到的一个模式——我们显然非常倾向于智能体——是智能体非常擅长重复代码……所以我们发现，我们不得不进行专注的冲刺，用智能体来减少技术债务。其美妙之处在于，你可以制定一个关于如何减少技术债务的规格说明，而它们非常擅长执行这一点。所以我认为这是解决这部分问题的方法。 第二部分，你谈到了成本。我认为这里有一个有趣的点。如果你相信这是未来的工作方式，那么你如何为你的代币获得最佳结果？这就是我认为像上下文引擎这样的东西能发挥作用的地方。对我来说，为正确的任务选择正确的模型会产生巨大的影响。 第二点——这更像是哲学和前瞻性的思考——随着这些模型能力持续以指数级改进，并且开源模型也会跟上步伐，将会有一个时刻，我认为流向前沿实验室和开源模型的代币比例将开始转变。那时，你最困难的问题可能仍然会交给前沿模型，但我描述的那种编码步骤——比如我确切知道需要做什么，并且我已经在规格说明中描述了它——一个开源模型可能就能为你完成。到那时，你的成本会下降很多，对吧？所以你需要一个允许你这样工作的系统，我认为成本问题会自行解决，这就是我的看法。 ***Ars**：谢谢。感谢你抽出时间。* **Perneti**：是的，我很享受这次聊天，Sam。 ## 要点总结 Wu和Perneti都同意，他们预计前沿模型在未来至少一年内将继续以当前甚至更快的指数级速度改进。（两人都没有明确讨论更长的时间框架。）两人都同意，这正在从根本上改变许多组织的软件开发方式。 如果存在实际的分歧，那就是上下文应该预先组装好，还是在每个任务期间重新发现——尤其是在大型私有代码库中。 他们有时也在衡量和优化不同的东西。Wu特别指出，Anthropic没有发现“几个可用的LSP”能带来“性能上的可测量改进”。需要注意的是，Wu在说这句话时描述的（LSP，即语言服务器协议）并不像Augment Code的工具链所做的那样广泛。 当Perneti和Wu描述超越grep的工具或系统的评估时，他们并不总是在谈论同一件事。这是（除其他原因外）他们得出不同结论的一个可能原因。 Perneti能谈到而Wu没有谈到的一点是，像Anthropic的Opus或Fable这样的前沿模型可能会变得过于昂贵，以至于无法继续成为开发者和组织智能体工作流中的主要或唯一模型，而更小或开放权重的模型可能会得到更广泛的应用。 随着计算资源紧张状况的持续，一些开放权重模型——包括那些足够小且量化程度足以在本地硬件上运行，或者至少在组织内部维护的硬件上运行的模型——现在在某些编码任务上已经接近近期前沿模型的性能。它们也很有可能继续以快速改进，从而成为许多团队和项目中编码智能体的可行选择。团队可能会越来越多地将昂贵的前沿模型保留用于最困难的问题，同时将更常规、规格明确的工作路由到这些更便宜或本地运行的模型上。 无论哪种方法在一年后占据主导地位，更自主的工作流并不会消除工程判断的必要性。相反，随着生产速度和规模的提升使得糟糕决策的成本更高，工程判断可能变得更加有价值，而不是更少。 Samuel Axon的照片 (https://arstechnica.com/author/samuelaxon/) Samuel Axon是Ars Technica科技和游戏报道的编辑主管。他涵盖物理AI和生成式AI、大语言模型、软件开发、游戏、娱乐和混合现实。他在Engadget、PC World、Mashable、Vice、Polygon、Wired等媒体撰写游戏和技术文章近二十年。他曾运营一家游戏行业的营销和公关机构，领导过电视网络CBS的编辑工作，并在创意代理公司SPCSHP为三星移动制定社交媒体营销策略。他还是一名独立软件和游戏开发者，为iOS、Windows和其他平台开发应用，毕业于德保罗大学，学习交互媒体和软件开发。 9条评论 (https://arstechnica.com/ai/2026/07/beyond-grep-the-case-for-a-context-rich-ai-coding-harness/#comments) 1. “最多阅读”栏目第一条故事配图：印度首枚私营研发火箭戏剧性首飞进入轨道 (https://arstechnica.com/space/2026/07/indias-first-privately-developed-rocket-reaches-orbit-on-dramatic-debut-launch/)