Automations · 自动化层 · 你不在场时它替你跑(可选)
它回答的问题: 哪些工作流可以脱离你的盯盘自动跑? 它在哪: cron / 工具内建 scheduler / GitHub Actions / 工具的 Hooks 它读取的时机: 计划任务定时触发 / 事件触发
原文金句
★ 「An agent that is running at 3:00 a.m. with a wrong answer can do damage before you wake up.」 「一个凌晨 3 点跑、答案是错的 Agent, 可以在你醒来之前造成实质损害。」 (#350-351,
00:23:53,021 → 00:24:02,371)
「自动化是一个很棒的、非必需的加项。」 (#344)
它在解决什么真问题
前面 6 层让你主动用 AI。 这一层让 AI 在你不在场时为你工作 — 每天早上 7 点的日报、定时去 ping Slack 的监控任务、工作日下午 5 点的承诺 follow-up。
但这一层是 7 层里风险密度最高的。 一个错误的自动任务, 会在你醒来前发出 100 封错邮件。
Nufar 的三条铁律
铁律 1 · 只自动化你已经手动跑过、信任的工作流 (#353)
「Only automate workflows you have run manually enough times and trust.」
实操规则: 这个 Skill 你必须手动调用过 ≥ 10 次, 每次结果你都直接 ship 没改, 才有资格自动化。
铁律 2 · 从「只产草稿、由你审阅」开始 (#354-355)
「Start with automations that produce draft for you to review, not outputs that go directly to other people.」
实操规则: 自动化的输出必须先到你的私人 inbox / DM / 草稿箱, 不直接发给任何其他人。 等你审了 30 天每天都没改动, 才考虑放开「直接发出」。
铁律 3 · 永远加日志 (#356-357)
「Always add logs. You need to know what ran and what it did as it was running.」
实操规则: 每个自动化任务必须写 stdout 到一个文件, 包含:
- 触发时间
- 用了哪些 Context / Skill
- 输出摘要(前 200 字)
- 任何报错
工具落点(2026-05-09 现状)
| 工具 | Automations 形态 | 备注 |
|---|---|---|
| Codex | Codex Automations(项目+prompt+cadence+sandbox 执行环境)+ background mode | 最完整 |
| Cursor | Cursor Automations(2026 GA, 云端 sandbox, 定时+事件) | 完整 |
| OpenAI Workspace Agents | 长跑云端 workflow | 企业级 |
| Hermes | cron + 7 种 sandbox 后端(Docker / SSH / Modal / Daytona / Vercel Sandbox 等) | 开源最强 |
| Claude Code | Hooks + OS cron(没有云端 scheduler) | 本地 |
| GitHub Copilot | GitHub Actions(外挂) | 走 CI |
| OpenCode | ❌ 无原生 | 需自己写 |
给 Chief of Staff 的自动化清单
按风险递增, 逐步加:
Level 1 · 只读 + 输出到自己(强烈推荐第一步)
- 每天 7:00 Daily Brief → 跑 Daily Brief Skill, 输出到你自己的 DM / Notion / 私人 inbox
- 每周五 16:00 Weekly Retrospective → 跑回顾 Skill, 输出到
memory/retrospectives/
Level 2 · 写权限但只写自己的工具
- 每天 17:00 Commitment Tracker → 扫今天的会议笔记, 把承诺写进你的个人任务列表
Level 3 · 谨慎引入(等 30 天 + 审过)
- 每周一 09:00 同步会议草稿 → 起草这周一对一议程, 放进你的草稿箱(不直接发)
Level 4 · 长期不建议
- 直接对外发邮件 / 自动加同事日历 / Slack 公开频道发言 — Nufar 的隐喻: 「凌晨 3 点错答可在你醒前造成损害」。
落地步骤(给你今天的 30 分钟 — 仅当你已搭好前 6 层)
前置检查
- Identity ✅ 已写 + 70% 满意
- Context ✅ 至少 3 份
- Skills ✅ 至少 3 个, 每个都跑过 10+ 次没改
- Memory ✅ 至少有 decisions.md
- Connections ✅ 至少 1 个 MCP / API 已配
- Verification ✅ 高频 Skill 已加 checklist + 跑过至少 1 次月度 retro
任何一条没勾上, 关掉这一篇, 不要做自动化。 退回去把那一层补上。
Step 1 · 挑一个最低风险的 Skill 自动化
最佳候选: Daily Brief(只读, 输出到自己, 没人会因为它错而受影响)。
Step 2 · 写日志包装
不直接调用 Skill, 包一层日志:
# ~/agent-os/automations/daily-brief.sh
#!/bin/bash
LOG=~/agent-os/logs/daily-brief-$(date +%Y-%m-%d).log
echo "===== $(date) =====" >> "$LOG"
claude run-skill daily-brief 2>&1 >> "$LOG"
echo "===== END =====" >> "$LOG"Step 3 · 加到 cron / scheduler
# crontab -e
0 7 * * * /Users/<you>/agent-os/automations/daily-brief.sh或在 Codex / Cursor 的 Automations 面板里建一个项目级定时。
Step 4 · 跑 7 天观察
每天打开输出, 检查质量。 如果有 1 次明显错, 暂停自动化, 修 Skill, 再跑。
Step 5 · 30 天后扩
第二个、第三个自动化, 同样按 Level 1 → 2 → 3 递进。
常见坑
| 坑 | 现象 | 怎么避 |
|---|---|---|
| 太早开始 | 第 1 周就自动化, Skill 还没稳定 | 先手动跑 ≥ 10 次没改, 再上自动化 |
| 直接对外 | 自动化发邮件给客户 → 错了 | 永远先到草稿 / 自己 inbox, 30 天验证后再放开 |
| 没日志 | 出问题不知道哪一步 | 每次必写日志, log 比输出更重要 |
| 加完忘了 | 三个月后还在跑, 内容全变了 | 每月 retro 时审一次自动化清单 |
| 链式调用 | 一个自动化触发另一个, 错误放大 | 不做 agent-to-agent 的链式自动化, 至少初期不做 |
🟢 译者点评
🟢 这一层是 7 层里最容易让人觉得「酷」, 但也是最容易让你掉进真实事故的。 我建议: 把这层当成奖励, 不是入门。 如果你前 6 层没稳定 8 周以上, 不要做自动化 — 你只是在用更高频率重复一个不够好的系统。
🟢 「永远加日志」 比看上去重要 10 倍。 没日志的自动化等于没有的: 出问题你不知道哪一步, 也不知道历史上做错过多少次。 我自己的最低标准: 每个自动化必须输出 stdout 到 ~/agent-os/logs/<task>-<date>.log, 周末扫一次, 看到有多少次「我以为对其实不对」 的输出 — 这个数字会让你重新审视 Skill 设计。
🟢 「凌晨 3 点错答」 这个隐喻被低估了。 真实事故案例: 我有同事的自动化在每周一早上自动给客户发 weekly status, 某个周一 LLM provider 出了 rate-limit, Skill 错把异常输出当成正文发了出去。 客户收到一份「Error: 429 Too Many Requests」 当 weekly status。 信任下降, 客户合同砍价。 永远先到草稿, 不直接对外。
🟢 企业级用户:这一层和 IT / 安全团队的合作不可绕开。 如果你接的是公司账号、公司数据, 自动化绕过公司 IT 的审计去跑, 出事 100% 是你担责。 路径长一点没关系, 走 IT 那条线比独自背锅好。
🔗 立刻去做(只在你前 6 层稳定后)
→ 选一个 Daily Brief 类的低风险 Skill 自动化, 跑 7 天, 然后读 08 Chief of Staff 完整模板 — 完整的 CoS 工作目录复刻。
🔗 延伸阅读
- Codex Automations 文档 — 当前业界最完整的自动化产品
- Cursor Automations — 2026 GA 的云 sandbox 自动化
- Hermes — cron + 7 backends 架构
- Claude Code Hooks — 事件驱动 + cron 组合实现自动化