把幾個角色資料夾放進 Codex 專案，能建立清楚的分工；但資料夾本身不會產生同時工作的數位員工。 一套可維護的 Codex 團隊其實有兩層：AGENTS.md 與 Skills 固定職責、路由和工作方法，原生 Subagent 才建立獨立執行緒，把互不相依的工作平行處理。
這個區分補上了近期社群「一人公司也能組 AI 團隊」教學裡最容易混淆的地方。金塵馬分享的資料夾架構很適合當角色手冊：主 Agent 先判斷需求，再依明文規則讀取內容、研究或專案角色的指令。若目標是讓研究員、審稿員與工程師真的同時動手，還要接上 Codex 的 Subagent 機制。
先把四個概念拆開
| 元件 | 解決的問題 | 是否建立獨立執行緒 | 適合放什麼 |
|---|---|---|---|
| Project | 這一次要完成什麼 | 否 | 目標、素材、交付物、期限 |
| Role Agent | 誰長期負責哪類工作 | 否 | 職責、邊界、路由、輸出格式 |
| Skill | 這類工作要怎麼做 | 否 | 可重複流程、範本、腳本、參考資料 |
| Native Subagent | 哪些獨立工作要分線執行 | 是 | 研究、探索、實作、審查等可並行任務 |
Project 是暫時的工作物件，Role Agent 是長期職責。今天要寫「網站改版案例」是一個 Project；內容編輯每週都要負責長文、校稿與交付格式，才值得成為一個 Role Agent。
新增角色前，至少確認它有一項其他角色沒有的資源：獨特規則、Skill、工具、資料、權限或交付物。若差別只剩名字與語氣，先保留一個主 Agent，否則維護成本會比產出更快增加。
最小目錄：角色層與執行層分開
以下架構保留社群教學裡好用的角色資料夾，再加入 Codex 官方的專案級 Subagent 設定：
workspace/
├── AGENTS.md
├── digital-team/
│ └── agents/
│ └── content-creator-agent/
│ ├── AGENTS.md
│ ├── skills/
│ │ └── longform-writing/
│ │ └── SKILL.md
│ └── .agents/
│ └── skills/
│ └── longform-writing -> ../../skills/longform-writing
├── .codex/
│ ├── config.toml
│ └── agents/
│ ├── content-researcher.toml
│ └── content-reviewer.toml
├── knowledge-base/
├── content-projects/
└── code-projects/
digital-team/agents/ 管長期職責，.codex/agents/ 管可委派的執行角色。兩者可以同名，但用途不同：前者是專案內的工作手冊，後者會讓 Codex 建立獨立 Agent thread。
根目錄 AGENTS.md 只做路由，不要塞滿所有規則
Codex 啟動工作時，會從專案根目錄一路走到目前工作目錄，讀取路徑上的 AGENTS.md；越靠近目前目錄的內容越晚載入，因此能覆蓋前面的規則。預設合併上限是 32 KiB，根檔案應保持精簡。
# 團隊路由
你是主 Agent，先判斷需求是否需要專門角色。
## 內容創作
當使用者明確要求撰寫、改寫或編輯文章時：
1. 讀取 `digital-team/agents/content-creator-agent/AGENTS.md`。
2. 視需要讀取該角色列出的 Skill。
3. 若研究與審稿互不相依，委派給對應 Subagent。
若使用者只是討論寫作方法，不要切換角色；由主 Agent 回答。
## 共同邊界
- 未經明確核准，不發布、不付款、不刪除資料，也不傳送外部訊息。
- 機密只從受控環境取得，不得寫進指令檔或範本。
- 最終回覆要列出已完成事項、驗證結果與待處理風險。
為什麼要把路徑寫清楚？官方的探索規則只會沿著專案根目錄到目前工作目錄載入指令。它不會自動掃描旁邊每一個角色資料夾。換句話說，主 Agent 讀到內容角色的 AGENTS.md，是因為根規則明確要求它去讀，並非資料夾名稱具有魔法。這是根據官方探索範圍做出的直接推論。
角色 AGENTS.md 要寫清楚「做」與「不做」
內容角色不需要重複公司的所有共通政策，只要補上自己的責任與交付格式：
# 內容創作者角色
## 主要職責
- 把已核實的素材整理成結構完整的長文。
- 保留來源界線，不把社群經驗寫成普遍事實。
- 交付標題、摘要、正文、來源與待確認事項。
## 不負責
- 不自行發布文章。
- 不修改產品程式碼。
- 不把未核實數字補成確定結論。
## 工作方法
長文任務使用 `$longform-writing`。
需要並行研究時，委派給 `content-researcher`；完成草稿後，再交由 `content-reviewer` 檢查。
這份檔案不靠「角色個性」創造價值。它讓工作邊界可以被檢查；當結果不對，團隊能判斷問題出在路由、Skill、資料，還是執行權限。
Skill 保存方法，Subagent 保存執行角色
一個最小的 Skill 可以只有 SKILL.md：
---
name: longform-writing
description: 當任務需要撰寫、重寫或編輯長篇文章時使用。
---
# 長文寫作
1. 先列出主張、證據與不確定處。
2. 每一個核心事實都要能追到來源。
3. 先完成結構，再處理語氣與節奏。
4. 交付前檢查標題是否忠於正文。
Codex 會先看到 Skill 的名稱、描述與路徑，觸發後才讀取完整內容；這就是漸進式揭露。Skill 很多時，初始清單仍有上下文上限，因此 description 必須直接說明「何時使用」，不要寫成品牌口號。
專案會從目前目錄往上掃描 .agents/skills。官方也支援 symlink，所以可以把可編輯來源保留在角色資料夾，再建立發現入口：
cd digital-team/agents/content-creator-agent
mkdir -p .agents/skills
ln -s ../../skills/longform-writing .agents/skills/longform-writing
在預設 workspace-write 模式下，工作區裡的 .agents 與 .codex 會受到唯讀保護。這類初始化最好由你在終端機完成，或在專案建置階段明確處理，不要假設執行中的 Agent 能自行改寫治理設定。
真正要平行工作，就建立原生 Subagent
截至 2026 年 9 月，Codex 已預設啟用 Subagent 工作流。每個 Subagent 有自己的執行緒與上下文，主 Agent 負責委派、等待與彙整。官方內建 default、worker 與 explorer，也能在專案的 .codex/agents/ 定義自訂角色。
研究角色可以這樣寫：
name = "content-researcher"
description = "查核文章核心主張並回傳來源、證據與不確定處。"
developer_instructions = "只做研究與查核，不修改文章檔案。優先使用第一方來源；每項結論附上連結與證據邊界。"
sandbox_mode = "read-only"
審稿角色則把責任鎖在草稿檢查：
name = "content-reviewer"
description = "檢查技術文章的事實一致性、可執行性與權限風險。"
developer_instructions = "讀取草稿與來源，列出具體問題和建議修改；除非主 Agent 明確授權，不直接改檔。"
sandbox_mode = "read-only"
再設定同一個工作階段允許的執行緒數：
[agents]
max_concurrent_threads_per_session = 4
委派時不要只說「組一個團隊」。把可獨立的工作切開，指定產出與寫入邊界：
請建立兩個 Subagent：
1. content-researcher 查核官方文件，只回傳來源與結論，不改檔。
2. content-reviewer 檢查現有草稿的步驟、權限與術語，只回傳問題清單。
兩者可平行執行。等待全部完成後，由主 Agent 統整並修改文章。
Subagent 很適合獨立研究與大範圍探索，也會多用 token。若兩個任務會同時修改同一份檔案，平行化反而容易製造衝突。實務上讓研究員與審稿員唯讀，最後只留一個 writer，通常更穩。
AGENTS.md 是行為規則，無法提供安全隔離
「不准刪檔」寫在提示裡，只是行為約束；真正限制能力的是 sandbox 與 approval policy。Codex 在本機使用作業系統層級的 sandbox，網路預設關閉，寫入通常限制在工作區。常見的 Auto 設定是 workspace-write 搭配 on-request 核准。
部署前至少做四件事：
- 先選好主 Agent 的權限模式再委派，因為 Subagent 會繼承父層的 permission mode。
- 研究與審查預設唯讀；寫入、刪除、付款、部署與發布分開核准。
- 不把 API key、密碼或客戶資料寫進
AGENTS.md、Skill 或範本。 - 每份可寫檔案只指定一個 owner；需要多人實作時，切分檔案或 worktree。
自訂 Agent 的 sandbox_mode = "read-only" 是合理預設，但不能把它當成永遠比目前工作階段更嚴格的保證。官方說明，啟動時的即時權限覆寫仍會重新套用到子 Agent。安全審查要看實際執行模式，不只看 TOML。
用正、反兩組測試驗證路由
第一個測試確認明確任務能進內容角色：
我要創作一篇文章。請先列出你載入了哪些 AGENTS.md、使用哪個角色、是否觸發 Skill，以及判斷理由；暫時不要寫正文。
第二個測試確認一般討論不會過度路由：
我有個寫作方法想和你討論。請說明你是否切換角色，以及為什麼。
接著再測一次 Subagent：讓兩個唯讀角色同時檢查不同材料，要求主 Agent 等待並合併結果。驗收時不要只看回答像不像團隊，而要看是否真的出現不同 Agent thread、每條 thread 的責任是否正確、是否有人越界寫檔。
規則更新後重跑這三組測試。已經不再重複出現的規則就刪掉；根 AGENTS.md 愈長，衝突與上下文截斷的機率愈高。
什麼時候值得新增一個 Agent？
當某類工作反覆出現，而且擁有獨立規則、工具、資料、權限或交付物時，才值得新增。一次性的網站改版比較像 Project；每週都要盤點需求、排程與驗收，才值得設成專案經理角色。
Role Agent 與原生 Subagent 不必二選一
可以。只需要一致的工作方法時，用 AGENTS.md 與 Skill 就夠了；只需要一次平行研究時，直接要求 Codex 建立 Subagent。長期團隊通常兩層都需要：角色層保存制度，執行層按任務展開。
Codex 不會自動讀到所有角色資料夾
不會。官方探索範圍是從專案根目錄到目前工作目錄。旁邊的角色檔案要靠根規則提供明確路徑，或由使用者直接在該角色目錄啟動工作。
Subagent 設定成唯讀就絕對安全嗎？
不能只靠唯讀設定。安全邊界要以實際 permission mode、sandbox、approval policy、可用工具與憑證為準。提示與 Agent TOML 是治理的一部分，無法取代技術隔離。
權威引用
- OpenAI：使用 AGENTS.md 提供專案指令
- OpenAI：Codex Subagents
- OpenAI：建立與使用 Skills
- OpenAI：Agent 核准與安全
- OpenAI：Codex 產品頁
社群案例來源：
Author Insight
數位團隊最值得設計的是交接面，角色名稱反而其次。研究員交付哪些證據、審稿員只能指出哪些問題、writer 在什麼條件下能寫入，這些界線一旦可驗證，Subagent 才能擴充產能；沒有交接規格，多開幾條 thread 只會更快製造不一致。
術語表
- Role Agent：用專案指令描述的長期職責，不必然對應獨立執行緒。
- Subagent：由 Codex 建立的獨立 Agent thread，完成被委派的工作後回傳結果。
- Skill：以
SKILL.md為入口的可重複工作方法，可附帶腳本、參考資料與資產。 - sandbox：在作業系統層限制檔案、網路與命令能力的技術邊界。
- approval policy：決定 Codex 何時必須先向使用者取得核准的設定。
