深度｜AI编码黑马Sourcegraph华裔联创：我们的理念不是以模型为核心，而是以Agent为核心

图片来源：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%的把握，它最终能够通过随机迭代找到正确答案。换言之，虽然它抵达目标的路径各不相同，但当我需要完成某项具体任务时，它已足够可靠，可以放心调用。

评估与帕累托权衡：质量-延迟-成本的三角平衡

Martin Casado：现在整个行业好像开始有点“反评测”的情绪了。那你觉得这到底是评测本身出了问题，还是其实是运行时系统层面的问题？

Beyang Liu：我认为evals的价值就在于，它们作为unit test或smoke test的工具时非常有效。当你向agent推送变更导致某处出错时，你希望及时获知—尤其对于那些关键workflow，理应始终保持稳定；一旦它失败，很可能其他模块也随之崩溃。这时，eval就能在结果从绿色变为红色时立刻发出警报，这很有价值。

我认为问题变得棘手的地方在于把eval当作优化目标。任何eval集都必须回答一个核心问题：当你在构建面向终端用户的产品时，真正关心的是产品体验，因此你会设计eval集来近似用户在使用产品时的主观感受。由此可见，eval集必然滞后于技术前沿，因为将“优质的产品体验”提炼成一组eval需要时间。过去我们多次经历这种现象。举例来说，在2023年前后的代码补全阶段，我们有一款实现自动补全的编码工具，当时最显眼的关键指标是补全接受率—即系统向用户提出修改建议后，用户接受的概率。乍看之下似乎滴水不漏，但在实际构建过程中，我们对该指标产生了一定程度的过度优化。任何指标都可能被“刷分”，即便是这个看似可靠的指标也不例外。

Martin Casado：开发者也许点了接受补全，但最终真的把这段代码提交了吗？就算提交了，在PR审核环节也可能被修改或被退回。这引出了Guido与我常探讨的议题：市场在多大程度上处于帕累托前沿（Pareto frontier）？换言之，当性能与成本、智能与成本需要互相权衡时，市场会统一采纳某种折中方案，还是只追求速度或只追求正确性？作为一线从业者，我们希望听听你的看法。我们经常提出这个简单的问题，却始终得不到明确答案。

另外，传统定价心理学认为，产品要么定位为高价，要么定位为低价，中间区间被称为“价值缺口”，消费者通常不会选择。起初我们也持这种看法：要么买最贵的方案，要么选最便宜的。实际上，我们观察市场时发现，最前沿的区间几乎已被占据；开发者整体非常成熟，对成本与价格的敏感度也各不相同。

Beyang Liu：也就是所谓的“低价方案vs高端方案”。对于Amp，我们提供两种顶层Agent：Smart Agent和Fast Agent。Fast Agent依靠广告支持，可免费使用；Smart Agent则始终按用量计费，以保持最前沿的智能水准。但话也不能说死，我也觉得也许在这两者之间，还会出现一个比较合理的“Mid Agent”。这种东西到最后其实更多还是看使用过程中的直觉判断—随着我们越来越重度地使用这些Agent，并逐渐观察到真实的用户使用模式，也许未来会自然浮现出一种Mid agents的形态。

开源模型如何真正落地？答案是：后训练比预训练更重要

Martin Casado：如果可以的话，我想深入了解你对开源模型的看法。你们会使用开源模型吗？你认为它们是生态中的重要组成部分吗？

Beyang Liu：是的，我们确实同时大量使用open source模型与closed source模型；不过，开源模型正变得越来越关键，原因有二。首先，开源或open-weight模型核心在于可以进行后训练。对于某种领域专用任务——例如Amp里日益增长的sub agent，像联系方式检索（context retrieval）或额外推理与依赖库拉取（extra reasoning+library fetching）——这类任务范围更窄，不必依赖前沿级的通用智能，反而更看重速度。而open-weight模型的优势在于，我们可以围绕目标进行后训练，让sub agent朝着“更适合这个任务”的方向优化。其次，开源模型的价格优势显著。如今涌现出越来越多性价比极高的open-weight模型，并且在agentic tool use方面表现稳健。从今年六月以来，整个格局剧变：过去真正优秀的agentic tool use模型只有一款，如今已出现多款可用选择。

Martin Casado：你能把它们的名字说出来吗？如果方便公开的话。

Beyang Liu：最早的agentic tool-use模型是Claude（版本包括Sonnet和Opus），可以说它掀起了当前这一波agent浪潮。如今已出现更多选择，例如GPT-5、Kimmy K2、CNFReCoder GLM等。

Martin Casado：这些类似的开源模型非常接近。

