สถาปัตยกรรมอ้างอิงสำหรับชั้นปฏิบัติการ AI แบบเธรด

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

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

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

วัตถุประสงค์ของสถาปัตยกรรม

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

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

หลักการเดียวกันใช้ใน ผู้ช่วย AI เฉพาะโครงการบน Telegram และ การขยายผู้ช่วย AI บน Telegram จากบุคคลสู่ทีม ช่องทางข้อความเป็นเพียงช่องทางขนส่ง ส่วนสถาปัตยกรรมการดำเนินงานคือชั้นส่งต่องาน เก็บข้อมูล ดำเนินการ ตรวจสอบ และกู้คืนที่อยู่เบื้องหลัง

องค์ประกอบขณะทำงาน

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

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

ส่วนที่สามคือชั้นโครงสร้างพื้นฐาน รวมกลไกที่ทำให้ระบบปฏิบัติการ AI ใช้งานได้: การตั้งค่าโปรไฟล์ สิทธิ์เครื่องมือ นิยามงาน cron สคริปต์ ข้อมูลสำรองเข้ารหัส บันทึกการกู้คืน กุญแจนำระบบขึ้นใช้งาน การตั้งค่า gateway ช่องทางสื่อสาร การตรวจสุขภาพ และเทมเพลตสภาพแวดล้อม ควรดูแลแยกจากงานธุรกิจ เพราะเป็นส่วนที่ต้องกู้คืน

ส่วนที่สี่คือชั้นผู้ดำเนินงาน ทำงานจริงผ่านคำสั่ง shell สคริปต์ในเครื่อง งานตามกำหนดเวลา ระบบอัตโนมัติผ่านเบราว์เซอร์ งานในรีโพซิทอรี GitHub Actions การเชื่อมต่อผ่าน API เอเจนต์เขียนโค้ด เครื่องมือประมวลผลเอกสาร หรือบริการภายนอก ทั้งหมดเป็นรายละเอียดการพัฒนา และต้องตรวจผลก่อนรายงานต่อผู้ใช้

วงจรคำขอ

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

บันทึกการส่งต่องานทำให้วงจรนี้ชัดเจน โดยระบุบริบทที่รับผิดชอบ เหตุผล ผู้ดำเนินการ จุดตรวจที่คาดหวัง และวิธีตรวจสอบ เช่น “เธรด: เนื้อหาเว็บไซต์ เหตุผล: อัปเดตบทความที่จะเผยแพร่ ผู้ดำเนินการ: เวิร์กโฟลว์ในรีโพซิทอรีร่วมกับการนำระบบขึ้นใช้งานผ่าน CI จุดตรวจ: build ผ่านและพร้อม commit วิธีตรวจสอบ: URL ที่ใช้งานจริงคืนสถานะ 200 และมีชื่อบทความตามคาด” บันทึกนี้ป้องกันการทำงานในบริบทผิดโดยไม่แจ้ง และให้ข้อมูลเพียงพอสำหรับระบบอื่นตรวจสอบ

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

แบบจำลองสถานะ

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

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

สถานะเชิงขั้นตอนสำคัญเป็นพิเศษ ทักษะหรือคู่มือปฏิบัติงานควรระบุเงื่อนไขเริ่มทำงาน คำสั่งที่แน่นอน ไฟล์ที่จำเป็น ขอบเขตความปลอดภัย ข้อควรระวัง และขั้นตอนตรวจสอบ นี่คือชั้นการดำเนินงานใน ทักษะเอเจนต์ AI เฉพาะสายงาน และ การปรับเอเจนต์แบบ Hermes ระบบดีขึ้นด้วยการบันทึกขั้นตอนที่ทำซ้ำได้ไว้ภายนอก ไม่ใช่พึ่งความจำจากบทสนทนาอย่างเดียว

รูปแบบการดำเนินงาน

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

ทุกรูปแบบต้องมีวิธีตรวจผล สคริปต์ควรคืนสถานะการจบงานและผลลัพธ์กระชับ งาน cron ควรเงียบเมื่อสำเร็จตามปกติและแจ้งเมื่อเปลี่ยนแปลงสำคัญหรือล้มเหลว ผู้ปฏิบัติงานที่ได้รับมอบหมายควรส่งพาธไฟล์ diff URL หรือหลักฐานชัดเจนที่ตรวจแยกได้ เวิร์กโฟลว์นำระบบขึ้นใช้งานควรส่งสถานะ CI สถานะผลงาน และผลตรวจจุดเชื่อมต่อจริง วินัยเดียวกันใช้กับ ไปป์ไลน์นำระบบที่ติดตั้งและดูแลเองขึ้นใช้งาน: ความสำเร็จเป็นสถานะที่พิสูจน์ด้วยหลักฐาน ไม่ใช่ข้อความที่เอเจนต์สร้าง

