OnBoard! 這個用愛發電小作坊，文字實錄全靠粉絲們貢獻！

2024年年末壓軸的 Coding agent & o3 一期其實非常 technical，沒想到也非常受歡迎（文字稿也準備中！），希望對這個話題有深入理解的你，一定不能錯過 🙂

其實早在2024年5月，OnBoard! 就第一次討論了coding agent 嘉賓陣容也是相當強大！從SWE Bench作者、現在 OpenAI agent 研究員 Shunyu Yao, 到 Augment, Replit agent 核心成員……

討論的內容也非常根本和硬核。如果你希望對 agent, coding agent 有更深度本質的理解，這一期都絕對值得好好收聽。因為內容比較技術，很多聽眾反饋希望有文字稿——於是，我們了不起的志願者終於奉獻了這篇精校稿件！

轉發的同時厚臉皮保留了Transcipt 製作者對本期內容的肯定，再次感謝無常同學的無私貢獻！

無常按：

2025年被很多人視為 Agent 之年，確實值得多關注。今天分享的這篇，應該是全網關於Agent話題最深入的討論了，大概沒有之一，從前沿研究、互動設計到產品落地，全文超過三萬字，一篇看明白。　

核心觀點

超 4000 字人工提煉，實在沒時間可以先讀核心觀點，但仍然非常推薦閱讀全文。

關於Agent

Agent本質上由三個部分組成：action space、decision making 和 memory。

action space 就是選擇什麼樣的工具來互動，如何設計interface，以及如何進行internal reasoning。
decision making可以透過planning來實現更復雜的決策。我們不只是直接產生單個動作，而是可以在腦子裡面模擬多個可能的動作並評估它們。就像下棋一樣，我可以預測如果我這樣走，對手會怎麼應對這樣的互動過程。

Agent最重要的兩個能力

一是獲取資訊的能力，無論是透過web還是透過RAG
二是自我驗證的能力，就是執行和測試。

General agent是個偽命題

因為很難真正產生價值。表面上看能幫你做很多事情，但首先系統穩定性是個問題。其次，如果要處理真正複雜的事務，僅靠API是不夠的，需要中間的agent來管理工作流程。而且你要解決的問題越寬泛，就越難讓它真正好用。需要人機互動才能真正發揮作用。
需求定義越明確，完成的成功率就越高；需求越abstract，就越需要interactive的步驟和人工介入。所以Replit對agent的思路是把它定位為協作夥伴，不是簡單地交付任務給它。

Agent 像把多個 LLM 當成 API 呼叫並組合成一個端到端的應用，但體驗前所未有：不穩定、需要持續迭代、需要使用者長時間等待。因此如何讓使用者能夠與Agent良好互動並獲得價值，需要複雜設計

產品化和做research是完全不同的事情。雖然在研究層面看起來不錯，但要做成使用者能用的產品，需要更多產品層面的思考。
agent與其他AI產品有很大的區別，首先是一個iterative(迭代)的過程，使用者需要耐心等待，這種產品形態是前所未有的。
與傳統軟體API相比，一個LLM相當於以前的一個API call，而現在的agent更像是把這些API組合成一個end to end的軟體。但前所未有的是可能需要等待十分鐘才能得到反饋。
agent還有一個特點是不穩定，它無法達到90%甚至80%、70%的準確率，更不用說傳統軟體追求的99.9%的穩定性。
面對這樣一個軟體，如何讓使用者能夠良好互動並獲得價值，需要複雜的設計。

怎麼定義multi agent system？為什麼我們需要它？

本質上是個inference time scaling的邏輯。我們最終希望在inference時用更多compute來獲得更好效果，增加agent數量就是scaling up的一種方式。不過現在base agent還不夠強，要等它達到一定水平後，multi agent的scaling才會真正發揮作用。就像團隊協作，如果大家都很菜，人越多越亂；但如果都夠強，兩個人可能比一個人效率快兩倍，三個人可能再快1.5倍。
multi agent其實有兩種不同定義：第一種是多個agent做同一件事，第二種是不同agent負責不同任務。比如MetaGPT這個專案，它模擬了一個完整的公司架構，有CEO、PM、程式設計師、reviewer，每個角色都有不同的prompt。在我們的設定裡，使用者和agent都是第一公民，這是很重要的理念。但這更像是一個 multi prompt（甚至有點像人格分裂的Agent），並不像一個 multi agent。

SWE Agent 和 Agent Computer Interface（ACI）：如果把interface design和agent design結合在一起，即使用GPT-4也應該能達到比現在更好的效果

軟體開發本質上是一個fundamentally interactive（根本上互動）的過程
人類使用的Visual Studio Code、vim或Emacs這些都是Human Computer Interface（HCI），我們投入大量時間去打磨這些工具。但這些工具可能並不適合agent。傳統上都是固定environment讓agent變得更好，比如Atari遊戲。
SWE Agent 提出 Agent Computer Interface（ACI），採用相反思路：固定一個簡單的ReAct agent，專注於打磨environment。最終會有一些co-design，但核心是如何設計最適合agent的interface。
和AutoGPT和baby AGI這類系統的差異？AutoGPT和baby AGI這類系統試圖把agent本身做得非常複雜，使用各種prompting方法、planning、reflection等技巧。但它們的environment其實很簡單，想做一個通用的agent，但效果不是特別好。SWE Agent的philosophy是，如果我們知道要做什麼task，就可以針對性地最佳化工具和environment，讓相對簡單的agent提升performance。
和Devin的差異？Devin是一個產品，SWE agent是研究專案。Devin是在標準environment下的複雜agent。SWE agent只是一個簡單的agent加上初步最佳化的interface。
Agent的效果並不完全依賴於模型的效果：如果把interface design和agent design結合在一起，即使用GPT-4也應該能達到更好的效果。
Language model就很像當年的GPU，最初只是個text generator，但大家用它做各種事情時發現了很多令人驚訝的能力。所以我覺得下一步應該把model和agent進行co-design，把agent的experience和資料反過來fine-tune model。

關於RAG

RAG為什麼重要？LLM-based 產品必須瞭解使用者的 codebase（上下文）

在現實工作中，無論你做什麼工作，都會面對一個巨大的codebase。所以第一，產品必須真正懂你的整個codebase，因此retrieval特別重要，因為這些程式碼不會出現在Foundation模型的訓練資料中。第二，產品feature必須能融入使用者的工作流。對於professional使用者來說，他們已經有了自己的工作方式，這就是為什麼程式碼補全這麼受歡迎，因為它對工作流的改變最小，用起來也很簡單。最重要的就是要在一個巨大的codebase裡面做一個好用的工具。

RAG為什麼難？

目前企業RAG系統準確率最多大概只有70%-80%，達不到過往軟體生產環境99.9%甚至更高的要求。RAG的難點是評估evaluation，甚至連標註都很難。關鍵是要先思考準確率本身的含義，就是top K的問題，可能是第一個結果準確，也可能是前十個結果都準確，這其實很像Google search的問題。Google search就是全世界最大的Retrieval系統。
指望文字embedding能在大量候選項中找出最佳匹配是非常難的，這不僅是embedding好壞的問題，而是對它的期望過高了。比如推薦系統，TikTok用使用者embedding去retrieve最接近的影片embedding，這種關聯是由使用者行為驗證的。Google的ranking也是基於使用者點選形成的系統。但常用的RAG方式是基於文字含義構建embedding，不是一個閉環系統。

長上下文long context能取代RAG嗎？

短期看不可能，因為long context太慢了。長期看呢？也很難，為什麼？首先你總是需要獲取使用者更多資訊的，但又不可能把所有資訊都輸入進去，所以需要RAG。再說了，就算你把所有資訊都作為上下文輸入進去，那也必須有一個選擇最相關內容的過程，那這個選擇過程其實就是Retrival，就是RAG。

關於研究

研究就是要minimize human factor，但是product本質上就是all about human。

Chain-of-Thought 和 Tree-of-Thought

Chain-of-Thought這篇paper的核心思想是，如果我們把next token prediction看作是一個system one的快速過程，那麼對於system two這種慢思考來說，它其實是一個對system one的控制。
Tree of thought的本質是透過tree search這樣的控制機制來control system one，而不是去替代它，而是去對系統施加控制

理解模型能力的2個維度：推進能力前沿push frontier、實現使用者價值help people

現有模型的強大能力並沒有真正傳遞到使用者手上。假設當前AI能力是60分，但大多數使用者可能只享受到20-30分的能力，有些甚至是零分。從產品角度，Replic工作是讓更多人能享受到這個60分的能力；從研究角度，則是要把這個60分提升到80分甚至100分。當上限提升後，普通使用者享受到的能力自然也會相應提升。
一個是push frontier，一個是help people實現價值。就像造紙局和用紙局的關係。造紙的人關注如何提升能力，用紙的人關注如何讓更多人用起來。不過現在確實還是一個research phase，絕對是research phase。

Life is more like text-based than video game

因為你要做的decision其實很多是open-ended的。比如說今天晚上做什麼，action space是open-ended的，並沒有一個類似遊戲裡的上下左右這樣的鍵盤去給你指引。你可以買張機票去另一個城市，或者看個電視，有無數種選擇。所以Language更接近這個事情的本質（姚順雨）

嘉賓介紹

姚順雨：普林斯頓大學博士，清華大學獲學士。他在Agent 領域發表了一系列非常有影響力的論文：從有奠基意義的 ReAct，Tree of Thoughts，到成為行業標準的基於 GitHub 的程式碼能力評估資料集 SWE-Bench，到首個開源AI 程式開發 agent 專案 SWE-agent，是絕對的天才研究員！https://ysymyth.github.io/
李珎：Replit
AI 團隊負責 AI Coding agent，ex- startup 創始人， ex- Googler。Replit 成立於 2016
年，是一個基於瀏覽器的 IDE，允許使用者在多種程式語言中編寫、執行和分享程式碼。2023 年$97.4M 的 B 輪，投資人包括
A16Z，Khosla Ventures、Coatue 等，估值 $1.16B https://www.linkedin.com/in/zhen-li-nexplain/
趙宇哲：Augment
任 AI 研究員，曾在Google Brain（現Google Deepmind）任 Staff Research
Engineer，主要研究方向是語言模型預訓練，指令訓練，神經檢索和檢索增強語言模型。Augment 成立於 2022
年，是一家為提供企業級全棧式 AI 程式設計助手的初創公司，由矽谷著名老牌風投 Sutter Hill Ventures
孵化（Snowflake也誕生於此），並在最新一輪獲得由Index Ventures、Lightspeed Venture Partners 和
Google 前 CEO Eric Schmidt 等領投的 2.5 億美金融資，估值接近 10 億美金

正文

注：本期錄製時間為2024年5月。但認知擴散的速度並沒有太快，業界的很多認知，到半年後的今天，似乎都遠沒趕上前沿研究半年前的認知。

00:00:45 – 00:02:07　

今年除了OpenAI的Solar驚起千層浪以外，同樣引起AI從業者尤其工程師極大關注的，想必就是僅透過一段演示影片就連續獲得兩輪融資，估值在半年內躥升到20億美元的Cognition
Labs的AI agent
Devin。作為宣稱的世界上第一位AI軟體工程師，它將如何重塑軟體開發甚至工程師這個職業？Devin是否能代表agent應用開發的方向？以及看到目前agent產品還有多少提升空間？　

這一期我們邀請到三位在各自領域都極具代表性的嘉賓，有來自去年剛晉升獨角獸的軟體開發雲平臺Rapid的AI
agent工程師，首個基於GitHub的程式碼能力評估資料集SWE-bench以及首個開源AI software agent專案Three
Agent的作者，還有剛官宣估值達到10億美元的企業級AI程式設計輔助公司Ogman的AI研究員。　

在兩個多小時的對話裡，我們從工程師個體、企業級需求以及學界研究等不同角度，深入探討了最近出現的程式設計輔助產品、試圖替代工程師的agent、基礎大模型的邊界，以及生成式AI對個人職業和社會的深遠影響。本期內容遠遠超出了對技術和產品的探討，希望能對正在收聽的你們有所啟發。enjoy。　

00:02:07 – 00:03:30　

Monica:　

大家好，歡迎來到Onboard，我是Monica。　

高寧:　

我是高寧。　

Monica:　

今天我們很難得在矽谷錄製這期線下的Onboard。這期節目的話題，我覺得集合了AI界最近最熱的幾個方向。一開始我們計劃討論AI
for coding這個話題。在幾個月前，大家關注更多是像Microsoft的Copilot這種auto
complete的形態。但是關注這個領域的朋友應該也注意到，前幾周Cognition Labs釋出了一個叫Devin的coding
agent，我覺得這一下子讓大家對LLM或AI如何改變整個軟體開發模式有了新的想象空間。　

