CI

本文聚焦 harness engineering 信任鏈的核心：Evidence（證據） 與 Attestation（獨立確認）。兩者分別回答「在已定義的檢查條件下，結果是否符合預期」與「這些證據是否足以支持產出符合需求意圖」。 前言 有了綁定好的合約之後，下一個問題是：agent 交出東西之後，如何證明它真的符合合約？ 這時很容易想到：既然 LLM 可以產出程式碼，那就再請另一個 LLM 進行 review，協助找問題、補充測試方向，或提供審查意見。這種做法有價值，但不能單獨成為最終放行依據。 換另一個 LLM，不會自動把帶有機率性的判斷（probabilistic judgment）變成可重現的 Evidence。不同模型、prompt 與工具仍然可能提供有價值的 review，但判斷也可能受到模型版本、context、推論結果與提示方式影響。 LLM 的審查是判斷，不是證明。它可以參與 Attestation，但不能只因為它說 OK，就把這句話直接當成 Evidence。 所以驗收這件事，可以拆成兩個角色不同的半場：可重現的檢查負責產出 Evidence，與產出角色分離的審查者或審查機制負責 Attestation。兩者都不能被繞過，也不能互相取代。 上半場：驗收即證據（Evidence） 先講機器這半場。這裡的重點是可重現性。 為什麼要可重現 證據的價值，來自它能在固定版本、執行環境與參數下重跑，得到可以比較的結果。驗收檢查需要把這些條件固定下來： Evidence 要綁定實際被驗收的 source revision，例如對應的 commit / tree 與必要的 diff，不只是假設某個 branch HEAD。 固定工具與 runtime 版本、依賴版本、執行參數、設定、輸入與必要的環境條件，並把這些資訊記錄進 Evidence。 必要 gate 的通過與否，不由單一 LLM 判斷決定；LLM review 可以作為審查輸入或輔助。 Evidence 可以證明產出在已定義的檢查條件與範圍內符合預期；這個結論只涵蓋被指定的版本、環境、輸入與驗收條件，不能證明所有未被覆蓋的情境都正確，也不能延伸成整個系統完全正確。 證據要綁定確切版本 每份 Evidence 都應該綁定實際被驗收的 source revision，例如對應的 commit / tree、必要的 diff，以及工具與 runtime 版本、執行參數和相關的環境條件。若工作目錄仍有未納入版本控制的變更，這些狀態也必須被拒絕或明確記錄。...