มีวลีหนึ่งที่กำลังเป็นที่พูดถึง ซึ่งสรุปทิศทางของการเขียนโค้ดแบบ Agentic ได้เป็นอย่างดี: เป้าหมายไม่ใช่พรอมต์ที่ดีขึ้น แต่เป็นเวิร์กโฟลว์ที่ทำงานได้เองโดยที่คุณไม่ต้องเฝ้าดู คนส่วนใหญ่ใช้ Claude เหมือนกับการใช้หน้าต่างแชท คุณพิมพ์ รอ อ่าน แล้วพิมพ์อีกครั้ง ซึ่งก็ใช้ได้ แต่จะจำกัดผลลัพธ์ของคุณไว้ที่เอเจนต์ตัวเดียวที่คุณต้องดูแลอย่างใกล้ชิด แต่วิศวกรที่ดึงศักยภาพที่แท้จริงจาก Claude ได้สร้างสิ่งอื่นขึ้นมา นั่นคือเวิร์กโฟลว์ที่เริ่มต้นตามกำหนดเวลาหรือทริกเกอร์ ทำงาน ตรวจสอบผลลัพธ์ของตัวเอง และจะแจ้งให้มนุษย์ทราบก็ต่อเมื่อมีบางสิ่งจำเป็นต้องตัดสินใจเท่านั้น
สรุปย่อ
เวิร์กโฟลว์ Claude ที่ทำงานได้เองโดยที่คุณไม่ต้องเฝ้าดูนั้นต้องการองค์ประกอบห้าส่วน: ข้อกำหนดที่แม่นยำ, การทำงานแบบ Headless (ไม่โต้ตอบ), เกตการตรวจสอบที่กำหนดผลลัพธ์ได้ซึ่งตัดสินว่าผ่านหรือไม่ผ่าน, มาตรการป้องกันที่เข้มงวด (รายการที่อนุญาต, จำนวนการทำซ้ำที่จำกัด, เพดานค่าใช้จ่าย, สวิตช์หยุดฉุกเฉิน), และการส่งมอบงานที่แจ้งเตือนมนุษย์หรือแจ้งเตือนเมื่อเกิดข้อผิดพลาด โหมด Headless ของ Claude Code (claude -p), Claude Agent SDK, Hooks และตัวกำหนดตารางเวลา (cron หรือ launchd) มอบองค์ประกอบทั้งห้าให้คุณ เอเจนต์ไม่ใช่ส่วนที่เสี่ยง แต่การปล่อยให้ทำงานโดยไม่มีเกตและมาตรการป้องกันต่างหากที่เสี่ยง สร้างสิ่งเหล่านี้ก่อน แล้วค่อยปล่อยให้มันทำงานเอง
ทำไม “การทำงานได้เอง” ถึงเป็นเป้าหมายที่แท้จริง
การแชทภายใต้การดูแลมีข้อจำกัดที่ชัดเจน: คุณ การทำซ้ำทุกครั้งต้องรอให้มนุษย์อ่านผลลัพธ์และตัดสินใจว่าจะทำอะไรต่อไป โมเดลสร้างผลลัพธ์ในไม่กี่วินาที จากนั้นก็จะหยุดทำงานเป็นนาทีในขณะที่คุณเปลี่ยนบริบท คุณคือคอขวดในระบบที่โดยปกติแล้วรวดเร็ว
เวิร์กโฟลว์ที่ทำงานเองได้จะขจัดข้อจำกัดนั้น เอเจนต์ทำงาน สคริปต์ตรวจสอบ หากเกิดข้อผิดพลาดจะถูกส่งกลับโดยอัตโนมัติ และคุณจะเข้ามาแทรกแซงเฉพาะจุดที่จำเป็นเท่านั้น ประโยชน์ที่ได้รับไม่ใช่แค่ความเร็วเท่านั้น แต่ยังรวมถึงการทำงานแบบขนาน เมื่อเวิร์กโฟลว์ทำงานได้โดยไม่ต้องมีการดูแล คุณสามารถเพิ่มขนาดได้โดยการเพิ่มเวิร์กโฟลว์ ไม่ใช่การพิมพ์ให้เร็วขึ้น นี่เป็นการก้าวกระโดดแบบเดียวกับที่เราเคยกล่าวถึงในบทความ เวิร์กโฟลว์แบบไดนามิกของ Claude Code ซึ่งเซสชันเดียวสามารถแตกแขนงออกเป็นเอเจนต์แบบขนานจำนวนมากได้
แต่ “การทำงานได้เอง” ก็เพิ่มความเสี่ยง เอเจนต์ที่ได้รับการดูแลซึ่งทำการแก้ไขที่ไม่ถูกต้องจะถูกจับได้เมื่อคุณอ่านความแตกต่าง แต่เอเจนต์ที่ทำงานเองได้จะคอมมิต (commit) การแก้ไขนั้น ทำงานในขั้นตอนต่อไป และดำเนินต่อไปเรื่อยๆ ดังนั้นระเบียบวินัยจึงเปลี่ยนจากการสร้างพรอมต์เป็นการออกแบบระบบ: คุณกำลังสร้างเครื่องจักรที่ต้องถูกต้อง มีขอบเขต และตรวจสอบได้เมื่อไม่มีใครเฝ้าดู บทความของ Anthropic เรื่อง การสร้างเอเจนต์ที่มีประสิทธิภาพ ก็ให้เหตุผลเดียวกัน ประโยชน์ที่แท้จริงมาจากสภาพแวดล้อมรอบโมเดล ไม่ใช่จากข้อความเดียวที่ฉลาดขึ้น
ห้าส่วนที่ทุกเวิร์กโฟลว์ที่ทำงานได้เองต้องการ
หากคุณข้ามส่วนใดส่วนหนึ่งไป เวิร์กโฟลว์จะทำสิ่งที่ผิดพลาดอย่างมั่นใจหรือไม่ก็ไม่หยุดทำงานเลย
- ข้อกำหนดที่แม่นยำ คำอธิบายที่เป็นลายลักษณ์อักษรของสิ่งที่ถือว่าเสร็จสิ้น ซึ่งเอเจนต์จะอ่านเมื่อเริ่มต้นการทำงานทุกครั้ง ข้อกำหนดที่คลุมเครือจะนำไปสู่งานที่คลุมเครือ "แก้ไข API" จะล้มเหลว; "เอนด์พอยต์ POST /orders ส่งคืน 201, ตรวจสอบ Body ตาม Schema, ปฏิเสธฟิลด์ที่ขาดหายไปด้วย 422" จะสำเร็จ
- การทำงานแบบ Headless Claude ต้องทำงานโดยไม่มีมนุษย์อยู่หน้าแป้นพิมพ์ นั่นหมายถึงโหมดไม่โต้ตอบ ไม่ใช่ UI แบบแชท
- เกตการตรวจสอบ การตรวจสอบที่กำหนดผลลัพธ์ได้ ซึ่งจะคืนค่าผ่านหรือไม่ผ่านพร้อมเหตุผลที่ชัดเจน: การทดสอบ, การตรวจสอบประเภท, การตรวจสอบ Schema, การทดสอบสัญญา นี่คือสิ่งที่ทำให้เวิร์กโฟลว์ตัดสินใจได้ว่างานนั้นเสร็จสมบูรณ์จริง ๆ แทนที่จะเชื่อคำพูดของโมเดล
- มาตรการป้องกัน (Guardrails) รายการที่อนุญาตสำหรับการเข้าถึง, จำนวนการทำซ้ำสูงสุด, เพดานค่าใช้จ่าย, การบันทึก และสวิตช์หยุดฉุกเฉิน สิ่งเหล่านี้ช่วยป้องกันไม่ให้การทำงานที่สับสนสร้างความเสียหายในขณะที่คุณหลับ
- การส่งมอบงาน (Handoff) เมื่อเวิร์กโฟลว์เสร็จสิ้นหรือล้มเหลว มันจะแจ้งให้ใครบางคนทราบ การแจ้งเตือน, ร่างสำหรับตรวจสอบ, การแจ้งเตือนข้อผิดพลาด ความเงียบไม่ใช่ความสำเร็จ
สามส่วนตรงกลางคือส่วนที่การตั้งค่าส่วนใหญ่ยังขาดอยู่ เรามาสร้างแต่ละส่วนด้วยเครื่องมือที่ Claude มอบให้คุณ
องค์ประกอบพื้นฐานของ Claude
โหมด Headless (claude -p)
โหมดพิมพ์ของ Claude Code จะรันพรอมต์แบบไม่โต้ตอบและออก การดำเนินการนี้เป็นรากฐานของทุกเวิร์กโฟลว์ที่ทำงานได้เอง คุณมอบหมายงาน จำกัดเครื่องมือ บันทึกผลลัพธ์ และดำเนินการต่อไป
claude -p "Implement the orders endpoint per spec.md, then run the test suite" \
--allowedTools "Edit,Write,Bash" \
--output-format json \
>> run.log 2>&1
แฟล็ก --allowedTools มีความสำคัญมากกว่าที่เห็น ใน UI การแชท คุณจะอนุมัติการกระทำแต่ละอย่างด้วยตนเอง ในโหมด Headless ไม่มีใครอนุมัติ ดังนั้นรายการที่อนุญาตคือการควบคุมเดียวของคุณต่อสิ่งที่เอเจนต์สามารถแตะต้องได้ เริ่มต้นด้วยการจำกัดขอบเขตและขยายออกไปเมื่อคุณเชื่อใจในการทำงานเท่านั้น ชุดแฟล็กทั้งหมดอยู่ใน เอกสารประกอบของ Claude Code
Claude Agent SDK
เมื่อคำสั่งเชลล์ไม่เพียงพอ Claude Agent SDK ช่วยให้คุณขับเคลื่อน Claude ด้วยโปรแกรมจาก Python หรือ TypeScript คุณจะได้รับลูปในโค้ด: ส่งงาน, สตรีมผลลัพธ์, ตรวจสอบการเรียกใช้เครื่องมือ, ตัดสินใจว่าจะดำเนินการต่อหรือไม่ นี่คือวิธีการที่คุณจะควบคุมกระแสการทำงานของเอเจนต์อย่างแท้จริง
import { query } from "@anthropic-ai/claude-agent-sdk";
const MAX_ITERATIONS = 8;
let feedback = "";
for (let attempt = 0; attempt < MAX_ITERATIONS; attempt++) {
for await (const msg of query({
prompt: `${task}\n\nPrevious failures:\n${feedback}`,
options: { allowedTools: ["Edit", "Write", "Bash"] },
})) {
// stream/log messages as the agent works
}
const gate = runVerification(); // การตรวจสอบที่กำหนดผลลัพธ์ได้ของคุณ
if (gate.passed) break; // เสร็จสิ้น
feedback = gate.failures; // พรอมต์ถัดไปจะเขียนขึ้นเอง
}
ลายเซ็นที่แน่นอนอยู่ในเอกสาร แต่รูปร่างเป็นประเด็นสำคัญ: ลูปที่รันเอเจนต์ซ้ำพร้อมกับความล้มเหลวครั้งล่าสุดเป็นพรอมต์ถัดไป หากคุณกำลังตัดสินใจระหว่างการสร้างลูปของคุณเองกับตัวเลือกที่โฮสต์ไว้ การเปรียบเทียบระหว่าง เอเจนต์ที่จัดการโดยระบบเทียบกับ Agent SDK ของเราจะอธิบายว่าแต่ละแบบเหมาะสมเมื่อใด
Hooks สำหรับมาตรการป้องกันที่กำหนดผลลัพธ์ได้
Hooks จะรันคำสั่งของคุณเองที่จุดคงที่ในวงจรชีวิตของ Claude โดยไม่มีโมเดลเข้ามาเกี่ยวข้อง เป็นวิธีการที่คุณใช้บังคับกฎที่เอเจนต์ไม่สามารถหลีกเลี่ยงได้ ต้องการให้ชุดทดสอบรันหลังจากการแก้ไขไฟล์ทุกครั้งหรือไม่? Hook PostToolUse สามารถทำได้แบบกำหนดผลลัพธ์ได้
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [{ "type": "command", "command": "npm test --silent" }]
}
]
}
}
เนื่องจาก hook เป็นโค้ดธรรมดา ไม่ใช่คำขอไปยังโมเดล มันจึงทำงานเสมอ นี่คือคุณสมบัติที่คุณต้องการสำหรับมาตรการป้องกันในการทำงานที่ไม่มีการดูแล เอเจนต์ไม่สามารถตัดสินใจที่จะข้ามมันไปได้
ตัวกำหนดตารางเวลาเพื่อเรียกใช้งาน
เวิร์กโฟลว์ที่ทำงานได้เองโดยที่คุณไม่ต้องเฝ้าดูจำเป็นต้องมีบางสิ่งบางอย่างที่จะเริ่มต้นมันโดยที่คุณไม่ต้องทำอะไรเอง บนเซิร์ฟเวอร์คือ cron; บน Mac คือ launchd ไม่ว่าจะด้วยวิธีใด คุณกำลังเรียกใช้คำสั่ง Headless ตามกำหนดเวลา
# ทุกวันธรรมดาเวลา 7 โมงเช้า: รันเวิร์กโฟลว์การบำรุงรักษา, บันทึกทุกอย่าง
0 7 * * 1-5 cd /srv/api && claude -p "$(cat tasks/nightly-maintenance.md)" \
--allowedTools "Edit,Bash" >> logs/run-$(date +\%F).log 2>&1
นั่นคือกระดูกสันหลังทั้งหมดของการตั้งค่าแบบอัตโนมัติ: ตัวกำหนดตารางเวลาจะเรียกใช้ Claude แบบ Headless, เอเจนต์ทำงานตามข้อกำหนด, Hooks และเกตช่วยให้มันซื่อสัตย์, และบันทึกจะบอกคุณว่าเกิดอะไรขึ้น
ออกแบบลูป ไม่ใช่พรอมต์
นี่คือกรอบความคิดที่เชื่อมโยงทุกสิ่งเข้าด้วยกัน หยุดถามว่า "ฉันควรบอกอะไร Claude?" เริ่มถามว่า "ลูปแบบไหนที่จะทำให้ Claude บอกตัวเอง?" เอเจนต์เป็นตัวสร้างที่รวดเร็วแต่ไม่มีความน่าเชื่อถือว่าสิ่งที่มันทำนั้นถูกต้องหรือไม่ ลูปจะมอบความรู้สึกนั้นผ่านเกต เราได้เจาะลึกเรื่องนี้ในบทความ หยุดสั่งพรอมต์เอเจนต์โค้ดดิ้งของคุณ แต่สร้างลูปแทน และนี่คือแนวคิดหลักสำหรับการทำงานที่ไม่มีการดูแล: ความมั่นใจของโมเดลไม่สำคัญอีกต่อไป มีเพียงคำตัดสินของเกตเท่านั้นที่สำคัญ
นี่คือเหตุผลว่าทำไมข้อกำหนดที่ชัดเจนจึงดีกว่าพรอมต์ที่ชาญฉลาด ข้อกำหนดเดียวกันนี้จะขับเคลื่อนการทำซ้ำทุกครั้งและยังเป็นเอกสารประกอบอีกด้วย ไฟล์ design.md หรือ AGENTS.md ที่รวบรวมเจตนา ข้อจำกัด และคำนิยามของสิ่งที่ถือว่าเสร็จสิ้น จะให้เป้าหมายที่มั่นคงแก่เอเจนต์ในการทำงานทุกครั้ง แทนที่จะให้คุณต้องอธิบายบริบทใหม่ทุกครั้ง
ตัวอย่างการใช้งานจริง: การบำรุงรักษา API แบบอัตโนมัติ
ทำให้เป็นรูปธรรม สมมติว่าคุณต้องการเวิร์กโฟลว์ที่รักษาสถานะของเอนด์พอยต์ API ให้ซิงค์กับ OpenAPI spec ของมัน ทำงานทุกเช้า และไม่เคยปล่อยเอนด์พอยต์ที่เสียออกไป นี่คือโครงสร้าง
- ข้อกำหนด (Spec) สัญญาอยู่ในไฟล์ OpenAPI; พฤติกรรมอยู่ใน Test Case เอเจนต์จะอ่านทั้งสองเมื่อเริ่มต้นการทำงาน
- ทริกเกอร์ (Trigger) งาน cron เวลา 7 โมงเช้าจะเรียกใช้ Claude แบบ Headless พร้อมกับงานบำรุงรักษา
- สร้าง (Generate) เอเจนต์จะทำการปรับปรุงการใช้งานให้สอดคล้องกับข้อกำหนด: เพิ่มเอนด์พอยต์ที่ขาดหายไป, แก้ไขรูปแบบการตอบสนองที่ไม่ตรงกัน, เพิ่มความเข้มงวดในการตรวจสอบ
- เกต (Gate) เวิร์กโฟลว์จะรันชุดทดสอบ API กับบริการที่กำลังทำงานอยู่ การยืนยันสถานะ, การตรวจสอบ JSON Schema บนทุกการตอบสนอง, การตรวจสอบสัญญาเทียบกับข้อกำหนด หากเกิดข้อผิดพลาดจะถูกส่งกลับมาเป็นโครงสร้าง: "คาดหวัง 422 เมื่อ
customer_idหายไป, ได้รับ 500" "ฟิลด์totalในการตอบสนองเป็นสตริง, แต่ Schema ระบุว่าเป็นตัวเลข" - วนซ้ำหรือแจ้งเตือน (Loop or escalate) เกตแดงหรือไม่? ข้อผิดพลาดที่มีโครงสร้างจะกลายเป็นพรอมต์ถัดไปและเอเจนต์จะแก้ไขช่องว่างนั้นโดยเฉพาะ จนกว่าจะถึงขีดจำกัดการวนซ้ำ เกตเขียว? มันจะเปิด Pull Request (PR) ฉบับร่าง หากหมดความพยายาม? มันจะบันทึกการแจ้งเตือนพร้อมกับความล้มเหลวครั้งล่าสุดและหยุดทำงาน
- การส่งมอบงาน (Handoff) มนุษย์จะได้รับ PR ที่สะอาดเพื่อตรวจสอบ หรือรายงานข้อผิดพลาดที่แม่นยำ จะไม่มีการคอมมิตโดยเงียบ
เกตในขั้นตอนที่ 4 คือสิ่งที่ทำให้ทั้งหมดนี้ปลอดภัยที่จะทำงานได้โดยไม่มีการดูแล หากไม่มีเกตนี้ เอเจนต์จะแก้ไขโค้ดและรายงานความสำเร็จตามการอ่านของตัวเอง ซึ่งเป็นวิธีเดียวกับที่เอนด์พอยต์ที่เสียไปถึงการผลิต นี่คือจุดที่ Apidog เข้ามาช่วยในเวิร์กโฟลว์อัตโนมัติ: การออกแบบ API, Schema, Mock Server และการทดสอบอัตโนมัติทั้งหมดอยู่ในพื้นที่ทำงานเดียวกัน ดังนั้นเกตและข้อกำหนดจึงซิงค์กันโดยค่าเริ่มต้น คุณชี้การทำงานไปยังสถานการณ์ทดสอบของ Apidog และเอเจนต์จะได้รับการตรวจสอบ Schema ว่าผ่าน/ไม่ผ่านในการวนซ้ำทุกครั้ง Mock Server ทำหน้าที่แทนการพึ่งพาที่ยังไม่พร้อมใช้งาน ดังนั้นการทำงานตอนตี 3 จะไม่ถูกบล็อกโดยรอบุคคลที่สามที่ไม่เสถียร ทีมที่เชื่อมต่อการเข้าถึงเอนด์พอยต์ของเอเจนต์ผ่าน Apidog AI agent debugger จะช่วยให้มันเข้าถึงและตรวจสอบเอนด์พอยต์ในลักษณะเดียวกับที่ผู้ทดสอบที่เป็นมนุษย์จะทำ ดาวน์โหลด Apidog หากคุณต้องการสร้างเกตด้วยภาพมากกว่าการสร้างตัวรันด้วยตนเอง

