開場故事

如果你把 OpenClaw 想成一個會上班的 Agent，那 cron 就像它的打卡鬧鐘。

但這個鬧鐘不是單純「時間到就響」而已。
它比較像一張排程單：

• 到點叫醒系統
• 把這次任務標成 cron turn
• 直接執行排好的 payload
• 不要先做一大堆跟任務無關的 bootstrap
• 做完就盡量給出乾淨、簡短、可機器處理的結果

這也是為什麼我覺得 cron 很值得單獨拿出來講。
因為它不是一般對話 turn。
它是「系統自己安排自己做事」的那一類 turn。

第 17 天我想看的就是這件事：

cron 是怎麼被 OpenClaw 掛進來的？

今天要解的問題

• cron turn 和一般聊天 turn 差在哪裡？
• OpenClaw 為什麼要替 cron 準備專屬協作指示？
• cron 執行時，為什麼要先直接做 payload？
• 為什麼 cron 不該先花時間讀 bootstrap、memory、project docs？
• cron 在工具和生命週期上，為什麼會有比較窄的權限？

架構總覽

先把這條線想清楚：

1. 排程器在時間到了之後喚起一個 turn
2. OpenClaw 看到這次 trigger === "cron"
3. runtime 立刻切換成 cron 專用的 collaboration instructions
4. 這次 turn 直接執行 payload
5. 回傳結果時保持簡短、機器友善

這裡最關鍵的觀念是：

cron 不是一種「更特別的聊天」，而是一種「更偏自動化的工作 turn」。

所以它的行為設計也不一樣。
它要少一點人味，多一點確定性；少一點探索，多一點直接執行。

原始碼節錄

先看 OpenClaw 怎麼把 cron 變成專屬協作指示。

📄 原始碼：extensions/codex/src/app-server/thread-lifecycle.ts:2844-2846

function buildTurnScopedCollaborationInstructions(params) {
	if (params.trigger === "cron") return buildCronCollaborationInstructions();
	if (params.trigger === "heartbeat") return buildHeartbeatCollaborationInstructions();
	return null;
}

function buildCronCollaborationInstructions() {
	return [
		"This is an OpenClaw cron automation turn. Apply these instructions only to this scheduled job; ordinary chat turns should stay in Codex Default mode.",
		"Execute the cron payload directly. If it asks you to run an exact command, run that command before doing any investigation, planning, memory review, or workspace bootstrap.",
		"Use context already provided by the runtime, but do not spend time loading or re-reading workspace bootstrap, memory, or project-doc files before executing the cron payload. Inspect those files only if the payload asks for them or the command fails and they are needed to diagnose it.",
		"Keep output concise and automation-oriented. Prefer the final command result or a short failure summary over status narration."
	].join("\\n\\n");
}

這段短，但意思很重。

它等於在說：

• 這次不是一般對話
• 這次是 scheduled job
• 你要優先執行 payload
• 不要先進入長篇思考模式
• 不要浪費時間重新讀不必要的資料

也就是說，OpenClaw 會替 cron turn 改寫工作姿勢。

再看工具層怎麼對 cron 做限制。

📄 原始碼：src/agents/agent-tools.ts:459-460

const cronSelfRemoveOnlyJobId =
  options?.trigger === "cron" && options.jobId?.trim() ? options.jobId.trim() : undefined;

這個變數很小，但透露出一個很實際的設計：

• cron 不是完全自由的背景執行
• 它在某些情境下只允許處理自己的 job
• 也就是說，排程 turn 的權力是被收斂過的

這很符合 OpenClaw 的整體哲學：

背景工作要能自動跑，但不能無邊界地亂跑。

白話拆解

1. cron 不是「晚點再做」，而是「系統幫你安排好的工作」

很多人聽到 cron，只會想到定時執行。

但在 OpenClaw 裡，它的語意更像：

• 這不是人臨時丟進來的聊天
• 這是系統已經決定要做的工作
• 所以它有自己的執行規矩

這就是為什麼 cron 需要專屬 instructions。

2. 為什麼要直接執行 payload

因為 cron 的價值，不在於它會不會聊天，而在於它能不能準時做事。

如果每次 cron turn 都先做一大堆：

• 重新讀 workspace bootstrap
• 重新翻 memory
• 重新想自己是誰
• 重新整理世界觀

那排程系統很快就會變慢，甚至變得不可預測。

所以 OpenClaw 乾脆告訴它：

先做 payload，其他事情只有在必要時才補。

這樣才像排程。

3. cron 的輸出要短

排程任務通常不是寫長篇報告。

它更像是：

• 成功了，給我結果
• 失敗了，給我短摘要
• 需要人工接手，再把關鍵資訊留下來

這樣後續的 automation 才接得上。

4. cron turn 的邊界要比一般聊天窄

你可以把 cron 想成一個只有固定工具箱的夜班員工。

它不需要知道整間公司每個角落的細節。
它只要知道：

• 這次任務是什麼
• 可以做哪些事
• 做完要怎麼交代

這樣做的好處是穩。
代價是彈性比較小。

但排程任務本來就不是拿來亂探索的。

設計取捨

• 好處是 cron turn 很乾淨，直接對準工作目標
• 好處是避免排程任務把時間花在不必要的 bootstrap 上
• 好處是自動化的輸出比較容易接其他系統
• 好處是權限與行為邊界比較明確
• 代價是它不能像一般對話那樣自由發散
• 代價是 debug 時要先知道這次是 cron turn，不能直接拿普通 turn 的期待套上去

我覺得這樣的設計很對。
因為排程本來就不是來聊天的。
排程是來讓系統自己去處理那些應該固定做的事。

今天的結論

• cron 在 OpenClaw 裡是特殊的 scheduled turn，不是一般聊天
• buildCronCollaborationInstructions() 會把工作姿勢切到 automation 模式
• cron turn 要優先執行 payload，不要先做多餘的 bootstrap
• cron 的輸出要簡短、可接續、可機器處理
• cron 在工具與 job 處理上會有較窄的邊界
• 這種設計讓 OpenClaw 的排程任務更穩，也更像真正的工作流

下一步

下一篇我想接著看另一個很像「資料來源」但其實更像「能力清單」的東西：

OpenClaw 怎麼找到並讀進 skill.md？