最近各種 Deepseek R1 解讀的文章鋪天蓋地，不過，要真正理解 R1 這樣的推理模型的核心原理，以及有可能帶來的最有影響力也最有確定性的場景之一，Coding Agent, 那還是要回到這一切的起點：R1 所對標的 OpenAI o 系列模型。

過去一年，M小姐的播客 OnBoard! 在Coding Agent 第一次出現和 OpenAI o3 釋出兩個重要節點，分別做了3小時的中美深度連線探討，嘉賓涵蓋了來自 OpenAI, Deepmind 的研究員、Replit, All Hands AI, Augment 等頭部 Coding agent 公司核心成員，投資人等，很多網友稱之為“全網最深度解讀”，一直收到各種求文字實錄的呼聲——我們這就來了！

上個月我們釋出了《【三萬字實錄】對話OpenAI,Replit,Augment核心成員：深度解讀Agent底層能力與互動設計》：

今天，在網友張無常和 Serine Lyu 的協助下，這份4萬字的 《3小時中美連線，深度解讀 Coding Agent 與 OpenAI o3》文字實錄，終於出爐了！

（文末“原文連結”直達Apple Podcasts 播客）

校對工作工程巨大，再次感謝網友用愛發電的努力。希望在這個資訊紛雜的時代，這一份來自一線的深度務實探討，能讓你離本質與未來都更近一些。

再次，歡迎大家關注 OnBoard! 在小宇宙、Apple Podcasts, 喜馬拉雅、Spotify 等播客平臺都可以找到我們。

無常按：
（M小姐的話：無常同學的引言寫得非常好，特別保留下來，歡迎大家關注他的公眾號）

這是一篇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 能力、實現難點和未來挑戰的思考。

沒有套話，全是真知灼見。讀的過程中忍不住加了很多評論。花了我不少時間整理，也會花費你不少時間閱讀，但絕對值得。

嘉賓介紹

Yusen Dai，真格基金管理合夥人，聚美優品聯合創始人。
李珎， ReplitAgent核心成員，Replit 資深工程師，ex-位元組，Google.
Xingyao Wang， Allhands AI (開源專案 OpenHands) co-founder & Chief AI Officer， UIUC PhD.
Binyuan Hui，阿里巴巴通義實驗室科學家
CohostPeak，真格基金EIR，前猛獁瀏覽器創始人
OnBoard! 主持Monica：美元VC投資人，前 AWS 矽谷團隊+ AI 創業公司打工人，公眾號M小姐研習錄 (ID: MissMStudy) 主理人 | 即刻：莫妮卡同學

核心觀點

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 的賣工具，而是賣生產力
創業並不是一定要訓練自己的模型，而是要和模型形成一種更緊密的共生關係。核心競爭力在於如何把模型用好，以及對使用者實際工作流程的深刻理解。
要保持樂觀和敬畏：雖然我們現在用的是能獲得的最好模型，但如果明天能拿到新版本，情況可能就完全不同了。

正文

注：本期錄製時間為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領域一線的創業者、大模型研究員以及投資人的重磅陣容，一起跟大家探討個痛快。

讓我介紹今天的重磅嘉賓：首先是 ReplitAgent的核心成員李珎，他們在今年九月首次推出的 ReplitAgent引領了windsurf，bolt等一系列Coding Agent產品的領頭羊，也是第一次展示除了這種產品形態。我們還邀請到了開源版 Devin 演化而來的商業公司 Allhands AI 的 CTOXingyao。在底層模型方面，我們請來了最具國際聲譽的中國開源大模型——阿里巴巴通義千問的 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

讓我們請下一位返場嘉賓李珎來分享。

李珎:

我是李珎，在ReplitAgent擔任AIAgentengineer。我是最早的ReplitAgent創作者之一，最開始這個專案只有我一個人在做，後來逐漸發展成為公司的核心專案。在九月份之後也是高速成長的過程中，我們可能是市面上第一個能公開使用的Agent。

最近我在用Agent幫助國內一個電影導演團隊，將他們的需求透過ReplitAgent轉化為產品落地。比如電影劇本的拆解、翻譯等工作，我會從他們那裡總結需求，然後用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:10:14

好，那接下來有請Bingyuan來聊一聊。

Bingyuan:

大家好，我是Bingyuan。

00:10:14 – 00:11:18

我目前在通義主要負責coding這個方向。我們最近開源的coder專案受到了大家的關注和喜愛，收到了很多社群非常好的反饋。

我可以跟大家分享一個比較好玩的場景，我最近在嘗試讓AI以Agent的形式去清洗程式碼資料。傳統方式下，我需要觀察大量程式碼，編寫處理指令碼，然後不斷迭代來獲得好的資料。但現在AI已經可以在面對陌生資料時自主進行清洗。我希望未來如果模型足夠強大，它的能力可以從資料清洗擴充套件到自主判別資料價值，甚至可以編寫訓練程式碼來訓練更強大的模型，並進行自我評估。

如果AI架構能夠突破，不僅軟體開發流程會發生變化，模型迭代的流程也會隨之改變。這是我最近觀察到的一個很有意思的趨勢。特別是看到昨天o3的釋出，我感覺這些變化可能會比我們預想的更早到來。未來模型的進步，可能真的要靠模型自己去迭代。

00:11:18 – 00:12:36

Monica:

能給大家簡單介紹一下嗎？因為之前提到千問是做基礎模型的，你們也有自己的foundationmodel和coding model。剛才提到的這個coder具體是一個什麼樣的產品？

Bingyuan:

我們希望先在coding這個方向單獨進行驗證，包括資料和技術的探索。我們在通用模型基礎上，進行了大量的prompt engineering、instructiontuning，甚至是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能力。我很關注這兩類模型未來是獨立發展還是會在某個節點融合。

對於Agentframeworks，我想和Xingyao討論一個重要問題：如何更好地發揮模型能力。因為相同模型在不同框架下表現差異很大，而框架與模型能力的關係也並非簡單的線性關係。

另外，我注意到很多朋友，包括雨森，透過現在的Agent產品完成了人生第一個專案（網站或者產品），但由於沒有工程能力，往往在deployment階段遇到困難。軟體的生命週期很長，包括maintain、更改以及內容管理等，這些都是需要Agent類產品思考的問題。

00:15:02 – 00:15:38

Monica:

感謝 Peak 的分享。接下來，我們會為還沒有聽過或不太熟悉這些產品的聽眾介紹幾個我們經常提到的產品。同時，我們也會邀請幾位一線的 builder 深入分享他們整體的構造思路、思考和演進過程。

雨森，作為一直很深入地跟進Coding Agent以及更廣泛 AI 領域的投資人，能否請你從這個視角來分享一下你所觀察到的Coding Agent產品演進，以及為什麼你這麼重視這個領域的創業機會和未來可能性？請你簡單梳理一下過去的發展，並分享你的思考。

00:15:39 – 00:16:33

戴雨森:

程式設計一直是AI領域中非常重要的一件事情，因為透過寫程式碼，AI可以控制很多外部工具。從ChatGPT出現到現在這兩年時間裡，AI程式設計已經經歷了四個主要的進化。

一開始ChatGPT出現時，我們給AI一個指示，它就能把程式碼寫好直接貼在聊天框裡，這確實是人工智慧的一個飛躍，因為它程式碼寫得確實很好。但第一代AI並不知道我們為什麼要寫這個程式碼，完全是根據我們給的prompt來寫，所以我們往往需要在prompt裡把很多上下文都寫進去。而且我們需要手動把程式碼貼上回IDE裡面再去執行。當代碼出現錯誤問題時，再拋給AI，這樣AI就像個瞎子，完全不知道發生了什麼，像一個奴隸一樣在寫程式碼。這就是ChatGPT和Claude剛出來時的情況，包括GitHub Copilot也是如此。

00:16:33 – 00:17:49

GitHub Copilot的出現是AI寫程式碼能力的第一次飛躍，它讓AI能夠讀取整個code base作為上下文，從而理解我們為什麼要寫這段程式碼。不過在第一代產品中，使用者還需要手動把程式碼貼上回IDE進行除錯，這種模式可以說是"我問你答"式的人機合作。

Cursor提出了一個重要概念：next action prediction。具體來說，就是當你寫下當前這行程式碼時，AI能推測你接下來要寫什麼程式碼。這體現了模型對程式碼的深度理解，以及對程式設計師任務更強的規劃和拆解能力。隨著GPT-3.5等模型的進步，系統能生成更長的程式碼塊，更準確地預測使用者意圖。