高寧:　

每個階段都非常有代表性的產品和技術。　

Monica:　

對，所以我們今天請到了在這個領域非常有發言權的幾位嘉賓。剛才我們也喝了點小酒，氣氛已經到位了。　

00:03:31 – 00:06:07　

高寧:　

請三位嘉賓做個簡單的自我介紹，同時分享一下今年發現的最有意思的產品。我們從順雨開始吧。　

姚順雨:　

大家好，我叫姚順雨，是Princeton第五年的PhD，馬上畢業了，現在在舊金山的Sierra實習。說到有意思的產品，我想推薦Sierra，這是AI領域真正能落地的產品之一，主要做customer service business agent。我們已經有很多客戶了，最讓人興奮的是它真的work，而且能夠完全替代某些角色。　

Monica:　

Sierra確實是去年最受關注的典型大佬創業公司，是原來Salesforce的CEO創立的，主要為企業提供customer service chatbot服務。　

高寧:　

那除了Sierra之外，你今年發現最有意思的AI產品是什麼？　

姚順雨:　

我經常使用Perplexity，主要用它代替Google搜尋一些知識性的內容。　

Monica:　

不只是在國內，就算在國外，在AI圈子之外的人對Perplexity都不太熟悉。我現在除了查詢具體網站這類事實資訊用Google外，只要是帶問號的搜尋都會用Perplexity。

李珎:　

我現在使用Perplexity的比例已經達到30%了。　

Monica:　

順雨，你能介紹一下是如何進入AI研究領域的嗎？　

姚順雨:　

我本科時就開始做科研，最初是做computer vision，後來覺得想要研究language，就轉向了這個方向。　

Monica:　

順雨很謙虛，他在agent相關的工作在整個領域都有很強的標誌性意義，一會兒我們會請他詳細介紹。　

00:06:07 – 00:06:44　

趙宇哲:　

大家好，我叫趙宇哲，我現在在一家做full stack AI for code的AI創業公司工作。之前我在Google Research的Google Brain團隊，主要做language research的工作。　

Monica:　

對，這家公司也是某大佬創業的，我們今天集齊了各個大佬創業公司。這家公司是某特別愛孵化的大佬基金孵化的一個公司。　

00:06:45 – 00:09:56　

高寧:　

能說說你是怎麼進入AI這個領域的嗎？　

趙宇哲:　

我進入這個領域運氣特別好。我PhD期間做的是比較理論的研究，當時覺得這些理論研究缺乏實際意義和解釋性。畢業時我在vision和language兩個方向之間選擇，因為在PhD期間做過一些vision的小專案，但最終選擇了language方向，因為language與intelligence更接近，而vision更偏向perception（感知）。　

五年前我加入了Google，正好是發明BERT的團隊。經歷了BERT前後NLP研究的翻天覆地變化，這對我來說是非常好的學習機會。最初我做了很多BERT的pre-training相關工作，後來參與了LaMDA專案。LaMDA是生成式AI的開山鼻祖，在此之前沒人認為生成式語言模型可以用來做chatbot。之後我們做了第一批instruction tuning的工作，發表了相關論文。　

我個人比較感興趣的研究方向是retrieval，我認為retrieval對language model來說是一個很重要的capability，這也是我現在在新公司正在做的事情。除此之外，我也參與了一些產品落地的工作。　

說到AI產品，我覺得影片生成很有意思，雖然我主要是看demo。日常使用最多的還是GPT，特別是用GPT-4來處理一些影像相關的任務。　

00:09:57 – 00:10:23　

高寧:　

好的，李珎。　

Monica:　

大家好。　

李珎:　

大家好，我叫李珎，目前在一家B輪創業公司工作。我們的產品不僅僅是一個IDE，它最初是從一個multiplayer online IDE開始的，現在已經有兩千多萬用戶。　

00:10:23 – 00:11:33　

大部分人其實是在學習程式設計，或者說不太會寫程式碼的，這些人需要一些沒那麼專業的programmer的幫助。我們的vision是"Next billion software creator"。　

趙宇哲:　

這個世界上會寫程式的人只有三四千萬，是人類人口的極小部分。　

李珎:　

對，我們經常聽到"我有一個idea，但是缺一個程式設計師"。　

趙宇哲:　

有idea的人是很多的。　

李珎:　

但是我們的vision其實就是想讓所有人都成為software
creator，你有一個idea就可以create
software。這個vision在七年前就有了，所以第一步是做一個雲IDE，讓大家可以在手機上、在任何地方寫程式碼，然後有一些輔助配置環境的工具。現在加入了更多AI的部分，這讓我們離實現這個vision會更近很多。　

00:11:33 – 00:12:58　

這是我們公司，我是六個月前來到這裡的。我在北航本科畢業後直接去了Google，在那裡工作了五年。　

趙宇哲:　

在Google主要是做推薦系統？　

李珎:　

對，做Google

News，我們叫Discover，其實也是news。那時候我一直在做AI，特別是推薦系統，這是上一波AI最賺錢的場景和產品。做了五年後，我覺得基本已經卷到頭了，因為大家都在往上加各種各樣的奇技淫巧。有很多feature
engineering，然後在模型裡面加一些奇怪的結構，比如attention、transformer這些。這些方式it
worth，但已經有種捲到頭的感覺了。真正能帶來正向revenue的突破不多，所以我後來就出來了，去TikTok做了一年推薦，想看看他們在幹什麼。　

00:12:58 – 00:15:42　

Monica:　

你不是已經覺得捲到頭了嗎？怎麼又去了一個更卷的地方？　

李珎:　

我當時覺得Google的工作方式可能不太適合我，想看看中國公司是怎麼樣的，因為我想創業。創業就會面臨一個問題：是在美國創業還是在中國創業？所以我想給自己一年時間去回答這個問題，就去了TikTok。待了一年拿到綠卡後我就出來創業了，因為我覺得自己做才能真正學到東西。　

我做了一個Biotech領域的Copilot，就是給biotech的人做copilot。從前年到去年九月份，那時ChatGPT還沒出來。我們當時有個very
big ambition，想做GPT的App Store。後來我發現AI在coding領域能產生更大的價值，就開始尋找這個方向的機會。　

Monica:　

所以你當時去的這家公司已經做了好幾年了，是在一個什麼階段？　

李珎:　

他們已經做了六七年，有很好的產品市場契合度，有大量使用者非常喜歡這個產品，但需要開始盈利了。我加入的時候正好是公司開始引入AI的早期階段，他們剛從Google
Research挖來了我的老闆，他之前在做PaLM和其他coding model。公司剛開始加入ghost
writer等AI相關feature，是很早期的階段，然後後面又做了一系列的提升。　

00:15:44 – 00:16:59　

高寧:　

你今年發現的最有意思的AI產品是哪個？　

李珎:　

因為我想要Empower更多人去build software，有一個產品特別有意思。是一家叫Buildspace的公司，是a16z投資的。它更像是一個學校，主要是幫助更多人學習怎麼做產品。他們今年做了一個新產品，是一個chatbot。你可以跟它說你的idea，它要麼幫你生成程式碼，要麼幫你對接到能幫到你的人。比如說，如果你是YouTuber，你跟它說我想要給我的影片生成更好的封面，它就會幫你找到大概十個正在做YouTube影片封面生成的公司或者個人。　

00:16:59 – 00:17:45　

這個產品本質上是在把人和人connect起來，這是一件很好的事情，是幫助你去完成目標。你並不需要自己會做所有的事情，只要有人能幫你完成就可以。他之前是做crypto的，現在在Web3上。　

觀眾:　

本質上這是一個非常有意思的公司。　

李珎:　

我非常喜歡這個founder，他是一個特別優秀的創業者。他很喜歡sharing他的knowledge。我在他那裡學到的創業知識，可能比我自己做創業六個月學到的還多，而在他那裡只花了幾個星期的時間。　

00:17:46 – 00:20:24　

Monica:　

我覺得這個挺有意思的，讓我想到HeyGen。他們之前分享過早期的一個growth

hack。這是一家華人創業公司，前段時間拿到了Benchmark的4000萬美金投資。他們是幫你自動生成類似真人的avatar。最早他們把服務放到Fiverr這個freelancer平臺上，那裡真人影片服務通常要收費幾十到一百美金一小時。他們就把AI生成的影片標價很低，好像就五美金左右。這個價格差太大了，一下子就開啟市場了。我覺得以後有了這些AI技術和產品，真的可以幫你端到端完成工作，到時候在這些網站上，你可能都分不清哪些是AI、哪些是真人做的了。　

李珎:　

我是透過Buildspace認識到這些的。Buildspace的slogan是six
weeks to work on your
dream。它會定期組織batch活動，六週時間讓你去實現自己的夢想。你可以做software、APP，甚至像我當時那樣畫漫畫，也可以寫歌。他們不教你怎麼寫程式碼，而是教你怎麼讓別人關注你的產品，怎麼去launch。我參加過兩次，後來透過Buildspace的founder Farza和Anthropic CEO的fire side chat認識了Anthropic，這就是我現在在這裡的原因。　

00:20:24 – 00:20:41　

趙宇哲:　

非常酷的。　

Monica:　

對，很棒。剛才李珎講到了Replit，這家成立五六年的公司現在融資已經超過了兩億美金。　

高寧: 　

是個獨角獸了。　

00:20:41 – 00:21:37　

Monica:　

對，朱老師說得對。在這波AI浪潮中，Replit在美國一直處於聚光燈之下。我覺得他們算是前行者，從兩三年前就開始加入很多AI功能，迭代也非常快。我專門去看了Replit的部落格，他們分享了很多關於AI的思考。去年年中他們就發表了一篇部落格，講AI will redefine every single app feature。他們釋出的這些AI功能讓我們發現，AI在IDE開發工具裡的應用遠不止Copilot那樣的功能。李珎，你能給大家介紹一下Replit的AI產品都有哪些？它背後的主線邏輯是怎樣的？　

00:21:38 – 00:22:02　

趙宇哲:　

我們的主線邏輯很簡單，我們想做兩件事。　

李珎:　

第一件事是Next billion software creator，讓更多的人可以去create software。第二個是from idea to software，就是把你的想法轉變成一個能夠幫你profit的軟體。　

00:22:02 – 00:22:32　

我們所有的產品都是圍繞著這個平臺，這是一個雲端的程式碼平臺，它支援multiplayer功能。　

趙宇哲:　

使用者可以在雲端編寫程式碼。　

李珎:　

這個multiplayer功能實際上給我們帶來了很多使用者，特別是教育領域的使用者。比如老師可以即時看到學生在寫什麼程式碼，在整個debug過程中，每一個步驟都能在multiplayer環境下被看到。　

00:22:32 – 00:23:56　

觀眾:　

是code completion，就是我們當時的ghost writer。　

李珎:　

在你寫程式碼的時候，它會出現一堆ghost writer，也就是ghost text。你可以接受它給你的補全建議，這個其實跟GitHub Copilot和大量的補全產品非常像。這是一個很直觀的能夠幫助程式設計師寫程式碼的產品，也是現在大家覺得最有用的產品之一。　

同時我們會有一個AI

chat，這是個很常見的產品。在我們的IDE裡，左邊是程式碼，右邊就是chat。你可以用它做很多事情，比如幫你生成程式碼，然後直接一鍵貼到IDE裡面。或者當某個地方有紅線提示LSP錯誤或語法錯誤時，上面會有debug按鈕，點選後它會在chat裡顯示錯誤原因，並告訴你如何修復。　

00:23:56 – 00:25:34　

我們的Software開發流程是這樣的：從寫程式碼開始，然後debug執行，我們最大的優勢是把所有環境都放在了雲端。　

趙宇哲:　

雲端確實解決了很多問題。　

李珎:　

是的，程式設計師都知道配環境很麻煩。Replit透過雲端環境和standardize的setup指令碼解決了這個問題，這樣就不存在本地Python

dependencies這樣的問題了。到最後一步deployment時，你完成軟體後希望它成為一個真的網站供人訪問。我們其實做了一件事，就是把整個軟體開發週期裡面要做的事情都整合在了一個平臺裡面，是一個all
in one的platform。　

現在市場上有很多公司分別在做code completion、deployment等單項功能。把這些整合在一起有好有壞：壞處是我們一個公司要做好幾家公司的事情，好處是可以把整體體驗最佳化得非常好。　

00:25:34 – 00:26:44　

我們釋出了很多功能，包括ghost
writer和chat。今年初我們做了一個很大的改動就是AI for
All。之前AI功能只對付費使用者開放，現在我們把這個功能開放給了所有人。你現在上Replit，不需要有賬號就可以使用code
completion和AI chat。這對我們來說其實是在花錢的事情，因為我們要支付這些token給免費使用者。　

