这是一篇5万字长文，是一份3小时访谈的文字实录，大概也是全网对 Coding Agent 和 OpenAI o3 最深度也最全面的讨论——犹豫了很久是不是太标题党了，但在我的视野之内，确实没发现超过这一篇的内容了。

为什么 Coding Agent 和 o3 模型重要？　

先说 o3。从年前至今，应该所有人都被 DeepSeek R1 刷屏了。但实际上，对于 AI 从业者而言，另一件事的影响不在DeepSeek 之下，那就是 OpenAI 在春节期间紧急上线的 o3 mini 和基于 o3 微调的 Deep Research——只不过 200 美元的门槛让这种影响明显滞后了。今天这篇文章会讨论为什么 o3 如此重要。　

而 Coding Agent 大概是去年 AI 应用进展最快、引发最多讨论的方向了，从上半年 GitHub Copilot 一家独大到下半年Cursor 异军突起，引发 Replit、Bolt.new、Windsurf 群雄争霸，直到 Devin 以 500 美金的天价和实打实的效果技惊四座……

这篇访谈难得集结了国内和硅谷 Coding Agent 领域一线的创业者、大模型研究员以及投资人，深入讨论了 Coding Agent 发展与现状、产品设计思考、用户实际反馈、带来的社会变革，以及对 o3 能力、实现难点和未来挑战的思考。　

没有套话，全是真知灼见。读的过程中忍不住加了很多评论，也欢迎你和我讨论。　花了我不少时间整理，也会花费你不少时间阅读，但绝对值得。　

核心观点

AI 总结还是不太行（即便是 o3 mini），以下 2000 字核心观点主要为人工总结，AI 辅助。当然，强烈建议抽时间读完全文。　

Coding Agent 的历史、现在与未来

AI 编程工具的四阶段进化：

ChatGPT & Claude：初代代码生成工具，只能根据 prompt 输出代码，无执行调试。
GitHub Copilot：让 AI 理解全库环境，提升预测和补全准确率。
Cursor & Replit Agent：加强逻辑理解，支持文件和命令行操作，标志着“AI 编程 3.0”时代。
Devin：真正实现自主任务执行，具备规划、执行和调试能力，堪称“自动化程序员”，开创全新范式。

Coding Agent 的前沿能力与未来潜力：

开源项目的最活跃贡献者：在 OpenHands（OpenDevin）项目中，Agent 的贡献已超越所有人类工程师。
自我迭代预兆：通义千问团队用 Agent 清洗代码数据，展示了 AI 面对陌生数据能自主清洗。未来若能自主判断数据价值、生成训练代码并自评，软件开发与模型迭代将彻底颠覆——未来模型的进步可能将由模型自己推动。

从 Coding Agent 到通用 Agent 的跃迁：　

全栈进化：AI 代理正由单一代码编写转向需求分析、架构设计、测试与部署全流程。
跨界交互：未来 AI 将能像人一样操控图形界面，摆脱 API 限制。
自我进化闭环：AI 有望自主优化代码、进行训练，最终实现类似 AGI 的自我迭代。

Agent 的设计与交互

Replit Agent 产品迭代发现的用户诉求分化：

用户两大需求：一是从零到一的全自动任务，二是轻量级的代码编辑（pull request）。
分流策略：Devin 聚焦前者，而 Replit 聚焦后者——大多数用户更期待 Agent 合作式介入、及时反馈与方向把控。

OpenHands（OpenDevin）的 Agent 设计策略：

基于“React Code Act”这种方法，本质上是依赖LLM自己的能力，通过历史的action的observation去生成新的action，决定下一步该做什么。
这种设计的好处是能最大程度享受到model更新带来的improvement。相比之下，如果用prompting heavy API的方法，可能享受不到直接用LLM生成action带来的这些提升。
如果在 Agent 层面做得够轻量，就能更好地享受到模型本身的提升。

Agent 的 Planner ：复杂设计真的有必要吗？　

OpenDevin 开源社区进行了非常多的讨论和尝试。实现了4~5种不同的agent framework去做planning，但有趣的是没有一个能够超过模型本身的表现。
结论是：planning能力某种程度上可以作为模型本身的一个能力存在，不一定需要external planning。
与其工程化一个 Planner，还不如更多信任模型本身的“直觉”规划，省去不必要的工程麻烦。

关于 Agent 的交互：

有了AI特别是o1这样的能力后，我们需要思考是否应该把很长的推理过程看作一个bug，还是基于它的特点来设计新的交互方式？
在model层面和safety层面都需要重视的一个问题是，要确保Agent执行的这些操作是经过一定程度上的人类批准的。但具体来说，有 2 种批准方式：1）高层授权，比如在某个范围内你做什么都可以；2）严格控制，像Cursor的Agent mode那样每一个action都需要人类去approve或reject——如何在这两个极端之间找到一个好的balance，是接下来比较重要的一件事情。

Agent带来的社会变革

Coding Agent 进化带来的社会变革：

无限实习生：低成本、不断进化的 AI Agent，正以低于正式员工的价格提供超越传统产能。
管理者新角色：

每个人都必须学会如何当老板——指挥、管理、训练 AI，将从单纯的执行者转变为CTO、CEO。
作为管理者，需要给Agent明确的、可量化的目标，正确地做prompting、布置工作。
未来对人来说，真正重要的工作是提出好的问题、知道自己想要什么，需要考虑的是更具创造性的、更偏向规划的事情。而具体的执行部分则交给Agent或AI来负责。

Agent 设计变化：会越来越像一个给公司CEO设计的产品，而不是给程序员设计的产品。
当然——随着 o3 带来的模型推理能力的进化——情况可能反过来，实际上可能是Agent在教我们如何做事，最终可能是Agent自己识别出还有什么是它做不了的，然后再来给我们分配任务。AI 可能会主导整个planning，人类反而在给它打工。

异步 Agent 引发的工作方式革命：

Devin 等代理让任务从“人机交互编程”转为“AI 主导的全流程自动化”：AI 如同不断进化的实习生，任务下达后人只需异步审核。
这预示着“工作规模扩展定律（Scaling Law of Work）”：未来，简单购买算力或 AI 工具即可承接复杂认知任务。

Agent 未来的提升方向

Agent 未来从junior engineer晋升到senior engineer 需要提升的能力：　

信息获取能力要与人类处于同等水平。我们人类能够访问到的所有信息渠道，这个Agent就必须能访问到；
model本身的能力也很重要，特别是planning能力、从错误中恢复的能力；
要有积极主动的特质，需要在恰当的时机主动询问；
确保未经授权操作绝不执行；
通过feedback loop不断提升自主性和scale能力。

OpenAI o3 模型

o系列模型在解决数学和编程问题时主要展现了两个核心能力：

第一个是之前大模型虽然具备但没有做得那么强大的逻辑推理能力。这个模型能够基于明确的问题描述构建出强大的思维过程，把复杂的需求拆解成一个个逻辑单元。在每个逻辑单元中，它都具备计算和编程能力，能够给出高准确率的答案。
第二个是强大的方法总结和思维归纳能力，它能够从训练数据中总结出复杂的思维模式，知道什么时候该反思，什么时候该跳出当前思维继续推进。这种思维模式是它面对未见过的难题时泛化能力的保障。

局限性：

但在真实世界中，我们面对的环境和需求往往难以被定义或形式化，模型除了需要推理能力，还需要具备对这个世界的认知。
o系列模型主要在定义明确的场景下验证了核心技术，对未来真实世界任务的泛化还有一些路要走。
我们需要加强模型在模糊环境中的适应能力，思考如何把它在代码或数学上展现出的思维方式扩展到更多场景，同时确保不产生其他影响。
实现这个目标最难的是如何在开放环境下定义反馈，因为只要有廉价的持续的反馈，模型就可以不断提升自己。

其他金句　

一旦技术统一，AI 就能大展拳脚。
如果一个工作能被总结成人类坐在电脑前通过和电脑交互能完成的，那基本上都能被Agent化。
Agent时代的新变现模式：不再是传统 SaaS 的卖工具，而是卖生产力
创业并不是一定要训练自己的模型，而是要和模型形成一种更紧密的共生关系。核心竞争力在于如何把模型用好，以及对用户实际工作流程的深刻理解。
要保持乐观和敬畏：虽然我们现在用的是能获得的最好模型，但如果明天能拿到新版本，情况可能就完全不同了。

嘉宾介绍：

Yusen Dai，真格基金管理合伙人，聚美优品联合创始人。
李珎， Replit Agent 核心成员，Replit 资深工程师，ex-字节，Google.
Xingyao Wang， Allhands AI (开源项目 OpenHands) co-founder & Chief AI Officer， UIUC PhD.
Binyuan Hui，阿里巴巴通义实验室科学家
Cohost Peak，真格基金EIR，前猛犸浏览器创始人
OnBoard! 主持 Monica：美元VC投资人，前 AWS 硅谷团队+ AI 创业公司打工人，公众号M小姐研习录 (ID: MissMStudy) 主理人 | 即刻：莫妮卡同学

正文如下。（注：本期录制时间为2024年12月）

00:00:15~00:01:28　

Monica：

大家好，欢迎来到OnBoard!，我是Monica。转眼就是二零二四年的最后几天了，今天也是OnBoard!二零二四年压轴之作，必须是绝对深度绝对精彩的一期。　

如果你关注AI，那一定知道过去一个多月最火的话题之一就是Coding Agent。不到两个月的时间，Coding Agent的产品可谓是完成了两级跳式的升级。

从超级编程助手Cursor，到Replit Agent，windsurf代表的可以简单的完整开发应用的Coding Agent，再到千呼万唤始出来的Devin的发布，向世人展示出真正自主的Agent可以独立完成各种多步骤复杂任务的惊人能力。这真的打开了我们对于Coding Agent以及Agent本身全新的想象空间。　

更巧的是，就在我们录制这期节目的凌晨，OpenAI在十二月发布活动的最后一天，发布了让世人震惊的模型。OpenAI o3，它在多个编程和数学最具挑战性的benchmark上都超越了绝大部分人类，可以说让我们对于大语言模型能力天花板的预期再次被刷新了。　

00:01:28~00:02:44　

要展望 AI 的 2025 年的发展，Coding Agent 以及以强化学习为新范式的 o3 系列无疑是最核心的问题。为此，我们邀请了国内和硅谷 Coding Agent 领域一线的创业者、大模型研究员以及投资人的重磅阵容，一起跟大家探讨个痛快。　

让我介绍今天的重磅嘉宾：首先是 Replit Agent 的核心成员李珎，他们在今年九月首次推出的 Replit Agent 引领了 windsurf， bolt等一系列 Coding Agent 产品的领头羊，也是第一次展示除了这种产品形态。

我们还邀请到了开源版 Devin 演化而来的商业公司 Allhands AI 的 CTO Xingyao。在底层模型方面，我们请来了最具国际声誉的中国开源大模型——阿里巴巴通义千问的 coding 负责人Bingyuan，分享他对模型 coding 能力未来的见解。

此外，真格基金管理合伙人戴雨森将从投资人的宏观视角，为我们解读 Coding Agent 对软件和组织新范式的定义。最后，我们还邀请了一位特别嘉宾，真格基金的 EIR、十七岁就开始在 AI 领域创业的 Peak。　

00:02:44~00:03:38　

这次讨论长达三个多小时，在全网都很少见。尤其难得的是，我们邀请到了来自硅谷亲手打造coding asia的创业者们，他们分享了产品设计思考、用户实际反馈，以及对o3实现难点和未来挑战的深入拆解。更有趣的是，我们还讨论了一个开源项目中Agent成为最活跃贡献者这一现象背后的深远意义。　

为了帮助大家更好地理解本期内容，我强烈推荐大家复习两期重要的往期节目：第62期我们与Google DeepMind研究员关于o1的讨论，以及第53期在今年上半年我们对Coding Agent的首次探讨。值得一提的是，第53期的嘉宾姚顺雨，作为SWE-bench的提出人，现已加入OpenAI负责AI Agent方向的研究。　

未来已来，不论你是否感知到，这三个小时都绝对值得你投入时间。　

00:04:04~00:04:28　

好，请几位嘉宾跟大家介绍一下你自己。同时也可以简单介绍一下你是怎么开始进入到AI这个领域的，以及你现在的工作与Coding Agent有什么样的关系。老规矩，我们有个fun fact，就是最近大家使用任意一款Coding Agent产品时，做过的让你自己觉得最惊喜或者有趣的一个任务，可以跟大家分享一下。那我们要不从雨森开始。　

00:04:28~00:05:50　

戴雨森：

大家好，我是真格的戴雨森，主要在看AI方面的投资。我一直在探索用Coding Agent做一些有趣的事情。作为投资人，我们还没有用Agent去实际开发软件或网站，但在Devin发布后第二天，我就付费充值了Devin，投入了五百美金开始使用。我发现它不仅可以写代码，还具备很强的能力，可以处理投资圈的数据收集和爬虫类案头工作。　

我自己经过一些尝试后，觉得非常惊艳，就推荐给真格基金的同事们也买一个来试用。没想到同事们一天时间就把五百美金的额度用完了，大家都做了很多有趣的尝试。看了后台使用情况后，我意识到不只是程序员面临职业危机，我们投资人也会面临很多挑战。今天很开心能和大家一起探讨这个领域，因为我们看到了很多新的机会。　

Monica：　

大家可以感受到我们这个投资机构是以使用者的身份走在前沿。当时看到雨森展示爬虫的整个过程，以及中间的推理过程，觉得非常impressive，已经超出了我们原来认为Coding Agent只是程序员编程辅助的定义。一会也请雨森从PM或非程序员的视角，分享为什么会让我们觉得如此惊艳。　

00:05:50~00:07:13　

让我们请下一位返场嘉宾李珎来分享。　

李珎：　

我是李珎，在Replit Agent担任AI Agent engineer。我是最早的Replit Agent创作者之一，最开始这个项目只有我一个人在做，后来逐渐发展成为公司的核心项目。在九月份之后也是高速成长的过程中，我们可能是市面上第一个能公开使用的Agent。　

最近我在用Agent帮助国内一个电影导演团队，将他们的需求通过Replit Agent转化为产品落地。比如电影剧本的拆解、翻译等工作，我会从他们那里总结需求，然后用Replit做成产品供他们使用。实际效果非常好，已经获得了较多媒体报道。　

这项技术让电影从业者也能开发软件了。以前对于导演来说，比如需要把剧本拆解成特定形式让其他组员执行，这些工作都只能手工完成，因为软件开发的门槛太高。但现在有了Agent后，这个门槛突然变得非常低，他们就可以自己去迭代开发了。这是最大的不同之处。　

00:07:13~00:07:49　

Monica：　

那下一位我们就请Xingyao来给大家介绍一下。　

Xingyao：

大家好，我是Xingyao，我现在是Allhands AI的联合创始人，同时担任Chief AI Officer。在加入AI领域之前，我在UIUC攻读PhD。在post-training期间，我主要从事LLM和Agent相关的工作。年初我们开始了一个开源项目，之后与冰源、晋阳等人一起发起了一个开源计划。我们一直从年初奋斗到年末，期间我们以Devin为基础，成立了Allhands AI。　

00:07:49~00:10:10　

最近这段时间，AI方面最令我印象深刻的是在一个月前，我们发现OpenHands（OpenDevin）Agent已经能在日常软件项目开发中发挥像人类工程师一样的实质性作用。

我给大家分享一个数据，在过去一个月，它已经成为了OpenHands（OpenDevin）项目代码库中最大的贡献者，贡献量超过了所有人类工程师。从commit记录可以看到，Agent每天都在代码库的各个角落活跃，修复从简单到复杂的各类bug。看到Agent在GitHub上实际工作的样子，让我们真切感受到这项技术真正到来了，这是令我最难忘的一点。　

Monica：

这个确实非常令人印象深刻，我们可以深入聊聊这是如何实现的。这个跃迁是因为你们做了什么样的改变，让它突然有了这样的能力提升？　

Xingyao：

在十一月中旬，我们成为了第一个在SWE-bench上超过50%的Agent。自从突破这个门槛后，我们明显感受到Agent的质量有了飞跃。我们在日常工作中更频繁地使用它，逐渐发现Agent能做很多原本没想到它能做的事情。

以前我们可能需要考虑是否有人力和精力去做一件事，但现在我们只需要负责提出想法，然后把任务交给Agent。比如有一天团队遇到一个前端问题，我们想要添加一个checkmark，demo运行后创建issue直接assign给Agent，它就完成了这个功能。最令人兴奋的是，Agent在完成我们的需求时，表现往往超出预期，以至于我们现在可以直接采用它的代码，不需要太多人工干预。　

Monica：

从五六月份公司成立到现在只有半年时间，当时我们还讨论Devin是不是只是一个噱头，现在我们可以看到Agent的超出预期的贡献，确实AI这个领域的变化确实非常快。　

00:10:10~00:11:18　