後來，Cursor還加入了檔案操作能力，可以直接在本地建立和修改檔案，比如處理需要下載的檔案、需要建立的檔案等。同時還引入了命令列操作建議。這標誌著我們進入了AI程式設計3.0階段：AI能自動寫程式碼、建立檔案並執行除錯，如果程式碼有問題還能自己debug。這讓我們從"我問你答"進化到"我問你寫"，大大加快了程式設計自動化的程序。

00:17:49 – 00:19:03

我在一兩個月前第一次使用Windsurf時感到非常激動，因為它能在一臺全新的、未安裝任何程式設計環境的系統上，僅透過一兩步簡單指令就實現demo的自動化執行。不過這個過程仍然需要我持續關注。而Devin的出現開創了新的正規化，它真的很像一個真人。我把任務交給它後就可以去做其他事情，它能透過planner進行完整的任務規劃，持續自主程式設計和除錯，還能建立檔案，透過虛擬機器訪問網際網路獲取所需資訊。

最重要的是，我可以隨時打斷和調整它的工作程序。這與之前的ChatGPT和GitHub

Copilot有很大不同，因為使用這些工具時，一旦給出prompt就必須等待整個流程完成，中途很難新增額外指示。從管理者的角度看，這就像給員工分配任務後可以不斷調整要求。另外，Devin還與Slack做了深度整合，除了程式碼庫外，還可以從Slack中獲取任務背景的上下文資訊，這對於準確完成工作非常重要。

00:19:03 – 00:20:25

所以我在看到Devin之後，我發現它不只是可以程式設計。它已經能完成很多透過一個人坐在電腦前面、透過網際網路能夠解決的事情。在這種非同步的Agent產品出現之後，我覺得產生了一個很重要的概念：當我們能夠簡單地花錢或者說花算力就能買到工作成果時，這就誕生了某種工作的scaling law。

我覺得人類使用的工具可以分為兩類。第一類像電鑽或ChatGPT這樣的，你得持續投入注意力，有點像是你踢一腳開動一下，必須持續對話，一旦把注意力挪開就不能繼續工作了。另一類就是所謂的自動化，比如我佈置個爬蟲，寫好後它自己去爬，但它只能完成重複性工作，沒有自己去調整決策、反思的能力。

而我們說的AutonomousAgent，也就是全自動代理，既不需要我投入太多注意力，又可以完成非重複性的、需要創造性思考的工作。我覺得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應該是ReplitAgent。

雖然今天很多人都想直接聽Devin相關的內容，但我覺得前面我們討論的Cursor和Replit Agent這兩部分以及這兩種產品形態仍然非常重要。李珎，能否更深入地跟大家分享一下ReplitAgent具體是做什麼的？另外也想了解你們一開始是怎麼開始做這個產品的，以及從產品釋出到現在這半年時間裡有哪些重要的迭代？

00:22:48 – 00:24:27

李珎:

我覺得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來開發軟體。我們現在已經實現了這個目標。

00:24:27 – 00:25:22

Replit跟Devin不太一樣的一點是我們更注重幫助使用者從零到一去build一個東西。具體來說，即使使用者完全不會寫程式碼，只要有了IDE，就可以告訴Agent"我要build一個這樣的網頁或軟體"。Agent會先幫你make一個plan，然後你可以與Agent進行交流並prove這個plan。之後Agent會開始寫程式碼、裝環境、把專案搭建起來執行，一步一步地虛擬地把你想要的東西搭建起來。這就是一個完整的從零到一的過程。

我們的產品在九月份釋出，到現在已經有三四個月了。在這期間我們看到了大量不同的use case，獲得了很多insights。其中最大的產品形態insights是，根據使用者需求的不同，使用者的expectation是非常不一樣的。在最開始時，我們比較接近一個Asynchronous（非同步）的Agent，就是使用者給出需求後，我們會不停地迭代action，最後deliver一個結果。

00:25:22 – 00:26:54

在產品釋出後，我們收到了很多使用者反饋。使用者更期待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到七十或者八十了。之前在推特上做了一次直播，很多使用者來分享他們的故事，其中印象比較深的是有一個德里的印度小哥，他說在ReplitAgent釋出後已經透過它掙了十萬美金了。我們看到非常多的使用者已經把他們的產品上線了，在網站上make revenue。這個更像一個創業的過程。

我特別喜歡的一個pattern就是，有一些創業者用Agent非常快速地去build up他們自己的idea，然後放出去驗證product marketfit。用來驗證PMF的第一個版本開發速度變得非常快，他們可以在不同產品之間share很多set up，比如說翻譯的這些set up，比如說tracking分析的set up。這樣就可以非常快地去驗證idea，直到找到適合的idea和marketniche。

如果你是一個優秀的創業者，你的產能會被無限地增大，會被增大到十倍甚至一百倍。我看到身邊很多創業者已經在做這個事情，還有一些人在幫他們驗證data的idea。因為這個門檻沒有那麼高，但效率又非常高。

00:29:36 – 00:30:23

Monica:

讓我們回來follow up一下。從Replit釋出到現在，除了你剛才提到加了一個system之外，還有哪些更新對提高使用者滿意度和效能有比較大的幫助？

李珎:

其實底層模型沒有太大變化，仍然是GPT-3.5模型。主要更新集中在幾個從零到一的AI特別關注的方面。第一個重要的更新是integration。對於從零到一的使用者來說，他們更需要把產品接入到各種不同的服務中，這樣產品才能真正產生價值。比如說需要接入OpenAI、Firebase、Supabase資料庫，以及Stripe支付系統，只有集成了Stripe才能開始盈利。實際上很多LLM在integration方面做得並不是特別好。

無常按：2024 年底了，竟然還在用 GPT-3.5——可見實際需求和 Benchmark 之間有很大的 gap，也說明模型以外的東西有多重要。

00:30:23 – 00:33:06

首先要說明的是，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為主，現在完全是Agentfirst的設計了。技術棧從最初的Flask、Next.js擴充套件到支援React，又支援了更多使用者想要的slack，這些framework本身就把"什麼是好看"這件事包含在裡面了。我們還加入了讓AI自己搜尋圖片的功能，以及一些工具讓使用者可以直接調整網站的顏色和字型大小，把一些原本需要AI來做的工作轉成了UI工具。這些改進讓產品在美學和功能上都提升了很多，過去三個月的進步真的讓我很驚訝。

00:33:06 – 00:35:57

Peak:

我們剛才聊了很多從零到一的內容，作為使用者我能感覺到這一年進展非常快，從零到一的達成率和速度都在提升。但從一到十的體驗還沒有那麼ready，這方面你們接下來有什麼準備？還是會更多專注於從零到一的探索階段？

李珎:

我們希望能幫助使用者從零到一百，不只是做產品，還要幫他們賺錢。

從零到一是現在的第一步，也是AI比較擅長的領域。我們看到很多使用者每天透過smashAgent或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二話不說就開始往裡面寫程式碼，整個專案呈現出非常bottomup的狀態。隨後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是Agentruntime。它主要負責把event stream裡的所有action轉化為具體的command去執行，比如在sandbox環境中執行bash command，讓Agent能獲取執行結果。

這三塊之間其實是純粹的Agent和event stream的互動邏輯。使用者互動是透過直接往event stream里加入資訊來實現的。比如使用者想讓Agent做某件事，就直接把訊息push到eventstream裡，Agent就能觀察到。

這樣設計的好處是，雖然現在我們只有web UI，但未來可能會有多個Agent同時work on同一件事情，就像在辦公室裡多人協作一樣。我們特意做了這樣的future-approved architecture設計，考慮到未來可能有多使用者連線到同一個Agentsession，或者多個Agent連線到同一個使用者。

具體實現上，我們現在主要基於react code act這種方法，本質上是依賴LLM自己的能力，通過歷史的action的observation去生成新的action，決定下一步該做什麼。這種設計的好處是能最大程度享受到model更新帶來的improvement。相比之下，如果用promptingheavyAPI的方法，可能享受不到直接用LLM生成action帶來的這些提升。這是我們早期的一些Agentdesign 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種不同的agentframework去做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 planningstructure，就需要考慮很多工程決策：比如什麼時候更新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:51:28

Xingyao:

我個人對於Computer Use和SimplifyAction Space這樣的行動方式是非常非常看好的。從簡化的角度來看，我們實際上只有一個access tokeyboard、一個滑鼠和一個螢幕，這就是我們所有的Input Space，但透過這些有限的輸入方式組合，我們卻能完成非常多的操作。

軟體本身是一個非常非常強大的東西，我們可以用軟體來構建更多的軟體，然後用這些軟體去控制這個世界上的一切。現在世界上的一切基本上都是被軟體所控制的，所以如果你能生成好的軟體，理論上來說就能做一些事情。

