D5「協調多代理協作」10 題原創模擬題，附正確答案、解析與常見陷阱。選項順序在互動版會隨機排列。
你要指派三個 cloud agent 任務：甲改 API 路由，乙為甲新增的路由補測試，丙改 README。要避免衝突，又要保留能平行的部分。哪些安排正確？
複選題，選項：
正確答案：讓丙與甲同時開始各自執行；讓乙等甲的 PR 合併後再開始
解析：D5-O1 要求為平行執行設定隔離，並安排彼此相依的工作。丙只改 README，和甲沒有重疊，可以同時執行；乙要測試甲新增的路由，必須等甲的變更合併後才有東西可測，應該排在甲之後。三個任務全部依序執行雖然安全，卻白白放棄了甲與丙的平行度；乙與甲同時開始，乙會對著還不存在的路由寫測試。
常見陷阱：「全部依序」看起來最保險，但題幹要求保留能平行的部分。先找出真正的相依關係，再決定哪些要排隊。
依據：Exam GH-600 Study Guide、Risks and mitigations for GitHub Copilot cloud agent
多代理流程要能在事後稽核，但 PR 描述有長度限制，團隊只想寫入還原決策與分析失敗所需的最少內容，其餘留在各自的 session log。哪些應寫進 PR 描述？
複選題，選項：
正確答案：每次交接時傳遞的輸入與假設；關鍵決策以及做出決策的理由；失敗或只部分完成的代理結果
解析：D5-O2 要求記錄代理之間的關鍵決策、交接與結果，讓事後能還原誰在什麼依據下做了什麼。交接的輸入與假設、關鍵決策與理由、失敗或部分完成的結果，都是還原決策的必要內容；失敗紀錄尤其是事後分析最需要的證據。每次工具呼叫的完整輸出已經在 session log 中，題幹也要求其餘內容留在那裡，不必重複寫入 PR。
常見陷阱：失敗的結果不是雜訊。只記錄成功的部分，事後就無法分析哪裡出了問題。
依據：Exam GH-600 Study Guide、Troubleshooting GitHub Copilot cloud agent
在 custom agent 的 profile 設定 user-invocable: false 後，Copilot 不會再依任務自動選用它，但使用者仍可手動選擇。
是非題：判斷敘述是否正確。
正確答案：錯誤
解析：這句描述的是 disable-model-invocation: true：停止 Copilot 依任務內容自動選用，改為只能手動選擇。user-invocable: false 的效果相反，使用者無法再手動選擇這個 agent，只能以程式方式存取。兩者可以組合使用，逐步停用代理，同時保留 profile 與 Git 歷史供稽核。
常見陷阱：兩個欄位名稱相近、方向不同：disable-model-invocation 關掉自動選用，user-invocable 關掉手動選擇。
兩個代理的 PR 改到同一個檔案，但改的是不同函式；兩邊的意圖不衝突，測試也都通過。最合適的處理是什麼？
單選題，選項：
正確答案：先合併其中一個，另一個 rebase 後重跑測試
解析：D5-O1 要求偵測並化解重疊的修改，處置強度要看重疊的性質。兩個 PR 改的是不同函式、意圖不衝突，只是同一個檔案，依序合併並在 rebase 後重跑測試即可。若兩邊改到同一段程式碼或意圖矛盾，才需要暫停並指定整合者；關閉重做會浪費已通過測試的成果；再加入第三個代理只會多一個衝突來源。
常見陷阱：指定整合者是處理意圖衝突的做法。題幹已排除意圖衝突，套用最重的流程只會拖慢交付。
多代理流程中，某個代理的 session 已經很久沒有新的 commit 或 log 輸出。它最可能處於什麼狀態？
單選題，選項：
正確答案：停滯（stalled）
解析：D5-O3 要求辨識失敗、部分完成與停滯的執行。長時間沒有進度、也沒有結束訊號，就是停滯；部分完成是產出一部分結果後就結束；已完成有明確的結束與產物；退役則是生命週期上的主動移除。停滯需要逾時與監控才能發現，發現後應決定重試、重新指派或交給人處理。
常見陷阱：停滯的代理不會報錯，所以容易被當成「還在跑」，要靠時間門檻判斷。
五個代理平行修改五個互不相依的模組：三個成功並通過驗證，兩個因暫時性的網路錯誤中斷。最合理的恢復方式是什麼？
單選題，選項：
正確答案：保留三個成功的產物，只重跑中斷的兩個
解析：D5-O3 要求為多代理失敗設計恢復模式。五個模組互不相依，成功的三個已通過驗證，不受另外兩個影響，可以保留；中斷原因是暫時性網路錯誤，直接重跑那兩個即可。全部重跑浪費已完成的工作；改由人手動完成，對暫時性錯誤而言是過度反應；模組互不相依，也不必等查明原因才合併成功的部分。
常見陷阱：如果模組彼此相依，或失敗原因來自共同的錯誤前提，答案就會不同。恢復方式要依題幹給的相依性與失敗原因決定。
你讓多個專家代理分別檢查安全、效能與可讀性，最後由一個角色整合結論。這是哪一種協調模式？
單選題，選項：
正確答案：主管／工作者（orchestrator）
解析：由一個主管（orchestrator）分派工作給多個專長不同的工作者，再整合結果，就是主管／工作者模式；custom agent 可以透過 agent 工具別名委派其他 custom agent 執行任務。管線式是前一個的輸出成為下一個的輸入，沒有平行分析；不整合的平行執行少了最後的綜合；共同編輯同一份檔案則沒有協調機制。
常見陷阱：管線式也是多代理，但它是依序傳遞，不是平行分析後再整合。
某個多代理流程的費用超出預算兩倍，你要找出是哪個代理造成的。最直接的資料是什麼？
單選題，選項：
正確答案：每個代理各自的 token 與執行用量
解析：D5-O2 要求用營運訊號分析多代理流程。題幹問的是費用來自哪個代理，最直接的訊號是每個代理各自的 token 與執行用量。交接紀錄與時間軸適合分析延遲與卡點，不能直接換算成本；最終 PR 只呈現結果；提示詞只能推測行為，無法顯示實際用量。
常見陷阱：交接紀錄與時間軸是事後分析最常用的資料，但要先看題幹問的是哪一種問題：延遲看時間軸，成本看用量。
你要讓某個 custom agent 暫時不被 Copilot 自動選用，但使用者仍可在需要時手動選它，而且要保留 profile 與歷史。應該怎麼設定？
單選題，選項：
正確答案：設定 disable-model-invocation: true
解析：disable-model-invocation: true 讓 Copilot 不再依任務內容自動選用這個 agent，但使用者仍可手動選擇，profile 與 Git 歷史都保留。user-invocable: false 會讓使用者無法手動選擇；tools: [] 只會停用這個 agent 的所有工具，不會改變它能否被選用；刪除 profile 則無法再手動選用。
常見陷阱：D5-O4 的退役是分階段的：先停自動選用、再停手動選擇，最後才考慮刪除。每一步都保留在 Git 歷史中。
代理甲與代理乙對某個函式有沒有 race condition 給出相反的結論：乙附上可重現的失敗測試，甲只有閱讀程式碼後的推論。整合者應該怎麼做？
單選題，選項：
正確答案：採用乙的結論，並記錄採用的依據
解析：D5-O3 要求依證據化解代理之間的矛盾。乙的可重現失敗測試直接證明 race condition 存在；甲的推論再完整，也推翻不了一個能重現的失敗。把矛盾原樣寫進報告等於沒有整合；投票可能讓共用錯誤前提的代理形成多數，票數取代不了證據。
常見陷阱：甲、乙的順序不代表誰先誰後或誰比較可信。依據是題幹描述的證據，不是選項的位置。