DeepSeek Harness Job Panel 子代理分工指南

你看到 Job Panel 裡有多個任務，卻不知道誰正在改檔案、誰負責失敗結果。
最快解法：不要按子代理品牌固定分工，先為每項工作寫好目標、輸入、可寫範圍、權限、驗收產物與失敗負責人。

這篇適合誰

這篇給準備把大任務拆給多個子代理的獨立開發者，也適合需要管理並行程式任務與倉庫寫入邊界的小型研發團隊。
如果你負責遠端執行環境、權限、連線中斷或任務恢復，下面的判斷框架也能直接用在值班 runbook。

提醒：截至 2026 年 8 月 18 日，rc.7 Release 已確認 Codex 與 Claude Code 子代理任務可以接入 Job Panel；這只代表接入面，不代表面板自動提供檔案隔離、權限隔離、衝突解決或跨重啟恢復。正式上線前，仍應核對官方 Release 記錄、架構文件及相關程式碼變更。

先分清責任，再選子代理

DeepSeek Harness Job Panel 的價值在於集中查看任務，而不是替你決定任務邊界。最常見的錯誤，是主 Agent 已經修改同一個檔案，子代理又收到「完成這項功能」的模糊指令。最後即使其中一方成功，主 Agent 也難以判斷哪一份結果才是正式產物。

每項子代理任務至少要有以下資料：

• 唯一任務標識：例如 auth-readonly-01，不要只用「後端任務」這種名稱。
• 單一目標：只處理一個可驗收結果，不把研究、修改與部署混在同一項工作。
• 輸入來源：指定 commit、分支、檔案清單或調研文件。
• 唯一負責人：主 Agent、子代理或人工值班者只能有一個最終接管者。
• 產物位置：差異檔、測試輸出、日誌摘要與未完成項目要能被主 Agent 直接讀取。

Codex 的官方介紹也把專案指引、測試命令與程式碼規範視為任務上下文的一部分；因此，你不應只把自然語言需求丟進面板，而要把「在哪裡工作、能執行什麼、完成後交什麼」寫進任務契約。可參考官方 Codex 工作方式說明。

DeepSeek Harness Job Panel 怎麼管理子代理？
把 Job Panel 當成任務登記、狀態觀察和結果匯總層。真正的所有權仍要由任務契約、版本控制記錄和驗收文件共同確認。面板顯示某項工作存在，不等於它擁有該檔案，也不等於它在背景持續執行。

Codex 與 Claude Code 的適用邊界

不要先問「Codex 比較適合什麼」或「Claude Code 能不能完成什麼」，而是先把工作分成能力要求。品牌名稱不能替代當前版本的實測；同一個子代理在只讀環境、可寫倉庫和有外部工具的環境中，風險完全不同。

這個評分不是 Codex 或 Claude Code 的產品排名，而是該類任務在責任可追蹤性上的穩定程度。只讀調研通常最容易接管；外部工具任務則要先處理憑據、網路和人工批准。

Claude Code 的官方文件把子代理視為具有獨立指示與工具配置的工作單位；這可用來設計任務契約，但不能據此推斷你的 Job Panel 已經完成作業系統層級隔離。可對照Claude Code 子代理文件。

Codex 和 Claude Code 子任務應該怎樣分工？
可採用「能力而非品牌」的分法：

• 調研代理：只讀搜尋、列出相關檔案和風險，不提交修改。
• 修改代理：只處理一個模組，使用獨立分支或 worktree。
• 驗證代理：只執行建置、測試、靜態檢查，不自行修正失敗。
• 主 Agent：決定是否接受、返工、回退，並保留最終合併責任。

如果當前版本尚未證明某個代理能穩定執行建置、工具呼叫或結果回傳，就先用低風險只讀任務做最小驗證，不要從名稱推斷功能完整性。

工作區策略與衝突責任

多個子代理能不能同時修改同一個倉庫，答案是「技術上可能，流程上不應直接允許」。問題不只在 Git merge conflict，也包括產生檔、鎖定檔、測試資料庫、環境變數和暫存目錄被不同任務互相覆蓋。

你可以在以下三種策略中選擇：

1. 只讀共享：所有代理讀同一個固定版本，但只有一個代理可以寫入。適合調研、規格整理和測試規劃。
2. 獨立工作區：每項修改任務使用獨立分支或 worktree，主 Agent 負責逐一比較與合併。Git 官方的 git worktree 文件說明了同一個倉庫管理多個工作樹的基本方式。
3. 順序合併：先完成基礎修改，再讓後續代理針對已驗證版本工作。速度較慢，但最容易追蹤衝突來源與回退點。

