AI Agent 也能操作 Codex 同步Codex Provider Sync v0.4 自動化協(xié)議 plan-apply 詳解【免費下載鏈接】codex-provider-syncSynchronize Codex session provider metadata across rollout files and SQLite state.項目地址: https://gitcode.com/gh_mirrors/co/codex-provider-syncCodex Provider Sync 是一個用于在 rollout 會話文件與 SQLite 狀態(tài)之間同步 Codex Provider 元數(shù)據(jù)的本地工具。從 v0.4 開始它新增了一個面向腳本、CI 和 AI Agent 的實驗性自動化接口不再需要人工點擊界面AI Agent 也能安全地執(zhí)行同步、切換、恢復(fù)等操作。核心思想只有一句話——plan-apply先生成計劃再明確執(zhí)行任何寫操作默認(rèn)只是演練必須憑一份帶摘要簽名的計劃才能真正落盤。為什么 AI Agent 需要同步接口手動點界面對 Agent 來說既慢又不可靠。v0.4 的自動化接口CodexProviderSync.Automation.exe為機(jī)器調(diào)用提供了三個關(guān)鍵能力機(jī)器可讀輸出每次運行只向標(biāo)準(zhǔn)輸出寫一份固定結(jié)構(gòu)的協(xié)議 JSON診斷信息走標(biāo)準(zhǔn)錯誤方便 Agent 直接解析明確的退出碼成功、參數(shù)錯誤、計劃失效、忙碌、回滾失敗、需要恢復(fù)等狀態(tài)各自對應(yīng)獨立退出碼無需猜結(jié)果與 GUI 同源桌面界面和自動化接口共用同一套校驗、備份、恢復(fù)、鎖和 WSL 安全規(guī)則行為一致。相關(guān)源碼與協(xié)議定義AutomationProtocol.cs、automation-protocol-v0.4.schema.json支持的 7 個命令從只讀到寫入命令用途是否寫入describe查看協(xié)議能力和安全要求否status只讀檢查當(dāng)前 Provider、rollout 與 SQLite 狀態(tài)否plan為寫操作生成一份計劃否只產(chǎn)出計劃sync同步歷史會話元數(shù)據(jù)需--applyswitch切換 Provider/model 后同步需--applyrestore恢復(fù)托管備份需--applyprune清理舊的托管備份需--apply所有寫命令默認(rèn)都是dry-run不帶--apply時只返回影響預(yù)覽一個字節(jié)都不會改。完整的命令行參數(shù)見 AutomationCommandLine.cs。plan-apply 兩階段流程AI Agent 的安全閥這是整個協(xié)議最核心的設(shè)計。分三步走第 1 步生成計劃plan.\CodexProviderSync.Automation.exe plan --operation sync --codex-home C:\Users\you\.codex --provider openai返回的計劃包含planId、stateFingerprint目標(biāo)狀態(tài)指紋、expiresAtUtc過期時間、executionToken一次性執(zhí)行憑證和 64 位小寫的digest計劃內(nèi)容 SHA-256 摘要。第 2 步Agent 審查計劃Agent 檢查計劃中的目標(biāo)列表、警告和意圖是否與預(yù)期一致——這一步正是讓 AI 先想清楚再動手的環(huán)節(jié)。第 3 步明確執(zhí)行apply.\CodexProviderSync.Automation.exe sync --codex-home C:\Users\you\.codex --provider openai --apply --plan C:\Temp\plan.json --plan-digest digest執(zhí)行必須同時提供--apply、計劃文件和精確的--plan-digest三要素缺一不可。計劃為什么不能作弊計劃有三重約束Agent 無法繞過綁定狀態(tài)指紋如果計劃生成后目標(biāo)狀態(tài)變了比如有新會話寫入執(zhí)行直接被拒絕要求重新生成計劃有過期時間計劃只在expiresAtUtc之前有效防止拿舊計劃無限期重試單次使用執(zhí)行憑證通過持久化臺賬記錄用過即失效杜絕重復(fù)執(zhí)行。這套模型與桌面端的交互設(shè)計完全同構(gòu)詳見 ADR-0009寫操作采用 Plan / Confirm / Apply。機(jī)器可讀的結(jié)果Agent 如何判斷成敗每次運行的 JSON 響應(yīng)都帶有l(wèi)ifecycle生命周期字段如accepted、planning、readyToApply、applying、succeeded、failed、recoveryRequired和可區(qū)分的退出碼退出碼含義Agent 建議動作0成功繼續(xù)后續(xù)步驟2參數(shù)或用法錯誤修正命令3計劃無效/過期重新生成計劃4忙碌有未完成操作稍后重試5已回滾的失敗檢查備份與錯誤信息6需要恢復(fù)走restore流程7已取消或超時重新規(guī)劃10協(xié)議內(nèi)部錯誤報告上游這種退出碼 lifecycle timeline的組合讓 Agent 能像讀 API 文檔一樣理解每一次操作而不需要解析人類可讀的日志。安全邊界Agent 能做什么、不能做什么自動化接口在設(shè)計上刻意收窄了權(quán)限這些不變式來自 ADR-0001絕不觸碰憑證任何自動化路徑都不讀取、不復(fù)制、不記錄、不修改auth.json備份優(yōu)先寫入前自動創(chuàng)建托管備份失敗時嘗試回滾無法確認(rèn)完整性時明確報需要恢復(fù)而不是假報成功拒絕危險路徑絕對路徑校驗會拒絕符號鏈接與 reparse pointWindows 進(jìn)程也不會通過 WSL UNC 路徑直接修改 SQLite不承諾 1.0 穩(wěn)定協(xié)議0.4處于實驗階段未來可能發(fā)生不兼容變更Agent 集成時建議先用describe探測能力?？焖偕鲜? 步跑通第一次 Agent 同步看能力.\CodexProviderSync.Automation.exe describe確認(rèn)協(xié)議版本與支持命令查狀態(tài).\CodexProviderSync.Automation.exe status --codex-home C:\Users\you\.codex拿到當(dāng)前 Provider 與文件數(shù)計劃 執(zhí)行按上文第 1、3 步生成計劃并執(zhí)行sync。更完整的示例含將計劃寫入臨時文件、提取 digest 的 PowerShell 寫法請參考官方快速開始文檔AUTOMATION_QUICKSTART_ZH.md。若想了解 GUI 自動化與發(fā)布驗證的完整設(shè)計可閱讀 AUTOMATION_DESIGN_NOTES.mdv0.4 的發(fā)布背景見 v0.4.0 發(fā)布說明。小結(jié)Codex Provider Sync v0.4 的自動化協(xié)議把AI Agent 操作本地數(shù)據(jù)這件事做成了工程化的標(biāo)準(zhǔn)答案plan-apply 兩階段流程保證 Agent 先看影響再動手狀態(tài)指紋 過期 單次使用保證計劃不可濫用機(jī)器可讀 JSON 區(qū)分退出碼保證 Agent 能可靠判斷結(jié)果。對于想讓 AI 參與日常 Codex 會話維護(hù)的用戶這套協(xié)議是目前最穩(wěn)妥的入口。【免費下載鏈接】codex-provider-syncSynchronize Codex session provider metadata across rollout files and SQLite state.項目地址: https://gitcode.com/gh_mirrors/co/codex-provider-sync創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考