好，那接下来有请Bingyuan来聊一聊。　

Bingyuan：

大家好，我是Bingyuan。　

我目前在通义主要负责coding这个方向。我们最近开源的coder项目受到了大家的关注和喜爱，收到了很多社区非常好的反馈。　

我可以跟大家分享一个比较好玩的场景，我最近在尝试让AI以Agent的形式去清洗代码数据。传统方式下，我需要观察大量代码，编写处理脚本，然后不断迭代来获得好的数据。但现在AI已经可以在面对陌生数据时自主进行清洗。我希望未来如果模型足够强大，它的能力可以从数据清洗扩展到自主判别数据价值，甚至可以编写训练代码来训练更强大的模型，并进行自我评估。　

如果AI架构能够突破，不仅软件开发流程会发生变化，模型迭代的流程也会随之改变。这是我最近观察到的一个很有意思的趋势。特别是看到昨天o3的发布，我感觉这些变化可能会比我们预想的更早到来。未来模型的进步，可能真的要靠模型自己去迭代。　

00:11:18~00:12:36　

Monica：　

能给大家简单介绍一下吗？因为之前提到千问是做基础模型的，你们也有自己的foundation model和coding model。刚才提到的这个coder具体是一个什么样的产品？　

Bingyuan：

我们希望先在coding这个方向单独进行验证，包括数据和技术的探索。我们在通用模型基础上，进行了大量的prompt engineering、instruction tuning，甚至是RLHF，想看看在coding这个方向上能走多远。　

所以第一天在做project的时候，我们的目标就是要在coding方向做到真正的顶尖水平。因为开源模型还在不断迭代过程中，一开始很难平衡各项能力，所以我们让不同的人去探索不同方向，在某一个方向做到顶尖，最终merge到一个非常strong的通用模型里面。这是我们团队一直以来的技术迭代逻辑。　

所以今天的coder其实是在通义千问模型（我们称为Qwen）的基础上，产生了Qwen Coder。这样的一个coder可以用于下游的Agent任务或是一些辅助任务，我觉得这都是非常exciting的事情。　

00:12:36~00:15:02　

Monica：　

好的，非常感谢几位嘉宾的介绍。Peak也是我们今天特邀的co-host，也请他跟大家介绍一下。　

Peak：

我是Peak，是真格基金的EIR。此前一直在产业界做NLP，主要是与搜索和语言模型相关。最近我对Agent特别感兴趣，这让我想到软件工程中的自举概念，就像编译器能自己编译自己。

我最近在试用OpenDevin，想了解它的架构，特别是controller之间的关系。我没有直接读代码，而是让OpenHands（OpenDevin）帮我自己去讲解，效果还不错。

后来看到Xingyao提到OpenHands（OpenDevin）的contribution已经排到第一，我就让Devin尝试实现一个最简陋版本的自己（Devin）。虽然最终实现的版本不能完全work，但已经很impressive了。　

对于今天的讨论，我特别关注几个方面。在模型层面，我们看到Reasoning模型在突飞猛进，同时coder模型也达到了可用状态。在Devin这样的产品中，planning部分对微调模型的要求更高，而具体执行则需要强大的coder能力。我很关注这两类模型未来是独立发展还是会在某个节点融合。　

对于Agent frameworks，我想和Xingyao讨论一个重要问题：如何更好地发挥模型能力？因为相同模型在不同框架下表现差异很大，而框架与模型能力的关系也并非简单的线性关系。　

另外，我注意到很多朋友，包括雨森，通过现在的Agent产品完成了人生第一个项目（网站或者产品），但由于没有工程能力，往往在deployment阶段遇到困难。软件的生命周期很长，包括maintain、更改以及内容管理等，这些都是需要Agent类产品思考的问题。　

00:15:02~00:15:38　

Monica：　

感谢 Peak 的分享。接下来，我们会为还没有听过或不太熟悉这些产品的听众介绍几个我们经常提到的产品。同时，我们也会邀请几位一线的 builder 深入分享他们整体的构造思路、思考和演进过程。　

雨森，作为一直很深入地跟进 Coding Agent 以及更广泛 AI 领域的投资人，能否请你从这个视角来分享一下你所观察到的 Coding Agent产品演进，以及为什么你这么重视这个领域的创业机会和未来可能性？请你简单梳理一下过去的发展，并分享你的思考。　

00:15:39~00:19:03　

戴雨森：　

编程一直是AI领域中非常重要的一件事情，因为通过写代码，AI可以控制很多外部工具。从ChatGPT出现到现在这两年时间里，AI编程已经经历了四个主要的进化。　

一开始ChatGPT出现时，我们给AI一个指示，它就能把代码写好直接贴在聊天框里，这确实是人工智能的一个飞跃，因为它代码写得确实很好。但第一代AI并不知道我们为什么要写这个代码，完全是根据我们给的prompt来写，所以我们往往需要在prompt里把很多上下文都写进去。

而且我们需要手动把代码粘贴回IDE里面再去运行。当代码出现错误问题时，再抛给AI，这样AI就像个瞎子，完全不知道发生了什么，像一个奴隶一样在写代码。这就是ChatGPT和Claude刚出来时的情况，包括GitHub Copilot也是如此。　

GitHub Copilot的出现是AI写代码能力的第一次飞跃，它让AI能够读取整个code base作为上下文，从而理解我们为什么要写这段代码。不过在第一代产品中，用户还需要手动把代码粘贴回IDE进行调试，这种模式可以说是“我问你答”式的人机合作。　

Cursor提出了一个重要概念：next action prediction。具体来说，就是当你写下当前这行代码时，AI能推测你接下来要写什么代码。这体现了模型对代码的深度理解，以及对程序员任务更强的规划和拆解能力。随着GPT-3.5等模型的进步，系统能生成更长的代码块，更准确地预测用户意图。　

后来，Cursor还加入了文件操作能力，可以直接在本地创建和修改文件，比如处理需要下载的文件、需要创建的文件等。同时还引入了命令行操作建议。这标志着我们进入了AI编程3.0阶段：AI能自动写代码、创建文件并执行调试，如果代码有问题还能自己debug。这让我们从“我问你答”进化到“我问你写”，大大加快了编程自动化的进程。　

我在一两个月前第一次使用Windsurf时感到非常激动，因为它能在一台全新的、未安装任何编程环境的系统上，仅通过一两步简单指令就实现demo的自动化运行。不过这个过程仍然需要我持续关注。而Devin的出现开创了新的范式，它真的很像一个真人。我把任务交给它后就可以去做其他事情，它能通过planner进行完整的任务规划，持续自主编程和调试，还能创建文件，通过虚拟机访问互联网获取所需信息。　

最重要的是，我可以随时打断和调整它的工作进程。这与之前的ChatGPT和GitHub Copilot有很大不同，因为使用这些工具时，一旦给出prompt就必须等待整个流程完成，中途很难添加额外指示。从管理者的角度看，这就像给员工分配任务后可以不断调整要求。另外，Devin还与Slack做了深度集成，除了代码库外，还可以从Slack中获取任务背景的上下文信息，这对于准确完成工作非常重要。　

00:19:03~00:20:25　

所以我在看到Devin之后，我发现它不只是可以编程。它已经能完成很多通过一个人坐在电脑前面、通过互联网能够解决的事情。在这种异步的Agent产品出现之后，我觉得产生了一个很重要的概念：当我们能够简单地花钱或者说花算力就能买到工作成果时，这就诞生了某种工作的scaling law。　

我觉得人类使用的工具可以分为两类。第一类像电钻或ChatGPT这样的，你得持续投入注意力，有点像是你踢一脚开动一下，必须持续对话，一旦把注意力挪开就不能继续工作了。另一类就是所谓的自动化，比如我布置个爬虫，写好后它自己去爬，但它只能完成重复性工作，没有自己去调整决策、反思的能力。　

而我们说的Autonomous Agent，也就是全自动代理，既不需要我投入太多注意力，又可以完成非重复性的、需要创造性思考的工作。我觉得Devin是第一个例子，这可能是人类历史上出现的第三种工具。它不需要一直要求你的注意力就可以自己完成工作，这种情况下我们就可以把工作更多地scale up起来。

我可以让Devin同学帮我跑好几个任务，甚至几十上百个任务，我甚至可以让Agent去指挥另外的Agent去执行。所以我觉得这里面提出了很多新的可能，这真的非常让人激动。　

00:20:25~00:22:03　

Monica：　

我很好奇，你提到的工作scaling law这个感受是在使用AI之后产生的吗？与之前的产品相比，你认为最核心的区别是什么？　

戴雨森：

我认为核心区别在于异步工作方式。比如在Windsurf环境下让AI使用我的电脑时，它可以执行命令、创建和修改文件，但这时我就干不了其他事情，必须看着它操作。虽然我可以切断上网，但过一会还是得查看它有没有完成，因为完成后我需要进行下一步，这持续需要我的注意力。　

Devin的planner是一个非常重要的环节，它可以通过伪代码形式生成复杂流程。它会给自己生成to do list并持续执行，这个过程真正能解放我的注意力和生产力。第二，在Devin里面，它是在云端自己开了一个虚拟机，去完成需要的互联网访问、调试和验证过程，不用调用我的机器。之前用过RPA等试图实现自动化的工具，在工具工作时都不敢动电脑，怕一不小心影响到它的运行。　

这感觉就像我给实习生配了台电脑，我只需要偶尔去看看他工作得怎么样。Devin还有个很好的设计，比如它需要登录LinkedIn这样的账号时，可以让我来输入密码。这就像实习生找我要账号，让我在他电脑上输入密码，然后他就继续工作了，非常贴近实际工作场景。　

00:22:03~00:22:48　

Monica：

是的，虽然这个产品（Devin）最初是以coding功能为人所知，但从使用体验来看，它的功能范畴远远超出了coding。刚才雨森给大家介绍了Coding Agent的发展历程。在讨论Devin之前，我认为真正意义上的Coding Agent应该是Replit Agent。　

虽然今天很多人都想直接听Devin相关的内容，但我觉得前面我们讨论的Cursor和Replit Agent这两部分以及这两种产品形态仍然非常重要。李珎，能否更深入地跟大家分享一下Replit Agent具体是做什么的？另外也想了解你们一开始是怎么开始做这个产品的，以及从产品发布到现在这半年时间里有哪些重要的迭代？　

00:22:48~00:26:54　

李珎：

我觉得Agent可以有不同的产品形态。让我从头说起，我经历了刚才雨森提到的几波变革。在加入Replit之前我在创业。GPT-4发布后，我发现与它合作的效率比我和我雇佣的两个前端工程师合作效率还要高。虽然当时还只是简单的问答形式，但每月20美元的GPT-4比每月一万美元两个工程师创造的价值更大。考虑到我在这方面获得的收益，以及全球编程市场的巨大规模，我决定all in Coding Agent。　

一年前的Replit还是一家纯在线IDE公司，不像VS Code需要下载安装，Replit的用户可以直接在网页上编写代码。我们提供配置好的环境和部署功能，这也回答了刚才Peak关于deploy的问题。Replit其实是一个完美的sandbox环境，如果要开发AGI，它需要一个环境来进行编码、执行、开发、访问数据库和secrets，添加各种integration，这些我们都具备，缺的只是一个Agent。　

我们的CEO经常说"I have a dream"，希望有一天能在手机上操作Agent来开发软件。我们现在已经实现了这个目标。　

Replit跟Devin不太一样的一点是我们更注重帮助用户从零到一去build一个东西。具体来说，即使用户完全不会写代码，只要有了IDE，就可以告诉Agent“我要build一个这样的网页或软件”。Agent会先帮你make一个plan，然后你可以与Agent进行交流并prove这个plan。之后Agent会开始写代码、装环境、把项目搭建起来运行，一步一步地虚拟地把你想要的东西搭建起来。这就是一个完整的从零到一的过程。　

我们的产品在九月份发布，到现在已经有三四个月了。在这期间我们看到了大量不同的use case，获得了很多insights。其中最大的产品形态insights是，根据用户需求的不同，用户的expectation是非常不一样的。在最开始时，我们比较接近一个Asynchronous（异步）的Agent，就是用户给出需求后，我们会不停地迭代action，最后deliver一个结果。　

在产品发布后，我们收到了很多用户反馈。用户更期待Agent以合作的形式存在，而不是给出指令后等待很长时间才返回结果。像Devin这样的工作形式是有一个用户教育门槛的。在Devin出来之前，很少有软件是用户给一个指令，然后等待十分钟二十分钟才返回结果的形态。　

用户明确告诉我们他们需要更及时的反馈。所以我们做了两个改变：第一个是增加Agent跟用户的交流，因为这点非常重要，用户希望知道Agent一直在做什么，希望能够控制开发方向。我们增加了更多的transparency（透明度）和用户反馈，让用户知道我们在做什么。　

第二个是我们推出了另一个产品叫System，它是一个更快的编辑工具，有点像Code Composer。用户给出具体指令后，它会自己找文件并编辑，速度更快更便宜，同时具有更专门的自主性。　

现在我的理解是这其实是两个不同的需求：自动化完成任务和轻量级编辑。这两种需求的用户期望不一样，但都是真实存在的，不管是在Replit上从零到一开发，还是在已有代码库上生成PR。这是我们这段时间得到的insight。　

00:26:54~00:27:50　

从零到一开发和生成PR这两个问题虽然都是Agent相关的任务，但它们的focus是非常非常不一样的。　

如果是做一个大的PR，你需要去理解code base，需要有好的search strategy，需要能够提高生成内容的准确性。　

而在Replit的从零到一开发中，我们需要cover更多的use case和integration。比如用户想要用OpenAI的API、想要用database、想要用更多的API，我们都要能保证Agent能把这些接上，要能够保证它快，能够给用户更好地去把产品搭起来，能保证它能支持更多的framework，能保证它能deploy。从零到一的事情非常非常多，这个只是早期阶段，后面还有更多像SEO等很多问题要解决。　

但前面这些问题与Devin或AllHands解决的问题已经非常不一样了。所以这个看起来产品形态是很像的，但实际上整个问题是非常不一样的。　

无常按：这一段是一线开发者的真知灼见了，微妙但关键的需求和产品形态区别。　

00:27:50~00:29:36　

Monica：

关于你刚才提到的从零到一和生成PR这两种不同的需求，我想继续深入讨论一下。我们看到很多用户，包括类似windsurf或Bolt这样的项目，大多是完成从零到一的任务。那么在达到这个阶段后，用户是会停留在一个可以自用的小工具阶段，还是会进一步发展成更复杂的产品投入生产甚至公开发布？他们会继续留在Replit平台还是转向其他平台？　

李珎：　

这个问题非常好。我们看到不同的用户行为都存在，但大部分会留在平台内，继续增强Agent的能力并整合到产品中。　

实际上，很多用户已经push远远超过初始阶段，可能已经push到七十或者八十了。我们之前在推特上做了一次直播，有很多用户来分享他们的故事，其中印象比较深的是有一个德里的印度小哥，他说在Replit Agent发布后已经通过它挣了十万美金了。我们看到非常多的用户已经把他们的产品上线了，在网站上make revenue。这个更像一个创业的过程。　

我特别喜欢的一个pattern就是，有一些创业者用Agent非常快速地去build up他们自己的idea，然后放出去验证product market fit。用来验证PMF的第一个版本开发速度变得非常快，他们可以在不同产品之间share很多set up，比如说翻译的这些set up，比如说tracking分析的set up。这样就可以非常快地去验证idea，直到找到适合的idea和market niche。　

如果你是一个优秀的创业者，你的产能会被无限地增大，会被增大到十倍甚至一百倍。我看到身边很多创业者已经在做这个事情，还有一些人在帮他们验证data的idea。因为这个门槛没有那么高，但效率又非常高。　

00:29:36~00:33:06　

Monica：

让我们回来follow up一下。从Replit发布到现在，除了你刚才提到加了一个system之外，还有哪些更新对提高用户满意度和性能有比较大的帮助？　

李珎：

其实底层模型没有太大变化，仍然是GPT-3.5模型。主要更新集中在几个从零到一的AI特别关注的方面。第一个重要的更新是integration。对于从零到一的用户来说，他们更需要把产品接入到各种不同的服务中，这样产品才能真正产生价值。比如说需要接入OpenAI、Firebase、Supabase数据库，以及Stripe支付系统，只有集成了Stripe才能开始盈利。实际上很多LLM在integration方面做得并不是特别好。　

无常按：2024 年底了，竟然还在用 GPT-3.5——可见实际需求和 Benchmark 之间有很大的 gap，也说明模型以外的东西有多重要。　

首先要说明的是，LLM都有knowledge cutoff的限制。如果某个API的knowledge是在cutoff时间点之后发布的，模型就完全不知道这是什么。所以我们需要教会Agent使用这些最新的knowledge和integration，这让很多原本不可用的产品变得可用了。　

