AIREITERFactory Automations 可以透過排程、Slack 頻道中的頂層訊息、GitHub 事件，或外部 HTTP 請求啟動 Droid 工作階段。Webhook 觸發目前仍屬 Private Preview；排程則採固定 UTC 時間，不會隨夏令時間自動調整。它適合進行範圍明確的試行，但還不是可以直接全面投入正式環境的萬用方案。
Factory Automations 實際上會執行什麼
每個自動化流程都由觸發條件、操作指示、執行身分與執行目標組成（Factory 文件）。
| 觸發方式 | 什麼情況會啟動 | 主要執行細節 |
|---|---|---|
| 排程 | 自然語言頻率或五欄位 cron | 在指定電腦或執行目標上執行；受管理電腦支援 10 個自動化流程，其中 5 個可設定為每分鐘執行 |
| Slack | 符合條件的頻道頂層訊息 | 在原始訊息的討論串中回覆 |
| GitHub | Pull request、留言、推送、標籤、檢查結果或排程 | 完成設定並合併後，在 GitHub Actions 中執行 |
| Webhook | 其他服務送出的 HTTP POST | Droid Computer 或執行範本；Private Preview |
自動化流程可以設為私人使用，也可以與組織共用。工作階段的隱私設定則是另一層控制，決定誰能開啟由這些執行結果建立的工作階段。
不同觸發方式，代表不同的維運模式
排程執行：最適合拿來起步
排程可以接受「every Monday at 9am PST」這類自然語言，也能使用 0 9 * * 1 這種 cron 表達式。Factory 會預覽實際執行時間，但 cron 採用 UTC。若輸入明確的時區，系統會將時間換算成固定的 UTC 排程，不會隨夏令時間自動調整（Factory 文件）。
適合一開始嘗試的工作，包括每日狀態摘要、依賴套件稽核、過期文件檢查，或只負責整理證據、不直接合併程式碼的 PR 審查員。
Slack 訊息：好用，但只處理頂層訊號
Slack 自動化會在可存取頻道中出現符合條件的頂層訊息時啟動。討論串中的回覆不會獨立觸發執行。篩選條件可以依頻道模式、寄件者類型、關鍵字、排除關鍵字或排除寄件者進一步限制。
執行結果會回覆在觸發訊息的討論串中。如果有多個自動化流程同時符合條件，只有第一個會在該討論串回覆，其餘流程則會發布獨立訊息，並附上原始訊息的連結。Factory 文件也說明了包括私人頻道存取規則在內的相關行為（Factory 文件）。這很適合用在受控的事故處理頻道，但不適合依賴每一則後續回覆的工作流程。
GitHub 事件：設定閘門清楚，完成後威力十足
自訂 GitHub 自動化可以監聽 Pull request、推送、留言、標籤變更、檢查完成或排程事件。它們會在 GitHub Actions 中執行，而建立流程時，Factory 會在每個選定的儲存庫開啟一個設定用 pull request。
這個設定用 pull request 必須先合併，自動化工作流程才會啟用。在工作流程進入預設分支之前啟動的執行都會失敗；在此之前，自動化也無法發布留言、推送提交或開啟 pull request。如果週期性工作本來就由儲存庫事件觸發，且正常的 pull-request 審查仍是交付前的最後一道關卡，GitHub 會是最有力的選擇。
Webhook：功能到位，但可用性仍有限
Factory 將 Webhook 自動化列為 Private Preview，並要求組織聯絡支援團隊才能啟用。Webhook 會由外部 HTTP POST 啟動工作，但不能在使用者的本機執行；它需要 Droid Computer 或執行範本。
Factory 會提供 Webhook URL、X-Webhook-Secret 標頭選項，以及讓無法設定標頭的發送端使用的 URL 格式。文件建議優先使用標頭，因為 URL 中的密鑰可能出現在記錄檔裡；密鑰只會顯示一次，而輪換密鑰後，舊值就會失效（Factory Webhook 文件）。
同一份文件列出 200 KiB 的請求本文上限、每分鐘接受 60 個請求、保存 30 天的傳遞記錄、相同本文 10 分鐘內的去重視窗，以及每小時最多執行 10 次的限制。這些控制讓 Webhook 足以用來測試警報回應，但只要正式環境需要穩定且可預期的存取，Private Preview 狀態就仍是阻礙。
決定自動化是否安全的控制項
排程、Slack 與 Webhook 自動化可以使用目前使用者身分，或共用服務帳戶執行。執行身分會影響連接器存取權、計費與 Slack 顯示的身分；執行目標規則則詳列於 Factory 文件。
讓操作指示保持精準，使用可以撤銷的憑證，選擇專用執行目標，並把部署與合併權限留在現有的儲存庫控制機制中。Factory 在 Slack Marketplace 上的頁面也明確提醒，這個應用程式可能出錯，使用者應再次確認程式碼與回應。
有使用者指出幾項監督上的缺口，包括沒有 Linux 桌面應用程式，也沒有跨電腦同步功能（@JoelDeTeves 在 X 的貼文）；如果團隊預期能離開桌面環境後，仍然監督長時間執行的自動化工作，這些限制就值得納入考量。
Factory Automations 與簡單 GitHub Action 的差異
| 需求 | Factory Automations | 簡單 GitHub Action |
|---|---|---|
| 對儲存庫執行一段操作指示 | 原生 Droid 工作階段與執行目標 | 團隊自行提供代理程式執行環境與工作流程程式碼 |
| 排程工作 | 自然語言或 cron，但有 UTC 限制 | GitHub cron 與自訂邏輯 |
| Slack 觸發 | 支援篩選與討論串回覆的頂層訊息 | 自行處理 Slack 應用程式或 Webhook 串接 |
| GitHub 事件 | 引導式設定 PR 與 GitHub Actions 執行 | 直接撰寫工作流程檔案 |
| Webhook | 內建，但屬於 Private Preview | 自行建立端點、驗證、重試機制與工作程序 |
| 審查界線 | 可以先準備工作，交由人工審查 | 取決於工作流程權限 |
如果工作只是確定性高的 API 串接，例如每日產生 PR 摘要，使用 GitHub Action 就好。若週期性工作需要調查、掌握儲存庫脈絡、提出程式碼變更，或產出人類易讀的工作階段，才適合選擇 Factory。不要只是為了省下幾行短程式，就改用代理程式平台。
讓自動化逐步取得更多權限的低風險試行方案
- 選擇一項輸入範圍明確的週期性工作，例如審查新 pull request 或檢查產生的檔案。
- 先從排程自動化開始，不要一開始就用 Webhook；這樣可以避開預覽功能的存取限制，也更容易檢查執行頻率。
- 讓輸出結果成為報告或 pull request，而不是部署或合併。
- 記錄失敗的執行、被阻擋的工作、變更過的檔案，以及人工修正內容；只有已接受的 pull request，還不足以作為判斷依據。
- 一次只擴大一個維度：另一種工作類型、另一個儲存庫，或另一種觸發方式。
Factory 的工作流程指南建議，先重現原始失敗，再於乾淨環境測試修正，最後檢查相鄰案例，確認無誤後才保留成可重複使用的指示。這也應該成為 Automation 試行時採用的標準。
常見問題
Factory Automations 支援 Webhook 嗎？
支援，但 Webhook 觸發目前屬於 Private Preview，可能需要組織層級的啟用權限。執行時需要 Droid Computer 或執行範本。詳情請參閱上方的 Webhook 章節。
Slack 討論串中的回覆會觸發自動化嗎？
不會。只有符合條件的頂層訊息會啟動執行；請參閱 Slack 訊息。
排程會跟著夏令時間調整嗎？
不會。Factory 儲存的是固定的 UTC 排程；當所在地的夏令時間規則變更時，請重新檢查排程。請參閱排程執行。
GitHub 自動化會在設定用 pull request 合併前執行嗎？
不會。設定用 pull request 必須先進入預設分支；更早啟動的執行會失敗。請參閱GitHub 事件。
Webhook 傳遞重複時會怎樣？
如果 10 分鐘內收到相同本文，系統會將其記錄為 Deduped，不會再次啟動執行。Factory 也會記錄被篩除、達到速率上限、略過及失敗的傳遞。
別忘了它的取捨
如果輸出可以留在 pull-request 審查流程內，就可以優先試行排程或 GitHub 觸發的工作。Slack 在團隊採用頂層訊息規範時相當實用；Webhook 雖然已具備足夠細節可供測試，但由於仍是 Private Preview，現階段不應成為正式事故處理系統的基礎。