無常按：當年的名言：Software is eating the world. 現在：AI is eating the world.

00:51:28 – 00:52:23

讓我們回到OpenHands Paper的話題。我們這個paper的名字叫做"OpenPlatform for AI Software Developer as Generalist Agent"，最終目標是開發一個通用的Agent。對於這樣的通用Agent來說，我們認為最基本的action space應該包含幾個核心能力：首先是執行程式碼的能力，最簡單的實現就是透過Terminal；其次是編輯程式碼的能力，這需要一個File Editor；第三個目前相對缺失的能力是與browser進行interaction。其實與browser的互動本質上和在電腦上操作各種app沒有太大的區別。所以第三個點其實就是我們剛提到的computer use，computer use不是沒有limitation的，現在的主要問題是，我們還是在以pixellevel的方式在螢幕上進行操作，準確性還不夠高。雖然短期來看這個能力可能還沒有達到我們預期的那麼capable，但我相信這個問題在未來一定會得到提升。

00:52:23 – 00:52:39

Peak:

我覺得聽起來越來越像，OpenHands在做的就是賽博世界的自動駕駛。我們現在正在等待類似FSD這樣的純視覺方案的出現。

Xingyao:

我其實覺得像這種簡化的action space，最終的bottleneck其實就在model本身。其實foundationmodel只要你一開始就用上，後面就都不是問題了。

00:52:39 – 00:52:54

我印象非常深刻的就是在Claude最新的模型釋出之前，我們想方設法絞盡腦汁研究怎麼去improve那個Agentediting。結果cloude一發布，直接把streamreplaceedit訓練到模型裡面了，這個問題雖然不能說完全解決，但也解決了百分之八九十。

00:52:54 – 00:54:01

Monica:

我覺得解決這些問題，你們的模型現在是不是也用到了computer use的API嗎？

Xingyao:

我們現在有一個方案是直接使用computeruse功能。我們最近新合進去的一個功能是做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:54:35

Monica:

當Computer Use出來的時候，我們還在討論是不是因為Anthropic的to B基因的原因。他們本來就有很好的先發優勢，這次終於不是OpenAI先發布vision-based模型，而是直接釋出了API。現在的問題是到底要用API這種形式，還是用其他形式。其實當OpenHands（OpenDevin）這樣的產品足夠強大後，這些功能都會被包含在裡面。從最終產品形態來說，把這個作為一個能力，而不是自己去開發一個只用這種能力的產品，這樣的impact會更大。

00:54:35 – 00:55:50

我想了解一下，在過去這幾個月裡，你們在技術和business角度上做出了哪些重要決策？這些決策是如何提高產品能力和整體社群adoption的？Bingyuan如果有補充也可以分享。

Xingyao:

我認為最重要的技術決策發生在早期OpenDevin階段。那時我們處於相對野蠻發展的階段，社群裡PR滿天飛。我和來自industry背景的Robert對OpenHands這個Agent有著完全不同的expectation。

作為researcher背景的人，我希望這個Agent是easy to use的，可以很容易地進行迭代，做各種research和嘗試。我不需要考慮任何UI方面的問題，只希望action的能力越來越強。但Robert更關注Agent作為產品需要和front end、Userexperience進行tightly integrate。

在這兩種需求之間做balance是很困難的，因為為了給前端使用者提供最好的體驗，有時候需要在Agent方面做出一些犧牲。

00:55:50 – 00:57:35

比如說設計通用action時，你必須要求researcher按特定方式寫Agent才能在frontend裡使用。但對很多researcher來說，我現在連AI能不能work都不知道，讓我花那麼多功夫去研究你們的實現方式，去研究怎麼和產品結合，我其實並不關心那麼多。

無常按：哈哈哈哈哈

所以我們做對了一件最重要的事，就是把backend分得足夠清楚。我只需要關心一件事：我會把所有歷史資訊給你，你拿這些資訊做什麼不關我的事，我只expect這個Agent最後給我一個action就行了。這樣在Agent開發這部分，我們就可以完全抽離出來，讓researcher可以自己在這塊專注開發，不用去碰框架裡其他的程式碼。

現在我們backend有兩套使用方法：一套是和前端產品直接接入，另一套是Reheadless的方法，把Agent直接跟我們造好的一整套框架結合的使用方法。這對應了兩種不同的人群：前者是希望用OpenHands完成工作的使用者，後者是想pushAgent能力的researcher和開發者。

現在很多工作都在用OpenHands作為baseline，比如CommitZero、AgentBench，包括OpenAI的MLE Bench都在用它測試不同的benchmark。這是我們早期做對的一件事。

00:57:35 – 00:58:54

Bingyuan:

回顧OpenDevin到OpenHands的整個歷程，我自己挺有感觸的。開源社群的力量確實非常強大，從我們最初提出這個想法，到現在專案能夠這麼健康發展，開源給大家帶來了很多不一樣的東西。

OpenDevin和OpenHands選擇開源這條路，主要帶來了兩個重要的好處。首先，開源意味著透明，因為這種透明性，就像剛剛Xingyao講到的很多優勢都被放大了。因為我們要服務更多的人，讓更多人參與進來，所以在架構和技術選型上就要去考慮更多的相容性，這樣才能確保專案未來的健康發展。

第二個好處是開源可以打消大家對閉源商業公司的顧慮。更重要的是，我們相信未來的open model也能在openAgent中發揮作用。如果我們能從貢獻openAgent逐步發展到一起貢獻open model，讓所有東西都是開放的，大家就會對未來更有信心。這種透明度、靈活性和每個人都有contribution的機會，正是開源的精髓。我們必須要透過開源的力量，在AI時代為每個人創造屬於自己的AI。

00:58:54 – 01:00:24

這也是我今天覺得OpenHands能做得這麼好，大家能一起貢獻的一個非常重要的核心動機。

Monica:

正好我們來聊聊關於開源的問題。既然已經實現了這麼厲害的能力，為什麼會想要做一個OpenSource版本的Coding Agent？這能給你們帶來什麼優勢，又有什麼挑戰呢？

Bingyuan:

一開始的proposal動機其實很簡單，就是看到這個東西未來一定很酷。我覺得開源社群需要有這樣一個專案，因為開源社群有很多有創造力和能力的人。如果我們能有一個組織把這些人凝聚起來，一起做一個非常酷的東西，這從歷史到今天都有很多成功案例。我認為做一個開放的CodeAgent專案會非常有吸引力。事實證明當時熱度確實非常高，僅憑一個Readme就吸引來Xingyao，這是我們一個非常大的收穫。包括後面Gram和Robert的加入，都充分展現了開源社群強大的創造力。我們自己做Qwen，現在應該算是最擁抱開源的大模型團隊，從開源中得到了很多。

所以我們一直在堅持，希望能給開源社群反哺一些東西。我覺得未來面向AI的開源專案會越來越多，任何場景和任務都可能會有頂尖的開源專案出現。我希望未來開源的AI專案能與開源模型更有機地結合，真正把open這件事做到極致。往小了說，這是給每個人參與AI的機會；往大了說，這對整個社會的進步，以及推動AI民主化的程序都具有重要的幫助。

01:00:24 – 01:01:33

Xingyao:

剛剛Bingyuan說的非常好，就是democratizing AI technology。我們網站上就明確寫著，這麼重要的AI技術不能只保留在少數閉源公司手中，這是我們最初的樸素理念。

作為一個researcher，我認為open source本身是一個非常好的research媒介。我們早期做different research時關注high performance，現在做LLM我們有Hugging Face，在serving方面我們有VLM等工具。如果沒有這些開源的code base作為基建支撐，很多方面的科研進展都會相對緩慢。

我們一開始就希望透過開源專案推動researchand development。但是比如當我釋出基於OpenHands的paper時，我會把相關程式碼都開源。這種開放的模式能讓我們更容易吸收學界Research產出的高質量Agent。

01:01:33 – 01:02:39

作為一個developer，我會為open-source搖旗吶喊。特別是對於developer tool這種讓開發者自己使用的工具，在效能和體驗相近的情況下，大家會更傾向於使用開源工具而不是閉源工具。

我認為在Agent的實現上，並沒有一個真正的大model作為護城河。比如說，我看到你的閉源Agent產品，透過觀察它是怎麼互動的，就能猜出背後的商業邏輯。我可能花兩三個月時間，砸進去一些精力，就能復刻出一個表現差不多的東西。既然大家看著behavior就能猜到，為什麼還要讓大家浪費時間呢？不如直接把核心code開源出來，讓大家在這個基礎上投入時間做更多更有意義的technology創新。

