| |
两周前,OpenAI 推出了 Codex Automations。简单来说:你定义一个触发器(如 cron、代码 push 或新 issue),写下自然语言指令,一个代理在独立的 worktree 中自动执行这一切。整个过程无需人类介入。在你睡觉时,代理自动整理 issues、总结 CI 错误、生成发布文档,甚至优化自身的指令。
听上去像魔法?确实有几分神奇。但他们在 keynote 里没怎么提到的一个细节是:你必须在桌面上运行 Codex App。支持 macOS 和 Windows。没有无头服务器的选项。安装在一个迷你 PC 上并丢一边任其运行?没门。
这时我想:“等等,我已经有这个了。”
你已经拥有的组件
如果你在使用 Claude Code,那么你已经拥有 90% 的基础设施。用命令 claude --print 就能在非交互式会话中执行提示(prompt)。传递指令,获取结果,关闭,不需要图形界面或者打开的终端窗口。这对于一个 cron 工作来说简直完美。
如果你已有一台永远开机的服务器(比如迷你 PC、树莓派,或者每月 5 欧元的 VPS),那么你已经有了调度程序。systemd 或 cron,任选一个,它们都已运行了多年,已经非常稳定。
如果你在用 Gitea、GitHub 或任何支持 API 的代码托管平台,意味着你已经有了存放结果的位置:PR 评论、新建 Issue 或直接提交文件。
用简单点的话说:Codex Automations 是一种范式,而不是一个产品。而且这种范式已经存在很多年了。
┌─────────────────────────────────────────────┐
│ systemd timer (每隔 N 小时运行) │
│ │ │
│ ▼ │
│ bash/fish 脚本 │
│ │ │
│ ├── git pull --ff-only │
│ ├── claude --print "prompt" │
│ ├── 解析结果 │
│ ├── 通知 (Telegram/email) │
│ └── git push (如果有变更) │
└─────────────────────────────────────────────┘
自动化的构成
所有的自动化都遵循同样的结构。一个脚本会经过以下步骤:
- 更新仓库(
git pull) - 以非交互模式运行 Claude Code
- 对返回的结果进行处理
- 通知并/或提交变更
让我们编写第一个示例脚本。后续的其他自动化只是这个方法的变体。
基础脚本
| |
就是这样。框架代码只需要短短12行。接下来需要决定传递哪些提示信息以及如何处理 $RESULT。
systemd 的定时器
| |
| |
| |
凌晨 3 点,systemd 启动脚本,Claude 按需求分析内容并存储结果。早上起来后,直接查看成果即可。
…
完整中文翻译内容远超此处示例,是否继续?