ความปลอดภัยและการกำหนดสิทธิ์

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

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

การแก้ระบบใช้งานจริงควรติดตามสถานะแยกกัน: การแก้ในเครื่อง การตรวจในเครื่อง commit, push ผล CI ผลการนำระบบขึ้นใช้งาน และการตรวจระบบจริง การรายงานว่า “เสร็จ” ก่อนตรวจระบบจริงยังไม่ครบ วินัยนี้จำเป็นสำหรับระบบเนื้อหา การเปลี่ยนโครงสร้างพื้นฐาน และเวิร์กโฟลว์ข้อมูล เพราะการเปลี่ยนแต่ละสถานะล้มเหลวแยกกันได้

การกู้คืนและการย้ายระบบ

ชั้นปฏิบัติการ AI แบบเธรดต้องย้ายระบบได้ การสำรองเฉพาะพรอมป์ต์ไม่เพียงพอ ชุดที่กู้คืนได้ต้องมีการตั้งค่าโปรไฟล์ หน่วยความจำ ทักษะ นิยามงาน cron สคริปต์ การตั้งค่าปลั๊กอิน เทมเพลตสภาพแวดล้อม ที่อยู่รีโพซิทอรีระยะไกล เอกสารนำระบบขึ้นใช้งาน การจับคู่ช่องทางสื่อสาร และวิธีกู้คืน แคชขนาดใหญ่กับผลงานที่สร้างขึ้นมักสร้างใหม่ได้ โดยทั่วไปควรกู้ข้อมูลลับจากระบบจัดการข้อมูลลับเฉพาะหรือ keychain แทนข้อมูลสำรองข้อความธรรมดา

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

ข้อกำหนดระบบที่ LLM อ่านเข้าใจได้

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

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

รายการตรวจสอบการพัฒนา

• กำหนดส่วนติดต่อผู้ใช้ที่คงที่หนึ่งชุดและให้ผู้ดำเนินการภายในทำงานอยู่เบื้องหลัง
• สร้างเธรดงานที่มีชื่อจำนวนน้อย พร้อมขอบเขตและสถานะชัดเจน
• ใช้บันทึกการส่งต่องานสำหรับคำขอที่ซับซ้อน: บริบท เหตุผล ผู้ดำเนินการ จุดตรวจ และวิธีตรวจสอบ
• แยกหน่วยความจำถาวร ทักษะเชิงขั้นตอน ไฟล์ต้นทาง บันทึกบทสนทนา และผลงานที่สร้างขึ้น
• ย้ายงานที่ทำซ้ำและให้ผลแน่นอนไปเป็นสคริปต์หรืองานตามกำหนดเวลา
• ระบุขั้นตอนแก้ระบบจริงให้ชัด: ตรวจในเครื่อง commit, push, CI นำขึ้นใช้งาน และตรวจระบบจริง
• ตรวจงานที่มอบหมายก่อนรายงานว่าเสร็จ
• สำรองโปรไฟล์ ทักษะ หน่วยความจำ cron สคริปต์ การตั้งค่า และบันทึกการกู้คืน
• เก็บข้อมูลลับนอกช่องทางข้อความของผู้ช่วยและกู้คืนผ่านระบบจัดเก็บข้อมูลลับเฉพาะ
• ซ้อมกู้คืนเป็นระยะและบันทึกหลักฐาน

ผลลัพธ์ในการดำเนินงาน

ผลลัพธ์คือชั้นปฏิบัติการทางเทคนิคที่มีพฤติกรรมคาดการณ์ได้ คำขอเข้าผ่านส่วนติดต่อเดียวแต่ไม่สะสมในบริบทไร้โครงสร้างเดียว งานถูกส่งต่อ สถานะแยกประเภท เลือกวิธีดำเนินงานอย่างตั้งใจ ผลกระทบได้รับอนุญาต ผลลัพธ์ผ่านการตรวจสอบ และกู้ระบบบนเครื่องอื่นได้

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