别训练模型，Factory 创始人说应该去淘金

在红杉资本的《Training Data》节目中，主持人 Sonya Huang 和 Pat Grady 请来了 Matan Grinberg 和 Eno Reyes。两人是 Factory 的联合创始人，这家创业公司成立十三个月，卖的是他们称为 droid 的自主软件工程系统。Grady 开场先说，两人都欣赏一封写得很漂亮的冷邮件。Grinberg 在普林斯顿读本科、主修弦理论时，给高等研究院（Institute for Advanced Study）的 Juan Maldacena 发过一封邮件。这家机构的特别之处在于，它不用招收研究生，更不用带本科生。Maldacena 几乎会和任何人在黑板前谈上两个小时，然后悄悄丢给你一道题，让你二十四小时内做出来。Grinberg 之前听研究生们提醒过，于是通宵做题，后来还和他合作发表了一篇论文。

第二封冷邮件发给了红杉资本的合伙人 Shaun Maguire，他同样出身弦理论。Grinberg 在伯克利读博一年后意识到，自己做理论物理，只是因为它难，谈不上热爱。他的研究已经从纯物理滑向物理里的机器学习，再到大多数时候都在做 AI。他看到 Maguire 的一次演讲，从旧论文里认出了这个名字，震惊于一位货真价实的弦理论学者竟然创办过公司，还加入了红杉资本。他说，大多数弦理论学者都不太擅长社交。原定从红杉门洛帕克办公室步行到斯坦福再走回来的三十分钟路程，最后变成了三个小时。Maguire 错过了很多会议，还劝他退学，并给出三个选项：趁马斯克刚接手之后加入推特，因为只有最狠的人才会去；加入 Maguire 的公司 Foundry，做“胶水”；或者自己去创业。

他选了第三个，同时还和老朋友重逢了。Reyes 和 Grinberg 在普林斯顿的朋友圈高度重叠，却从来没有单独深谈过一次，他们分别在对面的两个餐饮社团（eating clubs）里。Reyes 从亚特兰大飞回来参加一场 LangChain 黑客松之后，两人在中午喝了咖啡，从那以后几乎每个小时都在一起工作。Reyes 的家族故事不会出现在 LinkedIn 上：他父亲那一边的家人在 1960 年代末从墨西哥来到旧金山。他的祖父母在 1970 年代于洛斯阿尔托斯开了一家墨西哥餐厅，1980 年代把它搬到了 Haight 和 Cole 的街口，之后离开加州去了佐治亚州，他正是在那里长大的。在普林斯顿读完计算机科学之后，他在 Hugging Face 为企业客户训练、优化并部署大语言模型，其中包括与 Harrison Chase 合作的早期 LangChain 集成，之后还在微软待过一段时间。

Huang 提到，对 AI 创始人来说，最诱人的塞壬之歌就是训练基础模型。Grinberg 多年学数学和物理，形成的审美是“根本性”；而在 AI 研究里，代码对机器智能的根本性再明显不过。Reyes 注意到，开源社区正朝着用大语言模型来模拟人类认知的方向发展，而大语言模型只是系统中的一块，也就是 Harrison Chase 所说的“认知架构”（cognitive architectures）。他还看到，代码生成领域最先进的玩家，做的仍然只是自动补全。他们喜欢说，软件是阿基米德撬动世界的那根杠杆，而 AI 代码生成则是撬动这根杠杆的又一根杠杆，效果层层叠加。

Grinberg 说，Factory 的使命是把自主性带入软件工程。具体来说，就是把开发生命周期里的任务自动化：代码审查、文档、测试、调试、重构。他一项项列出来的时候，就很明显，这些都是工程师不喜欢做的活儿。这是有意为之。代码生成很重要，令人惊艳的演示也很重要，但在大多数组织里，工程师并不是把时间花在有趣的开发上。他们往往太晚才做审查、测试和文档，然后为错过的截止日期吃尽苦头。如果这些工具要在企业里真正有用，就得去工程师所在的地方，去他们最想自动化掉的工作上。

他们把这些系统叫作 droid：每一类任务一个，软件开发生命周期里的每一步一个。把问题当作游戏来看很方便，因为生命周期本身已经提供了规则。Grady 给出一种解释，他们也认可：droid 是真正管用的、专门负责某项工作的自主智能体。这个名字是刻意绕开“智能体”的说法。Grinberg 说，成立十三个月后，他原以为业界已经往前走了，但“智能体”这个词依然等同于不可靠、随机性强的演示品，甚至是空头支票式的软件。他们想要的，是今天就对企业工程师有价值的系统，不止于对未来的酷炫展示，也不限于业余项目里的黑客玩具。一个有趣的事实是：他们最初注册的名字是 San Francisco Droid Company，后来在法律建议下改成了 Factory，因为卢卡斯影业（Lucasfilm）对商标的保护非常积极。

