คู่มือปฏิบัติเกี่ยวกับ 3 ชั้นที่ผู้คนมักสับสน
คนส่วนใหญ่พูดถึง AI Agents ราวกับว่ามันเป็นสิ่งเดียวกัน
แต่จริงๆ แล้วไม่ใช่
เมื่อ Agent ก้าวไปไกลกว่าแค่ของเล่นสาธิต และเริ่มแตะต้องไฟล์, API, เอกสาร, ลูกค้า หรือโค้ดในระบบจริง คุณไม่ได้แค่ "ป้อน Prompt ให้โมเดล" อีกต่อไป
คุณกำลังออกแบบระบบ
และในระบบนั้น มี 3 แนวคิดที่ถูกนำมาปนกันอยู่เสมอ:
- วิศวกรรม Harness (Agent Harness Engineering)
- วิศวกรรม Loop (Loop Engineering)
- วิศวกรรม Graph (Graph Engineering)
ทั้งสามทำงานรอบโมเดลเดียวกัน
ทั้งหมดส่งผลต่อความน่าเชื่อถือ
และใช่ ทั้งสามสามารถมีลูปได้
แต่มันแก้ ปัญหาที่แตกต่างกัน
ถ้าคุณสับสนระหว่างมัน คุณจะลงไปดีบักเลเยอร์ที่ผิด
คำตอบแบบ 30 วินาที
นี่คือเวอร์ชันที่ชัดเจน:
- วิศวกรรม Harness สร้างสภาพแวดล้อมรอบโมเดล
- วิศวกรรม Loop ออกแบบวงจรการทำงานและการรับฟีดแบ็คซ้ำๆ
- วิศวกรรม Graph ทำให้โครงสร้างเวิร์กโฟลว์ชัดเจน
โมเดลความคิดที่ดีคือ:
สภาพแวดล้อม → ฟีดแบ็ค → โฟลว์
- Harness มอบเครื่องมือ, หน่วยความจำ, การควบคุม และพื้นที่ทำงานให้โมเดล
- Loop ตัดสินใจว่างานจะถูกลองใหม่, ตรวจสอบ และปรับปรุงอย่างไร
- Graph กำหนดว่าขั้นตอนใดที่อนุญาตให้เกิดขึ้นต่อไป
นั่นคือความแตกต่าง
ทำไมคำศัพท์เหล่านี้ถึงสำคัญในตอนนี้
โมเดลเปล่าๆ ไม่สามารถทำงานจริงได้ด้วยตัวเอง
มันไม่สามารถ:
- รักษาสถานะของโปรเจกต์ข้ามเซสชัน
- เรียกใช้เครื่องมืออย่างปลอดภัย
- ตรวจสอบเบราว์เซอร์
- บังคับใช้สิทธิ์
- ลองทำงานที่ล้มเหลวอีกครั้ง
- ตรวจสอบคุณภาพของผลลัพธ์
- จัดเส้นทางงานไปยังผู้เชี่ยวชาญเฉพาะทาง
- หยุดในช่วงเวลาที่เหมาะสม
ทั้งหมดนั้นมาจากระบบรอบๆ ตัวมัน
เมื่อซอฟต์แวร์แบบ Agentic เติบโตขึ้น สแต็กที่ใช้งานได้จริงก็กำลังเกิดขึ้น:
- Harness ให้สภาพแวดล้อมการทำงานแก่โมเดล
- Loops ทำให้งานทำซ้ำได้และตรวจสอบได้
- Graph ทำให้เวิร์กโฟลว์ที่ซับซ้อนชัดเจนและควบคุมได้
เมื่อคุณมองเห็นสิ่งเหล่านี้เป็นเลเยอร์ที่แยกจากกัน ความสับสนมากมายเกี่ยวกับสถาปัตยกรรม AI ก็จะหายไป
Harness ที่จริงจังมักมีอะไรบ้าง
- การฉีดบริบท (Context Injection)
สิ่งที่โมเดลเห็นก่อนที่จะลงมือทำ:
- คำแนะนำ
- ความรู้ที่ดึงมา
- สถานะการสนทนา
- หน่วยความจำ
- นโยบาย
- กฎเฉพาะงาน
- พื้นผิวการกระทำ (Action Surfaces)
สิ่งที่โมเดลสามารถทำได้:
- การเรียก API
- การกระทำในเบราว์เซอร์
- คำสั่ง Shell
- การรันโค้ด
- เครื่องมือ MCP
- ฐานข้อมูล
- ฟังก์ชันที่กำหนดเอง
- ความคงทน (Persistence)
สิ่งที่อยู่รอดข้ามเวลา:
- ไฟล์
- จุดบันทึก (Checkpoints)
- สถานะเซสชัน
- บันทึกความคืบหน้า
- ประวัติ Git
- หน่วยความจำระยะยาว
- การควบคุมการทำงาน (Execution Control)
วิธีจัดการการรัน:
- การลองใหม่
- การหมดเวลา
- งบประมาณ
- การเลือกโมเดล
- การสร้าง Sub-agent
- ประตูอนุมัติ
- ความปลอดภัยและการกำกับดูแล (Safety And Governance)
สิ่งที่ทำให้ระบบปลอดภัย:
- สิทธิ์ระดับต่ำสุดที่จำเป็น
- การแยกส่วน
- รายการอนุญาต
- การจัดการความลับ
- การอนุมัติจากมนุษย์
- การสังเกตการณ์ (Observability)
สิ่งที่ช่วยให้คุณดีบักได้:
- ร่องรอย (Traces)
- อินพุตและเอาต์พุตของเครื่องมือ
- การเปลี่ยนสถานะ
- ความหน่วง
- ต้นทุน
- ผลลัพธ์การประเมิน
ทำไมวิศวกรรม Harness ถึงสำคัญ
สองทีมสามารถใช้โมเดลเดียวกันและได้ผลลัพธ์ที่แตกต่างกันโดยสิ้นเชิง
ทำไม?
เพราะทีมหนึ่งมอบสิ่งเหล่านี้ให้โมเดล:
- เครื่องมือที่สะอาด
- สถานะที่เสถียร
- หน่วยความจำที่มีโครงสร้าง
- สิทธิ์ที่ชัดเจน
- การทำงานที่สังเกตได้
และอีกทีมมอบให้:
- Prompt ที่คลุมเครือ
- เครื่องมือที่ยุ่งเหยิง
- บริบทที่มีสัญญาณรบกวน
- ไม่มีหน่วยความจำ
- ไม่มีการตรวจสอบ
โมเดลอาจเหมือนกัน
แต่สภาพการทำงานไม่เหมือนกัน
วิศวกรรม Harness มีความสำคัญเมื่อ Agent:
- ไม่สามารถเข้าถึงความสามารถที่ถูกต้อง
- สูญเสียบริบทระหว่างเซสชัน
- ทำงานไม่สอดคล้องกันข้ามสภาพแวดล้อม
- ไม่สามารถตรวจสอบได้
- มีสิทธิ์มากเกินไป
- ไม่สามารถกู้คืนได้อย่างสะอาดหลังจากการหยุดชะงัก
ถ้าโมเดลไม่สามารถทำงานได้อย่างน่าเชื่อถือ สิ่งแรกที่ต้องดูคือ Harness
2. วิศวกรรม Loop
มันคืออะไร
Agent ที่ใช้เครื่องมือทุกตัวมีลูปในตัวเล็กๆ อยู่แล้ว:
- เรียกโมเดล
- สังเกตผลลัพธ์
- รันเครื่องมือ
- ป้อนการสังเกตกลับไป
- ทำซ้ำจนเสร็จ
วิศวกรรม Loop เริ่มต้นเมื่อคุณ จงใจออกแบบวงจรเพิ่มเติม รอบพฤติกรรมนั้น
ไม่ใช่แค่ "ถามอีกครั้ง"
ไม่ใช่แค่ "ลองใหม่"
แต่เป็นระบบการทำงานและฟีดแบ็คที่แท้จริง
กายวิภาคของ Loop ที่ดี
ตัวกระตุ้น (Trigger)
อะไรเป็นจุดเริ่มต้นของรอบใหม่?
- คำขอผู้ใช้
- การทดสอบที่ล้มเหลว
- เอกสารใหม่
- การรันตามกำหนดการ
- Webhook
- ฟีดแบ็คจากผู้ประเมิน
เป้าหมาย (Goal)
เงื่อนไขเฉพาะใดที่เราพยายามจะบรรลุ?
ไม่ใช่ "ทำให้ดีขึ้นเรื่อยๆ"
แต่เป็นเป้าหมายที่แท้จริง
สถานะ (State)
รอบถัดไปจำเป็นต้องรู้อะไรบ้าง?
- ฉบับร่างปัจจุบัน
- ความพยายามครั้งก่อน
- ผลลัพธ์ของเครื่องมือ
- ข้อผิดพลาด
- สถานะความคืบหน้า
นโยบายการดำเนินการ (Action Policy)
Agent ได้รับอนุญาตให้ทำอะไร?
- แก้ไข
- มอบหมาย
- เรียกเครื่องมือ
- ใช้โทเค็น
- เขียนไฟล์
- เปิด Pull Request
หลักฐาน (Evidence)
เราจะรู้ได้อย่างไรว่ามันได้ผล?
- การทดสอบ
- การตรวจสอบ Schema
- การอ้างอิง
- ความแตกต่าง (Diffs)
- เมตริก
- การอนุมัติจากผู้ตรวจสอบ
ฟีดแบ็ค (Feedback)
อะไรที่ล้มเหลวกันแน่?
ฟีดแบ็คควรกระชับและนำไปปฏิบัติได้
กฎการหยุด (Stop Rule)
เมื่อไรมันจะจบ?
- สำเร็จ
- หมดเวลา
- งบประมาณหมด
- ถึงจำนวนลองสูงสุด
- ความล้มเหลวที่กู้คืนไม่ได้
- การส่งต่อให้มนุษย์
หลักการสำคัญที่สุดในวิศวกรรม Loop
**อย่า Loop บนความมั่นใจ
ให้ Loop บนหลักฐาน**
"Agent บอกว่ามันเสร็จแล้ว" ไม่ใช่เงื่อนไขการหยุด
เงื่อนไขการหยุดที่แท้จริงมีลักษณะเช่น:
- การทดสอบผ่าน
- Schema ตรวจสอบผ่าน
- การอ้างอิงแก้ไขได้
- ผู้ตรวจสอบอนุมัติ
- การตรวจสอบนโยบายสะอาด
นั่นคือวิศวกรรม Loop
ทำไมวิศวกรรม Loop ถึงไม่ใช่แค่วิศวกรรม Prompt
Prompt บอกโมเดลว่าต้องทำอะไร ระหว่างการเรียก
Loop กำหนดว่าระบบทำอะไร หลังจากการเรียก
ซึ่งรวมถึง:
- วิธีตรวจสอบผลลัพธ์
- วิธีตอบสนองต่อความล้มเหลว
- วิธีรักษาความคืบหน้า
- วิธีตัดสินใจว่าจะดำเนินการต่อหรือไม่
- วิธียุติ
การ Prompt ช่วยปรับปรุงการตอบสนอง
Loop ช่วยปรับปรุงกระบวนการ
นั่นเป็นปัญหาทางวิศวกรรมที่แตกต่างกันมาก
3. วิศวกรรม Graph
มันคืออะไร
วิศวกรรม Graph ทำให้โครงสร้างเวิร์กโฟลว์ชัดเจน
มันตอบคำถามที่แตกต่าง:
ไม่ใช่แค่ "Agent ควรทำอะไร?" แต่ "อะไรที่อนุญาตให้เกิดขึ้นต่อไป?"
ในวิศวกรรม Graph:
- ขั้นตอนคือ โหนด (Nodes)
- การเปลี่ยนผ่านคือ ขอบ (Edges)
- การแตกกิ่งชัดเจน
- การทำงานแบบขนานชัดเจน
- การรวมกลับชัดเจน
- การลองใหม่ชัดเจน
- การแทรกแซงของมนุษย์ชัดเจน
Graph กลายเป็นแผนที่ควบคุมของระบบ
สิ่งที่วิศวกร Graph ออกแบบจริงๆ
ขอบเขตของโหนด (Node Boundaries)
สิ่งใดควรอยู่ใน:
- ฟังก์ชันที่กำหนดตายตัว
- การเรียก LLM
- Agent ผู้เชี่ยวชาญ
- ขั้นตอนการตรวจสอบโดยมนุษย์
Schema ของสถานะ (State Schema)
แต่ละโหนดสามารถอ่านหรือเขียนอะไรได้บ้าง
เงื่อนไขการจัดเส้นทาง (Routing Conditions)
หลักฐานใดที่ย้ายงาน:
- ไปข้างหน้า
- ถอยหลัง
- ไปด้านข้าง
- ไปสู่การส่งต่อ
การทำงานพร้อมกัน (Concurrency)
อะไรที่สามารถรันแบบขนานได้ และอะไรต้องรอ
วงจรและการออก (Cycles And Exits)
อนุญาตให้ลองใหม่ที่ไหน, อนุญาตกี่ครั้ง, และหยุดอย่างไร
ความทนทาน (Durability)
จุดบันทึกเกิดขึ้นที่ไหน และเวิร์กโฟลว์กลับมาทำงานต่ออย่างไรหลังจากการหยุดชะงัก
เมื่อไหร่ที่ Graph คุ้มค่า
Graph มีประโยชน์เมื่อกระบวนการมี:
- การแตกกิ่งที่มีความหมาย
- การอนุมัติ
- การส่งต่อผู้เชี่ยวชาญ
- งานแบบขนาน
- เส้นทางการกู้คืน
- เวิร์กโฟลว์หลายขั้นตอนที่มีจุดควบคุมที่ชัดเจน
มันมีประโยชน์น้อยกว่าเมื่องานเป็นเพียง:
"ให้ Agent หนึ่งตัวมีเครื่องมือสองสามอย่างแล้วปล่อยให้มันทำงาน"
ในกรณีนั้น Harness ที่แข็งแกร่งบวกกับ Loop สองสามอันอาจเพียงพอ
Graph เพิ่มความชัดเจน แต่มันก็เพิ่มโครงสร้างด้วย
โครงสร้างที่มากเกินไปเร็วเกินไปอาจทำให้ระบบเปราะบาง
3 ชั้นทำงานร่วมกันอย่างไร
สมมติว่าคุณกำลังสร้าง Agent สำหรับการวิจัยและเผยแพร่
มันต้อง:
- กำหนดขอบเขตหัวข้อ
- รวบรวมแหล่งข้อมูล
- คัดกรองการอ้างอิง
- ร่างรายงาน
- ผ่านการตรวจสอบทางกฎหมาย
- เผยแพร่หลังจากการอนุมัติเท่านั้น
นี่คือวิธีการแมปชั้นต่างๆ:
Harness
จัดหา:
- การเข้าถึงเบราว์เซอร์
- เครื่องมือค้นหา
- พื้นที่ทำงานไฟล์
- หน่วยความจำ
- การอ้างอิง
- การอนุมัติ
- ร่องรอย
- การจัดเส้นทางโมเดล
Loop
จัดการ:
- การลองดึงแหล่งข้อมูลใหม่เมื่อหลักฐานอ่อนแอ
- การแก้ไขข้อผิดพลาดในการอ้างอิง
- การรันตรวจสอบเกรด
- การรีเฟรชงานเมื่อตลาดเปลี่ยน
Graph
ควบคุมเส้นทาง:
- การกำหนดขอบเขต
- การวิจัย
- การคัดกรอง
- การสังเคราะห์
- การร่าง
- การตรวจสอบ
- การเผยแพร่
โดยมีประตูมนุษย์ก่อนการเผยแพร่
นั่นคือเหตุผลที่ 3 ชั้นนี้ไม่สามารถใช้แทนกันได้
มันทำงานร่วมกัน แต่มันไม่ใช่สิ่งเดียวกัน
วินิจฉัยความล้มเหลวก่อนที่คุณจะเลือกวิธีแก้ไข
นี่คือกฎที่ใช้งานได้จริง:
ถ้า Agent ไม่สามารถทำงานได้ ให้แก้ไข Harness
ตัวอย่าง:
- ขาดการเข้าถึงเครื่องมือ
- สถานะที่ล้าสมัย
- หน่วยความจำที่อ่อนแอ
- สิทธิ์ที่ไม่ดี
- ไม่มีการสังเกตการณ์
ถ้า Agent เกือบจะทำงานได้แต่ไม่น่าเชื่อถือ ให้แก้ไข Loop
ตัวอย่าง:
- ฉบับร่างแรกใกล้เคียงแต่อ่อนแอ
- ความสำเร็จไม่สม่ำเสมอ
- การลองใหม่ไม่มีการควบคุม
- ไม่มีหลักฐานการเสร็จสิ้น
ถ้ากระบวนการมีความซับซ้อน ให้แก้ไข Graph
ตัวอย่าง:
- ผู้เชี่ยวชาญหลายคน
- การอนุมัติ
- ตรรกะการแตกกิ่ง
- เส้นทางขนาน
- การส่งต่อที่มีโครงสร้าง
ข้อผิดพลาดทั่วไป
1. สร้าง Graph เร็วเกินไป
ทีมงานมักจะวาดไดอะแกรมเวิร์กโฟลว์ขนาดใหญ่ก่อนที่จะเห็นว่าการทำงานจริงๆ เป็นอย่างไร
วิธีที่ดีกว่า:
- เริ่มต้นด้วย Harness ที่เรียบง่ายกว่า
- เก็บรวบรวมร่องรอย
- ค้นหารูปแบบที่เสถียร
- ทำให้เป็นทางการเฉพาะสิ่งที่สมควรได้รับการควบคุม
2. ปล่อยให้โมเดลเดียวกันเขียนและให้คะแนนโดยไม่มีการป้องกัน
การตรวจสอบตนเองสามารถช่วยได้ แต่มันก็มีจุดบอดร่วมกัน
ควรเลือกใช้:
- การตรวจสอบแบบกำหนดตายตัวเมื่อเป็นไปได้
- บริบทของผู้ตรวจสอบแยกต่างหาก
- ผู้ประเมินภายนอก
- การอนุมัติจากมนุษย์สำหรับการกระทำที่มีผลกระทบสูง
3. ใช้ "ลองต่อไป" เป็น Loop
นั่นไม่ใช่การออกแบบ Loop
นั่นคือการรั่วไหลของต้นทุนที่ไม่มีการควบคุม
ทุก Loop ต้องการ:
- เป้าหมายที่วัดได้
- หลักฐานจริง
- ข้อจำกัดในการลองใหม่
- กฎการส่งต่อ
4. ปฏิบัติต่อ Harness เหมือนลิ้นชักเก็บของ
เครื่องมือที่มากขึ้นไม่ได้หมายถึง Agent ที่ดีกว่าโดยอัตโนมัติ
เครื่องมือที่มากเกินไปสร้าง:
- ความผิดพลาดในการเลือก
- บริบทที่มีสัญญาณรบกวน
- ความน่าเชื่อถือที่อ่อนแอ
- พื้นผิวความเสี่ยงที่กว้างขึ้น
Harness ที่ดีไม่ใช่สิ่งที่รก
มันแม่นยำ
5. โทษโมเดลสำหรับความล้มเหลวในการจัดระเบียบ
โมเดลไม่สามารถชดเชยให้กับ:
- API ที่เสีย
- สถานะที่ล้าสมัย
- เงื่อนไขการออกที่ขาดหายไป
- Schema เครื่องมือที่คลุมเครือ
- โหมดความล้มเหลวที่มองไม่เห็น
แก้ไขเลเยอร์ที่เป็นเจ้าของความล้มเหลวนั้น
รายการตรวจสอบสำหรับการผลิตแบบง่ายๆ
Harness
- เครื่องมือมีขอบเขตแคบและมีเอกสารหรือไม่?
- สถานะคงทนหรือไม่?
- สิทธิ์เป็นระดับต่ำสุดที่จำเป็นหรือไม่?
- ผู้ปฏิบัติงานสามารถหยุด, ตรวจสอบ และดำเนินการต่อได้หรือไม่?
- ร่องรอยมองเห็นได้หรือไม่?
Loop
- หลักฐานใดพิสูจน์ความสำเร็จ?
- ฟีดแบ็คใดที่ส่งกลับเมื่อล้มเหลว?
- อนุญาตให้ลองใหม่กี่ครั้ง?
- กฎการหยุดคืออะไร?
- จะเกิดอะไรขึ้นเมื่องบประมาณหมด?
Graph
- เส้นทางใดที่ต้องกำหนดตายตัว?
- อะไรที่สามารถรันแบบขนานได้?
- ประตูมนุษย์อยู่ที่ไหน?
- สถานะใดที่แชร์กัน?
- เส้นทางการกู้คืนเริ่มต้นที่ไหน?
การประเมิน
- คุณสามารถเล่นร่องรอยจริงซ้ำได้หรือไม่?
- คุณสามารถเปรียบเทียบเวอร์ชันได้หรือไม่?
- คุณสามารถระบุได้ว่าการปรับปรุงมาจากการเปลี่ยนแปลงจริงหรือไม่?
การปฏิบัติการ
- คุณกำลังติดตามต้นทุนหรือไม่?
- ความหน่วง?
- อัตราความล้มเหลว?
- อัตราการแทรกแซง?
- ความสำเร็จของงานในระบบจริง?
วิธีที่ง่ายที่สุดในการจำความแตกต่าง
ถ้าคุณจำได้เพียงสิ่งเดียว ให้จำสิ่งนี้:
- วิศวกรรม Harness ทำให้โมเดลพร้อมทำงาน
- วิศวกรรม Loop ทำให้งานเป็นแบบวนซ้ำและตรวจสอบได้
- วิศวกรรม Graph ทำให้เส้นทางการดำเนินการชัดเจนและควบคุมได้
ไม่มีอะไรแทนที่สิ่งอื่นได้
Graph ที่สมบูรณ์แบบจะไม่ช่วย Harness ที่อ่อนแอ
Harness ที่แข็งแกร่งก็ยังคงเสียเงินโดยเปล่าประโยชน์ถ้าไม่มี Loop ที่ดี
และ Loop ที่สะอาดก็กลายเป็นเรื่องยากที่จะจัดการเมื่อการแตกกิ่งและการอนุมัติยังคงซ่อนอยู่ในโค้ดเฉพาะกิจ
ระบบ Agent ที่น่าเชื่อถือจะปรากฏขึ้นเมื่อทั้ง 3 ชั้นถูกออกแบบอย่างตั้งใจ
นั่นคือสแต็กสถาปัตยกรรมที่แท้จริง
ข้อคิดสุดท้าย
ผู้คนยังคงพูดถึง AI Agents ราวกับว่าการก้าวกระโดดครั้งสำคัญคือโมเดล
ในระบบจริง นั่นแทบจะไม่ใช่ตัวสร้างความแตกต่างที่แท้จริง
ตัวสร้างความแตกต่างคือระบบรอบๆ โมเดล:
- Harness ที่ทำให้มันทำงานได้
- Loops ที่ทำให้มันปรับปรุงได้
- Graph ที่ทำให้มันทำงานภายใต้การควบคุมได้
นั่นคือวิธีที่ Agent ของเล่นกลายเป็นระบบจริง
ถ้าคุณอ่านมาถึงตรงนี้:
- BOOKMARK หน้านี้ไว้
- ติดตาม @LunarResearcher
- ติดตาม Substack ของฉัน
- ติดตาม ช่อง Telegram ส่วนตัว ของฉัน