高寧:　

使用者現在不需要註冊就可以體驗這些AI功能了嗎？　

李珎:　

對，不需要註冊就可以用。這是我們的vision，因為我們想要讓更多人能夠用AI去create software。這也是我加入後做的比較大的第一批工作之一。　

00:26:46 – 00:28:57　

這其實也引出了我們自己的一些工作。我們訓練了自己的code completion模型，包括上個月釋出的code pair模型，因為我們要支援更多人使用AI。我們有幾百萬使用者需要服務，這對模型和後端系統提出了很多特殊要求。　

高寧:　

我理解就是需要一個更小的模型，用更低成本的方式來服務更大規模的使用者，對嗎？　

李珎:　

對，有兩個出發點。第一個就像你說的，模型必須要小，因為這樣才快，而且要便宜。第二個原因是我們要利用自己的資料來提升模型效能。　

Monica:　

我看到最近釋出的1.5版本code模型是3B引數量。　

李珎:　

對，我們現在有3B引數量的code
completion模型，已經放在Hugging Face上可以下載。另外，我們最近還發布了一個code
repair模型，它不是做補全，而是幫你修復程式碼錯誤的。這個模型既可以讓agent用來修復程式碼中的bug，使用者也可以直接獲得修復建議。相比呼叫更大的模型，我們用更小更快的方式來提供建議，這樣就能更頻繁地服務使用者。　

00:28:57 – 00:30:43　

高寧:　

現在我們看到專門針對coding的模型非常多，非常卷。不管是大模型公司還是像magic這樣的startup，包括雲廠商都在開發自己的coding model。我想請教大家，我們是否真的需要一個專門的coding model？它的能力是否真的可能超越現在的通用基礎模型？

Monica:　

這涉及兩個問題：一是專門的coding模型在效果上能否超越最好的通用基礎模型，二是我們現在有這麼多專門的coding model，是純粹出於效率的考量，還是有其他因素在裡面？　

李珎:　

從Replit的角度來說，我們的目標是要Power next billion Creator。雖然我們只訓練了3B的模型，但評估顯示其效能比Code Llama 7B更好。因為我們的使用者主要是citizen developer，所以我們更關注效率和成本。我們的主要考量是如何降低為使用者提供免費服務的成本，同時充分利用我們自己的資料。　

00:30:43 – 00:31:01　

Monica:　

關於podcast討論的這個話題，如果大家使用公開抓取的coding資料，大機率這些資料的質量不如企業內部的程式碼那麼高，因為很多開原始碼可能存在garbage in， garbage out的問題。　

00:31:01 – 00:31:46　

趙宇哲:　

我覺得這個問題很好，我們的promise是我們絕對不會在意這一點。這就是做enterprise業務的特點。我可以看到做enterprise和非enterprise業務有很大的區別。　

比如說data

engine這個領域，為什麼要用Snowflake而不用Azure或者GCP的服務？有一部分原因是trust。如果你是面向企業的企業，對這個特別在意。當然也不是所有企業都這樣，特別小的企業可能無所謂，但是到了一定規模，大家對這個問題特別清楚，會對security有顧慮，這讓體驗很不一樣。　

00:31:46 – 00:34:04　

Monica:　

我在想，在這個領域是否不存在所謂的資料飛輪效應？因為客戶資料都無法使用，各個model的資料似乎都沒有什麼優勢。　

趙宇哲:　

我並不完全同意。公司可以獲取一些帶license的資料，而且GitHub本身的資料已經很豐富。目前標準做法是收集GitHub的各種版本進行deduplicate。但這裡有個關鍵問題是license，在GitHub上clone程式碼並不意味著license允許你用於訓練。如果要認真做enterprise服務，這存在legal風險。比如Microsoft為了獲得trust，會向GitHub使用者承諾處理所有legal問題。　

Monica:　

那這樣的話，如果GitHub也嚴格遵守license，是不是意味著他們在資料上也不會比別人有優勢？　

趙宇哲:　

是的。而且Copilot現在是用OpenAI的API，他們之間的關係並不透明。不過，GitHub確實提供了enterprise服務，如果企業需要fine tuning，他們可以提供fine tuning服務和私有化部署。　

Monica:　

所以最終企業的需求是希望model只benefit自己的資料？　

趙宇哲:　

對，這會是一個重要的service方向。　

00:34:04 – 00:35:29　

Monica:　

我對這個領域還不是很瞭解，想請教一下，如果拿最強大的通用基礎模型，比如GPT-4這樣的模型，與專業的coding模型相比，它們的程式設計能力是怎樣的關係呢？

趙宇哲:　

這是個很好的問題。當初不只有專門做coding的模型，還有專門做數學證明的模型。這種專門化模型出現有幾個原因：　

一方面是學術界的research需求，因為程式碼這個language不是natural language，作為natural language研究的人原本不研究code。但當T5這些模型出現後，學術界就開始專門研究如何用這些模型去做code task，包括數學和邏輯證明的模型。　

另一個重要原因是cost考慮，因為雖然code跟natural language有關係，但關聯度並不那麼高。如果只是想訓練一個專注於code的模型，可能專門訓練會更好。比如國內的DeepSeek就是一個非常優秀的程式碼模型。　

Monica:　

而且DeepSeek還是開源的。　

00:35:30 – 00:36:50　

趙宇哲:　

還是開源的。然後在程式碼訓練上，有一個很有意思的預訓練方法叫fillingthemiddle。它不是傳統的從上到下、從左到右的訓練方式，而是專注於上下文中間的內容。這個任務特別適合做程式碼補全。OpenAI的論文也提到了這一點，說明這種filling the middle的訓練方式是很重要的。　

DeepSeek就採用了這種方法，而且他們還在程式碼訓練上做了一些創新，比如repo level的預訓練。你想啊，對於普通文字來說，不同文字之間是隨機組合的，因為它們本來就沒什麼關係。但是對程式碼來說就不一樣了，因為在同一個程式碼庫裡，不同的檔案之間是有關聯的。DeepSeek就利用這種檔案之間的關係來構造訓練資料，這樣就能得到很好的長文字訓練資料。　

00:36:51 – 00:37:10　

姚順雨:　

我們需要對這些內容進行排序嗎？　

趙宇哲:　

對，這是在做錯誤處理。在code上實現是很容易的。我覺得在natural language中雖然不是不可以，你可以用search來排序文字，但code就容易得多，因為code的結構比較清晰。　

李珎:　

結構比較清晰。　

趙宇哲:　

對，正是因為結構比較清晰，所以在code上可以更容易地實現這些功能。　

00:37:10 – 00:37:36　

姚順雨:　

是不是tokenization也不太一樣？　

趙宇哲:　

理論上可以用相同的tokenization，但實際上確實會不一樣。即使用相同的訓練策略，distribution也會不一樣。不過之前的表現確實很好。　

GPT-4的程式碼能力非常強。對於general model來說，你需要專門分配很大的預算來訓練程式碼能力，因為程式碼相關的能力需要很大的模型capacity。　

00:37:36 – 00:38:33　

最近釋出的Llama 3在程式碼方面表現很強。從能力上來說，專門的code model不一定比general model強，但它的模型體積一定更小。

Monica:　

現在這些model的coding能力相比是怎麼樣的？　

趙宇哲:　

DeepSeek很強，然後Llama和GPT都很厲害。但這要看具體task，GPT不是專門做程式碼補全的模型。專門的程式碼補全模型在這方面確實厲害。但在human evaluation時，有一個特別的task，就是decode任務。

高寧:　

刷題的那個。　

趙宇哲:　

對，就是很簡單的standalone任務，給你一個單獨的任務，要求實現某個演算法，GPT-4在這方面表現很強。　

00:38:33 – 00:40:00　

Monica:　

去年年初我們和Google PaLM的作者之一討論時就提到，大家發現加入coding資料的重要性已經成為業界共識。如果那些做Foundation model的公司目標是AGI，他們肯定會花大價錢，儘可能獲取所有能拿到的最高質量coding資料。　

趙宇哲:　

完全同意這個AGI的觀點。有人認為如果是一個很強的程式設計師能寫程式碼就是AGI的體現，因為優秀的程式設計師可以實現很多功能。這就是Magic
Dev
Def公司的主張，這是很有邏輯的。這也解釋了為什麼大家都關心MMLU能力，還有人專門訓練模型做奧數，因為這些都與reasoning能力關係最緊密。　

李珎:　

如果我們認為當前的瓶頸是reasoning能力，那就應該給模型提供更多的reasoning資料。而現在大家能想到的最強的reasoning資料就是程式碼。

00:40:00 – 00:40:56　

高寧:　

我知道有一家startup，他們專門為LLM公司提供訓練用的程式碼資料。這些LLM公司會提出具體需求，然後這家startup負責招聘專業程式設計師來編寫高質量的程式碼資料，用於預訓練。這個模式有點像Scale AI。　

李珎:　

他們是透過購買這些資料來獲得收入的。　

趙宇哲:　

我看到很多程式碼的instruction資料集。　

高寧:　

是的，GitHub上的程式碼資料質量只能說是中庸水平，現在確實需要更專業、更高質量的程式碼資料集。　

Monica:　

這說明我們進入了資料升級階段，要產生高質量的資料，成本也在不斷提高。　

00:40:56 – 00:43:29　

我想了解一下，你剛才提到為了讓模型有更好的程式碼補全能力，有很多專門的訓練方式。這些訓練方式能用於Foundation model的訓練嗎？　

趙宇哲:　

是可以的。這種上下文預測的方式並不新，T5就是這麼做的。我之前做過一個叫dialogue

predicting的工作，目標是透過已知對話的上下文來預測中間的話語內容。這個task雖然有多種變體，但並不是很popular，主要是因為效率問題。在decoder-only
model中，training時你只是讓它predict下一個token。這裡有個概念叫cost of masking，就是在predict
token時會使用當前所有可見的token。如果做filling the middle training，dependency關係就會改變，之前的計算就不能被重用了。　

姚順雨:　

比如你想用第一句和第三句來預測第二句，然後又要用第二句和第四句來預測第三句，這樣很多計算就沒法reuse。　

趙宇哲:　

對，雖然付出同樣的計算量，但效率會低很多。　

Monica:　

這讓我想到最近大家經常討論的AI能否幫我們解決複雜的學術問題，比如數學定理證明。本質上不就是已知條件和結論，需要證明中間過程嗎？這個technique能用在這方面嗎？　

趙宇哲:　

有這個可能性，但做reasoning時不一定要用filling the middle的方式。你可以用其他prompt方式，把結論直接放到prompt前面告訴模型這是目標。這樣也是可以work的。　

00:43:29 – 00:45:26　

Monica:　

姚順雨，你怎麼看？就前段時間Magic Dev一上來就融了上億美金，號稱要做最最牛逼的coding模型，說這是通往AGI的捷徑。　

姚順雨:　

我認為coding資料對訓練Foundation Model非常重要，這個毫無疑問。但僅靠coding能否實現AGI這點還有待商榷。natural language和programming language是有本質區別的。programming language更結構化，而natural language更noisy，有更多的pragmatic結構。對於人來說，比如要創業，就需要同時掌握programming language和natural language。我覺得高質量的coding資料eventually會很重要。　

Monica:　

你覺得eventually最強的Foundation Model的coding能力會強於專門的coding model嗎？　

姚順雨:　

我覺得是的，因為這不是一個fair comparison。Foundation Model規模更大，而且在其他資料上訓練後整體推理能力會更強。但這要取決於具體application，比如Copilot這樣的應用就需要小模型。　

李珎:　

討論最強模型的話，最強的模型一定是把所有資料都用上的。不會出現一個僅僅因為用了更多coding資料就能超越最強模型的情況。

00:45:27 – 00:46:42　

Monica:　

讓我們聊聊model之後的產品話題。o1選擇了一條比較難的路徑，就是完全構建一個自己的IDE。我們看到很多像Copilot這樣的產品採用外掛形式，我很好奇你們是怎麼思考這個產品形態的，以及不同產品形態對AI產品設計會有什麼影響？　

李珎:　

說實話，這個產品的邏輯我一開始也不太懂，我覺得很多人可能也看不懂。雖然表面上看起來就是一個IDE，但我們選擇這種形式是有原因的。最大的好處是可以降低使用者的上手成本，使用者不需要去操心下載VS

Code、安裝Replit外掛、學習如何使用Azure部署等這些複雜的步驟。我們把這些功能都以按鈕的形式整合起來，讓使用者可以一鍵設定環境。這也是我們在2022年之前能夠吸引使用者的一個重要原因。　

