圖一：跨平台工程的共同底座是契約、狀態與證據。兩個模型能交換訊息，只是協作的起點。本文圖像皆為原創技術示意，不代表平台官方架構。
TL;DR
Claude Code 與 OpenAI Codex 共用程式碼，仍需要共同處理派工、版本、寫入競爭與失敗恢復。本文拆解一套 Windows 環境中的工程設計：以共享契約統一完成條件，由單一主協調者選擇原生工作者，透過模型情境協定（Model Context Protocol，MCP）橋接另一個平台，再用持久化工作圖、合作式寫入認領與獨立驗證接住執行結果。實測涵蓋兩項 Codex 單平台產品驗收、限定的 Codex → Claude 互斥交接，以及正式工作根的修復結案；這些結果各有受測範圍，尚不足以宣稱任意雙平台任務都能全面自動化。
一、從一次交接看問題：程式寫好了，為什麼工程還沒完成？
先看一個教學情境。Claude Code 正在調整資料匯入模組，Codex 準備替同一個模組補測試。兩個編碼代理（Coding Agent）都能讀取同一份程式碼儲存庫（Repository），也各自知道自己的任務。Claude 回報「實作完成」後，Codex 對當時讀到的檔案執行測試，得到成功結果。幾秒後，前一個工作程序才把最後一次變更寫回磁碟。這時候兩份回覆都可能出自善意，但「測試通過」已經無法證明最新版本正確。
若主控又恰好遇到工具逾時，問題會再多一層：前一位寫者究竟沒啟動、仍在執行，還是已寫入卻沒有送回結果？重派可能造成重複副作用；直接交給下一位寫者，可能讓兩個程序同時修改檔案；宣布失敗，也可能丟掉一份已經完成的產物。這個例子不是本文的實測產品需求，而是用來說明多代理工程中共同存在的時間差。
要接住這些時間差，需要的就是代理執行環境工程（Harness Engineering）：把模型的判斷接到工具、狀態、資源協調、驗證及恢復機制。提示詞可以要求 Agent「不要覆蓋別人的工作」，卻不能憑文字完成跨程序互斥；聊天紀錄可以保存「打算派工」，卻不能代替原生平台確實受理執行的回執。
因此，自主工作流（Auto Workflow）的目標應該定義得比「自動產生程式碼」更完整：使用者交付目標、驗收條件與授權邊界，主協調者自行選擇必要方法，完成實作、測試、修復與結案。只交付目標的驗收（Goal-Only）則刻意拿掉人類提供的角色順序與逐步操作劇本，用來觀察系統能否承擔這些工程決策。
自主性仍受授權約束。使用者可以授權修改功能，卻保留部署、權限設定或破壞性操作的裁決權。系統必須區分「目前可以繼續做什麼」與「需要新的合法入口才能做什麼」。否則，一次權限拒絕很容易被錯誤理解成應該改用另一種身分嘗試。
以下先沿著契約、派工、狀態與寫入交接拆解架構，再分析故障如何暴露責任邊界，最後對照三個日期的驗收結果，說明自主工作流如何推進與停止。歷史案例的觀測範圍截至 2026 年 10 月 19 日；驗收範圍與資料來源列於文末的認識論分錄。教學程式碼則逐段標明性質，避免把概念介面誤認為平台內建功能。
二、先拆責任：一位主協調者，兩個原生執行平台
跨平台架構最先要解決的不是如何傳話，而是誰負責決定下一步。本文採用主協調者（PRIMARY Coordinator）負責整合目標、工作相依、方法調整與結案；原生工作者（Native Worker）則是實際由各平台角色機制啟動、具有工具執行紀錄的工作實例。單一任務只有一位有效 PRIMARY，專業工作仍可在相依及資源條件允許時並行。
這個安排避免了兩個決策中心各自認為自己有權結案。假設 Claude Worker 發現測試需要調整，它應回傳觀測與建議，由 PRIMARY 判斷是否改變工作圖；不應在另一邊偷偷建立第二套工程目標。共同契約讓兩端對「怎樣算完成」有一致理解，原生平台則各自保有自己的工具、會話與能力限制。
圖二：本案例受測的主控方向是 Codex PRIMARY → 自製 MCP Native Transport → Claude CLI 原生 Worker。Graph 保存工程狀態，Transport 承接執行；共享產物的寫入認領與獨立驗證另有責任。圖中沒有宣稱反向自動派工已驗證。
可以將這套系統理解成幾個彼此交接、但不能互相代言的元件：
| 元件 | 它掌握的事實或決策 | 必須另外取得的證據 |
|---|---|---|
| PRIMARY Coordinator | 使用者目標、工作相依、方法取捨與結案判斷 | 原生執行結果、有效授權、固定產物的驗收證據 |
| 原生 Agent 與技能（Skills） | 領域判斷、探索、實作、審查與測試方法 | 是否真的啟動、實際可用工具及執行能力 |
| 持久化工作圖執行層（Graph Runtime） | 節點、修訂、完成條件與狀態轉移 | 真實程序身分、檔案副作用及測試原始結果 |
| 原生執行橋接層（Native Transport） | 派工受理、原生啟動、輸出收集與已知終態 | 產品是否符合需求、其他程序是否仍存活 |
| 寫入認領輔助程式（File Claim Helper） | 合作協議中的寫入持有人及借還狀態 | OS 是否允許寫入、持有人自述是否符合原生紀錄 |
| 獨立審查者／測試者（Reviewer／Tester） | 固定候選版本與原始證據是否支持驗收 | 該候選版本是否就是最後交付版本 |
這裡的「原生」有實際意義。在完成跨端測試的方向中，Codex 經專案自製的橋接程序啟動 Claude CLI，再由 Claude 的原生機制執行指定 Worker。它不是 Codex 在回覆中模仿 Claude 的語氣，也不是把兩個角色名稱寫進同一段 Prompt 就算完成。
操作介面與執行入口也需要分開。桌面應用（Desktop）是人類與主會話互動的地方；命令列介面（Command-Line Interface，CLI）可以建立另一個具有自身載入條件的會話；MCP Server 是對外提供工具的程序。設定檔存在、主會話看得到工具、對端程序已啟動、產物已通過驗收，是四個不同的觀測點。每跨過一個觀測點，都應留下對應回執，而不是依賴前一位 Agent 的推測。
三、共用契約如何落地：共享語意，保留平台自己的角色機制
共用契約要解決的是語意一致性。例如「實作完成」是否包含讀回產物？「測試成功」必須綁定哪個版本？工具逾時之後，誰有權決定重試？如果 Claude 與 Codex 各自讀到一套不同規則，即使工具彼此連通，交接仍會失真。
本案例的做法是讓共同工程原則有單一入口，再由平台設定展開。AGENTS.md 可承載共同目標、變更範圍、驗收與恢復規則；Claude 的專案入口 CLAUDE.md 明確引入適用契約，並配合自己的角色定義；Codex 則由實際載入的指示與專案設定承接。不能假設 Claude 會因為某份 AGENTS.md 存在，就自動取得所有共同規則，也不能假設已開啟的每個會話都同步套用新設定。
下面是教學用的責任配置圖，不是本案例可直接部署的完整目錄。task-state/ 是用來解說持久化資料位置的通用名稱；兩端必須各自確認檔案確實載入。
workspace/
├── AGENTS.md 共用工程契約
├── CLAUDE.md Claude 平台入口及契約引用
├── .claude/agents/ Claude 原生角色定義
├── .codex/config.toml Codex 專案設定
├── .codex/agents/ Codex 專案角色定義
├── .agents/skills/ 按需要載入的工作知識
└── task-state/ 工作圖、證據索引與恢復資訊
角色檔案的語法必須尊重各平台。Claude Code 使用帶有 YAML 前置資料的 Markdown 定義子代理。以下是依官方格式撰寫的最小教學示例，不是私人正式角色檔；工具清單限制此角色的工具面，並不能代表所有外部程序都受它控制。Claude Code 子代理文件
---
name: candidate-reviewer
description: Review a fixed candidate and report verifiable findings.
tools: Read, Grep, Glob
---
Inspect the supplied candidate version and acceptance criteria.
Report findings with evidence. Do not implement changes.
依撰稿時的 Codex 官方說明，專案可在 .codex/agents/ 使用獨立 TOML 檔定義自訂角色。以下同樣是格式教學示例；名稱與指示由本文設計，不是歷史實測角色檔。它表達審查職責，不會因為指示寫了「不要實作」，就另外建立唯讀的執行沙箱（Sandbox）。Codex 子代理文件
name = "candidate-reviewer"
description = "Inspect a fixed candidate and report evidence."
developer_instructions = """
Read the supplied candidate and acceptance criteria.
Report findings with evidence. Do not implement changes.
"""
平台的載入介面也需要版本意識。官方設定參考仍列有 agents.<name>.description 與 agents.<name>.config_file，用於在設定層宣告角色及對應檔案；這與上面的獨立角色檔案格式應分開閱讀。共同的角色職責可以維持，平台的載入方式卻可能演進。 實作時應對照安裝版本及實際工具清單，不能把一段教學設定當成所有版本皆相同的部署契約。Codex 設定參考
技能負責重用工作知識，角色負責專業分工，兩者都不應暗中增加授權。這也解釋了為什麼根入口不宜無限膨脹：曾有一段工程把每次事故都追加成常駐指示，最後連文件載入上限都成為問題。較合理的分配是保留精簡、始終適用的共同契約，讓角色細節按需載入，歷史事故則作為可追溯資料保存。
這一層如何驗證？不能只檢查檔案存在。至少要從合法的原生入口啟動角色，確認它取得固定輸入、使用預期工具，並留下可核對的結果。只有如此，「Reviewer」才是一位實際執行過的工作者，而不是工作圖中一個好看的標籤。
四、把工程事實留在工作圖：先記意圖，再綁定真實執行
跨會話工作最大的狀態風險，是把一句回報當成一筆已發生的事實。「準備派 Builder」與「原生平台已接受 Builder」之間有時間差；「Builder 已結束」與「測試已確認這版產物」之間也有時間差。Graph Runtime 的價值是將這些差異持久化，讓下一個會話能從已知事實恢復，而不必讀完全部聊天再猜測進度。
一張有用的工作圖不只存節點名稱。它還需要保存工作相依、使用者驗收條件、由主控推導的中間檢查、條件修訂、輸入與產物版本、原生結果的索引，以及遇到未知狀態時尚待確認的事項。這裡的驗收條件稱為 Acceptance Criteria（AC）。若不知道某份測試報告究竟對應哪一版 AC、哪個候選版本，即使報告內容是 PASS，也不足以支撐結案。
以下為概念狀態圖，用來解釋事件順序，並非正式 Runtime 所有狀態名稱的逐字列舉：
PENDING
| 記錄派工意圖
v
DISPATCHING
| 原生平台受理，取得實際執行參照
v
RUNNING
| 收集原始結果與固定產物版本
v
HARVESTED
| 依有效 AC 獨立驗證
v
VERIFIED
| 必要條件成立，未結資源已處理
v
CLOSED
執行中斷且結果不明 -> UNKNOWN -> 唯讀對帳及受控恢復
2026 年 10 月 17 日的控制圖檢查曾暴露一個缺陷，工程紀錄將它標為 F11：派工前的檢查點要求真實 Worker 身分與執行識別，甚至提前要求確認檔案所有權。但 Worker 尚未啟動，也還沒有提出寫入認領。一個任務因此提前填入不正確身分，另一個在啟動後才補記，兩者都不符合預期時序。
根因是狀態機在錯誤的時間要求尚不存在的資料。若只要求模型「更仔細填表」，下一輪仍會遇到相同矛盾。修復原理是將事件拆開：先保存 dispatch_intent，原生工具受理後記錄 launched，必要時再晚綁定真實身分；寫入認領則等到寫者實際需要資源時再發生。F11 是工作圖身分及時序綁定缺陷，不是那兩項產品功能驗收失敗。
並行更新還有另一種風險。假設兩個程序都讀到修訂 12，一個補上執行回執，另一個補上測試結果；若直接各自覆寫整張圖，後寫者可能抹掉前一筆更新。比較後交換（Compare-and-Swap，CAS）要求更新時帶上預期修訂，只有目前版本相符才接受；版本不同就重新讀取、整合，不能盲目重送舊快照。
# 概念偽程式碼；函式皆為本文教學命名，非官方或可直接呼叫的 API。
graph = read_graph()
intent = append_event(
"dispatch_intent", node=node, expected_revision=graph.revision
)
execution = launch_native_worker(scoped_input)
# 工具實際受理後，才有 execution.ref；不可事先猜造。
latest = read_graph()
append_event(
"launched", node=node, execution_ref=execution.ref,
expected_revision=latest.revision
)
result = collect_original_result(execution.ref)
if result.is_unknown:
record_unknown_for_reconciliation(node, execution.ref)
else:
candidate = freeze_artifact_version(result)
verify_against_ac(candidate, effective_ac_revision)
這段示意省略了儲存、錯誤處理與重試實作，不能憑它宣稱取得完整交易保證。尤其原生 Worker 已啟動、但 launched 尚未寫入就崩潰的窗口，仍需要 Transport 的既有紀錄與原生回執協助對帳。CAS 能防止工作圖更新互相覆蓋，不能替外部程序提供「剛好執行一次」保證。
2026 年 10 月 18 日，這套工程的核心契約（Core Contract）C1–C7 正式整合進 Runtime。這是本案例的整合里程碑，並非 Claude、Codex 或 MCP 的官方標準。理解這個結果，仍須把三種責任分開：Graph 管理紀錄一致性，平台提供執行事實，獨立驗證者檢查產物。三者各自留下可核對的證據，狀態欄中的 PASS 才有可追溯意義。
五、MCP Native Transport：讓派工可追蹤，也讓重試有邊界
工作圖知道下一個節點應該執行，並不表示它能直接啟動另一個平台。本案例用 MCP 作為工具連接方式。就標準輸入／輸出（stdio）傳輸而言，用戶端啟動 MCP Server 子程序，雙方經標準串流交換協定訊息；這個標準定義傳訊方式，沒有替應用程式決定誰是 PRIMARY、誰能修改檔案。MCP stdio 規格
本案例在這條通道上加了一層專案自製的 Native Transport。Codex 主控呼叫其工具，Transport 驗證派工資料、保存紀錄，再從合法入口啟動 Claude CLI 原生 Worker。MCP 的傳輸層與專案的原生派工橋接層是不同層次；後者的工具語意是應用設計，不是協定自帶的跨平台 Agent 功能。
這層橋接可依以下工具職責理解。表中名稱屬於本案例的自製應用介面，不是 OpenAI 與 Anthropic 共同提供的內建 API：
| 自製工具 | 它應完成的工作 | 不能順帶宣稱的結果 |
|---|---|---|
dispatch |
核對限定範圍、保存派工意圖、嘗試啟動原生 Worker | 產品已完成或已通過驗收 |
collect |
收集同一執行實例的原始輸出、產物與終態 | 其他子程序一定全部停止 |
status |
回傳有證據支持的已知狀態 | 沒有回覆就代表沒有副作用 |
reconcile |
依停止、副作用、認領釋放與覆核證據處理未知前手 | 逾時後可以無條件再派一位寫者 |
一份派工包至少需要讓接收者知道：這是哪個任務與節點、哪一次嘗試、指定角色是誰、可讀寫哪些資源、輸入版本是什麼、適用授權從哪裡來。輸入以內容雜湊綁定，才能避免「Reviewer 原本要審 A，實際卻讀到後來的 B」。原生執行識別則等受理後再綁定，不能由主控預填一個看似完整的值。
真正棘手的是重試。回到開頭的情境：Claude Worker 可能已經寫完檔案，只是 collect 沒有把結果交回主控。此時「工具逾時」描述的是觀測失敗，不能證明外部操作未發生。同一節點的同一次嘗試應回查既有紀錄；若原結果不明，先確認程序終態、產物副作用及認領狀態。這是避免重複操作的應用層責任，不能因為 MCP 連線恢復就跳過。
因此，Transport 保持狹窄職責很重要。它可以回答某次原生執行的已知終態，不能自封為另一位 Planner，也不應自行修改產品 AC 或擴大權限。主控是否能結案，仍要看固定版本的驗收結果、未結資源與使用者授權。通道的成功只是其中一筆證據。
六、File Write Claim：協調寫入窗口，不能冒充作業系統強制鎖
即使派工與結果都能追蹤，共享工作樹仍可能被兩位 Worker 同時修改。聊天中的「我準備寫這個檔案」不夠可靠：訊息可能延遲，另一個會話也未必看得到。這時需要檔案寫入認領（File Write Claim），由確定性的 Helper 管理合作成員的寫入窗口。
這是一種合作式互斥機制。遵守協議的寫者在動手前先認領；已有有效持有人時，Helper 拒絕另一位寫者。它無法攔截所有編輯器、Shell、第三方程序或未經 Helper 的寫入途徑，不能稱為作業系統的全域強制鎖。
要理解它的能力，必須把幾種常被混在一起的控制分開：
| 機制 | 回答的問題 | 適用邊界 |
|---|---|---|
| 存取控制清單（Access Control List，ACL） | OS 對此執行身分是否允許指定存取？ | 依實際權杖、物件權限與作業系統語意判定 |
| 執行沙箱（Sandbox） | 此執行上下文能接觸哪些路徑、工具或網路？ | 視平台、工具及執行入口而定 |
| 平台核准（Platform Approval） | 這項工具動作是否獲得平台要求的核准？ | 不因契約文字或 Claim 自動取得 |
| 操作守衛／事件掛鉤（Guard／Hook） | 已掛接入口的這次操作是否符合規則？ | 覆蓋範圍及是否具有否決能力，取決於實作與模式 |
| File Claim Helper | 合作協議中，目前誰取得此資源的寫入窗口？ | 不授予 OS 權限，也不約束所有旁路寫者 |
這張表不是通用的固定執行順序。一次寫入可能同時受多層限制，任一層通過都不能替另一層背書。即使 Claim 有效，Sandbox 仍可能拒絕；即使平台允許工具呼叫，也不能推斷已有正確的工程認領。若 Helper 以 Worker 自己的身分執行，帳本自述的 holder 也不是獨立身分認證，仍需核對原生工具紀錄。
正常的認領生命週期是：借閱（Borrow）→ 寫入 → 讀回並固定產物版本 → 正式歸還（Return）→ 確認釋放 → 下一位角色接手。它與任務責任歸屬（Task Ownership）不同。PRIMARY 或 Builder 可以長時間對任務負責，但寫入認領只應覆蓋當次需要修改資源的窗口。若 Builder 等 Reviewer 時一直持有認領，或要求唯讀 Reviewer 也先借到寫入權，就會把協調機制變成阻塞來源。
圖三：互斥證據需要同時成立的持有期間、對端認領拒絕，以及拒絕前後不變的內容雜湊。圖中一個交接序列是教學示意，不能當作帳本事件總數。
本案例的互斥驗證可用下列順序理解：Codex 先成功認領共同資源，Claude 在這段有效持有期間嘗試認領，應被 Helper 拒絕，且共享檔案內容不變；Codex 正式歸還後，Claude 才成功認領。接著交換方向：Claude 持有期間，Codex 的認領應遭拒；Claude 歸還後，Codex 能再認領、讀回並正式歸還。
拒絕必須有正確原因。單獨看到 PermissionError、Hook 拒絕或程序逾時，都不能算作合作式互斥通過，因為那可能只是 OS 權限不足，尚未走到認領判斷。驗收必須對照原生工具結果、有效持有時間、Borrow／Return 帳本與內容讀回，證明「因為對方正持有，所以本次認領被拒絕，且沒有造成寫入」。
2026 年 10 月 18 日的限定跨端終驗對照了 12 組成功 Borrow／Return，以及相對應的 24 筆帳本事件。這是成功借還的計數，不是 12 個產品任務，也不是 24 次互斥衝突或端到端測試。互斥是否成立，要看上述相反方向的競爭與交接證據，不能只看帳本列數。
七、從四種故障學恢復：每一層都要有可驗證的退出路徑
1. 路徑認領遇到硬連結：拒絕新寫入，也要能處理舊持有
失敗時保持關閉（Fail-closed）要求在條件不足時停止危險動作。但若所有拒絕都沒有合法出口，系統就會陷入失敗後卡死（Fail-stuck）：保護仍在，正常工作與恢復卻一起停擺。
本案例曾遇到 Windows NTFS 的硬連結（Hard Link）問題：同一個實體檔案可以有多個名稱，單一路徑不足以代表完整資源。以路徑為基礎的 Helper 因此拒絕一般借閱，是可以理解的保守設計；問題是，同一條限制又套到正式歸還與維護流程。測試留下的多重名稱無法由合法持有人處理，連帳本的中間發布狀態也可能被同一規則阻斷。
修復原理是拆分操作語意：一般借閱防止新增風險，正式歸還處理既有持有，受控恢復處理特定停靠狀態，唯讀對帳提供判斷依據。恢復入口仍須限定物件與前提、保存處置證據，不能用一個「忽略所有檢查」開關取代。這個修復說明的是特定故障的退出路徑；目前沒有涵蓋所有硬連結變體的測試母體，不能延伸宣稱此類風險已全面消失。
2. 契約允許，OS 仍拒絕：ACL 修復必須同時核對能力與保全
另一段工程中，Codex 能讀取必要檔案，卻無法透過 Helper 寫入帳本。若只讀治理文件，很容易誤以為 Guard 或角色設定沒有放行。實際盤點發現，一批舊目錄關閉了 NTFS 權限繼承，新受限執行身分無法經上層目錄取得必要存取。這是實際能力缺口，增加 Prompt 不會改變 OS 的判定。
修復還遇到身分表示的接縫：某些受限身分有有效的安全識別碼（Security Identifier，SID），卻沒有可解析的一般帳戶名稱。如果維修工具先強制把識別碼轉成名稱，再交給要求名稱解析的介面，操作可能在真正修改權限前就失敗。因此，「OS 能識別這個執行身分」與「某個管理介面能以帳戶名稱表示它」，是兩個不同前提；診斷與修復工具必須使用其實際支援的身分表示方式。
更重要的是，檔案內容未變不等於安全屬性未變。一次操作後，部分安全描述元的明示與繼承權限形狀偏離預期。工程因此保留失敗紀錄，對受影響範圍作限定恢復，再與基線核對。在指定原始快照母體上，23,187／23,187 筆保全對帳通過。這是特定母體的保全結果，不是修復了 23,187 個物件，也不是全機 ACL 永久正確的證明。
後續採取更窄的必要授與，再回到正式工作根及受測入口驗證原目標。這個權限與跨端寫入工程在紀錄中稱為 H-2；2026 年 10 月 19 日，原工程目標完成限定的 F1–F5 驗收結案。同時必須保留原 Stage1 失敗、舊 Stage2 驅動未執行的歷史。目標後來達成，不代表舊驅動每個階段都曾成功執行，也不需要為了把舊流程塗成綠色而重新操作正式權限。F1–F5 是該次工程的五項驗收代號，其結案只適用於限定的正式工作根與受測入口。
3. Guard 看見字串，沒有看懂副作用：先找真正的寫入目標
早期一個 Guard 把「保護路徑與寫入動詞同時出現在命令文字」當成風險訊號。結果，讀取治理文件、再把分析寫到普通報告，也可能被誤判成修改治理文件。反方向也有問題：真正的寫入目標若經變數間接表示，單純字串共現未必找得到。
問題在於量測對象錯了。Guard 應辨識哪個操作會對哪個實際目標造成副作用，並對無法確認的部分保留限制；持續堆疊例外字串，只會把同一個錯誤藏進更長的規則。即使改善解析，也必須承認它只看得到已掛接的入口。官方 Hook 文件所列的事件生命週期，是理解這種適用範圍的起點，不能拿來證明自製 Guard 具備相同強制力。Claude Code Hooks reference
本案例後期 Codex 側曾使用僅提供建議（advisory-only）的自訂 Guard：它回傳警示，不直接否決工具請求。該時期的硬性限制仍由平台 Sandbox、Platform Approval 與 OS ACL 各自執行；File Claim 則維持合作協議內的協調責任。這個模式差異必須寫清楚，不能把所有時期的 Hook 都畫成一道全能防火牆。
4. 心跳證明反客為主：確定性時間交給程序處理
為了確認兩端 Worker「仍然活著」，工程曾要求它們每隔數秒產生新證明檔，再依很短的新鮮度期限決定能否繼續。這相當於把大型語言模型（Large Language Model，LLM）的一次推理回合當成即時時鐘，但思考、工具呼叫、上下文整理與磁碟操作都不保證在幾秒內完成。
後果是驗證本身產生更多檔案、借還交易與逾時問題，原本想證明的共享檔案互斥反而被掩蓋。修正採取架構減法：讓確定性的 Helper 與短時間持有資源的程序承擔互斥，讓原生紀錄與正式帳本承擔結果證據，LLM 負責啟動、判斷與收集結果。完成條件應直接量測目標性質，而不是讓模型不停證明自己正在證明。
這四種故障最後回到同一個恢復原則。Worker 若為 UNKNOWN，超過存活期限（Time to Live，TTL）、沒有心跳或缺少回執，都不足以證明它已停止。可以先做唯讀查證、繼續無相依工作；但相依寫入必須等待停止、副作用、認領釋放與必要覆核的證據。UNKNOWN 是需要保存與對帳的工程狀態，不能為了往前跑就改寫成 FAIL，再立即重派。
八、把驗收放回正確母體：三個日期，回答三種問題
前面的設計與事故說明了機制，接下來必須回答「實際證明到哪裡」。狀態機測試、原生 Worker 啟動、共享檔案互斥、產品功能與權限保全，是不同的驗收問題。沒有版本、入口、母體與判定範圍，PASS 的數量很容易變成過度宣稱。
| 日期 | 受測範圍 | 限定驗收結果 | 結果的限制 |
|---|---|---|---|
| 2026-10-17 | 兩項 Codex 單平台 Goal-Only 普通任務 | CSV 6/6、Queue 8/8，外層獨立功能驗證通過；任務觀測窗內沒有使用者補充方法劇本或逐步 CONTINUE | 沒有使用對端 Native Transport；F11 的工作圖身分與時序缺陷另行成立 |
| 2026-10-18 | Core Contract C1–C7 正式整合，限定的 Codex PRIMARY → Claude 原生 Worker 協作 | 經專案自製 MCP Native Transport 啟動 Claude CLI 原生 Worker，與 Codex 端完成指定的互斥、歸還、交接及獨立覆核 | 不代表反向主控完成，也不代表所有測試都是跨平台產品端到端測試 |
| 2026-10-19 | H-2 原工程目標，在限定正式工作根與受測入口驗收 | 限定修復後，F1–F5 通過並結案；指定原始快照母體的保全對帳為 23,187／23,187 | 原 Stage1 失敗與舊 Stage2 驅動未執行仍保留；未涵蓋所有 Sandbox 上下文 |
10 月 17 日尤其能說明驗收為什麼需要分層。兩個普通開發任務的產品功能通過，可以支持那兩個需求在受測條件下成立；後續 F11 檢查失敗，則說明控制圖對真實派工的記錄還有缺口。把兩者合併成「產品失敗」會抹掉有效結果；只留下功能 PASS，又會掩蓋恢復與稽核的問題。
10 月 18 日則需要分清「主控方向」與「資源互斥方向」。同一位 Codex PRIMARY 可以觀察 Codex Writer 與 Claude Writer 輪流認領，驗證雙方在對端有效持有期間遭拒；這仍不等於 Claude 已經能反向擔任 PRIMARY，自動派出 Codex Worker。寫者交換方向，與工程主控交換平台，是不同能力。
10 月 19 日需要分清「原工程目標結案」與「舊修復流程的歷史」。後來的合法修復與重測可以補足原目標所需能力，但先前失敗、未執行與後續替代路徑，都必須保留。這條因果鏈讓後續維運者知道為什麼修改過權限，也知道哪份證據仍只適用於原快照母體。
目前不能據此宣稱的範圍包括：Claude PRIMARY → Codex Worker 的反向自動派工、任意跨平台 Goal-Only 產品閉環、所有 Sandbox 執行上下文，以及長期常駐與各種長時間中斷恢復。這些需要各自的實測設計與證據；已完成的限定測試不會自動外推過去。
九、Auto Workflow 的停止條件：完成使用者目標，也避免無限自我修補
當人類先寫好完整派工劇本，指定每個角色、步驟與下一次操作，Agent 最後完成任務，主要證明的是這份外部編排有效。Goal-Only 驗收刻意移除這種方法指令，才能觀察 PRIMARY 是否會自行辨識相依、選擇角色、收集證據，並在授權範圍內修復可恢復問題。
10 月 17 日的兩項 Codex 普通任務提供了一次限定觀測：CSV 與 Queue 功能驗收成立，且觀測窗內不需要使用者逐步傳送 CONTINUE。但同一輪工程也暴露自主工作流的另一種失敗：它可能知道如何繼續，卻不知道何時足以停止。
當次紀錄中，兩項產品任務本身合計約 41 分鐘，後續 Harness 自我驗證又投入約 2 小時 44 分鐘，最後碰到平台安全拒絕。這是當次流程的時間紀錄，不是一般效能基準。它的價值在於揭露完成條件的漂移：如果每個新發現都成為本次必須修好的元件，任務就會從交付產品，轉成無限擴張的控制器維修。
解法是區分使用者驗收條件（User AC）與主控推導條件（Derived AC）。User AC 是使用者真正要求的結果，不能由主控為了方便而刪除；Derived AC 是為達成目標推導出的中間檢查。若證據顯示某個 Derived AC 過度嚴苛、量錯性質，或已被更小且等效的方法取代，可以記錄理由、修訂條件並接受必要的獨立覆核。這種修訂必須留在工作圖，不能事後偷偷降低成功標準。
例如，「測試固定候選版本」直接支撐產品正確性，不能因為工具不方便就省略；「要求 LLM 每幾秒親自刷新證明」若沒有量到真正的互斥性質，則應重新檢查設計。主控需要說明替代方法如何維持必要性質，再以測試證據確認，而不是用一句「為了效率」取消檢查。
將前面的元件接回實際工作，自主循環可以整理成下列流程。這是責任與決策的概念示意，不表示每個任務都必須啟動所有角色，也不代表已驗證任意跨平台產品任務：
使用者目標、必要輸入、User AC 與授權邊界
|
v
PRIMARY 釐清相依與風險，建立工作圖及 Derived AC
|
v
選擇必要角色與執行入口，記錄意圖並取得原生回執
|
v
Worker 依寫入認領實作，讀回產物並歸還資源
|
v
Reviewer / Tester 對固定候選與有效 AC 提交證據
|
+------------+-------------+
| | |
v v v
條件成立 可恢復缺陷 狀態不明或超出授權
整理後結案 修訂方法再驗證 保存 UNKNOWN / 等待合法入口
其中最容易被省略的是回到實作的那一段。如果 Tester 發現缺陷，PRIMARY 應先判斷失敗對應產品需求、測試環境還是控制紀錄，再決定修復哪個節點。修復後產物已改變，前一版的 PASS 便不能直接沿用；新的驗證必須重新綁定候選版本與有效條件。工作圖保存的也不能只有最後一次成功，還要留下前一輪失敗與方法修訂，讓恢復者知道為什麼又執行了一次。
結案則需要相反的判斷：必要條件已由相應證據支持，寫入認領已正式歸還，未知前手不再阻擋相關工作，剩餘事項也沒有被隱藏為成功。此時應交付成果與適用限制，而不是因為還能想到另一個改善，就自動把它變成本次工程的新目標。這正是 Auto Workflow 與一段永遠重試的腳本之間的差別。
對準備建立類似系統的團隊，可以從一個逐步擴大的最小閉環開始：先定義目標與權限，讓每端原生角色能在固定輸入下完成工作，再用真實程序驗證共享資源的借閱、拒絕、歸還及異常退出。接著加入只記錄已發生事實的持久化工作圖，最後才接入單一方向的跨平台 Transport，確認未知前手不會導致盲目重派。
當這些底座具備證據，再以普通產品需求做 Goal-Only 驗收，同時檢查產品 AC、控制圖、人工方法介入與未結資源。角色是可選用的專業能力，不是每項任務必須走完的流水線；反向主控與更多並行工作，也應在既有方向可靠後另行驗證。這樣增加複雜度，才知道每一層究竟解決了什麼問題。
結語：可自主推進的工程，也必須可解釋地恢復與結案
Claude Code 與 Codex 的跨平台協作，核心在於把意圖、執行、狀態、資源與證據接成一條可核對的鏈。共同契約讓兩端理解相同的完成語意；原生 Worker 提供實際執行；MCP Native Transport 承接受理與收集；Graph Runtime 保存版本化的工程事實；File Write Claim 協調合作寫者；平台與 OS 執行各自的能力限制；獨立驗證則把成功宣告綁回固定產物。
這些責任清楚後，人類才有機會退出日常的逐步派工，同時保留授權與最終責任。遇到未知時，系統能保存缺口、合法對帳；遇到權限邊界時，能指出必要入口；條件成立時，也能停止擴張工作並交付結果。
衡量這類架構，應看它是否在明確範圍內完成真實需求、留下可獨立檢查的證據，並保留失敗與修訂的因果歷史。模型、工具與平台會繼續變動，能讓工程延續的，是後來的人與 Agent 仍然可以回答：做過什麼、為什麼這樣做、目前證明到哪裡，以及下一次中斷時該從哪裡恢復。
🔗 認知脈絡與延伸閱讀
以下官方文件於撰稿時核對，用來查證公開介面。教學角色設定、概念狀態與偽程式碼須依實際版本調整；它們不包含完整部署與安全實作。
- Claude Code：Create custom subagents：原生角色檔案、工具範圍與載入方式。
- Claude Code：Hooks reference：事件入口、輸入輸出與判定生命週期。
- Codex：Subagents：原生子代理、自訂 TOML 角色與繼承的執行限制。
- Codex：Configuration Reference：專案設定、角色設定層與 MCP Server 配置。
- MCP：Transport overview：協定傳輸與應用語意的責任區分。
- MCP：stdio transport：以子程序標準串流承載訊息的規範。
本站相關長文可對照閱讀〈數位巴別塔〉對來源、失敗與重建路徑的討論，以及〈當 AGI 注定成為認知巨人〉對提議與裁決分工的討論：
🏛️ Epistemic Ledger Entry: #0009
- Timestamp:
2026-10-22T02:54:40+08:00 - Claim: 跨平台自主工程需要將共同契約、原生執行、持久化狀態、合作式寫入協調與獨立驗證分離，再用明確版本及恢復證據連接。工具成功、產品成功與控制圖正確性應分層判定，結案也必須保留先前失敗與未執行歷史。
- Epistemic State:
High Conviction (Architecture Principle) / Limited Empirical Validation - Evidence Scope: 驗收數字依 2026-10-17 至 2026-10-19 工程案例的整理資料引用，撰稿時未重跑私有測試。Codex 單平台 CSV 6/6、Queue 8/8；限定 Codex PRIMARY → Claude 原生互斥交接；H-2 於受測正式工作根及入口完成 F1–F5。12 組借還、24 筆事件及 23,187／23,187 保全對帳，分別只代表其指定母體。官方文件用於核對公開介面，不是上述私有測試結果的獨立證明。
- Dependencies: 有效授權與實際載入契約；原生工具回執；固定產物及有效 AC 修訂；遵守 Claim 協議的合作寫者；獨立覆核；限定執行上下文。
- Revision Trigger: 反向主控、更多跨平台產品需求、不同 Sandbox 或長時間中斷若產生新證據，應追加對適用範圍的修訂；若旁路寫入或未知前手處理反例出現，也必須重新檢查目前的協作保證。