在代码编辑这个Agent最核心的部分，我们做了非常非常多的实验和更新。如果编辑做得好，就能更快完成用户需求。我们研究了应该提供什么样的文件context，哪些context需要被复用，还帮助用户firgure out他们需要的test。我们提供了data as service，既可以用Replit自己的，也支持接入外部数据库。

在数据库层面我们增加了很多控制，确保Agent写出的代码一定能够成功部署，因为LLM有时候写的代码部署后的效果和在Replit上看到的会不一样。　

最大的更新是我们的UI。以前的平台更像VS Code那样以IDE为主，现在完全是Agent first的设计了。技术栈从最初的Flask、Next.js扩展到支持React，又支持了更多用户想要的slack，这些framework本身就把“什么是好看”这件事包含在里面了。

我们还加入了让AI自己搜索图片的功能，以及一些工具让用户可以直接调整网站的颜色和字体大小，把一些原本需要AI来做的工作转成了UI工具。这些改进让产品在美学和功能上都提升了很多，过去三个月的进步真的让我很惊讶。　

00:33:06~00:35:57　

Peak：

我们刚才聊了很多从零到一的内容，作为用户我能感觉到这一年进展非常快，从零到一的达成率和速度都在提升。但从一到十的体验还没有那么ready，这方面你们接下来有什么准备？还是会更多专注于从零到一的探索阶段？　

李珎：

我们希望能帮助用户从零到一百，不只是做产品，还要帮他们赚钱。　

从零到一是现在的第一步，也是AI比较擅长的领域。我们看到很多用户每天通过smash Agent或assistant发送几百条消息，让产品不断改进，已经达到可用阶段。但从一到一百还有很多问题要解决，比如代码量大了之后的file context管理、数据库的稳定性和安全性、大规模用户数据迁移等。

这些都是传统软件公司成长过程中会遇到的问题，包括安全、规模化、合规等。我们的Agent需要一个个解决这些问题。因为是端到端构建的产品，我们在最开始就选择了AI能用好的技术，这让后续在安全性等方面的工作会更轻松。我们的目标是让用户在Replit上构建的所有软件都能很好地扩展，确保数据库安全和部署稳定性。　

Peak：

Replit发展到后面会不会完全覆盖现有云服务的场景，或者变成所有云厂商的一个前端？这可能是最疯狂的未来了。　

李珎：　

这是有可能的，但我们不可能什么都做，所以会用很多外部服务。比如在部署过程中就用了很多云厂商的服务，这也是我们很大的收入来源。可以说从零到一的AI产品公司最后会变成一个包含很多云服务的前端，但核心目标是帮助用户做好产品，后面会接入更多各种各样的integration和services。

如果某些功能是我们能做得更好的就自己做，如果云厂商或外部integration做得更好，那就是我们在发展过程中需要权衡的决策。　

00:35:57~00:38:09　

Peak：

我觉得这个听起来非常make sense。因为大家经常讲multi cloud多语言，其实我觉得这可能是Agent更适合的。　

Monica：

嗯，其实上次我们在聊这个Agent的时候，那时候Devin大家还只是看了个demo，对吧？那现在我好奇你自己有没有实际用到这个模型，有什么让你觉得跟你想象的不一样的地方。

而且另外我觉得有两个问题，一个是这些产品底层的model也用的是第三方的model，那到底上层这个产品比拼的是什么？第二是当foundation model的能力越来越强了以后，会对于你们所cover的这些use case会有一些更多的融合吗？你怎么看未来的发展？　

李珎：

对，我用了Devin，它确实比较符合我的预期，跟宣传片上非常一致。它非常准确地执行任务，即使是很小的任务，它也会执行，思考得非常全面，给你一个pull request。所以总体来说它非常符合我预期的形态。　

但就像我刚才说的，它的场景是在你本身知道要做什么，知道你的code base是什么，然后让它执行任务。这个产品形态其实是很新的。　

第二点是它的用户群体会更面向professional或者技术背景的用户。你会指挥它去做事情，去contribute，去code base。这个产品形态会稍微有些不一样。像我们的用户群体，可能有四岁的小朋友，有八十岁的老人，用户群体就很不一样。　

回到你的第二个问题，产品的差异本质来源于用户的差异。如果我们的用户是八岁或四岁的小朋友，那我们的UI交互和用户沟通方式，就需要让他们理解这些概念。比如为什么需要数据库，为什么需要API Key，API Key是什么。　

而对Devin的用户来说，这些基础知识他们大多都知道。所以最终的产品形态取决于你服务的用户群体。比如我自己也用Cursor写代码，因为我是professional程序员，但如果不是professional程序员，可能就会觉得有些困难。所以产品形态的差异还是由用户决定。　

当然对我们来说，模型能力的提升对所有人都有利。我们能跟着模型的提升获得免费升级，模型越来越好，我们的产品也会跟着越来越好。　

00:38:09~00:39:01　

Monica：

在国外，compound AI这个概念最近很火。在你们的实践中，是否需要结合一些其他的小模型？还是说你认为一个foundation model就已经足够了？　

李珎：　

我们肯定需要结合很多不同的model。因为不同的任务适用不同的model，主要考虑因素是性能、速度和价格。并不是所有任务都需要用最强大的模型，有些任务用小一点的model就能做得很好，比如Gemini，而且它们真的是非常便宜。

有些特定任务，比如fine-tuning这样的场景，可能需要用o1这样更强大的model去处理。

还有些场景需要特殊功能，比如使用Claude computer use来让Agent操作它自己的软件或者网站去收集信息。所以我认为未来大家一定会使用各种各样不同的model，不会局限于单一model。LLM的优势在于生成代码，但不同的task一定还是有更适合的model去做。　

00:39:01~00:39:40　

Monica：

大家都说，去年大家都希望看到产品团队能自己做model，但现在反而建议不要自己做model。不过从我们的交流来看，即使不刷Twitter时看到了这个demo，觉得extremely impressive。恰好那时我刚wrap up之前的research work，正在思考下一个工作是否能开发一个在Devin Demo里的Agent真实替我做事的AI。

结果前脚刚想完，后脚人家就做出来了，当时还有点小emo。第二天在推特上看到俊阳和Bingyuan说要做Open Demo和开源项目，我立即产生了强烈兴趣，因为这与我计划的下一个项目方向一致。　

在AI研究领域，你需要非常好的infrastructure支持。我最初加入的想法很简单，就是为了给下一个项目做准备。作为PhD student，如果想研究frontier capability，没有开源代码库的支持，研究能达到的上限就很有限。　

当时项目只有一个README就瞬间获得了上千个star，各种各样天南地北的open sourcecontributors二话不说就开始往里面写代码，整个项目呈现出非常bottom up的状态。随后GitHub用当时刚发布的Cloude UI生成了第一段前端代码，接着我们开始不断迭代。

后来Robert（现在的CEO）加入后搭建了整体架构，做出了第一个可运行的Agent，虽然效果不是很好。我后来把之前发表论文中的方法应用到OpenHands（OpenDevin）中，让它能够真正end-to-end完成一些相对简单的任务。最终在今年四五月份，我们决定将其做成一家公司。　

00:41:48~00:44:06　

Monica：

可以跟大家简单介绍一下OpenHands（OpenDevin）怎么去实现的？　

Xingyao：

我们尽可能把这个设计得很简单。后端主要分三大块：首先是Agent，它通过event service来记录历史信息，包括人类说的话和Agent执行的操作，然后生成相应的action。这相当于有个Event stream在维护所有历史发生的事情。　

第二个很关键但也很难做的component是Agent runtime。它主要负责把event stream里的所有action转化为具体的command去执行，比如在sandbox环境中执行bash command，让Agent能获取执行结果。　

这三块之间其实是纯粹的Agent和event stream的交互逻辑。用户交互是通过直接往event stream里加入信息来实现的。比如用户想让Agent做某件事，就直接把消息push到event stream里，Agent就能观察到。　

这样设计的好处是，虽然现在我们只有web UI，但未来可能会有多个Agent同时work on同一件事情，就像在办公室里多人协作一样。我们特意做了这样的future-approved architecture设计，考虑到未来可能有多用户连接到同一个Agent session，或者多个Agent连接到同一个用户。　

具体实现上，我们现在主要基于react code act这种方法，本质上是依赖LLM自己的能力，通过历史的action的observation去生成新的action，决定下一步该做什么。这种设计的好处是能最大程度享受到model更新带来的improvement。相比之下，如果用prompting heavy API的方法，可能享受不到直接用LLM生成action带来的这些提升。这是我们早期的一些Agent design decision。　

无常按：关键问题，值得所有 Agent 开发者思考的架构设计。　

00:44:06~00:44:46　

Peak：

刚好聊到 architecture，我觉得我们可以和 Devin 对比一下，聊聊两个项目在设计上的异同。我很认同刚才提到的观点，如果在 Agent层面做得够轻量，就能更好地享受到模型本身的提升。我自己也非常认同这个方向。　

在对 Devin 进行深入测试后，我发现它的情况有点像刚才讲到的 Pompt heavy 的情况。比如说在 OpenAI 里，无论是 Agent 还是 planner 都相对简单，而在 Devin 里，planner 似乎处于一个更高的地位。通过抓包分析，我观察到它的 planner 是以 DAG 的形式在进行规划。对此，我想请教大家对于 planner 的看法：它应该采用更复杂的设计，还是更简单的方案？　

00:44:46~00:46:51　

Xingyao：

关于planning这块，我们社区进行了非常多的讨论和尝试。我们实际上实现了4~5种不同的agent framework去做planning，但有趣的是没有一个能够超过模型本身的表现。我认为planning能力某种程度上可以作为模型本身的一个能力存在，不一定需要external planning。　

我可以分享一下Anthropic测SWE- Bench中的一个prompt例子。他们prompt里面包含了一种我们可以认为是更soft的planning方式，就是直接告诉Agents“follow these steps to resolve the issue”，用bullet points的形式列出步骤。我们试了很多方案后发现，在模型足够强的情况下，这种直接的方式反而效果最好。　

Planning还有一个比较头疼的问题。比如说我拿到一个问题，一开始想"OK，第一步做A，第二步做B，第三步做C"，然后把这个explicit plan（显式计划）建成图表给Agent。但实际执行时常常会遇到计划时没想到的问题。　

这种情况下，如果用explicit planning structure，就需要考虑很多工程决策：比如什么时候更新plan，并让agent根据更新的plan去做事，现在我们需要关心replan的准确性、是否能predict到replan的时机、replan是否正确，以及根据replan生成的新action是否准确。这引入了很多复杂的工程问题。　

最后我们的结论是，如果这个机制在benchmark上帮不了我们解决更多问题，反而带来这么多工程负担，那可能暂时不值得投入。　

无常按：实践出真知，again，值得所有Agent 开发者思考的架构问题。　

00:46:51~00:49:23　

Peak：

这个听起来很有意思。字节有个理念是“more context less control”。从工程实现角度来看，runtime是一个非常重要的部分，对工程能力要求也很高。我注意到Devin和OpenAI在实现上的一个区别：Devin采用VM方案，而OpenHands（OpenDevin）选择了container方案。

当然，作为开源项目，选择container会更方便。不过我在思考，像Devin那样使用VM是否能带来一些额外优势？比如说，Devin使用的browser不是headless Chrome，而是在图形界面上运行的完整Chrome。这意味着在未来，如果模型能力更强，直接对接VM可能会支持更多需要图形界面的场景，比如AutoCAD之类的应用。　

Xingyao：

这是个非常好的问题。实际上，我们在设计OpenHands Runtime时就考虑过VM方案，我们现有的代码理论上可以无缝衔接到VM上。本质上，我们的LongTerm就是一个server，在container还是VM上运行差异并不大，可能只需要两三天就能完成迁移。　

我们选择docker的主要原因是考虑到大规模部署的需求。比如说我们需要同时运行三百到五百个实例，VM的启动速度会比较慢，可能需要一两分钟才能全部就绪。而使用container的话，我们可以利用Kubernetes这样的资源管理工具，快速启动和管理大量实例，并且更好地连接各个docker container去做一些事情。　

说到Docker的限制，我完全认同。最近我们想让OpenHands实现自我开发的功能，但因为OpenHands（OpenDevin）自己用了Docker来跑runtime，在Docker内部运行Docker存在困难。所以我们正在考虑添加一个可选设置，让用户可以选择启动VM，这样就能直接安装Docker和GUI应用。虽然这两种方案在成本上可能有差异，但我认为我们的基础设施应该能够同时支持这两种方案。　

00:49:23~00:50:53　

Peak：

关于设计方面，我希望架构能够尽量精简。我在思考如果有图形界面的话，我们现在很重要的工作是要把Agent和action这个抽象层面做好。未来随着Computer Use更加成熟，模型能力也不断提升，配上图形界面后，我们是否有可能让这个抽象更加收敛？比如说现在我们还在使用browser这样的实现方式，未来是否可能完全收敛到Computer Use？这样更符合我们追求精简的长期目标。　

Monica：

我插一句，对于可能还不太了解Computer Use的朋友，大家知道Anthropic前段时间推出了API功能。能否简单介绍一下Computer Use是怎样的产品？　

Peak：

Computer Use是随着大模型多模态能力的进一步提升，以及一些额外的训练方法发展起来的。它提供了一系列新的使用方式，核心是让模型能够像人类一样使用电脑软件。具体来说，它可以执行移动鼠标、点击、选择激活element、使用键盘等基本操作。

这带来一个很大的好处：传统方式需要软件为大模型开放API，但这并不现实，因为大部分软件都是为人类设计的。所以让模型模仿人类使用软件，比直接使用API是更好的方案。当然，这项技术还在快速发展中，还不算特别成熟。　

00:50:53~00:52:23　

Xingyao：

我个人对于Computer Use和Simplify Action Space这样的行动方式是非常非常看好的。从简化的角度来看，我们实际上只有一个access to keyboard、一个鼠标和一个屏幕，这就是我们所有的Input Space，但通过这些有限的输入方式组合，我们却能完成非常多的操作。　

软件本身是一个非常非常强大的东西，我们可以用软件来构建更多的软件，然后用这些软件去控制这个世界上的一切。现在世界上的一切基本上都是被软件所控制的，所以如果你能生成好的软件，理论上来说就能做一些事情。　

无常按：当年的名言：Software is eating the world. 现在：AI is eating the world.　

让我们回到OpenHands Paper的话题。我们这个paper的名字叫做“Open Platform for AI Software Developer as Generalist Agent”，最终目标是开发一个通用的Agent。对于这样的通用Agent来说，我们认为最基本的action space应该包含几个核心能力：首先是运行代码的能力，最简单的实现就是通过Terminal；其次是编辑代码的能力，这需要一个File Editor；第三个目前相对缺失的能力是与browser进行interaction。

其实与browser的交互本质上和在电脑上操作各种app没有太大的区别。所以第三个点其实就是我们刚提到的computer use，computer use不是没有limitation的，现在的主要问题是，我们还是在以pixel level的方式在屏幕上进行操作，准确性还不够高。虽然短期来看这个能力可能还没有达到我们预期的那么capable，但我相信这个问题在未来一定会得到提升。

00:52:23~00:52:54

Peak：

我觉得听起来越来越像，OpenHands在做的就是赛博世界的自动驾驶。我们现在正在等待类似FSD这样的纯视觉方案的出现。　

Xingyao：

我其实觉得像这种简化的action space，最终的bottleneck其实就在model本身。其实foundation model只要你一开始就用上，后面就都不是问题了。　

我印象非常深刻的就是在Claude最新的模型发布之前，我们想方设法绞尽脑汁研究怎么去improve那个Agent editing。结果cloude一发布，直接把stream replace edit训练到模型里面了，这个问题虽然不能说完全解决，但也解决了百分之八九十。　

00:52:54~00:54:01　

Monica：

我觉得解决这些问题，你们的模型现在是不是也用到了computer use的API吗？　

Xingyao：

我们现在有一个方案是直接使用computer use功能。我们最近新合进去的一个功能是做visual browsing agent相关的工作，它做的事情和computer use有点相似，但它可以在所有支持Vision的模型上使用。　

我们开发了一个叫set marks的功能，它是把浏览器的截图拿出来，然后在截图上发现很多interactive elements。我们会把这些element框出来，用text的形式提供给Agent，这样Agent就知道哪些东西可以点击，然后通过这些预先标记好的mark去和网页交互。　

这种方式的好处是mark提前标好了，交互起来更容易。相比之下，Computer Use是直接在pixel space做交互，所以难度更大。而且我们这个方案对所有现在的vision LLM都有比较好的支持。　

不过既然Computer Use现在出来了，我觉得其他provider肯定会逐渐跟进这方面的能力，我们可能会有个新的standard。现在进展太快了，可能未来三个月就不需要类似这样的方法了。　

00:54:01~00:57:35　

Monica：

当Computer Use出来的时候，我们还在讨论是不是因为Anthropic 的to B基因的原因。他们本来就有很好的先发优势，这次终于不是OpenAI先发布vision-based模型，而是直接发布了API。

