Claude Code Routines: เอเจนต์บนคลาวด์ตามกำหนดเวลา รูทีนย่อย และรูทีนร่วม

นี่คือคู่มือเชิงลึก หากต้องการภาพรวมแบบห้านาที อ่านได้ที่บทความบล็อกประกอบ

1. ทำไมเอเจนต์ที่ทำงานตามกำหนดเวลาจึงสำคัญ

จนถึงไม่นานมานี้ เอเจนต์ AI สำหรับเขียนโค้ดทำงานได้เฉพาะเมื่อมีคนคอยดูอยู่ คุณต้องเปิดเทอร์มินัล สั่งงาน อนุมัติการกระทำของมัน และอ่านผลลัพธ์ เมื่อปิดเซสชัน งานก็หยุดลง รูปแบบนี้เหมาะกับงานเชิงสำรวจ แต่งานวิศวกรรมจำนวนมากไม่ได้เป็นงานเชิงสำรวจหรืองานเร่งด่วน หากเป็นงานที่เกิดซ้ำ เช่น คัดแยกคิว issue ที่สะสมมาตลอดคืน ตรวจสอบว่าเอกสารยังตรงกับ API รีวิว pull request ทุกตัวด้วยเช็กลิสต์เดียวกัน หรือตรวจสอบการดีพลอยก่อนที่ช่วงเวลาปล่อยเวอร์ชันจะปิด

ทีมที่ต้องการให้เอเจนต์ทำงานเหล่านี้โดยไม่มีคนดูแลต้องสร้างระบบรองรับเอง ทางเลือกที่พบบ่อยคือ cron job ใน GitHub Actions เครื่องสำรองที่เปิดทิ้งไว้ในห้องเก็บของ หรือเอนจินเวิร์กโฟลว์อย่าง Trigger.dev หรือ n8n ที่ต่อการเรียกเอเจนต์เพิ่มเข้าไป ทุกวิธีใช้งานได้ แต่ล้วนเพิ่มโครงสร้างพื้นฐาน ข้อมูลรับรอง ค่าใช้จ่าย และภาระดูแลรักษา ให้กับสิ่งที่แท้จริงแล้วเป็นเพียงคำสั่งเดียว: "ทำสิ่งนี้ทุกคืน แล้วบอกฉันว่าเจออะไรบ้าง"

Routines ขจัดระบบรองรับเหล่านั้นออกไป ทั้งกำหนดเวลา ทรัพยากรประมวลผล การเช็กเอาต์รีโพสิทอรี และบันทึกการตรวจสอบ ล้วนอยู่ภายใน Claude Code เอง

2. routine คืออะไร

Anthropic นิยาม routine ว่าเป็นการกำหนดค่า Claude Code ที่บันทึกไว้ ซึ่งประกอบด้วยห้าส่วน:

• พรอมต์ คำสั่งที่ Claude ปฏิบัติในทุกการรัน เนื่องจากไม่มีใครอยู่ตอบคำถาม พรอมต์จึงต้องครบถ้วนในตัวเองและต้องระบุว่าอะไรคือ "งานเสร็จ" คุณยังเลือกโมเดลได้ที่นี่ และโมเดลนั้นจะถูกใช้ในทุกการรัน
• รีโพสิทอรี รีโพสิทอรี GitHub หนึ่งแห่งหรือมากกว่า แต่ละแห่งจะถูกโคลนใหม่ทุกครั้งที่เริ่มรัน จากแบรนช์เริ่มต้น เว้นแต่พรอมต์จะระบุเป็นอย่างอื่น
• สภาพแวดล้อมบนคลาวด์ ควบคุมการเข้าถึงเครือข่าย ตัวแปรสภาพแวดล้อม และสคริปต์ตั้งค่าซึ่งเป็นตัวเลือกเสริมสำหรับติดตั้ง dependency ผลลัพธ์ของการตั้งค่าจะถูกแคชไว้ จึงไม่ต้องรันซ้ำทุกครั้ง
• คอนเนกเตอร์ การเชื่อมต่อ MCP ในบัญชี claude.ai ของคุณ เช่น 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 แบบกำหนดเอง สำหรับช่วงเวลาที่ตัวเลือกสำเร็จรูปไม่รองรับ เช่น ทุกสองชั่วโมง หรือวันที่หนึ่งของเดือน ให้เลือกตัวเลือกที่ใกล้เคียงที่สุด แล้วรัน /schedule update ใน CLI เพื่อตั้งค่า cron expression ช่วงห่างขั้นต่ำคือหนึ่งชั่วโมง ความถี่ที่มากกว่านั้นจะถูกปฏิเสธ
• การรันครั้งเดียว อธิบายเวลาด้วยภาษาธรรมดา เช่น /schedule in 2 weeks, open a cleanup PR that removes the feature flag Claude จะยืนยันเวลาที่แน่นอนก่อนบันทึก หลังจากรันแล้ว routine จะปิดตัวเองและถูกทำเครื่องหมายว่า Ran การรันครั้งเดียวไม่นับรวมในเพดานการรันต่อวัน

3.2 API

ทริกเกอร์ API จะให้ HTTPS endpoint เฉพาะแก่ routine ระบบใดก็ตามที่ส่ง POST request แบบยืนยันตัวตนได้สามารถเริ่มการรันได้ เช่น เครื่องมือแจ้งเตือน ไปป์ไลน์การดีพลอย หรือหน้าผู้ดูแลระบบภายใน token จะถูกสร้างใน web UI แสดงเพียงครั้งเดียว ใช้ได้กับ 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."}'

response จะมี session ID และ session URL ที่เปิดดูการรันแบบเรียลไทม์ได้ ฟิลด์ text ซึ่งเป็นตัวเลือกเสริมใช้ส่งบริบทเฉพาะของการรันแต่ละครั้ง ทีมที่ให้ความสำคัญกับความปลอดภัยควรทราบว่า Claude Code จะห่อข้อความนี้ไว้ในบล็อก <routine-fire-payload> และระบุว่าเป็นข้อมูลที่ไม่น่าเชื่อถือ Claude จะไม่ทำตามคำสั่งที่อยู่ในนั้น เว้นแต่พรอมต์ที่บันทึกไว้ของ routine จะสั่งให้ใช้ payload หาก routine ของคุณต้องดำเนินการตามเนื้อหาของการแจ้งเตือน พรอมต์ควรระบุไว้อย่างชัดเจน เช่น "Investigate the alert described in the routine-fire-payload block." การออกแบบนี้หมายความว่า token ที่รั่วไหลทำให้ผู้อื่นเริ่มการรันได้ แต่ไม่สามารถเขียนคำสั่งของ routine ใหม่ได้

endpoint นี้อยู่หลัง beta header ที่ระบุวันที่ Anthropic ระบุว่าการเปลี่ยนแปลงที่ไม่เข้ากันกับเวอร์ชันเดิมจะออกภายใต้ header เวอร์ชันใหม่ และสองเวอร์ชันก่อนหน้าจะยังใช้งานได้ต่อไป เพื่อให้ผู้เรียกใช้มีเวลาย้ายระบบ

3.3 เหตุการณ์ GitHub

ทริกเกอร์ GitHub จะเริ่มเซสชันใหม่ทุกครั้งที่เกิดเหตุการณ์ที่ตรงเงื่อนไขบนรีโพสิทอรีที่เชื่อมต่อไว้ โดยต้องติดตั้ง Claude GitHub App บนรีโพสิทอรีนั้น รองรับเหตุการณ์สองหมวด:

• Pull request: เปิด ปิด มอบหมาย ติดป้ายกำกับ ซิงโครไนซ์ และการอัปเดตอื่น ๆ
• Release: สร้าง เผยแพร่ แก้ไข หรือลบ