Huang 刚刚请 Harrison Chase 上过节目，聊了定制的认知架构，所以她很想听 Factory 的版本。Reyes 认为，基础模型层和编排层都有很大的创新空间。技术上的类比来自 DeepMind 的 Alpha 系列：只要问题能被建模成一场游戏，也就是有规则、有环境、有反馈回路，就能搭建出与人类推理相当、甚至超过人类的系统，无论这场游戏是围棋、蛋白质折叠，还是代码。Factory 的大部分推理工作，是在决策中做推理时搜索，是直觉与规划的混合。他们暂时还不训练基础模型。实验室会继续改进延迟、上下文窗口，以及在某些任务子集上的表现。只要需要行动、环境反馈和长期规划，单个基础模型就很难什么都做得好。这正是应用层可以创新的地方。

Huang 引用普林斯顿的 SWE-agent 论文作为佐证：只要架构对，小型开源模型也能在代码上展现出惊人的智能体推理能力。Reyes 喜欢那个团队，也喜欢 SWE-bench，但他强调，做这些系统靠的是模型层、任务、评估数据和整体架构之间的协作，不止于一个基准测试。被问到最喜欢哪种认知架构，比如思维树还是思维链，他不肯选。在类似游戏的问题空间里，你可以去搜索，蒙特卡洛树搜索和语言智能体树搜索（language-agent tree search）这类技术都很有意思。没有哪一种架构适用于所有任务。把开发生命周期拆成语义上有意义的片段，可以让开发者定义这场游戏的边界；Factory 的工作，就是搞清楚哪种设计适合哪类任务。Huang 听出了 Rich Sutton 的《苦涩的教训》：能够规模化的，是搜索和学习这两种技术。Reyes 同意，两者都需要。

Grady 接着引用了 Grinberg 几个月前说过的一句话：OpenAI 有数百名工程师在做 Factory 所在的这片边缘地带。这并不是讽刺。许多创业公司都在训练或微调模型；OpenAI 和 Anthropic 则在投入大量资源，让基础模型变得更好、更便宜、更快。Factory 不想跑一场和自己能力不匹配的比赛。训练基础模型是他们打不赢的仗，而且到了现在这个阶段，它也算不上什么独特的战场。尚未成熟的，是人们真正在用的产品。在风投们喜欢的比喻里，现在满地都是卖铲子的，却没有人去淘金。他们的论点是：利用 OpenAI、Anthropic 和谷歌花费数十亿美元、动用数百名工程师打造出来的漂亮黑箱，做出人们真正会用的产品，然后才有资格去做更花哨的事情。如果你无法用这些模型做出一个有人用的产品，微调和训练也救不了你。那很可能只说明它不是一个好产品。

Grinberg 的另一个类比，是拿 Jeff Dean 来代指一个非常好的基础模型，也就是一个推理能力惊人的 GPT-6。把它丢进你的工程组织，带着所有的细微之处和最佳实践，光靠原始推理并不足以可靠地做出贡献。给 Jeff Dean 一道 LeetCode 题，他会解出来。但如果给他一个二十年的老代码库，其中一部分已经废弃，一部分是刚退休的人最后动过的，那你就需要深入理解工程的系统本身：不只是代码，还包括决策的来由、人们如何沟通，以及团队这一周最关心什么。Factory 面向企业关注的，正是这些不那么吸引眼球的细节。

大多数 AI 编程公司优化的是单个开发者的效率。Reyes 想要的是整个系统。工程副总裁关心的，不是某个人是不是每小时多完成了一项任务。那个人写出的代码可能要差 40%，导致别人要在上面返工；或者花了四个小时做计划，堵住了另外五位工程师。一阶指标，比如某人多快按 Tab 接受自动补全的语句、多快完成一个孤立的任务，都会漏掉瓶颈。Factory 则试图去看工程负责人真正在衡量的指标：代码返工率（code churn）、从提交合并请求到合并的时间、工程组织里从提问到得到第一个回答的时间。Reyes 说，这些指标对组织的交付速度影响大得多。

