Copilot應用科學中的智能體驅動開發

我可能剛剛把自己自動化到了一個完全不同的工作……這是軟件工程師中常見的模式——出於靈感、挫折，甚至有時是懶惰，他們構建系統來消除繁瑣工作，從而專注於更創造性的任務。隨後，我們最終擁有並維護這些系統，將自動化的好處帶給周圍的人。

作為一名AI研究員，我最近將這一理念推向了新的高度，自動化了我的腦力勞動。現在，我發現自己正在維護這個工具，以便Copilot應用科學團隊的所有同事都能做到同樣的事情。在此過程中，我學到了很多關於如何有效創建和協作使用GitHub Copilot的知識。應用這些經驗，不僅為我解鎖了極其快速的開發循環，還使我的隊友能夠構建適合他們需求的解決方案。

在我解釋如何實現這一點之前，讓我先介紹一下這個項目的背景，以便你更好地理解GitHub Copilot的能力範圍。

動因

我的工作很大一部分涉及分析編碼智能體在標準化評估基準（如TerminalBench2或SWEBench-Pro）上的表現。這通常需要仔細審查大量的所謂“軌跡”——即智能體在執行任務時採取的思維過程和行動列表。評估數據集中的每個任務都會產生自己的軌跡，顯示智能體如何嘗試解決該任務。這些軌跡通常是包含數百行代碼的JSON文件。將基準集中的數十個任務乘以每天需要分析的大量基準運行，我們面對的是數十萬行代碼需要分析。

這是一項不可能獨自完成的任務，因此我通常求助於AI。在分析新的基準運行時，我發現自己在重複同樣的循環：使用GitHub Copilot發現軌跡中的模式，然後親自調查——將需要閲讀的代碼行數從數十萬減少到幾百行。然而，我內心的工程師看到了這項重複性任務，並説：“我想自動化它。”智能體為我們提供了自動化這類智力勞動的手段，於是eval-agents誕生了。

計劃

工程和科學團隊更好地合作。這是我解決這個新挑戰時的指導原則。因此，我在設計並實施該項目時牢記幾個目標：

• 使這些智能體易於共享和使用
• 便於編寫新的智能體
• 使編碼智能體成為貢獻的主要載體

前兩個目標深植於GitHub的基因中，也是我在整個職業生涯中（尤其是在維護GitHub CLI開源項目期間）積累的價值觀和技能。然而，第三個目標對項目的塑造最大。我注意到，當我設置GitHub Copilot來幫助我有效構建工具時，它也使項目更容易使用和協作。這一經歷教會了我一些關鍵經驗，最終以我意想不到的方式推動了第一和第二個目標的實現。

讓編碼智能體成為你的主要貢獻者

首先描述我的智能體編碼設置：

• 編碼智能體：Copilot CLI
• 使用的模型：Claude Opus 4.6
• IDE：VSCode

值得注意的是，我利用了Copilot SDK來加速智能體創建，該SDK在底層由Copilot CLI驅動。這使我可以訪問現有工具和MCP服務器，註冊新工具和技能的方法，以及許多其他開箱即用的智能體特性，無需重新發明輪子。

有了這些，我可以通過遵循幾個核心原則非常快速地簡化整個開發過程：

提示策略：智能體在你採用對話式、詳細描述、並在進入智能體模式之前使用規劃模式時表現最佳。

架構策略：經常重構、經常更新文檔、經常清理。

迭代策略：“信任但驗證”現在變成了“歸咎於流程，而非智能體”。

發現並遵循這些策略引發了一個令人難以置信的現象：添加新智能體和功能變得快速而簡單。我們有五個人首次加入該項目，在不到三天的時間內，我們總共創建了11個新智能體、4項新技能以及eval-agent工作流的概念（可以看作是科學家的推理流）。這相當於在345個文件中增加了+28,858/-2,884行代碼。

太棒了！

下面我將詳細介紹這三個原則以及它們如何實現了這一令人驚歎的協作與創新。

提示策略

我們知道，AI編碼智能體非常擅長解決範圍明確的問題，但對於更復雜的問題（你只願意委託給高級工程師的那種），它們還需要手把手的指導。因此，如果你希望智能體像工程師一樣工作，就要像對待工程師一樣對待它。引導它的思維，過度解釋你的假設，利用它的研究速度在跳入更改之前進行規劃。我發現，將一些關於我正在思考的問題的意識流思考放入提示中，並與Copilot在規劃模式下合作，比給它一個簡短的問題陳述或解決方案要有效得多。

以下是我編寫的一個提示示例，用於為工具添加更健壯的迴歸測試：

> /plan 我最近觀察到Copilot愉快地更新測試以適應其新範式，即使這些測試不應該被更新。如何創建一個保留的測試空間，讓Copilot無法觸及或必須保留以防止迴歸？

這引發了一系列來回討論，最終形成了一系列類似於契約測試的護欄，只能由人類更新。我對想要的東西有一個想法，通過對話，Copilot幫助我找到了正確的解決方案。

事實證明，使人類工程師工作最有效的因素，同樣也使這些智能體工作有效。

架構策略