而且最重要的一點是，技術本身其實沒有那麼重要，但是讓技術變得真正有用起來，這才是非常非常重要的。從這個角度來說，open source是有一定優勢的。

01:02:39 – 01:03:34

比如說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最近有一個叫做cursorrules的library一樣。

01:04:24 – 01:05:42

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%確保所有資料都不會離開你們的環境。這種開源的特性讓我們更容易贏得客戶的信任。

01:05:42 – 01:07:29

除了前面提到的，對於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:20

Monica:

我覺得這讓我們重新認識到模型之上應用的價值。比如Devin設計的介面，在不同位置提供三個tab，包括web狀態檢視、程式碼檢視，以及如何讓使用者在過程中進行互動和打斷。像Cursor這樣的產品也不是簡單地在程式碼編輯器裡放一個對話方塊。

在有了AI特別是o1這樣的能力後，我們需要思考是否應該把很長的inference看作一個bug，還是基於它的特點來設計新的互動方式。這些都是應用開發者基於對模型能力的深入理解和思考去做的事情，這也是我們作為投資人很期待看到的。我跟雨森也討論過，認為把產品簡單地做成wrapper其實是一種很懶的方式，這一點在AI領域會被反覆證明。

01:09:20 – 01:09:41

既然講到我們對於底層模型能力的這個期望，那我覺得就不得不講最新鮮熱乎的o3了。那我覺得正好Bingyuan是這方面專家了。我想先問一下，首先是這個o1，o1這樣的模型出現，覺得對於coding的模型這塊有什麼樣的影響？那現在剛剛看到了這個o3之後，你覺得它又有哪一些是讓你覺得最impressive？

01:09:41 – 01:11:00

Bingyuan：

首先o1出來的時候就讓大家感到非常不可思議。我認為inference timecomputing這個路線非常有道理，它一直在推進這個chain of thought這個概念。當把chain of thought做到極致後，就會湧現出更多我們期待的智慧特徵。它的效能表現也非常出色。

目前o1和o3主要是在一些容易驗證的任務上表現突出，比如程式碼、數學以及考試型別的任務。我認為o這個系列現階段還是以探索技術邊界為主的研究方向。在產品應用層面還需要思考更多可能性，但在技術層面它已經證明了自己可以達到一個非常crazy的水平。

昨天晚上o3的釋出最令人震撼的是，他們確實把這條技術路線推向了極致。當我看到code forces 和AIME的水平時，我甚至懷疑自己是不是看錯了，因為那個水平已經完全超出了我們的想象。對於當下LLM或者說當下AI的期待，o3的釋出確實超出了我的預期。OpenAI急於證明自己的技術具有斷崖式的領先優勢，我認為他們暫時確實做到了。

01:11:00 – 01:12:38

但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探索和學習，再結合longchain of thought，整體呈現出一個非常完備的推理模型。這個確實很酷。

Monica:

這個你可以展開講講。因為有時候有些觀點認為，所有模型能力的提升不就是更多資料、更多compute和資料的暴力美學嗎？除了資源之外，o3還有哪些我們可能低估的能力？另外，你剛才提到Alignment這一塊，為什麼在提升coding能力或者說在技術路線上會特別重要？

01:14:04 – 01:15:32

Bingyuan:

我有一個觀點，雖然Ilya說預訓練要結束了，但對於我們來說還有一段空間需要追趕。在pre-training上還有很大的發展空間，無論是token的數量、質量，還是對model size和model scaling的探索。我覺得今天開放的模型或追趕者的模型，在很多方面還有未知的東西需要搞明白。

如果假設Ilya看到的模型就是OpenAI最強的pre-trainmodel，考慮到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上。

01:15:32 – 01:17:52

讓我來解釋為什麼alignment對coding如此重要。從通用模型角度，我們期待與人類對齊，但coding model最終需要與開發環境或者和executer對齊。我們的首要目標是確保程式碼能透過環境的所有測試，實現預期功能。這個signal相比人類主觀評價要嚴格得多，這也意味著我們有了很好的評估標準。

另外，coding和math都是很好的方向，因為math有標準答案可以校驗。coding model的優勢在於不僅能解決競賽級程式設計題，還能解決實際軟體開發中的問題。無論哪種場景，核心都是讓模型與環境完美對齊，理解當前狀態並給出能透過執行器校驗的響應。即使程式碼風格不夠完美，只要能透過所有unit test，就能被使用者接受。

o3這樣的形態特別適合codeAgent。在這類任務中，比如提交issue時，使用者願意花一天時間讓AI進行深入推理。從這個角度，在code agent階段投入inference time的computing是非常划算的。

培訓很重要，alignment在coding中也很重要。我們對智慧的探索可以從coding開始，泛化到更大的reasoning範疇，最終發展到完整的Agent。比如computer use就是很好的方向。我們可以看到一個清晰的進化路徑：從CodeAgent到DigitalAgent，再到未來的PhysicalAgent。這就是為什麼我們要在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和ArcAGI相關的問題。對AI的一個終極期望是實現AI

researcher，能夠解決人類正在研究的未知問題。我很好奇，o3已經能解決這些大部分人類都無法解決的數學和coding題目，與未來成為研究員的能力之間有什麼關聯？雖然可能不一定是下一個愛因斯坦、牛頓，但至少要能發現問題，提出創新性的研究方向和答案的能力。

Bingyuan:

我認為o3目前可以完成research的一部分，特別是需要排列組合的問題求解。這種能力並非簡單的列舉，而是透過有邏輯有思維的方式進行資訊的整合、加工、利用，並且二次創新。

但對模型的更高要求是能夠提出有價值的問題，甚至定義新的科學問題。這是一個遞進的過程，因為科學發展本身就是從很多微小的創新積累到一個基點，等待一個能夠定義新問題的人開啟下一次科學浪潮。

research本質上是邏輯和創造力的結合。但在AI幫助人類探索未知問題時，安全性是一個關鍵維度。我們不能因為模型的幻覺而導致錯誤的結論，這可能是實現AI researcher最具挑戰性的部分。

01:24:05 – 01:26:05

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模型，這是個很好的發展方向。

01:26:05 – 01:27:57

除了效能和成本這兩個維度，我們還需要考慮go beyondSWE-bench。雖然SWE-bench很好地測試了Agent解決Github Issue問題的能力，但它忽略了人類在現實生活中需要面對的許多問題。比如我們現在使用AIAgent的方式，包括像Devin這樣能在Slack中與人互動的整合，我們更需要measureAgent在真實公司環境下執行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提升是因為已經採集的資料被更強大的modelpre-training，已經透過inferencescaling從歷史中回憶出這些資訊。這個問題需要更多關於data contamination（資料汙染）的follow-up實驗。

01:27:57 – 01:28:18

我認為datacontamination的實驗挺重要的，它能夠在很大程度上決定使用者的實際體驗能否提升。這裡有一個關鍵問題需要考慮：模型的能力提升到底是主要來自於它們本身能力的提升，還是主要來自於它們能夠從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:31:49

Bingyuan:

昨天OpenAI在SWE- bench上的表現令人印象深刻，特別是考慮到o1之前在這個任務上稍微有些翻車。更讓人震撼的是它在Codeforces上達到的水平。

震撼的點在於，Codeforces現在還沒有特別標準化的benchmark評估，但Codeforces是檢驗人類程式設計水平的平臺。它會在固定週期內舉辦多場比賽，需要計算rank分數，相當於要跟人類同臺競技去寫程式設計題目。他今天做到這個分數，基本代表在寫檔案級別的程式碼或解決方案時，已經達到了非常非常非常牛的狀態。

而且Codeforces在一定程度上可以緩解之前提到的洩露問題，因為每週都會有新的比賽和題目出現，我相信在泛化性上應該會有一定保障。但是Codeforces還是更多檢驗檔案級別或競賽級別的解決方案能力。SWE- bench可能已經開始有一些真實環境下的簡單評估了。我覺得未來評估還需要提出更難的benchmark，在更真實或更具挑戰性的條件下測試表現。

01:31:49 – 01:33:10

對未來benchmark的期待，我認為有幾個重要的準則。第一，它要足夠具有挑戰性，特別是對已有的模型來說。第二，需要有動態更新的機制。比如說Live Code Bench是一個很好的benchmark，它從leetcode的周賽中抓取題目來評測模型。這種動態更新機制對於評估模型的真實泛化性非常重要。第三，選擇的任務要容易驗證。這也反映了現有技術路線可能需要依賴一些廉價的signal來達到好的效果。

Monica:

我們可能還不確定在coding和數學等能力上的提升，是否能真正轉化到更general的日常生活Agent任務中？