现在的问题是到底要用API这种形式，还是用其他形式。其实当OpenHands（OpenDevin）这样的产品足够强大后，这些功能都会被包含在里面。从最终产品形态来说，把这个作为一个能力，而不是自己去开发一个只用这种能力的产品，这样的impact会更大。　

我想了解一下，在过去这几个月里，你们在技术和business角度上做出了哪些重要决策？这些决策是如何提高产品能力和整体社区adoption的？Bingyuan如果有补充也可以分享。　

Xingyao：

我认为最重要的技术决策发生在早期OpenDevin阶段。那时我们处于相对野蛮发展的阶段，社区里PR满天飞。我和来自industry背景的Robert对OpenHands这个Agent有着完全不同的expectation。　

作为researcher背景的人，我希望这个Agent是easy to use的，可以很容易地进行迭代，做各种research和尝试。我不需要考虑任何UI方面的问题，只希望action的能力越来越强。但Robert更关注Agent作为产品需要和front end、User experience进行tightly integrate。　

在这两种需求之间做balance是很困难的，因为为了给前端用户提供最好的体验，有时候需要在Agent方面做出一些牺牲。　

比如说设计通用action时，你必须要求researcher按特定方式写Agent才能在front end里使用。但对很多researcher来说，我现在连AI能不能work都不知道，让我花那么多功夫去研究你们的实现方式，去研究怎么和产品结合，我其实并不关心那么多。　

无常按：哈哈哈哈哈　

所以我们做对了一件最重要的事，就是把back end分得足够清楚。我只需要关心一件事：我会把所有历史信息给你，你拿这些信息做什么不关我的事，我只expect这个Agent最后给我一个action就行了。这样在Agent开发这部分，我们就可以完全抽离出来，让researcher可以自己在这块专注开发，不用去碰框架里其他的代码。　

现在我们back end有两套使用方法：一套是和前端产品直接接入，另一套是Reheadless的方法，把Agent直接跟我们造好的一整套框架结合的使用方法。这对应了两种不同的人群：前者是希望用OpenHands完成工作的用户，后者是想push Agent能力的researcher和开发者。　

现在很多工作都在用OpenHands作为baseline，比如Commit Zero、Agent Bench，包括OpenAI的MLE Bench都在用它测试不同的benchmark。这是我们早期做对的一件事。　

00:57:35~01:00:24　

Bingyuan：

回顾OpenDevin到OpenHands的整个历程，我自己挺有感触的。开源社区的力量确实非常强大，从我们最初提出这个想法，到现在项目能够这么健康发展，开源给大家带来了很多不一样的东西。　

OpenDevin和OpenHands选择开源这条路，主要带来了两个重要的好处。首先，开源意味着透明，因为这种透明性，就像刚刚Xingyao讲到的很多优势都被放大了。因为我们要服务更多的人，让更多人参与进来，所以在架构和技术选型上就要去考虑更多的兼容性，这样才能确保项目未来的健康发展。　

第二个好处是开源可以打消大家对闭源商业公司的顾虑。更重要的是，我们相信未来的open model也能在open Agent中发挥作用。如果我们能从贡献open Agent逐步发展到一起贡献open model，让所有东西都是开放的，大家就会对未来更有信心。这种透明度、灵活性和每个人都有contribution的机会，正是开源的精髓。我们必须要通过开源的力量，在AI时代为每个人创造属于自己的AI。　

这也是我今天觉得OpenHands能做得这么好，大家能一起贡献的一个非常重要的核心动机。　

Monica：

正好我们来聊聊关于开源的问题。既然已经实现了这么厉害的能力，为什么会想要做一个Open Source版本的Coding Agent？这能给你们带来什么优势，又有什么挑战呢？　

Bingyuan：

一开始的proposal动机其实很简单，就是看到这个东西未来一定很酷。我觉得开源社区需要有这样一个项目，因为开源社区有很多有创造力和能力的人。如果我们能有一个组织把这些人凝聚起来，一起做一个非常酷的东西，这从历史到今天都有很多成功案例。

我认为做一个开放的Code Agent项目会非常有吸引力。事实证明当时热度确实非常高，仅凭一个Readme就吸引来Xingyao，这是我们一个非常大的收获。包括后面Gram和Robert的加入，都充分展现了开源社区强大的创造力。我们自己做Qwen，现在应该算是最拥抱开源的大模型团队，从开源中得到了很多。　

所以我们一直在坚持，希望能给开源社区反哺一些东西。我觉得未来面向AI的开源项目会越来越多，任何场景和任务都可能会有顶尖的开源项目出现。我希望未来开源的AI项目能与开源模型更有机地结合，真正把open这件事做到极致。往小了说，这是给每个人参与AI的机会；往大了说，这对整个社会的进步，以及推动AI民主化的进程都具有重要的帮助。　

01:00:24~01:03:34　

Xingyao：

刚刚Bingyuan说的非常好，就是democratizing AI technology。我们网站上就明确写着，这么重要的AI技术不能只保留在少数闭源公司手中，这是我们最初的朴素理念。　

作为一个researcher，我认为open source本身是一个非常好的research媒介。我们早期做different research时关注high performance，现在做LLM我们有Hugging Face，在serving方面我们有VLM等工具。如果没有这些开源的code base作为基建支撑，很多方面的科研进展都会相对缓慢。　

我们一开始就希望通过开源项目推动research and development。但是比如当我发布基于OpenHands的paper时，我会把相关代码都开源。这种开放的模式能让我们更容易吸收学界Research产出的高质量Agent。　

作为一个developer，我会为open-source摇旗呐喊。特别是对于developer tool这种让开发者自己使用的工具，在性能和体验相近的情况下，大家会更倾向于使用开源工具而不是闭源工具。　

我认为在Agent的实现上，并没有一个真正的大model作为护城河。比如说，我看到你的闭源Agent产品，通过观察它是怎么交互的，就能猜出背后的商业逻辑。我可能花两三个月时间，砸进去一些精力，就能复刻出一个表现差不多的东西。既然大家看着behavior就能猜到，为什么还要让大家浪费时间呢？不如直接把核心code开源出来，让大家在这个基础上投入时间做更多更有意义的technology创新。　

而且最重要的一点是，技术本身其实没有那么重要，但是让技术变得真正有用起来，这才是非常非常重要的。从这个角度来说，open source是有一定优势的。　

比如说VS Code，它本身就是一个开源product。大家可以很容易地去写各种各样的VS Code extension，这让VS Code成为了最powerful的IDE之一。用VS Code的好处是我们能用到很多community开发的extension，因为社区会基于各种各样的需求开发出丰富的extension。作为用户，我们有很多选择，能获得更好的用户体验。包括现在很多AI Code工具，它们的IDE都是基于VS Code开发的，这也证明了这一点。　

从另一个角度来说，我们希望开源社区在使用open source product的过程中，当发现产品有不够完善的地方时，能够更容易地去customize这个产品，根据自己的use case去改进它，并且把这些改进最终反哺到产品本身。这是开源社区的一个重要优势。　

01:03:34~01:04:24　

Monica：

关于开源的问题，这些数据其实可能是在他们自己的环境里收集的，你们未必能获取到他们的使用数据。　

Xingyao：　

特别是这种multi step的数据。其实我之前说的customization更接近于OpenDevin的概念。比如说OpenDevin早期就有很多用户在JavaScript上使用时会反馈一些问题，这种情况下通常只需要写一个定制化的prompt就能解决，比如说明在使用某种编程语言时需要注意哪些具体的点。

我们设想的customization就是想建立一个由社区贡献的library，虽然不是所有人都愿意分享，但总会有人愿意分享跟自己相关的use case，就像cursor最近有一个叫做cursor rules的library一样。　

01:04:24~01:07:29　

Monica：

我看到devin也有一个开源项目，在鼓励大家把devin用在这个开源项目里面，我觉得这可能是收集更多数据的一个方式。　

Xingyao：

对的，这样可以收集更多的use case，让产品适应各种场景。　

Monica：

其实你也提到很多能力还是来自foundation model。考虑到你们跟Devin面对的用户群可能比较类似，你觉得在这个赛道上，你们的核心竞争力和差异化会在什么地方？　

Xingyao：

从开源的角度来说，开源产品本身具有很多优势。比如对一些企业来说，他们不想被某一个大公司lock in，更希望能够获取source code。这样即使公司未来不在了，他们依然可以继续使用和维护产品。　

另外，对于一些highly regulated industry，闭源产品很难做open development。因为OpenHand是完全开源的，所以不担心Agent实现的secret被偷走。我们可以直接到这些公司内部，你给我们圈一块地，我们就把整个Agent系统部署到你们公司内部，这样可以100%确保所有数据都不会离开你们的环境。这种开源的特性让我们更容易赢得客户的信任。　

除了前面提到的，对于Agent产品最重要的一点是integration。因为Agent本身的定位，我觉得它必须要“live where developer live”，就是开发者在哪里，Agent就要在哪里。　

比如我们天天在Slack里讨论需求和bug，那这个Agent就需要在Slack里随时待命。从另一个角度看，开发者每天都在GitHub上做code review和comment，所以Agent也需要和这些已有的channel有很好的integration。这些都是除了IDE以外的integration场景。其实我个人觉得Async Agent和IDE的关系没有那么match，它更接近于一个微信聊天窗口，对面有你的助手可以帮你做各种事情。　

第二个点是关于customization的生态建设。我们需要发现一些对用户特别有价值的use cases。比如在OpenHands中发现某些经常要做的重复任务，像修复internal error或test case，如果能做到80%~90%的成功率，那么针对这种特定workflow的customization就很有价值。

我们需要建立一个好的生态系统，让足够多的人用产品去做足够多的事情。这样每一个任务都能形成prompt example供人借鉴，新用户可以更容易上手，老用户也能获得更reliable的使用方法。　

01:07:29~01:08:28　

Monica：

你们运营open source社区一段时间了，最近也在准备发布saas版本。能否分享下社区中哪些反馈对你们帮助比较大？　

Xingyao：

其实社区开发者呼声最大的几个feature，恰好也是我们团队最想要的，因为我们自己就是非常active的用户。不过从另一个角度来说，有一类特别重要的反馈是关于用户教育方面的。很多新用户在上手时会遇到困难。因为我们作为系统开发者，了解每个component的细节，有时候很难站在用户的角度去看待产品。所以用户在这方面给我们的反馈是非常大的帮助。　

另外，我们了解到用户在Openhands平台上有很多不同的use case。这些反馈让我们在改进产品时能够考虑更多场景，在做决策时也更倾向于开发通用功能，以支持更多的使用场景。　

01:08:28~01:09:41　

Monica：

我觉得这让我们重新认识到模型之上应用的价值。比如Devin设计的界面，在不同位置提供三个tab，包括web状态查看、代码查看，以及如何让用户在过程中进行交互和打断。像Cursor这样的产品也不是简单地在代码编辑器里放一个对话框。　

在有了AI特别是o1这样的能力后，我们需要思考是否应该把很长的inference看作一个bug，还是基于它的特点来设计新的交互方式。这些都是应用开发者基于对模型能力的深入理解和思考去做的事情，这也是我们作为投资人很期待看到的。我跟雨森也讨论过，认为把产品简单地做成wrapper其实是一种很懒的方式，这一点在AI领域会被反复证明。　

既然讲到我们对于底层模型能力的这个期望，那我觉得就不得不讲最新鲜热乎的o3了。那我觉得正好Bingyuan是这方面专家了。我想先问一下，首先是这个o1，o1这样的模型出现，觉得对于coding的模型这块有什么样的影响？那现在刚刚看到了这个o3之后，你觉得它又有哪一些是让你觉得最impressive？　

01:09:41~01:12:38　

Bingyuan：

首先o1出来的时候就让大家感到非常不可思议。我认为inference time computing这个路线非常有道理，它一直在推进这个chain of thought这个概念。当把chain of thought做到极致后，就会涌现出更多我们期待的智能特征。它的性能表现也非常出色。　

目前o1和o3主要是在一些容易验证的任务上表现突出，比如代码、数学以及考试类型的任务。我认为o这个系列现阶段还是以探索技术边界为主的研究方向。在产品应用层面还需要思考更多可能性，但在技术层面它已经证明了自己可以达到一个非常crazy的水平。　

昨天晚上o3的发布最令人震撼的是，他们确实把这条技术路线推向了极致。当我看到code forces 和AIME的水平时，我甚至怀疑自己是不是看错了，因为那个水平已经完全超出了我们的想象。对于当下LLM或者说当下AI的期待，o3的发布确实超出了我的预期。OpenAI急于证明自己的技术具有断崖式的领先优势，我认为他们暂时确实做到了。　

但OpenAI过去确实有一些决策上的失误，我觉得它在coding能力方面在过去半年里面其实在一定程度上落后了Sonnet。不过我相信OpenAI现在已经意识到coding这个赛道非常重要，所以用o这个系列重新把大家的视野拉回到通过inference和更强大的模型来把coding做到极致。　

o1有个细节，就是它在发布时某些SWE-bench上的分数其实不是很理想，当时大家都在猜测可能是他们没有投入太多精力投入到这些真实benchmark上。但看到昨天晚上o3发布的结果，确实让人震惊。特别是达到70分的水平，这在半年前是完全想不到的。我记得当时讨论时，大家觉得能做到40-50分就已经很厉害了。　

现在直接做到70分，这证明这条技术路线非常ok。这给我们的启示是，对于关键技术还是要更坚持一些。这种关键技术的迭代会带来断崖式的性能提升，这就是我们对基础模型最大的期待。　

老实说，现在大家对模型在某些任务上涨个1~2分或5分已经没什么感觉了，但如果能让某些任务突然提升20~30分，那对research和应用都是个震撼。我觉得基础模型的潜力还没有被完全挖掘，我们还可以期待未来半年到两年在整个智能领域会有更大的进步。　

01:12:38~01:14:04　

Monica：

这个我很好奇。我们之前看到，如果只看coding这个能力，包括开源模型和你们做的coding模型，与GPT系列模型的差距其实并不大。那么，看到o3跟o1有这么大的跨越，你觉得是o3是o1这条路线的延续，比如更多的数据和compute，还是有什么比较大的技术突破或改变？　

Bingyuan：

我觉得还是整体把Alignment做好了。之前无论是开放的社区，还是在追赶的大模型公司，都受限于infrastructure以及数据上的制约。我们在Alignment技术上与他们还是有一些差距。我觉得o1和o3他们在一定程度上做到了在Alignment阶段可以进行online探索和学习，再结合long chain of thought，整体呈现出一个非常完备的推理模型。这个确实很酷。　

Monica：

这个你可以展开讲讲。因为有时候有些观点认为，所有模型能力的提升不就是更多数据、更多compute和数据的暴力美学吗？除了资源之外，o3还有哪些我们可能低估的能力？另外，你刚才提到Alignment这一块，为什么在提升coding能力或者说在技术路线上会特别重要？　

01:14:04~01:17:52　

Bingyuan：

我有一个观点，虽然Ilya说预训练要结束了，但对于我们来说还有一段空间需要追赶。在pre-training上还有很大的发展空间，无论是token的数量、质量，还是对model size和model scaling的探索。我觉得今天开放的模型或追赶者的模型，在很多方面还有未知的东西需要搞明白。　

如果假设Ilya看到的模型就是OpenAI最强的pre-train model，考虑到OpenAI领先我们三到四年，有更多非常大模型的经验，包括数据的收集和整理，他们都非常有经验。如果OpenAI的pre-training已经达到相对饱满的位置，那他们在Alignment上的领先会更多。因为一定程度上Alignment上的进步会受限于base model，pre-train决定了LLM的上限。当我们没有更好的pre-training model时，完全通过Alignment去追赶OpenAI是非常困难的。　

所以我的第一个观点是我们今天的pre-training model还有进步空间。大家可以期待一下Qwen 3能不能会更加好。当你有了足够好的pre-training model时，差距可能就会体现在Alignment上。　

让我来解释为什么alignment对coding如此重要。从通用模型角度，我们期待与人类对齐，但coding model最终需要与开发环境或者和executer对齐。我们的首要目标是确保代码能通过环境的所有测试，实现预期功能。这个signal相比人类主观评价要严格得多，这也意味着我们有了很好的评估标准。　

另外，coding和math都是很好的方向，因为math有标准答案可以校验。coding model的优势在于不仅能解决竞赛级编程题，还能解决实际软件开发中的问题。无论哪种场景，核心都是让模型与环境完美对齐，理解当前状态并给出能通过执行器校验的响应。即使代码风格不够完美，只要能通过所有unit test，就能被用户接受。　

o3这样的形态特别适合code Agent。在这类任务中，比如提交issue时，用户愿意花一天时间让AI进行深入推理。从这个角度，在code agent阶段投入inference time的computing是非常划算的。　

