假設要重整一套散落在 API、middleware 和 tests 裡的 permission logic，可以很快開出三條工作線：一個 Agent 找所有 permission checks，一個改 implementation，另一個補 tests。
三條線真正開始互相衝突，是在它們回來時各自帶著不同前提。
負責找 code 的 Agent 認為某支 middleware 不該碰；改 implementation 的 Agent 已經動了它；tests 全綠，但驗的還是舊行為。這時再多開一個 Agent 沒什麼幫助，因為問題根本還沒被切清楚：permission model 誰說了算？Worker 可以改到哪裡？它回來時要附什麼 evidence？兩份結果互相衝突時，誰決定哪一份進主線？
本文把負責拆解與收斂的角色叫 主 Agent，執行 bounded task 的叫 Worker，負責獨立驗證的叫 Checker。這三個只是方便談 responsibility boundary 的名稱，不是 Codex 介面裡的固定角色。
先把 permission model 的決定留在一個地方
如果新的 permission model 還沒決定，讓三個 Worker 同時動手只會把歧義分散到三條工作線上。
主 Agent 在這個階段要做的事情很具體：定 outcome、切 scope、標出 dependencies，還有寫下什麼情況算驗收通過。至於 codebase search、大檔 review、caller mapping 這種可以獨立交差的工作，才適合拆出去。
OpenAI 在 GPT-5.4 mini 的發布裡就用了這種 manager-worker 分工。較大的 GPT-5.4 保留 planning、coordination 和 final judgement，mini subagents 去處理 codebase search、large-file review、supporting documents 等較窄的工作。[1] 型號之後會換，這裡只借它的分工方式。
回到 permission refactor，可以先把工作拆成這樣：
- Worker A 只負責找齊 session creation 牽涉到的 permission checks。
- Worker B 在 permission rule 已經批准後，才改指定 implementation。
- Worker C 盤點 migration 會碰到哪些 callers 和 tests。
新的 permission model 長什麼樣、公開 API 要不要變、兩個 Worker 的假設衝突時採哪一個，仍由同一個 decision owner 收回來判斷。
Codex App 已經支援多個 Agent 平行工作，也用 worktree 隔開各自的 working copy。[2] 這讓多條施工線比較不容易互踩檔案，但它不會替你決定 architecture。
Figure 1｜主 Agent 保留 decision ownership，Worker 做 bounded execution，Checker 驗證 claim，最後由 Lead Agent 或 Human 負責 closure。
Worker 回來時，要能直接驗收
「幫我處理 permissions」幾乎沒有提供邊界。Worker 得自己猜目標、自己猜能改哪裡，最後再自己決定什麼叫完成。
探索型工作可以收得很窄：
Goal:
Map every permission check involved in session creation.
Scope:
Read only. Do not modify files.
Return:
- file path
- function or rule
- current behaviour
- unresolved ambiguity施工型工作則是另一種 contract：
Goal:
Implement the already-approved session permission rule.
Writable scope:
src/auth/*
tests/auth/*
Return:
- changed files
- tests run
- failures or assumptions這些格式只是示意，Codex 沒有要求固定 schema。Worker 回來後，主 Agent 不該還要重新翻一次整個 repository，才能知道它改了什麼、碰了哪些 scope，以及回報的 evidence 能不能拿來驗收。
Worker 在過程裡發現 scope 外的問題也很正常。它可以把問題列回來，但不要順手把新問題併進原任務。這種 scope drift 一旦發生在兩三條平行工作線上，後面很難分辨哪些 change 是原本就批准的。
Worktree 把檔案分開，兩套假設還是可能撞在一起
把 Worker 放進不同 worktree，解決的是 working state。
OpenAI 在 Harness Engineering 裡讓 app、logs 和 metrics 也能按 worktree 啟動與觀察，讓每個 change 可以在自己的環境裡驗證。[3] Symphony 則把 workspace 綁到 issue，coding agent 只在那個 issue 的 workspace 裡工作；orchestrator 另外維持一份 authoritative state，負責 dispatch、retry 和 reconciliation。[4]
可是 Worker A 和 Worker B 就算完全沒有 Git conflict，還是可能做出兩套互相衝突的 permission contract。
假設 Worker A 決定 session token lifetime 要縮短，Worker B 卻照舊 lifetime 去補 migration。兩邊可以完全沒有 Git conflict，各自的 tests 也可能都過。等到 integration 才會發現，兩個 change 根本在實作不同的 permission contract。
state ownership 可以拆成兩層看：
Working-state ownership 管的是 Worker 在哪個 workspace 裡動哪些 files。
Semantic ownership 管的是某個 architecture decision、schema、contract 或 invariant 最後由誰定義。
worktree、workspace 和 write scope 能把第一層切得很清楚。第二層如果沒有人負責，衝突只是晚一點爆出來。
Figure 2｜Workspace isolation 能隔開 working state；不同 Worker 對 contract 的理解，仍要回到同一個 convergence owner 收斂。
Worker 說 done 之後，Checker 才開始工作
done 是 Worker 對 execution completion 的 claim，不等於整件事已經可以接受。
OpenAI 在 Harness Engineering 裡要求 Codex 先 review 自己的 change，再 request 額外的 specific agent reviews，接著處理 human 或 agent feedback；文中也提到，他們把大量 review effort 移向 agent-to-agent review。[3]
放到 permission refactor 裡，Checker 可以只盯幾件事：
- diff 有沒有跑出批准過的 write scope；
- acceptance criteria 有沒有真的被滿足；
- tests 驗的是新 permission behaviour，還是只把舊 tests 修到變綠；
- Worker 的結論能不能從 code、test、log 或其他 evidence 重現；
- 還有哪些 assumption 沒有被解掉。
Checker 發現 architecture 問題時，可以 reject 並附上 evidence，但不要順手把整套 permission model 重設一遍。那個決定要回到原本的 decision owner。
Worker 可能真的把指定 change 寫對了，但 acceptance criteria 本身定錯；也可能 criteria 沒問題，implementation 卻漏了一條 caller path。
三條線收回來之後，還有人要負責 closure
假設 Worker A 找到一條沒預期到的 legacy rule，Worker B 已經照新 contract 完成 implementation，Checker 又發現 migration tests 對舊 lifetime 有依賴。到這裡沒有哪一份 output 可以單獨決定最後答案。
主 Agent 或指定的人類 owner 得重新對齊假設、確認 dependency order、決定 legacy rule 要不要留在本次 scope，最後才判斷這個 refactor 能不能接受。
Symphony 的規格允許一次 successful run 停在 Human Review，不必直接把 tracker item 推成 Done。[4] run 成功、tests pass、review 沒有新 finding，都只說明某一層完成了；整件工作的 acceptance 仍然需要明確 owner。
高風險工作裡，這個 owner 可以是人。OpenAI 對 Codex 的安全治理另外處理 sandbox、approval、access boundary 與 agent-native telemetry。[5] 這些機制處理 Agent 的執行邊界、approval 和 auditability；誰負責接受整件工作，仍由 workflow 自己定義。
有些 permission change 根本不值得拆
如果 permission contract 還在改、三個子任務一直碰同一份 state、每一步都依賴前一步的細節，硬拆 Worker 只會增加 hand-off 和 integration。
Symphony 的文章提到，OpenAI 團隊觀察到多數人同時管理大約三到五個 interactive sessions 後，context switching 就開始變得痛苦，productivity 也往下掉。[4] 3–5 個 session 是 OpenAI 團隊在那套 workflow 裡的觀察，不能拿來當所有人的上限。Agent 可以同時跑更多工作，但人的 attention 不會跟著線性增加。
同一篇文章也保留了例外。碰到模糊、需要強 judgement 和 expertise 的問題，工程師仍然會回到 interactive Codex session。[4]
派下一個 Worker 前，先看它的 write scope 能不能切乾淨、回來的結果能不能單獨驗收，以及它和其他工作線之間要交換多少 state。這三件事還說不清楚時，先留在一條 thread 裡，反而比較容易看清楚前後依賴。
參考資料
[1] OpenAI, “Introducing GPT-5.4 mini and nano”, 2026-03-17.
[2] OpenAI, “Introducing the Codex app”, 2026-02-02.
[3] OpenAI, “Harness engineering: leveraging Codex in an agent-first world”, 2026-02-11.
[4] OpenAI, “An open-source spec for Codex orchestration: Symphony”, 2026-04-27.
[5] OpenAI, “Running Codex safely at OpenAI”, 2026-05-08.