在2025雲棲大會現場，Qoder技術負責人陳鑫分享了Qoder產品研發背後的思考以及AI Coding的發展趨勢。他指出上下文工程正在逐漸取代提示詞工程成為主流，但上下文太長或太短都會影響模型的效果，為此Qoder做出了一系列優化設計，包括支持RepoWiki功能、集成記憶感知系統等。他還表示，未來多智能體架構是應對更長、更復雜任務的基石，但構建這樣多智能架構仍存在諸多技術挑戰，未來Qoder將繼續結合世界領先的模型和先進的工程能力，幫助開發者開發更加複雜的任務。
以下是演講全文：
感謝各位來到 Qoder 的專場，由我來給大家分享一下Qoder IDE背後的技術思考，回顧一下我們怎麼一步一步把產品做到世界領先的，以及我們對未來技術趨勢的判斷。
AI Coding 技術發展趨勢
第一部分先介紹 AI Coding 技術發展的三個趨勢：
趨勢一、從提示詞工程到上下文工程
一是大家熟知的，現在智能體已經從提示詞工程一步一步進化到了上下文工程，為什麼要把提示詞工程和上下文工程區分開，主要是大家工作的兩種形態發生了很大的變化，最早我們開發LLM應用的時候，更多是Chatbot，主要是編寫一些系統提示詞、優化Workflow、用户輸入的請求，經過一系列大模型的處理達到更好的效果。重點就是提示詞的改變和提示詞的封裝上面，以及讓開發者引入很多的上下文，然後把上下文組裝起來，告訴大模型。但是隨着Agent的快速發展，發生了很大的變化，為什麼叫上下文工程，除了原來的系統提示詞以外，還有非常多工具的提示詞去編寫，Agent最重要的是使用工具，除了使用工具，還在多輪的跟物理世界的迭代，讀取代碼寫代碼的過程中產生了很多工具的反饋，這些都需要一輪一輪的方式疊加到上下文裏面去，最終讓大模型知道走到哪一步，下一步怎麼辦，怎麼持續把用户的問題解掉。
這個過程中就會發現上下文的寬度嚴重不足了，過去18K就夠了，現在200K、300K，甚至1M都不夠。隨着大模型上下文越來越大，成本和開銷越大，速度也會越慢，而且大模型並不是對非常長的上下文都有着強的指令遵循能力。比如説世界頂級模型，最多也就是200K以內，甚至100K以內有相對較好的指令遵循能力。如果上下文越長就會出現模型理解力越差，甚至放在最前面的上下文就會忘記，這是大模型注意力機制的缺點。當然隨着大模型能力越來越好，更長上下文也具備很長注意力。我們必須在一個有限的上下文中，把解決問題最精準的內容放進去，這是關鍵的挑戰。所以在上下文工程我們也做了非常多的技術優化，接下來給大家一一呈現。
趨勢二、從短任務對話協同到長任務異步委派
第二個技術趨勢是從短任務的對話協同逐步到了長任務的異步委派。異步委派任務的相關思考和設計，核心帶來的就是兩種不同的人機交互模式：
- 對話式人機協同模式更多要不斷地手把手，迭代式的給AI進行交互，在這個過程中如果要調整模式，就希望AI有不懂的就要問，從而逐步地引導開發者，把問題澄清。
- 異步委派模式就需要追求準確的輸入、以及自主地完成編碼測試修復。原來對話式人機協同模式是AI把代碼寫出來，再詢問開發者要不要測試，但是異步委派這種頻繁的交互花費更多時間。現在我們就需要AI能夠自主地完成更長的任務、更復雜的任務和更多階段的任務，這是非常大的技術的演進。
趨勢三、從AI代碼生成到全鏈路軟件開發
AI Coding發展到全鏈路的軟件開發，之所以大家發現所有的產品都在聚焦於代碼生成、代碼編寫。開發人員工作力的提升，好像還沒有到測試和設計，為什麼呢？核心的原因有幾個：
- 大模型本身能力還不足以支撐端到端的研發，以及長時間任務的完成。
- 現在大模型在很多的複雜任務上的工程能力還沒達到。
- 研發任務是最簡單的補全編碼任務，再往後會發生什麼？大模型要理解你的需求設計，要能幫你做設計，要對複雜代碼庫做充分的理解，智能、能力要非常高，大家都知道寫一個代碼模塊簡單，做一個架構就難了，對阿里來説，可能得需要P7以上的員工做一個複雜架構設計，對人的要求很高，對AI的要求也高。
- 如果測試意味着什麼？一是AI要充分地理解複雜的需求和邏輯，這個時候沒有代碼，邏輯是抽象的。二是理解圖，甚至要界面上點一點，需要多模態的能力，這些都對大模型的能力有一個非常複雜的要求。
過去有一些傳統的做法，在CI/CD或者其他流程中把某一個模塊做AI化，這個不是叫AI原生的做法，AI原生的做法是今天讓AI像人一樣操作這些工具，自主地完成設計、編碼和測試的過程，我相信在不久的將來，可能6-12個月，這個全鏈路就會發生很大的變化，這是第一個預判。
企業的知識和經驗非常重要，我們在做很多企業級落地的時候會發現大模型之所以做不好，很多原因是因為我們工程的rules沒有寫好，一些編碼的API、知識沒有沉澱好。但是在過去落地的過程中發現沉澱這些知識和編輯維護這些知識，對於企業來講成本太高，所以我們嘗試了Repo Wiki，發現大模型來做知識的總結和沉澱可能更有效一點，所以未來會變成由AI驅動，然後企業其他研發作為補充的方式逐步的沉澱企業的經驗和優秀的知識，這是第二個預判。
Qoder產品背後的技術思考
前面介紹了三個最主要的發展趨勢，接下來從產品層面看一下關鍵能力背後的技術思考。
Qoder整體產品架構
其實對於Qoder產品，最重要的就是這三個能力，因為子功能非常多，我抽象為以下三種不同的編程形態：
- 第一種是代碼補全/NES：在編碼區，由開發者編碼，AI預測，它預測的是片段級的。
- 第二種是Agent Mode：對話式協同，根據用户要求迭代式修改代碼。
- 第三種是Quest Mode：端到端完成委派異步變成任務。
在以前，使用代碼補全的用户是遠遠大於使用Agent 的用户，但是在Qoder上，使用Agent Mode的用户是比做代碼補全的用户要多。這説明我們判斷的沒錯，即現在研發範式已經逐步地進入了Agent核心驅動的模式，所以Agent Mode是我們核心產品的能力，Quest Mode是我們的未來，工作負載越來越多的異步化，最終會在Quest Mode上面承載大量的研發任務。
接下來，我具體展開每一個核心產品能力背後的技術思考。
一、代碼補全/NES
代碼補全/NES是所有的開發者都可以使用的能力，原來只能做代碼補全，現在可以做下一個邊際未知預測，讓代碼補全能力從中間式補全變成可以用來做代碼的重構、規範的修正、錯誤的修復，還可以更加精準地預測開發者做下一步要幹什麼，這是能力的升級。
關鍵挑戰是合適的時機給開發者推薦合適的能力。過去代碼補全能力是開發者寫到哪，AI就續寫一段。但是NES不一樣，NES需要判斷開發者修改的變量在哪些地方引用了，在哪些地方逐一的修改，甚至另外的文件修改，重構也一樣，這塊函數改了，其他地方的函數要不要改，所以整體的預測難度就大幅度提升。我們通過不斷強化學習的想法合成開發者意圖的鏈路，最終不斷地優化。
二、智能對話 Agent Mode
智能對話Agent Mode是與開發者同步式協同的方式完成編碼任務，核心難點有：
- 理解代碼庫：我們面向的是非常複雜的真實軟件，大家可以把Agent執行的一個任務拆解成兩個核心的能力。但是這需要先理解代碼庫，理解工程，知道開發者輸入需求以後需要改哪些文件，需要學習什麼。
- 執行任務：把所有的信息收集好給AI，AI基於傳入的上下文準確的調用工具，準確完成編碼任務。
通過這兩步，我們構建了核心的代碼檢索能力和Agent能力。
三、工程知識可視 Repo Wiki
我們並不是第一家做Repo Wiki的，但是我們是第一家有能力把所有開發者的私有倉庫全部做成Wiki的產品，這是質的突破。其他家只能解決開源倉庫幾百個，上千個，我們可以解決上萬個、百萬個甚至上億倉庫的生成，核心就是在於我們專門精調Wiki專用的多智能體的架構，各種各樣的智能體負責生成，以及單獨訓練了Wiki的專用模型，才實現了既低成本又快速，又高質量的整體Wiki生成。
但是Wiki生成只是第一步，是整個在context戰略當中的第一環，因為它原來沒生成的時候，大家完全沒有更高層次的知識架構的呈現。基於此，生成的文檔首先用於開發者查看並支持分享的文檔，更重要的是，它未來也能夠幫助AI更深入地理解代碼庫。在未來長期的知識演進中，開發者可以持續貢獻知識，豐富知識庫。
大家知道在編寫真實需求的過程中，我們會有大量的暗知識、坑等，例如開發者寫完代碼沒有註釋，後來者就會踩坑。這些坑能不能讓AI感知人類標註的方式逐步沉澱，最終變成上下文，假以時日，AI就是這個團隊裏面最懂工程的角色，沒有之一。如果達成這樣，相信我們的效果會繼續往上提升一大截。
四、異步委派任務Quest Mode
異步委派任務 Quest Mode，通過Spec-Driven，Development的模式去實現智能體端到端交付編程任務。這個能力要求是非常高的，首先必須要有全球最頂級的大模型才能做；其次要有複雜多智能體架構和協同機制；最後要有比較強的遠程的沙箱環境容器大規模的調度能力，以及快速的雲端代碼檢索能力，這些能力全部具備，才能夠保證這個模式能工作。
大家發現，現在能夠做異步委派的產品比較少，耳熟能詳的就是幾家做大模型核心的廠商，當然阿里也是一個全球非常強的大模型的競爭者，所以基於這一套能力就可以順理成章的構建異步委派任務了。
Qoder技術優化路徑
前面簡單回顧了我們的產品和背後的技術思考和重要的要點，今天繼續下鑽一層，看看怎樣一步一步使用核心技術將Qoder打造成全球領先效果的產品。
一、Qoder代碼補全/NES能力進化
首先是最基礎的代碼補全和NES，其實從2023年開始做代碼補全能力，到2024年已經能達到了33%的採納率，全語言的平均值，這個值對於開發者來講效果已經非常好。但是我們在原來的代碼補全能力之上，又進化NES，就是下一個點位預測，包括工程本地的檢索、關聯的依賴檢索、相關型上下文、相似型上下文以及開發者的所有編輯軌跡，我們都做了非常長的上下文工程能力，同時，我們還配套專門訓練了NES模型，通過最新強化學習方法，一個大規模訓練的集羣，最終保證能力的持續進化。
二、面向未來模型能力，佈局Coding Agent技術
第二個就是Agent能力，我們面向未來的模型能力佈局了Coding Agent技術。通過我們對於Agent技術的判斷，實現了四種非常不一樣的人機交互模式。首先是智能對話的模式，這個是傳統Agent Mode；接下來人機協同技術設計界面、長程任務監督與干預界面、結果確認與驗證界面這三個模式都是面向未來的委派式的人機協同交互模式。大家認為長程任務也可以使用CLI運行，為什麼要用IDE，這就是開發者對於複雜任務的掌控。當任務越來越大，開發者如何洞察它、掌握它以及確認它是OK的，就一定需要複雜的GUI或者是複雜的研發流程協助的，而不是一句話就可以搞定，所有的交互一定是複雜的，任務複雜了，交互一定複雜，所以在這種背景下我們設計了一系列的交互的界面。
再深入就是支撐交互界面的核心技術，包括上下文管理技術、複雜工程管理技術、複雜工程理解和自主的記憶感知。今天除了擁有世界頂級的模型以外，包括代碼向量模型、重排模型、記憶模型、Wiki模型還有NES補全模型，全部都是我們精心訓練的。這些模型在相應的性能和推理速度上都達到了世界非常領先的水平，這也是我們產品相較於其他產品明顯感覺到不同的地方。
三、打造完整、極致的上下文工程能力
我們是如何打造完整、極致上下文工程能力的？其實剛開始就提到了做Agent最重要的就是上下文工程，包括四部分：
- 系統提示詞與工具：所有的大模型都有個性，不同的大模型對提示詞的感知不一樣，我們要針對不同的模型特點設計不同的工具，這是非常複雜的部分需要大量的評測和複雜的Agent框架去高效完成。
- 高效檢索：快速檢索到知識代碼和知識，給到大模型，這塊的核心要點就是全面、結構化，而且信息密度要足夠高。我們可以用一個超大上下文把所有的東西都塞進去，但是帶來的後果是模型注意力的下降、成本的暴增、速度變慢，這個結果開發者是不買賬的。今天我們要用最精準的方式找到解決問題最相關的代碼和知識送給模型，這是核心要突破的點。
- 自優化記憶感知：我們是希望能夠在開發者跟AI對話過程中，逐步讓AI總結開發者的行為習慣和過去的經驗教訓，形成一個記憶的體系，實現最懂開發者習慣和工作的人就是AI。為什麼今天一定要做記憶？還有一個數據跟大家分享，雖然一再強調rules是實現更高效果的核心，就是要打造各種各樣的rules給大模型，但是實際上能夠把rules用得好的人是百分之十以下，真正使用rules的也是非常小的比例，絕大部分的開發者是沒有能力對Agent做精細的調教，這樣效果就差了。我們用AI幫大家形成rules，所以記憶感知有一部分能力就是自優化、自迭代的rules，通過不斷地跟AI潛移默化的過程中，就讓rules變得豐富，這也是我們今天能夠給大家一個非常強能力核心的基礎。
- 上下文組織：通過靈活可擴展的Agent框架，實現緩存友好的智能體流程編排和上下文組織策略。針對工具執行策略、工具輸入信息、上下文壓縮等場景做經下滑調優，進一步優化上下文利用效率和執行成本。
四、新一代智能工程知識、代碼檢索技術
最早在2023年、2024年做代碼的語義檢索，就是傳統的RAG模式，通過Embedding、ranker去做代碼檢索，但是我們發現這還不夠，今天我們已經從傳統的RAG的代碼結構引擎變成真正意義的Context Engineer。現在傳給開發者已經不是關鍵詞了，而變成了一句話，今天大模型希望開發者給他返回什麼樣的東西，然後開發者通過語義關鍵詞引擎、代碼圖譜引擎和架構知識引擎，告訴大模型解決這個問題需要這些代碼，通過非常結構化的方式傳給它。好處是什麼？一次性獲取到所有解決問題的代碼，不需要進一步迭代了，就帶來了效率和成本大幅度的提升，解決問題更加精準。所以我們已經通過一些技術的能力將整個變成了Context Engineer。
五、具備自優化能力的記憶感知技術
我們開發者常説記憶系統是一個門檻比較低，人人都能做一個記憶系統，但要產生效果非常難。今天Qoder也是全球最早一波，甚至是現在做的功能最複雜的記憶感知體系。我們會根據開發者的代碼進行自動的抽取，也可以根據開發者跟AI Agent的對話做實時的抽取，背後有計算引擎考慮記憶的融合、彙總以及遺忘相關的機制，希望AI能夠模擬人，記住我們的行為、習慣以及我們的偏好，包括個人偏好、歷史經驗、系統知識，所有這一套再跟Context Engineer結合，就會發現現在AI不但能夠了解今天代碼庫裏面所有的細節，而且還能夠知道開發者想要什麼，提升開發者效率，避免每次對話都跟全新的人打交道一樣，例如上一個對話糾正了一個問題，下一次繼續犯錯，所以在Qoder裏面就不會發生這樣的問題，就是因為有了記憶感知體系。
六、緩存友好的上下文管理技術
我們打造了一個緩存友好的上下文管理技術，所有做Agent最重要的就是做緩存友好的上下文管理，尤其是我們給大家提供的能力是200K上下文。我們從一開始就定義要給大家提供非常長的上下文解決問題，這個過程當中有Tools Prompt精調、System Prompt精調以及User Prompt，包含工程結構、記憶、Rules，還有用户選擇context和用户query，所有的這些信息用一個非常複雜的結構拼起來，傳遞給大模型，讓大模型才能很好地幫助我們精準地完成任務。
七、智能體效果評測體系
最後是評測，怎麼知道效果變好了、開發者哪裏有問題，哪個模型適合什麼場景，有什麼偏好，怎樣路由等，我們希望實現模型的自動選擇。這是一個技術潮流，最新的OpenAI發佈了GPT5以後，就把模型選擇器下下掉了，它認為這個是一個糟糕的設計，開發者很難知道模型怎麼選，模型能力越來越強，邊界越來越模糊，選擇的難度就更大了。今天我們希望通過一個比較複雜的評測體系，能夠當一個模型推出的時候，可以幫助大家做好相應的評測和路由，最終達到很好的效果。現在越來越多的開發者是為了效果買單，而不是説接入了多少款模型，最終要的是效果、解決問題的速度。
Qoder未來的技術挑戰與應對
Qoder未來的技術挑戰與應對，我從來沒有見過軟件工程或者效能產品發展速度如此之快，所有的範式只有一年的生命週期，我們暢想一下未來發生什麼。
一、從設計、執行到驗證
全鏈路軟件研發實現更高準確率
我們認為今天要實現軟件研發，更高的準確率要做好三個階段：
第一個階段：Design，今天要想實現效能的提升，異步的委派，最重要的還是表達清楚需求。我們設計了Agent專門幫助開發者澄清需求，未來有80%的設計工作可以由AI來做。設計工作是一個價值高地，如果今天AI能夠統領代碼庫，甚至多個微服務的架構都能夠精確地設計好技術方案，這個對開發者來講時間是大大地提升，在座的開發者應該有體感，實際上我們很多工作都是在這兒，在前面的需求澄清和設計階段花費了大量的精力，我們希望通過Qoder能夠把這塊輔助了。
第二個階段：Act，我們做Agent Mode就是做這塊，能夠把代碼生成做得足夠好。
第三個階段：Verify，這個大家都沒有做好的，隨着代碼生成越來越多，不能靠人去Verify了，這個過程中除了簡單的單元測試，link錯誤修復，界面錯誤以外，我們今天能不能做集成測試，甚至是複雜的UI測試，這個也是價值高地。
如果這三個都能做到非常好，那一個任務端到端的交付就成為現實，這個時候效率就跟現在完全不一樣，現在還是需要人手把手把着AI。
二、多智能體架構應對更長更復雜任務
如果要實現三階段能力的端到端，一定需要一些技術的支撐，多智能體架構就是未來我們應對更長、更復雜任務的基石。這張圖是Devin公司做的，他是最早做多智能體架構的，他們在上面踩了很多坑，其實我們做多智能體架構的時候，核心要解決單智能體的上下文窗口受限問題，實現更長、更復雜任務，但是同時也引入了多智能體之間的信息共享、同步問題，有可能讓多智能體更容易失敗。
所以，我們一定要對多智能體進行精調，而且每一個Sub Agent都需要做非常好的開發，就像我們開發Agent Mode下面的工具一樣，實際上Sub Agent本質上也是一個工具，完成單個任務的時候要的內聚，以及跟主Agent要有足夠好的協同，這個系統是非常精妙的系統，我們要獨立邊界、完整的信息傳遞謹慎採用並行化，通過這些才能達到更好、更長任務的實現。
三、更多專用領域模型突破複雜任務成本瓶頸
最後的核心，我們做的所有的產品沒有模型一定就沒有競爭力的，在這個過程中，我們目標是用更多專業的模型突破複雜任務的成本和性能的上限，我們做了一系列的模型支撐Qoder，但是背後有幾十個模型為大家服務，最核心的就是智能體大模型。前幾天也看到了Qwen3 Qoder或者Qwen 3 Max等等一系列的模型發佈，海外也有非常多的模型發佈，我們會第一時間對這些模型進行評測和支持，實現更長上下文、更加複雜任務的執行。
除了這些還不夠，還需要一系列模型輔助，尤其是未來的Design、Act、Verify三階段裏面需要大量的模型支撐，包括記憶類模型、檢索類模型、Wiki生成的模型，以及各種Tools也需要專業訓練的模型，會話總結、代碼應用、Terminal的處理都可以用一個模型處理，可以讓場景更加泛化，信息提取更加精準，效果更加好，以及最早做的補全NES模型，整個這一套成了Qoder效果拔羣的基礎，也是我們最擅長，也是最能做好的事情。
今天我的分享就到這裏，謝謝大家！
歡迎用户到Qoder官網下載體驗！
官網地址：
下載體驗鏈接：https://qoder.com
關注我，掌握Qoder最新動態