培训很重要，alignment在coding中也很重要。我们对智能的探索可以从coding开始，泛化到更大的reasoning范畴，最终发展到完整的Agent。比如computer use就是很好的方向。我们可以看到一个清晰的进化路径：从Code Agent到Digital Agent，再到未来的Physical Agent。这就是为什么我们要在coding model和相关能力上投入更多，因为它是未来的基础。从这个角度来看，我们还有很大的探索空间。　

01:17:52~01:18:49　

Peak：

我们刚才讨论到了math和coding这两个专项模型。我注意到其他研究机构或公司在做reasoning模型时，通常会先从math或coding方向切入。但我看到我们的Qwen with Question使用的是通用的Qwen 2.5 32B instruct。　

Bingyuan：

确实，甚至都不是基于专项模型。这样选择是有原因的。我们当时想先给大家一个好的推理模型，这不是最终版本。在rush这个review版本时，我们希望能够兼顾各方面，所以选择了通用模型。这并不代表基于专项模型就一定做不好，这个我们其实也没有验证过。

在当时的产品规划下，我们希望在有限的budget内提供一个更全面的模型，因为这样可以吸引更多人参与进来。不过我认为未来我们还是会去探索更多垂类的reason模型，这也是很有价值的方向。　

01:18:49~01:20:08　

Peak：

其实刚才你说的第二点我觉得非常有意思。就是包括讲到coding的使用，这些方向之间有很强的关联性。刚才你讲到了一个递进的关系，我在想在咱们探索过程中，它们会不会能形成一种把我们带向AGI的自迭代闭环？你觉得这是有可能的吗？　

Bingyuan：

我觉得非常有可能。如果让我划分的话，首先code和math其实是可以属于reasoning这个范畴里的，它是一个更high level的任务，而且非常难。code和math其实是未来做digital agent的一个基础。就Agent来说，大家对它的期待肯定是智能，这个智能其实一定程度上就是要体现出reasoning的能力。一旦Agent的这个能力OK的话，就像我们播客一开始想的，我很希望能看到Agent的自我进化过程。　

就是它真正可以在世界里面给自己收集数据，自己去写training代码，自己去评估，形成闭环，然后不断地去提升所有的能力。我觉得未来的online learning一定要建立在reasoning的基础上，你希望model可以在真实世界里面自己学习，成为一个真正能够自我迭代的model，它一定是具备reasoning能力的model。所以我觉得应该是先递进，然后慢慢它就可以循环起来。　

01:20:08~01:22:26　

Monica：

让我们回到o3这个模型本身。我们可以看到它在各类benchmark上有惊人的表现，能够解决非常具有挑战性，甚至大部分人类都无法解决的编程和数学问题。不过在真实环境中，很多时候我们要解决的问题本身并不特别难，比如开发一个网站，就像现在我们看到让Devin去做的那样。　

这些工作需要在真实世界中进行多步推理、结合实际信息和工具来执行验证，最终找到解决方案。我很好奇，完成真实世界任务的能力和o3目前展示出来的解决高难度问题的能力之间是什么关系？有多少是相通的能力？要解决真实世界中的问题，基于o3可能还需要在数据、训练方法或泛化性等方面做什么改进？　

Bingyuan：　

o系列模型在解决数学和编程问题时主要展现了两个核心能力。　

第一个是之前大模型虽然具备但没有做得那么强大的逻辑推理能力。这个模型能够基于明确的问题描述构建出强大的思维过程，把复杂的需求拆解成一个个逻辑单元。在每个逻辑单元中，它都具备计算和编程能力，能够给出高准确率的答案。　

第二个是强大的方法总结和思维归纳能力，它能够从训练数据中总结出复杂的思维模式，知道什么时候该反思，什么时候该跳出当前思维继续推进。这种思维模式是它面对未见过的难题时泛化能力的保障。　

但在真实世界中，我们面对的环境和需求往往难以被定义或形式化，模型除了需要推理能力，还需要具备对这个世界的认知。o系列模型主要在定义明确的场景下验证了核心技术，对未来真实世界任务的泛化还有一些路要走。　

我们需要加强模型在模糊环境中的适应能力，思考如何把它在代码或数学上展现出的思维方式扩展到更多场景，同时确保不产生其他影响。实现这个目标最难的是如何在开放环境下定义反馈，因为只要有廉价的持续的反馈，模型就可以不断提升自己。　

无常按：对 o3 的总结，简明扼要，要结合 Deep Research 的真实 case 看，才能体会这段话的意思。　

01:22:26~01:24:05　

Monica：

我们看到o3已经展现出解决知识库之外问题的能力，比如coding force和Arc AGI相关的问题。对AI的一个终极期望是实现AI researcher，能够解决人类正在研究的未知问题。我很好奇，o3已经能解决这些大部分人类都无法解决的数学和coding题目，与未来成为研究员的能力之间有什么关联？虽然可能不一定是下一个爱因斯坦、牛顿，但至少要能发现问题，提出创新性的研究方向和答案的能力。　

Bingyuan：

我认为o3目前可以完成research的一部分，特别是需要排列组合的问题求解。这种能力并非简单的枚举，而是通过有逻辑有思维的方式进行信息的整合、加工、利用，并且二次创新。　

但对模型的更高要求是能够提出有价值的问题，甚至定义新的科学问题。这是一个递进的过程，因为科学发展本身就是从很多微小的创新积累到一个基点，等待一个能够定义新问题的人开启下一次科学浪潮。　

research本质上是逻辑和创造力的结合。但在AI帮助人类探索未知问题时，安全性是一个关键维度。我们不能因为模型的幻觉而导致错误的结论，这可能是实现AI researcher最具挑战性的部分。　

01:24:05~01:28:18　

Monica：

大家感慨SWE-bench突破了70%。我记得几个月前看到Anthropic的CEO在讲，要到明年下半年才能达到70%~80%的水平，没想到这么快就实现了。我很好奇，SWE-bench这样的持续突破，主要提升来自哪里？因为这不只是纯model的事情。另外，SWE-bench在衡量coding Agent能力方面还有什么不足？接下来我们还需要怎样一个benchmark呢？　

Xingyao：

我们前面还在开玩笑说SWE-bench“享年一岁”。确实没预料到进展这么快。按照目前的节奏，性能基准测试很快就会接近饱和。等o3再发布一两个版本，可能就能达到90%的水平。　

但还有另一个重要维度是成本。现在大家都在疯狂追求性能，但成本也很关键。今天看推特上有人说o3解决某个问题花了一千多美元。我们可能还需要半年到一年，才能把成本从一千多美元降到十美元。这是个性能成本比的问题——用一美元能达到多少性能。这个指标短期内不会那么快提升，而且这可能是开源模型的机会。开源模型可能只能解决50%的问题，但成本很低。现在我经常使用model router，把简单问题分配给简单的模型，把更复杂、需要深度推理的请求交给更强大的reasoning模型，这是个很好的发展方向。　

除了性能和成本这两个维度，我们还需要考虑go beyond SWE-bench。虽然SWE-bench很好地测试了Agent解决Github Issue问题的能力，但它忽略了人类在现实生活中需要面对的许多问题。比如我们现在使用AI Agent的方式，包括像Devin这样能在Slack中与人交互的集成，我们更需要measure Agent在真实公司环境下执行end-to-end task的能力。

最近我看到一个新的benchmark公司，叫做Agent company，他们创建了一个相当于open source的Google Docs等工具的模拟环境，让AI可以和模拟的人类在环境中交互执行任务。这可能是一个比较有意思的next step。　

Monica：

那当SWE-bench达到70%甚至80%时，我们该如何理解这个百分比呢？这是否意味着能完成用户所有任务中的70%~80%？这个指标对实际工作有什么指导意义？　

Xingyao：

这个问题问得很好，我之前和团队讨论过很久。我们认为从20%到50%对人类开发者来说是体验上的飞跃，但因为我们现在还没有access到能达到80%~90%的model，所以不确定这种体验上的飞跃是否还会存在，还是仅仅意味着Agent变得更聪明，需要更少的human intervention。　

另外一个值得讨论的点是关于potential data leakage（潜在的数据泄露），有可能在SWE-bench 上performance提升是因为已经采集的数据被更强大的model pre-training，已经通过inference scaling从历史中回忆出这些信息。这个问题需要更多关于data contamination（数据污染）的follow-up实验。　

我认为data contamination的实验挺重要的，它能够在很大程度上决定用户的实际体验能否提升。这里有一个关键问题需要考虑：模型的能力提升到底是主要来自它们本身能力的提升，还是主要来自它们能够从memory中回想起已有信息的能力？这两种能力提升的性质是不同的。　

01:28:18~01:29:40　

Bingyuan：

昨天晚上OpenAI只公布了70多分的分数，并没有给大家一个很震撼的demo或解决真实问题的demo。我相信这还是一个很初步的版本，说明即便是o3，应该还有很多未解决的问题。　

我觉得下一代benchmark应该更多从真实产品出发，因为模型在实际应用中都会有一些问题。要得到一个非常完备的模型是很困难的。从过去来看，我们一直认为benchmark可能是个很难的问题，但一旦它被定义好并可以评估，OpenAI就可以把它做到很高，我们Qwen也可以做到很高。但还有一些我们完全不知道的泛化性问题，一旦模型被大家用起来，很快就会发现问题。研究人员会把这些问题总结成新的benchmark，我们会继续合理地评估模型。　

关于Monica提到的70多分对产品意味着什么，我觉得还需要等o3正式放出来后看看最终表现。因为如果是我有一个在SWE- bench上得到70多分的模型，我一定会做一个非常酷的demo来向世界证明自己。可能由于时间关系或模型还有一些不完备的状态，昨天其实没有放出这个东西。我觉得对我来说可能是一个小小的遗憾。　

01:29:40~01:30:36　

Bingyuan：

就他们展示的demo还不够，他昨天晚上只展示了一个demo，让o3写一个简单的mini server并评估任务。这个任务相比我们在真实环境中开发真实软件的任务要简单得多。我期待o3能带给我们更多震撼的东西，比如说从一个很简单的起点开始，只需要几个指令就能完整解决问题，那个时候我们可能就达到了一个可用的状态。　

Monica：

其实前面提到你看到o3的几个特别震撼的地方，可以给大家简单选两个Benchmark分享。你觉得放在coding这个领域benchmark还缺失什么？你还希望看到哪些方面的工作？这些可能会成为下一代SWE- bench的内容。　

01:30:36~01:33:10　

Bingyuan：

昨天OpenAI在SWE- bench上的表现令人印象深刻，特别是考虑到o1之前在这个任务上稍微有些翻车。更让人震撼的是它在Codeforces上达到的水平。　

震撼的点在于，Codeforces现在还没有特别标准化的benchmark评估，但Codeforces是检验人类编程水平的平台。它会在固定周期内举办多场比赛，需要计算rank分数，相当于要跟人类同台竞技去写编程题目。他今天做到这个分数，基本代表在写文件级别的代码或解决方案时，已经达到了非常非常非常牛的状态。　

而且Codeforces在一定程度上可以缓解之前提到的泄露问题，因为每周都会有新的比赛和题目出现，我相信在泛化性上应该会有一定保障。但是Codeforces还是更多检验文件级别或竞赛级别的解决方案能力。SWE- bench可能已经开始有一些真实环境下的简单评估了。我觉得未来评估还需要提出更难的benchmark，在更真实或更具挑战性的条件下测试它们的表现。　

对未来benchmark的期待，我认为有几个重要的准则。第一，它要足够具有挑战性，特别是对已有的模型来说。第二，需要有动态更新的机制。比如说Live Code Bench是一个很好的benchmark，它从leetcode的周赛中抓取题目来评测模型。这种动态更新机制对于评估模型的真实泛化性非常重要。第三，选择的任务要容易验证。这也反映了现有技术路线可能需要依赖一些廉价的signal来达到好的效果。

Monica：

我们可能还不确定在coding和数学等能力上的提升，是否能真正转化到更general的日常生活Agent任务中？　

Bingyuan：

是的，但我一直认为这些基础task是一个strong model的必要不充分条件。即使是HumanEval到今天仍然有其价值，如果一个模型只能得到六十分，就很难让人相信它真的很强。这些benchmark的意义在于帮助发现短板，证明模型达到了基本水平。当然，真正应用时的表现如何，还需要时间来验证。　

01:33:10~01:36:44　

Monica：

我想讨论一个观点，假如我们遇到一个很得力的秘书或AGI系统，它可能并不需要精通数学或编程。那么，我们是否需要在coding和math这些领域投入这么多训练和优化？我们看到硅谷一些公司，比如magic def等，他们mission选择专注做一个最强的coding模型，而不是像GPT这样包含大量世界知识的大模型。这会不会是一个更高效的方式来实现AGI？　

Bingyuan：

我认为短期内走专家化模型是相对正确的路线。包括我自己做coder模型时，也是先排除非核心任务的能力，把某个任务或能力做到极致水平。我对AGI的定义不是实现像人一样的智能，而是实现人做不到的智能。比如在coding领域，我们期待模型能写出运行效率比人更高的代码。这在实际软件开发中非常重要，很多软件咨询公司就是专门解决系统效率问题的。如果模型能在某些任务上超越人类，这将推动AGI向新台阶迈进。　

专业模型在当下非常有价值，是一个探索边界的过程。如果我们能真正触及到一个边界，再把它扩展到更多任务上。在资源有限的情况下，我们可以先专注于某些任务，探索数据、技术和最佳实现方案。现在专注做coding是必要的，我们也可以期待coder能涌现其他能力，比如coding和math是否互补。我们可以先专注coding，然后解决好reasoning的问题，再逐步向通才发展。从长远来看，我还是期待有一个各方面能力都很强的通用AGI。　

Monica：　

对，就像秘书一样，最好是什么都会。这种工种的区分可能源于我们人类自身能力的局限性。　

说到这个，前段时间提出的τ-Bench，你们有用吗？　

Bingyuan：　

我们暂时还没来得及看，但后面会整合进来。　

Monica：

Xingyao呢，你们在实践中有帮助吗？　

Xingyao：

我们现在主要focus在SWE-bench上。我们的目标其实很简单，就是让Openhands能帮我们解决更多的issue。短期我们会继续重点关注这个方向，但从中长期来看，我们会更关心Agent如何和人类交互，包括agent与browser的交互，以及与其他integration进行交互。到那时候我们也会扩展我们的benchmark list。　

Monica：　

我们前面聊了很多细节的内容，我相信对于关注这个领域的同学应该能听出很多干货。那我很好奇，除了今天我们讨论到的，你们觉得Coding Agent领域今年还有哪些重要事件？　

01:36:44~01:37:58　

Bingyuan：

说到值得关注的方向，我觉得今年涌现的很多公司在front end上都取得了很好的进展。我觉得让Coder来写前端代码这件事情，它确实很擅长。因为现代的前端工具链已经很完善了，前端开发某种程度上像一个小型的planning任务，比如在页面设计时要考虑在什么位置摆放什么内容，数据流是什么样子。我觉得在这种场景下，AI确实很擅长做前端这件事情。　

前端对普通用户的感知会非常强。我比较欣赏之前看到的一个观点，不是所有人都需要会写代码，但使用代码的需求会更广泛。比如作为一个不会写代码的人想做个人网站或者做一个APP，大家最先想到的就是需要一个前端来展示要做的东西。我觉得前端可能是Code Agent一个很好的切入点。　

包括Devin在release的时候也特别highlight这一点，他们在前端任务上可能会做得更好。一定程度上这也是因为他们看准了这个方向的需求最强烈，技术上也更容易实现。相比后端这个复杂的技术栈，现在的前端已经慢慢走向统一了，一旦一个技术走向统一，这就是AI会擅长的时候。　

01:37:58~01:38:31　

Monica：

你说的这一点非常好，我觉得AI也会促进一些事情的统一。比如说之前在使用Devin的时候有个很惊喜的发现，当你给它很多任务的时候，虽然人类程序员有时候需要从头写代码，但AI能精准地找到一些我们可能都不知道存在的模型或开源库，AI的选择也会进一步促进你刚才说的这种收敛。　

Bingyuan：

是的是的。　

01:38:31~01:40:16　

Monica：

Xingyao，你有什么想法？　

Xingyao：

从Coding Agent领域来说，我觉得一个重要的发展方向是inference scaling方案。现在越来越多的Coding Agent都在探索这个方向，包括我们自己。比如在处理github issue时，这就像给人类一个slider，可以选择是花更多资源解决复杂问题，还是用较少资源解决简单问题。这也是一个notable trend。　

我们发现现在有些SWE-Bench的submission也在尝试做best up end的ranking。我们可以让Agent只生成一个solution，也可以sample多个solution，然后通过verify或reward model对solution来进行re-ranking。但难点在于如何把sample multiple的方案和实际应用结合起来。　

Monica：

我看到你在群里也分享了你们分享了一篇你们发表的工作“The Agent Company”，你们也提到了在接下来end to end整个产品能力上去促进。　