Grinberg 提到，在企业里渗透最深的 AI 产品是 Copilot，而它被普遍拿来衡量成功的指标，是自动补全的采纳率。如果你是 CTO，要怎么把这个数字拿给管理层？他们不知道它意味着什么，也不知道它怎么换算成业务目标。还有一个隐藏的风险：有研究发现，使用这类工具的组织，代码返工率会上升 20% 到 40%。这些研究本身有问题，但方向很清楚：AI 生成的代码占比越高，如果审查方式不做改变，返工率就会上升。面对工程负责人时，Factory 讲的是三个维度：节省工程时间、提高速度、改善代码质量。然后把它们合并成一个数字，拿去跟 CFO 对话：工程速度（engineering velocity）。这就是 droid 的瞄准点。

他们在案例研究上还不太公开，但 Reyes 愿意分享总体数字。平均周期时间提高了约 22%。代码返工率下降了 13%。测试 droid 每天能为工程师节省大约四十分钟。让数千名开发者使用这些工具，还有另一个红利，就是一个实时的基准测试。SWE-bench 是送给社区的礼物，是一种开源的系统比较方式；但从战略上说，真实世界的部署，才让他们能加快 droid 质量的迭代速度。

Reyes 说，生产环境中最大的意外是，工程师非常热爱主人翁感。一个接管任务的自主产品，要面对的是一群有充分理由反复无常的开发者：他们每天都被各种工具和自动化轰炸。任何自上而下强制执行的东西，都必须足够灵活。每个人对代码审查的理解都不一样。有人想要超人级的 linter，有人想要对改动做深度分析，还有人干脆讨厌一切审查。Grinberg 在公司内部常说一句话：代码审查就像去车管所（DMV）办事。不管办公室多干净、队伍多短，没人喜欢它，因为归根结底，是有人在批评你做的事情。

这种分化，正是他们坚持做一整组 droid 的原因。审查这类东西，工程负责人喜欢看到它推动组织级指标，而开发者却觉得不好玩。测试 droid 恰恰相反：对于不再需要花几个小时写单元测试的开发者来说非常棒，但对盯着业务指标的负责人来说，就没那么一目了然。他们的目标是整个工程组织，既不只为 VP 服务，也不只为个人服务。Grady 的总结是：他再也不用去车管所了，因为对方会把驾照寄给他。Huang 调侃道：看 Pat 的开车风格，还是别寄了。

完全自主的软件工程师还有多远？Huang 拿 Waymo 作比方：它曾经看起来近在眼前，接着跌入一段绝望的低谷，然后未来又加速到来。我们现在到了第几局？什么时候能有完全自主的 Jeff Dean？Reyes 想重新表述这个问题。技术进步一再通过提高人们工作的抽象层级，改变劳动力的格局。历史上，让人们在更少领域知识的前提下也能影响软件，需求都会爆炸式增长。Factory 已经看到，当人们从次要任务中解放出来，比如为一个 PR 生成单元测试、维护那些团队里 95% 的人都已经懂的文档，他们就会转向编排、架构，以及这个 PR 到底想解决什么问题，至于是否遵循风格指南，则退居次要。随着时间推移，软件工程师会越来越像架构师或设计师。他预计，未来参与软件创造的人会多十倍，每个人的影响力相当于今天的 100 或 1000 人。只是那时的样子，可能跟今天的生命周期步骤并不一样。

Grady 读出 Factory 网站上的一句话：他们希望成为即将到来的创造力与自由时代的灯塔，而按需获取的智能将解锁这个时代。Grinberg 把话题拉回产品定位。去攻克开发中最性感的部分，也就是从零开始做一个应用，固然很诱人，但正因为如此，开发者会本能地防备，因为那正是他们最享受的部分。如果把开发本身自动化了，工程师剩下的就只是审查、测试和写文档，任何软件工程师都会称之为令人沮丧的地狱。Factory 想与开发者站在同一边，不与之为敌，所以他们自动化的是开发者不想做的那部分工作。五年之后，没有人真正知道这个工作会叫什么，可能是策展人、培育者、编排者，但只要他们留在用户身边，就能坐在高杠杆的位置上，就不必去取代用户。