多個子代理可以同時修改同一個倉庫嗎？
只有在每個代理的寫入範圍互不重疊、產生檔不共享、合併責任明確時才考慮。若兩項任務都會改同一個設定檔、依賴鎖定檔或資料庫遷移，應回退到獨立工作區或順序合併。不要把「並行數增加」當成效率指標；無法快速判斷衝突歸屬時，並行反而增加返工。

權限與狀態的實際核對

Job Panel 的任務可見性，與伺服器或 macOS 層級的操作權限是兩回事。你要分開核對四個範圍：

• 檔案：子代理能讀寫哪些目錄，是否能碰到其他專案或 SSH 金鑰。
• 命令：能否執行刪除、套件安裝、服務重啟或部署命令。
• 網路：是否可連出外部 API、套件來源或內部服務。
• 憑據：環境變數、金鑰鏈、設定檔和 CI/CD Secret 是否被繼承。

高風險操作至少保留一個人工接管點，例如部署、刪除資料、修改生產設定和使用具寫入權限的外部 API。即使面板能顯示任務狀態，也不要把「可見」誤認為「已隔離」。若你把這些任務接到 CI/CD，還應逐項核對工作流程到底可讀取或修改哪些資源，可參考 GitHub Actions 的權限設定文件。

狀態同樣需要實測。你應在隔離倉庫內依次測試建立、查看、取消、逾時、失敗、主程序退出和遠端連線中斷，記錄任務是否真的停止、是否留下部分檔案、是否能取得最後輸出。若官方文件沒有明確說明跨重啟行為，就只能標為「未確認」，不能寫成可恢復。

Job Panel 是否支援跨重啟繼續任務？
除非當前版本的官方文件或真實測試明確證明，否則不要假設支援。面板重開後仍看到一筆任務記錄，只能證明記錄存在，不能證明子代理程序、命令或網路連線仍在運作。平台團隊應把「程序是否存活」與「任務狀態是否可查」分成兩個監控項目。

子代理任務失敗後由誰恢復？
任務契約中要直接寫明責任：只讀調研失敗由主 Agent 重派；程式修改失敗由原修改代理先提供日誌；建置失敗由驗證代理保留現場，不得自行覆蓋修改；高風險操作失敗則交由人工值班者接管。沒有這個欄位，主 Agent 很容易重跑全部步驟，造成重複提交或二次破壞。

任務契約的條件式選擇

你可以把下面的條件列表直接放入團隊 runbook：

• 若任務只需讀取程式碼、整理規格或定位問題，選單一只讀子代理；否則回退到先調研、後修改的串行流程。
• 若只改一個模組，且可用獨立分支驗證，選受控修改代理；否則不要與其他寫入任務並行。
• 若任務需要建置或測試，但不需要更改程式碼，選獨立驗證代理；否則由主 Agent 決定是否重新開一項修復任務。
• 若兩項任務會寫入相同檔案、鎖定檔或產生資料，選順序合併；否則才考慮隔離並行。
• 若需要網路、憑據、部署或刪除操作，保留人工批准；若無法建立批准點，就不要交給自動子代理。
• 若失敗後無法提供 diff、命令、日誌與未完成項目，停止擴大並行，先修正交付格式。

主 Agent 接收結果時，至少要能回答三件事：改了什麼、如何證明、失敗時從哪裡回退。交付資料不足，就算任務標記為完成，也不應直接合併。

先用兩項低風險任務驗收

上線前不要一次拆解整個產品。先準備兩項互不相關的低風險任務：一項只讀調研，一項針對獨立檔案的受控修改。你要記錄任務標識、輸入版本、工作區、實際權限、狀態變化、取消結果、輸出檔和主 Agent 的接管步驟。

這個小型驗收能快速暴露三類問題：

• 面板能否區分任務記錄與實際程序狀態；
• 子代理是否真的遵守可寫範圍；
• 失敗後是否保留足夠證據，讓主 Agent 不必重跑全部流程。

如果團隊打算長期讓多個子代理並行執行，還要把遠端 Mac 的隔離方式、工作區容量、連線中斷處理和節點數量納入規劃。你可以先閱讀 DeepSeek Harness 多專案部署方向，再按實際任務量參考 Mac mini M4 價格與規劃指南。

當前做法若是所有代理共用一台開發機，通常會有三個真實缺點：檔案與分支邊界難以追蹤、權限容易過度繼承、遠端連線或主程序中斷後不易判斷現場。若你只需要短期測試、臨時算力或隔離的驗收環境，租用 MacDate 的獨立 Mac 節點會比把多個高風險任務塞進同一個工作區更容易管理；若是長期穩定重負載、必須接實體周邊，或已有固定本地基礎設施，直接自購 Mac 仍可能更合適。可先查看 MacDate 的裸機 macOS 方案，再按任務契約決定是否租用。