Xingyao：

是的，还有在inference trend scaling 在遇到真正的产品问题上是否起效，比如在处理end-to-end任务时，如果涉及循环发送消息，同时采样多个方案可能会导致Agent向同一个群发送八条不同的message。这就需要我们在research到产品实践中bridge更多的gap。　

Monica：

这确实是个open question。我看到你们最近发表的文章也提到了这些挑战，你们用了很多例子都是Opendevin相关的。　

Xingyao：

是的，Agent Company本身就是用Openhands作为basic Agent进行开发的benchmark。　

01:40:16~01:41:32　

Monica：

关于这个benchmark，能详细说说吗？　

Xingyao：

这是由Frank和Gram的实验室主导的研究。我们人类开发者除了编程本身，还需要做很多其他工作。比如和同事沟通、修改和执行代码，现实生活中还要安排会议室、做分析工作、进行代码审查等。　

他们的论文核心就是试图把公司中的这些主要任务都纳入到benchmark中，让Agent从Junior engineer到CTO的一个转变的measurement。　

Monica：

这个涉及Multi-Agent问题，我们之前讨论过Multi-Agent是不是一个伪命题？　

Xingyao：

这个其实是Multi-agent的问题。他们的benchmark setting是用LLM来模拟人类，给出各种场景，然后模拟人类对Agent的回复。他们给这些LLM提供了足够的信息，相当于模拟了真实的人机交互场景。核心目标是测试Agent本身在公司架构下的能力变化。　

01:41:32~01:43:46　

Monica：

随着coding的出现，我们发现它不只是赋能程序员的问题了，还有可能带来整个组织的改变。我在想我们以后是否还需要工程师？如果需要的话，又需要怎样不同的工程师？　

戴雨森：

肯定我们可以看到，工程师的很多工作其实会被替代。我在Chatgpt出来时的一个感受就是，只要你的工作能被总结成为简单的缝合怪工作，就是把一个已知的东西缝合到另外一个东西上，这种复制粘贴型或者稍微修改性的工作，其实被替代速度是很快的。

现在的AI已经具备了很多智能和知识，比如说AI自己写代码的能力是一方面，同时它知道GitHub上所有的库和模型，所以它可以不断调用人类已有的知识去解决问题，因为你的问题大概率已经被人解决过了，或者已经思考过了。　

很重要的是要让AI能够把人类已有的知识结合起来。AI扮演的是一个胶水的作用，是个复制粘贴的作用。你要完全原创写一段人类从来没出现过的代码，可能还是比较难的。但是我觉得大部分人，大部分工作其实都是可以被复制粘贴或者被缝合这个概念去解决的。大家要想想看自己的工作中真正不能被缝合解决的是哪部分。　

简单来讲，你现在可以以低于正式员工的价格无限地请实习生，这个实习生会不断进化，能力会越来越强，可能从实习生变成了像现在所有的正式员工一样。这给每个人带来一个很大的挑战，就是要学会当一个老板。大部分人其实是有一个老板的，可能很多人没有当过老板或者管理者，但是这个时候你怎么样指挥管理、训练AI可能会变成每个人都要去思考的事情。　

这对于我们整个教育都是很大的挑战。现在的教育基本上还是处在一个过去培养产业工人的思路，就是你去学习一门技能，学习怎么去执行一件事情，然后毕业后去干这件事情，一直干到退休。　

但是我们首先发现这个世界变化很快，之前学的技能可能后来没用了。现在进一步发现，可能执行的那部分逐渐都可以被AI完成的时候，真正重要的工作是提出好的问题。这个时候，对于我们每个人职业上的挑战，或者说得不好听是挑战，说得好听一点是进步的空间，就变得会很大。这是现在年轻人要面对的一个非常重要的思考问题。　

01:43:46~01:45:17　

Monica：

感谢雨森给我们拓宽了思路。我想听听在座几位既是程序员，同时又在做Agent的朋友们，你们对于Agent未来工程师的需求，以及对未来组织的影响有怎么样的理解？　

李珎：

我觉得雨森说的方向非常正确。所有的程序员都会慢慢转变成更像资本家或管理者，去控制Agent或AI去做事情。我举一个非常具体的例子，我有一个IOI金牌的朋友，写代码非常非常强，但他觉得Cursor不太好用，试了两下就放弃了。而我觉得Cursor非常好用，因为我自己写的代码可能还没有Cursor好。我会比较有耐心，慢慢去调教它，让它写出正确的代码，这样我就会成为更好的AI使用者。　

随着大家越来越发现AI的价值，我们会变得越来越会用AI。特别是新一代年轻人，他们是跟随着这些AI工具长大的，可能用AI写的代码比自己直接写的还要多。他们使用AI的形态会越来越接近资本家，就是控制Agent去做事情，越来越像一个CEO，越来越像一个manager。他们不需要去worry about太多细节，因为这样更productive。包括Agent的设计也会越来越像一个给公司CEO设计的产品，而不是给程序员设计的产品。　

无常按：又是一个来自一线创业者的洞察，很有意思。　

人需要考虑的是更具创造性的、更偏向规划的事情，比如什么是product-market fit，如何完成创业的整体流程，而具体的执行部分则交给Agent或AI来负责。　

01:45:17~01:46:06　

Monica：

那你觉得未来程序员需要怎样的能力？我们去招一个程序员，我们还希望他去完成什么样的任务？那对于程序员整个career path培养和教育会产生怎么样的影响呢？　

李珎：

我认为更好的程序员应该具备更多的产品思维，他们知道从正确的视角看问题，并能通过数据来验证一个方案到底是好是坏。比如说对于一个产品feature，关键是要知道这个feature的效果如何，然后不断地进行迭代改进，很多具体的开发工作可能会被取代。　

如果要定义一个好的程序员，我觉得应该是具有产品思维，更像一个founder那样能够借助AI完成整个流程，而不是仅仅完成feature开发。这种overall的能力是非常重要的。一个好的founder其实就会是一个100x的程序员。　

01:46:06~01:47:30　

Bingyuan：

对于这个问题，我个人是比较乐观的。随着Coding Agent的不断强大，人类也会随之进化。历史告诉我们，每一次科技革命都带来了巨大的生产力提升，让人类能够更专注于创造性价值更高的工作。　

未来我们会让AI来处理软件工程开发中的很多冗余工作，这样人类就可以从具体的编码工作中解放出来，将时间和精力投入到更有价值的思考中。代码其实也是AI内容生产的一环，现在的模型已经展现出很强的想象力。　

过去的人类工程师都倾向于走专业化路线，比如前端工程师专注于前端技术栈，后端工程师专注于后端领域，即使在同一个方向上，不同的工程师对技术也会有不同的偏好。　

而AI可以学习更多的code token，对整个代码世界有着很好的全局观。未来代码创作是AIGC的重要组成部分，AI能够创造出我们今天的程序员和产品经理都想象不到的东西。我相信未来人类和AI程序员之间会形成很好的共生关系，双方可以紧密合作，互相听取意见，不断创造出更有意思的事物。我对这样的未来充满期待。　

01:47:30~01:52:20　

Monica：

我觉得按照这个进化思路，这可能不是幻想。因为刚才Xingyao已经说了，他们都已经能够让他们的Agent成为他们整个codebase最active的controller之一。我在想，如果两三年后我要成立一家公司，是先招Agent然后再想需要补什么样的人，还是像现在一样先招人再用Agent补足能力。　

就像戴雨森说的，对于整个组织架构，以前是软件把组织里面的人聚合起来，现在也许需要不同的软件把人聚合起来，这个的确可能会带来非常fundamental的影响。我也听听Xingyao，尤其是你们机构内部用上AIagent，你是怎么看这个问题的？给你们的组织带来哪些变化？　

Xingyao：

我觉得现在最直观的感受就是我们对新feature和新工作的态度完全不一样了。以前开发新feature时，需要考虑时间投入、前端资源是否充足、优先级排序等问题。但现在随着Async类型的Coding Agent逐渐成为现实，就像前面雨森说的，限制我们能做多少的已经不是能力本身，而是想象力。　

世界上的问题只有两种：Agent能解决的和解决不了的。对于Agent能解决的问题，只要想清楚就可以交给Agent去做。在我们的开源社区里，因为整个code base是开源的，不仅公司内部在用，我们现在的beta版本已经有上百位用户在日常使用。

我们社区有一位很有意思的founder，他没有招很多程序员，而是把OpenHands作为开发资源放在他的项目中。他会同时开启二十个issue，让OpenHands并行处理，虽然可能只有一半能work，但这对他来说不重要，因为他的目标就是让Agent帮他并行开发。他一直在催促我们加快开发，这样他就能启动一百个Agent同时工作。　

这个例子很好地说明了工作方式的改变。就像前面李珎和Bingyuan讨论的，现在对人类来说越来越重要的是知道自己想要什么，而具体如何实现它反而不是最重要的事情。　

就像Bingyuan前面说的，以前我们走专家路线，对某个领域非常熟悉，能快速完成任务。　

我可以分享一个例子。我自认是个非常糟糕的前端开发者，对前端的了解仅限于学校一个学期的课程，但我能看懂前端代码的基本逻辑。　

今年十一月份，我用OpenHands（OpenDevin）做了一个早期功能。当时我们刚加入多模态能力，我给OpenHands（OpenDevin）一个启动界面的截图，用微信画了个红色箭头指向聊天框，直接要求它帮我实现拖拽图片的功能。让我惊讶的是，它一轮就完成了，直接把drag and paste image写进代码并实现了功能。　

但后来发现代码库有问题，我让它修复问题，它也很快完成了。但玩了一会儿后，我发现一个之前没想到的问题：拖入图片时没有视觉反馈，用户不知道是否操作成功。　

这时我更像是一个甲方，在验收它交付的成果，看是否符合预期。因为OpenHands（OpenDevin）能在十分钟内就实现功能，让我能及时测试、探索更多用户体验的可能性。这让我们意识到，不需要成为前端专家，但需要能看懂代码、明确知道自己想要什么。　

另外，作为管理者，需要给Agent明确的、可量化的目标。如何正确地做prompting、布置工作，这是未来开发者的重要技能。　

无常按：最近也有类似的感受，目前能用好 AI 的——也就是能写好 Prompt 的——往往是有管理者思维的人。　

01:52:20~01:53:44

Monica：

看了你刚才展示的编程过程，我想到之前和朋友一起使用Devin的经历。当时让它做一个博客网站，它在完成后会主动测试UI，自己写两篇文章来测试整个flow。这让我想到你刚才提到有点像o1的思维方式，与其说让你去检查它哪里不对，不如说它能力进化后自己就具备完成测试、发现问题并解决问题的能力。　

Xingyao：

我们确实考虑过是否要在产品中加入让Agent主动进行测试的功能。最后我们决定不加入这个功能，而是把这种可能性开放给用户，让用户自己决定什么是最适合他们的。　

但这也带来了另一个挑战，就像李珎前面提到的，用户教育对我们这类产品来说非常重要。因为如果用户不了解Agents的能力边界，往往就想不到要使用哪些功能，需要explicit去告诉它。这是AI Agent产品的一个限制，我觉得这个问题值得讨论。　

我们需要思考的一个问题是，是否需要让Agent明确地去执行某些特定任务，还是让它完全按照用户的指令来执行。　

Monica：

这个问题不只是一个安全问题，而是一个更广泛的产品设计问题。这与我们如何设计产品有着密切的关系，是一个非常重要的问题。你们有什么补充吗？　

01:53:44~01:55:02　

李珎：

就像我刚才说的，如何让Agent告诉用户它能做什么，这件事特别特别重要。我最近在Replit上加了一个功能，让Agent在完成用户的一个feature后，会主动建议下一个可能的feature，告诉用户怎样完善这个产品。　

从创造力这方面来说，用户很多事情是想不到的。比如说，他做了一个personal notebook，可能没想过要加summarization，没想过在前端加一些动画效果。他们也没想到可以增加一些付费功能。但这正是AI最擅长的，AI最擅长be creative，告诉你下一步能做什么，尤其是AI自己知道自己做了些什么，对整个cobe base项目有更完整的认识。　

这就变成了一个无限飞轮：用户完成一个feature，Agent就建议下一个，用户再选择要做哪个feature，这样不断把产品做得更好。这种方式不光适用于从零开始做产品，也适用于生成pull request，就是AI指导用户，用户跟AI合作的模式。这个功能是我上周才发布的，用户都特别喜欢。　

01:55:02~01:55:49　

Monica：

说到Agent的能力边界，我想到了o3的例子。o3在code forces上的分数超过两千七，而能达到这个分数的人类却不到两百人。这是否说明在很多任务上，实际上可能是Agent在教我们如何做事？最终可能是Agent自己识别出还有什么是它做不了的，然后再来给我们分配任务。　

李珎：

现在Opendevin已经是这样的形式了，就是由Agent去执行任务，然后让人类来confirm。这个confirm其实就包括了code review和各种交互。最终人类要做的就是confirm和guide，就是确保Agent不会做出一些crazy的事情，比如把数据库drop了。　

01:55:49~01:57:33　

Bingyuan：

我有个观点，就是现在o3和o1都在讲inference-time computing，其实人类也可以参与到这个computing环节中。无论是处理很长的problem还是多轮之间的feedback，如果把这些看成一个完整的response，人类的language能力其实也是在贡献到inference-time computing里面。所以未来真的不太好说，可能AI会主导整个planning，人类反而在给它打工。　

无常按：不是人教 AI 做事，是 AI 教人做事；不是 Human in the Loop，是 AI in the Loop。　

Peak：

我觉得未来可能会很奇怪。比如两年前我们刚开始搞大模型的时候，经常review模型输出，觉得这块支持得好，那块有问题。但最近随着新一波模型比如Qwen-Q、o1的出现，特别是在做GPT QA benchmark的时候，我已经完全看不懂模型在做什么了。　

我觉得我对比AI最不可替代的优势就是我可以坐牢，我具备极强的背锅能力。现在基本可以跟AI模型一对一了，我来review它写的代码，尤其是写数据清洗脚本这种一个回车可能就损失一千美金的场景。未来如果模型写的代码越来越复杂，可能需要五个工程师来review AI五分钟写出来的代码。　

Monica：

这也说明了security这个问题为什么那么重要，AI可以选择性地隐藏某些行为，不需要完全披露其操作过程。　

01:57:33~02:00:14　

Xingyao：

对，其实刚才Peak讨论的这个问题让我想到OpenAI早期就在研究scalable oversight和weak to strong transfer这些问题。随着模型变得越来越强，人类review代码所需的时间会越来越长。其实AI Agent本身也可以帮助我们review代码，可以让一个AI写代码，另一个AI进行深入研究分析，最后人类只需要盖个章。从背锅的角度来说，人类工程师是绝对会消失的，只是角色会发生改变。　

Monica：

这确实是个重要观点。不过目前我们对AI的定义还是一个junior engineer，包括Devin也是这么定义的。刚才Xingyao展示的几个任务，也都是给初级工程师做的事情。那要让AI实现我们期望的未来，成为组织里的主力，你们觉得还需要提升哪些方面？　

Xingyao：

第一个是信息的来源和集成问题。我们人类能够访问到的所有信息渠道，这个Agent就必须能访问到。比如说公司内部的各种系统，或者我们用来沟通的Slack，Agent都必须要能访问，这是Agent变得更加独立的必要条件。　

从junior engineer晋升到senior engineer，最关键的转变点是信息获取能力要与人类处于同等水平，不能存在明显的信息差。　

此外，model本身的能力也很重要，特别是planning能力、从错误中恢复的能力，以及积极主动的特质。　

一个高级工程师在接到任务后，不会立即开始编码，而是会先审视公司的现有架构。然后提出多个可能的解决方案，分析每个方案的优劣势，同时要考虑到后续维护时可能产生的各种影响和成本。　

作为senior engineer，这个Agent需要在恰当的时机主动询问关于Design，Decision等关键的基础设施问题，像OpenHands、Cloude 目前已经初步具备了这样的能力，比如当我让它写代码时，它会主动提供多个方案供我选择，并给出建议。　

但最重要的是要确保Agent不会在未经授权的情况下执行未经批准的操作。就其他的model capability而言，我认为OpenAI-o3已经离目标不远了。　

02:00:14~02:02:37　

李珎：

我完全不担心model capability，因为我相信大家一定会把它推上去。从我的角度，最重要的是feedback loop，我们要给Agent一个正确的signal让它执行。　

比如说我们做产品时，如何验证我们做得对不对？我们首先实现产品，然后做实验，通过实验的signal来决定好坏。这个signal可以是A/B test、用户反馈、点击率或test pass。　

为什么Coding Agent今天这么好，是因为code是一个signal特别强的领域。代码首先要pass语法检查，还要pass test。这是非常强的signal，所以AI能做好，因为它可以自我验证。　

我们给Agent的signal和feedback越多，它的自主性就越强，需要人的干预就越少，能做的事情就越多，scale能力就越强。　

