Factory Delegations 正式開放：從 Slack、Linear 派工作給 Droid，權限與審查怎麼設？

團隊在 Slack 發現問題，卻得換工具、找程式庫、重講背景，才能讓 AI 動手。Factory Delegations 想把這段交接留在原本的對話與工作單裡。

台灣時間 2026 年 10 月 17 日，官方宣布功能正式開放。團隊能在支援的入口提及 Factory，或把工作單交給它，讓 Droid 到遠端電腦調查、修改並測試。

Droid 是 Factory 的程式代理，能依任務使用模型與工具。但執行時用誰的帳號、能碰哪些程式庫，仍由組織設定決定。

這個差別會影響導入方式。Slack 私訊使用發訊者的個人身份，共享頻道與工作單則使用服務帳號，也就是專供自動化執行的組織身份。

對已經使用這項工具的團隊，我會先挑一個小型維修工作試行，把驗證方法與人工審查要求寫好，再逐步擴大入口。

Factory Delegations 能從哪些工具接工作？

Delegations 把派工入口放進團隊原本使用的工具，讓人不必每次先打開程式代理。官方公告 描述的重點，就是從既有工作工具交出任務。

但入口名稱出現在文件中，不代表每一個都已全面開放。2026 年 10 月 18 日查詢官方完整文件時，Microsoft Teams 仍標示開發中。

以下整理文件列出的方式。若組織的設定按鈕不能使用，也要先核對該入口是否已對你的組織開放。

表格裡的差異，會決定任務從哪裡進來。可是任務開始後，用什麼身份讀程式、改檔案與連接其他服務，還需要另一層設定。

因此，導入時先選一個團隊最常用的入口即可。能完成一次清楚交接，比同時打開所有工具更容易看出設定是否正確。

個人私訊和共享派工，使用誰的權限？

Slack 私訊跟隨個人身份，共享頻道與工作單則跟隨組織服務帳號。因為兩者的憑證來源不同，同一句任務在不同入口可能有不同存取範圍。

私訊使用個人的 Git 與工具連線

Slack 文件 說明，私訊中的工作使用傳訊者的個人身份與連接器。Git 是管理程式版本的工具，相關憑證決定代理能讀取或推送哪些程式庫。

連接器則提供執行任務需要的外部工具。例如需要讀取某個工作系統，代理得先有那個系統的連線，不能因為你能在 Slack 找到它，就自動取得所有服務權限。

不過，私訊仍會使用組織 Apps 配置的環境、指示與預設模型。身份跟隨個人，不等於整個執行方式都由個人重新設定。

共享工作使用服務帳號

頻道與工作單中的共享派工，使用配置指定的服務帳號。它有自己的 Git 憑證、連接器及可用電腦，所以不會自動沿用發起人的私人連線。

這讓團隊能集中管理共享工作，但也要求管理者知道服務帳號究竟能碰什麼。若它沒有專案權限，任務就可能開始後才發現找不到程式庫。

反過來說，服務帳號權限太廣，也不能靠發起人的個人設定自然縮小。因為執行身份不同，團隊應在這個帳號上安排需要的範圍。

身份確認後，也可以安排個人的派工預設。文件允許成員加入自己的指示，在組織政策允許時選擇模型，但這些指示是接在共同要求後面，不會取代組織規則。

例如團隊固定要求交回測試，個人可以再補充摘要格式。因為共同要求仍在，審查者不用擔心每位成員都把交付標準改成不同版本。

身份與行為規則對上後，還要有地方執行程式。這也是 Delegations 要求管理員先準備運算環境的原因。

管理員要先準備什麼？

付費方案、管理角色、應用程式授權，以及執行身份與環境，都要先到位。因為 Delegations 處理的是組織工作入口，並不是個人登入一個工具就完成整組設定。

依官方文件，設定者需要 Factory 的 Manager 或 Owner 角色，也需要在外部工作區安裝或授權應用程式的權限。團隊成員派工時，也得有對應組織的帳號。

帳號識別要能對上。文件要求 Factory 與連接應用的帳號電子郵件一致，讓系統知道是誰送出任務。這是成員自行核對的設定條件，不需要把帳號資料貼到公開討論串。

先看預設配置，再決定要改什麼

設定入口在 Settings → Delegations。管理員可以連接派工應用，並在 Apps 配置裡檢查模型、共同指示、外掛、身份與運算方式。

符合條件的組織會收到預設配置、服務帳號與環境，但預設值仍應被檢查。因為它能建立一個入口，不代表已經知道你的專案要跑哪些測試。

共同指示適合寫團隊固定要求，例如修改後交出測試結果、說明受影響檔案，或在哪些情況建立合併提案。把要求寫在共同配置裡，才能讓後續派工維持一致。

Apps 配置也不是只對一個 Slack 頻道生效。官方文件說它由派工應用共用，所以調整共同模型或指示時，應先知道其他入口是否也使用同一份配置。

例如一個頻道只想增加摘要格式，若直接改共同指示，其他工作單入口也可能跟著收到要求。這時把任務特有的格式放在當次派工裡，會比修改整個組織配置容易控制。

這種分層的目的，是讓固定要求保持一致，同時讓不同任務保留需要的背景。團隊第一次導入時，可以先記錄哪一層管理什麼，之後遇到結果不同就較容易追查。

動態與持續電腦，各有前置條件

Dynamic 會從指定 Environment 準備執行環境，Persistent 則使用服務帳號池裡的電腦。Environment 可以理解成一組準備電腦的設定，讓任務開始時取得需要的工具與專案條件。

動態方式需要選好環境，持續方式則需要帳號池裡有可用電腦。若任務排不到機器，應先檢查這一層，避免反覆重新登入外部應用。