Beyang Liu：这取决于具体工作负载。在我们的评估中，用作顶层Smart Coding Agent驱动时，仍首选Sonnet或GPT-5；而对于快速的定向编辑或某些sub-agent，团队越来越倾向于采用体量更小的模型，因为它们延迟更低，且任务复杂度有限——质量达到一定水平后便出现边际效益递减，此时继续降低延迟能带来更佳的交互体验。

Guido：要实现一款表现出色的agent，所能使用的模型规模最小能到什么程度？

Beyang Liu：就目前而言，若要驱动一款顶层agent，所需的模型规模仍相当可观，大约要达到数百亿乃至数千亿参数。若只是search agent，规模可以再缩小一些。另外，我们还有一类专门用于edit suggestion的模型——当你需要手动修改代码时，它会给出下一步编辑建议。这类场景使用的模型非常小，仅需“个位数十亿参数”即可。

Martin Casado：你训练自己的模型吗？

Beyang Liu：我们确实会这么做，但要说明的是，我们并不会从零开始训练这些模型。现在基本已经不会再做预训练了，那样不太明智。在这个阶段你再去从头训一个模型，无论是花钱还是资源投入上，都显得不太负责任，而且大概率也没什么实际意义。

Martin Casado：这些其实更多是一些特定场景下的应用，不只是写代码，我们合作的很多产品也是类似的情况。现在业内普遍有一种看法：大规模预训练这条路基本已经走到一个经济平衡点了。你当然还能继续花钱请人造数据，但回报已经在明显递减——你需要更贵的人力，还要成倍增加数据量，才能换来有限的提升。但另一方面，现在真实的产品数据、用户数据其实非常多，而且整个应用空间非常大，所以就很自然地可以开始去做更小、更专用的模型。所以我想确认两点：第一，这个判断是不是成立；第二，你们现在训练的模型是不是也正好符合这种“面向具体场景的小模型发展路线”。

Beyang Liu：确实如此。规模庞大的generalist models在早期实验阶段非常出色，因为它们训练于多样化数据，本身就像一次探索，连训练团队都难以预料会涌现哪些行为。但当需求被映射到具体工作负载和目标agent后，目标就清晰得多。业内普遍做法是，在后台使用多模型路由：API表面看似只暴露一个模型，实际上会按任务切换到更小的模型。应用层同样可行——如果采用agent architecture，可将软件开发流程拆分为context fetching、debugging等专门任务，为每个任务配置专属agent，再根据其成功所需条件，挑选参数尽可能小且符合质量标准的模型。

Guido：所以这不仅只是“质量-成本”这一条效率前沿，而是涉及多维度、多条曲线的组合考量。

Beyang Liu：基本上，每个agent都对应一条工作流，模拟某种人类流程——也许与人类曾经执行的步骤大致重合，也许并不完全相同——但本质上它就是一个子程序。这也是我始终回到“函数类比”的原因。

Guido：现在有了可调参数：你想要多强的reasoning？希望agent具备多大的能力？预算又是多少？

Beyang Liu：每项任务都有一条自己的小型帕累托前沿，而沿着这条前沿的最优点因任务而异。

十年展望：IDE与CLI终将让位于多Agent协作面板

Martin Casado：我想深入讨论开源模型及其影响——我知道你有看法，我们也有看法，这的确是个有趣的话题。但在此之前，想请教：十年后，我们还会使用IDE吗？还是会在CLI里直接调用agents？软件工程将会变成什么样？

Beyang Liu：在我看来，未来的开发环境既不会像任何现有的IDE，也不会像今天习以为常的terminal。AI对所有知识领域（包括coding）的影响，是让人类实现能力跃升：你现有的工作内容将被升级，就像过去一年里我的岗位已发生巨大变化。回想一年前还在逐行修改代码，如今已完全陌生。我现在主要通过指令让agent执行特定编辑或完整计划，自己更像协调者；只有agent卡住时才偶尔手动介入。以代码行数计，目前超过90%都是借助Amp生成，且比例仍在上升。由此可见，未来的核心界面应能让人类编排多位agent的协作，并帮助理解其输出要点——这正是当下的瓶颈所在。

Martin Casado：当然，把人类的理解能力在线化。这回到我对问题需求的认识：即便在企业级规模，也存在系统层面的根本权衡，这些权衡无法回避。

Beyang Liu：这些权衡无法凭空消失，人类仍是瓶颈。不过我认为，在未来十年里人类依旧至关重要，软件工程始终是一项本质上的创造性工作。

Martin Casado：我想确认我们讨论的是同一件事：人脑中清楚自己想达成的目标，这份认知只有人类具备，往往需要在两种权衡间选定落点，因此必须找到能够清晰表达这一需求的方式。

