TRAE終於把Code和Work合併了
https://www.qbitai.com/2026/10/502426.html📌 TRAE把Code與Work合二為一，AI Coding走向多Agent協作
TL;DR：TRAE合併雙端工具，用Agent模式讓多個Agent同時推進開發與交付文件。
以前要改一個bug，得開啟TraeCode；要出一份技術方案，又得切換到TraeWork。這種在工具之間來回跳轉的「閃身步」，現在TRAE宣布正式結束：TraeCode與TraeWork雙端融合，升級成新的TRAE。
🤔 為什麼要合併
一個專案從想法走到交付，中間要拆需求、寫方案、出設計，後面還要測試、修bug、做彙報。這些環節過去被拆在兩個工具裡，上下文斷在兩處，產出的文件也散落兩邊，使用者只能夾在中間切換。新TRAE要做的，是把整條鏈路接起來，變成一個全鏈路開發平臺。
🧩 新架構：Agent模式與IDE模式
新TRAE提供兩種模式，切換入口在右上角。Agent模式主打「全域工作臺」，可以在同一個視窗裡管理專案，把寫程式碼、出文件、準備交付材料等不同工作分派給多個Agent同時進行。IDE模式則保留SOLO與IDE兩種既有玩法，適合需要逐行調整細節的場景。所有任務產出的文件，都會自動歸檔到「我的產物」，且每個產物都能直接分享給他人查看。
📊 三個實測場景看出什麼
量子位的實測設計了幾個對照場景：
一是重現網路上討論度很高的「3D鵜鶘騎腳踏車」demo，拆成三個Agent接力：Agent 1寫程式碼做出鵜鶘、腳踏車與場景；Agent 2當測試者，開啟頁面截圖並列出問題清單；Agent 3按清單逐條修復。開發Agent原本自稱已在瀏覽器測過兩輪、一切正常，但測試Agent上手後仍挑出4個問題，包括方向鍵完全反了。
二是從零做一個3D地牢遊戲編輯器，讓策劃與設計兩個Agent同時進行、互不可見對方成果，結果策劃案寫的格數是32×32、設計稿卻是20×20；一個把擦除工具快捷鍵設成E、另一個設成X；怪物重生點一個說放1個、另一個說放3個。負責開發的Agent讀完兩份文件後，依「先做出能玩的簡單版本」原則逐條取捨，並把理由寫進交付說明，之後還自行開啟瀏覽器測試，修掉6個問題（例如一進試玩模式就跳出「已暫停」視窗、畫面太暗看不清走廊）。
三是接手一個虛構的老專案TeamDesk（約20個檔案），三個Agent分別只負責寫架構說明、只修bug不碰測試檔、只補回歸測試不碰業務程式碼。事後核對原始程式碼，三者確實守住各自分工，業務程式碼只改了一行，測試資料夾也只多了一個新檔案。
💡 人要做的事情變了
從這幾次實測能看出一個共同規律：Agent數量增加，並不會讓結果自動變好。策劃與設計各說各話、開發Agent自我測試的信心與實際測試結果有落差，這些都說明分工之外還需要一個統籌或檢查的角色。量子位的觀察是，現在人要花心思的地方，變成了把工作拆清楚、給所有Agent一份共同依據，以及安排好誰執行、誰驗證。
🎯 實務啟示
新TRAE還提供模板庫、每日自動跑回歸測試的自動化功能，以及透過飛書、微信@TRAE跨平臺操作、手機端同步等能力，降低了多Agent協作的操作門檻。放眼海外，Cursor 3的Agents Window、Claude Code的Agent View，走的也是把「管Agent」與「改程式碼」整合進同一工具的路線。對工程師而言，與其糾結要不要用多Agent，更該思考的是怎麼準備清晰的共同依據，並安排好檢查與仲裁的角色，否則多個Agent平行工作反而容易產生衝突而不自知。
🔗 來源
- 標題：TRAE終於把Code和Work合併了
- 作者／機構：十三 @ 量子位
- 連結：https://www.qbitai.com/2026/10/502426.html
#AICoding #AIAgents #TRAE #DeveloperTools #MultiAgent #SoftwareDevelopment #Automation #LLM #ProductivityTools #AgenticAI
原始資料 量子位 · 收集於 2026-10-09
摘要原文
TRAE終於把Code和Work合併了 十三 2026-10-09 17:19:57 來源： 量子位 大寫的方便 金磊 發自 凹非寺 量子位 | 公眾號 QbitAI TRAE ，剛剛做了個大動作。 以前的你，如果要改個bug，得開啟TraeCode；要是還得出份技術方案，那又得一個 “閃身步” ，跳到TraeWork…… 現在，不需要這麼麻煩了。 因為它倆今天已經正式 雙端融合 ，統一升級成了 新的TRAE 。 新TRAE的一個亮點，就是它有Agent模式和IDE模式兩種。 其中， Agent模式 主打的是 全域性工作臺 ，大家可以在一個窗口裡管理專案，把不同工作分給多個Agent，寫程式碼、出文檔、準備交付材料都在這裡推進。 IDE模式 裡面依舊保留了SOLO和IDE兩種玩法。兩種模式的切換入口就在右上角，點一下就能過去。 例如前陣子讓整個AI圈“臥槽”的 3D版鵜鶘騎腳踏車 ，在新TRAE裡的“開啟方式”可以是這樣的。 我們在同一個專案資料夾裡，新建三個任務，三個Agent各司其職： Agent 1：寫程式碼，把鵜鶘、腳踏車和場景做出來； Agent 2：當測試，開啟頁面截圖檢查，列出一份問題清單； Agent 3：按給出的清單逐條修復存在的問題。 最終，它們就像一個小團隊那樣接力幹活，把一個具備完整功能的3D版鵜鶘騎腳踏車給做出來了： 於是乎，這隻鵜鶘，在新TRAE裡就這麼水靈靈地完整走完了開發、測試、修復、交付這一圈。 並且這期間所產生的測試報告、修復報告和交付說明等等，都自動存到了新TRAE裡的 “我的產物” ，每個產物也都可以 直接分享給別人 。 清清楚楚，一目瞭然。 那麼作為AI Coding領域 資深玩家 的TRAE，為什麼要突然把這兩個雙端給合併了？ 對於小白和專業開發者，新TRAE又有什麼區別？ 帶著這些問題，我們不妨通過深度實測來感受一下。 小白也能從一個想法做出一款遊戲 我們先來看下新TRAE能否讓一個不會程式設計的小白，也能把自己的想法變成遊戲。 恰巧Minecraft之父Notch之前還說AI Coding很糟糕，結果後來又發帖稱自己還挺享受的，而且正給自己的地牢遊戲做地圖編輯器。 所以，我們第一個實測也來做一個能自己搭地牢、還能進去走的 3D地牢遊戲做地圖編輯器 。 這一次，我們在新TRAE裡建好專案後，先同時開兩個任務，一個負責寫遊戲策劃，一個負責出界面設計稿： 可以看到，在我們下達指令之後，兩個Agent便立即開始各忙各的了。 沒過多久，兩份成果就都交了出來。 策劃Agent交出的是一份 Word版策劃案 ，外加一份內容一致的Markdown檔案，操作流程、每種元素的用途、驗收標準，都寫得明明白白。 設計Agent則是真的畫出了一張高保真 設計稿 ，編輯模式和第一人稱試玩模式兩個介面都在一張圖裡，整體走的是低多邊形的地牢風格： 接下來，我們再新建第三個任務，讓它讀取策劃和設計的成果，開始 寫程式碼 。 不過在這一步，出現了一個非常真實的小插曲。因為策劃和設計是同時進行的，兩個Agent誰也看不到對方的成果，結果就各寫各的了。 比如設計稿裡的網格是20×20，策劃案裡卻是32×32；擦除工具的快捷鍵，一個定成了E，另一個定成了X；就連怪物重新整理點，一個說全圖只放1個，另一個說要放3個。 好在負責開發的Agent讀完兩份檔案後，按照“先做出能玩的簡單版本”的原則，把這些衝突逐條做了取捨，還把理由都寫進了交付說明裡： 這也說明，Agent一多，光有分工還是不夠的，總得有個角色出來統籌全域性。 在寫完程式碼之後，開發Agent還自己開啟瀏覽器測了一遍，順手修掉了6個問題，比如一進試玩模式就彈出“已暫停”的視窗，又比如試玩畫面太暗，連走廊都看不清。 最終做出來的編輯器，地板、牆、門、寶箱、拉桿、怪物重新整理點都能隨手放，撤銷重做、自動儲存、JSON匯入匯出也都一應俱全： 影片地址： https://mp.weixin.qq.com/s/tckIeqpzcq2jB11STQLTBg 值得一提的是，Notch正在做的新遊戲，名字就叫《Levers and Chests》，直譯過來正是“拉桿和寶箱”。 我們編輯器裡的這兩樣東西，就當是給他的一點小致敬了[solute]。 同樣的，在這個專案跑完之後，Word策劃案、設計稿、設計說明，還有測試交付說明等等，全都整整齊齊地躺在“我的產物”裡。 這要放到以前，這些產物要麼埋在聊天記錄裡，要麼散落在各個資料夾裡；現在開啟一個頁面就能找到，想接著改，隨時回來點開就行。 那如果我們要改特別細節的內容呢？ 一鍵切換IDE模式 ，瞭解一下。 我們在右上角切換成IDE模式之後，直接在對話方塊裡輸入： 把第一人稱行走的速度調到70%。 沒過一會，它就把行走速度從每秒3.4格降到了2.4格，奔跑速度也跟著同步下調： 簡單來說，我們平時可以在Agent模式裡讓AI放手去幹那些 複雜開發 ，到了要摳細節的時候，再回到IDE裡一行一行地看，兩種模式各有各的用處。 真實工作裡也好用 做遊戲固然好玩，但對於專業開發者來說，他們更關心的，可能還是新TRAE能不能扛住日常的工作。 那麼接下來的實測，我們就直擊程式設計師們經常會頭疼的一個工作—— 接手老專案 。 為此，我們準備了一個名為TeamDesk的模擬專案。這是一個小型的任務管理網頁，大約20個檔案，資料全部是虛構的，專案裡還附帶了一份問題單。 這一次，我們直接在專案裡一口氣新建了三個任務，讓三個Agent同時開工： Agent 1：讀程式碼、搞懂專案，產出一份給新人看的架構說明； Agent 2：只負責修bug，不許碰測試檔案； Agent 3：只負責補回歸測試，不許碰業務程式碼。 Agent 1交出的架構說明是一份網頁報告，用大白話講清楚了這個專案分成哪幾層、頁面上的操作會怎樣改動資料、資料最後又存在了瀏覽器的哪個位置。 負責修Bug的Agent 2則是先按問題單復現了一遍，找到原因之後，只改了一行程式碼，給統計加上了一個排除已歸檔任務的條件： 最後，Agent 3在補回歸測試之後，呈現出了最終結果： 事後我們又對照了一遍原始程式碼，三個Agent都老老實實地守住了各自的分工，業務程式碼只改了一行，測試資料夾裡也只多了一個新檔案。 像這種迴歸測試，日常其實還可以交給新TRAE的 自動化功能 ，比如設定每天早上自動跑一遍，發現問題再提醒你。感興趣的小夥伴可以自己試試： 再來看一個更貼近日常的場景， 一個人交付一個完整的迭代 。 這一次，我們給自己定的任務，是做一個名為FeedbackDesk的反饋處理臺，拿到內部評審會上去演示。評審要用的東西包括一份產品需求文件、一個能操作的網頁Demo，再加一份評審PPT。 同樣的，我們還是一口氣新建了三個任務： Agent 1：寫產品需求文件； Agent 2：做網頁Demo； Agent 3：出評審PPT。 沒過多久，三個Agent就交出了各自的成果，分別是一份4頁的Word需求文件、一個可以直接在瀏覽器裡操作的網頁，還有一份6頁的評審PPT和配套講稿： 以前我們寫需求文件、做PPT得去TraeWork，做網頁又得回到TraeCode；現在在同一個窗口裡，一群Agent就把這幾件事同時推進完了。 而且更方便的是，新TRAE還提供了 模板庫 ，像諸如此類的文件工作，我們甚至可以直接套個模板就開搞： 還有更方便的。 即便你不在TRAE裡，現在綁定了 飛書 或 微信 ，只要直接@TRAE一下，就能直接讓它為 跨平臺 工作；而且 手機端 也是同步的哦： 方便，著實是方便。 為什麼要二合一？ 最後，我們回到開頭的那個問題，作為AI Coding領域的資深玩家，TRAE為什麼要把兩個端合併到一起？ 幾輪實測做下來，我們最大的感受是，寫程式碼其實只是開發裡的一環。 一個專案從想法走到交付，前面要拆需求、寫方案、出設計，後面還要測試、修bug、做彙報。 以前這些環節被拆在兩個工具裡，上下文斷在兩處，產物也散在兩處，人只能夾在中間來回“閃身步”。 而新TRAE這次做的，就是把這條鏈路給接起來，變成一個全鏈路開發平臺。 從縱向來看，從需求拆解到交付，文件、設計、程式碼和測試都能放在同一個專案裡，重複性的流程可以交給自動化，桌面、網頁和手機三端也保持同步。 從橫向來看，一個工作臺管著所有專案，多個Agent可以並行推進，哪個任務卡在了哪一步，左側欄裡一眼就能看到；真需要深改程式碼的時候，再一鍵切回IDE就好。 放眼海外，這件事也不只是TRAE一家在做。 今年4月，Cursor推出了Cursor 3，加入了專門管理Agent的Agents Window，同時保留了經典的IDE介面，兩個介面可以隨時切換。Claude Code也做了Agent View，能在一個面板裡同時啟動、管理和監控多個後臺Agent。 可以看到，海外頭部的AI程式設計工具，都在把“管Agent”和“改程式碼”往同一個工具裡裝。 不過實測也讓我們發現，Agent多了，事情並不會自動變好。就拿開頭那隻鵜鶘來說，負責開發的Agent交差時信心滿滿，說自己已經在瀏覽器裡測過兩輪，一切正常；可負責測試的Agent一上手，就挑出了4個問題，連方向鍵都是反的，按右鍵鵜鶘反而往左邊衝。 再加上地牢編輯器裡各說各話的策劃和設計，以及反饋處理臺裡數字分毫不差的三份產出，其中的規律其實已經很明顯了。 說到底，人要做的事情變了。現在我們更多的心思，是花在把活拆清楚、給Agent準備一份共同的依據，以及安排好誰來幹活、誰來檢查上。 這或許也是新TRAE這次升級想要解決的問題。 畢竟TRAE在AI Coding這條路上已然是個資深玩家，這一次把兩個工具合二為一，就是想用一個工作臺，把開發的每一個環節都接住，服務好更多想動手創造的開發者。 從讓一個Agent幫你寫程式碼，到指揮一群Agent從想法一路幹到交付，AI Coding也算是正式走進了Agent開發的新階段。 至於那個來回切換的“閃身步”，以後應該是用不上了。 版權所有，未經授權不得以任何形式轉載及使用，違者必究。 AI Coding TRAE 十三 把記憶交給CPU，大模型會變快 2026-09-16 真香！做這個邪惡老奶版「GTA 6」，我只花了5元！ 2026-10-08 Anthropic，你是來給智譜打廣告的吧！ 2026-09-30 Agent時代，CPU的價值該重估了 2026-09-22 相關閱讀
由 claude-code/sonnet 自動生成