跳至主要内容
版本：1.0.0

Agent 角色與協作

Main Agent 與 Sub-Agent 的分工​

角色負責什麼
Main Agent負責調度，辨識要執行的 Task 並派給對應的 Agent
Sub-Agent執行工作；各自擁有 workspace（工作目錄）、Skills 與模型

一台設備有一個 Main Agent，最多可建立十個 Sub-Agent。你匯入的 Agent 套件會成為設備上的 Sub-Agent。

每個 Agent 可以使用不同模型。在 Agent Management → Model 設定，變更會套用到下一張 Task 或下一個 Session；執行中的 Session 不會中途換模型。

查看：變更 Agent 的模型

變更 Agent 的模型

Agent 如何交接工作​

Sub-Agent 之間不會互相呼叫，也不會自動接續下一張 Task。 每張 Task 只屬於一個 Agent；要讓多個角色協作，需由使用者依序執行 Task，透過檔案交接結果：

  1. 在 Dashboard 按 START，執行前一個 Agent 的 Task。
  2. 確認執行成功，在 Task Run 的 Outputs 下載結果。
  3. 把下一個 Task 需要的結果檔打包成 ZIP，建立 Task 時上傳到 Material ZIP，並選擇下一個 Agent。
  4. 確認下一張 Task 的指令會讀取 materials/ 裡的輸入檔，再按 START。

例如，分析 Agent 產出 defect-analysis.md，使用者下載並打包後，交給 SOP 查詢 Agent 作為輸入。這是使用者操作的交接流程；下方流程圖也遵循這個方式。

每次執行都有自己的 Log、Session 與 Audit 紀錄，方便查看每個角色的結果與失敗原因。建立 Task 需要 Administrator；Administrator 或被指派到該 Agent 的 User 可以按 START。

執行限制​

項目限制
每台設備的 Sub-Agent最多 10 個，不含 Main Agent
同時執行 Task 的 Agent最多 5 個；第六個 Agent 的 Task 會被拒絕，不會排隊
每個 Agent 同時執行的 Task1 張；忙碌中的 Agent 不接新的

什麼時候需要拆成多個 Agent​

當不同步驟的目標、資料來源、Skill、領域知識、輸出格式或權限需求有明顯差異時，再考慮拆分。讓每個角色有清楚的責任與產出，會更容易個別測試、覆核與維護。

以下以 AOI（自動光學檢測）異常覆核為例。角色名稱是範例，不是平台內建的 Agent：

角色責任Skill 範例
Evidence Analyst（證據分析）分析檢測結果與佐證資料AOI 結果查詢、影像處理、缺陷歷史
Procedure Specialist（作業程序查詢）查出適用的 SOP 或排錯指南文件搜尋、知識庫
Planner（建議整理）整理建議的下一步脈絡彙整、分析結果
Coordinator（結果彙整）組出送審用的最終結果報告撰寫
AOI 偵測到異常
        ↓
證據分析 Agent → defect-analysis.md
        ↓ 使用者下載結果，作為下一張 Task 的 Material ZIP
作業程序查詢 Agent → sop-match.md
        ↓ 使用者交接所需結果檔並啟動下一張 Task
建議整理 Agent → recommended-steps.md
        ↓ 使用者交接所需結果檔並啟動下一張 Task
結果彙整 Agent → review-packet.md
        ↓
品質工程師覆核並決定下一步

設計原則​

單一責任​

每個 Sub-Agent 只做一件定義清楚的事。Evidence Analyst 負責分析證據，不會同時負責核准、通知、修改設備參數。責任範圍窄，才測得動。

最小 Skill 集合​

只給 Sub-Agent 它的工作真正需要的 Skill。每個 Skill 都列在該 Agent 的 TOOLS.md 裡，而一張 Task 只叫得動自己 Agent 已安裝的 Skill——所以套件本身就是權限邊界。負責查 SOP 的 Agent，沒有理由帶著控制設備的 Skill。

明確的輸入與輸出​

角色之間傳遞結構化的檔案，而不是大量對話脈絡：

缺陷類型
可能原因
佐證
信心程度
建議的下一步

把每個檔案宣告在 Expected Outputs，平台會在 Task 能夠完成之前確認它確實存在。

可預期的失敗處理​

每個 Step 自己宣告失敗時怎麼辦。暫時性失敗用 retry；繼續下去會產生誤導結果的地方用 on failure: stop。用 exit code 回報失敗——絕對不要在沒產生檔案的情況下印出成功訊息，因為平台檢查的是檔案，不是訊息。

彙整，但不要把全部集中​

負責彙整的 Agent 組裝結果、處理缺漏。它應該維持彙整者的角色，而不是慢慢累積成設備上權限最大的那一個。

協作時的共同規則​

  • 各自使用自己的 Skill 與 workspace。 透過上傳輸入檔交接，不以其他 Agent 的身分執行，也不直接讀寫其他 Agent 的檔案或平台私有路徑。
  • 保留人工核准與安全控制。 Prompt 不得要求忽略政策、隱藏行為或繞過核准。
  • 結果與紀錄不含機密。 stdout、Log、Session 與 Outputs 都不應出現密碼、token 或私鑰。

套件格式與 Task 指令，請見建立第一個 Agent。

常見陷阱​

  • 給每個 Agent 同樣一大包 Skill，讓角色失去分工。
  • 把多件不相關的工作放進同一個 Agent。
  • 沒有約定交接檔案的格式、必填內容與失敗處理。
  • 把所有 Skill 與權限集中到負責彙整的 Agent。
  • 還沒個別驗證每個 Agent，就先串接整條流程。

相關文件​