Github Copilot Agent模式使用經驗分享

本文總結了如何使用 GitHub Copilot Agent 模式，並分享實際操作經驗。

前置設置

1. 使用 VSCode Insider；
2. 安裝 GitHub Copilot（預覽版）插件；
3. 選擇 Claude 3.7 Sonnet（預覽版）模型，該模型在代碼編寫方面表現出色，同時其它模型在速度、多模態（如圖像識別）及推理能力上具備優勢；
4. 工作模式選擇 Agent。

操作步驟

1. 打開 “Copilot Edits” 選項卡；
2. 添加附件，如 “Codebase”、“Get Errors”、“Terminal Last Commands” 等；
3. 添加 “Working Set” 文件，默認包含當前打開的文件，也可手動選擇其他文件（如 “Open Editors”）；
4. 添加 “Instructions”，輸入需要 Copilot Agent 特別注意的提示詞；
5. 點擊 “Send” 按鈕，開始對話，觀察 Agent 的表現。

其它說明

• VSCode 通過語言插件提供的 lint 功能可以產生 Error 或 Warning 提示，Agent 能自動根據這些提示修正代碼。
• 隨著對話的深入，Agent 生成的代碼修改可能會偏離預期。建議每次會話都聚焦一個明確的主題，避免對話過長；達到短期目標後結束當前會話，再啟動新任務。
• “Working Set” 下的 “Add Files” 提供 “Related Files” 選項，可推薦相關文件。
• 注意控制單個代碼文件的行數，以免 token 消耗過快。
• 建議先生成基礎代碼，再編寫測試用例，便於 Agent 根據測試結果調試和自我校驗。
• 為限制修改範圍，可在 settings.json 中添加如下配置，只修改指定目錄下的文件, 僅供參考：

 "github.copilot.chat.codeGeneration.instructions": [
        {
            "text": "只需修改 ./script/ 目錄下的文件，不修改其他目錄下的文件."
        },
        {
            "text": "若目標代碼文件行數超過 1000 行，建議將新增函數置於新文件中，通過引用調用；如產生的修改導致文件超長，可暫不嚴格遵守此規則."
        }
    ],
    "github.copilot.chat.testGeneration.instructions": [
        {
            "text": "在現有單元測試文件中生成測試用例."
        },
        {
            "text": "代碼修改後務必運行測試用例驗證."
        }
    ],

常見問題

輸入需求得不到想要的業務代碼

需要將大任務拆分成較小的任務, 每次會話只處理一個小任務. 這是由於大模型的上下文太多會導致注意力分散.

喂給單次對話的上下文, 需要自己揣摩, 太多和太少都會導致不理解需求.

DeepSeek 模型解決了注意力分散問題, 但需要在 cursor 中使用 Deepseek API. 不清楚其效果如何.

響應緩慢問題

需要理解 token 消耗機制, token 輸入是便宜且耗時較短的, token 輸出貴很多, 且明顯更緩慢.

假如一個代碼文件非常大， 實際需要修改的代碼行只有三行, 但由於上下文多, 輸出也多, 會導致 token 消耗很快, 且響應緩慢.

因此, 必須要考慮控制文件的大小, 不要寫很大的文件和很大的函數. 及時拆分大文件, 大函數, 通過引用調用.

業務理解問題

理解問題或許有些依賴代碼中的註釋, 以及測試文件, 代碼中補充足夠的註釋, 以及測試用例, 有助於 Copilot Agent 更好的理解業務.

Agent 自己生成的業務代碼就有足夠多的註釋, 檢視這些註釋, 就可以快速判斷 Agent 是否正確理解了需求.

生成大量代碼需要 debug 較久

可以考慮在生成某個特性的基礎代碼後, 先生成測試用例, 再調整業務邏輯，這樣 Agent 可以自行進行調試，自我驗證.

Agent 會詢問是否允許運行測試命令, 運行完成後會自行讀終端輸出, 以此來判斷代碼是否正確. 如果不正確, 會根據報錯信息進行修改. 循環往復, 直到測試通過.

也就是需要自己更多理解業務, 需要手動寫的時候並不太多, 如果測試用例代碼和業務代碼都不正確, Agent 既不能根據業務寫出正確用例, 也不能根據用例寫出正確業務代碼, 這種情況才會出現 debug 較久的情況.

總結

理解大模型的 token 消耗機制, 輸入的上下文很便宜，輸出的代碼較貴，文件中未修改的代碼部分可能也算作輸出, 證據是很多無需修改的代碼也會緩慢輸出.

因此應盡量控制單文件的大小, 可以在使用中感受 Agent 在處理大文件和小文件時, 響應速度上的差異, 這個差異是非常明顯的.

• ←上一頁
• 下一頁→