從補全到 Agentic Edit：Trae 在代碼編輯上的落地與進化

作者｜馮緒

編輯｜李忠良

策劃｜AICon 全球人工智能開發與應用大會

當 AI 編程助手邁入 Agentic 階段，它不再只是“補全工具”，而是能自我規劃、跨文件協同、按反饋迭代的開發伙伴。圍繞這一轉變，Trae 團隊走過“補全 + Chat → Apply → Builder + Cue”的三階段路徑，逐步攻克文件精準定位、跨文件修改與效率—準確性—資源開銷的平衡。InfoQ 榮幸邀請到了馮緒字節跳動 /Trae 架構師 在 AICon 全球人工智能開發與應用大會·深圳站上分享了《Trae 插件在 Agent 代碼編輯的落地實踐》，他系統拆解 Apply 與 Search/Replace 的取舍、Cue 的智能補全機制，以及在“太陽系行星頁面”等真實案例中的落地經驗，提供可復用的工程方法論。

12 月 19～20 日的 AICon 北京站 將錨定行業前沿，聚焦大模型訓練與推理、AI Agent、研發新范式與組織革新，邀您共同深入探討：如何構建起可信賴、可規?；⒖缮虡I化的 Agentic 操作系統，讓 AI 真正成為企業降本增效、突破增長天花板的核心引擎。

詳細日程見：

https://aicon.infoq.cn/202512/beijing/schedule

以下是演講實錄（經 InfoQ 進行不改變原意的編輯整理）

AI 編程助手正加速走向智能化。憑借自主定位文件、修改代碼以及自動規劃與執行任務，AI Agent 既能高效完成開發工作，又能對結果進行自我校正與迭代，顯著提升開發效率。然而，要實現上述能力，仍面臨兩項挑戰：文件精準定位不足與跨文件修改困難。

TRAE 編程助手的發展階段

在介紹 Trae 如何解決這些問題之前，先回顧其產品形態的演進，整體分為三個階段。

第一階段是最初、也是最基礎的“補全 + Chat”。編輯能力以代碼續寫為主：根據用戶在編輯器中的輸入，系統自動提示可能的后續內容；同時提供聊天面板，用戶可在其中提問并獲得代碼建議。但用戶仍需手動復制粘貼，整體效率提升有限。

為解決手動復制粘貼的問題，進入第二階段：Check & Apply。核心變化是在代碼塊上提供“Apply”能力，用戶點擊即可將生成的代碼自動應用到原始文件，實現一定程度的自動化編輯。同時，我們開始探索模型的自動定位能力：當模型給出代碼塊時，會同時指明期望應用的目標文件。

第三階段（也是當前階段）是 Builder 與 Cue，目標是打造高度自動化的開發體驗。其一，Cue 提供更智能的補全，支持多行編輯與智能改寫，甚至可以預測下一步的光標位置；其二，Builder 能感知項目級上下文，自動規劃任務，并完成多文件的編輯與迭代。在這三個階段中，模型的編輯能力持續增強：早期僅能進行簡單續寫；中期具備一定的文件定位與修改能力；到第三階段，已能自動定位與修改文件，并執行更為精確的編輯。

從代碼補全到 Agentic Edit

現在來看 Trae 產品在代碼編輯能力上的三階段演進。代碼補全是大模型最基礎、也最擅長的能力。通過 Fill-in-the-middle、基于最近打開文件的上下文等策略，我們進一步提升了光標位置的續寫效果。然而局限也很明顯：只能在光標處編輯。

同一時期的 Trae 功能則顯得較為雞肋——模型生成代碼后，用戶仍需手動復制、粘貼，與直接打開 GPT 頁面問答差別不大。為了解決這一問題并提升可用性，我們引入了 Apply 機制，使模型生成的代碼片段能夠準確無誤地應用到原始文件中。

為實現這一目標，可以先分析當時 Trae 模型生成代碼塊的特征。

如上圖所示，模型的實際輸出并非完整文件，而是僅給出需要修改的核心片段。以該示例為例，模型按指令插入了注釋，因此中間部分被完整展示；至于未涉及修改的上下文，則以existing code等簡寫形式標注，表示這些區域無需改動。

之所以采用這種輸出方式，主要是為了顯著減少 token 消耗，從而提升生成效率。眾所周知，模型的上下文窗口存在限制。當時模型能力尚未達到如今水平，應用場景仍以問答式交互為主；受限于上下文窗口，模型難以一次性輸出完整全文。此外，在生成回答時，大量 token 還需用于拼接所采集的上下文信息。

有人會問，為什么不采用 Diff 格式進行輸出，就像 Git 那樣？事實上，我們在實踐中也嘗試過這種方式，但發現存在兩個主要問題。

