讀懂 Codex CLI：從倉庫結構追蹤一次 Agent 迴圈
閱讀終端 Agent 的原始碼，容易一開始就陷入目錄和型別名稱。更有效的入口是沿著一次任務走：使用者輸入在哪裡被接收，模型請求怎樣構造，工具呼叫由誰執行，執行結果又怎樣回到對話。Codex CLI 的 Rust 實現會隨版本調整，目錄名稱和邊界應以你檢出的倉庫為準；本文給出閱讀方法，幫助你驗證架構，而不是把某個提交的結構當作永恆事實。
從入口找到會話邊界
先看倉庫 README 和啟動入口，搜尋命令列引數解析、會話建立以及主迴圈。畫出“終端輸入—會話狀態—模型請求—事件輸出”的最短路徑。遇到抽象層時，沿呼叫點向下看，而不是隻讀型別定義。記錄關鍵函式及其呼叫者，這比從頭通讀整個倉庫更容易建立心智模型。
拆開 Agent 迴圈
一個典型迴圈會收集上下文、向模型傳送請求、處理文字或工具呼叫，再將工具結果加入會話繼續執行，直到完成或等待使用者。檢查程式碼中停止條件、錯誤分支、取消訊號與重試邏輯：它們決定 Agent 是否會重複執行、如何恢復以及何時把控制權交還給人。觀察日誌和事件型別，也能看出 UI 與核心執行邏輯之間的邊界。
追蹤工具呼叫的安全邊界
工具介面通常把模型提出的動作轉換為可執行請求，但不應把模型輸出直接等同於使用者授權。跟蹤 shell、檔案編輯或 MCP 呼叫經過哪些許可權檢查，哪些操作會暫停等待批准，拒絕後狀態如何處理。做原始碼實驗時使用臨時倉庫和無敏感資料，先理解預設許可權，再執行會寫檔案或聯網的操作。
用小實驗驗證閱讀結論
選擇一個只需讀取檔案的簡單任務，加入日誌或斷點觀察請求與結果；再嘗試一個需要確認的操作，比較事件路徑。一次只改一個變數，並記錄檢出的 commit。若倉庫已調整模組名，可以使用符號搜尋和 Git 歷史找到職責遷移，避免引用舊文章中的路徑造成誤導。
閱讀時的限制
原始碼只能說明特定版本的實現，不能保證託管服務、模型端行為或未來版本相同。不要把內部型別視為穩定 API，也不要為了理解迴圈就關閉安全檢查。優先檢視官方倉庫、版本標籤和貢獻檔案，再把結論寫成“在此提交中”的觀察。