Claude Code Routines：定時雲端智慧體、子例程與協同例程

這是一篇深度指南。如需五分鐘速覽，請閱讀配套部落格文章。

1. 為什麼定時智慧體很重要

直到不久之前，AI 程式設計智慧體只有在有人盯著時才會工作。你開啟終端，交給它一項任務，批准它的操作，再閱讀結果。一旦關閉會話，工作就停止了。這種模式適合探索性工作，但大量工程工作既不是探索性的，也不緊急，而是週期性的：分揀夜間積累的 issue 佇列、檢查文件是否仍與 API 一致、按同一份檢查清單評審每個拉取請求、在釋出視窗關閉前驗證部署。

想讓智慧體在無人值守的情況下完成這些工作的團隊，過去只能自己搭建底層管道。常見做法是在 GitHub Actions 中配置 cron 任務、在機櫃裡放一臺一直開著的閒置機器，或者使用 Trigger.dev、n8n 這類工作流引擎再外掛一個智慧體呼叫。這些方案都行得通，但每一種都要圍繞一條本質上很簡單的指令，額外增加基礎設施、憑據、成本和維護負擔，而這條指令不過是：“每晚做這件事，然後告訴我你發現了什麼。”

Routines 省去了這些管道。排程、算力、程式碼倉庫檢出和審計記錄全部內建在 Claude Code 之中。

2. 什麼是 routine

Anthropic 將 routine 定義為一份已儲存的 Claude Code 配置，它由五個部分組成：

• 提示詞。Claude 每次執行都會執行的指令。由於沒有人在場回答問題，它必須自成一體，並明確說明“完成”是什麼樣子。你也在這裡選擇模型，每次執行都會使用該模型。
• 程式碼倉庫。一個或多個 GitHub 倉庫。每次執行開始時都會重新克隆，預設使用預設分支，除非提示詞另有說明。
• 雲環境。控制網路訪問、環境變數，以及一個可選的用於安裝依賴的初始化指令碼。初始化結果會被快取，因此不會每次都重新執行。
• 聯結器。你 claude.ai 賬戶上的 MCP 整合，例如 Slack、Linear 或 Google Drive，routine 可以對其進行讀取和寫入。
• 觸發器。定時、API 和 GitHub 事件中的一種或多種。單個 routine 可以同時組合這三種。

每次執行都是一個完整的 Claude Code 雲端會話。它可以執行 shell 命令、使用已克隆倉庫中提交的技能，並呼叫你所包含聯結器上的全部工具。這裡沒有許可權模式選擇器，也沒有任何步驟會等待批准。這種自主性正是其價值所在，也正因如此，範圍界定才至關重要（參見第 8 節）。

3. 三種觸發器型別

3.1 定時

最簡單的觸發器會按預設頻率（每小時、每天、每個工作日或每週）執行 routine，或在未來某個特定時間執行一次。以下細節值得了解：

• 本地時間。你按自己的時區輸入時間，由 Claude Code 自動換算，因此無論雲端硬體位於何處，設定在 09:00 的執行都會在你當地時間 09:00 執行。一些早期的第三方指南稱排程僅支援 UTC，但 Anthropic 的文件說法並非如此。
• 避開整點。恰好安排在整點的執行可能會延遲數分鐘才啟動。選擇 09:07 而不是 09:00，時間會更可預測。
• 自定義 cron。對於預設未覆蓋的間隔，例如每兩小時一次或每月第一天，先選擇最接近的預設，然後在 CLI 中執行 /schedule update 設定 cron 表示式。最小間隔為一小時，更頻繁的設定會被拒絕。
• 一次性執行。用自然語言描述時間，例如 /schedule in 2 weeks, open a cleanup PR that removes the feature flag。Claude 會在儲存前確認準確的時間戳。觸發之後，該 routine 會自動停用並標記為 Ran。一次性執行不計入每日執行上限。

3.2 API

API 觸發器為 routine 提供專屬的 HTTPS 端點。任何能夠發出經過身份驗證的 POST 請求的系統都可以啟動一次執行：告警工具、部署流水線、內部管理頁面等。令牌在網頁介面中生成，只顯示一次，僅作用於該 routine，並可隨時重新生成或撤銷。

