Harness Engineering: คู่มือฉบับสมบูรณ์สำหรับการสร้าง AI Agents ที่ไม่พังง่าย

คนส่วนใหญ่กำลังพยายามปรับปรุง AI agent ผิดชั้น

เมื่อ agent ล้มเหลว พวกเขาเขียน prompt ใหม่

เมื่อมันล้มเหลวอีก พวกเขาเพิ่มคำแนะนำเพิ่ม

ก่อนที่เราจะเริ่ม:

ติดตาม Substack ของฉันเพื่อรับข้อมูล AI ใหม่ล่าสุด เวิร์กโฟลว์ agent และคำแนะนำทีละขั้นตอนก่อนที่จะลง X: [https://substack.com/@lunarresearcher

จากนั้นพวกเขาก็เปลี่ยนโมเดล เพิ่มเครื่องมือมากขึ้น ขยายหน้าต่างบริบท และหวังว่าการทำงานครั้งต่อไปจะแตกต่างออกไป

แต่ความล้มเหลวของ agent หลายครั้งไม่ใช่ความล้มเหลวในการใช้เหตุผล

มันคือความล้มเหลวของสภาพแวดล้อม

agent ไม่รู้ว่าไฟล์ไหนสำคัญ

มันใช้เครื่องมือที่ถูกต้องในที่ผิด

มันสูญเสียการตัดสินใจที่ทำในเซสชันก่อนหน้า

มันอ้างว่าสำเร็จโดยไม่ต้องตรวจสอบ

มันทำซ้ำการกระทำหลังจากความล้มเหลวบางส่วน

มันมีสิทธิ์ที่จะทำบางสิ่งที่ควรต้องได้รับการอนุมัติ

โมเดลไม่จำเป็นต้องเป็นปัญหาเสมอไป ระบบรอบๆ โมเดลนั้นไม่สมบูรณ์

ระบบนั้นคือ harness

และการออกแบบมันกำลังกลายเป็นสาขาวิศวกรรมของตัวเอง

Harness Engineering คือการปฏิบัติในการสร้างสภาพแวดล้อมที่เปลี่ยนความฉลาดของโมเดลให้เป็นงานที่เชื่อถือได้

prompt เปลี่ยนความพยายามครั้งเดียว

harness เปลี่ยนทุกความพยายาม

คู่มือนี้จะอธิบายวิธีสร้าง harness

1. โมเดลไม่ใช่ Agent

โมเดลสามารถใช้เหตุผล สร้าง เปรียบเทียบ และเลือกได้

แต่ agent ต้องโต้ตอบกับสภาพแวดล้อมจริงด้วย

มันจำเป็นต้อง:

• เข้าใจงาน
• ค้นหาบริบทที่เกี่ยวข้อง
• เลือกและใช้เครื่องมือ
• รักษาสถานะ
• เคารพสิทธิ์
• ตรวจสอบผลลัพธ์
• กู้คืนจากความล้มเหลว
• พิสูจน์ว่างานเสร็จสมบูรณ์

โมเดลคือเครื่องยนต์ในการใช้เหตุผลภายในระบบนั้น

harness คือทุกสิ่งที่ทำให้การใช้เหตุผลนั้นทำงานได้จริง

1คำขอของผู้ใช้
2     |
3     v
4+-----------------------------+
5|           HARNESS           |
6| สัญญา | บริบท | นโยบาย      |
7| เครื่องมือ | สถานะ | การตรวจสอบ |
8| ร่องรอย | การกู้คืน          |
9+-----------------------------+
10     |
11     v
12    โมเดล
13     |
14     v
15สภาพแวดล้อมจริง

โมเดลที่ทรงพลังใน harness ที่อ่อนแอก็ยังเป็น agent ที่อ่อนแอ

มันอาจสร้างการตอบสนองเฉพาะบุคคลที่น่าประทับใจ แต่มันจะทำงานไม่สอดคล้องกันในงานที่ยาวนาน สภาพแวดล้อมที่เปลี่ยนแปลง และความล้มเหลวบางส่วน

เป้าหมายของวิศวกรรม harness ไม่ใช่เพื่อขจัดความไม่แน่นอนออกจากโมเดล

แต่เพื่อกักเก็บความไม่แน่นอนนั้นไว้ภายในระบบที่สามารถสังเกต ตรวจสอบ และกู้คืนได้

2. เริ่มต้นด้วยสัญญางาน (Task Contract)

งาน agent ส่วนใหญ่เริ่มต้นจากความตั้งใจที่คลุมเครือ:

ปรับปรุงขั้นตอนการเริ่มต้นใช้งาน (onboarding flow)

ประโยคนั้นอาจเพียงพอสำหรับการสนทนา

แต่มันไม่เพียงพอสำหรับการทำงานอัตโนมัติ

ก่อนที่ agent จะลงมือทำ harness ควรแปลงคำขอเป็นสัญญางาน

สัญญาที่มีประโยชน์ตอบคำถามห้าข้อ:

1. ผลลัพธ์ใดที่ต้องมี?
2. อะไรอยู่ในขอบเขต?
3. อะไรที่ต้องไม่เปลี่ยนแปลง?
4. หลักฐานใดที่พิสูจน์ความสำเร็จ?
5. การกระทำใดที่ต้องได้รับการอนุมัติจากมนุษย์?

1วัตถุประสงค์: ลดการออกกลางคันระหว่างการเริ่มต้นใช้งาน (onboarding drop-off)
2
3ขอบเขต:
4  - ขั้นตอนการสมัคร (signup flow)
5  - การวิเคราะห์การเริ่มต้นใช้งาน (onboarding analytics)
6
7ข้อจำกัด:
8  - ห้ามเปลี่ยนการยืนยันตัวตน (authentication)
9  - รักษาพฤติกรรมของมือถือที่มีอยู่
10
11เกณฑ์การยอมรับ:
12  - การทดสอบผ่าน
13  - เหตุการณ์การวิเคราะห์ถูกส่งออก
14  - ภาพหน้าจอครอบคลุมทั้งเดสก์ท็อปและมือถือ
15
16ต้องได้รับการอนุมัติ:
17  - การปรับใช้ในระบบผลิต (production deployment)
18  - การย้ายฐานข้อมูล (database migration)

สิ่งนี้เปลี่ยนคำถามของ agent จาก:

ฉันควรทำอะไรต่อไป?

เป็น:

การกระทำใดที่ทำให้สภาพแวดล้อมเคลื่อนไปสู่ผลลัพธ์ตามสัญญา?

หากไม่มีสัญญา agent จะปรับให้เหมาะสมกับกิจกรรมที่ดูเป็นไปได้

เมื่อมีสัญญา มันสามารถปรับให้เหมาะสมกับการดำเนินการที่ได้รับการตรวจสอบแล้ว

3. ให้แผนที่ (Map) แก่ Agent ไม่ใช่คู่มือ (Manual)

การทิ้ง repository ทั้งหมด ชุดเอกสาร และประวัติการสนทนาลงในบริบทไม่ใช่การออกแบบบริบทที่ดี

มันคือการท่วมบริบท (context flooding)

harness ควรให้แผนที่ขนาดเล็กก่อน จากนั้นให้ agent ดึงรายละเอียดเมื่อมันเกี่ยวข้อง

1แผนที่โครงการ (PROJECT MAP)
2
3กฎของผลิตภัณฑ์     -> docs/product/
4สถาปัตยกรรม      -> docs/architecture.md
5ส่วนหน้า (frontend)          -> apps/web/
6ส่วนหลัง (backend)           -> services/api/
7การทดสอบ             -> tests/
8คำสั่ง          -> docs/commands.md
9กฎการเผยแพร่     -> docs/release.md

นี่คือการเปิดเผยแบบก้าวหน้า (progressive disclosure):

1งาน
2  -> แผนที่โครงการ
3      -> ระบบย่อยที่เกี่ยวข้อง
4          -> ไฟล์ที่แน่นอน
5              -> คำแนะนำในพื้นที่

บริบทควรขยายเพราะงานต้องการ ไม่ใช่เพราะข้อมูลมีอยู่

คอมไพเลอร์บริบทที่ดีจะตัดสินใจ:

• สิ่งใดที่จำเป็นเสมอ
• สิ่งใดที่สามารถดึงมาใช้ทีหลังได้
• สิ่งใดที่ล้าสมัยแล้ว
• สิ่งใดที่สามารถสรุปได้
• สิ่งใดที่ต้องคงไว้ตามตัวอักษร

วัตถุประสงค์ไม่ใช่บริบทสูงสุด

มันคือสัญญาณสูงสุดต่อ token

4. สร้างประตูเครื่องมือ (Tool Gateway) ไม่ใช่กองเครื่องมือ (Tool Pile)

การให้เครื่องมือยี่สิบอย่างแก่ agent ไม่ได้ทำให้มันมีความสามารถ

มันทำให้ agent มีวิธีทำผิดถึงยี่สิบวิธี

ทุกเครื่องมือควรมีสัญญาที่ชัดเจน:

1เครื่องมือ: edit_file
2
3อินพุต:
4  path
5  patch
6
7เงื่อนไขเบื้องต้น:
8  path มีอยู่
9  path อยู่ในพื้นที่ทำงานที่อนุญาต
10
11หลักฐานความสำเร็จ:
12  patch ถูกนำไปใช้
13  diff ที่ได้ถูกส่งคืน
14
15พฤติกรรมเมื่อล้มเหลว:
16  ไม่มีการเขียนทับบางส่วน
17  ข้อผิดพลาดที่มีโครงสร้างถูกส่งคืน
18
19ระดับความเสี่ยง:
20  ย้อนกลับได้

harness ควรควบคุมว่าเครื่องมือถูกเปิดเผยและใช้งานอย่างไร

มันสามารถ:

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

สิ่งนี้สร้างการแยกที่สำคัญ:

1โมเดลตัดสินใจเจตนา
2เกตเวย์ตรวจสอบการกระทำ
3เครื่องมือเปลี่ยนสภาพแวดล้อม
4เซ็นเซอร์สังเกตผลลัพธ์

โมเดลสามารถเสนอการกระทำได้

เกตเวย์เครื่องมือตัดสินใจว่าการกระทำนั้นถูกต้องพอที่จะดำเนินการหรือไม่

5. แยกสมอง (Brain) มือ (Hands) และประวัติ (History)

agent ที่เปราะบางจำนวนมากผสมทุกอย่างไว้ในบันทึกการสนทนาที่เพิ่มขึ้นเรื่อยๆ

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

ระบบที่แข็งแกร่งกว่าจะแยกความรับผิดชอบสามอย่าง:

1สมอง (BRAIN)
2วางแผน ใช้เหตุผล เลือก
3
4มือ (HANDS)
5ดำเนินการเครื่องมือภายในสภาพแวดล้อมที่ควบคุม
6
7ประวัติ (HISTORY)
8เก็บข้อเท็จจริงที่คงทน การตัดสินใจ และสถานะการทำงาน

โมเดลไม่จำเป็นต้องมีทุกเหตุการณ์ดิบในบริบทที่ใช้งานอยู่

มันต้องการสถานะปัจจุบันที่ถูกต้อง

sandbox ไม่จำเป็นต้องเข้าใจวัตถุประสงค์ทั้งหมด

มันจำเป็นต้องดำเนินการที่มีขอบเขตอย่างปลอดภัย

บันทึกเซสชันไม่จำเป็นต้องใช้เหตุผล

มันจำเป็นต้องรักษาสิ่งที่เกิดขึ้นหลังจากบริบทปัจจุบันหายไป

การแยกนี้ทำให้ agent ที่ทำงานยาวนานง่ายต่อการดำเนินการต่อ ตรวจสอบ และซ่อมแซม

มันยังช่วยให้คุณเปลี่ยนส่วนหนึ่งส่วนใดได้โดยไม่ต้องสร้างระบบทั้งหมดใหม่

6. หน่วยความจำต้องกลายเป็นสถานะที่คงทน (Durable State)

ประวัติการสนทนาไม่ใช่หน่วยความจำที่เชื่อถือได้

มันคือสตรีมเหตุการณ์

หน่วยความจำที่มีประโยชน์ควรถูกแปลงเป็นสถานะที่ชัดเจน

อย่างน้อย ให้รักษาสี่หมวดหมู่:

1ข้อเท็จจริง (FACTS)
2ข้อมูลที่มั่นคงที่ค้นพบเกี่ยวกับสภาพแวดล้อม
3
4การตัดสินใจ (DECISIONS)
5ตัวเลือกที่ทำและเหตุผลเบื้องหลัง
6
7ความคืบหน้า (PROGRESS)
8งานที่เสร็จสมบูรณ์ กำลังดำเนินการ ถูกบล็อก และที่เหลืออยู่
9
10บทเรียน (LESSONS)
11ความล้มเหลวที่ควรเปลี่ยนพฤติกรรมในอนาคต

ตัวอย่างเช่น:

1ข้อเท็จจริง:
2  - การตรวจสอบการชำระเงิน (checkout validation) อยู่ใน services/orders
3
4การตัดสินใจ:
5  - ใช้ไปป์ไลน์การตรวจสอบที่มีอยู่แล้ว
6  - เหตุผล: หลีกเลี่ยงแหล่งความจริงที่สอง
7
8ความคืบหน้า:
9  เสร็จสมบูรณ์:
10    - เพิ่มกฎฝั่งเซิร์ฟเวอร์
11  เหลืออยู่:
12    - อัปเดตการทดสอบแบบบูรณาการ (integration test)
13
14บทเรียน:
15  - คำสั่งทดสอบในเครื่องต้องการ TEST_DB_URL

สิ่งนี้มีประโยชน์มากกว่าการเล่นบันทึกการสนทนาห้าสิบหน้าและหวังว่าโมเดลจะสังเกตเห็นบรรทัดสำคัญ

เก็บประวัติดิบไว้สำหรับการตรวจสอบ

รวบรวมสถานะที่คงทนสำหรับการดำเนินการ

7. ความสำเร็จต้องมีหลักฐาน (Evidence)

agent ที่พูดว่า "เสร็จแล้ว" ไม่ใช่หลักฐานว่างานเสร็จ

มันเป็นเพียงเอาต์พุตของโมเดลอีกอันหนึ่ง

ความสำเร็จต้องถูกตัดสินโดยการเปลี่ยนแปลงที่สังเกตได้ในสภาพแวดล้อม

1การอ้างสิทธิ์                         หลักฐาน
2--------------------------------------------------
3"บั๊กได้รับการแก้ไขแล้ว"            การทดสอบที่ล้มเหลวตอนนี้ผ่านแล้ว
4"หน้าเว็บทำงานได้"              ขั้นตอนการทำงานของเบราว์เซอร์เสร็จสมบูรณ์
5"การย้ายข้อมูลปลอดภัย"       dry run และ rollback ผ่าน
6"รายงานถูกต้อง"              ค่าต่างๆ ตรงกับข้อมูลต้นทาง
7"งานเสร็จสมบูรณ์"                การตรวจสอบการยอมรับทุกข้อผ่าน

harness ควรรันการตรวจสอบเชิงกำหนดที่ถูกที่สุดก่อน

1ไวยากรณ์
2  -> ชนิดข้อมูล
3      -> การทดสอบแบบเจาะจง
4          -> การทดสอบแบบบูรณาการ
5              -> การตรวจสอบด้วยภาพหรือความหมาย
6                  -> การอนุมัติจากมนุษย์

อย่าใช้โมเดลอื่นในที่ที่คอมไพเลอร์ สคีมา เช็คซัม คิวรี หรือการทดสอบสามารถตอบคำถามได้

ใช้โมเดลสำหรับความคลุมเครือ

ใช้โค้ดสำหรับงานระบบ (plumbing)

โมเดลสามารถเสนอว่างานเสร็จสมบูรณ์แล้ว

มีเพียงสภาพแวดล้อมเท่านั้นที่สามารถพิสูจน์ได้

8. การตรวจสอบควรโจมตีผลลัพธ์

ผู้ปฏิบัติงาน (worker) และผู้ประเมิน (evaluator) ไม่ควรมีวัตถุประสงค์เดียวกัน

ผู้ปฏิบัติงานพยายามสร้างโซลูชันที่แข็งแกร่งที่สุด

ผู้ประเมินพยายามหาเหตุผลที่ควรปฏิเสธมัน

1ผู้ปฏิบัติงาน
2  -> สร้างผลงาน (candidate)
3
4ผู้ตรวจสอบ (verifier)
5  -> ตรวจสอบสัญญา
6  -> ค้นหากรณีที่ขาดหายไป
7  -> ทดสอบการอ้างสิทธิ์ที่ไม่ได้รับการสนับสนุน
8  -> พยายามทำลายผลลัพธ์
9
10รอดชีวิต
11  -> ยอมรับ
12
13ล้มเหลว
14  -> ส่งคืนหลักฐานที่ตรงเป้าหมาย

ความไม่สมมาตรนี้มีความสำคัญ

หากคุณถาม agent เดียวกัน ในบริบทเดียวกัน ให้ "ตรวจสอบงานของมันอีกครั้ง" มันมักจะรักษาสมมติฐานที่สร้างข้อผิดพลาดนั้นไว้

ขั้นตอนการตรวจสอบที่มีประโยชน์ควรมี:

• เกณฑ์การปฏิเสธที่ชัดเจน
• การเข้าถึงสิ่งประดิษฐ์ที่ผลิตขึ้น
• การเข้าถึงสัญญาการยอมรับ
• เครื่องมืออิสระหรือบริบทใหม่เมื่อจำเป็น
• สิทธิ์ในการปฏิเสธโดยไม่ต้องซ่อมแซม

การตรวจสอบไม่ใช่ความคิดเห็นที่สอง

มันคือความพยายามที่จะพิสูจน์ว่าผิด

9. โมเดลเสนอ นโยบายอนุญาต

กฎบางอย่างไม่ควรขึ้นอยู่กับว่าโมเดลจำมันได้หรือไม่

1ห้ามเผยแพร่โดยไม่ได้รับการอนุมัติ
2ห้ามเปิดเผยความลับ
3ห้ามเขียนนอกพื้นที่ทำงาน
4ห้ามเกินวงเงินใช้จ่าย
5ห้ามทำเครื่องหมายการทดสอบว่าผ่านเว้นแต่จะรันแล้ว

สิ่งเหล่านี้ไม่ใช่คำแนะนำใน prompt

มันคือนโยบาย

การออกแบบที่ปลอดภัยที่สุดคือนโยบายที่อยู่นอกวงจรการใช้เหตุผล

1ความเสี่ยงต่ำ (LOW RISK)
2อ่านไฟล์ ค้นหา ตรวจสอบ
3-> อัตโนมัติ
4
5การเปลี่ยนแปลงที่ย้อนกลับได้ (REVERSIBLE CHANGE)
6แก้ไขพื้นที่ทำงาน รันการทดสอบ
7-> อัตโนมัติพร้อมร่องรอย
8
9ผลกระทบภายนอก (EXTERNAL EFFECT)
10ส่งข้อความ ปรับใช้ ซื้อ
11-> ต้องได้รับการอนุมัติอย่างชัดแจ้ง
12
13ไม่สามารถย้อนกลับได้หรือละเอียดอ่อน (IRREVERSIBLE OR SENSITIVE)
14ลบข้อมูล หมุนเวียนข้อมูลรับรอง เผยแพร่ทั่วโลก
15-> ประตูที่แข็งหรือห้าม

ยิ่งผลที่ตามมารุนแรงเท่าไหร่ ประตูก็ยิ่งแข็งแกร่งเท่านั้น

ความเป็นอิสระไม่ใช่การไม่มีข้อจำกัด

มันคือความสามารถในการทำงานอย่างอิสระภายในขอบเขตที่บังคับใช้อย่างชัดเจน

10. การกู้คืนควรมุ่งเป้าไปที่คลาสความล้มเหลว

กลยุทธ์การกู้คืนที่พบบ่อยที่สุดคือ:

มีบางอย่างล้มเหลว ลองอีกครั้ง

นั่นไม่ใช่การกู้คืน

มันคือการทำซ้ำ

harness ควรจำแนกความล้มเหลวก่อนที่จะเลือกการกระทำถัดไป

1เครื่องมือหมดเวลา
2-> ลองใหม่พร้อม backoff
3
4อาร์กิวเมนต์ไม่ถูกต้อง
5-> ซ่อมแซมการเรียกใช้เครื่องมือ
6
7บริบทขาดหายไป
8-> ดึงแหล่งข้อมูลเฉพาะ
9
10การทดสอบล้มเหลว
11-> ตรวจสอบพฤติกรรมที่ล้มเหลว
12
13สิทธิ์ถูกปฏิเสธ
14-> ขออนุมัติหรือเลือกเส้นทางที่ปลอดภัย
15
16ข้อกำหนดที่ขัดแย้งกัน
17-> ส่งต่อให้มนุษย์
18
19ความล้มเหลวซ้ำซากไม่เปลี่ยนแปลง
20-> หยุดวงจร

การลองใหม่ควรเปลี่ยนเงื่อนไขที่เกี่ยวข้องอย่างน้อยหนึ่งอย่าง

มิฉะนั้นระบบกำลังจ่ายเงินเพื่อสร้างความล้มเหลวเดียวกันซ้ำ

ลูป agent ที่มีขอบเขตมีลักษณะดังนี้:

1สังเกต
2  -> ตัดสินใจ
3      -> ลงมือทำ
4          -> วัดผล
5              -> ยอมรับ
6              -> ซ่อมแซม
7              -> ส่งต่อ
8              -> หยุด

ทุกลูปต้องการงบประมาณ:

• ความพยายามสูงสุด
• เวลาสูงสุด
• การใช้จ่ายสูงสุด
• ขอบเขตการทำลายล้างสูงสุด
• เงื่อนไขการส่งต่อ

agent ที่เชื่อถือได้รู้วิธีดำเนินการต่อ

พวกเขายังรู้ด้วยว่าเมื่อใดที่การดำเนินการต่อนั้นไม่สมเหตุสมผลอีกต่อไป

11. คำแนะนำควรกลายเป็นโครงสร้างพื้นฐาน (Infrastructure)

คำแนะนำของ agent มีประโยชน์เมื่อมันอธิบายความเป็นจริงในพื้นที่

แต่คำแนะนำเพียงอย่างเดียวคือการบังคับใช้ที่อ่อนแอ

หากกฎมีความสำคัญซ้ำๆ ให้ย้ายมันลงไปในสแต็ก

1"ใช้ฟอร์แมตเตอร์"
2-> รันฟอร์แมตเตอร์โดยอัตโนมัติ
3
4"ห้ามนำเข้าข้ามเลเยอร์"
5-> เพิ่มการทดสอบสถาปัตยกรรม
6
7"รวมการย้อนกลับการย้ายข้อมูล"
8-> กำหนดให้มีไฟล์ rollback ใน CI
9
10"ห้ามแก้ไขไฟล์ที่สร้างขึ้น"
11-> บล็อกการเขียนไปยังพาธที่สร้างขึ้น
12
13"อ้างอิงทุกข้อความภายนอก"
14-> ตรวจสอบความครอบคลุมของการอ้างอิง

สิ่งนี้สร้างบันไดคำแนะนำ:

1คำอธิบาย
2  -> รายการตรวจสอบ
3      -> เทมเพลต
4          -> การตรวจสอบอัตโนมัติ
5              -> นโยบายที่บังคับใช้

ย้ายความรู้ที่สำคัญลงไปตามบันไดนั้นให้มากที่สุดเท่าที่จะทำได้

prompt ควรอธิบายการตัดสิน

harness ควรบังคับใช้ค่าคงที่ (invariants)

12. สังเกตการทำงาน ไม่ใช่แค่คำตอบสุดท้าย

สิ่งประดิษฐ์สุดท้ายที่สะอาดสามารถซ่อนกระบวนการที่แย่มากได้

agent อาจ:

• เข้าถึงข้อมูลผิด
• ไม่สนใจคำสั่งที่ล้มเหลว
• ลองการกระทำภายนอกซ้ำสองครั้ง
• ใช้งบประมาณที่คาดไว้ถึงสิบเท่า
• ได้คำตอบที่ถูกต้องด้วยเหตุผลที่ผิด

คุณต้องการร่องรอยที่ทำให้การทำงานสามารถสร้างขึ้นใหม่ได้

109:14  สัญญาถูกสร้าง
209:15  แหล่งบริบทถูกโหลด: architecture.md
309:17  ไฟล์ถูกแก้ไข: checkout.ts
409:18  การทดสอบแบบเจาะจงล้มเหลว: คูปองซ้ำ
509:21  การใช้งานได้รับการซ่อมแซม
609:22  การทดสอบแบบเจาะจงผ่าน
709:24  การทดสอบแบบบูรณาการผ่าน
809:25  การปรับใช้ภายนอกถูกบล็อก: ต้องได้รับการอนุมัติ

ร่องรอยที่มีประโยชน์บันทึก:

• การเปลี่ยนสถานะ
• แหล่งบริบท
• อินพุตและเอาต์พุตของเครื่องมือ
• การเปลี่ยนแปลงสภาพแวดล้อม
• ผลการตรวจสอบ
• เหตุผลในการลองใหม่
• การตัดสินใจอนุมัติ
• ต้นทุนและความหน่วง

เป้าหมายไม่ใช่การเฝ้าระวัง

เป้าหมายคือการซ่อมแซมในพื้นที่

เมื่อการทำงานล้มเหลวที่ขั้นตอนที่ 18 คุณควรจะสามารถเริ่มต้นใหม่จากจุดตรวจสอบที่เชื่อถือได้แทนที่จะเล่นงานทั้งหมดซ้ำ

13. ทุกการทำงานต้องการใบเสร็จการเปลี่ยนแปลง (Change Receipt)

บันทึก agent ที่ยาวนั้นยากต่อการตรวจสอบ

เมื่อสิ้นสุดการทำงาน harness ควรรวบรวมใบเสร็จการเปลี่ยนแปลงขนาดเล็ก

1วัตถุประสงค์ (OBJECTIVE)
2แก้ไขการใช้คูปองซ้ำระหว่างการชำระเงิน
3
4สิ่งที่เปลี่ยนแปลง (CHANGED)
5- ตรรกะการตรวจสอบการชำระเงิน
6- การทดสอบการถดถอยแบบเจาะจง
7
8ได้รับการตรวจสอบแล้ว (VERIFIED)
9- lint ผ่าน
10- การทดสอบหน่วยผ่าน
11- การทดสอบแบบบูรณาการการชำระเงินผ่าน
12
13ยังไม่ได้รับการตรวจสอบ (NOT VERIFIED)
14- ผู้ให้บริการชำระเงินในระบบผลิต
15
16การตัดสินใจ (DECISIONS)
17- รักษาลำดับความสำคัญของคูปองที่มีอยู่
18
19ความเสี่ยง (RISKS)
20- ไคลเอนต์มือถือรุ่นเก่าไม่พร้อมใช้งานในเครื่อง
21
22ต้องได้รับการอนุมัติ (APPROVAL NEEDED)
23- ปรับใช้กับ staging

ใบเสร็จไม่ใช่บทสรุปของสิ่งที่โมเดลพูด

มันคือบทสรุปของสิ่งที่ระบบสามารถพิสูจน์ได้

สิ่งนี้ทำให้มนุษย์มีพื้นผิวการตรวจสอบที่กะทัดรัด และทำให้เซสชัน agent ถัดไปมีจุดเริ่มต้นที่เชื่อถือได้

การส่งมอบที่ดีที่สุดไม่ใช่ "นี่คือการสนทนา"

มันคือ "นี่คือสถานะ หลักฐาน และความเสี่ยงที่ยังไม่ได้รับการแก้ไข"

14. ทุกความล้มเหลวควรอัปเกรด Harness

ทีมที่อ่อนแอที่สุดแก้ไขเอาต์พุตที่ล้มเหลว

ทีมที่แข็งแกร่งที่สุดยังแก้ไขระบบที่อนุญาตให้มันเกิดขึ้นด้วย

หลังจากความล้มเหลว ให้ถาม:

1สัญญางานคลุมเครือหรือไม่?
2บริบทที่สำคัญมองไม่เห็นหรือไม่?
3เครื่องมือที่ผิดถูกเปิดเผยหรือไม่?
4เงื่อนไขเบื้องต้นขาดหายไปหรือไม่?
5ผลลัพธ์ไม่สามารถตรวจสอบได้หรือไม่?
6นโยบายถูกทิ้งไว้ใน prompt หรือไม่?
7การกู้คืนกว้างเกินไปหรือไม่?
8ร่องรอยไม่เพียงพอหรือไม่?

จากนั้นแปลงบทเรียนเป็นการปรับปรุงที่สามารถนำกลับมาใช้ใหม่ได้

1ความล้มเหลว
2  -> การวินิจฉัย
3      -> เซ็นเซอร์ กฎ แผนที่ การทดสอบ หรือสัญญาเครื่องมือใหม่
4          -> การทำงานในอนาคตจะดีขึ้นโดยอัตโนมัติ

นี่คือมู่เล่ของ harness

ระบบจะเชื่อถือได้มากขึ้นเพราะความล้มเหลวทิ้งโครงสร้างพื้นฐานไว้เบื้องหลัง

คำตอบที่แก้ไขแล้วช่วยหนึ่งการทำงาน

harness ที่แก้ไขแล้วช่วยทุกการทำงานในอนาคต

15. Harness ก็เสื่อมสภาพเช่นกัน

harness ที่มากกว่าไม่ได้ดีกว่าเสมอไป

โมเดลดีขึ้น เครื่องมือดีขึ้น งานเปลี่ยนไป มาตรการป้องกันเก่าอาจกลายเป็นแรงเสียดทานที่ไม่จำเป็น

วิธีแก้ปัญหาชั่วคราวที่สร้างขึ้นสำหรับโมเดลเมื่อวานนี้อาจป้องกันไม่ให้โมเดลวันนี้ใช้กลยุทธ์ที่ดีกว่า

สิ่งนี้ทำให้เกิดการเสื่อมสภาพของ harness:

1ข้อจำกัดของโมเดลเก่า
2  -> วิธีแก้ปัญหาชั่วคราวของ harness
3      -> โมเดลดีขึ้น
4          -> วิธีแก้ปัญหาชั่วคราวยังคงอยู่
5              -> ระบบช้าลงหรือมีความสามารถน้อยลง

ปฏิบัติต่อส่วนประกอบของ harness เหมือนโค้ดในระบบผลิต

วัดว่าพวกมันยังคงให้ประโยชน์หรือไม่

สำหรับเราเตอร์ ผู้ประเมิน เลเยอร์หน่วยความจำ และกฎการลองใหม่ทุกอัน ให้ถาม:

• ความล้มเหลวใดที่สิ่งนี้ป้องกัน?
• ความล้มเหลวนั้นยังเกิดขึ้นบ่อยแค่ไหน?
• สิ่งนี้เพิ่มความหน่วงและความซับซ้อนเท่าใด?
• ผลลัพธ์เดียวกันนี้สามารถทำได้ง่ายกว่านี้หรือไม่?
• จะเกิดอะไรขึ้นถ้าเราลบมันออก?

harness ที่ดีที่สุดไม่ใช่ harness ที่ใหญ่ที่สุด

มันคือระบบที่เล็กที่สุดที่เชื่อถือได้ในการปิดช่องว่างระหว่างเจตนาและหลักฐาน

สร้างเพื่อลบ

16. Harness ขั้นต่ำที่ใช้งานได้ (Minimum Viable Harness)

คุณไม่จำเป็นต้องมีแพลตฟอร์มการจัดระเบียบ (orchestration platform) เพื่อเริ่มต้น

สร้าง harness เป็นชั้นๆ

ระดับ 1: งานที่มีขอบเขต

• วัตถุประสงค์
• ขอบเขต
• ข้อจำกัด
• การตรวจสอบการยอมรับ

ระดับ 2: สภาพแวดล้อมที่อ่านง่าย

• แผนที่โครงการ
• คำสั่ง
• คำแนะนำในพื้นที่
• การพึ่งพาที่รู้จัก

ระดับ 3: การกระทำที่ควบคุม

• เครื่องมือที่พิมพ์
• การตรวจสอบอาร์กิวเมนต์
• ขอบเขตพาธและสิทธิ์
• ผลลัพธ์ที่มีโครงสร้าง

ระดับ 4: การดำเนินการที่คงทน

• สถานะการทำงานที่ชัดเจน
• จุดตรวจสอบ
• การตัดสินใจ
• บทเรียน

ระดับ 5: หลักฐาน

• การตรวจสอบเชิงกำหนด
• การตรวจสอบเชิงปฏิปักษ์
• ใบเสร็จการเปลี่ยนแปลง

ระดับ 6: การกู้คืนและการเรียนรู้

• การจำแนกความล้มเหลว
• การลองใหม่ที่มีขอบเขต
• การส่งต่อ
• การอัปเดต harness จากความล้มเหลวที่เกิดขึ้นซ้ำ

สร้างชั้นที่เล็กที่สุดที่กำจัดความล้มเหลวที่คุณมีอยู่จริง

อย่าเริ่มต้นด้วยสถาปัตยกรรมหลาย agent เพราะ prompt เดียวในบางครั้งต้องการคำชี้แจง

ความซับซ้อนควรได้รับจากการสังเกตความล้มเหลว

17. ข้อกำหนด Harness ที่นำกลับมาใช้ใหม่ได้

ก่อนที่จะให้ agent มีอิสระที่มีความหมาย ให้กำหนดสิ่งนี้:

1ข้อกำหนด Harness ของ Agent (AGENT HARNESS SPEC)
2
31. สัญญา (CONTRACT)
4   วัตถุประสงค์:
5   ขอบเขต:
6   ข้อจำกัด:
7   หลักฐานการยอมรับ:
8
92. บริบท (CONTEXT)
10   แผนที่ที่โหลดเสมอ:
11   แหล่งที่มาสำหรับดึงข้อมูล:
12   คำแนะนำในพื้นที่:
13   กฎความสดใหม่:
14
153. เครื่องมือ (TOOLS)
16   เครื่องมือที่อนุญาต:
17   เงื่อนไขเบื้องต้น:
18   ผลข้างเคียง:
19   หลักฐานความสำเร็จ:
20   นโยบายหมดเวลาและการลองใหม่:
21
224. สถานะ (STATE)
23   ข้อเท็จจริง:
24   การตัดสินใจ:
25   ความคืบหน้า:
26   บทเรียน:
27   รูปแบบจุดตรวจสอบ:
28
295. นโยบาย (POLICY)
30   การกระทำอัตโนมัติ:
31   การกระทำที่ต้องได้รับการอนุมัติ:
32   การกระทำที่ต้องห้าม:
33   ข้อจำกัดด้านงบประมาณ:
34
356. การตรวจสอบ (VERIFICATION)
36   การตรวจสอบเชิงกำหนด:
37   การตรวจสอบเชิงปฏิปักษ์:
38   กฎการยอมรับ:
39
407. การกู้คืน (RECOVERY)
41   คลาสความล้มเหลว:
42   ข้อจำกัดการลองใหม่:
43   เงื่อนไขการส่งต่อ:
44   การย้อนกลับที่ปลอดภัย:
45
468. การสังเกตการณ์ (OBSERVABILITY)
47   เหตุการณ์ร่องรอย:
48   ตัวชี้วัด:
49   ใบเสร็จการเปลี่ยนแปลงสุดท้าย:

หากฟิลด์เหล่านี้ไม่ได้ถูกกำหนดไว้ agent จะไม่เป็นอิสระ

มันกำลังแสดงสด (improvising)

18. วัดระบบในระดับที่ถูกต้อง

จำนวน token ไม่ใช่ตัวชี้วัดสุดท้าย

จำนวนงานที่พยายามก็ไม่ใช่เช่นกัน

หน่วยที่มีประโยชน์คืองานที่ได้รับการยอมรับ

ตัวชี้วัดที่ใช้งานได้คือ:

1เอาต์พุตที่ได้รับการยอมรับ
2------------------------------
3นาทีการตรวจสอบของมนุษย์ + ต้นทุนการทำงาน

นอกจากนี้ ให้ติดตาม:

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

สิ่งนี้ป้องกันภาพลวงตาทั่วไป:

agent สามารถดูเหมือนมีประสิทธิผลสูงในขณะที่สร้างงานตรวจสอบที่มีราคาแพง

วัตถุประสงค์ไม่ใช่กิจกรรมของ agent ที่มากขึ้น

มันคือผลลัพธ์ที่เชื่อถือได้มากขึ้นต่อหน่วยของความสนใจของมนุษย์

19. เมื่อคุณไม่จำเป็นต้องใช้ Harness ที่หนักหน่วง

ไม่ใช่ทุกการเรียกใช้โมเดลที่ต้องการระบบปฏิบัติการ

ใช้ prompt อย่างง่ายเมื่อ:

• งานสั้น
• เอาต์พุตง่ายต่อการตรวจสอบ
• ความล้มเหลวมีต้นทุนต่ำ
• ไม่มีผลข้างเคียงภายนอกเกิดขึ้น
• ผู้ใช้ยังคงอยู่ในวงจร

เพิ่ม harness เมื่อ:

• งานครอบคลุมหลายเครื่องมือหรือหลายเซสชัน
• สภาพแวดล้อมสามารถเปลี่ยนแปลงได้
• การกระทำมีผลที่ตามมาจริง
• ความสำเร็จยากต่อการตัดสินด้วยตนเอง
• ความล้มเหลวเดียวกันปรากฏขึ้นซ้ำๆ
• การตรวจสอบของมนุษย์กลายเป็นคอขวด

จุดประสงค์ของ harness ไม่ใช่เพื่อทำให้ demo ดูซับซ้อน

มันคือเพื่อทำให้งานจริงเชื่อถือได้

การเปลี่ยนแปลงที่แท้จริง (The Real Shift)

ผลิตภัณฑ์ AI รุ่นแรกถูกสร้างขึ้นรอบๆ prompt

รุ่นถัดไปกำลังถูกสร้างขึ้นรอบๆ สภาพแวดล้อม

คำถามไม่ใช่แค่:

เราจะทำให้โมเดลตอบคำตอบได้ดีขึ้นได้อย่างไร?

แต่มันคือ:

เราจะสร้างระบบที่การกระทำที่ดีทำได้ง่าย การกระทำที่เป็นอันตรายถูกควบคุม ความล้มเหลวมองเห็นได้ และความสำเร็จสามารถพิสูจน์ได้อย่างไร?

นั่นคือการเปลี่ยนแปลงจากวิศวกรรม prompt สู่วิศวกรรม harness

โมเดลให้ความฉลาด

harness ให้โครงสร้าง

ร่วมกันพวกมันสร้างการดำเนินการที่เชื่อถือได้

หาก agent ของคุณพังทลายอยู่เรื่อยๆ ให้หยุดเติมคำคุณศัพท์ลงใน prompt

สร้างสภาพแวดล้อมที่มันต้องการเพื่อประสบความสำเร็จ

ถ้าคุณอ่านมาถึงตรงนี้

คั่นหน้าคู่มือนี้ไว้

ติดตาม @LunarResearcher บน X

สมัครรับ Substack ของฉัน

ส่งบทความนี้ให้กับคนที่ยังคงพยายามแก้ไขทุกความล้มเหลวของ agent ด้วย prompt ที่ยาวขึ้น