這與自行部署代理沙盒有不同重點。Delegations 關注如何交出任務，自架環境則處理工作實際在哪裡跑，兩者要一起配合。

延伸閱讀：Factory OpenCompute 開放私人預覽：代理沙盒放進自家雲端，哪些資料仍要確認？

從 Slack 或 Linear 交出第一個任務，怎麼寫才清楚？

程式庫、預期結果與驗證方法，要隨任務一起交出。因為同一個頻道可能談過很多專案，代理需要知道這次到底要改哪裡。

從能驗證的小問題開始

與其只寫「修一下登入」，可以說明在哪個頁面、哪種操作失敗，以及成功後應該看到什麼結果。如果已經有錯誤訊息，也只附與這件事相關的部分。

以下是本文建議的任務寫法，方便團隊依自己的專案調整。

請調查會員網站在密碼錯誤時沒有顯示提示的問題。只處理登入頁與相關測試，確認正確密碼仍能登入、錯誤密碼能看到說明，再建立修改提案，交回測試結果。

這段任務把範圍與證據放在一起，因此代理比較容易知道什麼時候可以停止。若還需要產品決策，也應先把決策交給負責人，而不是讓代理猜畫面應該如何呈現。

在原本的對話或工作單跟進

Slack 可以使用提及所在討論串作為背景，也能回傳進度與結果。若用 Linear，則可在工作單描述寫清楚條件，再指派給代理或在留言提及它。

後續補充也盡量留在同一件任務裡。因為背景能接在一起，團隊比較容易知道哪些要求是後來新增、哪些結果已經確認。

但進度通知只是告訴你工作到了哪裡。收到「測試完成」後，仍應打開結果看它測了什麼，尤其是修改是否只涵蓋原本授權範圍。

工作連結的呈現與身份有關

官方 Slack 文件特別區分，個人私訊中的工作會附工作階段連結，共享頻道服務帳號工作則不以相同方式附連結。不能只因為沒有連結，就判定工作沒有執行。

這個差異也提醒管理員，第一次試行要確認團隊如何取得必要證據。若審查者看不到變更與測試，派工方便仍不足以完成交接。

如何追蹤結果並要求獨立審查？

先檢查測試與程式差異，再看核准是否真的由另一個人完成。程式差異是修改前後的比較，能讓審查者確認代理究竟改了什麼。

PR 是準備合併修改的提案，通常也放入檢查狀態與討論。若代理只交回一份摘要，審查者仍需要能對照實際修改，才能做決定。

機器人當作者，會改變核准關係

官方文件指出，共享派工若用 Factory Droid GitHub App 開 PR，作者會是 Factory，而不是發出任務的同事。GitHub 不允許作者核准自己的 PR，但發起人仍可能核准機器人開出的提案。

因此，只要求一份核准時，任務發起人可能自己滿足條件。若團隊的目的是一定要有另一位同事審查，必須另外把這件事寫進規則。

文件提出的方式包含，對所有 PR 要求兩位人工核准，或用必要狀態檢查，針對該機器人開出的提案要求兩位人類核准。

狀態檢查是合併前必須通過的檢查結果。因為它可以依提案作者套用條件，就能把「找另一位人審」從口頭習慣變成可執行的門檻。

驗收要能回答原本的問題

若任務是修登入提示，審查者要能核對錯誤密碼的結果，也要確認正常登入沒有被改壞。測試綠燈與產品行為應該能互相對照。

如果代理修了其他順手發現的問題，先看那些修改是否必要。任務越能維持清楚範圍，審查時間也越容易控制，之後要撤回時比較不會牽動無關功能。

延伸閱讀：AI 程式驗收教學：人工審查、測試與逐步上線，各自能抓到哪些錯誤

Delegations 與 Connectors 差在哪裡？

Delegations 接收任務，Connectors 提供執行任務需要的工具。因為兩者都可能需要登入授權，很容易被當成同一個設定。

例如，個人先連接 Slack 工具，代表代理能在相關身份下使用支援的 Slack 功能。這不會自動把派工應用裝到整個組織工作區。

反過來說，頻道能找到這個代理，也不代表服務帳號已經連上任務需要的所有外部系統。當工作卡住時，要先分清是入口沒有接到，還是進來後缺執行工具。

因此排錯可以從任務是否建立開始，再看身份、程式庫、工具與電腦。依照這個順序，比每次都重裝應用更容易保留問題線索。

常見問題 FAQ：Factory Delegations 導入前還要看什麼？

免費帳號也能設定嗎？

官方前置條件列的是付費組織，包含個人與組織方案。

具體可用項目仍要對照自己的方案與管理權限。

Teams 已經可以和 Slack 一樣使用嗎？

2026 年 10 月 18 日查詢時，文件仍把 Teams 標示為開發中。

因此導入計畫應先核對開通狀態，不要只依入口名稱安排正式工作。

改個人模型設定，會改成用我的個人權限嗎？

個人預設可以在政策允許時影響模型與指示，並不改變共享工作的服務帳號身份。

所以模型選擇與資料存取要分別檢查。

先把第一件任務交接清楚

Factory Delegations 適合已經有組織設定、希望把維修工作留在協作入口的團隊。先挑一個小問題，確認身份、執行與審查都能接起來，再擴大使用。

如果團隊還不確定服務帳號能做什麼，先整理權限與驗證方法。因為代理收到任務的速度變快，後面的交接標準也要足夠清楚，才能減少來回。

可以把下一次日常修正當成試行，要求代理交回對應的測試與修改提案。歡迎免費訂閱 AI 郵報，追蹤代理工具更新與能直接借用的工作方法。

資料來源

• Factory：Delegations 正式開放公告。
• Factory Delegations 完整文件。
• Factory Slack 派工設定。
• Factory Linear 派工設定。