00:46:42 – 00:49:45　

我在考慮加入時就在思考，如果AGI真的來臨，一個超強的AGI會需要什麼？它可能有很強的大腦，但如果要替代現有的軟體開發過程，它需要各種工具，就像手和腳一樣。它需要一個寫程式碼的地方，需要能測試、部署，然後驗證部署結果，看到自己構建的網站效果並進行反饋迴圈。最後還要把產品上線，接入支付功能，成為一個真正可以持續迭代的產品。　

這些工具現在都在本地，但最終會變成雲端API供AGI使用。實際上，我們（Replit）是在打造一個給AGI寫程式碼和製作產品的sandbox，只是現在的使用者還是人。即使OpenAI開發出超強的模型，它也需要像我們一樣構建雲平臺，讓AGI能夠編寫、執行、debug程式碼，處理編譯問題和LSP，處理各種錯誤和不同的程式語言。如果一個公司之前幾年的工作能被輕易取代，那這個公司就沒有什麼價值。　

姚順雨:　

你提到未來AI可能會使用你們的工具，它是透過API接入還是使用UI介面？　

李珎:　

我們內部已經有了這些API，包括獲取30多種程式語言的編譯結果、LSP結果、部署執行測試等每一個步驟。就是透過function calling，告訴AI這些工具可以用，它就能直接呼叫這些API。　

00:49:46 – 00:51:35　

Monica:　

我在思考未來的開發環境選擇問題。現在我們需要在GitHub和Replit之間做選擇，但我認為未來決策可能會往更高層面發展。就像訂外賣，現在我們要在Uber eats和其他平臺之間選擇，但未來可能我只需要表達我要訂外賣這個需求，由AI模型來決定使用哪個平臺。同樣，開發者可能只需要表達我要寫程式碼，由AI來決定在哪個平臺上實現。　

李珎:　

這要看使用者型別。如果是程式設計小白，確實需要很high level的抽象，比如幫我做個程式，演唱會有票就給我發簡訊。但對於專業程式設計師，就像F1賽車手一樣，他們會更具體地描述需求，比如要build一個iOS app，需要接入stripe，需要這個功能那個功能。　

高寧:　

當需求明確時，就需要specific的model和function。RAG技術更適合小白使用者，也就是citizen developer。而宇哲他們公司做的是外掛形態的產品，專門服務於企業裡的專業程式設計師。這與GitHub copilot等產品相比有其獨特的定位。　

00:51:35 – 00:54:09　

產品的一個不一樣的地方和這裡面的一些難點在哪裡？　

趙宇哲:　

我們公司的value proposition是希望我們的產品是真正懂你的codebase的。這個設計是針對已經有一個極大的codebase存在的場景。這和現在主流的那些benchmark很不一樣，因為那些更像是面試題，甚至比面試題還要簡單的考試題。　

在現實工作中，無論你做什麼工作，都會面對一個巨大的codebase。比如做財務的會面對整個公司的financial系統，做程式設計師的會面對整個公司的程式碼。有趣的是，世界上擁有最大codebase的其實不是tech公司，而是銀行。　

無常按：剛好和最近的一個思考不謀而合了。不存在從零到一的創作，今天人類幾乎所有創作都是有上下文的。所以AI產品必須要了解使用者場景的上下文，必須RAG（也許還應該有其他方式）。　

我們面臨兩個主要挑戰：　

第一，產品必須真正懂你的整個codebase，所以retrieval特別重要，因為這些程式碼不會出現在Foundation模型的訓練資料中。　

第二，產品feature必須能融入使用者的工作流。對於professional使用者來說，他們已經有了自己的工作方式，這就是為什麼程式碼補全這麼受歡迎，因為它對工作流的改變最小，用起來也很簡單。

所以對我們公司來說，最重要的就是要在一個巨大的codebase裡面做一個好用的工具。

00:54:09 – 00:55:26　

Monica:　

我很好奇，在你們這麼多AI feature中，哪個是最受歡迎的？　

李珎:　

最常用的顯然是code completion功能。不過最近增長最快的是deployment功能，它可以幫助使用者將產品網站或專案正式上線。這個功能增長非常快，而且能很好地monetize，因為使用者都願意為此付費。我們最近在deployment上也在加入很多AI feature。總的來說，對所有程式設計工作而言，最常用的是code completion和聊天功能。

實際上，我們的AI功能遍佈整個平臺的各個角落。這些功能背後都是同一套系統，它們之間可以相互共享context。

00:55:26 – 00:57:09　

Monica:　

我很好奇，剛才宇哲提到要滿足企業級需求，能否跟大家解釋一下，如何構建一個更懂企業自身需求的solution？是RAG吧？　

趙宇哲:　

對，就是RAG。這是很多做企業級AI的公司都需要面對的問題。RAG有很多種實現方法和變化，不同的任務需要不同的方案。　

RAG的核心功能是讓Foundation model能夠在私有資料的context下完成任務。在不進行fine tuning的情況下，唯一的方法就是把相關資訊放在模型的context裡。對於不同的task，你需要看不同的context，這一點在context特別多的時候尤為重要。企業相比個人通常會有更大的context，包括自己的codebase和各種資料。因為context量太大，你沒辦法把所有內容都放在language
model的context裡，所以需要使用retrieval技術來挑選相關的內容。　

00:57:09 – 00:58:39　

那這邊關於retrieval的實現，需要考慮在什麼時候執行，以及執行的頻率。　

李珎:　

需要做多次執行。　

趙宇哲:　

在選擇retrieval的具體實現時，你可以使用關係型資料庫，也可以選擇向量資料庫，這些都是可選的方案。　

Monica:　

雖然大家經常談論retrieval這個概念，但實際上並沒有一個統一的最佳實踐。針對不同的場景，現在的解決方案都是不同的。　

趙宇哲:　

確實，有些初創公司想要做通用解決方案。我之前做retrieval研究時也在探索這個方向，希望開發一個通用的retrieval模型。但就目前來說，在自然語言問答這個任務上，市面上的模型確實做得都很好，但問題是並不是所有場景都是問答任務，所以這不是一個萬能的解決方案。

高寧:　

在你現在做程式碼相關的企業場景中，特別是RAG這塊，你覺得最大的挑戰或者跟之前general場景最不一樣的地方在哪裡？　

趙宇哲:　

從技術角度來說其實沒有特別大的挑戰，但我覺得比較有意思的挑戰是evaluation。這個問題不僅存在於程式碼場景，對所有初創公司來說，價值評估和技術排名都是很困難的事情。　

00:58:39 – 00:59:34　

這適用於所有公司。RAG更難的地方在於它本身很難被value，因為它不是終端的。比如我做程式碼質量評估時，直接看程式碼好不好就行。但是當涉及到應該retrieve哪個文件來改進程式碼時，這就多了一層複雜度，所以retrieve的evaluation本身就更難做。這也是為什麼學術性的evaluation很難做。　

李珎:　

對，甚至連標註都很難。給你一個包含一千個檔案的code base和一個問題，讓你判斷哪兩個檔案最相關，這種標註是很難的。這不像其他資料標註任務，普通大學生就能完成，這個真的very hard。　

00:59:35 – 01:00:34　

姚順雨:　

對，你會用streaming來實現這個功能。　

Monica:　

我最近參加了Google Cloud的活動，看到很多企業使用者都在使用RAG技術。雖然每個企業都有自己的實現思路，但當討論到準確率時，發現一個問題：這些系統的準確率大多隻有70%-80%，這樣的準確率在生產環境中是很難部署的。我很好奇，提高準確率的難點究竟在哪裡？　

趙宇哲:　

這個問題的關鍵是要先思考準確率本身的含義，這實際上是一個evaluation的問題。　

李珎:　

就是top K的問題，可能是第一個結果準確，也可能是前十個結果都準確，這其實很像Google search的問題。　

趙宇哲:　

對，Google search就是全世界最大的Retrieval系統。

無常按：Google search就是全世界最大的 Retrieval 系統。一個簡單到容易被忽略的事實。　

01:00:35 – 01:04:01　

Monica:　

如果企業需要達到90%、95%或99%的準確率才能在生產環境中使用，那我們與這個目標之間的差距在哪裡？而且我們如何去衡量這些準確率呢？　

趙宇哲:　

我覺得要反過來看這個問題。針對特定任務，gap不一定很大。現在Foundation model比傳統NLP solution強的地方在於通用性，但retrieval不是一個做什麼都行的通用工具。它的定義很模糊，在不同任務中表現差異很大。　

Monica:　

我最近參加了一個developer meetup，看到Voyage公司在做embedding model，這是RAG架構中的一個重要環節。他們針對法律、程式碼等不同場景開發專門的embedding model。　

李珎:　

你指望一個embedding能在大量候選項中找出最佳匹配是非常難的，這不僅是embedding好壞的問題，而是對它的期望過高了。比如推薦系統，TikTok用使用者embedding去retrieve最接近的影片embedding，這種關聯是由使用者行為驗證的。Google的ranking也是基於使用者點選形成的系統。但常用的RAG方式是基於文字含義構建embedding，不是一個閉環系統。

無常按：在推薦系統裡，TikTok用使用者embedding去retrieve最接近的影片embedding，這種關聯是由使用者行為驗證的。Google的ranking也是基於使用者點選形成的系統——這都是閉環的。但常用的RAG方式是基於文字含義構建embedding，不是一個閉環系統。　

姚順雨:　

這是一個training task，是在arbitrary的任務上訓練的。　

高寧:　

那麼在現在還缺乏最佳實踐的情況下，給企業客戶的產品是不是需要根據每個具體任務去交付，這會是一個非標準的過程？　

01:04:01 – 01:05:46　

趙宇哲:　

程式碼檢索有個很好的特點，比如說做法律領域的應用可能會有侷限性，但在程式碼領域，不同企業使用的programming

language是相同的。不同的task可能需要不同的retrieval，但如果這個task做得好，即使是不同人寫的Java程式碼，用不同的library和design
pattern，基礎語言都是Java，所以這是可以transfer的。　

Monica:　

那麼不通用的部分是什麼呢？　

趙宇哲:　

不通用的是自然語言模型直接遷移使用的效果可能不理想。比如說做程式碼檢索的retrieval用來處理其他程式碼問題，效果可能好也可能不好。對於不同客戶，我們會提供相同的服務，這也是很有意思的一點。這讓我想到enterprise
AI在這一波LLM之前，投入了很大精力做AutoML，當時的目標就是要服務所有公司。　

01:05:46 – 01:07:04　

說到machine learning，最難的是training。AutoML說可以自動幫你清理model，你只要有資料就好了。但實際發現這個solution並沒有那麼general。　

不過code本身通用性很好，雖然對不同test你可能需要專門engineer一個solution，但這個solution是可以被zero-shot的。　

李珎:　

因為程式碼這件事兒，大家做法都一樣，都是在寫程式碼。大家大機率都用相同的language，都在相似的環境下面。這和Google之前想target的場景很不一樣。程式設計師的世界相對來說是比較同質的。　

姚順雨:　

對，就是在互相抄，大家都在Google上retro一下。　

Monica:　

但是對於一些大公司來說，因為他們有一些legacy的東西，情況會不太一樣。　

趙宇哲:　

這就是為什麼RAG的技術是一樣的，我們把不同的內容放在context裡面，就可以得到不同的結果。　

01:07:04 – 01:08:47　

Monica:　

我們一直在討論RAG，是應該靠更好的RAG還是更強的context window來解決問題？比如現在的Gemini有ten million的context window，可能還會更長，你覺得未來會怎麼發展？　

趙宇哲:　

如果說long context會取代RAG，長期maybe，但短期絕對不可能。我們測過，所有模型在處理long context時都很慢，不需要一百萬，只要十幾萬token就需要十秒幾十秒，特別慢對吧。不過，當我有這個model的時候，我可以把它轉成一個RAG solution。雖然沒那麼容易，但是非常good。　

姚順雨:　

大機率只有一小部分。　

趙宇哲:　

對，大概只有一小部分。而且如果這個model能讀一百萬token並且很強，那它大機率知道這一百萬token裡面哪些部分是有用的。所以這能被轉化成一個RAG solution，而且我有這個solution一定比你快。　

01:08:48 – 01:09:38　

李珎:　

而且我覺得從長期來看，有些部分是沒有辦法被代替的。　

趙宇哲:　

比如說，你在寫程式的時候……　

李珎:　

對，比如說你需要參考document。以numpy為例，它有非常多版本的document，你始終需要找到正確版本的document來使用，不可能把所有numpy的document都feed進去。這本質上是一個混合了搜尋和retrieval的問題，資訊可能來自底層程式碼庫，也可能來自外部網站，但始終需要從外界獲取資訊。你不可能把全世界所有的document都輸入進去，必須有一個選擇的過程，這個選擇過程就是retrieval，就是RAG。

