图片来源：a16z Deep Dives
Z Highlights:
-
对我们这些面向专业开发者构建工具的人来说，这真是令人惊喜的时代——底层技术往往能被更广泛的人群轻松使用。
-
真正的“原子级可组合单元”不是模型，而是agent本身——也就是用户输入一段文本，系统输出一系列行为的这套“契约”。
-
eval集必然滞后于技术前沿，因为将“优质的产品体验”提炼成一组eval需要时间。
-
开源模型正变得越来越关键，开源或open-weight模型核心在于可以进行后训练。
-
要尽可能确保美国的AI生态保持活力与竞争力。最好的做法是退后一步，让自由市场发挥作用：制定一套全国统一、清晰且完善的监管标准，聚焦具体应用及其场景，而非在模型层面笼统谈论“生存风险”；同时确保模型层面的充分竞争，杜绝任何反竞争行为或监管锁定。
Beyang Liu是Sourcegraph的联合创始人兼首席技术官，深耕AI编程代理与开源模型评测，在开发者工具与AI代码生成领域具标杆影响力，被誉为开发者搜索之父。此次和a16z的访谈发布于11月25日，对谈包括了Sourcegraph的介绍及Agent理解的探讨，最后聚焦了开源编程模型的地缘格局与监管风暴。
从code search到coding agent：Sourcegraph的历程
Martin Casado：感谢你的到来。今天的主题是AI与coding。你是这一领域公认的专家，我们想深入了解你如何看待问题与解决方案。你是Sourcegraph联合创始人兼CTO，我们也会谈到这一点。同时，感谢Guido的出席。首先，请你简要介绍一下自己的背景，然后我们再深入探讨。
Beyang Liu：我从事开发者工具领域已逾十年。大约十多年前，我创办了Sourcegraph，将全球首个真正可用于生产环境的code search engine推向市场，并成功推广至相当数量的《财富》500强企业。在此之前，我曾在Palantir担任开发者，那还是“创世”时期，我也正是在那里结识了我的联合创始人Quinn。当时我们负责数据分析软件，经常被“空投”进规模庞大的企业代码库，深刻体会到理解海量代码亟需更好的工具。再往前，我的背景与今日主题亦息息相关：求学期间我主修了machine learning，曾在Daphne Kohler的指导下从事computer vision研究。
Martin Casado：Sourcegraph最初以code search navigation起家，如今你们转向发展Amp这样的一款agent产品。所以，也许你可以先整体讲一讲，在AI出现之前你们主要在做什么，以及现在具体在做哪些工作，帮大家理解一下你们的背景。
Beyang Liu：公司的早期定位，其实是为了提升大型组织内部的编程效率，让专业软件工程师能够更高效、更容易地构建软件。但从长远来看，我们的愿景一直是不断拓展业务边界。所以我们最先解决的，是一个最基础、也最痛的问题——如何让人更好地理解代码。因为在一个大型代码库里，理解代码往往要占到80%到99%的时间，真正写代码反而只是最后的一小步。正是围绕“代码理解”这一核心难题，我们逐步积累并建立起了自己的领域专长。
随着LM日渐成熟，我们在后台密切地关注着这一方向。最初，我们利用LMs与embeddings来增强自家search engine的排序信号。随着ChatGPT等应用爆发，我们立刻意识到：把LLMs这一极具突破性的技术与此前积累的能力结合是一个巨大的机会。于是，我们推出了最新产品—名为Amp的coding agent。
Martin Casado：外界普遍认为Amp是一款“高度复杂、并带有鲜明主张的agent”。你也认同这种评价吗？还是说那只是旁观者的印象？
Beyang Liu：我认为我们确实在做一些非常独特的事情。
Martin Casado：不过最近在某一个benchmark上，正好有人专门讨论了这个问题。
Beyang Liu：我们注意到市面上有家初创公司做了一个关于某种merge rate的对比测试，我们最终拿下了榜首，这让团队颇感欣慰。不过我想强调的是，在构建agent的理念上，我们确实坚持了一些鲜明的主张，我相信这些观点很快就会被广泛采纳。当然，也有一些我们正在做的事情，现在外界很容易被“过度AI化”解读。但实际上，有些成果就是靠非常简单的思路实现的，效果却很好，我们就直接上线了，而且实际运行表现也非常不错。
Martin Casado：所以你的重点放在真正的大型代码库上。那么在结构层面，它和我在家里写那种小型homebrew项目、几百行左右的coding相比，有什么不同？
Beyang Liu：过去我们确实专注于大型代码库，但在打造Amp时，我们几乎完全脱离了现有代码基线，从零开始构建。原因有二：首先，Amp目前还只有七八个月大，今年二三月启动，正值新一代agentic tool-use浪潮兴起，首次真正实现稳健的工具调用并能与推理能力组合。我们最初想把它嵌入已有产品，但随着反复试验，我们逐渐意识到：这是一场真正的技术颠覆，于是我们决定从第一性原理出发，从零重建一个agent，重新定义它到底需要哪些工具。结果就是一款在大型代码库中表现出色（获得了大量客户的落地验证）、同时又适合业余coding的产品。
我最近让父亲试用Amp，他竟然用它为孩子做起了iPad小游戏，典型的亚洲爸爸想教孩子学数学，借此练习算术。父亲从没写过任何代码，却只需一句话就能生成一个简单游戏：孩子数对数字，小火箭就发射。对我们这些面向专业开发者构建工具的人来说，这真是令人惊喜的时代——底层技术往往能被更广泛的人群轻松使用。
Guido：这正是一种全新的范式，身为家长，你无需亲自写代码，也能让Amp按照指令自动生成适合孩子学习的游戏。
广告驱动的智能体：如何在‘顶级智能’与‘全民可用’之间找到平衡？
Martin Casado：另外颇受关注的一点是，你们最近决定转向广告模式。这让我的内心有些拧巴：一方面这是一个很“精品”、很高端、很专业的产品；但另一方面它又是一个靠广告支持、给所有人用的东西。那这种矛盾的定位，到底该怎么协调呢？
Beyang Liu：我们过去素有“顶级agent、超高智商”之称，始终采用纯用量计费而非固定月费，用户因此也没有动力去换更便宜的模型。我们的策略很简单：给你最强大的智能，只需为推理成本买单。可随着功能不断扩展，我们渐渐发现，其实可以画出一条“效率前沿”，用一个2×2坐标系来描述：一轴是intelligence，另一轴是latency，在这条权衡曲线上存在多个很有价值的平衡点。
并非“最强大的模型”就一定带来最佳体验；事实上，越聪明的模型往往也比市面上其他模型慢得多。因此，我们看到一个机会：可以打造一款更快的顶级agent，虽然它无法处理特别复杂的编码任务，却能高效完成针对性的编辑。当我们开始试验这些体积小、速度快的模型时发现，其推理成本低得多。于是我们联想到像我父亲这样的用户—只是业余做点项目，不想每月花上数百美元去做这些简单游戏—或许这里就蕴藏着一套新的模型方案。一开始其实只是个玩笑，有人提议：“干脆试试做广告，看效果如何。”大家都觉得不可能奏效，但这个点子反复被提起。最终我们决定：“好吧，就做一次实验，看看结果。”于是推出后，成长速度竟然非常迅猛。
Martin Casado：我想从更哲学的角度探讨一下。之前我和一位负责Cloud Code（这是个非常成功的CLI工具）的朋友交流。他说，团队这些年所做的改进其实很简单：不断“移除”用户与模型之间的层层障碍—就这样而已。他们的思路是：少做一点，让模型做更多。从智识或直觉上听来，这确实颇有意思，也相当合理。
但从另一面看，这种做法似乎成本高昂——我们让用户直接对接的是一款耗资数十亿美元训练的最先进模型。这与广告驱动的商业模式，或你刚提到那类运行速度快、规模更小的模型，似乎形成了对立。因此，你认为业界是不是正同时走在两条并行路线？
Beyang Liu：确实，不同任务和不同使用者会形成截然不同的工作流。有些人喜欢写一段长prompt，让coding agent自行解决；等再回来看，代码已经差不多能跑了。也有人不愿这么做，因为很多时候他们自己也还没想清楚到底要什么。
创作过程往往是边走边想、逐步勾勒软件形态的。有时同一个人也会在两种模式间切换：比如实现billing功能时，我很清楚需要支持哪些协议、如何接入Stripe，以及要建立哪些反馈循环，于是就写一个大prompt，交给agent去完成；但若要开发全新的特性，这套做法就不适合了。
我们刚刚在编辑器插件里上线了代码评审面板。这让我一时难以确定理想的评审体验应当如何呈现，因为此刻我审阅的不是他人的代码，而是Agent生成的代码—这是一条全新的工作流程。面对这种情形，我更希望与Agent进行频繁的互动式往返交流。我并不认为这两种做事方式必须拆分成截然独立的产品，但它们确实属于迥然不同的工作模式。
真正的基础单位不是Model，而是Agent
Martin Casado：那么，你如何看待以下几种选择之间的差别：使用其他实验室开发的模型、自己训练模型，以及使用开源模型？这些不同选择在你们的理念里是怎么定位的？
Beyang Liu：我们的理念不是model-centric，而是agent-centric。在我们看来，模型只是实现细节；真正重要的是，当你与agent交互时，它如何响应你的输入、会调用哪些tools、采取怎样的执行路径以及内部“思考”方式。固然，这些行为与模型息息相关，却并不完全取决于模型。本质上，还有很多因素会塑造agent的表现：例如system prompt、你为它配置的工具集合、工具的运行环境及具体说明，以及你提供的feedback loops指令。同一个模型，如果配以截然不同的system prompt和工具描述，也会展现出完全不同的行为。
Guido：双向看也成立吗？也就是说，在同样的prompt下，使用两个完全不同的模型，是否会得到不一样的行为？
Beyang Liu：当然如此。你可以把它理解为：如果你有一套agent的运行框架和工具描述，然后只是把底层的模型换掉，是完全无法保证它还能正常工作的。所以在我们看来，真正的“原子级可组合单元”不是模型，而是agent本身——也就是用户输入一段文本，系统输出一系列行为的这套“契约”。而这个agent的能力，其实是模型再加上prompt、工具、环境、反馈机制等所有这些因素共同决定的。因此，当我们选择要使用哪一款模型时，并不是简单追逐某家实验室最新的前沿模型，而是先明确希望agent（或其子-agent）展现何种行为，再寻找最能支撑该行为的合适模型。
Martin Casado：这点让我很难适应，在计算机科学史上，我们似乎第一次把“正确性”和“逻辑”主动让渡给机器。过去它们只是资源：也许性能或可用性有差异，但无论是database还是compute，只要我输入什么，就能确定无误地拿到对应输出。可如今我们对模型说：“帮我把这个问题搞定。”于是核心逻辑与正确性不再由人掌控；测试回来，结果只有45%的用例能跑通。
Beyang Liu：许多人都困惑于无法直接操控模型。不过在我看来，回到没有AI的时代，计算机系统的基本可组合单元是函数调用。当我们设计系统时，一个函数调用另一个函数，而被调用的函数又会继续委派下去。我认为在agent的世界里同样存在对应物，agent就像函数在AI语境下的升级或泛化版本。
Martin Casado：我是个传统派，在我看来，计算机基础设施就是compute、network、storage，再加上数据库。这些都是抽象化资源：给我存储、给我网络，底层语义和执行逻辑都由代码严格掌控。如今我们却把“想办法”这种核心逻辑与正确性交给模型去做。同一个任务，若把model2.1升级到model2.2，输出可能天差地别，仿佛换了一套全新的指令集。
Beyang Liu：即便结果可能略有差异，只要把agent设计得当，输出就不会出现天壤之别。举例来说，我们有一个子agent，专门负责搜索并挖掘相关上下文。每次运行确实有点像掷骰子——它会选择稍有不同的执行轨迹，检索不同的内容。但如今，如果我要在代码库里查找某个东西，我有99%的把握，它最终能够通过随机迭代找到正确答案。换言之，虽然它抵达目标的路径各不相同，但当我