首先，模型并不擅長輸出 Diff 格式。Diff 格式對語法和符號（如“+”“-”）等要求非常嚴格，一旦輸出的格式不符合標準，就會直接影響代碼編輯的準確性；其次，用戶在使用過程中需要良好的閱讀體驗。通常，用戶在看到模型輸出的代碼后，會先確認其是否正確、是否符合預期，然后才會采納。然而 Diff 格式本身可讀性較差，閱讀和理解起來比較費力。因此，我們最終放棄了采用 Diff 格式作為直接輸出的方案。

由此帶來的核心挑戰是：如何將模型輸出的帶有縮略格式的代碼塊精準地合并到原始文件中？

由于代碼在格式和內容上差異巨大，不同開發者的代碼風格也千差萬別，如果僅依賴規則匹配來完成合并，幾乎不可能覆蓋所有情況。

基于上下文與語義的改寫任務，正是大模型能夠發揮優勢的場景。因此，我們訓練了一個專用于代碼編輯的 Apply 模型。該模型接收兩類輸入：一是原始文件內容，二是 Chat 模塊 /Chat 模型輸出的帶有縮略的代碼塊（我們稱之為 Plan）。在獲取上述輸入后，模型對內容進行改寫與編輯，并輸出編輯后的完整文件。隨后，我們用該完整內容替換原文件，并以 Diff 形式展示給用戶，便于判斷哪些變更需要采納、哪些可以忽略。

要實現這一目標，對模型的選型與訓練提出了要求：其一，低時延；其二，良好的指令遵循能力；其三，支持長上下文。原因也不難理解：低時延可確保用戶點擊 Apply 按鈕后快速看到編輯結果；而在編輯任務中，模型需要嚴格遵照 Plan 的指令輸出，因此必須具備良好的指令遵循能力；同時，跨片段、跨文件的編輯需要更長的上下文支持。由于輸入和輸出會共享模型的 Token 窗口，而我們的方案要求將完整的原始文件交給模型處理，這會占用相當一部分上下文空間，導致留給生成內容的窗口減少。因此，模型必須具備較長的上下文處理能力，以確保能夠覆蓋更廣的修改范圍。

基于上述三點選型后，我們在訓練數據的構造上投入了大量精力。具體而言，我們針對不同 Chat 模型的輸出習慣，生成多種縮略格式的數據。不同的 Chat 模型對縮略格式的表達并不一致，甚至同一模型在不同次輸出中采用的縮略方式也可能不同：有的會輸出“existing code”，有的只會用“.”占位。為提升任務的準確性，我們對模型進行微調。

除了縮略格式，我們還面向不同場景構造數據：例如為“添加注釋”“import 依賴”“刪除代碼”“代碼重構”等需求準備樣例。通常需要先理解用戶意圖，再生成相應數據，以提升模型在具體場景中的準確性。此外，我們也針對常用編程語言構造數據，使模型能夠處理更豐富多樣的場景。

經過一系列訓練后，Apply 方案上線。這里有一個實際案例：我需要為某個文件的每個函數補充文檔注釋，只需給出“請為每個函數補上文檔”的指令，模型就自動生成了相應內容；模型會輸出相應的內容，部分函數細節可能采用了省略形式。隨后，當我點擊 apply 按鈕后，模型能夠根據生成的結果，為整個文件自動補充完整的注釋。

這一方案的上線確實顯著提升了用戶體驗，但也存在三方面的局限：其一，額外的資源開銷——除了調用 Chat 模型生成代碼塊，還需再調用一個模型執行編輯任務，整體資源消耗上升；其二，效率不足——在部分場景中，Chat 模型只需改一行，Apply 模型卻會重寫整個文件，導致效率偏低；其三，長文件限制——輸入與輸出共享上下文窗口，文件過長不僅可能無法處理，還會影響生成結果的準確性。工程上我們通過設置長度上限來規避風險，但當超長文件被拒絕服務時，用戶體驗仍會受影響。

盡管存在這些限制，Apply 在當時確實帶來了明顯的體驗提升，也啟發我們反思：代碼補全不應只做“續寫”，還應進一步優化整體體驗。

基于此，我們推出了更智能的代碼補全功能 Cue。Cue 支持多點編輯，不再局限于續寫，而是可以在多行中同時進行刪除、替換與插入；同時具備光標預測能力，例如當用戶在某一行引入方法時，它會提示在文件開頭補充相應的 import；此外還能跨文件編輯，智能識別需要變更的目標文件，從而突破“僅限當前文件與當前行”的限制。

與 Apply 相比，Cue 的挑戰更大，因為它需要理解更隱蔽的用戶意圖。用戶可能連續輸入大量字符或頻繁移動光標，這些操作往往暗含需求但不直接顯現。為此，我們通過分析用戶的編輯歷史來推斷真實意圖；在此基礎上，Cue 還需要支持倉庫級的跨文件編輯。我們基于 RAG 技術實現上下文感知，判斷與當前編輯內容相關的其他位置是否也應同步修改，從而提供更智能的補全能力。