無常按：長上下文能取代RAG嗎？短期看不可能，因為太慢了。長期看呢？也很難，為什麼？首先你總是需要獲取使用者更多資訊的，你不可能把所有資訊都輸入進去，所以需要RAG。再說了，就算你把所有資訊都作為上下文輸入進去，那也必須有一個選項的過程，這個選擇過程就是Retrival，就是RAG　

01:09:39 – 01:13:41　

Monica:　

剛才宇哲講到evaluation這個問題，這確實是我們聽到最多的難題之一。特別是在coding領域，這仍然是一個沒有共識的問題。正好順雨最近推出了SWE-bench，現在很多做coding的專案都在用。順雨，你能給大家介紹一下SWE-bench以及你之前在coding和agent方面的工作嗎？　

姚順雨:　

SWE-bench的動機很簡單，就是現有的coding benchmark不太行。一個好的benchmark應該具備幾個特徵：第一，要realistic practical，不能只是toy task；第二，需要challenging，不能太簡單；第三，需要easy to evaluate，要有好的評估方法。　

現在大多數NLP
benchmark這三點都做得不夠好。比如很多都是toy task，或者是一些簡單的問題。像human
evaluation這種最常用的benchmark，現在模型已經能達到95%以上的表現。對於agent
task來說，evaluation特別難，比如要評估一個web agent的輸出好壞就很難判斷。　

除了這些核心特徵外，一個好的benchmark還需要具備一些管理特徵。比如要有scalable的資料收集方法，同時要確保資料不會被訓練集汙染。我們發現GitHub的pull request和issue系統完美符合所有這些特徵。　

具體來說，task的input很簡單，就是一個真實的GitHub
issue和完整的程式碼庫，可能有50萬行程式碼。output就是一個能解決問題的pull
request。evaluation非常簡單，因為可以直接用專案裡的unit test。這個任務既實用又有挑戰性，目前最好的RAG方案的成功率也只有40%左右。而且資料收集很穩定，我們測試發現不同年份的success rate差不多，即使發生資料汙染，我們隨時可以獲取最新的資料來補充。　

01:13:41 – 01:14:25　

我們當時非常開心。然後開始去做SWE Agent想要去解決這個問題。　

Monica:　

讓我給大家解釋一下什麼是SWE-Agent。我們剛才討論了很多關於coding的AI功能，前段時間一個叫Devin的產品釋出了flash

demo，這確實給大家打開了新的視野。它展示了agent如何解決更復雜的coding問題，而且不僅僅是幫助寫更好的程式碼，還能解決全鏈路的問題。我想詳細介紹一下思維agent是什麼，以及它背後的設計理念是怎樣的。　

01:14:26 – 01:18:11l　

姚順雨:　

對，Sweet
Agent的想法其實很簡單。在SWE-bench專案中，我們發現用sequence to
sequence的方式處理這類任務是不現實的，因為輸入可能包含幾十萬行程式碼和具體issue。即使使用RAG方案篩選出相關檔案，仍然面臨很多挑戰，因為對人來說，軟體開發本質上是一個fundamentally interactive（根本上互動）的過程。

Sweet Agent是SWE-bench任務上的一個baseline agent。我們採用了基本的ReAct Agent (Reasoning and Action)思路，關鍵在於action
space的設計。最初我們嘗試讓agent在bash
terminal中工作，可以檢視檔案、導航資料夾、編輯檔案和執行程式。但很快發現最大的問題是編輯操作缺乏反饋。執行程式時能得到execution
result供agent判斷，但編輯檔案時沒有即時反饋，可能出現syntax error或authentication error卻不自知。　

這促使我們提出了Agent Computer Interface（ACI）的概念。人類使用的Visual Studio Code、vim或Emacs這些都是Human Computer Interface（HCI），我們投入大量時間去打磨這些工具。但這些工具可能並不適合agent。傳統上都是固定environment讓agent變得更好，比如Atari遊戲，而我們採用相反思路：固定一個簡單的ReAct agent，專注於打磨environment。最終會有一些co-design，但核心是如何設計最適合agent的interface。

01:18:12 – 01:18:45　

Monica:　

我們可以向大家描述一下，這個agent能實現什麼樣的體驗，它可以完成什麼樣的任務？　

姚順雨:　

我們現在上線了一個線上demo，你可以複製任何一個GitHub issue的連結，然後貼上進去，點選一個按鈕，它就會嘗試生成一個pull request來解決這個issue。　

Monica:　

如果大家感興趣的話，這個SWE-agent的演示影片在YouTube和B站上都能看到。　

01:18:45 – 01:19:49　

我覺得大家看了之後會覺得非常impressive。剛才順雨講到SWE-bench，很多RAG-based的solution準確率都在個位數。而最近Devin和sweet
agent的準確率都超過了10%，有一個很大的提升。這個提升主要來源是什麼？是不是你們的Foundation model用的是GPT-4？　

姚順雨:　

對，我們sweet agent用的是GPT-4。我發現一個比較有意思的實驗結果，在RAG的setup下，現在Claude Opus已經略微超過GPT-4一點點，大約3.幾個百分點。　

趙宇哲:　

百分之24本身也是很強的。　

姚順雨:　

是的，但是在agent這個領域，GPT-4還是比其他model要強很多，比Claude和其他的都要強很多。這可能是因為Claude針對長文字和RAG進行了最佳化，而GPT-4則是針對agent進行了最佳化。　

01:19:49 – 01:20:27　

Monica:　

這個three agent能在SWE-bench上比之前的RAG有這麼大的提升，主要是什麼原因？　

姚順雨:　

我覺得有好幾個原因。我覺得最根本的原因是它可以去execute程式碼，你可以寫unit
test然後去執行。如果執行失敗了，你還可以繼續嘗試修改。這個iterative的feedback
loop是非常重要的。如果我只給你一次機會寫pull
request就立刻提交，都沒有機會去執行，那就很難確保程式碼是正確的。但是execution是一個關鍵。　

01:20:27 – 01:21:32　

Monica:　

這個跟前段時間大家討論的agent概念，比如AutoGPT這樣的框架是一個概念嗎？還是有什麼不一樣的地方？　

姚順雨:　

我覺得不一樣的地方就是，AutoGPT和baby AGI這類系統試圖把agent本身做得非常複雜，使用各種prompting方法、planning、reflection等技巧。但它們的environment其實很簡單，想做一個通用的agent，但效果不是特別好。我的philosophy就是說，如果我們知道要做什麼task，就可以針對性地最佳化工具和environment，讓相對簡單的agent提升performance。

01:21:33 – 01:24:39　

高寧:　

你們與Devin之間的差別和準確率差異主要體現在哪些方面？　

姚順雨:　

Devin是一個產品，我們是研究專案，目標是解決SWE-bench。Devin作為產品需要處理各種軟體環境下的任務。他們採用了一個非常general的環境，包括web browser、terminal、editor和整個AI框架。而我們因為專注於特定任務，可以將介面最佳化到最適合agent完成任務。雖然我們的API design對各種程式設計任務都有幫助，但我們的技術路線是最佳化interface。　

Monica:　

對於目前10-12%的準確率，你怎麼看？你期望達到什麼樣的目標？　

姚順雨:　

我覺得現在大家都還是baseline水平。我有朋友的創業公司可能達到20%左右。我估計GPT-4應該能達到30%，因為SWE agent只是一個簡單的agent加上初步最佳化的interface。Devin是在標準environment下的複雜agent。如果把interface design和agent design結合在一起，即使用GPT-4也應該能達到更好的效果。

Monica:　

Devin下面是用GPT-4嗎？　

高寧:　

GPT-4 Turbo釋出時官方發了推文at了Devin，應該是說明Devin提前獲得了GPT-4 Turbo的介面。　

01:24:39 – 01:26:50　

Monica:　

根據你剛才的說法，現在很多人在討論agent為什麼雷聲大雨點小，沒有很好的落地。很多人歸咎於Foundation
model的reasoning能力不行，但根據SWE-bench的結果來看，在現有Foundation
model能力下其實還有很大的提升空間。　

李珎:　

產品化和做research是完全不同的事情。雖然在研究層面看起來不錯，但要做成使用者能用的產品，需要更多產品層面的思考。

agent與其他AI產品有很大的區別，首先是一個iterative(迭代)的過程，使用者需要耐心等待，這種產品形態是前所未有的。與傳統軟體API相比，一個LLM相當於以前的一個API call，而現在的agent更像是把這些API組合成一個end to end的軟體。但前所未有的是需要等待十分鐘才能得到反饋。　

另外，agent還有一個特點是不穩定，它無法達到90%甚至80%、70%的準確率，更不用說傳統軟體追求的99.9%的穩定性。　

面對這樣一個軟體，如何讓使用者能夠良好互動並獲得價值，需要複雜的設計。

01:26:50 – 01:29:13　

Monica:　

前面提到，姚順雨其實一直在agent這個領域做了很多工作，從最早可能從React開始。每個人對agent都有不同的理解，你能跟我們介紹一下你是什麼時候開始研究agent的，在這個過程中有哪些重要的研究？　

姚順雨:　

我覺得我比較幸運，2019年開始讀博士時，我的第一個專案就是在text adventure game中做agent。當時這是個很小眾的方向，因為大多數人做agent都是做RL，基本上都是做video game或robots，很少人做基於language的environment agent。

我覺得這個方向很有意思，因為它更接近reasoning，更接近intelligence。我認為life is more like a text-based more than a video game，因為你要做的decision其實很多是open-ended的。比如說今天晚上做什麼，action space是open-ended的，並沒有一個上下左右這樣的鍵盤去給你指引。你可以買張機票去另一個城市，或者看個電視，有無數種選擇。　

我覺得language更接近這個事情的本質。做完text game後，我發現text environment和傳統environment的本質區別在於它的action space是不需要預先定義的。這就需要reasoning，而reasoning本質上是思考的一部分。為什麼傳統的agent不如人，是因為人有一個神奇的action叫做思考，但傳統agent沒有。思考這個action很神奇，因為它沒有feedback，你腦子裡想任何事情都無法獲得外部世界的反饋，所以這個事情是學不了的。　

01:29:13 – 01:30:57　

Large Language Model為我們提供了parsing機制，讓我們能夠將reasoning和thinking作為language agent的重要組成部分。透過trail soft的進一步思考，我意識到agent本質上包含兩個核心部分：action space和decision making。

action space就是選擇什麼樣的工具來互動，如何設計interface，以及如何進行internal reasoning。

傳統上，decision making主要是透過generate next token來產生動作。但我認為，decision making可以透過planning來實現更復雜的決策。我們不只是直接產生單個動作，而是可以在腦子裡面模擬多個可能的動作並評估它們。就像下棋一樣，我可以預測如果我這樣走，對手會怎麼應對這樣的互動過程。　

基於這些思考，我們提出了新的conceptual framework：Cognitive architectures for language agents。本質上，agent就是由action、decision和memory三個部分組成的。

無常按：　

清晰到值得重複。本質上，agent由三個部分組成：action space、decision making 和 memory。　

action space 就是選擇什麼樣的工具來互動，如何設計interface，以及如何進行internal reasoning。　

decision making可以透過planning來實現更復雜的決策。我們不只是直接產生單個動作，而是可以在腦子裡面模擬多個可能的動作並評估它們。就像下棋一樣，我可以預測如果我這樣走，對手會怎麼應對這樣的互動過程。　

memory 是記憶。　

01:30:59 – 01:32:43　

Monica:　

所以你的工作就是從思考逐漸發展到taking actions的研究。我覺得現在大部分的agent工作其實都是在不直接改變Foundation model的情況下，主要透過prompt方式來實現的。

李珎:　

會這麼理解？　

姚順雨:　

我覺得這個事情從根本上存在問題，因為它沒有形成閉環，是個open
loop。我可以舉個例子，現在我們用H200就很像deep learning初期用GPU的方式。當年GPU不是為deep
learning設計的，是為遊戲設計的。後來大家發現它可以訓練AlexNet這些神經網路。接下來發生的事情很有意思：GPU和deep
learning method形成了co-evolve關係，GPU促進了更好的deep learning
method，而transformer這樣的method又反過來影響GPU的設計變化。　

language model就很像當年的GPU，最初只是個text generator，但大家用它做各種事情時發現了很多令人驚訝的能力。所以我覺得下一步應該把model和agent進行co-design，把agent的experience和資料反過來fine-tune model。

01:32:43 – 01:33:01　

我們有一個工作叫fineac，就是fine-tune React。　

Monica:　