ตัวกรองช่วยจำกัดว่าเหตุการณ์ใดบ้างที่นับ คุณกรองได้ตามผู้เขียน ชื่อเรื่อง เนื้อหา base branch, head branch ป้ายกำกับ สถานะดราฟต์ และสถานะการ merge โดยใช้ตัวดำเนินการ equals, contains, starts with, is one of, is not one of และ matches regex ทุกเงื่อนไขต้องตรงกันทั้งหมด ข้อควรระวังหนึ่งคือ matches regex จะทดสอบกับทั้งฟิลด์ ดังนั้นหากต้องการจับชื่อเรื่องที่มีคำว่า "hotfix" คุณต้องใช้ .*hotfix.* ไม่ใช่ hotfix

แต่ละเหตุการณ์จะสร้างเซสชันอิสระของตัวเอง ดังนั้นการพุชสองครั้งไปยัง pull request เดียวกันหมายถึงการรันสองครั้ง ในช่วง preview เหตุการณ์ GitHub ยังมีเพดานรายชั่วโมงต่อ routine และต่อบัญชี เหตุการณ์ที่เกินเพดานจะถูกทิ้งจนกว่าช่วงเวลาจะรีเซ็ต

4. การสร้าง routine ทีละขั้นตอน

คุณสร้าง routine ได้จากสามที่: เว็บที่ claude.ai/code/routines ส่วน Routines ในแท็บ Code ของแอป Claude Desktop หรือ CLI ทั้งสามช่องทางบันทึกลงบัญชีเดียวกัน routine ที่สร้างจากที่หนึ่งจึงปรากฏในที่อื่นทันที

4.1 บนเว็บ

1. เปิด claude.ai/code/routines แล้วเลือก New routine
2. ตั้งชื่อและเขียนพรอมต์ จากนั้นเลือกโมเดล
3. เพิ่มรีโพสิทอรีที่ Claude ต้องทำงานด้วย
4. เลือกสภาพแวดล้อมบนคลาวด์ สภาพแวดล้อม Default มีการเข้าถึงเครือข่ายระดับ Trusted ซึ่งอนุญาตรีจิสทรีแพ็กเกจทั่วไป API ของผู้ให้บริการคลาวด์ และโดเมนสำหรับการพัฒนา หาก routine ต้องเข้าถึงบริการของคุณเอง ให้ปรับรายการโดเมนที่อนุญาตของสภาพแวดล้อมก่อน
5. เลือกทริกเกอร์อย่างน้อยหนึ่งรายการ สำหรับทริกเกอร์ API ให้บันทึก routine ก่อน URL และ token จะถูกสร้างหลังจากนั้น
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 ผ่านการสนทนาได้เมื่อติดตั้ง GitHub App แล้ว อย่างไรก็ตาม API token สร้างหรือเพิกถอนได้บนเว็บเท่านั้น

หาก /schedule ไม่ถูกจดจำ สาเหตุเกือบทั้งหมดมาจากการยืนยันตัวตน Routines ต้องใช้การเข้าสู่ระบบด้วยการสมัครสมาชิก claude.ai คีย์ API จาก Console, ตัวแปรสภาพแวดล้อม ANTHROPIC_API_KEY หรือการเข้าสู่ระบบผ่านผู้ให้บริการคลาวด์อย่าง Amazon Bedrock จะทำให้คำสั่งนี้ถูกซ่อน ในแพ็กเกจ Team และ Enterprise ผู้เป็น Owner ยังสามารถปิด Routines สำหรับทั้งองค์กรได้

5. การเขียนพรอมต์ที่ทนทานต่อการรันแบบไม่มีคนดูแล