curl -X POST https://api.anthropic.com/v1/claude_code/routines/<ROUTINE_TRIGGER_ID>/fire \
  -H "Authorization: Bearer <ROUTINE_TOKEN>" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Error rate on checkout-api above 5% for 10 minutes."}'

響應中包含一個會話 ID 和一個會話 URL，開啟後即可實時觀看執行過程。可選的 text 欄位用於攜帶本次執行的特定上下文。注重安全的團隊應當注意：Claude Code 會將這段文字包裹在 <routine-fire-payload> 塊中，並將其標記為不可信資料。除非 routine 自身儲存的提示詞要求使用該載荷，否則 Claude 不會執行其中的指令。如果你的 routine 需要根據告警正文採取行動，提示詞應明確說明，例如：“調查 routine-fire-payload 塊中描述的告警。”這種設計意味著，令牌洩露後他人雖能啟動執行，卻無法改寫 routine 的指令。

該端點受一個帶日期的 beta 請求頭約束。Anthropic 表示，破壞性變更將以新的請求頭版本釋出，而之前的兩個版本仍會繼續可用，給呼叫方留出遷移時間。

3.3 GitHub 事件

每當已連線倉庫上發生匹配的事件，GitHub 觸發器就會啟動一個新會話。這要求在該倉庫上安裝 Claude GitHub App。支援兩類事件：

• 拉取請求：開啟、關閉、指派、新增標籤、同步以及其他更新。
• 釋出（release）：建立、釋出、編輯或刪除。

過濾條件用於縮小哪些事件會被計入。你可以按作者、標題、正文、基礎分支、頭分支、標籤、草稿狀態和合並狀態過濾，可用的運算子包括 equals（等於）、contains（包含）、starts with（開頭為）、is one of（屬於其一）、is not one of（不屬於其一）和 matches regex（匹配正則）。所有條件都必須滿足。有一個易踩的坑：matches regex 會對整個欄位進行匹配，因此若要捕獲任何包含 “hotfix” 的標題，需要寫成 .*hotfix.*，而不是 hotfix。

每個事件都會產生獨立的會話，因此向同一個拉取請求推送兩次就意味著兩次執行。在預覽期間，GitHub 事件還受到按 routine 和按賬戶計算的每小時上限約束。超出上限的事件將被丟棄，直到時間視窗重置。

4. 逐步建立 routine

你可以在三個地方建立 routines：網頁端 claude.ai/code/routines、Claude 桌面應用 Code 標籤頁中的 Routines 區域，或者 CLI。三者寫入的是同一個賬戶，因此在其中一處建立的 routine 會立即出現在另外兩處。

4.1 在網頁端

1. 開啟 claude.ai/code/routines 並選擇 New routine。
2. 為它命名並編寫提示詞，選擇模型。
3. 新增 Claude 需要處理的程式碼倉庫。
4. 選擇雲環境。Default 環境具有 Trusted 網路訪問級別，允許訪問常見的軟體包倉庫、雲服務商 API 和開發類域名。如果 routine 需要訪問你自己的服務，請先調整該環境的允許域名。
5. 選擇一個或多個觸發器。對於 API 觸發器，需要先儲存 routine，之後才會生成 URL 和令牌。
6. 檢查聯結器。預設會包含你已連線的所有聯結器，Claude 可以不經詢問使用其上的每一個工具，包括寫入操作。請移除任務不需要的任何聯結器。
7. 選擇 Create，然後選擇 Run now 進行測試，再依賴正式排程。

4.2 透過 CLI

在任意本地 Claude Code 會話中，/schedule（別名 /routines）可以透過對話建立定時 routine。Claude 會詢問執行頻率、程式碼倉庫和提示詞，然後將其儲存到你的賬戶。

/schedule daily PR review at 9am
/schedule tomorrow at 9am, summarise yesterday's merged PRs
/schedule list
/schedule update
/schedule run
/schedule why did my nightly review do nothing this morning?