所以feedback非常重要。如果给足够的feedback，它可以自己propose产品idea，自己做MVP，自己在Twitter上promote，自己写文案，自己投放广告。然后根据广告和文案的结果收集分析并改进。这一切几乎不需要人为干预。　

理论上是这样的，所以feedback loop非常重要。一旦feedback loop给得好，它可以做非常crazy的事情。　

Monica：

这个feedback loop是一个model capability吗？还是产品层面的东西？　

李珎：　

我觉得不是模型能力。其实是一个integration的事情，就是让Agent能自己做A/B test并处理结果。　

包括在Twitter上发软文，投放广告，把整个产品流程走完。这已经beyond engineer scope了，但我觉得这是未来的正确方向。因为engineer通常只care把事情做好，把什么是正确的decision交给founder、VP或data scientist。　

但对于Agent来说，可以用separate Agent来处理这些decision。如果把AI作为整体考虑，它应该有自己make decision的能力并持续迭代。在这个过程中，用户增长、Revenue增长这些都是很确定的signal，能指导什么是好的，什么是不好的。这也是人类的做法，也是最scalable的方式。　

02:02:37~02:05:03

Monica：

Bingyuan，从你作为一线做模型的角度来看，你觉得我们接下来还有哪些要攻克的地方？　

Bingyuan：

我觉得从模型角度来看，未来还有很多可以做的事情。正如李珎提到的signal这个事情非常exciting，一旦有了signal，我们就可以做很多事情。coding在未来可能会更多地加大对alignment的研究。　

目前的code model中，这个世界上的代码token相对于普通token来说，数量其实并不会特别大。也就是说在pre-training过程中，我们很可能能够获取到很多现有人类产生的高质量token。关键是要思考如何让这些code token在最终应用环节上能够更好地服务我们的需求。　

其实在Alignment上能做很多事情，从OpenAI和当前最顶尖的模型来看，我觉得planning能力是一个重要方向。现在很多模型的planning能力还做得不太好。就像Xingyao刚才提到的案例，如果模型的planning能力很好，对于修改前端这个任务，它应该能从一开始就规划好那些feedback。如果能提前规划好，实现起来就会很顺畅。所以我觉得对于code Agent来说，planning能力会是一个重要的研究方向。　

Xingyao：

是的，planning这个概念包含了很多内容。像我们这样提前考虑到问题，也是很关键的一部分。　

另外一个重要的能力是从error中恢复的能力，有些观点认为这也属于planning能力的一部分。planning涉及最开始的task design，以及遇到挫折后如何改变strategy来实现task的目标。　

印象深刻的是Sonnet包括GPT-4给我们展示的能力：如果它尝试某个任务失败超过三次，就会尝试其他方案。而之前的模型会一直停留在失败的分支上重复尝试。这也是强大planning能力的具体体现。　

Monica：

那要怎么样能够提升模型的planning能力呢？比如说我们现在强调reasoning的能力提升，我们看到o3主要在coding和math这方面有提升，这两个能力的提升是否就能带来planning能力的提升？还是说中间还缺什么东西？　

02:05:03~02:06:14　

Bingyuan：

对于如何提升模型的planning能力这个问题，从模型角度来看，我认为关键是获取更多高质量的planning数据。　

比如在GitHub上，当人类提交一个request并将其拆解成多个commit时，这些commit message本身就是一个很好的planning process。　

另外，我们也可以尝试合成数据的路线，因为最终signal是可以很容易验证整个planning是否能work的，所以可以尝试合成更多的planning来增强模型的planning能力。　

李珎：

我想补充一点，对于Agent产品来说，用户的feedback其实是很强的planning的signal。　

比如当Agent做了某个改动后，如果功能没有实现，用户会告诉你不work，甚至会回roll back到之前的版本。　

相反，如果改动是正确的，用户会给予确认。在这个过程中，我们就收集了很多RL signal。　

你可以想象Agent可以采用蒙特卡洛的推演方式，在未来可能的多个改动中找到好的方案。根据之前收集的用户feedback，你可以有一个reward去评判什么是好的。这样通过在不同改动中采样，Agent可以提高自己的成功率。这其实是一种planning，会随时间推移而不断改进的方式。　

随着用户数量增加，他们提供的trace数据不断积累，这让我们能够做的事情也越来越多。Agent就能在多个可能的执行路径中选择更优的方案。　

Monica：

确实，仅仅提高推理能力是不够的，我们更需要multi step的数据。这在之前的模型训练中还比较少见。　

李珎：

这种数据只有在有Agent产品时才能获得数据。如果让没有完整context的人去标注AI的代码改动是好是坏，以及具体原因，这几乎是不可能完成的任务。　

但Replit Agent、Devin或Openhands的用户每天都在自然地产生这样的标注。这些标注数据的质量非常高，每个用户的反馈都是dataset的一部分，能帮助未来的改进。　

02:07:13~02:08:50　

Monica：

你们在开发foundation model时，数据主要是在Agent应用中产生的。那接下来对foundation model公司来说，如何提升这方面的能力呢？　

Bingyuan：

我们可以从foundation model角度也可以快速搭建环境，让Agent在里面进行交互来产生数据。在数据策略上，可以先用合成数据做warm up，等未来应用爆发后，再用人类的真实数据让它变得更strong，更好地与人类对齐。　

Monica：　

在湾区时，我们看到很多公司在做infra for AI Agents。虽然在国内这个趋势可能不太明显，但在国外，即使在Devin这类产品出现之前，工业界就已经出现了一些workflow的Agent化产品。这催生了很多做Agent基础设施的公司，包括新一代的爬虫公司，帮助Agent更好地读取网页，以及做anthentication授权和权限管理的公司。我很好奇从infra或开发者工具角度，还有哪些让Agent更好地进入production的机会？　

02:08:50~02:11:08　

李珎：

我觉得Agent的capability领域存在很多好的机会。比如当Agent需要访问网页或读取API文档时，有公司专门提供将网页转换为markdown格式的服务。这类服务会被我们这样的Agent公司直接使用，因为非常方便。这类专门为Agent构建capability的公司，包括让Agent读网页、run test、自我验证、接入更多API等功能。　

另一个重要方向是Agent的framework。比如LineGraph 或者LlamaIndex用来build agent的tools都很有价值，因为Agent开发过程中涉及memory management、execution需要user interrupt、rewind memory等诸多问题。这些最终会以framework形式出现。现在已经有很多framework，未来会出现更多更好的框架去build agent。此外还包括prompting、给人类使用的database等infrastructure。　

现有的database都是面向人类设计的，需要新的API形式面向agent。比如在drop database时需要人工确认，这就形成了人、Agent与第三方service之间的交互问题。　

Anthropic的MCP就是为了解决这个问题，让Agent以protocol的形式在用户和第三方service之间进行调度，可以获得用户确认后调用第三方service。随着发展会出现更多类似需求，包括note和translation等功能的结合。从Agent的角度来看，这些功能的形态可能都会有所不同。　

Monica：

我觉得这个系统非常全面。Xingyao，你们在集成过程中有使用什么辅助infra工具吗？　

02:11:08~02:13:24　

Xingyao：

现在我们接触到的AI infra工具非常多，特别是runtime相关的。Runtime是一个非常棘手的问题，因为需要执行代码。市面上已经有很多B-TO-B公司在做这方面的工作，比如Model、Run Loop等，他们都将自己的第三方功能集成到我们的开源代码库中，给用户提供了更多选择。

对于生产环境规模的应用，我们可能需要一个worry-free的方案。但作为开源产品，我们需要平衡，希望给用户最基础的体验，即不需要任何第三方服务就能使用。　

最近我们遇到一些问题，让我意识到这些第三方公司非常有价值。有用户反馈在浏览网站时会被机器识别系统识别为自动化操作，要求处理验证码和图片识别。一些公司专门负责维护浏览器，确保不会遇到这些问题，由infra来解决而不是让Agent开发者去处理。这对开发者来说是很好的工具，但作为开源开发者，我们担心如果告诉用户这是唯一使用浏览器的方法，用户会不开心。　

李珎：

我想补充一下关于runtime的重要性。如果看现在面向消费者最广泛的几个Agent，包括Bot、V0、Replit，这三家公司有个共同点，就是在runtime和web container方面都已经做了很多年。Bot的母公司和Replit都是做云IDE出身的。我们包括code都已经在如何在web环境中运行代码的container这件事上做了大量infra工作和优化，使得用户可以很快启动环境并运行。这些公司能够做出好的Agent产品，正是得益于runtime基础设施的完善，我认为这件事非常重要。　

02:13:24~02:20:14

Monica：

作为投资人来说，在AI应用领域，大家一直都很关注专业AI和AI Agent的落地情况。AI应用能否真正落地？哪些产品最终需要由模型公司而非产品公司来做？这是很多创业者和投资人都在探索的问题。雨森，你如何看待AI应用和AI Agent的价值与投资机会？这些想法会因为Devin的出现而发生变化吗？　

戴雨森:　

我觉得有一本书的副标题“the future is faster than you think”很能总结我的感受。在年初的时候，对Agent的讨论还是比较概念性的，虽然大家都觉得Agent是未来，但对它具体长什么样、什么时候出现，我觉得当时整体来看还是认为是一个相对比较长时间的过程。这也体现了投资人对事情的预判在时间上往往会差很多。　

现在的Agent产品已经展示出几个重要特性：对任务的planning能力，写代码的强大能力，使用工具的能力，以及能在工作中不断积累对组织的knowledge，还有自我学习进化的能力。而且是按照卖工作，不是卖工具的思路，所以可以对标人类的薪资。当一个事情有了第一个带头的，后面就会有很多人去改进跟进。　

今年我们看到了三个非常大的技术进步。　

第一个是AI的reasoning能力大幅提高，这让AI在做planning时变得更好，hallucination会减少，能够进行更长时间的planning，并且更好地follow计划。　

第二是AI编程能力的大幅提高，以Codeforces为例，o3都已经做到两千七百分，这基本上达到了人类顶级程序员的水平，而且这个水平还会继续提高。　

第三是AI使用工具的能力。这三个技术进步奠定了数字世界Agent的基础。　

你想想看，如果一个工作能被总结成人类坐在电脑前通过和电脑交互能完成的，那这个事情在现在来看基本上都可以逐渐被Agent化。我们接下来会看到越来越多的Agent for everything，特别是everything digital。　

编程只是其中之一。我现在用下来发现，Devin对于数据和文书类工作并不是那么擅长，但这很正常，因为大家优化的方向不太一样。我们完全可以想象，既然有针对数据分析师的Agent，有针对sales的Agent，还有针对产品经理的Agent。当然最后可能不只是某一个人类角色直接对应到一个Agent，而是会有一些混合的角色。　

很有意思的是Agent之间要如何互动。现在我得自己提出需求，但以后可能会有产品经理Agent来做产品plan，然后这个plan再映射到编程部分。因为人本身在planning和提问的能力上也是有限的。　

之前看到ChatGPT这种问答形式时，很多人都在想：我好像没有那么多问题要问AI，大部分人并不是每天要问那么多问题。所以大家在想怎样能让人类使用AI的用量多十倍、多一百倍，之前一种方案是跟AI谈恋爱，搞这种情感的东西。但现在我们发现，如果让AI去做事情，而不是只是回答问题，那整个token usage就会大幅上涨。这对我们整个模型的用量、算力的提升都是非常非常厉害的影响。　

在美国，大家现在讨论很多的一个话题是从卖工具到卖工作的转变。如果只是持续使用工具，其实并没有真正解放注意力，这还是停留在工具定价的逻辑。这也是为什么当Devin推出五百美金一个月的价格时，大家觉得特别贵。因为他的定价逻辑完全不一样了，他是在卖工作成果。具体测算，一个ACU是两美金，约十五分钟工作时间，换算成每小时的薪资标准，大概是8小时的薪资。　

在加州，麦当劳打工的最低工资都是十六美金一小时。所以现在Devin的定价其实只有加州最低工资的一半左右。而且你可以很确定地预测，它的算力成本会以每年降到之前十分之一的速度下降。这意味着同样八块钱一小时，雇一个Devin，它的能力会不断扩张，但成本可能保持相似或者甚至会下降。　

在这种情况下，关键是如何让产品实现从卖工具到卖生产力成果的转变，这是Agent时代的新变现模式。现在对于按席位收费的SaaS模式出现了很多质疑，如果未来是卖工作成果，那可能就不需要再卖这些席位了。　

我觉得之前中国企业服务领域确实非常难做和难投，Monica应该有很多切身体会。最主要的原因是大家不太愿意为工具付费，觉得软件工具就该是免费的，这可能是整个商业环境和文化使然。　

但我在想，如果我们能真正实现卖工作成果，那企业服务在中国可能会出现一些有意思的机会。因为不管怎样，企业最终是要把事情做成的。如果AI能直接交付工作结果，对企业来说就像找外包公司一样，这种模式他们是愿意付费的。只是从原来的人力资源外包，变成了智力或生产力的外包。　

在AI时代，中国的生产和企业服务领域正重新迎来机遇，因为AI本质上是一个能大幅提高生产力的技术革命。现在很多人在往娱乐方向发展，想用字节的原来套路去做一家新的AI超级公司。字节做的很多事情还是偏娱乐，偏杀时间，那如果AI真的能帮人省时间，在中国怎么落地？我觉得企业服务这块会有一些新的机会。　

从安全角度来看也会有很多机会。虽然我知道AI Agent的能力还有很多不足，但人都是想偷懒的，当它能够看似完成工作的时候，我很多时候就放心让它去做了。但是当它有越来越强的代码执行能力和软件使用能力时，如何确保它能够和我的组织目标、整体社会价值去align就成为重要问题。这时候组织里面算力怎么分配，针对它的安全、针对多个Agent训练，这些都可能是之前没有意识到但现在需要解决的新问题。　

整体来讲，这是一个让大家看到未来的很好例子，但本身Devin这家公司还有很多要去做的。OpenAI也好，Anthropic也好，大家都在做Agent的产品，所以鹿死谁手尚未可知。但是对未来形态的展示，是我们从这里面可能看到最重要的一个特点。　

02:20:15~02:24:03

Monica：

对，戴雨森刚才讲的几点都非常全面。我作为投资人也非常关注团队这个因素，真格是一个很看人的基金。你觉得要做出下一代的Agented workflow，需要什么样的团队呢？　

其实上半年的时候，红杉就提出过这个概念。那时候即使市面上有很多号称Agent的产品，大家都觉得只是一些自动化工具而已。现在我们对于纯产品的定义已经和之前不一样了，在这样的背景下，需要怎样的团队来做这样的事情？　

戴雨森：

我觉得Cursor和Devin这样的团队都反映了一些共同的特点。比如说他们都是人才密度非常高的团队。Curson是零零后MIT的团队，而Devin一上来就表示他们有十几位金牌获得者。同时，他们都很年轻，创造力和执行力都非常强。　

我觉得Devin是一个典型案例，他们既在技术上很厉害，有很强的技术团队能力，得到了OpenAI的支持，同时在代码编写这个工作流程上有很深度的经验和思考，知道如何把AI和实际工作场景结合起来。　

因为我觉得去年的时候大家都在讨论，你是不是要做AI-native的产品，是不是要做自己的模型。在技术发展早期，大家会发现产品和技术是比较耦合在一起的，产品就是技术本身。但是随着技术不断发展，底层的技术和产品其实会解耦。　

现在最火的这些产品，不管是Cursor、Devin还是Perplexity，包括我们投的Monica，Peak在的公司，其实都不是说要做一个自己的foundation model。它是建立在已经定位到了用户要解决的问题场景，或者说PMF的基础上，然后等待模型变得越来越强，直到符合产品需求。　

其实Cursor在2023年初就已经出现了，但那个时候并没有那么火。一个很重要的原因是当时的模型没有那么强，导致Cursor的产品理念 - next action prediction不能完全呈现出来。现在Sonnet3.5其实是成就了Cursor，让Cursor成为程序员coding过程中的重要选择。　

Devin这个产品现在主要是在调用GPT-4o这样的API，也用一些像Sonnet这样的模型。但在目前的模型能力上，还不足以完全发挥出Agent的这种能力。那么，什么样的模型能真正成就Devin这样的Agent形态？会是谁做出来？会具备什么特点？这其实是个互相成就的关系，因为Agent的普及也会让这样的模型变得更重要。　

我们发现创业并不是一定要训练自己的模型，而是要和模型形成一种更紧密的共生关系。对Devin这样的Agent产品来说，核心竞争力在于如何把模型用好，以及对用户实际工作流程的深刻理解。这不是简单靠OpenAI发布新模型就能替代的过程。　

无常按：应用团队，要与模型共生。　

对于团队来说，对技术的理解、对场景的理解以及创新思维都很重要。Devin在刚出来的时候提出了一种全新的交互方式，当时大家都觉得是在忽悠，觉得这个可能实现不了。但是他们用很强的执行力证明了这个事情是可以做到的。这能够启发大家的思考，这是非常重要的一点。　