พรอมต์ของ routine ใกล้เคียงกับคู่มือปฏิบัติงาน (runbook) มากกว่าข้อความแชต เมื่อไม่มีใครอยู่คอยอธิบายความกำกวม คำสั่งที่คลุมเครือก็ให้ผลลัพธ์ที่คลุมเครือ หรือแย่กว่านั้นคือการกระทำอย่างมั่นใจที่คุณไม่ได้ตั้งใจ ลองเปรียบเทียบ:

พรอมต์ของ routine ที่ดีควรระบุ:

• ขอบเขต: รีโพสิทอรีใด ช่วงเวลาใด และรายการใด
• การกระทำที่อนุญาต: สิ่งที่ Claude เปลี่ยนแปลงได้ และที่สำคัญไม่แพ้กันคือสิ่งที่ห้ามแตะต้อง
• ผลลัพธ์: ปลายทางและรูปแบบที่แน่นอน เช่น PR แบบดราฟต์ ช่อง Slack หรือความคิดเห็นในระบบติดตามงาน
• เงื่อนไขการหยุด: สิ่งที่ต้องทำเมื่อไม่มีงาน และเมื่อใดควรยุติ
• การจัดการ payload: สำหรับทริกเกอร์ API ให้ระบุว่าจะใช้ข้อความที่ส่งมาหรือไม่ และใช้อย่างไร

เตรียมปรับแต่ง routine ใหม่สองหรือสามครั้งในสัปดาห์แรก อ่านบันทึกการทำงาน ไม่ใช่ดูแค่ป้ายสถานะ Anthropic ระบุชัดเจนว่าสถานะสีเขียวหมายความเพียงว่าเซสชันเริ่มและจบลงโดยไม่มีข้อผิดพลาดด้านโครงสร้างพื้นฐาน ไม่ได้หมายความว่างานสำเร็จ

6. รูทีนย่อย: การจัดโครงสร้างงานภายในการรันครั้งเดียว

Anthropic ไม่มีฟีเจอร์ที่ชื่อว่า "รูทีนย่อย" (sub-routines) ที่ Workstation เราใช้คำนี้เรียกรูปแบบการออกแบบที่ทำให้การรันแบบไม่มีคนดูแลที่ใช้เวลานานเชื่อถือได้มากขึ้นอย่างมาก: พรอมต์ของ routine ทำหน้าที่เป็นผู้ประสานงาน และมอบหมายแต่ละขั้นตอนที่กำหนดไว้ชัดเจนให้ซับเอเจนต์หรือสกิลที่คอมมิตไว้ในรีโพสิทอรี

วิธีนี้ได้ผลเพราะองค์ประกอบพื้นฐานสองอย่างของ Claude Code ที่อยู่ในรีโพสิทอรีของคุณ:

• ซับเอเจนต์ คือไฟล์ Markdown ที่มี YAML front matter อยู่ใน .claude/agents/ แต่ละตัวมี system prompt รายการเครื่องมือที่อนุญาต และโมเดลซึ่งเป็นตัวเลือกเสริมของตัวเอง และทำงานในหน้าต่างบริบทของตัวเอง มีเพียงบทสรุปเท่านั้นที่ส่งกลับไปยังผู้เรียก ซับเอเจนต์ทำงานแบบขนานได้ และโดยค่าเริ่มต้นสามารถมอบหมายงานต่อได้ลึกถึงสามระดับ
• สกิล ใน .claude/skills/ รวบรวมขั้นตอนที่ใช้ซ้ำได้ เช่น รูปแบบการเขียน release note หรือเช็กลิสต์รีวิวความปลอดภัยของคุณ ซึ่ง 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.

ประโยชน์ที่ได้นั้นจับต้องได้จริง ผู้ช่วยแต่ละตัวเห็นเฉพาะสิ่งที่จำเป็น บริบทของผู้ประสานงานจึงเล็กและโฟกัสตลอดการรันที่ยาวนาน สิทธิ์การใช้เครื่องมือแคบลงในแต่ละขั้นตอน ตัวอย่างเช่น triager ด้านบนไม่สามารถแก้ไขไฟล์ได้เลย โมเดลที่ราคาถูกกว่าจัดการขั้นตอนที่เป็นงานกลไกได้ และเนื่องจากซับเอเจนต์และสกิลอยู่ในระบบควบคุมเวอร์ชัน การเปลี่ยนพฤติกรรมของ routine จึงต้องผ่านการรีวิวโค้ดเช่นเดียวกับการเปลี่ยนแปลงอื่น ๆ

