自动化是附加到 工作流 上的触发器。工作流说明 做什么；自动化说明 何时 开始另一次运行。
自动化使用：
- 一个工作流，使用其当前流程
- 一个所有者，使用该所有者的自动化聊天和已连接的访问权限
- 一个触发器，例如计划、来自已连接服务的事件，或传入的 webhook
每次运行的内容
每次触发都会在该工作流和所有者的自动化聊天中启动一次新的 运行。它不会在每次触发时都创建一个全新的聊天。由同一成员为同一工作流拥有的自动化会复用该自动化聊天。
这次运行使用工作流的当前指令和触发器载荷。由于聊天会被复用，较早的运行会保留在其线程历史中。如果某项任务必须无状态地执行，请在工作流指令中明确说明，并告诉它只使用当前事件或显式时间窗口。
模型是在自动化聊天线程上选择的，而不是在代理或工作流上。自动化聊天首次创建时，其模型先从成员默认值开始，然后再到工作区默认值。后续触发会复用为该线程选择的模型。
打开自动化聊天可检查其运行、输出和可见错误。失败的触发仍会显示在那里，因此你可以修正工作流、连接器访问或触发器，然后再次运行。
触发器参考
工作流上的自动化选择器是当前工作区可创建内容的事实来源。某些事件类型通过工作区功能开关发布，因此可能不会处处可见。
计划
| 类型 | 行为 |
|---|---|
| Scheduled | 使用 cron 日程和 IANA 时区在墙钟时间运行。 |
| Interval | 在一次运行完成后等待配置的间隔，然后安排下一次运行。运行彼此不会重叠。 |
| Once | 在所选日期和时间运行，然后自行禁用。 |
保存前请确认自动化中显示的时区。对于墙钟时间安排使用计划自动化；对于完成后间隔很重要的轮询使用间隔自动化。
Gmail
| 事件 | 筛选条件 |
|---|---|
| New message | 可选的 From、To、Cc、Subject 和正文文本匹配器。若没有匹配器，则每一条新消息都符合条件。 |
| Label applied | 一个 Gmail 标签名称。 |
先从较严格的新消息筛选条件开始，这样繁忙的收件箱就不会产生意外数量的运行。
GitHub
GitHub 事件要求先在你的 GitHub 组织中安装 Okou 的 GitHub App。如果尚未安装，自动化设置屏幕会直接提示——组织管理员会在那儿看到 Install GitHub App 按钮，而其他人会被告知去找管理员。只需安装一次，下面的每一种 GitHub 触发器就都可用了。
| 事件 | 常见筛选条件 |
|---|---|
| 拉取请求 | 一个仓库和一个操作：打开、重新打开、关闭、准备好接受审查、转换为草稿、同步、添加到合并队列或从合并队列中移除、添加标签或移除标签。可按基础分支、作者、PR 编号或标签进一步筛选。对于 closed，你可以区分“已合并”和“未合并即关闭”。 |
| 工作流运行完成 | 仓库、工作流、结论、分支、触发事件和执行者。 |
| 工作流作业完成 | 仓库、工作流、作业、结论、分支、运行器标签和运行器组。 |
| 拉取请求审查已提交 | 仓库、审查状态、基础分支、头部分支和受信任作者。 |
| 部署状态已创建 | 仓库、环境、状态、引用、创建者、应用和生产环境标志。 |
| Issue 或拉取请求评论已创建 | 仓库、Issue/PR 范围、受信任作者和评论前缀。 |
没有单独的 GitHub label applied 事件。要响应 PR 标签，请选择 Pull request，选择 Labeled 动作，并添加标签筛选条件。
Google Calendar 和 Meet
- Calendar event created、updated 或 cancelled，范围限定为你选择的日历 ID
- Google Meet transcript generated，针对由已连接成员组织的会议
Chat 和其他集成
- Chat run finished 会监视你的某个聊天线程。它可以按已完成、失败或已取消状态筛选；对于已完成的运行，还可以使用不区分大小写的
*通配符匹配最终回复。 - Webhook received 会创建一个已签名的传入 URL，并在工作区计划包含 webhook 自动化时可用。
- Google Forms response submitted、Notion page/database events、Strapi entry published 和 Stripe invoice paid 只会出现在启用了这些自动化功能的工作区中。
事件自动化还要求相关连接器或集成已连接，并且对自动化所有者可用。
自动化消息会用自然语言描述发生了什么，而由 chat run finished 触发启动的运行会指回原始线程。
创建自动化
从一个可用的聊天开始。 先把任务作为一次性操作运行。等它产生了你想要的结果后，说：
“在洛杉矶时间每个工作日上午 8 点运行这个，并通过私信把结果发给我。”
Okou 会确认工作流、频率和目标位置，若工作流尚不存在则会保存它，并附加该自动化。
显式创建。 在工作区中打开一个工作流，点击 Add automation，然后选择触发器类型及其筛选条件。适合你事先知道形态且不想先做试运行时使用。
流程来自工作流。在 My Okou 中，运行会使用自动化所有者在该工作区中的个人指令（Instructions）、记忆、已连接账户和权限。在 Legacy Agents 中，由拥有的智能体提供智能体上下文。计划触发器会询问何时运行以及使用哪个时区。
公开工作流共享的是方法，而不是其创建者的自动化或访问权限。每位成员都会创建并管理自己的自动化。不要假定复制工作流会转移另一位成员的触发器、凭据或自动化聊天。
Automations 可以单独 启用和禁用，而无需删除它们——在度假前，或在你调试嘈杂的触发器时，这都是正确的做法。
目标位置
自动化需要知道结果要去哪里。在工作流指令中说明它：
- Slack 频道或 DM — 最常见；以消息或线程形式进入频道
- Feishu 或 Microsoft Teams — 对于使用这些工具的团队来说，做法相同
- Telegram 或短信 — 适用于个人的、移动优先的提醒
- Notion 页面或数据库 — 适合需要归档而不是广播的内容
- Google Doc 或 Sheet — 追加或覆盖
- GitHub issue 或 PR 评论 — 用于工程工作流
- Gmail 草稿 — 在你的账户中预先准备好，供你审核并发送
- 托管页面 — 参见 托管站点
- 工作区文件 — 当产物是视频、图像或可下载资源时
"Post to #engineering" 或 "DM me" 比 "send it somewhere." 更清楚。
操作提示
这些建议来自在生产环境中运行自动化：
- 观察前三次运行。 自动化很容易设置；当你看到 Okou 在你的环境中实际产出什么后，就更容易优化。
- 保持每个任务都很小。 冗长的多步骤自动化更脆弱。如果单个自动化必须更新五个系统，考虑把它拆成两个。
- 固定目标位置。 频道会改名，人员会离开。在工作流指令中明确写出目标位置；如果下次运行时找不到它，Okou 会发出警告。
- 为长时间查询设定时间范围。 如果提示要求“过去 30 天”，请在每次运行中都重申这一点，以保持窗口新鲜。
- 确认时区。 计划和一次性自动化会存储显式时区；保存前请检查显示的值。
- 度假前暂停。 尤其是那些会 DM 你的自动化——回来后面对 14 条简短 DM 没什么帮助。禁用该自动化，回到后再重新启用；工作流会保持不变。
成本和数量
自动化触发会启动一次正常运行，并可能根据所用的模型路由和服务消耗积分。估算成本时，请查看自动化聊天和 Billing。
短间隔会迅速累积：如果每次运行都在下一个间隔到来之前完成，15 分钟的间隔一天内最多可能运行 96 次。较宽泛的事件筛选同样可能产生大量噪音。先缩小范围，检查最初几次触发，然后再有意识地放宽筛选条件或频率。
当你想停止新的触发，但又不删除其工作流或历史记录时，请禁用该自动化。
