隨著人工智慧、機器學習和自然語言處理等技術的飛速發展，Agent 技術已經從理論研究走向實際應用，展現出巨大的潛力和價值。

儘管我們負責的 AI Coding 產品 Aone Copilot 在阿里集團被廣泛的使用，也在每個階段使用 AI 做了許多的探索，但長期以來我對大模型能解決複雜問題長期以來都持懷疑態度，所以我們遲遲沒有動手去做 Agent 產品。

一方面原因是當時我認為模型能力不夠，基於機率的模型推理能力上存在天然缺陷，另一方面是業務邏輯的複雜性，讓模型很難理解真實世界是如何運轉的。

此前，我也分享過我對 Agent 的三種模式的思考，我認為 Agent 會經歷三個模式：區域性自動化，廣泛自動化，和極端自動化，透過泛化程度對 Agent 能完成什麼任務做劃分，後面演化出倉庫級別生成單測這種簡單工作流模式，Extensions 這種與模型一起驅動的模式，在集團內都有不小的應用，也遇到了不少問題。

彼時的我對於如何實現極端自動化並沒有清晰的答案，主要是我沒有理清一些關鍵問題應當如何解決，但隨著多模態模型的能力，以及 Resoning 模型能力的逐步強化，我認為我們可能來到了從“人驅動”到“模型驅動”的關鍵節點，透過這篇文章我會闡述為什麼大家認為 Agent 模式會在 2025 年開始爆發，我們有了哪些進步，我們又面臨了哪些挑戰。

去年下半年，尤其是以 O1 和 DeepSeek 為代表的模型在 Resoning 模型的進步，基本打消了大家對模型推理能力的疑慮，模型開始變的越來越理解使用者在的需求是什麼。以 Resoning 模型為代表，我們再也不需要在 Prompt 的設計上再大費周章，也不需要為 Prompt 的組裝順序那麼在意，他就能更加深層次的理解使用者在說什麼，甚至在使用者給出一個錯誤的問題時也能幫助糾正。

推理能力的進步使得我們在給定任務的時候不用告訴模型應該如何做和如何思考，它具備往往能幫助使用者一次性的把事情做好，尤其是在需求理解層面能達到人類的水準，甚至能探查出人沒有表達出來的意思。

長期以來，我們總是認為資料很重要，尤其是散落在文件中的領域知識，所以我們會花很大的精力去總結文件，但總是容易遇到一個容易被忽視的問題，就是如何處理文件中的圖片 ，過去的做法是， 選擇性的將圖片保留成一個個連結切片保留到 Embedding 資料庫裡。

但問題是，圖片和文字都是穿插在一起的，不應該輕易的放棄文件中的圖，圖片中往往藏著領域架構，系統架構，演示，頁面指引等。有時候模型要充分理解你的領域知識和文件，需要結合圖和文字一起來看。

而隨著模型能力的進步，大模型在理解圖片有了很大的進步，即使是非常複雜的架構圖也能抓出重要資訊

藉助多模態模型，我們在處理領域知識時擁有了更多選擇：可以將圖片與文字整合處理，在檢索增強生成（RAG）中同時召回圖文資訊，或者在生成摘要時讓模型綜合理解影像與文字內容。。

多模態模型的另一個重要價值在於能夠幫助業務系統更準確地理解使用者所處場景。在構建答疑係統時，我們經常面臨一個挑戰：難以確切瞭解使用者當前所處的具體環境以及遇到的具體問題。例如，我們往往不清楚使用者在哪個網頁上遇到了什麼型別的錯誤提示。因此，傳統答疑係統常常需要透過猜測或要求使用者填寫表單來獲取關鍵資訊。

下圖直觀展現了在搭建答疑係統過程中遇到的這一典型問題。

過去，理解使用者在業務系統中遇到的問題主要有兩種方法：一是將當前網頁連結提供給大模型分析。然而，這種方法存在明顯缺陷——網頁連結資訊單一，且大量透過非同步載入的內容使模型難以準確把握使用者實際看到的資訊。二是在業務系統中部署大量日誌記錄點，試圖串聯起使用者的完整行為鏈路，從而幫助答疑係統理解使用者當前處境。但這種方法不僅侷限性較大，還需要對系統進行大量改造才能實現。

隨著多模態模型能力的發展，這一難題可能有了更為優雅的解決方案。透過直接分析瀏覽器頁面截圖，模型可以繞過複雜的日誌系統，直觀理解使用者可能面臨的問題。這種方式免去了耗時費力地挖掘"使用者在什麼處境下遇到問題"這一關鍵資訊的過程。