7. รูทีนร่วม: routine ที่ทำงานร่วมกัน

ขอย้ำอีกครั้งว่า "รูทีนร่วม" (co-routines) เป็นคำของเรา ไม่ใช่ฟีเจอร์ของ Anthropic เราใช้คำนี้เรียกroutine อิสระหลายตัวที่ส่งต่องานให้กัน เหมือนสายการผลิตที่ส่งชิ้นงานจากสถานีหนึ่งไปยังสถานีถัดไป routine ไม่สามารถเรียกใช้กันโดยตรงและไม่มีหน่วยความจำร่วมกัน แต่ routine หนึ่งจะสร้างสิ่งที่คงอยู่ถาวร (artefact) ซึ่งทริกเกอร์ของอีก routine หนึ่งคอยเฝ้าดูอยู่

ห่วงโซ่โดยทั่วไป:

1. Routine A (กำหนดเวลา) คัดแยก backlog ในคืนวันทำการ และเปิด PR แบบดราฟต์จากแบรนช์ claude/fix-…
2. Routine B (GitHub, pull_request.opened) กรองเฉพาะ head branch ที่ขึ้นต้นด้วย claude/ โดยใช้เช็กลิสต์รีวิวของทีมและติดป้ายกำกับให้ PR
3. มนุษย์รีวิวและ merge นี่คือจุดอนุมัติ
4. Routine C (GitHub, pull_request.closed, merged = true) อัปเดตเอกสารหรือพอร์ตการเปลี่ยนแปลงไปยัง SDK พี่น้อง แล้วเปิด PR ติดตามผล
5. Routine D (API) ถูกเรียกโดยไปป์ไลน์การดีพลอยหลังการปล่อยเวอร์ชัน จะรัน smoke check และโพสต์ผล go หรือ no-go หากเป็น no-go จะสร้าง issue ในระบบติดตามงาน ซึ่ง Routine A จะหยิบไปทำในคืนถัดไป

ช่องทางการส่งต่องาน เรียงจากมีโครงสร้างมากที่สุดไปน้อยที่สุด:

• เหตุการณ์ GitHub: มีมาในตัว กรองได้ และตรวจสอบย้อนหลังได้ทั้งหมด
• ป้ายกำกับและแบบแผนการตั้งชื่อแบรนช์: กำหนดเส้นทางงานได้โดยไม่ต้องเขียนโค้ดเชื่อมต่อใด ๆ
• การเรียก API: จาก CI ระบบมอนิเตอร์ หรือเครื่องมือภายใน โดยถือว่า payload เป็นบริบทที่ไม่น่าเชื่อถือ
• ระบบติดตามงานหรือ artefact ที่ใช้ร่วมกัน: issue ใน Linear หรือหน้าสถานะที่การรันตามกำหนดเวลาครั้งถัดไปจะอ่าน

ออกแบบรูทีนร่วมอย่างระมัดระวัง ใช้ตัวกรองเพื่อไม่ให้ routine ทำงานจากผลลัพธ์ของตัวเอง เช่น ยกเว้นผู้เขียนหรือแบรนช์ที่ routine นั้นสร้างขึ้น คงขั้นตอน merge โดยมนุษย์ไว้ระหว่าง routine ที่เขียนโค้ดกับ routine ที่นำโค้ดขึ้นใช้งานจริงเสมอ และอย่าลืมว่าทุกขั้นตอนใช้เพดานการรันต่อวันระดับบัญชีและเพดานเหตุการณ์ GitHub ร่วมกัน หากคุณเริ่มสร้างตรรกะแบบแตกแขนง การลองใหม่ และการกระจายงานข้าม routine จำนวนมาก แสดงว่างานของคุณเกินขอบเขตของรูปแบบนี้แล้ว และเอนจินเวิร์กโฟลว์โดยเฉพาะจะเป็นเครื่องมือที่เหมาะกว่า