Beyang Liu：是的，如今与开发者交流时会发现，他们心情颇为矛盾：一方面惊叹agent能写出大量且质量不错的代码；另一方面却发现自己有约90%的时间都在做代码评审。真正热爱代码评审的开发者恐怕百里挑一，其余人都觉得这工作相当吃力。

Guido：同时自己却成了“代码中层管理者”。

Beyang Liu：没错。许多开发者坦言，他们的生产效率前所未有地提升，但coding却不再有趣——而让coding重新变得“好玩”，正是我们想要解决的关键痛点之一。

Guido：优雅已不复存在，一切都只剩下对实现需求的审视。

Beyang Liu：是的，但问题还在于代码审查这件事本身就很枯燥；传统的代码评审界面并不好用，我认为它们从来也谈不上好用，只不过以前不那么显眼，因为代码提交的速度没有现在这么快。

Guido：举个再简单不过的例子：现在只要审查任何coding agent生成的代码，通常都是按文件逐个查看——一个文件接着一个文件，把这些按任务来分组，或者用小提示说明其中的几个错误。

Beyang Liu：确实如此，当下还有大量“低垂果实”有待采摘。上周我们在编辑器扩展中推出了代码评审面板，虽然仍不完美，但已远胜现有的代码托管评审工具。令人惊叹的是，如今机器人可以一次性生成大规模变更，而我们却仍需在GitHub PR中不断点击“expand hunk”展开差异，没有code intelligence，也无法编辑图表。感觉就像我们已经拥有一台法拉利发动机，却仍不得不把它绑在马车上使用。

开源编程模型的地缘格局与监管风暴

Martin Casado：时间有限，因此我想深入探讨政策层面的问题，因为模型的发展路径在很大程度上决定了行业走向。开源生态如今遍地开花。假设一家产品型公司现在决定自行post-train模型，几乎一定会选用open-source model；而越来越多的优质模型来自中国。你方才提到自己也使用中国的open-source模型。对此依赖关系，你怎么看？它会带来哪些潜在影响？再放大到美国及整个生态层面，这意味着什么？

Beyang Liu：首先就我们的生产环境而言，所有调用的模型都部署在美国服务器上；在信息安全层面，这是业界通行的最佳实践——绝不直接调用部署在中国的模型。但从更宏观的角度看，形势仍令人担忧。我认为，随着模型版图演进，不同模型的能力将逐渐趋于平坦化：在同一Pareto frontier（帕累托前沿）上，会出现多款性能相近、价位不同的选择。对应用层开发者来说，一旦能力差距缩小，就会倾向于选用开放权重（open-weight）模型，便于post train并节约成本。目前最强大的open-weight模型多源自中国，这意味着全球开发者在微调和部署时大量依赖这些模型。如果美国的open-weight生态跟不上步伐，未来世界可能会大规模转向、对中国模型形成深度依赖，这对美国及整体生态都是潜在风险。

Martin Casado：我们现在是否有具竞争力的美国开源模型？我想，如果把目光放到欧洲，也许会看到更优秀的非中国模型。

Beyang Liu：我们对目前的大部分模型生态都做过抽样评测——毕竟我们拥有众多sub-agent和agent，需要为每项任务找到最佳模型。坦率地说，在agent工作负载上表现最出色的模型几乎——可以说全部——都源自中国。这并非美国公司没有付出努力，而是当这些模型被放入agentic application时，其tool use的稳健性仍显不足，整体水准尚未到位。

Martin Casado：你认为这主要是政策、资金等因素造成的吗？

Beyang Liu：我认为可能是以上所有因素共同造成的。

Martin Casado：最简单的说法当然是“是的，这主要源于监管等因素”，但我并不确定这说法有多准确；实际上，情况要复杂得多。

Beyang Liu：有趣的是，AI革命诞生并发轫于西方。我认为，目前美国在技术栈的几乎所有环节仍占据领先地位——无论是chips还是frontier intelligence，基本上只有open-weight models这一块例外；至于electronics，则属于制造层面的范畴。从我的视角回看，若把时间拨回到AI革命的“早期”（大约2022年左右），当时占据主导的叙事都是围绕AGI：这项看似魔法般的新技术前所未有。舆论普遍宣称AGI指日可待，而它的含义只有两种极端：要么迎来乌托邦，所有问题迎刃而解，AGI将替我们打理生活；要么走向末日，它会彻底消灭人类，类似《终结者》那样的末日式结局。从事后视角来看，当时那种对模型格局的判断可以说相当准确。但真正直接使用这些模型的人很快就意识到：它们确实能够模拟某种智能，但本质仍主要是模式匹配——绝无可能突然“自我觉醒”，伸手危害人类。