值得注意的是，人類日常接收的大量資訊實際上是以影像而非純文字形式呈現的。許多系統之所以設計精美，正是為了增強人類的理解和閱讀體驗。長期以來，這部分影像資訊在模型理解中往往缺失，導致我們在處理複雜業務場景時的效果不盡如人意。多模態模型的發展有望顯著改善這一狀況，為業務系統的智慧化提供新的可能。

雖然程式碼能力是個老生常談的話題，幾乎每個新模型釋出時都會強調其程式設計表現，但這半年來真正令我震撼的，卻是模型在圖片復刻方面的出色能力，以及它持續穩定地輸出長篇內容的優異表現。

上面是原圖，下面是一句 promot 生成的 1 比 1 復刻的圖，還原度很高：

一次性生成程式碼的能力增強，甚至在前端程式碼場景下，一次生成上千行的程式碼而不會有任何語法問題，這極大的提升了從創意從 0 到 1 的效率。

在解決問題時，模型對自身能力邊界的認知程度直接影響其處理複雜問題的能力。這是因為，當模型無法準確評估自身侷限時，往往會依賴機率預測結果，導致看似合理實則錯誤的輸出。我們可以透過一個簡單案例來對比不同模型在此問題上的表現差異。

詢問 GPT-4o 一億以內最大的質數這個問題，它沒有經過思考直接給出的是一個錯誤數字。

但如果我問 Claude 3.7 一個更復雜的數字2313133123113 ，他直接給出了無法計算，並給出了正確的 Python 指令碼：

能夠認識到自身在特定領域的不足，並採取恰當的應對策略，這種能力是一項重大突破。試想，若缺乏這種自我認知能力，在處理複雜的多步驟問題時，錯誤便會層層累積。模型可能會陷入錯誤的結論中，卻始終無法意識到問題所在，這無疑為解決更復雜問題設定了障礙。

自從去年下半年以來， Cursor 經歷了迅猛的增長。然而，在我看來，Devin 是一款更具革命性的產品：Cursor 創新了 IDE 領域，而 Devin 則引領了 Agent 領域的變革。作為首個具體化且功能廣泛化的 Agent 產品，儘管 Devin 主打開發輔助（ Dev ），但在許多其他任務中它同樣表現優異，尤其是在技術和市場研究方面。這些產品的進步不僅提升了各自的效能，還推動了 Agent 理論層面的發展。

在 Devin 之前，大多數人提及的 Agent 主要在單一工作流中運用大型模型來解決特定的問題，例如進行某種判斷或呼叫某個 Function Call 等等，這並未充分發揮模型的全部價值與潛能。而自 Devin 以來，人們開始深刻理解了“模型驅動”的真正意義。

Devin 透過模型驅動能夠自主地進行規劃任務、反思、使用工具、聯網等活動。它具備非同步任務自動搜尋與執行的功能，從而解決了許多困擾業界的問題

因為他解決了眾多問題，並且是首個具體詮釋 "Planning Pattern" 的產品。儘管每月 500 美元的訂閱費用讓許多人望而卻步，但這並不能掩蓋他在能力上的卓越之處。隨後的所有產品，無論是 Manus 還是其他，都在某種程度上借鑑了他的理念。由於他的操作流程是從制定計劃開始，然後再進行實施，因此這種代理模式也被稱作“Planning Pattern”型別的代理。

此外， Devin 希望使用者把他當作一個實習生來使用。使用者可以非同步地將一些複雜的任務交給他執行，因此我們也將其稱為“非同步 Agent”。同時，因為他並未限制自己只從事特定的任務，所以我們同樣稱他為“通用 Agent”。

另外，既然我們可以非同步地將任務交給 Agent 執行，理論上人們無需時刻監督他的工作。若這樣的 Agent 數量充足，人們只需負責分配任務並準備驗收結果，這可能釋放出人類“十倍”的潛能。因此，我們認為這種模式能夠實現效率提升十倍的 Agent。

Cursor 和 WindSuf 在產品上進行了諸多創新，包括 "Apply" 和多行編輯補全功能，這些都給人留下了深刻的印象。然而，給我留下最深印象的是他們在本地 IDE 中的 Agent 模式。

當用戶提出一個需求時，Agent 會根據其對倉庫的索引和理解自行修改程式碼，甚至可以執行命令來完成任務，這是以前難以想象的功能。過去，我們對大型模型的能力持懷疑態度，擔心它們可能會生成一些不安全的命令，從而破壞使用者的環境或錯誤地刪除不應刪除的本地檔案等。

