Agent拉取請求無處不在：如何審查它們

您可能已經在不知不覺中批准了一個Agent生成的拉取請求。測試通過了，代碼看起來很乾淨，然後您就合併了。但問題恰恰在於這種輕鬆批准的態度。

根據2026年1月的一項名為“更多代碼，更少重用”的研究，Agent生成的代碼每次變更引入的冗餘和技術債務比人類編寫的代碼更多。表面看起來很乾淨，但債務是悄無聲息的。而且，同一項研究發現，審查者實際上更樂於批准這樣的代碼。

這並不是要放慢速度，而是要有意識地審查。兩者之間存在區別。

Agent拉取請求已經飽和了審查帶寬

數量已經驚人。GitHub Copilot代碼審查已經處理了超過6000萬次審查，在不到一年的時間裏增長了10倍。GitHub上超過五分之一的代碼審查現在涉及Agent。這僅僅是自動審查階段。拉取請求本身正在以比審查者處理速度更快的速度激增。

傳統的流程——請求審查、等待代碼所有者、合併——當一位開發者在午餐前就能啓動十幾個Agent會話時，就崩潰了。吞吐量已經呈指數級增長，而人類的審查能力卻沒有。差距在擴大。

您將審查Agent拉取請求。問題在於，當您審查時，是否能抓住重點。

誰（或什麼）實際編寫了這個拉取請求

在查看一行差異之前，您需要了解您正在審查的對象。

編碼Agent是一個高效、字面、遵循模式的貢獻者，但關於您的事故歷史、團隊的邊緣案例傳説或不在存儲庫中的操作約束，它沒有任何上下文。它會生成看起來完整的代碼。但那種“看起來完整”的失敗模式是危險的。

而您擁有那些上下文。這不是負擔，而是實際的工作。審查中無法自動化的部分是判斷，而判斷需要只有您才有的上下文。

給作者的一個提示

如果您要提交一個Agent生成的拉取請求，請在請求審查之前編輯正文。Agent喜歡冗長，它們描述了那些通過代碼本身更容易探索的內容。在差異中標註上下文有幫助的地方。在標記其他人之前，自己先審查一下，不僅是為了檢查正確性，更是為了表明您已驗證了Agent捕獲了您的意圖。

當涉及Agent時，審查自己的拉取請求並不是可選的，這是對審查者時間的基本尊重。

現在，回到審查者。拉取請求到達您的隊列。作者已經完成了他們的部分。以下是需要注意的事項。

需要注意的危險信號

1. CI遊戲

Agent可能會在CI中失敗。當他們這樣做時，他們有一條明顯的路徑來讓測試通過：刪除測試、跳過lint步驟、在測試命令後添加|| true。有些Agent會這樣做。

任何削弱CI的變更都是阻塞點。完全停住。在批准任何Agent拉取請求之前，檢查：

• 覆蓋率閾值是否發生變化？
• 是否有測試被刪除、重命名或標記為跳過？
• 工作流是否停止在fork或拉取請求上運行？
• 是否有CI步驟現在被門控在之前沒有的條件下？

如果上述任何一項答案為“是”，則在繼續之前需要明確的理由。

2. 代碼重用盲目性

這是作為審查者可以做的最高ROI的事情。Agent會尋找現有模式，它們會在代碼庫中找到一個模式並進行復制，通常不去檢查是否已經存在一個實現相同功能的實用程序。症狀包括：新實用函數與現有函數名稱略有不同但功能重複、驗證邏輯在多個地方重新實現、從頭編寫已存在於共享模塊中的中間件、以及名稱不同但“幾乎相同”的幫助函數。

Agent的本地上下文不包括存儲庫中現有的完整情況。但您有。

對於Agent拉取請求中的每個新幫助器或實用程序，快速搜索一下。如果找到等價物，不要只留下評論，請在合併前要求合併。遺留重複邏輯的代價是Agent會將其視為現有模式並進一步複製。

💡 專業提示：對於超過一定大小的Agent拉取請求，要求為添加新實用程序提供理由。這樣可以及早捕獲重複問題。

3. 幻覺正確性

明顯的幻覺（調用不存在的API、引用超出範圍的變量）會在CI中被捕獲。但危險的是微妙的：代碼編譯通過、通過所有測試，但卻是錯誤的。

分頁中的差一錯誤、從未在測試中命中的分支上的缺失權限檢查、在Agent從未考慮過的邊緣情況下短路驗證、僅在規模下出現的競態條件下的錯誤行為。

追蹤它，而不僅僅是掃描。選擇差異中最重要的路徑，從輸入到每次轉換再到輸出進行跟蹤。檢查邊界條件（零、最大、空）、對外部值的缺失驗證、每個分支的權限檢查以及令人驚訝的條件邏輯。

要求一個在變化前行為下失敗的測試。如果Agent不能編寫一個可以捕獲它聲稱修復的錯誤的測試，那麼修復是不完整的，或者理解是錯誤的。

4. Agent幽靈