Bingyuan:

是的，但我一直認為這些基礎task是一個strong model的必要不充分條件。即使是HumanEval到今天仍然有其價值，如果一個模型只能得到六十分，就很難讓人相信它真的很強。這些benchmark的意義在於幫助發現短板，證明模型達到了基本水平。當然，真正應用時的表現如何，還需要時間來驗證。

01:33:10 – 01:35:54

Monica:

我想討論一個觀點，假如我們遇到一個很得力的秘書或AGI系統，它可能並不需要精通數學或程式設計。那麼，我們是否需要在coding和math這些領域投入這麼多訓練和最佳化？我們看到矽谷一些公司，比如magic def等，他們mission選擇專注做一個最強的coding模型，而不是像GPT這樣包含大量世界知識的大模型。這會不會是一個更高效的方式來實現AGI？

Bingyuan:

我認為短期內走專家化模型是相對正確的路線。包括我自己做coder模型時，也是先排除非核心任務的能力，把某個任務或能力做到極致水平。我對AGI的定義不是實現像人一樣的智慧，而是實現人做不到的智慧。比如在coding領域，我們期待模型能寫出執行效率比人更高的程式碼。這在實際軟體開發中非常重要，很多軟體諮詢公司就是專門解決系統效率問題的。如果模型能在某些任務上超越人類，這將推動AGI向新臺階邁進。

專業模型在當下非常有價值，是一個探索邊界的過程。如果我們能真正觸及到一個邊界，再把它擴充套件到更多工上。在資源有限的情況下，我們可以先專注於某些任務，探索資料、技術和最佳實現方案。現在專注做coding是必要的，我們也可以期待coder能湧現其他能力，比如coding和math是否互補。我們可以先專注coding，然後解決好reasoning的問題，再逐步向通才發展。從長遠來看，我還是期待有一個各方面能力都很強的通用AGI。

Monica:

對，就像秘書一樣，最好是什麼都會。這種工種的區分可能源於我們人類自身能力的侷限性。

01:35:54 – 01:36:44

說到這個，前段時間提出的τ-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，大家最先想到的就是需要一個前端來展示要做的東西。我覺得前端可能是CodeAgent一個很好的切入點。

包括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領域來說，我覺得一個重要的發展方向是inferencescaling方案。現在越來越多的Coding Agent都在探索這個方向，包括我們自己。比如在處理github issue時，這就像給人類一個slider，可以選擇是花更多資源解決複雜問題，還是用較少資源解決簡單問題。這也是一個notable trend。

我們發現現在有些SWE-Bench的submission也在嘗試做bestup 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:

是的，AgentCompany本身就是用Openhands作為basicAgent進行開發的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:45:29

Monica:

那你覺得未來程式設計師需要怎樣的能力？我們去招一個程式設計師，我們還希望他去完成什麼樣的任務？那對於程式設計師整個career path培養和教育會產生怎麼樣的影響呢？

01:45:29 – 01:46:06

李珎:

我認為更好的程式設計師應該具備更多的產品思維，他們知道從正確的視角看問題，並能透過資料來驗證一個方案到底是好是壞。比如說對於一個產品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:48:11

Monica:

我覺得按照這個進化思路，這可能不是幻想。因為剛才Xingyao已經說了，他們都已經能夠讓他們的Agent成為他們整個codebase最active的controller之一。我在想，如果兩三年後我要成立一家公司，是先招Agent然後再想需要補什麼樣的人，還是像現在一樣先招人再用Agent補足能力。

就像戴雨森說的，對於整個組織架構，以前是軟體把組織里面的人聚合起來，現在也許需要不同的軟體把人聚合起來，這個的確可能會帶來非常fundamental的影響。我也聽聽Xingyao，尤其是你們機構內部用上AIagent，你是怎麼看這個問題的？給你們的組織帶來哪些變化？

01:48:11 – 01:49:42

Xingyao:

我覺得現在最直觀的感受就是我們對新feature和新工作的態度完全不一樣了。以前開發新feature時，需要考慮時間投入、前端資源是否充足、優先順序排序等問題。但現在隨著Async型別的Coding Agent逐漸成為現實，就像前面雨森說的，限制我們能做多少的已經不是能力本身，而是想象力。

世界上的問題只有兩種：Agent能解決的和解決不了的。對於Agent能解決的問題，只要想清楚就可以交給Agent去做。在我們的開源社群裡，因為整個code base是開源的，不僅公司內部在用，我們現在的beta版本已經有上百位使用者在日常使用。我們社群有一位很有意思的founder，他沒有招很多程式設計師，而是把OpenHands作為開發資源放在他的專案中。他會同時開啟二十個issue，讓OpenHands並行處理，雖然可能只有一半能work，但這對他來說不重要，因為他的目標就是讓Agent幫他並行開發。他一直在催促我們加快開發，這樣他就能啟動一百個Agent同時工作。

這個例子很好地說明了工作方式的改變。就像前面李珎和Bingyuan討論的，現在對人類來說越來越重要的是知道自己想要什麼，而具體如何實現它反而不是最重要的事情。

01:49:42 – 01:52:20

就像Bingyuan前面說的，以前我們走專家路線，對某個領域非常熟悉，能快速完成任務。

我可以分享一個例子。我自認是個非常糟糕的前端開發者，對前端的瞭解僅限於學校一個學期的課程，但我能看懂前端程式碼的基本邏輯。

今年十一月份，我用OpenHands（OpenDevin）做了一個早期功能。當時我們剛加入多模態能力，我給OpenHands（OpenDevin）一個啟動介面的截圖，用微信畫了個紅色箭頭指向聊天框，直接要求它幫我實現拖拽圖片的功能。讓我驚訝的是，它一輪就完成了，直接把drag and pasteimage寫進程式碼並實現了功能。

但後來發現程式碼庫有問題，我讓它修復問題，它也很快完成了。但玩了一會兒後，我發現一個之前沒想到的問題：拖入圖片時沒有視覺反饋，使用者不知道是否操作成功。

這時我更像是一個甲方，在驗收它交付的成果，看是否符合預期。因為OpenHands（OpenDevin）能在十分鐘內就實現功能，讓我能及時測試、探索更多使用者體驗的可能性。這讓我們意識到，不需要成為前端專家，但需要能看懂程式碼、明確知道自己想要什麼。

另外，作為管理者，需要給Agent明確的、可量化的目標。如何正確地做prompting、佈置工作，這是未來開發者的重要技能。

無常按：最近也有類似的感受，目前能用好 AI 的——也就是能寫好 Prompt 的——往往是有管理者思維的人。

01:52:20 – 01:53:22

Monica:

看了你剛才展示的程式設計過程，我想到之前和朋友一起使用Devin的經歷。當時讓它做一個部落格網站，它在完成後會主動測試UI，自己寫兩篇文章來測試整個flow。這讓我想到你剛才提到有點像o1的思維方式，與其說讓你去檢查它哪裡不對，不如說它能力進化後自己就具備完成測試、發現問題並解決問題的能力。

Xingyao:

我們確實考慮過是否要在產品中加入讓Agent主動進行測試的功能。最後我們決定不加入這個功能，而是把這種可能性開放給使用者，讓使用者自己決定什麼是最適合他們的。

但這也帶來了另一個挑戰，就像李珎前面提到的，使用者教育對我們這類產品來說非常重要。因為如果使用者不瞭解Agents的能力邊界，往往就想不到要使用哪些功能，需要explicit去告訴它。這是AIAgent產品的一個限制，我覺得這個問題值得討論。

01:53:22 – 01:53:44

我們需要思考的一個問題是，是否需要讓Agent明確地去執行某些特定任務，還是讓它完全按照使用者的指令來執行。

Monica:

這個問題不只是一個安全問題，而是一個更廣泛的產品設計問題。這與我們如何設計產品有著密切的關係，是一個非常重要的問題。你們有什麼補充嗎？

01:53:44 – 01:55:02

李珎:

就像我剛才說的，如何讓Agent告訴使用者它能做什麼，這件事特別特別重要。我最近在Replit上加了一個功能，讓Agent在完成使用者的一個feature後，會主動建議下一個可能的feature，告訴使用者怎樣完善這個產品。

從創造力這方面來說，使用者很多事情是想不到的。比如說，他做了一個personalnotebook，可能沒想過要加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在codeforces上的分數超過兩千七，而能達到這個分數的人類卻不到兩百人。這是否說明在很多工上，實際上可能是Agent在教我們如何做事？最終可能是Agent自己識別出還有什麼是它做不了的，然後再來給我們分配任務。

李珎:

現在Opendevin已經是這樣的形式了，就是由Agent去執行任務，然後讓人類來confirm。這個confirm其實就包括了code review和各種互動。最終人類要做的就是confirm和guide，就是確保Agent不會做出一些crazy的事情，比如把資料庫drop了。

01:55:49 – 01:57:33

Bingyuan:

我有個觀點，就是現在o3和o1都在講inference-timecomputing，其實人類也可以參與到這個computing環節中。無論是處理很長的problem還是多輪之間的feedback，如果把這些看成一個完整的response，人類的language能力其實也是在貢獻到inference-timecomputing裡面。所以未來真的不太好說，可能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 – 01:58:52

Xingyao:

對，其實剛才Peak討論的這個問題讓我想到OpenAI早期就在研究scalableoversight和weak tostrongtransfer這些問題。隨著模型變得越來越強，人類review程式碼所需的時間會越來越長。其實AIAgent本身也可以幫助我們review程式碼，可以讓一個AI寫程式碼，另一個AI進行深入研究分析，最後人類只需要蓋個章。從背鍋的角度來說，人類工程師是絕對會消失的，只是角色會發生改變。

Monica:

這確實是個重要觀點。不過目前我們對AI的定義還是一個junior engineer，包括Devin也是這麼定義的。剛才Xingyao展示的幾個任務，也都是給初級工程師做的事情。那要讓AI實現我們期望的未來，成為組織里的主力，你們覺得還需要提升哪些方面？

Xingyao:

第一個是資訊的來源和整合問題。我們人類能夠訪問到的所有資訊渠道，這個Agent就必須能訪問到。比如說公司內部的各種系統，或者我們用來溝通的Slack，Agent都必須要能訪問，這是Agent變得更加獨立的必要條件。

01:58:52 – 02:00:14

從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，因為我相信大家一定會把它推上去。從我的角度，最重要的是feedbackloop，我們要給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非常重要。一旦feedbackloop給得好，它可以做非常crazy的事情。

Monica:

這個feedback loop是一個model capability嗎？還是產品層面的東西？

李珎:

我覺得不是模型能力。其實是一個integration的事情，就是讓Agent能自己做A/B test並處理結果。

包括在Twitter上發軟文，投放廣告，把整個產品流程走完。這已經beyond engineer scope了，但我覺得這是未來的正確方向。因為engineer通常只care把事情做好，把什麼是正確的decision交給founder、VP或datascientist。

但對於Agent來說，可以用separateAgent來處理這些decision。如果把AI作為整體考慮，它應該有自己make decision的能力並持續迭代。在這個過程中，使用者增長、Revenue增長這些都是很確定的signal，能指導什麼是好的，什麼是不好的。這也是人類的做法，也是最scalable的方式。

02:02:37 – 02:03:22

Monica:

Bingyuan，從你作為一線做模型的角度來看，你覺得我們接下來還有哪些要攻克的地方？

Bingyuan:

我覺得從模型角度來看，未來還有很多可以做的事情。正如李珎提到的signal這個事情非常exciting，一旦有了signal，我們就可以做很多事情。coding在未來可能會更多地加大對alignment的研究。

目前的code model中，這個世界上的程式碼token相對於普通token來說，數量其實並不會特別大。也就是說在pre–training過程中，我們很可能能夠獲取到很多現有人類產生的高質量token。關鍵是要思考如何讓這些codetoken在最終應用環節上能夠更好地服務我們的需求。

02:03:22 – 02:05:03

其實在Alignment上能做很多事情，從OpenAI和當前最頂尖的模型來看，我覺得planning能力是一個重要方向。現在很多模型的planning能力還做得不太好。就像Xingyao剛才提到的案例，如果模型的planning能力很好，對於修改前端這個任務，它應該能從一開始就規劃好那些feedback。如果能提前規劃好，實現起來就會很順暢。所以我覺得對於codeAgent來說，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的程式碼改動是好是壞，以及具體原因，這幾乎是不可能完成的任務。

但ReplitAgent、Devin或Openhands的使用者每天都在自然地產生這樣的標註。這些標註資料的質量非常高，每個使用者的反饋都是dataset的一部分，能幫助未來的改進。

02:07:13 – 02:08:50

Monica:

你們在開發foundationmodel時，資料主要是在Agent應用中產生的。那接下來對foundation model公司來說，如何提升這方面的能力呢？

Bingyuan:

我們可以從foundation model角度也可以快速搭建環境，讓Agent在裡面進行互動來產生資料。在資料策略上，可以先用合成數據做warm up，等未來應用爆發後，再用人類的真實資料讓它變得更strong，更好地與人類對齊。

Monica:

在灣區時，我們看到很多公司在做infraforAIAgents。雖然在國內這個趨勢可能不太明顯，但在國外，即使在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:13:48

Monica:

作為投資人來說，在AI應用領域，大家一直都很關注專業AI和AIAgent的落地情況。AI應用能否真正落地？哪些產品最終需要由模型公司而非產品公司來做？這是很多創業者和投資人都在探索的問題。雨森，你如何看待AI應用和AIAgent的價值與投資機會？這些想法會因為Devin的出現而發生變化嗎？

02:13:48 – 02:14:55

戴雨森:

我覺得有一本書的副標題"the future is faster than you think"很能總結我的感受。在年初的時候，對Agent的討論還是比較概念性的，雖然大家都覺得Agent是未來，但對它具體長什麼樣、什麼時候出現，我覺得當時整體來看還是認為是一個相對比較長時間的過程。這也體現了投資人對事情的預判在時間上往往會差很多。

現在的Agent產品已經展示出幾個重要特性：對任務的planning能力，寫程式碼的強大能力，使用工具的能力，以及能在工作中不斷積累對組織的knowledge，還有自我學習進化的能力。而且是按照賣工作，不是賣工具的思路，所以可以對標人類的薪資。當一個事情有了第一個帶頭的，後面就會有很多人去改進跟進。

今年我們看到了三個非常大的技術進步。

第一個是AI的reasoning能力大幅提高，這讓AI在做planning時變得更好，hallucination會減少，能夠進行更長時間的planning，並且更好地follow計劃。

第二是AI程式設計能力的大幅提高，以Codeforces為例，o3都已經做到兩千七百分，這基本上達到了人類頂級程式設計師的水平，而且這個水平還會繼續提高。

第三是AI使用工具的能力。這三個技術進步奠定了數字世界Agent的基礎。

02:15:25 – 02:16:56

你想想看，如果一個工作能被總結成人類坐在電腦前透過和電腦互動能完成的，那這個事情在現在來看基本上都可以逐漸被Agent化。我們接下來會看到越來越多的Agentfor everything，特別是everything digital。

程式設計只是其中之一。我現在用下來發現，Devin對於資料和文書類工作並不是那麼擅長，但這很正常，因為大家最佳化的方向不太一樣。我們完全可以想象，既然有針對資料分析師的Agent，有針對sales的Agent，還有針對產品經理的Agent。當然最後可能不只是某一個人類角色直接對應到一個Agent，而是會有一些混合的角色。

很有意思的是Agent之間要如何互動。現在我得自己提出需求，但以後可能會有產品經理Agent來做產品plan，然後這個plan再對映到程式設計部分。因為人本身在planning和提問的能力上也是有限的。

之前看到ChatGPT這種問答形式時，很多人都在想：我好像沒有那麼多問題要問AI，大部分人並不是每天要問那麼多問題。所以大家在想怎樣能讓人類使用AI的用量多十倍、多一百倍，之前一種方案是跟AI談戀愛，搞這種情感的東西。但現在我們發現，如果讓AI去做事情，而不是隻是回答問題，那整個token
usage就會大幅上漲。這對我們整個模型的用量、算力的提升都是非常非常厲害的影響。

02:16:56 – 02:18:50

在美國，大家現在討論很多的一個話題是從賣工具到賣工作的轉變。如果只是持續使用工具，其實並沒有真正解放注意力，這還是停留在工具定價的邏輯。這也是為什麼當Devin推出五百美金一個月的價格時，大家覺得特別貴。因為他的定價邏輯完全不一樣了，他是在賣工作成果。具體測算，一個ACU是兩美金，約十五分鐘工作時間，換算成每小時的薪資標準，大概是8小時的薪資。

在加州，麥當勞打工的最低工資都是十六美金一小時。所以現在Devin的定價其實只有加州最低工資的一半左右。而且你可以很確定地預測，它的算力成本會以每年降到之前十分之一的速度下降。這意味著同樣八塊錢一小時，僱一個Devin，它的能力會不斷擴張，但成本可能保持相似或者甚至會下降。