8. ความปลอดภัยและการกำกับดูแล

• routine ทำงานในนามของคุณ routine เป็นของบัญชี claude.ai ส่วนบุคคลและไม่ได้แชร์กับเพื่อนร่วมทีม คอมมิตและ pull request จะแสดงตัวตน GitHub ของคุณ และการกระทำผ่านคอนเนกเตอร์ใช้บัญชีที่คุณเชื่อมโยงไว้ ให้ปฏิบัติต่อ routine เหมือน personal access token ที่มีสมองติดมาด้วย
• การป้องกันแบรนช์ โดยค่าเริ่มต้น Claude จะพุชไปยังแบรนช์ที่ขึ้นต้นด้วย claude/ และจะปฏิเสธการพุชไปยังแบรนช์ที่ได้รับการป้องกัน แบรนช์ที่มี PR ของผู้อื่นเปิดอยู่ และแบรนช์ที่มีคอมมิตของผู้อื่น
• สิทธิ์น้อยที่สุดเท่าที่จำเป็น นำคอนเนกเตอร์ที่ไม่จำเป็นออก คงการเข้าถึงเครือข่ายไว้ที่ Trusted เว้นแต่ต้องใช้โดเมนเฉพาะ คำขอที่ถูกบล็อกจะล้มเหลวด้วย 403 และ x-deny-reason: host_not_allowed ในแพ็กเกจ Pro และ Max ให้เก็บ API key เป็น API credentials ของสภาพแวดล้อม แทนที่จะเป็นตัวแปรธรรมดาซึ่งทุกคนที่ใช้สภาพแวดล้อมนั้นมองเห็นได้
• อินพุตที่ไม่น่าเชื่อถือ payload ของ API และข้อความจาก Run now จะถูกระบุว่าไม่น่าเชื่อถือ เนื้อหาที่ดึงมาระหว่างการรัน เช่น เนื้อหาของ issue และหน้าเว็บ ยังคงได้รับการจัดการ prompt injection ตามปกติ เขียนพรอมต์ที่บอก Claude ว่าควรเชื่อถืออะไร
• สถานะการเชื่อมต่อ หากการเชื่อมต่อ GitHub หมดอายุ การรันจะถูกข้ามไปนานสูงสุด 72 ชั่วโมง จากนั้น routine จะปิดตัวเองจนกว่าคุณจะเชื่อมต่อใหม่
• การควบคุมระดับองค์กร Owner ของแพ็กเกจ Team และ Enterprise สามารถปิด Routines สำหรับสมาชิกทุกคนได้จากการตั้งค่าผู้ดูแลระบบ

9. แพ็กเกจ การใช้งาน และขีดจำกัด

Routines ใช้โควตาการสมัครสมาชิกในลักษณะเดียวกับเซสชันแบบโต้ตอบ และเพดานรายวันมีผลเพิ่มเติมจากนั้น โควตาปัจจุบันของคุณแสดงอยู่ที่ claude.ai/code/routines และอาจเปลี่ยนแปลงระหว่างช่วง preview หากเปิดใช้เครดิตการใช้งาน การรันที่เกินเพดานจะดำเนินต่อไปโดยคิดค่าใช้จ่ายส่วนเกินตามจริง หากไม่ได้เปิดใช้ การรันเพิ่มเติมจะถูกปฏิเสธจนกว่าช่วงเวลาจะรีเซ็ต การรันตามกำหนดเวลาแบบครั้งเดียวไม่นับรวมในเพดาน ระหว่างที่การสมัครสมาชิกถูกพักไว้ routine ของบัญชีนั้นจะถูกระงับเช่นกัน

