智慧研發是快速發展又充滿挑戰的領域，除了捲上天的程式碼補全，基於程式碼的普通會話等場景外，還有基於大模型的 CodeReview，單測生成等能力陸續被開發出來並投入使用，也有部分團隊開始探索端到端的生成程式碼，不過，隨著大家在產品上越多的探索，人們對它解決複雜問題越來越缺乏信心了，問題究竟出在哪兒呢？是模型能力的問題還是發展階段的問題？在智慧化發展的現階段我們應該做些什麼呢？在 InfoQ 舉辦的 QCon 全球軟體開發大會 上，阿里巴巴程式碼平臺負責人向邦宇分享了“從 0 到 1，從 1 到 10：阿里在智慧研發中的大模型應用與挑戰”，他結合在阿里內部的探索經驗介紹大模型在各個發展階段遇到的問題和解決思路。
內容亮點
-
阿里內部的智慧化產品是如何資料驅動和業務驅動智慧化產品發展的，有哪些可借鑑的經驗
-
瞭解當前大模型解決複雜問題上到底遇到了什麼問題
-
瞭解內部智慧化產品和工具存在的意義是什麼，相比起外部第三方產品有哪些優勢
以下是演講實錄（經 InfoQ 進行不改變原意的編輯整理）。
四個月之前，QCon 大會會務組邀請我來做分享，當時希望講述我們在內部研發工具的發展歷程。然而，在過去的四個月裡，我們經歷了諸多變化，包括外部產品的更新，還有 Agent 理論以及模型技術的進步。因此，我們現在正將大量精力投入到 Agent 方向的拓展上。最近，我一直在修改 PPT，希望能夠將我們近期的工作進展、在 Agent 方面的思考以及取得的成果與大家分享。
阿里巴巴在智慧研發工具領域的探索起步較早，大約在 2023 年 3 月就開始啟動，至今已經過去了兩年多的時間。探索主要集中在以下幾個方面：首先，在程式設計場景方面，我們進行了多方面的嘗試，包括程式碼補全和程式碼會話功能。此外，我們還涉足了 Prompt 市場，希望透過這種方式讓使用者能夠更便捷地結合大模型的能力與整合開發環境（IDE）進行開發。
其次，在程式碼審查（code review）方面，我們是較早投入的團隊之一。目前，我們已經取得了一些成果，例如透過大模型對程式碼進行總結，幫助使用者發現程式碼中的問題，並且利用 AI 技術直接輔助使用者修改程式碼。
第三，由於工具是面向內部研發的，因此我們能夠與阿里巴巴內部的多個業務以及垂直業務進行深度整合。為此，我們開發了一個 extension 功能，以更好地支援這種整合。
第四，我們在 Agent 領域也進行了較早的投入。我們在專用 Agent 和通用 Agent 上都進行了探索，這些 Agent 被應用於程式碼補全功能，例如在內部 Copilot 外掛上，我們提供了兩種補全方式：一種是傳統的程式碼補全，另一種是多行補全，類似於 Cursor 這樣的多行編輯能力。這是我們在程式碼補全方面的拓展，也是我們與垂直業務整合的一個應用場景。
在 Prompt 市場方面，我們最初發布的功能較少，主要是希望透過快捷指令功能，讓使用者能夠快速使用大模型的能力，並與 IDE 進行結合。此外，我們還發現業務中存在許多自有工具、業務產品知識以及大模型的能力。因此，我們希望透過讓使用者能夠自行編排流程或呼叫工具，來實現一些垂直場景的整合，這就是我們所說的 extensions 功能。
我們在 code review 場景中進行了大量探索，這已經成為我們內部廣泛應用 AI 的一個重要領域。首先，我們開發了程式碼掃描功能，解決了當前大多數外部產品在程式碼審查時的一個痛點問題。目前，大多數外部產品在進行程式碼審查時，只能提供一個大致的總結，指出使用者提交的程式碼中存在哪些問題，但無法精確到具體行。而我們透過大模型技術，能夠直接定位到有問題的程式碼行，並且為使用者提供了一個採納按鈕。然而，過去我們雖然能夠指出具體哪一行有問題，但使用者往往不願意採納建議，因為採納後他們需要將程式碼拉取到本地，修改後再上傳，整個過程較為繁瑣。因此，我們進一步開發了一個“建議”功能，直接為使用者提供一鍵修改的建議，使用者可以直接採納這些建議，從而簡化了整個流程。這個功能目前在我們公司非常受歡迎。
我們還開發了程式碼總結功能。在過去，我們集團內部的許多開發者並沒有養成對程式碼進行總結的習慣。然而，我們希望透過實施 AI 應用，積累大量程式碼與自然語言關聯的資料，以便未來用於垂直業務的生成。因此，我們利用 AI 技術自動為使用者生成程式碼總結，這些資料未來可以用於支援垂直業務的發展。
我們在內部產品的指標方面，目前的日活數量大約為 12,000 人，集團內部的滲透率大概在 65% 左右。在程式碼補全方面，整體採納率約為 28%。由於阿里巴巴內部廣泛使用 Java，因此在 IntelliJ IDEA 上的程式碼補全採納率更高，大約為 33%。在 Code Review 方面，目前大約 20% 的程式碼審查問題是由 AI 生成的。
儘管在阿里巴巴內部有大量使用者使用我們的產品，並且我們在滲透率以及與現有平臺的整合方面都做了很多工作，但另一方面，我們內部存在許多 DevOps 平臺，包括程式碼平臺、需求管理平臺、釋出平臺和監控平臺等。從理論上講，我們應該能夠與外部產品形成差異化，並開展許多垂直領域的探索。然而在過去一段時間裡，雖然一線研發人員覺得工具在提升效率方面表現不錯，但對於一些非一線研發人員，他們可能認為效率提升還不夠。非一線可能希望從需求能夠直接轉換成程式碼，或者需求能夠直接上線，這才是他們眼中最高的效率提升。因此，我們嘗試了許多方法，試圖從端到端的角度去解決這個問題，但效果仍然不太令人滿意。
事實上，我們公司內部有大量可以整合的資料。程式碼平臺不僅記錄了每個使用者、每個開發者所編寫的程式碼背景，還涵蓋了他們的需求、修改了哪些檔案、檔案是如何修改的，以及具體的改動點等資訊。我們還會幫助開發者總結這些內容，並將其與需求和缺陷相關聯。此外，我們能夠透過程式碼倉庫追蹤倉庫的演化過程，包括需求的變更原因、程式碼的修改原因等。從理論上講，這些資料構成了一個非常有價值的倉庫演化歷史、程式碼演化歷史以及變更事件和運維監控事件的集合，它們本應被充分利用。
我們希望將使用者的介面、業務知識、文件、程式碼庫以及專家經驗整合起來，同時結合大模型的能力，如分類等功能，併為使用者提供我們產品的 Copilot 入口和知識搜尋能力，從而生成一個擴充套件。然而，我們發現即使是場景非常明確的情況下，也很難實現完全自動化。在阿里巴巴內部，經過多年的發展，我們積累了大量的外掛化程式碼，可以透過學習原始程式碼庫來生成外掛程式碼。但即便如此，對於這些高度垂直化的需求，我們也發現很難直接生成滿足使用者期望的程式碼。原因主要有以下幾點：
-
工具理解能力有限：工具很難完全理解使用者的真實需求。即使是面對面溝通，人們也很難完全清晰地表達需求，因此工具在理解邊界條件和約束條件時往往存在不足，難以準確把握使用者意圖。
-
使用者需求描述不清晰：使用者通常不擅長清晰地描述需求。他們可能隨意描述一個需求並嘗試使用工具，但如果 AI 生成的結果與預期有偏差，使用者往往會放棄使用。
-
領域知識整合困難：領域知識往往難以有效整合和理解。例如，開發者在提出需求時，程式碼中對同一概念的命名可能不一致（如商品可能被稱為“item”或“product”），這使得工具難以將使用者大腦中的知識轉化為模型可以學習的內容。
-
使用者使用成本高：我們為使用者生成的程式碼通常只能達到 85% 甚至 90% 的完成度，使用者仍需在本地修改程式碼並進行測試。這導致使用者使用成本較高，進而影響留存率。
大模型目前仍存在一些缺陷。首先，模型的可靠性不足，尤其是在處理複雜問題時，需要大量上下文資訊。我們可能需要透過 Embedding 技術搜尋大量資料，然後讓大模型直接生成結果，但在這個過程中，大模型的上下文視窗往往不夠大。其次，即使提供了很大的上下文視窗，隨著輸入內容的增加，模型抓取關鍵資訊的能力會變弱。此外，大模型還缺乏逐步解決問題的能力。雖然推理模型可以透過擴充套件 tokens 來解決推理問題，但目前推理模型仍存在速度慢或 tokens 過多的問題。
在內部平臺方面，我們發現平臺間的資訊整合並沒有做好。公司內部有多個平臺，如需求管理平臺、程式碼平臺、釋出平臺和測試平臺等，這些平臺在過去通常是分開部署的，透過 API 進行整合。但在大模型時代，由於資料不連通，很難在答疑場景中獲取使用者的完整上下文資訊，導致平臺間資訊整合困難。
此外，經驗和知識的利用也存在問題。公司內部有大量的資料和文件，但這些文件質量參差不齊，容易過時，且缺乏有效的維護策略。文件中大量的圖片資訊沒有被很好地解析，過去我們在文件中習慣插入大量圖片，而文字資訊反而較少。在處理 Embedding 時，我們往往會忽略這些圖片和影片，因為缺乏有效的多模態模型來理解它們。這導致我們在處理文件時，不僅文件質量差，還丟失了很多重要的資訊。
因為歷史原因，使用者的提交歷史、提交資訊以及程式碼審查描述等都沒有被規範化，導致我們在使用這些資料時，研發資訊難以串聯，挖掘成本極高。我們嘗試透過激勵措施（如咖啡券）鼓勵團隊成員編寫文件和知識，但發現這種方法不可持續，一旦系統更新，資訊又會過時。
在工程上下文方面，IDE 可以很好地解決工程上下文問題，例如在檢視程式碼時，可以方便地跳轉到函式或變數的定義，瞭解類的作用等。但一旦脫離 IDE，解決工程上下文問題的成本就會變得非常高。在程式碼審查場景中，雖然程式碼審查能夠發現很多問題，但這些問題往往侷限於程式碼本身，如錯別字、拼寫錯誤或程式碼風格問題。對於語法之外的問題，如業務邏輯或團隊規範問題，目前仍很難透過自動化工具解決，只能依賴人工審查。
在過去的一年裡，我們進行了大量的探索，包括與使用者知識庫的整合以及與使用者工具的融合，並取得了一些進展，但總體來說，結果並沒有那麼令人滿意。不過，令人欣喜的是，在過去半年中，我們觀察到外部出現了大量產品的更新、技術的進步以及理論的發展，這些都為我們內部產品帶來了新的機遇，也促使我們從 Copilot 向 Agent 方向轉變。接下來，我將介紹我們為何會有這樣的轉變，以及我們觀察到的一些現象。
首先，我們看到產品本身在不斷進步。 例如，像 Cursor、Windsurf 等工具，都為我們提供了許多新的思路。我們發現本地 IDE 的發展並沒有走到盡頭，它與人的協同和體驗提升仍有很大的挖掘空間。比如，多行補全功能在過去通常是基於游標位置逐行進行補全，但 Cursor 實現了在多個地方進行多行補全，我們也跟隨這一思路，在 JetBrains 上開發了類似的多行補全能力。另一個例子是“apply”功能，過去在聊天對話中，使用者很難將大模型生成的程式碼插入到檔案中，因為需要找到合適的位置並解決編譯問題。但 Cursor 透過一鍵“apply”功能，可以直接將生成的程式碼插入到當前檔案中，這大大提升了使用者體驗，我們也在這方面進行了很多類似的探索。
其次，多模態模型的能力在不斷進步。 過去，多模態模型很難理解複雜的架構圖，但最近我們發現這一能力有了突飛猛進的發展。在實際業務中，許多系統（包括監控系統）的設計初衷是為了方便人類理解波動等資訊，但模型很難理解這些資訊。如今，多模態模型的價值逐漸顯現，它能夠解決許多問題，包括前面提到的文件中的圖片問題和業務架構圖問題。在解決業務上下文或場景上下文時，模型也能夠更容易地理解使用者意圖，比如透過直接截圖來理解使用者在特定場景下遇到的問題。
第三，技術的進步使得端到端程式碼生成能力越來越強。 雖然模型在生成某些 logo 時可能仍有不足，但在樣式、佈局和文字方面，生成的結果已經非常接近原圖。
第四，大模型開始擅長思考並解決複雜問題。 這主要得益於推理、模型的發展。過去，大模型更擅長快速思考，但如今它們開始學會像人一樣進行深入思考。人在理解複雜問題時，如果僅靠機率判斷，結果往往是不準確的。如今，大模型透過處理更長的 tokens，激發了其思考能力。一個典型的例子是，當直接詢問 ChatGPT 等模型“1 億以內最大的字數是多少”時，過去的模型可能會給出一個錯誤的結論。但現在的模型會告訴你它無法直接給出答案，而是提供一個 Python 指令碼，透過指令碼來解決問題。這表明模型開始瞭解自己的能力邊界，這對於 Agent 的發展是一個巨大的助力。因為在處理複雜的長任務或 Agent 任務時，如果模型不瞭解自己的能力邊界，可能會在許多步驟中給出錯誤的結論。
雖然我們集團內部有大量使用者在使用 AI 產品，但他們並不滿足於目前僅能解決類似 Copilot 這樣的問題，也不滿足於僅能實現 20% 到 30% 的效率提升。因此，隨著大模型能力的顯著提升，包括多模態能力、複雜任務指令的理解能力，以及模型對自身能力邊界的認知，我們今年上半年設定了一個重大目標：全面向 Agent 模式轉變。
在過去的技術發展中，我們經歷了幾個階段。最初是人驅動階段，在程式碼補全中，完全依靠人工編寫程式碼，並由人決定是否採納。隨後進入人與模型共同驅動階段，模型開始參與部分流程決策，例如提供一批工具供使用者在遇到問題時使用，由模型判斷應該使用何種工具，但整體流程仍然是固定的。這種模式本質上是基於規則的編排，無論是編寫指令碼還是透過拖拉拽的方式，都是人與模型共同驅動的。這種基於規則的模型在短期內能夠提升效率，例如在垂直場景中能夠快速見效。然而，我們逐漸發現這種模式也限制了模型的能力，例如在呼叫 RAG 等技術時，雖然能解決一些問題，但靈活性不足，無法應對需求或上下文的變化。此外，流程編排還面臨以下問題：
-
泛化能力不足：流程編排無法解決泛化問題，稍微改變需求或上下文，流程就可能不再適用。
-
成本高昂：為每個場景單獨構建流程的成本非常高，且依賴人工，而人的表現往往不穩定。
-
複雜任務難以應對：對於稍微複雜一點的任務，基於規則的驅動模式很難奏效，因為規則無法窮盡所有情況。
我們還注意到，像 Devin 這樣的工具透過模型驅動的方式取得了成功。Devin 能夠從零開始生成程式碼，在其容器環境中進行除錯，幫助使用者生成需求和技術調研。這種完全依賴模型驅動的模式，能夠在獨立環境中執行復雜任務並取得成功。因此，我們決定摒棄基於規則編排的模式，轉向模型驅動的 Agent 模式，以更好地利用模型的能力，提升效率和靈活性。
我們開發了兩個 Agent 產品。第一個是基於 IDE 的 Agent 模式。在這個模式下，使用者可以在 IDE 中提出需求，我們透過模型驅動的方式呼叫 Shell 能力、程式碼庫的搜尋能力，以及編輯欄位、讀取欄位等能力，來自動幫助使用者實現需求。這個 Agent 主要應用於以下幾個典型場景：
-
小需求的實現：快速響應使用者的小型需求。
-
倉庫理解：幫助使用者理解程式碼倉庫，這是目前使用者使用最多的功能之一。
-
場景左移：我們希望透過 Agent 將許多場景提前到開發早期階段。在脫離 IDE 後，業務上下文和工程上下文的問題很難解決。例如，在程式碼審查時，如果大模型僅獲取程式碼的差異，而沒有工程上下文，就很難理解程式碼修改的影響範圍。我們需要找到程式碼的呼叫鏈路，但在脫離 IDE 後很難實現。如果能夠在 IDE 中將 IDE 本身的定義（Definition）和引用（Reference）等資訊暴露給模型，讓模型能夠使用這些工具，理論上它應該能夠自動找到程式碼審查過程中複雜的呼叫鏈路關係，發現更深層次的問題。因此，我們希望將程式碼審查和缺陷掃描等任務左移，讓 Agent 在 IDE 中發揮更大的作用。這個 IDE 上的 Agent 是透過不斷反饋和逐步執行的方式執行的，即每執行一步就反饋一次，逐步推進任務。
我們還啟動了另一個產品，名為 Aone Agent。Aone Agent 與 Devin 非常相似，因為我們一直在強調透過模型驅動來解決複雜問題，並讓 Agent 具備自主思考、自主規劃、使用工具、反思和自我學習的能力。目前，我們已經實現了這樣的程度：使用者可以提出一個需求，需求提交後，系統會在後臺啟動一個容器，容器啟動後會執行一個引擎。例如，如果使用者要求生成一個五子棋遊戲，引擎會生成程式碼，並在容器中啟動一個 React 系統。啟動後，系統會執行五子棋遊戲，進行測試，查詢程式碼問題，並反思整個過程。使用者只需提出需求，例如“幫我生成一個五子棋遊戲”，Agent 就能透過模型驅動解決這個長任務的複雜鏈路問題。整個過程大約持續半小時，但程式碼的生成、除錯和預覽都是由 Agent 自動完成的。這就是我們在開發的另一個產品——通用 Agent。
我們沒有將這個產品的定位放在只能做某一個工作，我們把它的定位放在一個全研發全生命週期的提效，所以要求它既可以做業務調研。
也能做技術調研報告的生成
做行程規劃
透過需求描述實現後端需求程式碼
透過設計稿實現前端程式碼並除錯和預覽
只有這種在一個產品裡 All In One 的實現 Agent 產品才能實現效率的最大化，才能讓一個人成為一個團隊並提升十倍效率。
我們來對比一下兩個 Agent 產品，如下表所示：
在通用 Agent 的發展過程中，我們遇到了一些挑戰和問題。我們原本認為通用 Agent 應該具備非同步處理複雜任務的能力，但在實際操作中，我們遇到了工程和模型兩方面的問題。
架構設計中包含了 Multi-Agent 的概念。任務首先交給一個 Leader Agent，它負責將任務分發給子 Agent，並在服務端進行資料收集，例如理解程式碼倉庫和當前環境，然後進行任務規劃、拆解和分發。子 Agent 可以執行各種任務，如 terminal 操作、shell 呼叫、檔案操作、Web 服務呼叫以及 MCP 協議的 Agent 呼叫，並在容器中執行底層工具。Agent 架構需要解決幾個關鍵問題，包括記憶控制、記憶儲存（短期和長期）、任務分發、任務容器排程、事件分發與收集、協調控制、子 Agent 管理和通訊，以及核心服務層的工具使用、收集、整合和通訊。
通用 Agent 面臨的幾個關鍵問題包括：
記憶管理：在通用 Agent 中，記憶分為短期記憶和長期記憶。短期記憶對於處理多步驟任務至關重要，因為它可以防止 token 上下文過度膨脹，避免過多細節干擾模型判斷。人類在解決複雜問題時，也會在潛意識中對過去的步驟進行壓縮，只保留關鍵資訊。長期記憶則用於儲存成功解決複雜任務的經驗，以便未來的任務可以借鑑這些經驗。長期記憶也面臨召回問題，即不同環境下的記憶是否能夠複用，以及如何選擇性地召回記憶。
-
任務執行：整個執行過程在一個容器中進行，需要有效的任務排程和事件管理。
-
子 Agent 管理：需要對子 Agent 進行有效的管理和通訊，以確保任務的順利執行。
-
工具整合：核心服務層需要整合和使用各種工具，以支援 Agent 的多樣化任務。
這些是我們整個架構的核心組成部分，也是我們需要解決的關鍵問題。透過有效地管理記憶、排程任務、協調子 Agent 和整合工具，我們可以提升通用 Agent 處理複雜任務的能力，並使其能夠從成功經驗中學習，不斷最佳化任務執行策略。
在評估 Agent 時，尤其是當任務多達上百步或者任務鏈路非常長時，我們面臨兩個主要挑戰。首先，我們如何找到標準的輸入輸出來評估 Agent 的能力，即 Agent 是否能夠解決當前的複雜問題。其次，我們如何評估 Agent 的效率，因為僅僅有能力是不夠的，Agent 還需要在合理的時間內解決問題。
在過去，對於大模型的評估通常是基於一些評測集，如 HumanEval 等，這些評測集有標準答案或近似標準的答案。然而，在 Agent 的評估中，我們需要解決的問題更為複雜。我們不僅需要評估 Agent 的結果，還需要評估其過程。例如，一個簡單的任務人類可能半小時就能解決，但如果 Agent 需要一天時間才能解決，那麼其效率顯然是不足的。為了應對這些挑戰，評估方法包括兩個方面：
-
結果評估：我們透過一些用例集來評估 Agent 的能力，這些用例集可能包括從零到一的程式碼生成任務、需求調研或技術調研等任務。透過這些任務，我們可以評估 Agent 是否能夠完成這些工作。
-
過程評估：由於 Multi-Agent 架構可以將任務分解，我們也會在不同的環節生成用例集，對 Agent 的中間過程進行評估。這樣，我們不僅可以瞭解 Agent 是否能夠完成任務，還可以瞭解它是如何完成任務的，以及完成任務的效率如何。
在工具使用方面也存在挑戰。Agent 在執行任務時需要使用大量工具，包括瀏覽器、shell 和 terminal 等。然而，Agent 在當前階段對於這些工具的使用能力還有所不足。我們也注意到許多創業公司正在開發面向 AI 的瀏覽器。例如，當我們要求 Agent 申請一個五子棋遊戲並預覽時，如果遊戲打開出錯，人類可能會立即開啟瀏覽器的控制檯檢視錯誤資訊，但對於 Agent 來說，它很難知道接下來該如何解決問題。另一個挑戰是工具之間的通訊問題。當主 Agent 指示子 Agent 進行系統測試時，如果之前生成的使用者名稱和密碼沒有傳遞給子 Agent，子 Agent 可能會不斷嘗試不同的使用者名稱和密碼來登入，而不是詢問主 Agent 獲取正確的憑據。這涉及到 Agent 與工具之間通訊的問題。
在大模型方面，我們也面臨一些挑戰。首先是指令跟隨能力的問題。例如，當我們指示 Agent 生成一個 HTML 郵件時，如果明確指出不要使用轉義符，但 Agent 仍然堅決使用轉義符，或者當我們要求 Agent 按照五子棋規則進行測試時，Agent 卻逐個嘗試無效的黑白棋步，這些都是我們在過程中遇到的問題。此外，還有指令上下文長度的問題。當給模型提供非常長的上下文時，模型捕捉隱藏細節資訊的能力較弱。例如，如果我們給模型一個複雜的檔案，並要求它生成呼叫鏈路圖，模型可能會忽略很多細節。但如果我們先從檔案中剔除一些註釋或不重要的資訊，然後再讓模型生成呼叫鏈路圖，它就能夠找到更多關鍵的鏈路資訊。
在模型推理和反思能力方面，我們認為 Agent 面臨兩個主要問題。首先，Agent 在尋找解決方案時可能會誤入歧途，而且可能無法意識到如何回到正確的軌道上，這表明其反思能力不足。其次，Agent 可能會陷入死迴圈，例如在下載失敗時不斷嘗試，而不是尋找其他解決方案。這種推理和反思能力的不足是 Agent 解決複雜問題的關鍵障礙。
我們擔心的一個問題是，在解決通用 Agent 的複雜任務場景時，許多演算法團隊可能還沒有充分意識到長任務鏈路上解決問題能力的重要性。過去的模型訓練通常以降低損失（Loss）為目標，這在處理區域性最優解的單步任務（如聊天機器人或程式碼補全）時是有效的。然而，Agent 模式涉及的是長鏈路任務，可能需要多步驟、反饋、反思和重新規劃，這些都是複雜任務的一部分。當前的大模型擅長解決區域性問題，但對於全域性最優解的 Agent 目標則顯得不足。
另一個擔憂是，具備 Agent 能力的模型並不多，所以這塊暫時比較依賴國外模型，我們與許多演算法團隊交流後發現，他們可能還沒有意識到在長任務鏈路上解決問題的能力的重要性。我們希望國內的演算法團隊儘早重視這個問題，解決 Agent 實際會遇到的問題。
依賴外部模型來執行 Agent 存在幾個問題：
-
成本問題：這些模型非常昂貴，例如，使用 Claude 服務的一個任務可能需要 50 到 80 元人民幣，複雜任務的 token 和輸出特別長，步驟也特別多，導致成本高昂，難以大規模推廣
-
隱私問題：使用外部閉源模型可能涉及資料隱私問題，這是許多開源 Agent 創新團隊共同面臨的問題。
-
限流風險：外部模型可能存在限流風險，因為外部模型提供商可能也在嘗試開發自己的 Agent 產品，他們擁有強大的模型，這給他們在 Agent 領域帶來了優勢。
-
被降智的風險：如果將來與模型提供商成為競爭對手，他們可能會降低我們依賴的模型的智慧水平，這是我們無法探測到的。
我們認為，通用 Agent 在實現非同步任務時，可能會帶來 10 倍的效率提升，這是一個非常理想的狀態，即我們只需將任務交給 Agent，讓它自己呼叫工具並與公司內部業務整合，從而實現大幅效率提升。然而，這存在一個嚴重的問題，即安全風險，包括自動駕駛可能存在的不可預測性和非同步執行的不可控性，我們無法即時監控。此外，還有隱私問題，例如 Agent 可能會過度收集資料，如財產資料、HR 資料等。還有一個授權邊界問題，使用者可能不清楚 Agent 被授予的許可權將用於什麼，例如，我們給 Agent 刪除倉庫的許可權，但不知道模型何時會使用它，這存在一個信任問題。最後一個問題是責任歸屬，如果我們將任務交給通用 Agent，它能夠大幅度提升效率，那麼操作者是人還是 Agent？如果造成不可挽回的損失，責任應該歸咎於 Agent 還是人？這是我們在理論上或業界應該共同面對和探討的問題。
此刻，人類正站在人機協作進化的轉折點——Agent 不是迭代，而是劃時代的正規化革命！這是繼圖形介面、移動網際網路之後，我們這一代人親手定義未來技術正規化的終極戰場。
你是否厭倦了在技術舒適區重複勞動？是否渴望在職業生涯中觸控真正的技術奇點？如果你對重構人機關係底層邏輯感到好奇，如果你對解決這些未知又複雜的問題感到興奮，不論是演算法還是工程，都歡迎加入我們。
有意者歡迎聯絡：[email protected]
向邦宇，阿里巴巴程式碼平臺負責人，在程式碼管理、程式碼結構化資料處理、程式碼搜尋、程式碼評審以及編輯器技術等領域擁有豐富的專業知識和實踐經驗。在阿里，他負責了包括 CloudIDE、程式碼搜尋、CodeReview 等多個關鍵產品的開發與管理，成功引領了程式碼智慧平臺的建設與發展。他主導實現的阿里內部多個前沿 AI 應用，包括程式碼續寫、Extensions、Workspace 等等，在阿里內部被廣泛使用，提升開發者的效率和質量。
日前，由極客邦旗下 InfoQ 中國主辦的 QCon 全球軟體開發大會在北京圓滿落幕。140 多場精彩演講放送，直擊行業痛點，為現場 1600+ 參會者傳遞可複製的經驗與模式。10 月 23 – 25 日，QCon 上海站即將召開，專題初步規劃見：https://qcon.infoq.cn/2025/shanghai/，如果你有相關案例想要分享，歡迎透過 https://jinshuju.com/f/Wz095d提交演講申請。