你們是自己先做了React，然後再做fine-tuning的研究嗎？　

姚順雨:　

對，因為我一直在等別人去做這件事，但發現沒有人做，所以我們就自己做了。　

01:33:01 – 01:34:01　

Monica:　

前段時間在討論agent這個話題時，有些公司比如Adapt就專門開發了針對agent的模型，我們特別重視模型的reasoning能力。我想請教，是否會出現一個專門針對agent的語言模型？這是否是個偽命題？　

李珎:　

對，Adapt。　

姚順雨:　

我認為agent是個非常寬泛的概念，具體取決於你想要做什麼樣的agent。如果是想做general purpose的digital agent，我覺得基礎模型會更有優勢。如果是做vertical domain的特定領域agent，那可能就不需要專門的模型。

高寧:　

聽起來你覺得這應該是個偽命題。　

Monica:　

對，結論應該是個偽命題。

01:34:01 – 01:35:07　

李珎:　

這其實是我創業時的出發點，就是要有個general agent幫你處理各種事務。我們做了一個類似ztier的專案，讓LLM來接入各種API。我們接入了Google Calendar、Gmail、訂機票、訂外賣這些服務。　

高寧:　

這樣就能幫助協調整個工作流程。　

李珎:　

但實際上這種general agent是個偽命題，因為很難真正產生價值。表面上看能幫你做很多事情，但首先系統穩定性是個問題。其次，如果要處理真正複雜的事務，僅靠API是不夠的，需要中間的agent來管理工作流程。而且你要解決的問題越寬泛，就越難讓它真正好用。　

姚順雨:　

對，它更多需要人機互動才能真正發揮作用。　

01:35:07 – 01:38:15　

李珎:　

對，coding agent的一個很好的特點是它能產生可以自我驗證的行動路徑，形成一個完整的閉環。當agent透過十步二十步的操作完成任務後，就會生成positive的訓練資料。　

姚順雨:　

行動路徑具體是怎麼定義的？　

李珎:　

這主要是基於OT flow，即使用者的edit記錄。OT是一種用來解決多人編輯衝突的格式，比如在Google
Docs多人編輯時就需要解決這種衝突。它會記錄諸如使用者在第五行第三列新增內容這樣的具體操作。這是一個很底層的使用者操作記錄，比Google
Docs的範圍更廣，還包括了執行shell、寫程式碼、debug等操作。　

姚順雨:　

這些資料真的非常exciting！　

趙宇哲:　

code也是可以爬的。　

李珎:　

對，這些資料的獨特價值在於可驗證性。我們能確認專案是否編譯成功、透過測試。這不僅是簡單的資料，而是一個達到成功狀態的完整軌跡。

Monica:　

這有點像Tesla在做的事情。　

李珎:　

目前我們還在探索如何最好地使用這些資料，包括legal和模型訓練方面的考慮。由於記錄了每一個操作步驟，整體資料量是非常大的。　

01:38:16 – 01:40:52　

Monica:　

我聽說現在有一些agent是用GPT-4來產生action model？　

姚順雨:　

這是distillation。這個跟agent沒關係。　

李珎:　

我現在在Replit做agent，它更像是coding interpreter。我們提供預構建的環境，沒有React Flow那些複雜的步驟，是更specific limited scope的。使用者只需提出需求，比如分析CSV檔案，系統就能生成程式碼並執行。　

我們特別關注小白使用者，因為他們完全不懂程式設計，甚至不知道Python是什麼，所以更需要agent的幫助。我們有個功能叫bug bounty，使用者可以釋出懸賞來解決bug。解決者可以是人類，也可以是SWE agent。　

這就是為什麼我們的CEO和SpaceX的CEO關係很好，因為使用者群是一體的。誰解決了bug就能獲得獎勵。　

Monica:　

順雨找到了賺錢的方式了。　

高寧:　

找到了應用場景了。　

01:40:53 – 01:42:04　

Monica:　

其實剛才順雨講到研究課題和產品之間的差異，就在這裡。在產品中，即使我說要有human loop，但我必須考慮參與loop的使用者是什麼樣的。比如像宇哲他們的客戶，預設都有一定的coding能力；但如果面向完全的小白使用者，這時候做human loop的互動設計就會很不一樣。

姚順雨:　

我覺得本質上來說，除非是做HCI research，研究就是要minimize human factor，但是product本質上就是all about human。

無常按：Product is all about human 好清醒的研究員！　

Monica:　

前兩天我跟open Devin（一個open source的Devin專案）的團隊交流過，也看了他們的架構。因為他們團隊都還在企業裡做產品，所以特別注重把human loop的互動融入到架構中。這確實和research的思維方式很不一樣。　

01:42:04 – 01:44:20　

我們一直在討論Devin，我很好奇大家第一次看到Devin demo時的反應是什麼？什麼讓你們印象最深刻？根據目前有限的公開資訊，你們還想了解哪些內容？　

李珎:　

我的第一反應是有人釋出了和我正在做的exactly相同的東西。因為我們團隊正面對著百萬級使用者量，有很多infra問題要解決，所以沒法釋出demo。　

不過我覺得Devin確實很impressive，特別是兩點：第一是web browsing功能，它可以讓agent去瀏覽網頁獲取更多資訊。對agent來說最重要的兩個能力：一是獲取資訊的能力，無論是透過web還是透過RAG；二是自我validate的能力，就是execute和test。　

姚順雨:　

web browsing確實非常難做。　

李珎:　

對，特別是interactive web browsing，不只是fetch一個網頁，還要在網頁裡進行browsing，這點做得很impressive。另外，他們第一版本還不能讓使用者修改程式碼，只能看著它生成。　

高寧:　

但中間是可以透過聊天方式去幹預的吧？　

李珎:　

對，你可以透過聊天來控制它，但沒有直接控制editor的許可權。　

01:44:20 – 01:46:19　

這個我覺得挺surprise的。　

姚順雨:　

更像個demo不像個產品。　

李珎:　

我覺得可能是他們的Design decision去限制scope。但我覺得正確的形式應該是都要具備，這對他們來說實現起來應該也不難。　

Monica:　

你覺得還有什麼想進一步瞭解的嗎？　

李珎:　

我很好奇他們準備怎麼把它作為產品去落地，給誰用。　

姚順雨:　

是to C還是to B？　

李珎:　

對，這也是我們經常思考的問題。這個agent看起來能做所有事情，但你做research是一回事，做公司要賣產品又是另一回事。最重要的是找到product-market
fit。是賣給coding小白還是其他人？價格定在這個區間合適嗎？這些包裝策略我都挺好奇他們怎麼想的。　

高寧:　

因為你剛才提到如果不讓工程師過多參與編輯環節，聽起來是面向沒有程式設計能力的人。　

姚順雨:　

給產品經理。　

李珎:　

我覺得可能也是因為比較早期，所以先focus在這個方向也make sense。　

01:46:19 – 01:48:13　

趙宇哲:　

我最喜歡的是Danny告訴我的這些東西。我一直在關注這些工作，在離開工作之前我就很喜歡做prompting相關的工作，我們也很早就開始做這些了，效果很好。　

說實話，我對agent的工作一直是失望的。比如Langchain之前火過一陣子，大家都在談論agent可以做這做那，但後來並沒有特別顯著的進展。雖然Devin在這方面是比較成功的，但我仍然持懷疑態度，因為從一開始我就認為這只是個demo。後來Twitter上也有人說這確實就是個demo。　

姚順雨:　

他是直接釋出產品的。　

趙宇哲:　

對，但這本質上不是一個軟體問題。這個demo是在告訴你這件事是可能的。關於產品化，我認為如果它真的能在所有情況下都work的話，產品化可能也沒那麼難。AI政策已經證明了我們無法阻止這個問題的發展。這個任務實際上是automation後面一個level的任務，就是從issue到PR的過程。　

01:48:13 – 01:49:22　

首先需要寫PR，現在有很多重要的tasks，比如如何做code
review。這些review工作現在可以用model來輔助，它能夠suggest具體的code
edits，這些功能已經可以投入service了。如果能把PR這塊做好，我甚至可以去負責整個project的架構，這就是architect要做的事情。在企業環境中，當我要build一個function時，會面對大量的code
base，需要開發新的feature。　

姚順雨:　

對，這些feature可以被系統地decompose成一系列PR。　

趙宇哲:　

這確實是一個很關鍵的步驟，這也是我特別看重這個task的原因。關於agent是否是一個好的solution這個問題，我認為從長遠來看它一定會很好，是個非常有價值的research topic。但對創業公司來說這是個很大的question mark。如果公司像早期的OpenAI那樣不以盈利和產品為直接目標，那麼做這個方向很合適。但如果是以product為導向，research的risk就相當高了。　

01:49:22 – 01:51:36　

姚順雨:　

這個很像當年adapt，一開始做了一個非常fancy的demo，最初是作為research lab使用，後來轉向enterprise產品。我覺得dev也可能會往這個方向轉。　

趙宇哲:　

這確實是個很risky的轉向。　

Monica:　

那這個問題是僅限於model層面，還是有其他research需要解決？　

姚順雨:　

如果只是作為research benchmark去和GPT-4比較，能做到一個decent的水平。但要做成產品，很多low-level tasks可能就work不了，你可能需要工具支援。

趙宇哲:　

對，從產品角度來說，假設我們現在有30%的成功率，提升到了50%。寫PR時50%是好的，但問題是透過unit test也不代表完全正確，unit test的coverage就是個問題。如果50%不好，誰來改它？如果它能自己改好就不會只有50%了。那程式設計師可能會想，我是不是自己寫一遍更快？

姚順雨:　

但你覺得unit test真的能實現完美的evaluation嗎？　

趙宇哲:　

我們內部試過，效果沒那麼好。GitHub上很多專案甚至都不寫unit test，質量也參差不齊。而且透過unit test不代表程式碼就對了，有時候程式碼錯一點點通不過測試，但實際程式碼質量也沒那麼差。　

01:51:36 – 01:52:22　

你的test質量可能沒那麼好，但是PR相關的test會稍微好一點，因為它會涉及好幾個部分，而且有好幾個原有的test去cover。不過也不是所有PR的test都這麼好。　

姚順雨:　

我們當時做這個的時候，就選了比較高質量的test。　

趙宇哲:　

對，這就是很重要的部分。如果隨便選一個，那validation的效果就沒那麼好。我們試過這種情況。　

姚順雨:　

在理想情況下，假設你有一個非常高質量的evaluation，那即使是10%的隨機選擇其實也是可以work的，因為你可以試一百次，然後只要把unit test透過就行。　

01:52:22 – 01:53:46　

Monica:　

如果我們給AI一個test，想看它的完成準確率是多少。我們可以把範圍限定在junior engineer的任務上，畢竟你也不會給junior engineer太難的test。假設在這些junior的工作範圍內，它能達到80%、90%的完成機率。　

姚順雨:　

可以。　

趙宇哲:　

這個可以去設計，但這就變成產品設計時要control你的user expectation。你要考慮怎麼定義user，不要讓他們濫用這個功能。因為有些PR大有些PR小，簡單的PR讓AI做是很好的，但推產品時你需要把user定義得比較清楚，否則他們一開始就會覺得這個不行那個不行。

Monica:　

這有點像我們招程式設計師一樣，你招不同level的人，佈置任務時也會考慮。比如給宇哲佈置任務和給一個剛畢業的佈置任務是不一樣的。我在想，當我們把agent也當成一個人來看的時候，我們assign task的方式是不是也應該不一樣。

01:53:46 – 01:55:13　

李珎:　

對，這個事情正在發生，很多小的task，比如寫unit
test、進行重構（rename）或者debug這些工作，都是可以交給junior
engineer來做的。在軟體開發的各個步驟中，已經有很多創業公司在專門針對這些任務開發產品，比如swift dev。　

我們發現需求定義越明確，完成的成功率就越高；需求越abstract，就越需要interactive的步驟和人工介入。所以我們對agent的思路是把它定位為協作夥伴，不是簡單地交付任務給它。它會在code base和repo中與你collaborate，當它在後臺執行時遇到問題，會發送notification給你，讓你指導它如何proceed。　

01:55:13 – 01:56:06　

Monica:　

使用者不能太小白。這就像甲方和乙方的關係，通常甲方什麼都不懂，這些東西是沒辦法的。　

李珎:　

這是不同level的問題。這樣的使用者不會問你技術層面的問題，而是會問需求方面的問題。比如說你要做website，他會問你這個website要不要dark mode啊，你覺得這個好不好看，要不要改一改？right，這些問題對於小白來說其實是make sense的，而且他需要問這些問題，這樣才能讓最終生成的東西符合你的期待。　

Monica:　

