快速瀏覽軟件工程中的代理/生成式AI

代理方法現在很熱門，因為單個 LLM 模型似乎僅限于點工具應用。每個這樣的應用程序都令人印象深刻，但仍然是我們想要自動化的更復雜的推理任務鏈中的一個步驟，代理方法應該在其中大放異彩。我一直聽說軟件工程 （SWE） 團隊在 AI 采用方面比硬件團隊進步得更快，因此認為對狀態進行快速現實檢查會很有用。本著這個想法的精神，我使用 Gemini Deep Research 來尋找本文的來源，有選擇地抽樣它提供的一些調查，同時添加一些我自己的發現。我的快速總結是，首先，什么算作進步取決于應用：基于便利性的使用模型在今天更容易實現，精確的使用模型也是可能的，但更有限。其次，在自動化子任務方面，進步更為明顯，這些子任務受制于交叉檢查和人工監控的自然框架，而不是免提的全面 SWE 目標。

自動化帶來便利

一篇有趣的論文建議，我們應該從出于方便需求的應用程序轉向基于提示的查詢，以服務于相同的目標。原則上，這種方法比應用程序做得更好，因為基于提示的系統消除了應用程序開發的需要，可以通過我們都使用的語言進行控制，而不需要神秘的人機界面，并且可以更容易地適應需求的變化。

有效的提示工程可能仍然比我們希望的更像一門藝術，但作者建議我們可以學習如何變得更有效，并且（我的解釋）也許我們只需要學習一次這項技能，而不是為每個獨特的應用程序學習。

即使是技術工程師也需要這種支持，不是在深度開發或分析中，而是在常規但重要的問題上：“還有誰在使用這個功能，最近使用它是什么時候，其他人看到了什么問題？傳統上，這些問題可能可以通過幫助庫或內部數據管理應用程序來回答，但是如果您想將問題與該應用程序范圍之外的其他來源或約束交叉怎么辦？在硬件開發中，想象一下，如果您可以對所有設計數據（規范、用例、源代碼、日志、波形、修訂等）進行基于提示的搜索，那么發現能力會有多大。

自動化精密開發

本文描述了一個代理系統，用于開發相當復雜的功能，包括人臉識別系統、聊天機器人系統、口罩檢測工具、蛇游戲、計算器和井字游戲，使用基于LLM的代理系統進行管理、代碼生成、優化、QA、迭代細化和最終驗證。它聲稱與標準基準相比代碼準確率為 85% 或更高，可在幾分鐘內構建和測試這些系統。在 85% 的準確率下，我們仍然必須遵循初始代碼，開發人員努力驗證和糾正生產質量。但假設這種準確性水平是可重復的，那么不難相信，即使經過幾周或幾個月的開發人員測試和改進，在不損失質量的情況下生產力的凈收益也可以是相當可觀的。

另一篇論文指出，在 SWE 中，自動開發的代碼仍然存在信任問題。然而，他們補充說，大多數大規模軟件開發更多的是從多個來源組裝代碼，而不是從頭開始開發代碼。這將信任問題變成了您可以信任多少組件和組件。我猜他們認為 DevOps 中的組裝相對微不足道，但在硬件設計中，SoC 級組裝（甚至多芯片系統組裝）更復雜，盡管仍然主要是機械的而不是創造性的。出錯的范圍肯定比從頭開始創建一個全新的函數要有限。我知道十多年前有一個基于人工智能的系統，它可以為 SoC 創建大部分集成基礎設施——時鐘、復位、中斷、總線結構等。這早在我們聽說法學碩士和代理之前。

同時，代理/生成式人工智能不僅對代碼開發有用。工具似乎可以自動化測試設計、生成和執行、調試以及更普遍的 DevOps。其中許多系統實際上相互交叉檢查，并輔以人工監督。錯誤可能會發生，但可能不會比在無人工智能系統中更嚴重。

方便、精確還是兩者兼而有之？

工程師癡迷于精度，尤其是在人工智能方面。但我們一天中所做的大部分事情都不需要精確。如果我們能快速得到“足夠好”的答案，它們就可以了。搜索、總結電子郵件或論文中的要點、生成文檔初稿，這些都是我們依賴（或希望）快速且“足夠好”的首次通過的便利性的領域。另一方面，在某些情況下，精度至關重要。對于金融交易、噴氣發動機建模、邏輯仿真，我們希望得到最準確的答案，而“足夠好”是不夠好的。

即便如此，精密應用仍然具有優勢。如果人工智能能夠非常快（幾分鐘）提供一個足夠好的起點，并且如果我們能夠通過接受超越該起點的改進和驗證的需求來管理我們的期望，那么縮短時間表和減少工作量的凈收益可能是值得投資的。只要您能對人工智能系統可以提供的質量建立信任。

順便說一句，我自己的經驗（我在 Gemini、Perplexity 和 Chat GPT 中嘗試了深度研究 （DR） 選項）支持了我的結論。每個 DR 分析在 ~10 分鐘內出現，對我來說主要是他們提供的參考資料而不是 DR 摘要。其中一些參考資料對我來說是新的，有些我已經知道了。如果我的研究純粹是為了我自己的興趣，這可能就足夠了。但我想更準確，因為我的目標是提供可靠的見解，所以我也通過更傳統的在線圖書館尋找其他參考資料。事實證明，結合這兩種方法是富有成效的！