停止修正AI代碼：構建智能體所需的系統

如果軟件工程師不再編寫代碼，那他們在做什麼？這是數百萬人心中的疑問。AI工具如今已被開發者廣泛使用，但裁員恐懼依然存在。然而，編碼只是軟件工程的一部分。這為工程師提供了貼近業務和了解其角色在組織與行業中的目的的機會。Tessl的技術人員、DevOps一詞的創造者、DevOpsDays全球活動系列的創始人Patrick Debois表示：“我喜歡用類比思考。2009年，我在想，如果運維更像開發會怎樣？”他在今年夏天的倫敦PlatformCon會議上發表了上述言論。他告訴聽眾，隨着上下文——AI用於任務的特定知識——取代人類代碼，“軟件開發生命週期變成了上下文開發生命週期。”這一生命週期已從單一的CI/CD反饋循環擴展為圍繞生成、通過測試驅動開發評估、將上下文作為包分發以及觀察的一系列同心圓。這種增長由個人開發者、團隊和整個組織思維方式的轉變所推動，併為平台工程團隊開闢了全新的機遇。Debois告訴The New Stack：“我主張的開發人員思維轉變是：如果智能體沒有按你的意願行事，停止修正代碼。改進系統，而不是提示。這種轉變是從‘我將與智能體一起做’轉向‘我將幫助智能體做得更好’。”Debois認為這是從確定性到非確定性和概率性系統及工作流程的必要轉變。它涉及工作方式和技術本身的諸多變化，但不能僅由單個工程師或團隊層面完成。就像DevOps一樣，這種變化只能在規模上實現。

如何成為上下文驅動的組織？可能感覺我們好像按下了開關，每家公司都“AI優先”。實際上，就像之前的DevOps、微服務和雲轉型一樣，AI正在向可預見的未來持續過渡。那麼，你的工程組織如何走上正確的上下文驅動之路？在團隊層面，Debois表示，一個好的問題是：智能體工作需要多少次接觸？不同團隊的工程師會輸入不同的上下文點，包括代碼庫、規範、事後分析、文檔、Slack消息、架構決策記錄、代碼示例、用例和合規指南。要使上下文以及智能體規模化，你需要了解個人和團隊正在生產哪些智能體及其輸出。Debois解釋説：“當你在優化A，我們在優化B時，我們要確保提供的整個上下文是針對整個團隊優化的。”包括：“如果你在為你的筆記本電腦優化系統，我們能否為團隊工作流程優化它？然後你只需擴展，比如，我們能否在平台層面做到這一點？或者跨多個團隊？”Debois告訴The New Stack：“這不是你刻意追求的東西。也許他們可以加速它，但你會看到這樣的跡象：‘哦，我有上下文，你也有上下文。當然，它就在Slack上。如果它放在倉庫裏，我可以重複使用呢？’這遵循了技術中任何趨勢從單個愛好者擴展到熱情團隊、再到幾個團隊，最終構建到平台中的模式。像所有工具驅動的變革一樣，AI既關乎人和流程，也關乎技術。但他認為，工具為行為改變打開了可能性。他繼續説：“根本性的變化是系統，而不是提示。然後尋找協作方向，從單打獨鬥到共享事物，現在作為團隊一起構建上下文。”

上下文工程演變為配套工程。組織可能認為上下文只需一次性或每年幾次在規則變更時輸入智能體系統，但Debois警告説，這不應是瀑布式。它是迭代的。如果上下文不是迭代的，那麼工程師就會重新陷入改寫提示或直接修復代碼本身的壞習慣。僅依賴傳統反饋循環意味着你的AI智能體艦隊無法帶來投資回報。Debois告訴PlatformCon聽眾：“行業內有一種説法：如果AI有問題，我們就使用更多AI。”他舉例説明一個大語言模型或AI代理如何生成代碼。“我們要求LLM評估這段代碼，它幾乎就像調用單元測試一樣。它沒有運行代碼，只是查看代碼。”這有一定價值，可能在於強制API端點或其他二進制質量門控，但他説這還不夠。相反，如果你在上下文中指定了需求，那麼這就會驅動智能體如何運行和評估代碼。但不應止步於此。他認為，AI智能體成熟度的下一階段在於配套和循環。配套工程專注於構建圍繞LLM的基礎設施、護欄和工具，以支持可靠、自主的智能體開發。Debois將智能體的內部配套定義為查詢API背後的日誌、指標和跟蹤，“這樣編碼智能體就能看到後果並改進”，所有這些都反饋到生成、評估、分發和觀察的活循環中。通過這種模式，智能體“自動知道出了問題，無需你不斷告訴它們”，他説，因為“它擁有傳感器，知道什麼失敗了，什麼改進了，然後可以回去改進這些邊界”，即使工程師在硬編碼某些東西。同樣，配套不應孤立地為單個開發者或團隊構建。Debois説：“他們正在為整個世界構建配套，所以想象一下，在如何做測試、如何進行驗證以及當前所有不同團隊的知識方面達成共識。人們開始基於相同的管道進行構建。”現實是大多數組織最終會有多個管道，但這些循環成為每個組織反饋循環的下一步演進。因此，為AI協調而構建會帶來更好的組織協作。