那其實這個agent就遠不止是一個coding的agent。　

趙宇哲:　

對，要求比較高，需要會跟人交流。

Monica:　

這就像個乙方，我覺得這個真的適合SWE-bench。　

01:56:07 – 01:56:46　

趙宇哲:　

如果這個agent真的很優秀，它就很適合作為contractor來幫你完成工作。　

Monica:　

我們前面可能需要一個agent來evaluate，判斷這個問題是否能被現有的agent解決。如果當前agent無法處理，系統會將你分配到其他合適的agent。它甚至可以幫你自動分配一些任務給人類操作員。

李珎:　

我們可以想象這樣一個世界，你可以僱傭很多不同的agent。比如SWE-bench是一個可以僱傭的agent，Devin是另一個選擇。你可以像檢視LinkedIn簡歷一樣，看到他們之前完成過什麼樣的任務，有什麼樣的工作記錄。　

姚順雨:　

最終還是要用賺錢多少來衡量，這是最基本的評判標準。　

01:56:46 – 01:58:00　

Monica:　

我注意到你們最近發表了一篇關於Olympia programming的論文，似乎是針對更復雜的數學問題。我很好奇能否介紹一下這個專案，以及它與SWE-bench有什麼關係？因為聽起來這兩個專案都在解決複雜的問題。　

姚順雨:　

這其實是coding這個問題的兩個不同frontier，是兩個完全不同方向的frontier。SWE-bench本質上處理的內容沒有那麼複雜，它更多關注的是long
context和noisy context的處理。而Olympia problem則完全相反，它的問題和程式碼都很短，可能就十到二十行，但更注重grounded reasoning、creative reasoning algorithm和organic reasoning。所以一個是考驗你對長文字和複雜context的處理能力，另一個則是考驗你對CHV這個grounded的理解和augment。

01:58:00 – 02:00:31　

Monica:　

你覺得解決數學問題和奧林匹克程式設計問題之間有什麼關係？　

姚順雨:　

我覺得奧林匹克程式設計問題更接近於測試基礎模型的推理能力。比如說，有N個人站成一列，需要進行某些操作，問有多少種可能的方案。這類問題需要你在空間中進行想象，理解組合的意義，做world modeling和simulation。傳統的軟體工程更多是pattern recognition，比如搜尋stack workflow和複製程式碼，不太需要這種深度推理。　

李珎:　

軟體工程的問題只要投入足夠時間總能解決，但奧林匹克程式設計中有些問題即使投入再多時間也無法解決。

姚順雨:　

對，我在debug時常常只需要搜尋已有解決方案，不需要太多推理。軟體工程主要是處理大量的知識、複雜的上下文和noisy situation。雖然世界上有數百萬程式設計師，但真正擅長程式設計競賽的人並不多，因為那需要更強的world modeling、simulation和organic reasoning能力。我認為這兩種能力是通向AGI的重要維度。

02:00:31 – 02:01:48　

Monica:　

我其實很好奇想探討一下關於Foundation model或LM能力邊界的理解。因為從Chain-of-Thought的發展來看，僅僅是在prompt層面的改進就能帶來效果上很大的區別。所以我很想知道，當我們討論現在LLM能力不足時，到底有多少是模型本身能力的侷限，又有多少是我們還沒找到正確方式來釋放它的能力？

姚順雨:　

我覺得這個問題可以從兩個部分來看：一部分是你怎麼去訓練模型，另一部分是你怎麼使用它，也就是我們說的prompt。模型能力的邊界就取決於這兩點。比如我剛才提到GPU H800的例子，我認為它應該形成一個閉環，就是我們使用模型的方式應該反過來去影響我們如何訓練這個模型。　

因為如果我們使用模型的方法跟它訓練時的資料不一致的話，它就沒有辦法釋放它的能力。我們現在釋放的這些能力其實都是所謂的 emergent properties。我覺得我們現在使用這些方法可以給我們一些 insights。可以幫助我們 improve 這些虛擬的網路。　

02:02:15 – 02:04:15　

Monica:　

我覺得在討論LLM的limitation時，大家經常提到predict
next token的方式像是一種快思考。而科學研究和更深層次的創造，大家認為需要system 2
thinking這種慢思考。但我記得你的paper中提到，透過prompt就可以實現system 2
thinking。這是否意味著模型本身具有慢思考的能力，只是我們還不知道如何使用？如果真的具有這種慢思考能力，是否意味著它已經可以幫助我們解決複雜的科學發現問題？我在想，是不是我們使用它的方式限制了我們對LLM邊界的想象？　

姚順雨:　

你說的應該是Chain-of-Thought這篇paper。這篇paper的核心思想是，如果我們把next
token prediction看作是一個system one的快速過程，那麼對於system
two這種慢思考來說，它其實是一個對system one的控制。　

觀眾:　

Control AGI over system one。

姚順雨:　

對，它是知道什麼時候去stop這個flow然後switch to something else，更多是對system one的一個control。它並不是獨立於system one存在的東西。所以tree of thought的本質是透過tree search這樣的控制機制來control system one，而不是去替代它，而是去impose control over system。

我們其實當時試過一些更難的任務，比如說去做unipl programming，或者一些我們認為更接近AGI的任務。　

觀眾:　

你說的是task對吧？　

姚順雨:　

對，但現在的模型還是無法完成這些任務。我覺得很大一個原因就是它的self evaluation能力還不夠強。比如說讓它寫三段程式碼，它很難判斷哪一段程式碼更好，因為這並不是它訓練過程中學習的內容。　

趙宇哲:　

這是經典的reinforcement learning問題。　

姚順雨:　

對，我們怎麼去使用這個模型其實反過來會告訴我們模型在哪些能力上有不足，我們應該去針對性地改進。　

02:05:01 – 02:06:32　

Monica:　

根據我們現在的使用方式，你覺得接下來應該往哪個方向去improve呢？　

姚順雨:　

這是一個比較抽象的問題。我們面對的是一個解空間，這條路徑可能找到解。

趙宇哲:　

這本質上是個搜尋問題。現在我們已經找到了一條路徑，但不能就此停止。這樣太簡單了，我們需要去sample這個空間。這就是大家在做agent prompting時在做的事情。最開始Chain of Thought只走一條路就結束，後來有一篇paper叫self consistency，提出可以sample多個結果並把它們結合起來，實驗證明效果確實更好。我們可以使用更復雜的搜尋方法。　

另外，第二個改進方向是要提升sampling model本身的能力。雖然RL是個很難訓練的方向，但language model有個很好的特點：只要你知道哪些資料是好的，就總是可以把它反饋回去。　

02:06:33 – 02:07:13　

相信大家都應該做這件事情，但這並不容易，因為所需的data並不存在。這些data需要找出來。這也是已經在發生的事情——現在有很多人要麼用已有的language model去filter和select預訓練資料，要麼直接生成訓練資料。　

高寧:　

你的意思是用language model來做這個？　

趙宇哲:　

對，就是用它產生的資料、feedback，或者其他任何形式的反饋來最佳化。但這個方向能走多遠，現在還不知道。　

02:07:13 – 02:10:20　

Monica:　

關於agent，最近大家討論比較多的是multi agent。我看到replay中有一個multi player的AI chat功能，能否介紹一下這個feature？　

李珎:　

這其實是multi agent system的一個前置工作。我們原來的AI chat只支援單人對話，而multi player chat允許多人同時share一個chat window，可以看到其他人的訊息。它有點像email系統，你可以看到每個人的訊息streaming的過程，有不同的session。　

Monica:　

這是說agent可以和多個人互動嗎？　

李珎:　

目前這只是一個面向多使用者的chat系統。但它是agent的前置工作，因為我們意識到，如果需要多個agent在後臺工作，就需要一個情報接收系統來監控它們的工作狀態。比如在report裡面，同時agent也在work on this report，你需要看到它們在做什麼。即使你把筆記型電腦合上，agent仍在工作，重新開啟時還能看到工作進展。我們的chat其實就是一個UI去看agent is working。

agent需要與人進行互動，可以透過對話或button形式。比如當agent需要進行deploy這樣的重要決策時，就需要詢問使用者確認，因為這涉及費用支出。我們需要考慮很多產品設計問題，比如什麼時候該詢問使用者、什麼時候讓agent在後臺工作。agent的state很複雜，它有很多observation，你也許不想看到那麼複雜的東西，只想知道它在7×24小時地為你工作。這就是我們ft五類現在正在做的事情。　

02:10:20 – 02:13:02　

Monica:　

你們怎麼定義multi agent system？為什麼我們需要它？　

姚順雨:　

我覺得本質上是個inference time scaling的邏輯。我們最終希望在inference時用更多compute來獲得更好效果，增加agent數量就是scaling up的一種方式。不過現在base agent還不夠強，要等它達到一定水平後，multi agent的scaling才會真正發揮作用。就像團隊協作，如果大家都很菜，人越多越亂；但如果都夠強，兩個人可能比一個人效率快兩倍，三個人可能再快1.5倍。

李珎:　

multi agent其實有兩種不同定義：第一種是多個agent做同一件事，第二種是不同agent負責不同任務。比如MetaGPT這個專案，它模擬了一個完整的公司架構，有CEO、PM、程式設計師、reviewer，每個角色都有不同的prompt。在我們的設定裡，使用者和agent都是第一公民，這是很重要的理念。

02:13:02 – 02:13:18　

姚順雨:　

這更像是一個 multi prompt，並不像一個 multi agent。

趙宇哲:　

我想問這個問題，如果你用的都是 GPT-4 的不同 system prompt，一個 prompt 對應一個 agent…那這是不是就是一個人格分裂的 agent？　

02:13:18 – 02:13:39　

Monica:　

既然Devin已經可以作為一個self agent完成從編碼到單元測試的整個流程，甚至能夠自己進行程式碼review，那為什麼還需要不同的角色呢？　

李珎:　

我理解啊，我理解就是……簡單的case就是不同的prompt，大家都知道給模型不同的prompt會帶來不同的表現。如果你告訴它你是一個software
engineer，它生成的程式碼就會比告訴它你是普通人要好得多。即使是同一個模型，你用不同的prompt方式，包括chain of
thought等方法。　

趙宇哲:　

對，可以用不同的方法。　

李珎:　

從互動的角度來看，它給你的結果質量是完全不一樣的。即使是同一個模型，它也會被當作不同的角色來對待。　

高寧:　

考慮到未來的成本和效果的價效比因素，各個小的agent背後不一定都需要用GPT-4這樣的模型，而是可以用專門的模型，比如程式碼補全的模型、testing的模型，這樣更合理，讓它們各司其職，真正成為替代某個職能部門的agent。　

李珎:　

對，其實大家關心的只是誰能把這個工作做完。　

02:14:51 – 02:15:08　

趙宇哲:　

你是全能選手對吧？　

李珎:　

讓Devin來幫我寫這個程式碼還是說讓一個Newgrass幫我寫這個程式碼，你只要能寫好，我其實不是很care。我甚至更希望一個Newgrass幫我寫程式碼。　

高寧:　

不然還欠Devin一個人情。　

02:15:09 – 02:17:24　

關於multi-agent系統設計，你覺得主要挑戰是在能力層面嗎？我們是否需要結合具體場景來考慮？　

李珎:　

這個問題要看你從哪個角度思考。作為更接近產品的人，我發現一個很大的問題：現有模型的強大能力並沒有真正傳遞到使用者手上。比如說GPT-4，當我發現它給我的程式碼質量比我僱傭的前端工程師還要好時，我就意識到AI已經能產生巨大的價值，但這個價值還沒有真正普及到大多數人手中。　

我建議從兩個維度來看這個問題：假設當前AI能力是60分，但大多數使用者可能只享受到20-30分的能力，有些甚至是零分。從產品角度，我們的工作是讓更多人能享受到這個60分的能力；從研究角度，則是要把這個60分提升到80分甚至100分。當上限提升後，普通使用者享受到的能力自然也會相應提升。　

姚順雨:　

一個是push frontier，一個是help people實現價值。

趙宇哲:　

這個比喻很貼切，就像造紙局和用紙局的關係。造紙的人關注如何提升能力，用紙的人關注如何讓更多人用起來。不過現在確實還是一個research phase，絕對是research phase。　

02:17:24 – 02:19:37　

Monica:　

我們聊了很多技術細節和產品的事，現在可以暢想一下未來。說到這個，貴司真的很會寫blog，這種水平AI可能一時半會還寫不了。　

李珎:　

寫paper就寫blog。

Monica:　

你們的blog裡提到"AI is redefining the whole software development life cycle"。但僅僅是auto complete這些功能並不算是真正的redefine。那麼未來一到三年內，整個life cycle會有哪些大的變化？　