而 Cursor 很好地解決了在執行過程中使用者的信任問題，因為它會告知執行的步驟、如何修改檔案以及使用了哪些工具等。Cursor 的設計理念與 Devin 不同，它是先收集資訊，然後執行任務，在接收到反饋後，透過資料反饋不斷最佳化其執行路徑，這是一種代理（Agent）模式。

我們稱他為 “Reflection Pattern”的 Agent，它不會先生成計劃，它需要和人同步協作的 Agent，在我們內部叫它“同步 Agent”。

從本地 IDE 的角度看，衡量一個 Agent 的效果好壞，主要依賴於多個因素。一方面，這包括模型能力的強弱；另一方面，則是我們本地 IDE 上搜索功能的有效性。在本地 IDE 中，我們可以最大程度地利用本地資源，特別是 IDE 本身的強大功能，從而能夠更好地處理一些先前難以解決的工程上下文問題。例如，可以直接透過本地 IDE 對外暴露的 API 向模型提供函式或類的定義、跳轉，甚至是呼叫鏈路。

因為有了這些改進，我們可以將原本在伺服器端難以處理的情景轉移到本地進行最佳化，如在本地執行程式碼審查、查詢程式碼缺陷等任務。這樣一來，在編碼階段就能發現並修正程式碼中的缺陷和問題，使用者不僅更願意進行修復，而且修復的成本也將大大降低。這是一個值得探索的方向。

但通用 Agent 會遇到一些挑戰

儘管我們現在可以看到市場上有很多標榜為通用 Agent 的產品，但實際上能夠處理通用或複雜任務的並不多。這些產品要麼不夠通用，要麼無法應對複雜的任務。我認為這主要是由於工程和技術模型兩個方面所面臨的挑戰。

其實當初我們看到 Devin 時，我們首先想到的是 Web IDE 的架構。我們認為，在瀏覽器中開啟的任務應當由後臺的一個獨立容器來處理。這一想法立即讓我聯想到了 Web IDE 的架構。

具體任務在一個環境中執行。在這個環境中，有一個“大腦”負責知識的引入、工具的使用、知識的壓縮以及模型的驅動。“大腦”的重要性體現在以下幾個方面：

通用 Agent 的效能受到 Engine、模型、各種 Prompt、工具篩選等方面的影響。在評估時，對於那些不確定性強的內容，我們需要進行模擬，並透過控制變數的方法找出關鍵的最佳化點。因此，建立一個能夠發現實現使用環境中問題的環境變得很重要只有透過評測我們才能明確改進的方向。

過去，在大規模模型的訓練和評估中，通常採用的是以 Query 和 Answer 為核心的評價方式。

這種評測集的特點通常是易於實施和評估的，比如 Pass @ 1 或者 EM、ES 等評估策略，通常是一組標準化的測試資料（輸入 – 輸出對），用於量化模型在特定任務上的表現。其目的在於提供統一的評估標準，以便橫向比較不同模型的能力（如準確性、穩健性和泛化能力）。例如 GLUE（自然語言理解）、MMLU（多學科知識）、HumanEval（程式碼生成）等。有些評測集，如 SWE-Bench，則設定了若干實際世界中的程式設計問題供智慧體解決。

然而，這類評測集僅能用於評估與編碼相關的智慧體能力，而無法全面反映通用型智慧體的綜合能力。因為在很多情況下，僅僅評估最終結果並不合理，因為智慧體產生的輸出往往不是標準化的，例如在一個需求調研任務中，我們難以透過產出直接判斷智慧體的質量，或這種評價本身就是主觀的。此外，評測的另一目的還在於最佳化整體設計架構，單純的結果評估很難揭示問題究竟出現在規劃階段、記憶階段還是工具選擇階段。

當然，評估過程本身也充滿挑戰，因為智慧體的執行過程是動態變化的，由模型驅動，每次生成的計劃不盡相同，所用工具也可能有所差異，因此嚴格對比變得困難。即便我們嘗試評估過程細節，比如具體進行了哪些規劃步驟，使用了多少步驟，這些資料的具體意義仍不易解釋清楚。因此，針對通用型智慧體產品的評測是一項行業難題，或許需要引入人工評估的方式，甚至為展示其通用性，還需構建多種突發場景來考察其應對能力，這些都是需要考慮的因素。