隨著模型能力的快速提升，我們來到了Authentic Edit的時代——其特點是模型可以自主完成文件級編輯。與此同時，我們也開始探索更適合這一范式的代碼編輯方案。

隨著模型能力的持續增強，Builder 這一產品形態應運而生。它是一種 Agentic 的代碼編程助手，能夠自主搜索整個代碼倉庫，自行決定需要編輯的文件，并可對不同文件或同一文件進行多次編輯，同時保持邏輯一致性。圍繞這一形態，我們也提供了更契合的編輯能力。

具體而言，我們為 Builder 配備了更豐富的編輯工具集：Write to File（用于新建文件）、Delete File（用于刪除文件）以及 Update File（用于編輯文件）。其中，Update File 無疑是最復雜的應用場景。

在 Builder 模式下，Apply 的局限被進一步放大。原因在于，Agentic 的一次任務往往涉及多次文件修改；如果每次都必須經過“Chat 模型輸出”與“Apply 模型編輯”這兩個階段，系統開銷會非常大。此外，這種雙階段疊加不僅增加資源消耗，也放大誤差，導致整體編輯失敗率偏高。另一個問題是 Apply 對長文件的處理能力不足，這在 Agentic 場景下尤為明顯。

基于上述判斷，我們在這一階段轉向了 Search/Replace 方案。該方案的核心機制相對簡單：首先有一個原始文件，模型會明確告知需要查找并替換的舊內容，同時給出對應的替換內容。最后，系統根據這兩部分信息執行查找與替換，從而得到編輯后的結果。該方案的優勢也十分明顯。一方面，它無需進行二次調用，從而避免了額外的開銷和誤差疊加。另一方面是該方案不受上下文窗口的限制。也就是說，在任意長度的文件中，模型只需輸出需要查找的那一行內容，就能夠被準確定位。

然而，這一方案并非完美，同樣存在一些挑戰。首先，對模型輸出的要求較高。模型必須嚴格遵循指定格式，并確保 _old_str_ 與原文精確匹配。此外，工具調用通常使用 JSON 作為格式化方式，但在將 _old_str_ 等字符串寫入 JSON 時，往往需要進行轉譯，否則會導致解析失敗。而轉譯本身又是模型容易出錯的環節。

其次，該方案在效率上也存在問題。當進行大規模變更時， _old_str_ 與 _new_str_ 可能會非常冗長，從而再次觸發上下文窗口的限制。雖然可以通過拆分為多次編輯來解決，但效率會降低。我們也嘗試過采用數組方式以提升效率，但數組格式對模型輸出的規范性提出了更高要求。

第三，工程復雜度相對 Apply 方案更高。為了應對輸出不確定性，需要引入更多防御機制，例如模糊匹配、相似度查找，以及在出錯時進行自動修復和重試。

因此，這兩種方案并非互相替代，而是適用于不同場景。在Chat模式下，我們更傾向于使用Apply方案，以提升用戶體驗；而在Builder模式下，則優先采用Search/Replace方案，因為其準確性更高，且不受文件長度限制。

以上是我們對 AgenticEdit的探索。上圖展示了一個Builder場景的 Showcase：需求是實現一個簡易的太陽系行星運行頁面。在此過程中，我會針對系統生成的不正確部分提出反饋；系統將依據這些反饋和我的需求持續改進，直至完成頁面，并逐步完善相關展示功能。

總結與展望

本次分享回顧了TRAE 編程助手的三個發展階段及對應的產品形態，并探討了其背后代碼編輯能力的演進過程：包括專注于完成代碼編輯任務的Apply模型，提供更加即時和智能補全體驗的Cue功能，以及充分利用大模型能力的Agentic Edit能力。面向未來，我們將從三方面繼續探索：進一步提升編輯的準確性與效率；探索 Multi-Agent 協作框架；持續激發模型的思考與規劃能力。感謝大家的聆聽！

嘉賓介紹

馮緒，字節跳動 Trae 插件架構師，曾就職于騰訊，具備豐富的一線研發和實踐經驗。當前專注在 AI 編程助手的建設中，參與 AI 編程助手從 0 到 1 搭建以及 Apply 能力的建設。致力于探索大模型與編程工具的深度融合，在 AI Agent 架構設計、代碼編輯技術優化等方向持續深耕，為提升開發者編程效率貢獻技術力量。

AI 重塑組織的浪潮已至，Agentic 企業時代正式開啟！當 AI 不再是單純的輔助工具，而是深度融入業務核心、驅動組織形態與運作邏輯全面革新的核心力量。

把握行業變革關鍵節點，12 月 19 日 - 20 日，AICon 全球人工智能開發與應用大會（北京站） 即將重磅啟幕！本屆大會精準錨定行業前沿，聚焦大模型訓練與推理、AI Agent、研發新范式與組織革新，邀您共同深入探討：如何構建起可信賴、可規?；?、可商業化的 Agentic 操作系統，讓 AI 真正成為企業降本增效、突破增長天花板的核心引擎。