10. เปรียบเทียบ Routines กับทางเลือกอื่นในการตั้งเวลา

10.1 ภายใน Claude Code

งาน /loop ผูกอยู่กับเซสชันและหมดอายุหลังเจ็ดวัน เหมาะอย่างยิ่งสำหรับคอยเฝ้าบิลด์หรือ pull request ขณะที่คุณทำงาน แต่ไม่สามารถใช้แทน routine ได้

10.2 นอก Claude Code

• GitHub Actions มีต้นทุนต่ำ อยู่ใกล้กับโค้ด และให้การควบคุม runner อย่างเต็มที่ แลกกับการต้องจัดการ YAML, secrets และการดูแล runner เลือก Actions สำหรับขั้นตอนบิลด์ที่ให้ผลแน่นอน และเลือก Routines สำหรับงานที่ต้องใช้วิจารณญาณ
• เอนจินเวิร์กโฟลว์ อย่าง Trigger.dev จัดการการลองใหม่ การกระจายงาน และการประสานงานระยะยาวได้ แต่คุณต้องเขียนการประสานงานนั้นเป็นโค้ดเอง ใช้เมื่อเวิร์กโฟลว์คือตัวผลิตภัณฑ์
• แพลตฟอร์มการเชื่อมต่อระบบ อย่าง n8n และ Zapier โดดเด่นในการย้ายข้อมูลระหว่างเครื่องมือ SaaS ส่วน Routines โดดเด่นในการใช้เหตุผลกับโค้ด ล็อก และเอกสาร ทั้งสองใช้ร่วมกันได้ดี เช่น โฟลว์ของ n8n สามารถเรียก API endpoint ของ routine ได้

11. กรณีการใช้งานที่ได้ผลดี

• จัดระเบียบ backlog: ติดป้ายกำกับและกำหนดผู้รับผิดชอบทุกคืน พร้อมสรุปในตอนเช้า
• คัดแยกการแจ้งเตือน: ระบบมอนิเตอร์เรียกทริกเกอร์ API แล้ว Claude เชื่อมโยง stack trace กับคอมมิตล่าสุด และเปิดดราฟต์การแก้ไข
• รีวิวโค้ดตามแบบของคุณ: ใช้เช็กลิสต์ของคุณเองกับทุก PR ที่พร้อมรีวิว
• ตรวจสอบการดีพลอย: smoke check และสแกนล็อกหลังการปล่อยเวอร์ชันแต่ละครั้ง ปิดท้ายด้วยผล go หรือ no-go
• เอกสารไม่ตรงกับโค้ด: สแกน PR ที่ merge แล้วทุกสัปดาห์ และเปิด PR อัปเดตเอกสารที่อ้างถึง API ที่เปลี่ยนไป
• พอร์ตไลบรารี: สะท้อนการเปลี่ยนแปลงที่ merge แล้วจาก SDK หนึ่งไปยัง SDK พี่น้องในอีกภาษาหนึ่ง
• สุขอนามัยของ dependency: ทบทวนแพ็กเกจที่ล้าสมัยทุกสัปดาห์ พร้อม PR อัปเกรดที่ทดสอบแล้วเพียงรายการเดียว

Routines ไม่ค่อยเหมาะกับงานที่ต้องทำบ่อยกว่าชั่วโมงละครั้ง งานที่ต้องให้มนุษย์ตัดสินใจระหว่างการรัน และเวิร์กโฟลว์ซับซ้อนที่มีหลายแขนงและต้องลองใหม่

12. เสียงตอบรับจากชุมชน