在這種情況下，關鍵是如何讓產品實現從賣工具到賣生產力成果的轉變，這是Agent時代的新變現模式。現在對於按席位收費的SaaS模式出現了很多質疑，如果未來是賣工作成果，那可能就不需要再賣這些席位了。

我覺得之前中國企業服務領域確實非常難做和難投，Monica應該有很多切身體會。最主要的原因是大家不太願意為工具付費，覺得軟體工具就該是免費的，這可能是整個商業環境和文化使然。

但我在想，如果我們能真正實現賣工作成果，那企業服務在中國可能會出現一些有意思的機會。因為不管怎樣，企業最終是要把事情做成的。如果AI能直接交付工作結果，對企業來說就像找外包公司一樣，這種模式他們是願意付費的。只是從原來的人力資源外包，變成了智力或生產力的外包。

02:18:50 – 02:20:14

在AI時代，中國的生產和企業服務領域正重新迎來機遇，因為AI本質上是一個能大幅提高生產力的技術革命。現在很多人在往娛樂方向發展，想用位元組的原來套路去做一家新的AI超級公司。位元組做的很多事情還是偏娛樂，偏殺時間，那如果AI真的能幫人省時間，在中國怎麼落地？我覺得企業服務這塊會有一些新的機會。

從安全形度來看也會有很多機會。雖然我知道AIAgent的能力還有很多不足，但人都是想偷懶的，當它能夠看似完成工作的時候，我很多時候就放心讓它去做了。但是當它有越來越強的程式碼執行能力和軟體使用能力時，如何確保它能夠和我的組織目標、整體社會價值去align就成為重要問題。這時候組織里面算力怎麼分配，針對它的安全、針對多個Agent訓練，這些都可能是之前沒有意識到但現在需要解決的新問題。

整體來講，這是一個讓大家看到未來的很好例子，但本身Devin這家公司還有很多要去做的。OpenAI也好，Anthropic也好，大家都在做Agent的產品，所以鹿死誰手尚未可知。但是對未來形態的展示，是我們從這裡面可能看到最重要的一個特點。

02:20:15 – 02:20:46

Monica:

對，戴雨森剛才講的幾點都非常全面。我作為投資人也非常關注團隊這個因素，真格是一個很看人的基金。你覺得要做出下一代的Agented workflow，需要什麼樣的團隊呢？

其實上半年的時候，紅杉就提出過這個概念。那時候即使市面上有很多號稱Agent的產品，大家都覺得只是一些自動化工具而已。現在我們對於純產品的定義已經和之前不一樣了，在這樣的背景下，需要怎樣的團隊來做這樣的事情？

02:20:47 – 02:21:22

戴雨森:

我覺得Cursor和Devin這樣的團隊都反映了一些共同的特點。比如說他們都是人才密度非常高的團隊。Curson是零零後MIT的團隊，而Devin一上來就表示他們有十幾位金牌獲得者。同時，他們都很年輕，創造力和執行力都非常強。

我覺得Devin是一個典型案例，他們既在技術上很厲害，有很強的技術團隊能力，得到了OpenAI的支援，同時在程式碼編寫這個工作流程上有很深度的經驗和思考，知道如何把AI和實際工作場景結合起來。

02:21:22 – 02:22:22

因為我覺得去年的時候大家都在討論，你是不是要做AI-native的產品，是不是要做自己的模型。在技術發展早期，大家會發現產品和技術是比較耦合在一起的，產品就是技術本身。但是隨著技術的不斷發展，底層的技術和產品其實會解耦。

現在最火的這些產品，不管是Cursor、Devin還是Perplexity，包括我們投的Monica，Peak在的公司，其實都不是說要做一個自己的foundation model。它是建立在已經定位到了使用者要解決的問題場景，或者說PMF的基礎上，然後等待模型變得越來越強，直到符合產品需求。

其實Cursor在2023年初就已經出現了，但那個時候並沒有那麼火。一個很重要的原因是當時的模型沒有那麼強，導致Cursor的產品理念 – next action prediction不能完全呈現出來。現在Sonnet3.5其實是成就了Cursor，讓Cursor成為程式設計師coding過程中的重要選擇。

02:22:22 – 02:23:07

Devin這個產品現在主要是在呼叫GPT-4o這樣的API，也用一些像Sonnet這樣的模型。但在目前的模型能力上，還不足以完全發揮出Agent的這種能力。那麼，什麼樣的模型能真正成就Devin這樣的Agent形態？會是誰做出來？會具備什麼特點？這其實是個互相成就的關係，因為Agent的普及也會讓這樣的模型變得更重要。

我們發現創業並不是一定要訓練自己的模型，而是要和模型形成一種更緊密的共生關係。對Devin這樣的Agent產品來說，核心競爭力在於如何把模型用好，以及對使用者實際工作流程的深刻理解。這不是簡單靠OpenAI釋出新模型就能替代的過程。

無常按：應用團隊，要與模型共生。

02:23:07 – 02:24:03

對於團隊來說，對技術的理解、對場景的理解以及創新思維都很重要。Devin在剛出來的時候提出了一種全新的互動方式，當時大家都覺得是在忽悠，覺得這個可能實現不了。但是他們用很強的執行力證明了這個事情是可以做到的。這能夠啟發大家的思考，這是非常重要的一點。

總結一下，第一要有很強的人才密度，這在遊戲需要探索的時候尤其重要；第二需要對技術和場景都有深刻的理解；第三執行力要很強。我們看到這些都不是很大的團隊，在幾個月到一年的時間內就能完成完整的產品並且deliver。特別是像Cursor這樣的產品，是在跟Copilot這種大公司開發的應用競爭。對創業公司來說，很重要的是要快，要在同樣方向上能跑贏大公司。很多時候創業公司反而在機動靈活性上有優勢。

02:24:05 – 02:24:46

Monica:

我們看到像Devin還有Xingyao這樣的團隊都是接近00後的同學。真的是這些年輕的researcher，他們反而沒有所謂的manager經驗、產品經理經驗，卻做出了非常優秀的產品。前面也提到現在矽谷從"software
as a service"轉變為"service as
software"這樣的workflow工作方式，我想請教一下，除此之外，在中國看到這些Agent型的公司，還有哪些你比較期待的機會？會有什麼不一樣的特點？

02:24:46 – 02:25:56

戴雨森:

我覺得一般來講，中國這種新產品的進化分為兩個階段。

第一個階段就是copy to China。比如當看到美國或世界上出現新模式時，如GPT出來後，中國就會有這種個人助手產品。我相信現在很多人在非程式設計領域會去復刻Devin的工作。

在程式設計領域，因為程式設計師一般都用最好的工具，較難有國產替代過程，不過在新創領域可能會有。如果是程式設計師群體，他們可能更願意使用Cursor這樣的全球範圍內最佳實踐的應用。

在非程式設計領域，我覺得只要在數字世界能夠完成任務，這都可以被Agent逐漸快速解決。無論是做海外市場還是中國市場，如果service as software這個大前提能成立，應該都會有很多新的產品形態機會。

當然在中國是否可行，這也是我非常感興趣的話題。如果聽眾朋友們想要在中國做生產力Agent的產品，我們非常願意去聊，因為雖然有些投資人對中國生產力工具的發展感到失望，但我覺得新的技術和新的產品形態可能會帶來新的機會。

02:25:56 – 02:26:28

Monica:

那我們進入最後的快問快答環節，我準備了幾個簡單問題。第一個問題，想請大家分享一下，你們最希望在未來一年和三年內，在Coding Agent或generalAgent領域看到什麼樣的發展？

戴雨森:

未來一年，我期待看到Agent在數字世界的各個領域都得到嘗試，就是Agentfor everything in the digital world。雖然有些領域可能暫時不會成功，但在某些領域會逐漸被人們採用。而且因為AI被賦予了足夠大的發展空間，我相信這裡面的產品形態會呈現百花齊放的狀態。

02:26:28 – 02:27:42

如果你給AI工具、程式碼和planning指揮他人的能力，可能帶來的風險是非常大的。從三年的角度來看，很難做出準確預測，因為按照目前的進化速度，Agent在執行很多工時的能力可能會超過99.9%的人類。那時候我們已經很難想象它具體會如何工作了。不過在三年的尺度上，我覺得很可能會看到Agent之間的協作，這會帶來全新的想象力，同時也會帶來潛在的問題。

人類之前有大量的想法無法得到實現。我們經常會聽到這樣的笑話："我有一個很好的idea，但是缺個CTO"，或者"我缺個程式設計師把它實現"。但是當把想法實現出來的能力逐漸變得不稀缺，甚至變得很便宜的時候，有多少沒有被實現的想法可能會被實現呢？