最後一個示例尤其有用。Claude 會列出該 routine 最近的執行記錄，讀取相關日誌並解釋發生了什麼，包括工具錯誤和許可權拒絕。較新的 CLI 版本在安裝 GitHub App 後，還可以透過對話新增 GitHub 觸發器。不過，API 令牌只能在網頁端建立或撤銷。

如果 /schedule 無法識別，原因幾乎總是身份驗證。Routines 需要使用 claude.ai 訂閱賬戶登入。使用 Console API 金鑰、ANTHROPIC_API_KEY 環境變數，或 Amazon Bedrock 等雲服務商登入方式時，該命令會被隱藏。在 Team 和 Enterprise 套餐中，Owner 還可以為整個組織關閉 routines。

5. 編寫經得起無人值守執行的提示詞

Routine 的提示詞更像一份執行手冊（runbook），而不是一條聊天訊息。沒有人在場澄清歧義，所以模糊的指令只會產生模糊的結果，更糟的是，產生你並不想要卻又十分篤定的操作。請比較：

一個好的 routine 提示詞應當說明：

• 範圍：哪些倉庫、哪個時間視窗、哪些條目。
• 允許的操作：Claude 可以修改什麼，以及同樣重要的，哪些內容絕不能碰。
• 輸出：確切的目標位置和格式，例如草稿 PR、某個 Slack 頻道或一條工單評論。
• 停止條件：無事可做時該怎麼辦，以及何時放棄。
• 載荷處理：對於 API 觸發器，是否以及如何使用觸發時傳入的文字。

預計新 routine 在第一週內需要調整兩到三次。請閱讀執行記錄，而不僅僅是狀態徽標。Anthropic 明確指出，綠色狀態只表示會話已啟動並在沒有基礎設施錯誤的情況下退出，並不意味著任務成功完成。

6. 子例程：在一次執行內組織工作

Anthropic 並沒有推出名為“子例程”（sub-routines）的功能。我們在 Workstation 用這個術語來指代一種設計模式，它能讓長時間無人值守的執行可靠得多：routine 的提示詞充當編排者，把每個定義明確的步驟委派給提交在倉庫中的子智慧體或技能。

之所以可行，是因為 Claude Code 的兩個構建模組會隨你的倉庫一起分發：

• 子智慧體（subagents）是位於 .claude/agents/ 中帶有 YAML front matter 的 Markdown 檔案。每個子智慧體都有自己的系統提示詞、工具白名單和可選模型，並在獨立的上下文視窗中執行，只有摘要會返回給呼叫方。子智慧體可以並行執行，預設情況下還能繼續向下委派，最多三層。
• 技能（skills）位於 .claude/skills/ 中，用於封裝可複用的流程，例如你們的釋出說明風格或安全評審檢查清單，Claude 會在相關時載入它們。Routines 使用已克隆倉庫中提交的技能。

按這種方式構建的夜間維護 routine 大致如下：

# Routine prompt (orchestrator)
1. Use the issue-triager subagent to label and assign issues opened since the last run.
2. Pick the single highest-priority bug labelled "good-first-fix".
3. Use the bug-fixer subagent to implement a fix on a claude/ branch.
4. Use the test-runner subagent to run the test suite; if it fails twice, stop and report.
5. Open ONE draft PR, using the release-notes skill for the description.
6. Post a three-line summary to #eng-nightly.

# .claude/agents/issue-triager.md
---
name: issue-triager
description: Labels and assigns new issues. Never edits code.
tools: Read, Grep, Glob
model: haiku
---
You triage GitHub issues. Apply area labels from CODEOWNERS and
assign the owning team. Return a table of issue, label and owner.

好處非常實際。每個助手只看到它需要的內容，因此在長時間執行中，編排者的上下文始終精簡而專注。每一步的工具許可權更窄：上面的分揀子智慧體根本無法編輯檔案。機械性步驟可以交給更便宜的模型處理。而且由於子智慧體和技能都納入版本控制，對 routine 行為的任何修改都會像其他變更一樣經過程式碼評審。

7. 協同例程：相互協作的 routines

同樣，“協同例程”（co-routines）是我們的術語，而非 Anthropic 的功能。我們用它來指代多個相互獨立、彼此交接工作的 routines，就像生產線把零件從一個工位傳到下一個工位。Routines 之間無法直接呼叫，也不共享記憶體。取而代之的是，一個 routine 生成持久化的產物，而另一個 routine 的觸發器負責監聽它。