工程師們，歡呼吧！還記得那些你想做但沒時間做的重構嗎？那些你從未有時間編寫的測試？那些你希望在入職時就存在的文檔？現在，在構建智能體優先的倉庫時，它們成為你可以做的最重要的事情。

那些將這類工作優先於新功能開發的時光一去不復返了，因為當你擁有一個維護良好的智能體優先項目時，藉助Copilot交付功能變得輕而易舉。

在這個項目中，我大部分時間都在重構名稱和文件結構，記錄新功能或模式，以及為我發現的問題添加測試用例。我甚至花了一些時間來清理智能體（就像你的初級工程師）在實現所有新功能和更改時可能遺留的廢棄代碼。這項工作使Copilot能夠輕鬆瀏覽代碼庫並理解模式，就像對其他任何工程師一樣。

我甚至可以問：“以我現在所知，我會如何不同地設計？”然後我可以證明實際上回過頭來重新架構整個項目（當然是在Copilot的幫助下）。

夢想成真！

這引出了我最後一條建議。

迭代策略

隨着智能體和模型的改進，我已經從“信任但驗證”的心態轉向了更加信任而非懷疑的心態。這反映了行業如何對待團隊：“歸咎於流程，而非人。”這是最高效團隊的運作方式，因為人都會犯錯，所以我們圍繞這一現實構建系統。

這種無指責文化為團隊提供了心理安全感，使他們能夠迭代和創新，知道即使犯錯也不會被責備。核心原則是我們實施流程和護欄來防止錯誤，如果錯誤確實發生，我們從中學到東西並引入新的流程和護欄，這樣我們的團隊就不會再犯同樣的錯誤。

將同樣的哲學應用於智能體驅動開發，對於解鎖這個極其快速的迭代管道至關重要。這意味着我們添加流程和護欄來幫助防止智能體犯錯，但當它犯錯時，我們添加額外的護欄和流程——如更健壯的測試和更好的提示——這樣智能體就不能再犯同樣的錯誤。更進一步，這意味着實踐良好的CI/CD原則是必須的。

像嚴格類型這樣的實踐確保智能體符合接口。健壯的linter為智能體施加實現規則，使其遵循良好的模式和做法。而集成測試、端到端測試和契約測試——這些手工構建可能很昂貴——在智能體輔助下變得便宜得多，同時讓你有信心新更改不會破壞現有功能。

當Copilot在其開發循環中擁有這些工具時，它可以檢查自己的工作。你正在為其成功創造條件，就像你在項目中為初級工程師創造條件一樣。

整合

當你的代碼庫為智能體驅動開發設置好後，你的開發循環將如下所示：

1. 使用/plan與Copilot規劃新功能。
2. 迭代規劃。
3. 確保計劃中包含測試。
4. 確保在實現代碼之前，計劃中包含文檔更新。這些可以作為額外的指南，與你的計劃並存。
5. 讓Copilot在/autopilot上實現功能。
6. 提示Copilot啓動與Copilot代碼審查智能體的審查循環。對我而言，通常是：請求Copilot代碼審查，等待審查完成，處理相關評論，然後重新請求審查。繼續此循環直到沒有更多相關評論。
7. 人工審查。這是我在前幾節中強調模式的地方。

此外，在功能循環之外，確保你還經常提示Copilot以下內容：

• /plan 審查代碼中缺失的測試、可能損壞的測試和廢棄代碼。
• /plan 審查代碼中的重複或抽象機會。
• /plan 審查文檔和代碼，找出文檔缺口。確保更新copilot-instructions.md以反映相關更改。

我每週自動運行這些一次，但我也經常在整週中運行它們，因為新功能和修復不斷進入，以維護我的智能體驅動開發環境。

帶走的經驗

最初是對一個極其重複的分析任務的挫敗感，最終變成了更有趣的東西：一種關於我們如何構建軟件、如何協作以及如何作為工程師成長的新思維方式。

以編碼智能體優先的心態構建智能體，從根本上改變了我的工作方式。這不僅僅是自動化的勝利——儘管觀看四位科學家在不到三天內交付11個智能體、4項技能和一個全新概念，令人驚歎。更重要的是，這種開發風格迫使你優先考慮：乾淨的架構、全面的文檔、有意義的測試和深思熟慮的設計——這些我們一直知道很重要但從未有時間做的事情。

與初級工程師的類比不斷得到驗證。你很好地引導他們，給予清晰的上下文，建立護欄使他們的錯誤不會成為災難，然後信任他們成長。如果出現問題，你歸咎於流程，而不是智能體。如果有一件事我希望你從中帶走，那就是使你成為偉大工程師和優秀隊友的技能，也是使你擅長與Copilot構建的技能。技術是新的，但原則不是。

所以，去清理你的代碼庫，編寫你一直推遲的文檔，並開始將你的Copilot視為團隊的最新成員。你可能會自動將自己帶入職業生涯中最有趣的工作。

覺得我瘋了？那就試試這個：

• 下載Copilot CLI
• 在任何倉庫中激活Copilot CLI：cd && copilot
• 粘貼以下提示：/plan 閲讀並幫助我規劃如何最好地改進此倉庫以進行智能體優先開發。