您進行了一次徹底的審查，解釋了問題，提供了上下文，建議了方向。然後拉取請求變得安靜。或者Agent回應了但完全沒抓住要點，在原地打轉。您又投入了一輪。仍然沒有有用的反饋。

沒有結構化計劃的大拉取請求與Agent放棄或方向錯誤高度相關。拉取請求越大、範圍越不明確，您就越有可能投入審查時間而一無所獲。

在您對一個大Agent拉取請求進行深入審查之前，檢查拉取請求歷史：它在之前的輪次中是否響應？它是否有清晰的實施計劃，還是Agent只是開始編寫代碼？

如果沒有計劃，在您寫任何評論之前，請求分解。複製粘貼版本：

“這個拉取請求太大了，沒有更清晰的實施計劃我無法審查。您能否將其分解為更小範圍單元，或添加每個部分的作用及結構原因摘要？之後我很樂意審查。”

堅定、簡短、不針對個人。這能節省您一個小時。

5. 工作流中的不受信任輸入

CI Agent中的提示注入是真實存在且被低估的。模式如下：Agent工作流從拉取請求正文、問題或提交消息中讀取內容，該內容被插入到提示中，提示發送給模型，模型輸出通過管道傳遞給shell命令，整個運行具有GITHUB_TOKEN權限。

當您審查任何調用LLM的工作流時，以下是阻塞點：

• 不受信任的用户輸入（拉取請求正文、問題正文、提交消息）是否未經消毒就被插入到提示中？
• GITHUB_TOKEN是否具有寫範圍而它只需要讀訪問？
• 模型輸出是否在未經驗證的情況下作為shell命令執行？
• 秘密是否對Agent步驟可訪問或打印到日誌中？

在合併前要求：工作流YAML中的最小權限（permissions: read-all是合理的默認值），在不受信任內容接觸提示之前進行消毒和引用，將“分析”步驟與“執行”步驟分開，並在影響生產的步驟上設置人工批准門，永遠不要eval模型輸出。

系統化審查流程

時間步驟 | 做什麼 --- | --- 1-2分鐘 | 掃描並分類：查看文件列表和差異大小。是窄任務（文檔、CI、小改動）還是複雜任務（多文件、邏輯、性能、測試）？這個分類決定了您後續的所有審查深度。

2-3分鐘 | 首先檢查CI變更：在閲讀一行應用代碼之前，查看任何涉及.github/workflows、測試配置、覆蓋率設置或構建腳本的內容。標記任何削弱CI的內容。停止標誌檢查。

3-5分鐘 | 掃描新實用程序：搜索新函數、幫助器或模塊。對每個進行快速倉庫搜索以檢查是否有重複。標記任何重新實現現有功能的代碼。

5-8分鐘 | 追蹤一條關鍵路徑：選擇最重要的邏輯變更，端到端追蹤：輸入→轉換→輸出。檢查邊界條件、權限、意外分支。這是您不能跳過的一步。

8-9分鐘 | 安全邊界：如果此拉取請求涉及任何調用LLM或處理不受信任輸入的工作流，請運行上述安全檢查清單。

9-10分鐘 | 要求證據：對於任何非平凡的邏輯變更，要求一個在變更前行為下失敗的測試。對於高風險變更，如果沒有回滾計劃，請要求一個。

何時要求更小的拉取請求：

• 差異涉及五個以上不相關的文件
• 您無法用一句話描述拉取請求的目的
• Agent沒有實施計劃或拉取請求正文為空
• CI失敗且差異中唯一的變更是測試文件

讓Copilot先審查

使用自動審查來承擔其擅長的任務：在人類介入之前捕獲機械性內容。Copilot代碼審查會標記樣式不一致、明顯的邏輯錯誤、缺失的錯誤處理和類型不匹配。它處理低級掃描。這樣您就可以騰出時間進行判斷工作，這才是您的真正價值所在。

將其視為先決條件，而不是替代品。讓Copilot先運行。如果它捕獲了明顯的問題，讓作者在您投入審查時間之前解決。

您可以通過特定於團隊的自定義指令來調整：標記任何修改CI閾值的代碼、顯示新實用程序以進行去重審查、檢查每個外部輸入是否經過驗證。指令越具體，自動審查就越有用。

💡 專業提示：我最近嘗試使用Copilot SDK將自己的審查檢查清單編碼化。為了不必記住在每個拉取請求上運行相同的安全檢查，我構建了一個工作流，它獲取我的個人檢查清單（管理端點上的身份驗證、測試實際運行、安全的環境變量處理）並自動針對差異運行。如果發現關鍵問題，它會阻止合併。

判斷是瓶頸，但這沒關係

代碼的表面積正在增長。拉取請求數量正在增長。您花在掃描樣板上的時間應該減少。

但不會減少的是您攜帶的上下文。您對系統的瞭解是任何地方都沒有寫下來的。這就是使您的審查有價值的原因，也是無法自動化的部分。

三個要點：

• 任何CI削弱都是硬性停止。
• 讓Agent先掃描。您追蹤關鍵路徑。
• 對於複雜的Agent拉取請求，默認使用危險信號檢查清單。

閲讀文檔 >