AIREITERFactory Automations 可以通过定时任务、Slack 顶层消息、GitHub 事件或入站 HTTP 请求启动 Droid 会话。不过，Webhook 触发器目前仍处于 Private Preview；定时任务使用固定的 UTC 时间，也不会随着夏令时自动调整。它适合进行范围明确的试点，但还不适合不加限制地直接投入生产。
Factory Automations 到底能运行什么
每条自动化都由触发器、执行指令、身份和执行目标组成（Factory documentation）。
| 触发方式 | 什么会启动运行 | 主要执行细节 |
|---|---|---|
| 定时任务 | 自然语言频率或五字段 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 documentation）。
适合优先尝试的任务包括：每天生成状态摘要、审计依赖项、检查过期文档，或者让 PR 审查机器人先整理证据，而不是直接合并代码。
Slack 消息：有用，但只响应顶层消息
当可访问频道中出现符合条件的顶层消息时，Slack 自动化就会启动。线程中的回复不会单独触发运行。你可以按频道匹配模式、发送者类型、关键词、排除关键词或排除发送者来筛选消息。
运行结果会回复在触发消息所在的线程中。如果有多条自动化同时匹配，只有第一条会在该线程里回复，其余自动化会分别发送消息，并附上指向原始消息的链接。Factory 在文档中也说明了包括私有频道访问规则在内的这些行为（Factory documentation）。这很适合管理规范明确的故障响应频道，但不适合依赖每一条后续回复的工作流。
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 documentation）。
同一份文档还规定了 200 KiB 的请求体上限、每分钟接受 60 个请求、保留 30 天的投递记录、相同请求体 10 分钟内的去重窗口，以及每小时最多运行 10 次的限制。这些控制项足以让 Webhook 用于测试告警响应，但如果生产系统要求稳定、可预期的接入，Private Preview 状态仍然是一个阻断因素。
决定自动化是否安全的控制项
定时任务、Slack 和 Webhook 自动化都可以选择以当前用户身份或共享服务账号运行。身份会影响连接器访问权限、计费归属和 Slack 中显示的发送者；执行目标相关规则见 Factory documentation。
保持提示词范围明确，使用可以随时撤销的凭据，选择专用执行目标，并继续把部署和合并权限交给现有的仓库控制机制。Factory 在其 Slack Marketplace listing 中也明确提醒，应用可能出错，用户应再次核对代码和响应内容。
一位用户提到了一些监督方面的缺口，包括没有 Linux 桌面应用，也没有跨计算机同步（post by @JoelDeTeves on 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 的 workflow guidance 建议先复现原始故障，再在干净环境中测试修正方案，并检查一个相邻案例，之后才保留可复用的指令。这也是评估 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，不应作为生产级故障响应系统的基础。