人在面對複雜問題時，儘管也是逐步推進，但在每完成一步後，往往會無意識地對資訊進行壓縮處理。例如，在理解一段複雜的程式碼邏輯時，你不必記住讀過的每一個字元；相反，你會大致掌握其內容，然後轉向其他檔案。這樣，你就能夠持續處理新任務。當後續任務需要之前的具體資訊時，再回過頭來查閱細節。這就是人類如何透過資訊壓縮與提取來管理資訊的方式，這一能力同樣適用於 Agent。

Agent 的記憶機制分為兩類：短期記憶和長期記憶，它們分別應對不同的需求。

在處理複雜任務時，由於模型的上下文長度受限，即便未來模型的上下文容量得以擴充套件，仍需依賴資訊壓縮功能。過多的資訊可能會導致關鍵點被忽略，因此短期記憶中的資訊壓縮有助於提煉出核心要點。Devin 產品的介面設計體現了這種壓縮能力，即在每個步驟完成後展示壓縮後的記憶摘要，而不是詳盡記錄每項操作，以便為後續步驟提供概要參考。

但是，單純地透過壓縮也有其侷限性，因為模型壓縮可能會忽視某些對複雜任務至關重要的細節資訊，例如我們在測試的時候發現 Agent 生成一組使用者名稱和密碼，然後轉頭就忘了，這就考驗瞭解決問題的工程技術能力。

如前所述，通用 Agent 應該擁有反思與學習總結的能力，這也是模型與 Agent 之間的區別之一。Agent 在學習過程中不斷進步，並掌握處理新任務的方法，因此 Agent 或許具有規模效應——使用者越多，它就越智慧。這種能力的具體表現就是“長期記憶”。每當使用者完成一項任務後，我們可以讓模型整理出一份可供日後參考的經驗資料。這樣，在 Agent 遇到新問題時，可以調取這些經驗來指導模型如何應對，從而實現了某種形式的長期記憶。Devin 則是透過 Knowledge 的方式來進行儲存，例如，在執行某項任務的過程中，透過對模型輸出進行校正，生成了一份可利用的知識。

不過，這種處理方式仍然顯得相當粗獷。主要是因為，一種知識在一個特定情境中可能非常有效，但在另一個情境下卻未必如此。例如，牛頓力學在宏觀和低速的世界裡表現得極為出色，然而當速度接近光速時便不再適用；同樣地，抗生素能夠有效地殺死細菌，但對於病毒則無能為力。因此，將成功的經驗固化為固定的“Agent 心智”，實際上也限制了模型的能力。如何根據具體的情境來甄別並利用這些經驗，並且恰當地掌握這一平衡點，本身就是一項重大的技術挑戰。

工程上的挑戰其實還是能夠克服的，畢竟有大量可借鑑的產品，我們也可以透過各種方法和產品手段來避免一些問題。然而，對於“模型驅動”的 Agent 產品來說，模型能力方面的挑戰更為艱鉅。當前，幾乎所有開發通用 Agent 產品的公司都將 Claude Sonnet 視為首選模型，因為除此之外，其他模型都無法很好地推動複雜任務的解決，模型能力的欠缺是我們比較擔心。

複雜的任務之所以複雜，在於判斷與限制條件多，約束多，對模型的要求也隨之增多，通常會組合成一個極其複雜的 Prompt，模型能遵循的指令越多，它能處理的問題就越複雜。然而，除 Claude 系列外，其他模型往往難以達到這一標準。

部分模型存在不遵循指令的情況，而且非常普遍，例如我明確告訴他不要轉義

但程式碼還是轉義了

主要體現為當噪音資訊變多時，找到關鍵資訊、理解能力會變弱。

某模型放入過多額外資訊時生成的流程圖，可以看到許多中間步驟被模型忽略了。

某模型僅保留關鍵資訊時生成的流程圖，如果去除掉一些細節資訊，模型就能找出更完整的鏈路。

複雜的任務之所以顯得複雜，要麼是因為其上下文字身就很長，例如 程式碼，或者在執行長步驟任務時，需要記憶更多上下文資訊。對於複雜任務，特別是涉及幾十甚至上百步的任務而言，把握住長上下文中關鍵的資訊至關重要。

推理與規劃能力是通用 Agent 解決複雜問題的關鍵。這種能力使得智慧體能夠分析問題、制定解決方案的步驟，並在執行過程中進行調整。Devin 在產品上會先為任務制定一個計劃，然後向用戶展示執行規劃的步驟。