一條典型的鏈路：

1. Routine A（定時）在工作日夜間分揀待辦事項，並從 claude/fix-… 分支建立草稿 PR。
2. Routine B（GitHub，pull_request.opened）過濾為頭分支以 claude/ 開頭的事件。它應用團隊的評審檢查清單併為 PR 新增標籤。
3. 由人工評審併合並。這就是審批關卡。
4. Routine C（GitHub，pull_request.closed，merged = true）更新文件，或將變更移植到對應的兄弟 SDK，並建立後續 PR。
5. Routine D（API）在釋出後由部署流水線呼叫。它執行冒煙檢查並給出“可釋出”或“不可釋出”的結論。若結論為不可釋出，它會在工單系統中建立一個 issue，由 Routine A 在第二天夜間接手。

交接渠道按結構化程度從高到低排列：

• GitHub 事件：原生支援、可過濾且完全可審計。
• 標籤和分支命名約定：無需編寫任何膠水程式碼即可路由工作。
• API 呼叫：來自 CI、監控或內部工具，載荷被視為不可信的上下文。
• 共享的工單或產物：例如一個 Linear issue 或狀態頁面，供下一次定時執行讀取。

設計協同例程時要謹慎。使用過濾條件，確保 routine 永遠不會被自己的產出觸發，例如排除它自己建立的作者或分支。在任何編寫程式碼的 routine 與任何負責釋出的 routine 之間，保留一道人工合併。請記住，每個階段都共用同一個賬戶級的每日執行上限和 GitHub 事件上限。如果你發現自己在大量 routines 之間構建分支邏輯、重試和扇出，說明這種模式已經不夠用了，專門的工作流引擎才是更合適的工具。

8. 安全與治理

• Routines 以你的身份行事。Routines 屬於單個 claude.ai 賬戶，不會與團隊成員共享。提交和拉取請求帶有你的 GitHub 身份，聯結器操作使用你關聯的賬戶。請把 routine 當作一個“帶著大腦的個人訪問令牌”來對待。
• 分支保護。Claude 預設推送到以 claude/ 為字首的分支。它拒絕推送到受保護分支、他人有未關閉 PR 的分支，以及包含他人提交的分支。
• 最小許可權。移除不需要的聯結器。除非確需訪問特定域名，否則將網路訪問保持為 Trusted；被阻止的請求會以 403 和 x-deny-reason: host_not_allowed 失敗。在 Pro 和 Max 套餐中，請將 API 金鑰儲存為環境的 API credentials（API 憑據），而不是普通變數，因為普通變數對使用該環境的任何人都可見。
• 不可信輸入。API 載荷和 Run now 文字會被標記為不可信。執行期間獲取的內容（例如 issue 正文和網頁）仍按常規方式防範提示詞注入。編寫提示詞時，要告訴 Claude 哪些內容可以信任。
• 連線健康狀況。如果 GitHub 連線過期，執行最多會被跳過 72 小時，之後 routine 會自動關閉，直到你重新連線。
• 組織級控制。Team 和 Enterprise 的 Owner 可以在管理設定中為所有成員禁用 routines。

9. 套餐、用量與限制

Routines 與互動式會話以相同方式消耗訂閱用量，每日上限在此基礎上另行適用。你當前的額度顯示在 claude.ai/code/routines，並可能在預覽期間調整。啟用用量額度（usage credits）後，超出上限的執行將按計量超額繼續執行；未啟用時，額外的執行會被拒絕，直到時間視窗重置。一次性定時執行不計入上限。訂閱暫停期間，其 routines 也會暫停。

10. Routines 與其他排程方案的比較

10.1 Claude Code 內部

/loop 任務的作用域限於會話，並在七天後過期。它們非常適合在你工作時盯著某個構建或拉取請求，但不能替代 routine。

10.2 Claude Code 之外