离可靠的实习生级工程师还有多远？一年，还是十年，还是已经到了？这要看任务。对于代码审查和测试，Reyes 认为已经到了。早期，有一个组织告诉他们，审查 droid 是团队里最好的审查者。把单体仓库拆分成微服务，这种通常要交给资深工程师带团队去做的工作，不会在某个非此即彼的时刻一下子完成。职责会分解为逐个文件地规划和实施重构；当这些子任务交给 AI 之后，这个角色就开始被叫做别的名字，因为你不再关注明天要写的那一行代码。他们还亲自试用了自家产品，去处理一个让他们畏惧了好几个月的 GitLab 集成。代码 droid 先规划步骤，在他们监控的同时实现子工单，最后他们得到了一个谁都没写过的集成。他们原本在考虑要不要招一个实习生。Grinberg 说，实习生的活儿，他们今天已经干完了。未来已经到来，它正在一级一级地攀登复杂度的阶梯。

Huang 问的是，当每个对手都用同样的模型时，你如何保持清醒。Grinberg 说，这个问题定义了这支团队。证明自己相对竞争对手存在价值的方法有很多。他们的答案是执念：他愿意押上一切，赌他们组建的这些人，比这个领域里的任何人都更执着。由此推论，唯一能赢的办法就是执行得更快，其他都只是锦上添花。你还需要那些把外部压力当作燃料的人。如果竞争对手做了件大事，你就泄了气，那说明你其实并没有真正痴迷于这个使命。如果目标是把自主性带入软件工程，那些噪音就无关紧要了。朝你定下的方向执行，其他的事情自会理清。

快问快答：如果不能做编程智能体，Reyes 会去看机器人。团队里很多人来自自主系统领域，多模态的函数调用大语言模型已经出现，硬件成本在下降，而且，半开玩笑地说，实体 droid 也在路线图上。Grinberg 无法想象做别的事情；视野狭窄既是盲点，也是特色。他们佩服谁？Grinberg 说是 Jeff Dean，因为他的研究，因为 TensorFlow，以及他与 DeepMind 相关的工作，也因为他听说 Dean 是个很好的人。在一个充斥着推特上互撕的社区里，负责任的领导非常重要。Reyes 则不会点名某一位孤胆天才；AI 是靠群体完成的。他们佩服的团队是 Mistral，它在很短的时间里就把开源模型推到了前沿。给创始人的建议：Grinberg 重复了那句关于淘金的话。Reyes 补充了一条产品测试：做出一个如果 OpenAI 发布 GPT-6 或 GPT-7，就能变得好 10 倍的东西。他们在内部把 Factory 看作：每当新模型发布，它的价值就会成倍增长。如果你因为别人的发布而焦虑，也许该调整策略了。

压轴的是上周的 SWE-bench 成绩。这个基准测试大约包含 2300 个问题，来自十二个热门的开源 Python 项目，通常是缺陷报告，附有人工标注的正确补丁和测试。问题是：AI 系统能否把自然语言转化为一个能解决这个问题的改动？此前的最高纪录约为 14%，由 Cognition 的 Devin 创下。Factory 拿到了 19%，而在这个排行榜上，同场竞争的还有微软研究院、亚马逊、IBM 和字节跳动。Reyes 的解释几乎是一个反基准测试的故事：他们做代码 droid，目的是支持真实的客户，并非为了某个基准测试。客户才是最好的基准测试。技术报告谈到了规划与任务分解、环境接地（environmental grounding），以及对代码库的理解，但真实世界数据集这颗北极星才最重要。每个 droid 都有自己的认知架构，按照人类完成该任务的流程来建模。元问题是在刚性与灵活之间取得平衡：入口点保持刚性，错误恢复保持一致，然后在解决问题的大部分过程中保持宽松。

19% 离让代码 droid 放任自流还差得远。Reyes 的回答是，人们已经在生产环境中用它，做的任务与基准测试并不完全重合。HumanEval 测的是编程面试题；SWE-bench 更接近真实工程，但主要是调试和意料之外的行为，而不是多处改动的迁移，也不是人类协作的任务。针对这些客户任务的内部评估显示，可靠性高得多。设计的另一半在于坦然承认系统的不足之处：比如任务进行中能加以修改、对 droid 为何做出某个决定要有一定的可解释性，以及有人能随时介入。你不需要在 SWE-bench 上拿到 100% 才能获得生产力上的提升。至于 80% 或 90%，进展很快，但他怀疑我们会先看到 SWE-bench 2 和 3：这些基准会问的，不只是代码对不对，还有它是否适合特定的代码库，因为现在有些任务特别依赖字符串匹配，做对了几乎像是在作弊。两三年内，也许吧。SWE-bench 的作者也都来自普林斯顿，他们甚至有同一位论文导师。