把每種工作都交給一個「數位員工」，聽起來很像成熟的 AI 團隊。金塵馬的 Codex 多 Agent 教學把內容創作、專案管理、財務與知識庫各自放進目錄，並讓 Main Agent 作為預設入口。這個做法真正值得採用的，不是先建立一張職稱表，而是把長期重複的工作，連同它的規則、資料範圍、工具與驗收方式放在同一個可審查邊界裡。
我的立場是：**只有當一類工作穩定重複，且至少有一項專屬資源時，才值得新增 Agent。**其他事情留給目前的入口 Agent 或一個專案目錄即可。這比先建立十幾個空角色少了維護成本，也讓每次路由有可以檢查的理由。
Agent 是長期職責；專案是這次要完成的事
兩者都可能是資料夾，卻不該承擔相同責任。
| 問題 | 專案 | Agent |
|---|---|---|
| 邊界由什麼決定 | 一個產品、文章、repository 或交付目標 | 一項持續存在的工作職責 |
| 主要保存什麼 | 任務的素材、目前狀態與階段性成果 | 規則、工作流程、可用工具、資料範圍與驗收方式 |
| 何時結束 | 目標完成或專案停止 | 直到這項職責不再需要 |
| 過度拆分的代價 | context 被分散 | 規則重複、路由模糊、權限面增加 |
例如「為 CarlStack 寫這篇文章」是專案；「把來源查核、繁中寫作、封面、檢查與發布做成一致流程」才是內容創作 Agent 的職責。同一個內容創作 Agent 可以服務多篇文章；同一篇文章也可能需要研究、寫作與發布等多個職責共同完成。
OpenAI 的模型指引提醒，模型會受到 AGENTS.md 與 Skills 等檔案中的指令影響，因此應定期審查可被讀取的規則與其衝突。這不是把 Agent 資料夾當人事資料夾的理由；反而表示每新增一層規則，都是一項需要負責的介面。官方模型指引
用四個訊號判斷要不要新增 Agent
新 Agent 至少要同時滿足「工作重複」與下列任一訊號。只有主題不同，例如今天寫 AI、明天寫職涯，通常不構成新 Agent。
| 專屬訊號 | 例子 | 若不存在，先用什麼 |
|---|---|---|
| 規則 | 發布前必須完成來源查核、格式與 CI | 目前 Agent 的任務指示 |
| 資料 | 只能讀取發票、帳戶或指定知識庫 | 專案內的明確資料夾 |
| 工具 | 需要特定 connector、資料庫查詢或發佈工具 | 一次性的受控工具呼叫 |
| 權限 | 可建立草稿，但不能對外發布或付款 | 保留在人工審批流程 |
| 交付與驗收 | 必須交付可合併 PR、已發布文章或對帳結果 | 專案的 acceptance criteria |
這是停止規則：如果沒有任何專屬訊號，就不新增目錄、不寫新的 AGENTS.md，更不建立角色人設。一次性的特殊要求留在當次對話；同一類錯誤反覆發生，且修正方法已被驗證，才提升為長期規則或 Skill。
先跑一條最小路由，不要先做完整組織圖
一個可工作的初始結構只需要預設入口和一個已證明有需要的職責。以下範例把隊伍規則與專案資料分開；不要求所有檔案都搬進同一個父目錄。
digital-team/
├── AGENTS.md # 預設入口與共用邊界
└── agents/
├── main-agent/AGENTS.md # 路由與結果整合
└── content/AGENTS.md # 寫作、來源與發布的職責
carlstack/ # 實際文章專案與內容資料根目錄規則保持短小即可：它只負責路由，不能偷偷複製所有職責細節。
# Digital Team
## 入口
- 使用者未指定職責時，讀取 `agents/main-agent/AGENTS.md`。
- 需要正式內容創作、來源查核或發布時，Main Agent 讀取 `agents/content/AGENTS.md`。
- 其他工作由 Main Agent 直接處理；職責規則不自動互相套用。這不是安全隔離。AGENTS.md 描述應有行為；能否真的讀取檔案、寫入資料或呼叫外部服務，仍由工作區範圍、sandbox 與 approval policy 決定。對刪除、付款、批量修改與對外發布這類不可逆動作，規則應要求事前確認，而環境也必須保留實際的許可門檻。把「不准讀財務資料」寫進提示，不能代替檔案權限、獨立帳號或最小權限憑證。
路由要有正例與反例，才知道它沒有變成萬用吸塵器
新增內容職責後，至少用兩句真實請求測試：
| 請求 | 預期路徑 | 成功證據 |
|---|---|---|
| 「把這則來源寫成正式文章並發布」 | Main → content Agent → 寫作／發布流程 | 有來源、草稿或文章、必要檢查與發布結果 |
| 「這個選題值得寫嗎？」 | Main Agent | 回答選題判斷，不啟動完整發布流程 |
正例證明該進入的工作會讀到必要規則；反例避免任何帶有「文章」兩字的對話都被昂貴流程攔截。若模型路由錯誤，先縮小角色職責或補足反例，不要立刻增加第二層 router、配置中心或更多角色。
同樣地，Skill 應封裝已穩定的多步工作，而不是把所有偏好都搬進全域清單。它的描述要說明何時使用、何時不用；隨著可讀取的規則增加，也要刪除過期內容。官方文件同樣建議審查模型可見的 Skills 與指令檔，避免不清楚或衝突的規則影響執行。OpenAI Docs
權限和職責一起切，但不要把它們混為一談
職責切分的價值，在於可以縮小資料與操作面：內容 Agent 不需要帳務資料；財務 Agent 也沒有理由預設擁有社群發文權限。但它不會自動產生技術上的隔離。
最小的分級足以先運作：
- 查詢資料與產生草稿可在狹窄工作區內直接進行。
- 建立或修改記錄時，先顯示精確目標與預期差異。
- 刪除、批次寫入、付款、發送與公開發布，必須在執行前明確確認。
隨著工作增加，再把「能做什麼」轉成可強制的控制：限制可寫目錄、為不同服務使用不同帳號、縮小 token 的 scope，並把高風險工具保留在 approval gate 後。好的規則讓 Agent 知道該停在哪裡；真正的權限控制讓它即使判斷錯誤，也到不了不該去的地方。
下一步：只為一個反覆出現的工作建立邊界
不要從「我需要哪些數位員工」開始。挑最近一個每週都會重複、每次都得重新交代背景的工作，寫下它專屬的規則、資料、工具、權限和驗收。若其中至少一項確實獨特，就建立一個 Agent，並跑過一個應命中與一個不應命中的請求。
兩條請求都穩定後，再考慮第二個職責。此時你擴充的不是一張漂亮的 Agent 組織圖，而是一個已證明能降低重複交代與錯誤路由的工作邊界。