มาตรการป้องกันที่ทำให้การทำงานได้เองปลอดภัย
นี่คือส่วนที่แยกเวิร์กโฟลว์ที่คุณไว้วางใจให้ทำงานข้ามคืนออกจากเวิร์กโฟลว์ที่ปลุกคุณตอนตี 3 เอเจนต์ที่ไม่มีการดูแลจำเป็นต้องมีขีดจำกัดที่เข้มงวด ไม่ใช่แค่เจตนาที่ดี
- รายการที่อนุญาต (Permission allowlists) แบบจำกัดวง ในโหมด Headless รายการที่อนุญาตคือเกตเดียวของคุณสำหรับสิ่งที่เอเจนต์สามารถทำได้ ให้สิทธิ์เครื่องมือขั้นต่ำที่งานต้องการเท่านั้น อย่าให้สิทธิ์การเข้าถึง Shell หรือคำสั่งที่ทำลายข้อมูลโดยไม่จำกัดแก่การทำงานที่ไม่มีการดูแล โดยไม่มีแซนด์บ็อกซ์
- จำนวนการวนซ้ำที่จำกัด (Bounded iterations) กำหนดขีดจำกัดของลูป การทำงานที่ไม่สามารถไปถึงเกตเขียวได้ภายใน N ครั้ง ควรหยุดและแจ้งเตือน ไม่ใช่ทำงานต่อไปไม่รู้จบ
- เพดานค่าใช้จ่าย (A cost ceiling) ลูปที่ทำงานเองจะใช้โทเค็นโดยที่มนุษย์ไม่ทันสังเกต กำหนดขีดจำกัดการใช้จ่ายและบันทึกการใช้จ่ายต่อการทำงาน ลูปที่ไม่ลู่เข้าควรชนขีดจำกัดและหยุดทำงาน บันทึกของเราเกี่ยวกับ การลดต้นทุนโทเค็นของเอเจนต์ สามารถนำมาปรับใช้ได้โดยตรงที่นี่
- ปกป้องเกต (Protect the gate) เก็บไฟล์ทดสอบและข้อกำหนดออกไปจากชุดไฟล์ที่เอเจนต์อาจแก้ไข หากมันสามารถเขียนการทดสอบใหม่เพื่อให้ผ่านได้ คุณก็ได้สร้างเครื่องจักรสำหรับการหลอกลวงความก้าวหน้า
- แซนด์บ็อกซ์ (A sandbox) รันงานที่ไม่มีการดูแลในพื้นที่ทำงานที่แยกต่างหากหรือในคอนเทนเนอร์ ไม่ใช่ในส่วนหลัก git worktree หรือ branch ที่ใช้แล้วทิ้งจะช่วยจำกัดรัศมีผลกระทบของการทำงานที่ไม่ดี
- การบันทึกและสวิตช์หยุดฉุกเฉิน (Logging and a kill switch) บันทึกการทำงานทุกครั้งลงในบันทึกที่คุณอ่านจริง และมีวิธีหยุดงานกลางคัน คุณไม่สามารถดีบักสิ่งที่คุณไม่ได้บันทึกไว้ได้
- การอนุมัติโดยมนุษย์ที่ขอบ (Human approval at the edges) “การทำงานได้เอง” ไม่ได้หมายความว่า “ไม่มีใครเลยตลอดไป” ให้มนุษย์อยู่ที่จุดเริ่มต้น (อนุมัติงาน) หรือจุดสิ้นสุด (อนุมัติ PR) ไม่ใช่ในลูปภายใน รูปแบบการเชื่อมต่อและโหมดความล้มเหลวที่นี่สอดคล้องกับ รูปแบบการเชื่อมต่อเครื่องมือเวิร์กโฟลว์แบบ Agentic และข้อผิดพลาด
ส่วนใหญ่แล้วสิ่งเหล่านี้สรุปได้เป็นกฎเดียว: เอเจนต์ที่ไม่มีการดูแลควรจะสามารถทำงานของมันได้เท่านั้นและไม่ทำอะไรอย่างอื่น จำกัดเครื่องมือ, กำหนดขอบเขตของลูป, แยกพื้นที่ทำงาน, และทำให้การทำงานทุกครั้งสามารถสังเกตการณ์ได้
ข้อผิดพลาดที่พบบ่อย
รูปแบบบางอย่างทำให้เวิร์กโฟลว์อัตโนมัติล่มเหลวอย่างรวดเร็ว
- ไม่มีเกต มีแต่ความรู้สึก หากการตรวจสอบเดียวคือ “เอเจนต์ คุณเสร็จหรือยัง?” คุณไม่มีเวิร์กโฟลว์ แต่คุณมีแชทบอทที่ไม่มีการดูแล เกตจะต้องอยู่ภายนอกเอเจนต์
- งานเดียวขนาดใหญ่ การทำงานที่ได้รับคำสั่งให้ “บำรุงรักษาบริการทั้งหมด” มักจะไม่ลู่เข้า แบ่งงานออกเป็นงานขนาดเอนด์พอยต์ แต่ละงานมีเกตของตัวเอง งานเล็กๆ จะเสร็จสมบูรณ์; งานใหญ่ๆ จะล้มเหลว
- สิทธิ์ที่เปิดกว้างเกินไป การให้สิทธิ์เครื่องมือทุกอย่างเพราะสะดวก จะทำให้ข้อผิดพลาดเล็กๆ กลายเป็นเหตุการณ์ใหญ่เมื่อไม่มีใครเฝ้าดู กำหนดรายการที่อนุญาตอย่างเข้มงวด
- ความสำเร็จแบบเงียบๆ หรือความล้มเหลวแบบเงียบๆ เวิร์กโฟลว์ที่คอมมิตโดยไม่บอกใคร หรือล่มโดยไม่มีการแจ้งเตือน แย่กว่าการไม่มีเวิร์กโฟลว์เสมอ ต้องมีการส่งมอบงานเสมอ
- เชื่อรายงานของโมเดลเอง เอเจนต์จะบอกว่ามันเสร็จแล้ว แต่เกตจะตัดสินว่าเสร็จจริงหรือไม่ สร้างสิ่งเหล่านี้เพื่อช่องว่างระหว่าง “ดูเหมือนเสร็จ” และ “เสร็จจริง” เพราะเมื่อทำงานโดยไม่มีการดูแล ไม่มีใครคอยจับตาดู
หากคุณทำสิ่งเหล่านี้ได้อย่างถูกต้อง เวิร์กโฟลว์ของ Claude ก็สามารถทำงานที่จำกัดและได้รับการตรวจสอบได้เท่ากับงานหนึ่งวันก่อนที่คุณจะดื่มกาแฟ แต่หากทำผิดพลาด คุณก็ได้ทำให้การผลิตโค้ดที่มั่นใจแต่ไม่ได้รับการทดสอบเป็นแบบอัตโนมัติ ความแตกต่างอยู่ที่เกตและมาตรการป้องกัน ไม่ใช่โมเดล หากคุณต้องการสถาปัตยกรรมที่ลึกซึ้งยิ่งขึ้น การวิเคราะห์ของเราเกี่ยวกับ การออกแบบ Agent Harness จะครอบคลุมว่าองค์ประกอบต่างๆ ทำงานร่วมกันอย่างไรในขนาดใหญ่
ประเด็นสำคัญ
การสร้างเวิร์กโฟลว์ Claude ที่ทำงานได้เองโดยที่คุณไม่ต้องเฝ้าดูนั้น ไม่ได้เกี่ยวกับ Claude มากนัก แต่เกี่ยวกับระบบที่คุณสร้างขึ้นรอบๆ มัน องค์ประกอบห้าส่วนมีความสำคัญ: ข้อกำหนดที่แม่นยำ, การทำงานแบบ Headless, เกตการตรวจสอบที่กำหนดผลลัพธ์ได้, มาตรการป้องกันที่เข้มงวด และการส่งมอบงานที่ชัดเจน หากทำสิ่งเหล่านี้ได้อย่างถูกต้อง โมเดลก็จะกลายเป็นผู้ทำงานที่รวดเร็วภายในเครื่องจักรที่ถูกต้อง มีขอบเขต และตรวจสอบได้เมื่อคุณไม่ได้เฝ้าดู
เริ่มต้นด้วยเวิร์กโฟลว์เดียว เขียนข้อกำหนดที่เข้มงวด รันแบบ Headless เทียบกับเกตการตรวจสอบที่รวดเร็ว อนุญาตเครื่องมือที่จำเป็นเท่านั้น จำกัดจำนวนการวนซ้ำ แยกพื้นที่ทำงาน และให้มันแจ้งเตือนคุณเมื่อเสร็จสิ้นหรือล้มเหลว สำหรับสิ่งใดๆ ที่เกี่ยวข้องกับ API ชุดทดสอบของคุณคือเกตที่ทำให้การทำงานที่ไม่มีการดูแลปลอดภัย และ Apidog มอบการออกแบบ, การจำลอง (mocking) และการทดสอบอัตโนมัติในพื้นที่ทำงานเดียวเพื่อสร้างมันขึ้นมา ดาวน์โหลดเลย เชื่อมต่อเกต และปล่อยให้เวิร์กโฟลว์ทำงานไปในขณะที่คุณทำสิ่งอื่น
