大模型掀起的 AI 輔助程式設計風潮已經吹了兩三年了，許多企業和管理層也強制性要求程式設計師必須學會使用 AI 工具提升效率。從一開始的 Copilot，到 Cursor、Windsurf…… 工具不斷升級，功能日漸完善。每隔一段時間，就會有新的功能出現，重新整理大家的認知。
最近，市場上多了一些「Code Agent」的產品，比如百度程式設計助手 Comate 上線的 Zulu，還有開源中國老朋友、資深開發者祝海林上線的 Auto-Coder，主打一個讓程式設計工具自己思考，自己就能幹完活。
先來看看官方的介紹 ——
Auto-Coder：
關鍵在於透過智慧體模式讓 AI 程式設計更好用。那麼問題來了，「Code Agent – 程式設計智慧體」到底是怎麼用，能用來幹什麼，和升級前的工具比優秀在哪，有沒有一些弊端？
OSCHINA 邀請了某公司技術合夥人、Auto-Coder 作者祝海林，跟他一起聊聊所謂的「程式設計智慧體」到底是什麼？這個功能和之前的 AI 程式設計能力本質區別是什麼？
從技術發展的角度來看，歷史上經歷過幾次重大變革。第一次是 Web 革命，那時建立一個個人部落格、個人站點，對技術人員來說就是一個機會；隨後是移動 APP 時代的到來。我認為，當前 AI 技術的浪潮同樣孕育著新的機遇，這個領域甚至可能出現大公司難以抗衡創新型小企業的局面。
我個人工作是從 Web, 到搜尋，推薦，再到大資料與傳統自然語言處理，所以一直和機器學習 AI 有點關係。
從 2023 年起，我便開始研究大模型相關的技術，早期是大模型微調、部署應用等，相應的工作成果為開源的 byzer-llm，2023 年底又開發過一個 Agent 框架（byzer-agent，應該是全球第一個基於 Ray 的分散式 Agent 框架）。
到 2024 年，我覺得大模型技術已經出現了一個清晰的應用場景 —— 並且我認為，任何新技術必然率先顛覆其原生領域 —— 大模型首個規模化落地的應用場景必然是 AI 輔助程式設計。
從去年下半年至今年上半年的行業動態也可見端倪：以估值已達百億美金的 Cursor 為例，各類 AI 程式設計工具，如 Augment 等持續湧現並獲得資本青睞。
值得注意的是，這些工具的功能演進正逐步趨同，這種現象恰恰標誌著 AI 程式設計輔助技術已發展至相對成熟階段 —— 只有當技術達到特定閾值後，產品形態才會進入收斂期。這也驗證了我的預判：AI 輔助程式設計一定是大模型技術第一個落地場景，也是真正能賺到錢的。
所以從 2024 年 3 月，我正式開始投入做自己的 AI 輔助程式設計工具 —— Auto-Coder。
Auto-Coder 下載地址：
https://pypistats.org/packages/auto-coder
不同 AI 輔助程式設計的實現原理對比
目前，AI 輔助程式設計的實現原理有 2 大類，一是基於規則流程的普通編輯模式，比如說早期 Cursor 工具的 “Composer” 模式，Auto Code 裡也會提供，這種模式的執行邏輯如下：
-
根據 query 自動查詢上下文
-
將原始碼檔案輸入系統
-
生成特定格式的修改格式（可 apply）
-
將生成內容合併回原始碼檔案
本質上是工具化的大模型應用，模型不具備自主決策能力，所有操作步驟均按預設規則執行。在 Auto Code 體系中，我們將其歸類為 “普通編輯模式”, 一般也叫 Context/Manual 模式。
二是大模型主導的 Agentic 模式，核心區別在於：所有流程不做提前規劃，交由大模型自主決策。
像是在 Auto–Coder 裡，我們會提供一些工具，比如閱讀、搜尋檔案、修改檔案的工具，把這些工具的使用說明告訴大模型，大模型會根據輸入的需求拆解目標，計劃每一步需要呼叫哪個工具。同時，大模型也會據工具呼叫結果更新系統狀態，相當於邊走邊看，持續決策直至滿足以下任一終止條件：
因此，Agentic 模式是變成了一個完全自驅的模式，給定需求後它會想辦法實現你的目標，大模型在其中是有主觀能動性的。
Code Agent 的實現流程
先來聊一下 Agent 本身，Agentic 模式下便是 Code Agent。從一個高的角度來看， Agentic AI 系統的核心是根據使用者的需求，完成兩個動作：
1. Reasoning: 檢視當前專案，思考解決方案
2. Acting: 根據思考做實現（修改程式碼，透過呼叫一些工具）Agentic Ai 系統會不斷重複著兩個動作，直到他自己認為已經解決了問題。
這和傳統意義上的 prompt -> response 是不一樣的。
大家用的聊天工具，包括 chatgpt, deepseek 網頁，其本質就是一個 prompt -> response 流程。而 Agentic AI 的流程則是，思考 -> 調整 -> 思考 -> 調整 來完成迴圈。
所以相比直接和大模型的一問一答模式， Agentic AI 系統是領取任務，自己做決策，覺得什麼時候，如何使用工具，以及下一步應該幹什麼，最終期望是能給 “老闆” 你提供一個滿意答卷。
這是 Agentic AI 和大模型的本質區別。同時這也和推理模型有本質的區別，推理模型本質上是 prompt -> thinking -> response ， 你可以理解為提供你答案之前，自己先打個草稿，然後再發言。
Code Agent 細化了前面的 Reasoning-> Acting 迴圈。
1. 分析當前使用者的需求，以及當前的程式碼的現狀（以及上一步工具執行的結果），給出一個解決流程。
2. 從流程的第一步開始，選擇合適的工具 (比如搜尋，閱讀程式碼檔案，羅列目錄等)
二選一怎麼選？
目前， Auto–Coder 的系統允許使用者根據不同場景選擇不同的工作方式。例如，如果使用者希望加快工作速度，可能會避免使用 Agent，因為 Agent 的執行速度相對較慢。為了完成一個任務，Agent 可能需要嘗試五六次甚至十幾次，每次都與大模型進行互動，消耗較多 token，總體速度較慢。
對於非常熟練且對專案熟悉的程式設計師，他們可能更傾向於使用 Context/Manual 模式，直接指定需要修改的檔案並給出修改指令，這樣可以在幾十秒內完成普通程式設計師可能需要一兩個小時才能完成的任務。
如果需求複雜或程式設計師對需求不夠清晰，他們可能會將需求交給 Agent，讓 Agent 去理解和消化，同時自行檢視相關檔案，再決定如何進行修改。這種情況下，使用 Agentic AI 系統更為合適。
因此我們鼓勵使用者根據自身需求選擇最合適的工作方式，以提高效率和節省成本。
在 AI 輔助程式設計中，成本是一個重要考慮因素。例如，目前最好的編碼模型之一是 Sonnet 3.7，但其成本較高，每 100 萬 token 的輸入成本為 5 美金，輸出成本為 15 美金。
以我個人的經驗，一次程式設計需求如果人工完成大約需要 30 分鐘到 1 小時，而使用 Sonnet 3.7 的話，成本大約在 0.6 到 2 美金之間。這是在理想狀態下的估算，因為 AI 生成的程式碼可能存在 bug，導致合併失敗需要重試，這樣成本可能會翻倍。
因此，成本是選擇工作方式時的重要考量。Context/Manual 模式相對節省成本，而 Agentic AI 模式成本較高，速度也較慢。
工具呼叫的兩種模式
Code Agent 的核心是大模型自主決策並呼叫工具完成任務。這裡的工具呼叫有兩種模式，據我所知，Windsurf、Cursor 等工具呼叫的是原子性工具，即非智慧工具。所謂非智慧工具，指的是例如我們提供的 readfile 函式和 certify 函式，我們會指導大模型如何呼叫這些函式。在自主決策過程中，大模型可能會決定首先檢視檔案，但由於其自身無法執行該操作，便會觸發 readfile 函式的呼叫，執行後返回檔案內容給大模型。大模型接收到結果後，再決定下一步操作。
這種方式下，大模型呼叫的是非智慧工具，並自由組合這些工具以完成程式設計任務，所有決策和操作都由大模型或 Agent 自行完成，例如決定替換檔案中的哪部分內容。
第二種方式則是呼叫已具備智慧的工具。以 Auto–Coder 為例，其中包含名為 coding 的 Agent 和名為 chat 的 Agent ，後者主要負責設計。當提出需求時，chat Agent 會提供詳細設計，而 coding Agent 則直接根據需求進行編碼實現。
具體而言，在 Auto–Coder 中，核心的 Agent 首先會根據對需求的理解，可能還會呼叫類似 read file 的工具以更清晰地理解需求，然後決定下一步是呼叫 coding Agent 還是先讓 chat Agent 進行設計。如果需求簡單且明確，核心 Agent 會直接呼叫 code Agent，並將需求細化後傳遞給 code Agent 執行，完成整個流程。這種方式下，存在一個總的 Agent 負責排程和編排其他 Agent 的工作。
綜上所述，目前存在兩種模式：第一種是底層使用非智慧工具；第二種是智慧工具和非智慧工具的組合，由 Agent 進行排程和編排。目前，我們的 Auto–Coder 已經實現了這兩種模式。
在 Agentic Edit 模式下，我們提供的工具集覆蓋全面且儘量精簡，功能交叉很少。例如，我們可能只提供兩個用於檔案查詢的工具：一個是搜尋功能，另一個是羅列特定目錄下的檔案。這兩個函式功能不重疊，如果提供太多工具，且沒有很好地進行抽象，那麼大模型在組合這些工具以完成通用程式碼任務時會更困難。因此，我們需要在保證功能覆蓋的基礎上，儘量減少工具數量，以免大模型難以找到最優解。
此外，大模型本身可能會忽略一些工具。如果工具太多，它通常會專注於幾個熟悉的工具，而不是充分利用所有提供的工具。因此，在正常情況下，如 Agenda 這類正規化所能使用的工具一般不會超過 10 個。
在 AI 輔助程式設計中，基本上 10 個類的原子工具就能滿足幾乎所有的編碼需求。但是，為了擴充套件功能，我們會加入一些特殊工具，比如最近熱門的 MCP。MCP 工具的使用也會控制在一定範圍內，即在實際使用過程中，啟用的工具數量是有限的。不會啟用所有外部 MCP 工具，通常在當前會話中只啟用兩三個。
我們實際上設計了兩種機制：第一種是透過代理 Agent 來選擇子 MCP 的執行；第二種是由最外層的 Agent 決定是否呼叫某個 MCP 的執行。兩種方式各有優劣，增加中間層會導致資訊損耗，而不增加則可能導致單個 Agent 管理的工具太多，從而影響效果。這與人類管理層的扁平化與深度化的優缺點非常相似。
MCP 與我們之前提到的 AI 輔助程式設計工具類似，都會內建一些基礎工具。例如，像 Windsurf、Cursor 這樣的工具，通常內部整合的都是非 Agent 類的工具，數量大約在五到八個之間。然而，為了擴充套件其使用其他工具的能力，比如連線谷歌進行搜尋，如果每個 AI 輔助程式設計工具都自己去實現這些功能，就會變得非常冗雜。因為使用者的需求是多樣的，甚至可能需要訪問公司內網的 API，這種情況下無法提前為所有可能性做好準備。
在這個過程中，MCP 提供了一種解決方案：透過註冊 MCP，Agent 在執行時動態呼叫這些 MCP 工具，這相當於為工具擴充套件留下了一個介面。只要遵循相應的規則或協議註冊，大模型就可以呼叫這些工具。但需要注意的是，在這個過程中資訊可能會有損耗。因為不同人實現的工具在自描述能力上存在差異，工具啟動後會提供一系列資訊來描述自身，大模型透過閱讀這些描述來決定工具是否適合當前需求。
由於 MCP 工具的質量參差不齊，類似於外掛的質量問題。相比之下，輔助程式設計工具內建的工具經過了反覆調優和適配，其品質相對較高。
真實場景：迭代老專案而非 5 分鐘寫個小遊戲
目前，大部分文章、自媒體或科技媒體的宣傳，都在強調我們的 Agent 能夠快速實現專案，比如一分鐘內完成一個遊戲的設計。確實大模型在建立新專案時成功率很高，例如 Gemini 的最新版本 Gemini 2.5 pro 在新專案開發上的表現就非常出色，能編寫出大量、高質量的程式碼。
然而，實際上，全球 99% 甚至 99.9% 的程式設計師主要是在迭代現有專案，這對模型的能力提出了不同的要求。
Gemini 2.5 pro 在老專案的修改上能力相比 sonnet 3.7 顯著偏弱，與開發新專案時表現出的能力截然不同。隨著新專案逐漸變為老專案，像 Gemini 這樣的模型可能會越來越力不從心。而 Sonnet 的 3.5、3.7 版本模型在處理老專案時表現出的能力則明顯更強。
因此，判斷一個 AI 輔助程式設計工具是否真正實用，核心在於它對老專案的支援能力。即，能否在現有專案的基礎上繼續進行迭代。這才能真正考驗一個 AI 輔助程式設計工具的優劣。這其中涉及許多挑戰，除了模型能力之外，我再舉幾個例子。
首先，大模型都有處理視窗的限制，如 64K、8K 或 200K tokens。現在，像 Gemini 和 GPT 4.1 這樣的模型提出 1M token 的處理能力，但實際上這仍然有限。例如，有些專案的一個檔案就超過了 64K tokens，導致大模型無法直接處理。在這種情況下，如何讓大模型有效地修改檔案就成為了一個挑戰。
另一個挑戰是，使用者的需求可能涉及多個檔案，比如一次重構可能涉及到 20-100 個檔案，每個檔案都都很大，這顯然超出了大模型的處理視窗。在這種情況下，如何讓大模型有效地修改多個檔案也是一個難題。這與單檔案大小的問題類似，都是 AI 輔助程式設計工具需要克服的挑戰。
這些挑戰通常只在開發老專案時才會遇到。因為新專案程式碼量較少，可以一次性將所有程式碼傳送給大模型進行修改。但對於老專案，如我們遇到的 Auto–Coder 專案，動輒就有上萬個龐大的 Java 檔案 , 此外還有古老的 JSP, PHP 等非常龐大的老專案存在。
在這種情況下，我們發現一些工具，如 Cursor，在處理上萬個 Java 檔案時可能會直接崩潰，在建索引過程中就出現故障。這實際上是真正考驗 AI 輔助程式設計工具真實能力的場景。
在 Auto–Coder 中，我們應對超大單一檔案的設計了一套方案，具體來說就是對檔案實現：滑動、抽取、合併三個動作。比如遇到當前檔案內容過長，相當於一張超長圖佔據了整個螢幕，而大模型無法一次性檢視整個圖片的內容，每次只能檢視一個視窗。假設這個視窗大小為 1000 行，那麼在修改過程中，由於不確定需要修改的具體部分，就需要逐步滑動視窗來定位。例如，可以每 10 行滑動一次，每次滑動後檢查當前視窗內的內容。當發現某個視窗中包含可能需要更改的程式碼片段時，就將這部分內容抽取出來，然後繼續滑動視窗進行判斷。那為什麼需要合併操作呢？在滑動過程中，會出現大量重疊的內容，這就需要透過合併操作去除這些重疊部分，確保抽取出來的內容是完整，有效的，可編輯的。
最終，我們獲取到的將是使用者真正關心的關鍵資訊。無需將整個檔案內容輸入大模型，只需提供這些關鍵資訊，大模型就能知道需要修改的部分。最後，將大模型的修改結果解析併合並回原始的超大檔案中。
這個過程包括視窗滑動、抽取和去重合並三個環節，我們實際測試效果非常好，例如之前測試過修改 Linux 核心裡龐大的單一檔案。
透過這種方式，我們能夠精確地定位並自動化地修改和合並內容。而傳統的技術往往難以實現這一點，因為檔案規模太大，無法像我們這樣以視窗為單位進行有效處理。例如，某些技術會以整個檔案為單位輸入大模型，這樣在定位修改位置時就會遇到困難。還有一些技術雖然有一定的滑動視窗概念，但在處理大量資訊時依然無法勝任。目前，這應該是 Auto–Coder 中較為獨特且其他競品尚未具備的功能。
對於熟練的程式設計師來說，如果清楚自己的任務且不需要大模型來尋找上下文，那麼在日常工作中，使用非 Agent 的 Manual 模式一次需求通常可以在 30 秒內完成，基本上在 3 到 60 秒之間大模型就能處理完畢。而如果手動完成這些任務，可能需要 1 到 2 小時。因此，使用大模型的效率提升是非常顯著的。
當然，這也取決於模型的速度。速度越快，使用者體驗就越好。你會發現程式碼在短短一秒內就完成了，而人工編寫可能需要兩三個小時。
下一步：突破“記憶”侷限
目前，AI 輔助程式設計工具面臨的最大挑戰，我個人認為，並非之前提到的那些問題，因為隨著時間的推移，我們在工程上會不斷改進。真正的問題在於，大模型本身不具備記憶能力，這究竟意味著什麼呢？
以 Auto–Coder 或 Cursor 為例，即使我使用它們開發了 1000 次，迭代了 1000 個功能，但每次新建一個回話後，對於 Cursor 或 Auto–Coder 來說，都相當於第一次接觸這個專案。
這是因為底層模型本身沒有記憶能力，所有的 “記憶” 都侷限於當前視窗。你必須將相關資訊放入視窗，模型閱讀後才能理解。現在，我們真正需要實現的功能是，隨著使用次數的增加，比如我使用 Auto–Coder 或 Cursor 開發專案的次數越多，模型對專案應越來越理解、越來越熟悉。就像人類在持續迭代過程中，腦海中會自然形成專案結構、檔案功能及修改需求的條件反射。
然而，大模型並非如此。每次對它來說都是全新的開始，即使已經讀過無數次某個檔案，下次遇到新需求時仍需重新閱讀，走完整個流程：先看檔案，再搜尋另一個檔案，然後繼續閱讀。
此外，大模型也不知道之前發生了什麼修改。儘管大部分 AI 輔助程式設計工具都引入了一定的記憶系統（例如會自動抽取和發現回話中的一些有用的內容並且記錄下來）
我認為這是大模型自身難以解決的問題，可能需要透過 AI 輔助程式設計工具自身來解決。目前市面上也有一些嘗試，比如 Auto–Coder、Cline 的文件追蹤系統。所謂文件追蹤系統，就是記錄專案所有變化對應的文件。下次程式設計時，帶上這些記錄，就能瞭解專案的迭代歷程，判斷哪些變數、哪些程式碼與當前需求相關。
隨著迭代次數的增加，這個記憶系統會越來越完善，大模型能收集到更多有效資訊來理解專案，從而實現 —— 使用 Auto–Coder 開發專案次數越多，提出的需求數量可以越少，甚至不需要指定檔案，模型就知道應該修改哪個檔案。
這是我堅信未來所有 AI 輔助程式設計工具都應努力實現的目標。
