作者注：本文用 5 個步驟講清如何設計 Agent 驗收關卡，讓長時間運行的智能體有明確的終點、可靠的反饋和可控的成本。
Agent 連續運行幾小時甚至幾天後，交回來的結果看似完整，卻沒人敢直接合入，這是很多開發團隊遇到的難題。本文將介紹 Agent 驗收關卡的 5 步設計法，幫助你在啓動長任務之前，把“做完”定義成機器可以反覆檢查的標準。
2026 年 10 月 27 日，CentOS 創始人之一 Gregory Kurtzer 公佈了 Ginux 項目。據報道，他在 11 天內主要依靠一個持續運行的 Codex 任務，留下約 13.9 萬行代碼，讓這款獨立內核啓動 Rocky Linux 10 並運行 systemd。有人追問他如何把跑偏的 Agent 拉回正軌，他的回答很簡單：關卡設得多。
這不是又一篇提示詞技巧合集，本文關注的是長任務真正依賴的工程結構：目標、關卡、證據、迴歸和停止條件。
核心價值：讀完本文，你將能爲自己的項目寫出一套 Agent 驗收關卡，並判斷哪些環節交給機器，哪些決定必須留給人。
Agent 驗收關卡核心要點
Agent 驗收關卡是一組預先定義、可以重複執行的檢查點。它告訴 Agent 當前結果是否達標，也告訴人類哪些證據值得審查。
| 要點 | 說明 | 價值 |
|---|---|---|
| 驗收標準前置 | 啓動長任務前寫清楚終點和階段目標 | 減少 Agent 用局部成功代替整體完成 |
| 關卡可執行 | 用命令、腳本、CI 或真實運行結果判定 | Agent 無需等待人工即可自行迭代 |
| 檢查系統行爲 | 關注程序實際運行時的表現 | 發現“看起來可信”的錯誤輸出 |
| 人機分層負責 | 人定架構與驗收，Agent 做實現與迴歸 | 人不再成爲循環中最慢的環節 |
| 預算可控 | 提前設定失敗次數、用量和暫停條件 | 避免長任務在錯誤方向上持續消耗 |
Ginux 案例中的 Agent 驗收關卡
Kurtzer 沒有把“寫一個內核”直接交給 Agent，而是選擇了 Linux 用戶空間程序能否運行、systemd 能否啓動這樣的硬性關卡。systemd 依賴大量系統組件，又是啓動和運行整個系統的核心進程，因此很適合用來檢驗內核是否真的可用。
這個項目運行在兩個相互配合的循環中。外部循環由人主導，從願景、架構與約束、驗收關卡，一直到審查實際行爲並決定修正或驗收；內部循環由 Agent 完成，反覆執行實現、構建並在 QEMU 中運行、測量分析故障、修訂和迴歸測試。
Kurtzer 還特別提醒，許多故障會產生很可信的輸出，實際卻違反語義、隔離要求或生命週期行爲。如果缺少關卡，最後很容易得到表面能運行、結構卻很薄弱的代碼。
爲什麼 Agent 驗收關卡要自動運行
Cursor 工程師 Lauren Tan 也把驗證視爲使用 Agent 時最重要的技能。她所說的驗證，包括讓 Agent 真正運行代碼、採集 CPU 跟蹤或堆快照、打開 iOS 模擬器，並按用戶的方式操作應用。
她公開稱自己每月可以把 4000 個 PR 合入生產環境。即使每個 PR 只由人檢查 5 分鐘，累計也要約 333 小時，所以這種規模下的檢查系統必須能在無人介入時運行。這個極端案例存在不少爭議，但它說明了一個普通團隊同樣適用的道理：Agent 能檢查自己的輸出，才能持續工作；不能檢查時，它只能把 diff 交給你然後停下。
配圖中的雙循環可以直接遷移到日常項目。如果想用不同模型分別承擔實現與審查，可以通過 API易 apiyi.com 接入，再把模型調用納入內部循環。
Agent 驗收關卡快速上手：5 步設計法
下面用一個常見任務作爲示例：讓 Agent 把一箇舊版 REST 服務遷移到新框架，並保持現有客戶端不受影響。你可以把示例中的檢查項替換成自己項目的構建、測試和部署流程。
第 1 步：爲 Agent 驗收關卡定義系統級終點
先寫一句可以被觀察的話，用來描述任務結束時系統應當發生什麼。“完成服務遷移”過於模糊，“使用同一批迴放請求，新舊服務的狀態碼和關鍵響應字段保持一致”則可以被驗證。
好的終點通常來自真實使用路徑。Ginux 的終點是 Rocky Linux 10 運行到 systemd 的 multi-user.target，Web 應用的終點可以是核心用戶流程跑通，數據任務的終點可以是輸出結果與基準數據集一致。
第 2 步：把 Agent 驗收關卡拆成五層
單一的最終測試反饋太慢，Agent 失敗後也很難定位問題。建議按照運行成本從低到高設置關卡，讓便宜的檢查先攔住明顯錯誤。
| 關卡層級 | 檢查內容 | 示例 | 失敗後的動作 |
|---|---|---|---|
| L1 靜態約束 | 格式、類型、依賴邊界 | 禁止模塊交叉導入 | Agent 立即修復 |
| L2 單元行爲 | 函數和模塊邏輯 | 核心單元測試 | Agent 定位並修復 |
| L3 集成契約 | 接口、數據庫、外部依賴 | 接口契約測試 | Agent 對比差異後修訂 |
| L4 系統運行 | 完整服務的真實行爲 | 啓動服務並回放請求 | Agent 收集日誌和性能數據 |
| L5 人工驗收 | 架構、風險和業務取捨 | 審查證據包並決定是否合入 | 人給出新約束或停止任務 |
Lauren Tan 的 Dune 架構提供了 L1 的極端例子。她通過 600 多個 PR 重構項目，並用 CI 校驗依賴圖，確保 Electron 的 main 和 renderer 目錄不會交叉導入，同時禁用 useEffect、禁止寫註釋。這些規則未必適合你的代碼庫，但把團隊約束寫成自動檢查的做法值得借鑑。
第 3 步：把 Agent 驗收關卡寫成可執行卡片
每道關卡都應該有一張簡短的卡片，放在 Agent 啓動時能讀取的項目文檔中。卡片寫清楚後，Agent 不需要猜測“什麼叫通過”，人也能據此追溯證據。
| 字段 | 填寫要求 | 服務遷移示例 |
|---|---|---|
| 關卡名稱 | 用行爲命名 | 回放請求一致性 |
| 運行環境 | 固定版本和依賴 | 隔離測試環境，使用固定數據快照 |
| 執行入口 | 提供一條明確命令 | make gate-replay（示例命令） |
| 通過判據 | 使用可比較的結果 | 狀態碼和關鍵字段全部一致 |
| 證據產物 | 保存可複查的文件 | 差異報告、服務日誌、性能記錄 |
| 保護規則 | 標明不可修改的內容 | 驗收樣本和判定腳本只讀 |
| 失敗策略 | 說明下一步動作 | 同一錯誤連續 3 輪未解決則暫停 |
其中，保護規則最容易被忽略。Agent 傾向於選擇眼前最省事的路徑，如果它能修改驗收樣本或放寬判定腳本，測試結果就會失去意義。建議把這部分放在受保護目錄，並在 CI 中檢查相關變更。
第 4 步：讓 Agent 驗收關卡進入自動迴歸循環
把內部循環寫進任務說明：先完成一個小改動，運行當前層級關卡，讀取失敗證據，修訂後再運行之前已經通過的關卡。這裏的迴歸很重要，否則 Agent 修好一處後，可能會悄悄破壞另一處。
每輪結束時，讓 Agent 記錄改動內容、運行的關卡、結果和未解決問題。長任務的上下文會不斷增長，這份記錄能幫助後續會話快速恢復狀態，也便於人類判斷它是在持續推進還是原地打轉。
驗收關卡還要防範“假通過”。下面幾種情況在長時間運行時尤其常見：
| 假通過類型 | 典型表現 | 對應防線 |
|---|---|---|
| 測試被修改 | 失敗用例被刪除或判定被放寬 | 驗收文件只讀，CI 檢查變更 |
| 只測試快樂路徑 | 正常請求通過，異常場景崩潰 | 增加故障注入和邊界樣本 |
| 模擬替代真實依賴 | Mock 全綠，集成環境失敗 | L4 必須運行真實服務 |
| 輸出像對但語義錯 | 日誌完整，生命週期行爲錯誤 | 比較狀態、時序和副作用 |
| 局部成功掩蓋風險 | 單項指標提升，整體穩定性下降 | 每個里程碑運行全量回歸 |
第 5 步：爲 Agent 驗收關卡設置人工決策點和停止條件
人的工作應集中在 Agent 難以替代的判斷上。Kurtzer 負責架構、Linux 兼容性目標、操作模型、故障解讀和停止決定；在對 Agent 生成的代碼不滿意時，他甚至會關掉 IDE，剋制親手修改的衝動，轉而提供新的指引。
建議至少設置三類暫停條件：同一關卡多輪失敗、Agent 試圖改動受保護內容、任務用量接近預算。暫停後的審查重點也應前移到證據包，先看系統行爲和風險，再決定是否深入閱讀 diff。
快速上手建議：先選一個能在一天內完成的小里程碑，只寫 3 到 5 張關卡卡片。API易 apiyi.com 提供本文涉及的 GPT、Claude 等系列模型的 API 調用，併兼容 OpenAI 與 Anthropic 接口格式，現有工具通常只需按文檔調整接口地址和密鑰，具體可用型號可在 API易 價格頁確認。
Agent 驗收關卡如何改變長任務成本
長任務的成本不能只看“一共用了多少 token”。報道中提到，Cursor 主頁統計的 token 至少包含普通輸入、模型輸出、緩存寫入和緩存讀取四類，價格差異很大。社區曾用同一份 1.5 萬億 token 用量估算賬單，不同算法的結果相差甚遠，主要分歧就來自計費口徑和緩存佔比。
| 計費項 | 長任務中的主要來源 | 控制方法 | 價格口徑 |
|---|---|---|---|
| 普通輸入 | 任務說明、日誌、代碼片段 | 只傳失敗相關證據 | 以 API易 價格頁實際數據爲準 |
| 模型輸出 | 代碼、分析和修訂計劃 | 限定每輪輸出範圍 | 以 API易 價格頁實際數據爲準 |
| 緩存寫入 | 新增或變化的穩定上下文 | 保持項目規則結構穩定 | 以 API易 價格頁實際數據爲準 |
| 緩存讀取 | 多輪複用的上下文 | 觀察命中情況，避免頻繁改動前綴 | 以 API易 價格頁實際數據爲準 |
公開案例的總費用可以用來理解項目規模，但不能直接換算成單價。Ginux 的 API 調用費報道約爲 8000 美元，Nicholas Carlini 用 16 個並行 Claude 智能體構建 C 編譯器的實驗約花費 2 萬美元。這些數字背後的模型、緩存和任務結構都不同，你的項目仍需單獨測算。
更穩妥的做法是先跑一個完整里程碑，記錄四類 token 用量和關卡失敗次數，再按 API易 價格頁 https://docs.apiyi.com/models 的當前數據計算。這樣得到的預算來自自己的任務形態，比直接套用別人的平均單價更可靠。
上圖想說明的是，關卡本身也會消耗資源，但它能把失敗提前暴露。對於普通團隊，目標應是用有限預算換取足夠的置信度，而不是追求每個改動都運行最昂貴的完整驗證。
Agent 驗收關卡常見問題 FAQ
Q1：什麼是 Agent 驗收關卡？
它是預先定義的可執行檢查點，用於判斷 Agent 的階段成果是否達標。一個完整的關卡包含運行環境、執行入口、通過判據、證據產物和失敗策略。
Q2:Agent 驗收關卡和普通 CI 有什麼區別？
CI 是常見的執行載體，驗收關卡則是更完整的任務控制設計。它除了判斷代碼能否通過測試，還要定義系統行爲、證據、迴歸範圍、人工決策點和暫停條件。
Q3：什麼時候必須設計 Agent 驗收關卡？
當任務需要多輪修改、跨多個模塊、運行時間較長，或者錯誤輸出不易肉眼發現時，就應該提前設計。一次性的小腳本可以簡化，但至少也要明確一條可運行的驗證方式。
Q4：有了 Agent 驗收關卡，還需要人工 Code Review 嗎？
需要。自動關卡適合判斷已知標準，人類仍要負責架構選擇、風險取捨和最終驗收。Kurtzer 也強調，判斷結果是否完整、局部成功是否帶來系統級風險時，經驗依然至關重要。
Q5：如何通過 API 接入模型來運行這套流程？
1. 在 API易 apiyi.com 註冊並創建 API Key。
2. 查閱文檔中心 `docs.apiyi.com`，確認接口地址和調用方式。
3. 根據工具選擇 OpenAI 或 Anthropic 接口格式完成配置。
4. 在 `https://docs.apiyi.com/models` 確認模型型號和價格後，再啓動小規模試跑。
Q6：預算有限時，怎樣精簡 Agent 驗收關卡？
優先保留低成本的 L1 和 L2 關卡，讓它們在每輪運行；L3 和 L4 放到功能完成或里程碑節點執行。Jellyfish 對 1.2 萬名開發者的統計顯示，典型用戶每月約使用 5100 萬 token，與極端案例差距巨大，因此應根據任務風險確定驗證頻率。模型費用請以 API易 價格頁實際數據爲準。
Q7:Agent 驗收關卡有哪些侷限？
關卡只能覆蓋被定義的風險，測試全綠也不等於代碼適合長期維護。Ginux 能夠啓動 Rocky Linux 10，距離生產級內核仍有很長的路，硬件支持、接口穩定、安全審查和社區維護都不是一次運行能證明的。社區對高頻 PR 模式的批評也提醒我們，要持續關注代碼的可維護性。
Agent 驗收關卡核心要點 Key Takeaways
- 先定義終點：用可觀察的系統行爲描述任務完成，避免模糊目標。
- 關卡要分層：從靜態約束逐步推進到真實運行和人工驗收。
- 證據要留存：每次運行都保存日誌、差異報告和性能記錄。
- 判定不可改：驗收樣本和腳本應受保護，防止 Agent 走捷徑。
- 迴歸常態化：修復新問題後，重新運行已通過的相關關卡。
- 人類掌握決策：架構、風險、停止和最終驗收由負責人判斷。
- 成本先試跑：通過 API易 apiyi.com 小規模驗證，再按價格頁測算預算。
總結：從 Agent 驗收關卡開始構建自主工作流
Agent 能否長時間自主工作，取決於它是否擁有清晰的目標和可靠的反饋。設計 Agent 驗收關卡時，可以牢記三點：
- 把“完成”變成可執行標準：讓 Agent 依靠運行結果判斷進度。
- 讓機器處理高頻驗證：用分層關卡、自動迴歸和證據包縮短反饋週期。
- 把關鍵判斷留給人：由負責人決定架構方向、風險邊界和停止時機。
建議從下一個中等規模任務開始，先寫關卡卡片，再啓動 Agent。需要測試不同模型時，可以通過 API易 apiyi.com 使用兼容 OpenAI 與 Anthropic 格式的接口完成接入，配置方法見文檔中心 docs.apiyi.com，模型價格和計費口徑以 https://docs.apiyi.com/models 的實際數據爲準。
📚 參考資料
- InfoQ – Ginux 項目報道:Codex 構建 Linux 兼容內核的過程與驗收方式
- 鏈接：
infoq.cn/article/OiyNEtFwV05opvsLTcvK -
說明：包含 HDAE 雙循環、項目規模和侷限性分析
-
InfoQ – Cursor 工程師 token 賬單報道：高強度 Agent 工作流與成本爭議
- 鏈接：
infoq.cn/article/q9iebpvFozfy4bgCYUyE -
說明：包含驗證閉環、Dune 架構和社區批評
-
Ginux 技術報告:Gregory Kurtzer 發佈的項目技術報告
- 鏈接：
zenodo.org/records/23682548 -
說明：適合深入瞭解研究目標、方法和結果邊界
-
Ginux GitHub 倉庫：項目源碼
- 鏈接：
github.com/gmkurtzer/ginux -
說明：可查看項目代碼和開源許可信息
-
API易文檔與價格頁：接口配置和模型價格說明
- 文檔鏈接：
docs.apiyi.com - 價格鏈接：
https://docs.apiyi.com/models - 說明：模型型號、價格和計費口徑請以頁面實際數據爲準
作者:APIYI 技術團隊
技術交流：歡迎訪問 API易 apiyi.com 與我們交流 Agent 工程實踐，更多接入資料可查閱 docs.apiyi.com 文檔中心。