如今，与从业者交流——无论是构建系统的人还是使用者——都会指出：ChatGPT已发布三年多，几乎人人用过，也都明白它的局限性。在我们的圈子里，那套“AI将接管世界”的论调基本被打破。但在其他领域，这种说法却自成气候，并已渗透到美国部分政策制定层面。

Martin Casado：问题的一部分在于，并非每位政策制定者都在日常使用语言模型。

Beyang Liu：我也说不准。常言道，究竟应怪无知还是恶意？一切都是黑箱，但这种说法显然荒谬，却仍被一些人认为符合国家利益：第一，它把模型过度神化，好像模型就是AI的全部；而现实中，关键是把模型推动到各个应用场景，让其真正落地成可用系统。第二，在制定相关法律法规时，若被“终结者”式叙事左右，你对风险的容忍度、对生态创新的开放度，以及对模型权重开源的接受度都会截然不同。

Martin Casado：我们经常讨论一个问题：在当前的政策环境下，即便拥有无限的资金和人才，我们是否仍能打造出具有竞争力的模型？抑或说，如果政策不变，我们就注定处于劣势——是否已经太晚，无法在不改变政策的前提下实现这一目标？举个例子：我不明白OpenAI为何以那种方式发布开源模型，但他们显然对模型所用的数据极为敏感。我猜这主要出于版权顾虑，不过具体原因我也不确定。并且我觉得很反常——Meta已经很久没有推出新模型，美国也几乎拿不出真正的开源模型，已有的尝试似乎还都受到各种限制。有人认为这并非技术或资金问题，而是政策掣肘已现。请问你同意这种看法吗？还是说我们只是尚未真正投入，未来仍能推出有竞争力的开源模型？

Beyang Liu：说实话，我也不知道。我并不了解这些研究机构内部的具体情况。

Martin Casado：很令人惊讶的是，美国曾率先推出开源模型（例如Llama3），如今却普遍转而使用中国模型。那美国模型去哪儿了？为什么没有新进展？我猜这与围绕开发者责任的舆论、政策监管、版权纠纷以及各类诉讼有关，导致很多团队投鼠忌器、不敢轻举妄动。

Beyang Liu：很可能确实如此，而且当前的监管格局演变也无济于事。今年早些时候，联邦层面曾试图制定一套统一的AI模型监管标准，但最终搁浅。结果就是，我们正在缓慢（有时又迅速）地走向各州各管一套的“拼布式”法规，这对行业发展非常不利。

Guido：州级法规规定，任何人在该州提供模型都必须遵守该法规。理论上，只要一个州率先出台此类规定，其他州就会尝试把自己的政策推向全国。

Beyang Liu：措辞非常含糊，留下了过大的解释空间；我认为这从来都不是好事。

Guido：这些问题尚未经过充分的司法检验，对吧？结果就是大大增加了复杂度。对一家小型初创公司而言，如今要打造开源权重模型几乎难如登天——毕竟，谁愿意冒这个风险？

Beyang Liu：这让我想起当年第一次研究GDPR合规时的情景。我和公司法务及外部律师逐条阅读法规，判断我们的做法是否技术性违规，却发现条文非常宽泛。法务的结论是：细则不足，最终如何定性要看主管部门里哪位决策者拍板；只希望他们先盯“大鱼”，别先来找你麻烦。

Martin Casado：有点讽刺的是，这反而等于送给那些大型社交平台巨头一份“超级大礼”，因为真正能应付这些法律、政治问题的，只有它们那种规模的法务团队和政策团队。我们作为投资人也近距离看到了这一点：这些问题一出来，其实基本上就把原本的行业格局给“固化”住了，反而进一步巩固了原有巨头的地位。那我也顺着这个话题想问一个快一点的问题：如果从你的角度来看，未来在政策层面，美国应该如何去支持开源生态的发展？你会给出怎样的建议？

Beyang Liu：要尽可能确保美国的AI生态保持活力与竞争力。最好的做法是退后一步，让自由市场发挥作用：制定一套全国统一、清晰且完善的监管标准，聚焦具体应用及其场景，而非在模型层面笼统谈论“生存风险”；同时确保模型层面的充分竞争，杜绝任何反竞争行为或监管锁定。简言之，别让当年Internet Explorer与Netscape在互联网1.0时代上演的垄断剧本在AI领域重演。

原文：The Truth About Coding Agents: Why 90% of Your Time Is Now Code Review

https://www.youtube.com/watch?v=Jxz4GJSG8ZA

编译：Tinghuan Wu

文章来自于“Z Potentials”，作者“a16z Deep Dives”。