ปฏิกิริยามีทั้งสองด้าน แต่โดยรวมเป็นไปในทางบวก InfoQ อ้างถึงวิศวกรที่กระตือรือร้นกับการเชื่อม AI เข้ากับแดชบอร์ด observability และเวิร์กโฟลว์ CI โดยตรงผ่าน webhook ขณะที่บางส่วนยังคงสงสัย โดยชี้ถึงฟีเจอร์การตั้งเวลาของ Claude ก่อนหน้านี้ที่ทำงานได้เฉพาะบนเครื่องของผู้ใช้ และมองว่าความน่าเชื่อถือ uptime และขีดจำกัดโควตาควรได้รับความสนใจก่อนฟีเจอร์ใหม่ จากประสบการณ์ของเรา Routines ได้รับการออกแบบมาอย่างดีในด้านความปลอดภัย โดยเฉพาะการจัดการ payload ที่ไม่น่าเชื่อถือและการป้องกันแบรนช์ ความเสี่ยงหลักด้านการปฏิบัติงานคือการเปิดใช้คอนเนกเตอร์กว้างเกินไป และพรอมต์ที่ไม่เฉพาะเจาะจงพอ

13. Workstation ใช้งานสิ่งนี้อย่างไร

ที่ Workstation เราให้บริการระบบอัตโนมัติแบบเอเจนต์แก่ลูกค้าในด้าน DevOps การดำเนินงานด้านการเงิน และเวิร์กโฟลว์ลูกค้า Routines เข้ากับแนวทางของเราได้ดี นั่นคือ ใช้โครงสร้างพื้นฐานที่ให้ผลแน่นอนสำหรับระบบรองรับ ใช้ AI สำหรับงานที่ต้องใช้วิจารณญาณ และมีจุดอนุมัติโดยมนุษย์ก่อนที่สิ่งใดจะขึ้นสู่ production หากคุณต้องการความช่วยเหลือในการออกแบบห่วงโซ่ routine ไลบรารีซับเอเจนต์ หรือการกำกับดูแลที่เกี่ยวข้อง พูดคุยกับทีมของเรา

14. ประเด็นสำคัญ

• routine คือพรอมต์ รีโพสิทอรี สภาพแวดล้อม คอนเนกเตอร์ และทริกเกอร์ที่บันทึกไว้ ซึ่งรันอย่างอิสระบนคลาวด์
• ทริกเกอร์อาจเป็นกำหนดเวลา (ขั้นต่ำหนึ่งชั่วโมง ใช้เวลาท้องถิ่น) การเรียก API (bearer token, payload ที่ไม่น่าเชื่อถือ) หรือเหตุการณ์ pull request หรือ release บน GitHub
• ใช้ได้กับ Pro, Max, Team และ Enterprise โดยมีเพดานการรันต่อวันเพิ่มเติมจากการใช้งานปกติ ฟีเจอร์นี้ยังอยู่ในช่วง research preview
• ใช้รูทีนย่อย (ซับเอเจนต์และสกิล) เพื่อให้การรันที่ยาวนานครั้งเดียวยังคงโฟกัสและใช้สิทธิ์น้อยที่สุด
• ใช้รูทีนร่วม (routine ที่ส่งต่องานผ่าน PR ป้ายกำกับ และการเรียก API) สำหรับไปป์ไลน์หลายขั้นตอน โดยมีจุดให้มนุษย์อนุมัติการ merge อยู่ตรงกลาง
• จำกัดขอบเขตคอนเนกเตอร์และการเข้าถึงเครือข่ายอย่างเข้มงวด เขียนพรอมต์ให้เหมือนคู่มือปฏิบัติงาน และอ่านบันทึกการทำงาน

แหล่งที่มาและเอกสารอ่านเพิ่มเติม

• Anthropic: Introducing routines in Claude Code (14 เมษายน 2026)
• เอกสาร 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 อยู่ในช่วง research preview พฤติกรรม ขีดจำกัด และ API อาจเปลี่ยนแปลงได้ ข้อมูลในคู่มือนี้อ้างอิงจากเอกสารที่ Anthropic เผยแพร่ ณ วันที่ 25 กันยายน 2026