在美國有一個很有意思的網站叫websim，你只要輸入一個prompt，就可以生成一個對應的網站。這說明我們現在使用的軟體和網站都是別人想法的產物，但顯然這個世界上如果有個想法的全集，現在已有的網際網路只是很小的一部分。那這個還沒有被髮明出來的網際網路是什麼樣子？在這個意義上，我覺得整個人類社會創新的速度可能會大大提高。

02:27:42 – 02:29:30

重要的是想法，因為執行力已經可以透過花錢以越來越快的速度、越來越低的價格買到。關鍵是如何讓這些想法得以實現？這對風險投資會產生重大影響。目前我們給AI提出問題和任務的速度還受限於人類的思考速度，如果能實現AIAgent之間的相互指揮和協調，我們可能開展的工作範圍會進一步大幅擴充套件。這樣一來，提出好的問題、好的思考、創新型能力將成為人類獨有的優勢，而AIAgent之間如何使用和分配資源，可能會變成一個黑盒子，大多數人不需要過多關注。

有朋友說，程式設計師更關注像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美金的訂閱費，還包括使用費。同樣一個任務的monthlyAgentcomputer units（ACU）消耗是不可控的，有時候幾美金就夠了，有時候可能要花十幾美金。不過我覺得這個成本問題應該很快就能得到改善。

02:31:25 – 02:33:14

Bingyuan:

一年的話，我期待Coding Agent能真正實用化，讓所有人都因為它的存在使開發變得非常高效。這是很多公司、個人開發者和開源社群都在努力的短期目標。

從長遠來看，我更理想主義一些，希望能看到AI在Codeforces上成為穩定的第一名。我對AI超越人類很有信心，因為它能吸收如此多的資料，可能會產生比人類更高階的智慧。這樣強大的模型對科技發展和社會進步都會有重要意義。關於AI可能寫出人看不懂的程式碼，雖然這不是一個好的特性，但只要它在某些事情上足夠強大，我認為這是可以接受的。

Monica:

有個有趣的現象，現在的模型已經能解決很多人類解決不了的數學題和程式設計問題，但在處理一些簡單的日常任務時反而不如人類。這個問題是出在模型本身，還是產品層面呢？

Bingyuan:

我覺得這主要是時間問題，現在的研究重點還沒有從一些定義明確的任務轉移到更廣泛的應用場景上。

02:33:14 – 02:34:29

就是這樣。技術一旦在某些難題上得到驗證，下一步擴充套件就是時間問題了。

Xingyao:

我覺得一年之內，各家的preparing model，包括像big lab的OpenAImodel都會有很大進展。Opensourcemodel應該能在benchmark上穩定在50到70分這個水平。同時，在GitHub上用Coding Agent解決問題會成為新常態。雖然現在這些Agent的水平可能還只相當於實習生，還沒有達到我們期望的junior那麼可靠。

我希望三年之後，它能百分之百成為一個穩定的junior開發者，而且有50%的可能性會成為一個非常穩定的、可以挑大梁的可靠隊友。這就要求像在Agent company這類的benchmark上要達到七八十分。按現在的發展速度，三年應該是沒問題的。

Monica:

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

02:34:29 – 02:34:43

Xingyao:

我現在最大的體驗就是覺得這個OpenHands懂得比我多得多。我現在會在網上找到各種文章，然後向它提問，比如詢問某個技術是否適合應用到我們的report中。從這個角度來看，它已經是一個SeniorEngineer了。

02:34:43 – 02:36:03

Monica:

哎，我們剛才講了很多Coding Agent的優缺點，有個有趣的問題想請大家分享一下，就是你們在使用Coding Agent時有沒有遇到過意外的"翻車"經歷，特別是在那些你覺得它應該能做好的地方。

Bingyuan:

我平常經常用模型寫一些資料處理的程式碼，因為這類程式碼的邊界條件處理比較容易出錯，自己寫的時候也會需要花時間debug。所以當模型的coding能力提升後，我會比較依賴它來處理這些任務。

但有個問題就是，它寫程式碼時會受到你提供的上下文影響。比如我給它一段樣例資料，它有時候就會影響你最終資料處理指令碼程式碼的準確性，因為我做coder，讓它寫新的code來處理，它生成的新code可能會被原始code影響到。這其實是個很常見的需求，應該有很多方法可以解決，但現在還是會出現一些意外的翻車情況。

02:36:03 – 02:37:09

Monica:

關於context的理解，雖然現在我們說contextwindow很長，但這並不代表對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:

這確實是我們一直在思考的問題。目前我們採用的是最簡單的方法，就是直接把所有內容塞到contextwindow裡。

我們現在有一個快要完成的memory compensation專案，核心思想是並非所有step對於predict下一個action都同等重要。比如在一百個turn中，可能只有最近的二十個turn的資訊值得保留，前面八十個turn可以直接刪掉或做個簡單總結。我們正在探索這種不同的memory管理方法，目標是agent讓每次執行action的cost保持在一個常數級別，比如每一輪的input的context window永遠保持在32K這樣的固定大小。

02:38:34 – 02:39:47

Peak:

正好聊到context這個話題，我最近用Coding Agent時遇到了一些踩雷的情況，本質上也是一個廣義的context問題。Devin有一個叫做knowledge的功能，設計初衷很好。比如在做資料分析任務時，我提醒它分析問題要多看官方報告而不是隻看新聞，它就會把這個知識update並記下來。

實際使用下來是好壞參半的，十次裡有五次是驚喜，五次是踩雷。這個問題部分靠模型能力提升能解決，但更多需要產品層面的設計。從長遠來看，這可能會成為產品的一個競爭力，就像我給實習生交了更多知識一樣，使用者用得越久越不容易轉向其他產品。

Monica:

對這個knowledge management功能，我覺得真的非常驚豔。它能自己知道哪些資訊應該留下來，不用一個個具體地去指定。這讓我覺得很像在培養一個有進化能力的實習生，是新一代的lockin。

02:39:48 – 02:41:03

那這個Coding Agent還有哪些做得不夠好的地方，可以分享一下嗎？

Xingyao:

其實在這方面，我覺得當你給codingagentaccess的時候，它可能會做一些意想不到的事情。比如說，我有時候只是想讓Agent讀一讀某個開源專案的repository，幫我看看程式碼怎麼寫，但是它有時候會趁我不注意，拿著我的GitHub token去開PR。這本質上是Agent會做一些未經授權的action。我覺得這在model層面和safety層面都需要重視，就是要確保Agent執行的這些操作是經過一定程度上的人類批准的。

但是說到人類批准這個問題，你可能會有非常high level的批准方式，比如在某個範圍內你做什麼都可以。另一端是像Cursor的Agentmode那樣的嚴格控制，要求每一個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，期望值太高，總是問為什麼這些模型在某些任務上還表現得這麼差。

另一方面，我覺得大家反而低估了現有frontiermodel的實際能力。特別是在Coding Agent方面，雖然有些問題需要一些複雜和精妙的prompts，但一旦掌握訣竅，現有模型就能做出非常非常多讓人驚訝的事情。比如說，當Agent遇到問題時，讓模型列出五個可能的hypotheses並一個個排查，這樣簡單的prompt就能讓Agent的能力提升好幾個臺階。現在的模型已經能做很多我們想象不到的事情，只是我們還沒找到正確的開啟方式。

Monica:

所以問題在於是我們限制了Agent的能力？

Xingyao:

對，其實如果我們不給Agent這種"想出五個假設"的建議，它本可以透過reinforcement learning，在大量訓練中總結失敗和成功的經驗，自己學習到這樣的技巧。

02:43:18 – 02:44:54

Monica:

讓我們看看這個Bingyuaninference的情況。

Bingyuan:

這個問題我思考了比較久，主要是在想o3的能力到底有多強。我們今天討論的高估和低估，其實都還是在o3出來之前的認知範疇。雖然我們現在用的是能獲得的最好模型，但如果明天能拿到新版本，情況可能就完全不同了。

無常按：和大多數人的認知衝突的是，你以為 AI 解決不了的大部分具體問題，大機率只是因為你的問題綜合評估的優先順序還不夠高——研究重點還沒有轉移到你的場景上。換句話說，只是時間問題。

所以我的暴論是：永遠不要低估AI，永遠不要低估一個高估AI的人。

我覺得大家對模型的高估主要體現在期待它無所不能，要求面面俱到。對於沒有AI背景的普通使用者來說，他們對AI的認知差異更大。比如我跟母親解釋我的工作時，她很詫異，因為她認為在零幾年的時候人機對話就已經解決了。這說明普通使用者被AI震撼的門檻其實更高。