作者：陳鑫（神秀）
大家好，我是通義靈碼的產品技術負責人陳鑫。過去有八年時間，我都是在阿里集團做研發效能，即研發工具相關的工作。
我們從 2015 年開始做一站式 DevOps 平臺，然後打造了雲效，也就是將 DevOps 平臺實現雲化。到了 2023 年，我們明顯感覺到大模型時代來了以後，軟體工具將面臨著徹底的革新，大模型和軟體工具鏈的結合，使軟體研發進入下一個時代。
那它第一個落腳點在哪？實際上就是輔助程式設計，所以我們就開始打造了通義靈碼這款產品，它是一個基於程式碼大模型的的 AI 輔助工具。今天我借這個機會和大家分享通義靈碼技術實現上的一些細節以及我們如何看待大模型在軟體研發領域的發展。
我會分為三個部分來分享。第一部分先介紹 AIGC 對軟體研發的根本性影響，從宏觀上介紹當下的趨勢；第二部分將介紹 Copilot 模式，第三部分是未來軟體研發 Agent 產品的進展。為什麼我會提到 Copilot Agent，稍後我給大家講解。
AIGC 對軟體研發的根本性影響
這張圖是我過去幾年畫的一張圖，我認為企業研發效能的核心影響因素是這三點。
第一點是人員技能。 人員技能決定了企業研發效能的一個非常大的因素，比如說谷歌可以招聘到個人能力強於他人十倍的工程師，一個人等同於十個人，那由一群十倍工程師組成的一個小團體，戰鬥力就很強，甚至可以實現全棧，他們的角色分工可能就非常簡單，工作非常高效，最終的效能也非常大。
但是實際上我們企業內部，尤其是中國企業，沒有幾個能夠達到谷歌的水平。這是客觀影響因素，我們認為人員技能是效能基石，當然也是效能的破局點。
第二點是協同消耗。 在我們不可能要求每個工程師能力強大的基礎上，每個人一定是有專業分工的，比如有些做軟體設計，有些做開發、做測試、做專案管理。這些人組成的團隊隨著軟體架構的複雜度越來越大，組織的複雜度也會正相關的變大，這就造成了協同消耗也會越來越大，最終拖慢了整體的研發效能。
第三點是成本控制。 我們發現做專案的時候人員不可能總是富裕的，永遠是缺人手，也不可能有無限的資金去招到十倍工程師，所以這也是一個制約因素。
今天在 AIGC 的時代，這三個因素已經產生了一些根本性變化。
在人員技能上， 透過 AI 輔助可以快速將一些初級工程師的能力提升。這個其實在國外是有一些報導的，初級工程師使用了程式碼輔助工具的效果是明顯高於高階工程師的，為什麼呢？因為這些工具對於初級工作的替代，或者說它的輔助效果是非常好的，所以它可以快速補齊初級工程師的能力短板。
在協同消耗上， 如果今天 AI 能夠變成一個超級個體，實際上它對流程協同消耗的降低是有幫助的。比如一些簡單的工作就不需要跟人打交道了，AI 直接就可以做，也不需要給每個人都講一遍需求應該怎麼測試，AI 做簡單測試就可以了，這樣時間的效率就提升了。所以可以透過超級個體去有效的降低協同消耗。
在成本控制上， 實際上 AI 大量的用法就是代替事務性工作，包括現在用程式碼大模型去做程式碼輔助，也是希望代替 70% 的日常事務性勞動。
那具體來看的話，會有這四個挑戰以及智慧化的機會。
第一個是個體效率，剛剛也給大家介紹了，大量研發工程師的重複工作和簡單溝通都可以透過 AI 來完成了，它是一個 Copilot 模式。
另外一個協作效率，一些簡單的工作直接讓 AI 做，可以使協同消耗降低，這點剛剛我已經講述的比較清晰了。
第三個是研發體驗，過去 DevOps 工具鏈關注的是什麼？一個接一個拼成一個大的流水線，拼成整個的工具鏈。其實每個工具鏈在不同的企業裡可能有不同的使用習慣，甚至有不同的賬號體系、不同的介面、不同的互動、不同的許可權。這種複雜度給開發者帶來了非常大的上下文切換成本和理解成本，這在無形中讓開發者其實很不爽。
但是在 AI 時代發生了一些變化，我們可以透過統一的對話入口，用自然語言的方式去操作很多工具，甚至在自然語言的視窗裡解決很多的問題。
我舉個例子，比如過去查一個 SQL 到底有沒有效能問題，我們應該怎麼辦？可能先在程式碼裡面把 SQL 語句摳出來，把它變成一個可執行的語句，再放到一個 DMS 系統裡面診斷一下看看它有沒有用索引，有沒有問題，然後再人工判斷一下到底要不要改這個 SQL 去最佳化它，最後再到 IDE 裡把它變更掉，這個流程需要切換多個系統，要做很多的事情。
那在未來，如果我們有程式碼智慧工具的話，就可以圈選一個程式碼，問大模型這個 SQL 有沒有問題，這個大模型可以自主的呼叫一些工具，比如 DMS 系統去分析，並且拿到的結果可以直接透過大模型告訴我 SQL 應該如何最佳化，直接告訴我結果，我們只需要採納它就可以解決，整個操作鏈路會被縮短，體驗就會提升，從而提升研發效率。
第四個是數字資產，過去大家寫了程式碼放在那都變成了屎山程式碼或者說是負債，當然裡邊有非常多優秀的金礦沒有被挖掘出來，然後還有很多文件想要找的時候找不到了。
但是在 AI 時代，我們做的最重要的事之一就是需要去梳理我們的資產以及文件，透過 SFT、RAG 的方式去賦能給大模型，讓大模型變得更聰明，更加符合企業的個性化理解，所以今天這種人機互動方式的變化，會帶來體驗上的變化。
人工智慧從剛剛的幾個影響因素再往下拆，它核心是帶來了三種人機互動方式的變化。第一種是 AI 會變成一個 Copilot，和工具進行結合，然後人可以指揮它幫我們完成一些單點的工具。到第二階段，實際上大家應該有共識了，它變成 Agent，也就是它具備了一些自主完成任務的能力，包括自主寫程式碼或者做測試。其實工具扮演的是一個多領域專家，我們只需要給定上下文並完成知識對齊即可。第三個階段我們判斷 AI 可能會變成一個決策者，因為在第二階段決策者還是人，在第三階段有可能大模型會具備一些決策能力，包括更高階的資訊整合分析能力。這時候人會更多的聚焦於業務的創意和糾偏，很多事情都可以交給大模型做。透過這種不同的人機模式的變化，讓我們整體的工作效率會變高。
還有一點是我們剛剛講到的知識傳遞形式也發生了根本性的變化。在過去是透過口口相傳、透過培訓，老帶新去解決知識傳遞的問題。未來很有可能不需要這樣，只需要讓模型具備業務知識和領域經驗，讓每一個開發工程師都使用智慧化工具，它的這些知識就可以透過工具傳導到研發過程中，就會變成右邊圖上所示的現在 DevOps 的一站式工具鏈。積累了大量程式碼和文件資產後，將這些資產梳理清楚跟大模型放在一起，透過 RAG、SFT，模型嵌入到 DevOps 工具的各個鏈路，從而又產生更多資料，形成了這樣的正向迴圈，一線開發者在這個過程中就能享受到資產帶來的紅利或者說能力。
以上就是我從宏觀的角度介紹了現在大模型影響研發效率的核心因素，以及兩個最重要的形態改變：第一個是人機互動的形態發生了改變，第二個是知識傳遞的方式發生了根本性變化。 現在由於各種各樣的技術限制以及大模型發展階段的問題，我們做的最好的還是 Copilot 人機互動模式，所以接下來就介紹下我們的一些經驗，如何去打造最佳的這種 Copilot 人機互動模式。
打造最佳 Copilot 姿勢
我們認為程式碼開發的人機互動模式，目前只能解決比如小任務的問題、需要人工採納的問題、高頻次的問題，像程式碼補全，AI 幫我們生成一段，我們接納一段，再生成一段，再接納一段，這種頻次非常高的問題，還有短輸出的問題，不會說一下子就生成一個工程，甚至不會一下就生成一個類，我們每次都是生成一個函式或者幾行。為什麼要這樣來做呢？其實和模型本身能力的限制有很大關係。
因為我們現在上下文寬度還非常有限，假如要完成一個需求，沒有辦法把所有的背景知識全部交給它一次性搞定，所以要不就是透過 Agent 去拆成一堆的小任務，逐步解決。要不就在 Copilot 模式裡讓它完成一個最簡單的工作，比如按照一個註釋去生成一小段程式碼，這樣我們叫做解決小任務。
在人工採納上，人工現在必須對程式碼大模型生成的結果做判斷。目前做的好的可能也就是30%-40%的採納率，也就是說我們有超過一半的生成程式碼實際上是不準確的，或者是不符合開發者預期的，所以要不斷的消除幻覺問題。
但是讓大模型真正能在生產級使用最重要的還是要人工確認，然後高頻次是不要生成太多，每次生成一點，因為人工去確認這段程式碼是否 ok 的成本也是影響效能的，後文會講一些我們的思考和我們做的事情，透過高頻次去解決準確性率有限問題。另外短輸出主要是考慮效能和成本問題。
現在程式碼助手這種模式，實際上是特別精確的命中了大模型的一些技術限制，才讓這樣的產品能夠快速落地，它有一個非常好的時機。在我們看來，開發者最喜歡的 Copilot 模式，是以下四個關鍵詞：高頻剛需、觸手可及、知我所想、唯我專屬。
第一個是我們要解決高頻和剛需的場景，這才能讓開發者覺得這個東西是真的有用，而不是個玩具。
第二個是觸手可及，也就是隨時可以喚醒它，隨時可以幫我們解決問題。不再像以前需要透過各種搜尋引擎去搜尋程式碼，它就像在我身邊一樣，隨時可以喚醒它幫我解決問題。
第三個是知我所想，也就是它回答我問題的準確度，以及它在什麼時機回答我的問題都是非常重要的。
最後還要為我所屬，它能懂我私有的一些知識，而不是說只瞭解完全開源的東西。我們把這四點具體再展開討論一下。
高頻剛需
我們需要判斷什麼是軟體研發最高頻的場景。我這邊有一些真實的資料，第一個資料來自 JetBrains 在 2023 年做的一個開發者的生態報告，整理了開發者最耗時的活動，其中可以看到百分之七八十都是編寫程式碼，理解程式碼及網際網路搜尋、除錯、寫註釋、寫測試。這幾個場景實際上就是程式碼智慧工具的功能，像通義靈碼這樣的產品最核心解決的問題，其實就是最高頻的問題。
後面這兩個資料是通義靈碼線上幾十萬使用者的資料分析。我們現線上上採納的程式碼， 73% 來自於補全任務，27% 來自於問答任務的採納。所以今天大量的 AI 替代人去寫程式碼，還是在 IDE 的行間生成，這是從真實的情況下反映出來的一個結果。後面是使用問答功能的比例，有 76% 的比例是來自於研發問答，剩下的 10% 是程式碼最佳化和解釋程式碼等等一系列的程式碼任務。所以絕大部分的開發者還是在使用我們的工具去問一些常用的研發知識，或者透過自然語言的方式讓程式碼大模型生成一些演算法，解決一些小的問題。
其次的 23% 才是我們真正的一些細節的程式碼任務，這是給大家一個資料洞察。因此我們就有了核心的目標。第一，我們要解決好程式碼生成的問題，尤其是在行間生成。第二，要解決研發問題的準確度以及專業性問題。
觸手所及
我們最終要講的是打造沉浸式程式設計體驗，我們希望今天開發者絕大部分的問題都可以在 IDE 裡面解決，而不是需要跳出。
過去我們的體驗是什麼？是遇到問題去網際網路搜尋，或者問問別人，問了一圈以後再自己判斷，最終寫上程式碼複製放到 IDE 裡面除錯編譯，不透過了再去查，這樣的話就會非常耗時。我們希望能在 IDE 裡面直接問大模型，讓大模型幫我生成程式碼，這樣體驗就很爽。我們透過這樣的一個技術選擇，解決了沉浸式程式設計體驗的問題。
補全任務是一個效能敏感型任務，它的輸出需要在 300 到 500 毫秒，最好不要超過一秒，所以我們有一個小引數模型，它主要是用來生成程式碼的，而且它的大部分訓練語料也來自於程式碼。它雖然的模型引數很小，但是在程式碼生成的準確度上非常高。
第二個我們要去做好專項任務，我們還有 20%~30% 實際上的任務是來自於這些，包括註釋生成、單元測試、程式碼最佳化、運營錯誤排查等七項任務。
我們目前使用了一箇中等引數模型。這裡主要考慮的，一是生成效率，二是調優。一個非常大引數的模型，我們調優的成本是很大的，但是在這種中等引數模型上，它本身的程式碼理解和程式碼生成效果已經不錯了，所以我們選擇了中等引數模型。
然後在大模型上面，尤其是我們 70% 多的研發問題回答上，我們追求的是高精度，而且追求的是實時的一些知識。所以我們透過一個最大引數的模型，疊加了我們的 RAG 技術，讓它外掛了一個近乎於實時的基於網際網路的知識庫，所以它回答的質量和效果就非常高，並且能大幅消除模型幻覺，提升回答質量。我們透過這樣的三個模型支援了整個沉浸式程式設計的體驗。
第二點是我們要實現多端，因為只有覆蓋了更多的端，才可以覆蓋更多的開發者。目前通義靈碼支援 VS code 和 JetBrains，主要解決的是觸發問題、展示問題，還有一些互動性問題。
最核心層次下面，我們本地 Agent 服務是一個獨立的程序。這個程序跟上面的外掛之間會進行通訊。這個程序最主要解決的是程式碼核心的一些能力，包括程式碼智慧補全的部分，會話管理的部分，智慧體。
此外，語法分析服務也非常重要，我們要解決跨檔案引用的問題等，都需要語法分析。如果我們要做本地的檢索增強，我們還需要輕量級的本地向量檢索引擎。所以整個後端的服務實際上是透過這樣的方式就可以快速的實現擴端。
我們還有一個特色，我們有一個零點幾B的本地離線的小模型，來實現個別語言的單行補全，這是可以脫網去做的，包括 JetBrains 最近也上了一個跑在本地的小模型。透過這種方式，也會保證我們的一些資料安全隱私問題，比如本地的會話管理、本地的儲存，全部都放到了本地電腦上。
知我所想
知我所想對於 IDE 外掛這個工具而言，我認為有幾點。第一是觸發時機，在什麼時候觸發，對於開發者體驗的影響也非常大。比如我在空格的時候要不要觸發？IDE 已經生成提示的時候要不要觸發？在刪除這段程式碼的時候要不要觸發？我們大概有超過 30~50 個場景去梳理，到底在這個場景上要不要進行程式碼觸發，這部分透過規則就可以搞定，只要一點點細心去摸索，去調研開發者體驗，就可以解決，這不是很高深的技術。
但是在程式碼生成長度方面，我們認為是比較難的。 因為在不同的編輯區的不同的位置，它生成什麼樣長度程式碼，直接影響了我們的體驗。如果開發者只是傾向於生成單行程式碼，帶來的問題就是開發者不能理解整個生成的內容，比如生成一個函式，他不知道這個函式到底要幹什麼，生成一個 if 語句，他不知道 if 語句裡邊的業務邏輯是什麼，就沒有辦法完整的判斷功能單元，影響了他的體驗。
我們用一些固定的規則去做，也會導致一個問題，即它會比較死板。所以我們的做法實際上是基於程式碼的語義資訊，透過訓練的方式，經由大量的樣本，讓模型理解了今天在什麼場景下應該生成多長，我們實現了由模型自動判斷類級別、函式級別、邏輯塊級別及行級別的生成力度，我們把它叫做自適應的生成力度決策。我們透過做這項大量的預訓練，讓模型去感知，從而提升了生成的準確度，這塊我們認為也是一個比較關鍵的技術項。
再往下最關鍵的就是如何去消除模型的幻覺，因為只有幻覺得到足夠的消除，才能夠提升我們的採納率。所以我們一定要實現基於庫內的跨檔案上下文感知，在這裡，我們做了很多的基於程式碼的語義分析，引用鏈追蹤，相似程式碼以及動態語言型別推導等。
最關鍵的就是想方設法的去猜開發者在這個位置補全他可能需要什麼樣的背景知識，這些東西可能還會涉及到一些語言、框架、使用者習慣等，我們透過各種各樣的東西將它的上下文獲取出來，並且進行優先順序排序，把最關鍵的資訊放到上下文裡面去，然後給到大模型進行推導，讓大模型去消除幻覺。透過這樣的技術就可以實現跨檔案上下文感知的測試集，我們的準確率從 22% 提升到了 66.9% ，我們還在不斷的去精進提升補全的效果。
最後一個是我們本地的庫內檢索增強。剛剛其實也說了，上下文感知也只是猜測開發者在觸發位置的上下文。更多的場景是今天開發者要問一個問題，讓大模型基於本地的庫內所有檔案去幫我解決一個問題，比如幫我修復一個 bug，幫我增加一個需求，幫我填充一個檔案，自動實現增刪改查，甚至幫我的 Pompt 檔案增加一個新的包的版本，類似這樣的需求其實有很多，要實現的話實際上是要給大模型外掛一個檢索引擎。因為我們不可能把整個工程的檔案全部塞給大模型，因為上下文寬度的影響，我們必須使用到一個技術，叫做本地的庫內檢索增強。
這個功能就是來實現我們基於庫內的自由問答的，在本地去建立一個庫內的檢索增強服務，我們判斷這樣的方式對於開發者的體驗是最好的，安全性也是最高的。
程式碼不需要上傳到雲端，就可以完成整個鏈路。 從整個鏈路上來講，開發者問一個問題以後，我們就會去程式碼庫提取需求的關鍵資訊進行任務拆解，拆解完了做本地的向量檢索召回，然後再做檢索的結果合併及重排，以及去企業內部的資料知識庫檢索，因為企業有統一的知識庫管理，是企業級的。最終把全部的資訊彙總起來傳送給大模型，讓大模型去生成和解決問題。
唯我專屬
我覺得企業要想讓程式碼大模型真的能實現一個非常好的效果，都逃不過這一關。比如如何實現企業資料的個性化場景，比如在專案管理階段，如何能夠讓大模型按照需求/任務/缺陷內容的一些固有的格式和規範去生成，幫我們實現一些需求的自動拆解、自動續寫、自動總結等等。
開發階段可能是大家最關注的，經常有企業會講要有符合企業自己的程式碼規範，引用企業自己的二方庫，呼叫 API 生成 SQL，包括使用企業自研的一些前端框架、元件庫等等，這些都屬於開發場景。測試場景也要生成符合企業規範的，甚至是理解業務的測試用例。在運維場景，要時刻查詢企業的運維知識，然後去回答，去獲取企業的一些運維的 API 快速生成程式碼。這些都是我們認為要做的企業資料化個性化場景。具體的做法是要透過檢索增強或者微調訓練的方式來實現。
在這裡我列了一些簡單的場景和需要注意的事項，包括程式碼應該怎麼處理，文件應該怎麼處理，程式碼過來要進行過濾、清洗、結構化，然後才能夠可用。
在我們訓練的過程中，要去考慮開放域資料和私域資料的混入。比如我們要去做一些不同的引數調整，在檢索增強上，我們要考慮不同的檢索增強策略，我們其實也是在不斷的進行探索，包括如何在程式碼生成場景裡面命中我們所需要的上下文資訊，以及我們在問答場景裡面如何去命中我們需要的回答的上下文資訊，這屬於檢索增強。
我們要做的就是企業級的檢索增強方案，企業級的檢索增強方案目前的架構圖大概是這樣。中間是知識庫的管理服務，包括資料解析的排程、問題的理解、整理回答、結構化的解析、資料分塊等等，核心的能力在中間這塊，向下是我們比較常用的 Embedding 的服務，包括大模型的服務、向量的儲存和檢索。
向上是我們管理的一些後臺，在這個場景下支援了我們關於文件的檢索增強以及程式碼生成的檢索增強。程式碼生成也就是補全這個場景的檢索增強它所需要的處理方式和技術跟文件其實還是略有不同。
過去我們跟復旦大學也做過幾年的學術研究，非常感謝他們的付出，我們也有一些論文在發表，當時我們測試集的結果也是用一個一點幾B的模型，再配合檢索增強，它實際上的準確率和效果就可以達到一個大概 7B 以上模型的同等效果。
未來的軟體研發 Agent 產品演進
我們認為未來軟體研發一定會進入到 Agent 時代，也就是說它具備一些自主性，並且它可以非常容易使用我們的工具，然後理解人類的意圖，完成工作，最終會形成一個如圖所示的多智慧體的協同模式。
就在今年三月份，Devin 的誕生其實讓我們感覺到這個事情真真實實的被加速了，我們從來沒有設想到這個事情能夠完成一個真實的業務專案，我們過去都沒有想象到，甚至我們都覺得這個事情可能還要一年以後，但是它的出現讓我們覺得，今天真的可以透過大模型拆解數百上千個步驟，並且一步一步執行，出現問題它還可以自我反思，自我迭代，有這麼強的拆解能力和推理能力讓我們非常意外。
隨著 Devin 的誕生，各個專家學者就開始投入，包括我們通義實驗室，馬上發起的一個專案叫 OpenDevin。這個專案在短短的幾周內 star 數就超過了 2 萬，可以看到大家對這個領域非常的熱情。然後馬上開源了 SWE 的 Agent 專案，把 SWE- bench 的解決率又推升到了 10% 以上，過去的大模型都在百分之幾，推升到 10% 已經接近了 Devin 的表現，所以我們判斷在這個領域的學術研究會非常快，
我們大膽猜測一下，很有可能在 2024 年年中左右的 6 到 9 月份，很有可能 SWE- bench 的解決率會超過 30%。我們大膽猜測一下，如果能夠達到百分之五六十解決率的話，它的測試集實際上是一些真實的 Github issue，讓 AI 完成 Github 上面的 issue，可以去修復 bug，去解決需求的這樣一個測試集。如果這個測試集能夠讓 AI 的自主完成率達到百分之五六十，我們認為真的是可以在生產級中落地了。至少一些簡單的缺陷可以交給它來修復，這是我們看到的目前業界的一些最新的進展。
但是這張圖也不是馬上就能實現的，現在從技術路線上來講，我們會沿著這四步逐步實現。
第一步我們現在還在做單庫的問答 Agent，這個領域是非常前沿的，我們現在在做單庫的問答 Agent，近期會上線。
下一步我們希望推出能獨立完成編碼任務的 Agent，它的作用主要是具備一定的自主規劃能力，可以使用一些工具去了解背景知識，能夠自主的完成單庫範圍內的編碼任務，還不是跨庫，可以想象一個需求有多個程式碼庫，然後前端也改、後端也改，最終形成一個需求，我們覺得還很遠。
所以我們先實現單庫的編碼 Agent，下一步我們會去做測試 Agent，測試 Agent 可以基於程式碼 Agent 的生成結果，自動完成一些測試任務，包括理解任務的需求、閱讀程式碼、生成測試用例，並且自主執行。
如果這兩步的成功率做的比較高的話，我們就會進入到第三步。讓多 Agent 基於 AI 排程共同完成任務，從而實現從需求到程式碼到測試的全流程自主化。
從工程的角度來講，我們會一步一步這麼來走，確保每一步都達到一個比較好的生產級落地，最終去做產品。但是從學術來講，他們研究的速度會比我們更快，現在我們是從學術、工程討論的，我們還有第三個分支就是模型演進。這三條路就是我們現在阿里雲和通義實驗室一起聯合在做的一些研究。
最終，我們會形成一個 Multi-Agent 概念架構，使用者可以跟大模型進行對話，大模型可以進行任務的拆解，然後有一個多 Agent 協同系統。這個 Agent 可以外掛一些工具，它有自己的執行環境，然後多 Agent 之間可以互相協同，它們還會共享一些上下文機制。
這個產品圖會分為三層。最下面是基礎層，對於企業來講，可以先把基礎層做好。比如現在可以引入一個程式碼大模型，我們雖然沒有馬上實現 AI Bot，但是現在已經具備了 IDE 程式碼生成外掛的這些能力，已經可以做一些工作了，就是 Copilot 的模式。
Copilot 模式在基建層上面，進化了 Agent 這一層，實際上基建是可以複用的。該做的檢索增強、微調訓練和知識庫，現在就可以做起來了。這些知識的梳理，資產的積累，是來自於原來 DevOps 平臺的積累。現在就可以透過一些提示詞工程的方式，將現在基礎的能力層跟整個 DevOps 工具鏈進行結合。
我們做了一些實驗，在需求階段要想讓這個大模型來實現一個需求的自動拆解，我們可能只需要將過去的一些拆解資料，還有現在的需求拼成一個 prompt 給大模型，大模型就可以比較好的去完成拆解並且完成人員的分配。在實驗中發現，結果的準確率還是蠻高的。
其實現在整個 DevOps 工具鏈，並不需要所有東西都要用 Agent或者都要用 Copilot。我們現在用一些提示詞工程，就有很多場景可以馬上去賦能，包括我們在 CICD 過程中的自動排錯，在知識庫領域的智慧問答等都可以實現。
在實現多 Agent 以後，這個 Agent 可以在 IDE 裡面透出，也可以在開發者的門戶，即 DevOps 平臺透出，甚至在我們的 IM 工具裡面透出。它實際上是一個擬人的智慧體。本身這個智慧體它會有自己的工作區，在這個工作區裡我們的開發者或者說管理者可以去監控它到底是如何幫我們完成程式碼編寫的，如何幫我們完成測試的，它到底在網際網路上獲取了什麼樣的知識去完成工作，會有一個它自己的工作空間，最終實現整個任務的完整流程。
點選此處，體驗通義靈碼。