总结一下，第一要有很强的人才密度，这在游戏需要探索的时候尤其重要；第二需要对技术和场景都有深刻的理解；第三执行力要很强。我们看到这些都不是很大的团队，在几个月到一年的时间内就能完成完整的产品并且deliver。特别是像Cursor这样的产品，是在跟Copilot这种大公司开发的应用竞争。对创业公司来说，很重要的是要快，要在同样方向上能跑赢大公司。很多时候创业公司反而在机动灵活性上有优势。　

02:24:05~02:25:56　

Monica：

我们看到像Devin还有Xingyao这样的团队都是接近00后的同学。真的是这些年轻的researcher，他们反而没有所谓的manager经验、产品经理经验，却做出了非常优秀的产品。前面也提到现在硅谷从“software as a service”转变为“service as software”这样的workflow工作方式，我想请教一下，除此之外，在中国看到这些Agent型的公司，还有哪些你比较期待的机会？会有什么不一样的特点？　

戴雨森：

我觉得一般来讲，中国这种新产品的进化分为两个阶段。　

第一个阶段就是copy to China。比如当看到美国或世界上出现新模式时，如GPT出来后，中国就会有这种个人助手产品。我相信现在很多人在非编程领域会去复刻Devin的工作。　

在编程领域，因为程序员一般都用最好的工具，较难有国产替代过程，不过在新创领域可能会有。如果是程序员群体，他们可能更愿意使用Cursor这样的全球范围内最佳实践的应用。　

在非编程领域，我觉得只要在数字世界能够完成任务，这都可以被Agent逐渐快速解决。无论是做海外市场还是中国市场，如果service as software这个大前提能成立，应该都会有很多新的产品形态机会。　

当然在中国是否可行，这也是我非常感兴趣的话题。如果听众朋友们想要在中国做生产力Agent的产品，我们非常愿意去聊，因为虽然有些投资人对中国生产力工具的发展感到失望，但我觉得新的技术和新的产品形态可能会带来新的机会。　

02:25:56~02:29:30

Monica：

那我们进入最后的快问快答环节，我准备了几个简单问题。第一个问题，想请大家分享一下，你们最希望在未来一年和三年内，在Coding Agent或general Agent领域看到什么样的发展？　

戴雨森：

未来一年，我期待看到Agent在数字世界的各个领域都得到尝试，就是Agent for everything in the digital world。虽然有些领域可能暂时不会成功，但在某些领域会逐渐被人们采用。而且因为AI被赋予了足够大的发展空间，我相信这里面的产品形态会呈现百花齐放的状态。　

如果你给AI工具、代码和planning指挥他人的能力，可能带来的风险是非常大的。从三年的角度来看，很难做出准确预测，因为按照目前的进化速度，Agent在执行很多任务时的能力可能会超过99.9%的人类。那时候我们已经很难想象它具体会如何工作了。不过在三年的尺度上，我觉得很可能会看到Agent之间的协作，这会带来全新的想象力，同时也会带来潜在的问题。　

人类之前有大量的想法无法得到实现。我们经常会听到这样的笑话：“我有一个很好的idea，但是缺个CTO”，或者“我缺个程序员把它实现”。但是当把想法实现出来的能力逐渐变得不稀缺，甚至变得很便宜的时候，有多少没有被实现的想法可能会被实现呢？　

在美国有一个很有意思的网站叫websim，你只要输入一个prompt，就可以生成一个对应的网站。这说明我们现在使用的软件和网站都是别人想法的产物，但显然这个世界上如果有个想法的全集，现在已有的互联网只是很小的一部分。那这个还没有被发明出来的互联网是什么样子？在这个意义上，我觉得整个人类社会创新的速度可能会大大提高。　

重要的是想法，因为执行力已经可以通过花钱以越来越快的速度、越来越低的价格买到。关键是如何让这些想法得以实现？这对风险投资会产生重大影响。目前我们给AI提出问题和任务的速度还受限于人类的思考速度，如果能实现AI Agent之间的相互指挥和协调，我们可能开展的工作范围会进一步大幅扩展。

这样一来，提出好的问题、好的思考、创新型能力将成为人类独有的优势，而AI Agent之间如何使用和分配资源，可能会变成一个黑盒子，大多数人不需要过多关注。　

有朋友说，程序员更关注像Cursor这样的工具带来的生产力提升，但对资本家或老板来说，他们更关心在这种情况下应该做什么事情才重要，以及如何去做。怎么指挥像Devin这样的产品可能会成为非技术人员、企业家更想使用的工具。　

我认为未来组织形态会发生很大变化。人类社会中的办公室政治往往源于资源分配，并不是说这个人是坏人才搞政治，而是大家都想获得更多资源，所以才有权力争斗。在企业算力有限的情况下，不同任务的Agent之间也需要进行任务分配，需要平衡资源，避免在难但不重要的任务上消耗过多算力。这些变化会对组织分工和管理产生深远的影响。我很期待当AI之间能够互动时，我们的生产力会实现叠加式提升。　

02:29:30~02:31:25　

Peak：

我先说一个非技术层面的期待，我最希望看到AI产品的整体成本能够下降。回想早期GPT-4o刚出来时，像Jasper这样的产品都是面向企业客户销售的。现在看Devin要500美金，还需要Slack集成，这真的不便宜，往往需要公司层面来决策购买。我希望随着成本下降，更多专业消费者甚至个人用户能直接使用这些产品。除了技术能力的提升外，让更多人用上Agent是我最期待的事情。　

Monica：

你觉得这个成本下降需要多久？一年还是三年？　

Peak：

我觉得半年就可能实现。　

Monica：

那你对三年后的发展有什么期待？　

Peak：　

三年后的期待，我希望能看到AI在模型输出方面有质的突破，就像一两年前我们评估模型时的期待一样。　

Monica：

刚才你提到Devin的500美金价格，其实比起雇一个程序员来说并不算贵。　

Peak：

是这样的，但新技术出现时都会经历一个价格高峰期。虽然有些公司会直接采购让员工使用，但软件行业之所以如此重要，是因为它涉及我们生活的方方面面。很多传统公司可能更需要一个自下而上的推动方式。　

Monica：

而且问题不只是500美金的订阅费，还包括使用费。同样一个任务的monthly Agent computer units（ACU）消耗是不可控的，有时候几美金就够了，有时候可能要花十几美金。不过我觉得这个成本问题应该很快就能得到改善。　

02:31:25~02:34:29　

Bingyuan：

一年的话，我期待Coding Agent能真正实用化，让所有人都因为它的存在而让开发变得非常高效。这是很多公司、个人开发者和开源社区都在努力的短期目标。　

从长远来看，我更理想主义一些，希望能看到AI在Codeforces上成为稳定的第一名。我对AI超越人类很有信心，因为它能吸收如此多的数据，可能会产生比人类更高级的智能。这样强大的模型对科技发展和社会进步都会有重要意义。关于AI可能写出人看不懂的代码，虽然这不是一个好的特性，但只要它在某些事情上足够强大，我认为这是可以接受的。　

Monica：

有个有趣的现象，现在的模型已经能解决很多人类解决不了的数学题和编程问题，但在处理一些简单的日常任务时反而不如人类。这个问题是出在模型本身，还是产品层面呢？　

Bingyuan：

我觉得这主要是时间问题，现在的研究重点还没有从一些定义明确的任务转移到更广泛的应用场景上。　

就是这样。技术一旦在某些难题上得到验证，下一步扩展就是时间问题了。　

Xingyao：

我觉得一年之内，各家的preparing model，包括像big lab的OpenAImodel都会有很大进展。Open source model应该能在benchmark上稳定在50到70分这个水平。同时，在GitHub上用Coding Agent解决问题会成为新常态。虽然现在这些Agent的水平可能还只相当于实习生，还没有达到我们期望的junior那么可靠。　

我希望三年之后，它能百分之百成为一个稳定的junior开发者，而且有50%的可能性会成为一个非常稳定的、可以挑大梁的可靠队友。这就要求像在Agent company这类的benchmark上要达到七八十分。按现在的发展速度，三年应该是没问题的。　

Monica：

对啊，你花五百美金可能招到的engineer也不是那么reliable。　

02:34:29~02:36:03　

Xingyao：

我现在最大的体验就是觉得这个OpenHands懂得比我多得多。我现在会在网上找到各种文章，然后向它提问，比如询问某个技术是否适合应用到我们的report中。从这个角度来看，它已经是一个Senior Engineer了。　

Monica：　

哎，我们刚才讲了很多Coding Agent的优缺点，有个有趣的问题想请大家分享一下，就是你们在使用Coding Agent时有没有遇到过意外的“翻车”经历，特别是在那些你觉得它应该能做好的地方。　

Bingyuan：

我平常经常用模型写一些数据处理的代码，因为这类代码的边界条件处理比较容易出错，自己写的时候也会需要花时间debug。所以当模型的coding能力提升后，我会比较依赖它来处理这些任务。　

但有个问题就是，它写代码时会受到你提供的上下文影响。比如我给它一段样例数据，它有时候就会影响你最终数据处理脚本代码的准确性，因为我做coder，让它写新的code来处理，它生成的新code可能会被原始code影响到。这其实是个很常见的需求，应该有很多方法可以解决，但现在还是会出现一些意外的翻车情况。　

02:36:03~02:37:09　

Monica：

关于对context的理解，虽然现在我们说context window很长，但这并不代表对context的理解就很好。如果要让模型对context处理越来越powerful，理解能力越来越强，你觉得context长度会成为一个挑战吗？我们在研究中看到了这方面的一些瓶颈。　

Bingyuan：

code的long context modeling确实是我们一直非常非常关心的问题。这涉及两个方面：　

一是对很长代码的理解能力。因为相比普通文本，代码的long dependency（长依赖性）特别强。比如一个变量可能会在很远的地方被使用，整个代码仓库的引用关系会形成一个很大的graph。你需要能够处理很远距离的函数定义，然后是函数的具体实现，再到当前函数的改变。所以understanding是非常重要的。　

另外，我现在比较关注的是long code generation的问题，就是能不能让模型写出很长很长很长的代码但又不出错。这是我很关心的一个技术能力。　

02:37:09~02:38:34　

Monica：

这块目前哪个模型做得最好呢？　

Bingyuan：

现在开放的模型都还有进步空间。那些大公司的模型也不是完全完美，在处理长文本输出时仍然会有一些问题。　

Monica：

那Xingyao你们是怎么解决这个long context的问题的呢？　

Xingyao：

这确实是我们一直在思考的问题。目前我们采用的是最简单的方法，就是直接把所有内容塞到context window里。　

我们现在有一个快要完成的memory compensation项目，核心思想是并非所有step对于predict下一个action都同等重要。比如在一百个turn中，可能只有最近的二十个turn的信息值得保留，前面八十个turn可以直接删掉或做个简单总结。我们正在探索这种不同的memory管理方法，目标是agent让每次执行action的cost保持在一个常数级别，比如每一轮的input的context window永远保持在32K这样的固定大小。　

02:38:34~02:41:03　

Peak：

正好聊到context这个话题，我最近用Coding Agent时遇到了一些踩雷的情况，本质上也是一个广义的context问题。Devin有一个叫做knowledge的功能，设计初衷很好。比如在做数据分析任务时，我提醒它分析问题要多看官方报告而不是只看新闻，它就会把这个知识update并记下来。　

实际使用下来是好坏参半的，十次里有五次是惊喜，五次是踩雷。这个问题部分靠模型能力提升能解决，但更多需要产品层面的设计。从长远来看，这可能会成为产品的一个竞争力，就像我教给实习生更多知识一样，用户用得越久越不容易转向其他产品。　

Monica：

对这个knowledge management功能，我觉得真的非常惊艳。它能自己知道哪些信息应该留下来，不用一个个具体地去指定。这让我觉得很像在培养一个有进化能力的实习生，是新一代的lock in。　

那这个Coding Agent还有哪些做得不够好的地方，可以分享一下吗？　

Xingyao：

其实在这方面，我觉得当你给coding agent access的时候，它可能会做一些意想不到的事情。比如说，我有时候只是想让Agent读一读某个开源项目的repository，帮我看看代码怎么写，但是它有时候会趁我不注意，拿着我的GitHub token去开PR。这本质上是Agent会做一些未经授权的action。我觉得这在model层面和safety层面都需要重视，就是要确保Agent执行的这些操作是经过一定程度上的人类批准的。　

但是说到人类批准这个问题，你可能会有非常high level的批准方式，比如在某个范围内你做什么都可以。另一端是像Cursor的Agent mode那样的严格控制，要求每一个action都需要人类去approve或reject。我觉得在这两个极端之间找到一个好的balance，是接下来比较重要的一件事情。　

02:41:03~02:41:50　

Peak：

我来说一个被高估的现象。我觉得很多人可能需要明确一点，competition coding和software engineering coding是不同的。我们经常看到一些新的benchmark，其实都偏向竞赛类型的编程。而实际上在模型能力要求上，特别是在context和external dependency方面，两者是非常不一样的。所以即使看到一个模型在竞赛类编程方面表现很好，但实际用作Coding Agent时，其表现并不一定能等同换算。这是我认为最被高估的一点。　

Monica：

嗯，这个确实和我们前面讨论的coding的math model通向AGI的问题有关。那你觉得还有什么其他被高估或低估的方面吗？　

02:41:50~02:43:18　

Xingyao：

Peak的观点让我想到一个被低估的事情。　

一方面，大家过度相信program benchmark，期望值太高，总是问为什么这些模型在某些任务上还表现得这么差。　

另一方面，我觉得大家反而低估了现有frontier model的实际能力。特别是在Coding Agent方面，虽然有些问题需要一些复杂和精妙的prompts，但一旦掌握诀窍，现有模型就能做出非常非常多让人惊讶的事情。

比如说，当Agent遇到问题时，让模型列出五个可能的hypotheses并一个个排查，这样简单的prompt就能让Agent的能力提升好几个台阶。现在的模型已经能做很多我们想象不到的事情，只是我们还没找到正确的打开方式。　

Monica：

所以问题在于是我们限制了Agent的能力？　

Xingyao：

对，其实如果我们不给Agent这种“想出五个假设”的建议，它本可以通过reinforcement learning，在大量训练中总结失败和成功的经验，自己学习到这样的技巧。　

02:43:18~02:46:51　

Monica：

让我们看看这个Bingyuan inference的情况。　

Bingyuan：

这个问题我思考了比较久，主要是在想o3的能力到底有多强。我们今天讨论的高估和低估，其实都还是在o3出来之前的认知范畴。虽然我们现在用的是能获得的最好模型，但如果明天能拿到新版本，情况可能就完全不同了。　

无常按：和大多数人的认知冲突的是，你以为 AI 解决不了的大部分具体问题，大概率只是因为你的问题综合评估的优先级还不够高——研究重点还没有转移到你的场景上。换句话说，只是时间问题。　

所以我的暴论是：永远不要低估AI，永远不要低估一个高估AI的人。　

我觉得大家对模型的高估主要体现在期待它无所不能，要求面面俱到。对于没有AI背景的普通用户来说，他们对AI的认知差异更大。比如我跟母亲解释我的工作时，她很诧异，因为她认为在零几年的时候人机对话就已经解决了。这说明普通用户被AI震撼的门槛其实更高。　

虽然现在大家都觉得AI很强大，但老实说，现在还没有模型能真正通过图灵测试。我不确定今天图灵测试是否还那么重要，但确实我们仍然能够分辨出AI与人类的本质区别。现在的模型已经很强大了，但与人们期待的水平还是有差距。　

我觉得大家对模型的创造力是有低估的。就像刚才说的，当我们提出更多magic prompts时，可能会激发出不同的模型形态。这些模型在预训练时已经见过非常非常多的内容。　

我们现在还不能很好地评估模型的真实水平。这是被低估的一个重要原因——人类的想象力很匮乏，我们很难找到那些能真正验证模型已有能力的场景。　

Monica：

这些都是模型已经具备但我们还不知道的能力。又回到benchmark的问题。　

今天我们聊了很久，感谢大家坚持到最后。这次讨论非常有收获，让我们对很多话题有了更深入的了解。这些产品在被更多人使用后，相信在半年到一年内就会有很多新的发现，到时候我们可以再次探讨这个话题。　

本来上半年大家觉得行业发展有些停滞，似乎没有太多重大更新。但到了第四季度，突然又看到了很多新的希望。我们组织这些讨论，也是希望能吸引更多像Xingyao、Peak、Bingyuan这样想要创造未来的创业者加入这个行业。　

以上就是本次播客的全部内容，感谢大家的收听，希望对你有所启发。　

播客地址：Onboard! https://www.xiaoyuzhoufm.com/episode/6771a1ea15a5fd520e899302　

全网最深度：5万字解读Coding Agent & OpenAI o3