李珎:　

AI redefining software engineer life cycle其實很好理解。現在的software engineer工具和life cycle都是為人類設計的，我們都是考慮電腦前面坐著一個人需要什麼樣的工具。但如果從AI角度考慮就完全不一樣了。比如git有十幾年歷史了，一直沒有什麼進化，對人來說可能make sense，但對AI來說未必。如果把AI視為第一生產力，我們就需要重新思考如何設計git，甚至programming language。

姚順雨:　

你覺得有什麼東西是需要重新設計的？　

李珎:　

IDE肯定需要重新設計。不過說實話，我現在還沒想到什麼東西是fundamentally需要重新設計的。如果真的想到了，我會立即開始做這件事。　

趙宇哲:　

這確實是個很好但很難的問題。　

02:19:37 – 02:22:43　

姚順雨:　

很多東西在大部分情況下可能沒有本質區別，對Python和C來說，只要有足夠多的資料都能學會。　

李珎:　

但有些東西是一定不會被取代的。我覺得首先很重要的是跟現實世界的互動動作。比如說，軟體公司裡面很大一部分工作是AB test，這其實就是validation的部分。你的模型再強大，你都需要去validate你的答案是否正確。比如你現在有個電商網站，做了頁面改動，這個改動對網站revenue是正向還是負向的？模型再強大也不知道，除非你去測試。所以這部分工作不僅不會被取代，反而需要被重新設計，思考如何讓模型更好地去測試。

趙宇哲:　

這個問題很好但確實很難。我比較喜歡把這個類比成自動駕駛。有人直接做L4自動駕駛，就會考慮要不要方向盤，沒有方向盤後車該造成什麼樣。這個問題很valid，但存在風險且難以預測。另一條路徑是先把基礎功能實現，從使用者那邊學習，看他們使用時發生了什麼變化。

對程式語言來說這是個很大的變化。從C、C++開始，程式語言一直在演進，目標就是讓程式設計更容易更簡單。現在透過AI工具可以直接得到可執行的程式碼。未來不會再有說我只是個C++程式設計師，不寫Python這種情況。工程師加上copilot，或者copilot本身就會成為全能的程式碼編寫者。這種變化已經在發生，影響了大家對language和syntax的態度。比如proto就在努力讓資料傳輸在所有語言裡都能實現，這是個很好的例子。　

02:22:43 – 02:23:30　

如果以後我們真的能成為language-agnostic的開發者，那是不是就能有一些library可以隨意呼叫各種程式語言的feature，然後透過自己寫的middleware來作為portal統一管理這些功能？　

這件事對開發者來說其實很煩的。比如說我開發了一個專案，然後發現用Rust實現更好，需要重新寫一遍，這真的很煩。不過以後這個問題應該會得到解決，因為確實有很多場景需要用另一種語言重寫專案，這件事情很值得去做。　

姚順雨:　

GPT可以做這個。　

趙宇哲:　

對，因為這些事情本質上就是translation，這個問題其實並不難解決。　

02:23:30 – 02:24:09　

高寧:　

這個跟大語言模型的多語言能力是一個相同的道理。　

趙宇哲:　

對，這個原理並不難，模型能做得很好。這會帶來很大的變化，具體意味著什麼我現在還不太確定。但我有一個prediction，就是"next billion"一定會發生——它會降低程式設計門檻，提升整體能力水平。有人說它會replace程式設計師，但不會的。它會讓所有人都變成程式設計師，讓好的程式設計師變得更好。這真的很棒。　

姚順雨:　

我認為如果AGI實現，它將能夠完成任何工作，軟體開發只是其中之一。軟體開發的獨特之處在於它具有較高的feedback資料，這使得AI在這個領域可能有更多學習機會。相比之下，像人際交往這樣需要真實互動的任務就非常微妙，對吧？這個相對來說是一個比較不well-defined的任務，這反而是AI的優勢。　

具體來說，task decision是非常重要的。比如Should
your agent take care of the unit test? Should your agent take care of
the code body? Just high level decomposition make sense。一方面，我們需要探索現有模型的邊界，研究如何讓它做得更好；另一方面，我們也需要這樣的人 to make the base model value，最重要的是two people should communicate。　

02:25:45 – 02:27:27　

Monica:　

我看到順雨最近做了一個關於language agent的social impact研究，想請你談談language agent對社會和工作的影響。　

姚順雨:　

我分享研究中的一個重要發現。我們構建了一個金字塔模型來描述不同工作被替代的可能性。金字塔第一層是business tasks，第二層是collaboration和communication，最上層是design和high-level exploration。

最容易被替代的是第一層，就是那些重複性強且需要可靠性的business工作，比如客服、報稅或基礎法律服務。這類工作可以用程式碼和固定流程來處理，不需要太多人際互動。　

第二層是collaboration，需要同時掌握與人和計算機打交道的能力。與計算機互動是well-defined的，但與人打交道則需要理解pragmatics，學會如何與人合作，這是非常tricky的。　

最難被替代的是最上層，涉及開放性探索的工作，比如scientific discovery或theorem proving這樣需要創新思維的領域。　

02:27:29 – 02:28:46　

Monica:　

既然你們提到AGI，剛才順雨那篇文章講到的social…　

趙宇哲:　

我有點surprise，這三層太過了。我是一個contrary的觀點。對於失業這個問題，從長期來看對人類社會是好事，但對個人來說是很不好的事情。這種情況每次技術革命都會發生。就業總量我不覺得會減少或增加。當然，如果說所有工作都被機器人替代了——最近robotics確實很火，這也是個很好的方向——那誰知道還會有什麼工作可以創造呢？但短期內一定會有人失業，這些人就會成為不穩定因素。美國工業革命時期就發生過這樣的事情。這讓我覺得有點無語，情況沒那麼樂觀。　

姚順雨:　

可能還是需要三個結合起來。　

02:28:46 – 02:31:04　

趙宇哲:　

我是從BERT開始做的。說起LaMDA的故事很有意思，我做完後超級喜歡這個專案。LaMDA團隊的Daniel後來去做Character AI，因為他是個語言學習者，喜歡聊天和chatbot。Character AI不會去做AGI，因為包括Norm和Daniel，他們都不在乎刷benchmark，只想要做chatbot。Google不給他們做，他們就自己去做了。

那時候我們做research、發paper都挺好的。我當時沒覺得Google太謹慎，因為它有自己的理由。但ChatGPT出來後整個世界就變了。我說我是受害者就是因為現在好好做research都做不了了，大家都去做product。雖然還有很多有意思的research方向，但現在整個research風氣都變成只能拉著模型去做study。這更多變成了engineering相關的工作。我不是說engineering不是好的research，但在這之前確實有很多其他有意思的research方向。　

這個技術不僅影響我們這些直接做research的人，還會影響很多其他工作崗位，帶來巨大的social impact。我雖然希望這個技術發展，因為它是很好的technology，但發生後怎麼辦？這個工作變得有點sick，因為完全被資本追逐。我本來覺得這是個很好的工作，比如Google做東西是為了更好的產品，但後來發現不是這樣。　

ChatGPT出來之後，推動AI發展的其實不是AI界，而是整個VC和資本。資本看到了所有的機會，這個勢頭已經完全停不下來了。　

無常按：被資本裹挾的研究，壓力巨大。最近Google DeepMind的一位科學家，就確實在這樣的壓力去世了，RIP。　

Monica:　

這就像GPU和AI的相互推進一樣。GPU最早是遊戲領域吸引資金，後來AI吸引了最多的投資，這又推動了GPU的發展方向。　

李珎:　

因為後面可能創造的價值和可以取代的價值都太大了。　

Monica:　

它的想象空間很大。　

趙宇哲:　

從Google來看，它的文化是肉眼可見的在下降，還在進行裁員，面臨很大壓力。很多人都是從Google跑出來的。在推廣過程中，我們發現使用者也面臨很大壓力，所有人都覺得必須要學會使用這些AI工具。　

高寧:　

現在有自媒體在販賣焦慮，說不會用就要落伍了。　

趙宇哲:　

但實際上大部分人並不那麼喜歡學習，喜歡跟進新東西的人是少數，所以就會產生很多焦慮。

02:33:24 – 02:33:32　

Monica:　

對你剛才說的很好奇。那些你覺得本來很有意思可以繼續的研究專案，比如說有哪些是你希望能繼續但沒有能繼續下去的？　

02:33:33 – 02:34:54　

趙宇哲:　

現在很多領域都在轉向，比如machine learning領域的一些應用，像Siri這樣的專案。　

姚順雨:　

已經不做了，現在都不再吹LLM了。　

趙宇哲:　

對，很多statistician都不再做統計理論研究了。我以前做過很多machine
learning theory的研究，覺得這些理論真的很漂亮很有意思。我特別喜歡graphical
model，這些東西真的很酷！但是你能看到，現在很多researcher已經不做這些研究了。　

對研究領域來說，我覺得這絕對不是好事，因為還有很多值得繼續深入的研究沒有完成。　

02:34:55 – 02:36:23　

Monica:　

我前段時間去了幾趟東岸。在矽谷我們經常感覺特別被overwhelm，但東岸的環境確實更diverse。我在紐約期間跑了一圈Yale、UPenn、NYU，還有MIT、Harvard，參與了很多AI的討論。這邊可能整天都在討論AI，但東岸的AI討論總是會結合biotech、healthcare等領域。

前兩天在MIT，我主持了一個panel，除了真格的合夥人外，另外三位都是哈佛的professor。他們分別研究AI in Healthcare、電池材料，還有一位是研究theory的。這種多樣性讓我特別有感觸，希望能保留這些研究方向。　

趙宇哲:　

用AI做biotech的其實一直都有。我有個很好的朋友就是做material science的，他們在用model去做predict。　

Monica:　

我理解你說的，有些更偏研究數學原理的美的東西可能被忽視了。　

趙宇哲:　

是的，machine learning的研究有些趨同，但如果你跨領域使用machine learning去研究其他物件，我覺得這個是很好的方向。　

02:36:24 – 02:38:52　

Monica:　

就是做AI。　

李珎:　

不，是做biotech。我覺得這是一件很好的事情，因為AI正在非常大程度地加速biotech和healthcare的研究進展。我們之前開發的產品，現在還在繼續做，就是幫助biotech這些早期公司的研究員生成程式碼，幫他們生成insights來確定下一步研究方向。　

這其實是很有用的。你要知道，他們的研究週期都是非常長的。比如我有一個朋友，他在研究定向殺死衰老細胞，換句話說就是在研究長生不老藥。他們正在用AI去predict下一步應該用什麼樣的蛋白質結構最可能發現好的藥物。　

這個過程是這樣的：雖然實驗現在還是要人來做，但做完實驗後會給AI
feedback，然後再去做下一步predict。這個過程is actually
happening，你並不需要依賴AGI直接設計出長生不老藥，但GPT-4正在切實地幫助這些biotech研究者確定他們的下一步方向。　

這是AI帶來的社會影響中少數幾個比較好的事情。也許很快我們就能把人類的壽命延長到120歲、150歲，甚至200歲。如果沒有AI，這個速度一定會更慢。AI可以幫助我們解決一些我們一直想解決的問題，比如癌症等。聽起來很玄幻，但在我創業過程中接觸了很多藥廠和biotech公司，這就是他們每天都在思考的問題：如何讓人類活得更久。

02:38:52 – 02:41:09　

高寧:　

從coding到展望未來再到social impact，我們有了很好的收尾。現在進入快問快答環節，準備了三個問題。　

Monica:　

大家控制在半分鐘到一分鐘回答。　

高寧:　

第一個問題是今年在工作或研究方向上的小目標是什麼？先請順雨回答。　

姚順雨:　

把現在的專案wrap up，然後開啟新的篇章。　

李珎:　

我的目標是讓足夠多的人能在Replit上創造他們自己的軟體，即使不會程式設計也能透過它賺錢。作為創業者，我深知只有當你的idea能帶來實際價值時，才能感受到它的意義。你可以做一個toy專案，但沒人care；而大多數人都需要他們的產品被人care。我希望能讓足夠多的人在Replit上創造自己的產品，without
knowing how to code。　

趙宇哲:　

我希望能保持現在對工作的熱情。　

Monica:　

現在驅動你保持熱情的是什麼？　

趙宇哲:　

我很喜歡我們的團隊。從長遠來看，我希望能和團隊一起見證technology對Embodied Intelligence的發展。這是一個可以預見的結果，特別是在self engineering方面。　

02:41:09 – 02:42:33　

Monica:　

那我問個輕鬆點的問題，大家在研究AI和工作之餘最喜歡做什麼呢？　

姚順雨:　

我喜歡打籃球和看書。　

Monica:　