而在我們執行任務的過程中遇到變化時， Devin 會調整他的計劃。這與人類相似，在完成一項複雜的任務時，人們通常也無法一開始就制定出一個完美的計劃，而是會在實施過程中不斷進行調整。

這個圖反應了，Agent 存在的挑戰不僅僅是一次性就把事情做好，而是在一個長鏈路任務下需要具備反思和的能力

在之前，訓練過程中透過計算 Loss 來降低梯度，從而提升模型效果。這種點對點的模型能力提升，在過去的打榜或 ChatBot 等產品形態中確實取得了巨大成功。然而，在 Agent 場景下，以往極致地最佳化區域性最優解並不一定能成為全域性最優解。例如，一個多步驟任務從 a 到 b 再到 c 和 d，雖然每一步都是最優的，但對於整個任務而言，a 直接到 d 可能才是最優路徑。過去的經驗表明，無論國外模型釋出何種新功能，國內的開源模型總能迅速跟進，這一次是否依然能夠順利實現呢？

另一個問題是，Claude 作為一個斷檔級別的存在，其優秀之處遠不止於編寫程式碼的能力，它在幾乎所有能力上都處於領先地位。近期與許多同行交流後發現，大家似乎尚未充分認識到這一點，在如何使我們的模型在指令遵循、長上下文理解、規劃及反思等方面達到 Agent 能使用的水平的問題上毫無頭緒。究竟是由於其基礎能力強大且資料質量較高所致，還是採用了某些特殊的訓練方法或標註手段使其具備如此強大，目前外界對此一無所知。要知道，Claude 3.5 Sonnet 已經是在去年六月釋出的，這是令人比較擔心的。

我們最近也在與其他演算法團隊進行溝通，希望能夠儘快提升模型效能，包括建立適用於 Agent 任務的評估體系，以及建立能夠讓 Agent 執行的模擬環境等措施，以期幫助演算法團隊更快地縮短與 Claude 之間的差距，並推動國內儘快實現真正具備 Agent 能力的大模型。

最近有一種觀點認為，Agent 會被模型取代，認為“模型即應用”。但我的判斷是：通用 Agent 並不會被取代。通用 Agent 與模型之間是一種共生的關係——Agent 像為模型這個“大腦”裝上了“手腳”，賦予了它行動（Action）的能力。只要保持 Agent 架構的簡潔性，並且不透過流程編排來限制模型的能力，Agent 就能夠隨著模型能力的提升變得更加強大和通用。實際上，Agent 會直接受益於模型泛化能力的提高。

目前，模型的結構和推理能力存在著固有的侷限，而 Agent 正好可以幫助模型應對環境感知、記憶儲存以及工具使用等一系列系統性的問題。“大腦”般的模型自身無法長出手腳去採取行動，通用 Agent 實質上就是一個為模型裝備行動器官的技術解決方案。

甚至通用 Agent 還可能會產生規模效應，透過工程技術讓模型具備持續反思和學習的能力，而這正是現有模型結構所無法實現的。

然而，隨著模型能力的不斷提升，那些以工作流（Workflow）為核心的專業 Agent 確實有可能被淘汰。因為現在許多專為人工編排設計的功能，在將來很可能可以由模型自動完成。這種更高層次的自動化編排能力，將會使某些專業 Agent 失去存在的意義。

此刻，人類正站在人機協作進化的轉折點——Agent 不是迭代，而是劃時代的正規化革命！這是繼圖形介面、移動網際網路之後，我們這一代人親手定義未來技術正規化的終極戰場。

大家也可以關注我們的校招和社招崗位

向邦宇，阿里巴巴程式碼平臺負責人，內部智慧研發產品負責人，在程式碼管理、程式碼結構化資料處理、程式碼搜尋、程式碼評審以及編輯器技術等領域擁有豐富的專業知識和實踐經驗。在阿里主導了內部研發智慧化的發展，開發阿里內部 Copilot 和 Agent 等 AI 產品，被內部同學大範圍應用。

在 AI 大模型重塑軟體開發的時代，我們如何把握變革？如何突破技術邊界？4 月 10-12 日，QCon 全球軟體開發大會· 北京站 邀你共赴 3 天沉浸式學習之約，跳出「技術繭房」，探索前沿科技的無限可能。

本次大會將匯聚頂尖技術專家、創新實踐者，共同探討多行業 AI 落地應用，分享一手實踐經驗，深度參與 DeepSeek 主題圓桌，洞見未來趨勢。