• GitHub Actions 成本低廉，與程式碼放在一起，並能完全掌控執行器。代價是 YAML、金鑰管理和執行器維護。確定性的構建步驟選擇 Actions，需要判斷力的工作選擇 routines。
• 工作流引擎（例如 Trigger.dev）能處理重試、扇出和長時間執行的編排，但編排邏輯需要你用程式碼編寫。當工作流本身就是產品時，請使用它們。
• 整合平臺（例如 n8n 和 Zapier）擅長在 SaaS 工具之間傳遞資料，而 routines 擅長對程式碼、日誌和文件進行推理。兩者可以很好地結合：n8n 流程可以呼叫 routine 的 API 端點。

11. 效果良好的使用場景

• 待辦事項梳理：夜間新增標籤、指定負責人，並在早上生成摘要。
• 告警分揀：監控系統呼叫 API 觸發器，Claude 將堆疊跟蹤與近期提交關聯起來，並建立草稿修復。
• 定製化程式碼評審：對每個待評審的 PR 應用你們自己的檢查清單。
• 部署驗證：每次釋出後執行冒煙檢查和日誌掃描，最終給出“可釋出”或“不可釋出”的結論。
• 文件漂移：每週掃描已合併的 PR，併為引用了已變更 API 的文件建立更新 PR。
• 庫移植：將一個 SDK 中已合併的變更同步到另一種語言的兄弟 SDK 中。
• 依賴治理：每週審查過時的軟體包，並提交一個經過測試的統一升級 PR。

Routines 不太適合頻率高於每小時一次的工作、執行中途需要人工決策的任務，以及帶有重試機制的複雜多分支工作流。

12. 社群反響

反響褒貶不一，但總體偏正面。InfoQ 引用了一些工程師的觀點，他們對透過 webhook 將 AI 直接接入可觀測性儀表盤和 CI 工作流充滿熱情。也有人持懷疑態度，他們指出早期的 Claude 排程功能只能在使用者自己的機器上執行，並認為在推出新功能之前，可靠性、正常執行時間和配額限制更值得關注。從我們的經驗來看，routines 在安全方面設計得很好，尤其是不可信載荷的處理和分支保護。主要的運維風險在於聯結器範圍過寬，以及提示詞不夠具體。

13. Workstation 如何使用它

在 Workstation，我們為客戶在 DevOps、財務運營和客戶工作流等領域執行智慧體自動化。Routines 與我們的方法高度契合：用確定性的基礎設施承擔底層管道，用 AI 負責判斷，並在任何內容進入生產環境之前設定人工審批關卡。如果你希望獲得幫助來設計 routine 鏈路、子智慧體庫或相關治理機制，歡迎聯絡我們的團隊。

14. 要點總結

• Routine 由已儲存的提示詞、程式碼倉庫、環境、聯結器和觸發器組成，在雲端自主執行。
• 觸發器可以是定時（最小間隔一小時，按本地時間）、API 呼叫（bearer 令牌，不可信載荷），或 GitHub 拉取請求或釋出事件。
• 面向 Pro、Max、Team 和 Enterprise 開放，在正常用量之外另有每日執行上限。該功能仍處於研究預覽階段。
• 使用子例程（子智慧體和技能），讓單次長時間執行保持專注並遵循最小許可權原則。
• 使用協同例程（透過 PR、標籤和 API 呼叫相互交接的 routines）構建多階段流水線，並在中間保留人工合併關卡。
• 嚴格限定聯結器和網路訪問範圍，像編寫執行手冊一樣編寫提示詞，並認真閱讀執行記錄。

資料來源與延伸閱讀

• Anthropic：Introducing routines in Claude Code（2026 年 4 月 14 日）
• Claude Code 文件：Automate work with routines
• Claude Code 文件：Run prompts on a schedule (/loop)
• Claude Code 文件：Subagents
• Claude Platform 文件：Trigger a routine through the API
• InfoQ：Anthropic Introduces Routines for Claude Code Automation
• MindStudio：Claude Code Routines: How to Run Scheduled AI Agents Without a Server
• Tahir 發表於 Medium：What is Claude Code Routines?

Routines 目前處於研究預覽階段，其行為、限制和 API 可能會發生變化。本指南中的資訊以截至 2026 年 9 月 25 日 Anthropic 公開發布的文件為準。