เขียนรากฐานของเอเจนต์ใหม่: การปรับโครงสร้าง Orkas ตั้งแต่พื้นฐาน

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

ทำไมต้องแตะรากฐาน

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

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

2. การประสานงานเป็น "การวางแผนแบบตายตัว" รุ่นแรกเป็นกลไกแผน/DAG: ให้โมเดลแตกงานเป็นกราฟแผนก่อน แล้วให้ตัวดำเนินการแจกงานตามกราฟ ฟังดูเป็นระเบียบ แต่ความเป็นจริงของเอเจนต์เปลี่ยนแปลงตลอดเวลา การอ่านไฟล์หนึ่งอาจเผยว่าต้องเปลี่ยนทิศทาง และผลของงานย่อยหนึ่งก็ตัดสินว่าขั้นตอนถัดไปควรส่งให้ใคร การตรึงการตัดสินใจไว้ในกราฟที่สร้างล่วงหน้าหมายความว่า ทุกครั้งที่ "แผนตามความจริงไม่ทัน" ต้องคอยแก้เฉพาะหน้าภายในตัวดำเนินการ

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

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

1. นำชุดความสามารถเต็มรูปแบบของเอเจนต์เขียนโค้ดมาสู่เดสก์ท็อป

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

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

การตัดสินใจทางสถาปัตยกรรมที่สำคัญคือ แยกออกเป็นสองชั้น:

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

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

ชุดความสามารถนี้มีอะไรบ้างจริง ๆ

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

• การจัดการไฟล์อย่างละเอียดและการค้นหาในเครื่อง read_file รองรับการอ่านตามช่วงอักขระและดึงข้อความจากเอกสาร PDF / Office โดยอัตโนมัติ; edit_file แทนที่ "สตริงเดิม → สตริงใหม่" อย่างแม่นยำ และกำหนดให้ต้องอ่านก่อนเขียนทุกครั้ง; write_file บันทึกชิ้นงานและเก็บบันทึกไว้; stat_file ตรวจสอบขนาด; search_files ค้นหาตามชื่อ/glob, grep_files ค้นหาเนื้อหาข้ามไฟล์ กลุ่มนี้ทำให้เอเจนต์ "ค้นโค้ดและแก้ไฟล์" ในพื้นที่ทำงานจริงได้เหมือนวิศวกร แทนที่จะทำได้เพียงรับและส่งข้อความทั้งก้อน
• Bash และเครื่องมือระบบ ตัวดำเนินการเชลล์ในแซนด์บ็อกซ์ พร้อมโหมดทำงานเบื้องหลัง โดยงานยาวแยกออกจากเทิร์นปัจจุบันและบันทึกล็อกลงไฟล์ รวมถึงการควบคุมการดำเนินการอันตรายตามระดับความเสี่ยง พลังของเอเจนต์เดสก์ท็อปส่วนใหญ่มาจากความสามารถในการสั่งชุดเครื่องมือระบบได้โดยตรงนี่เอง
• หลายเวิร์กเกอร์ทำงานพร้อมกัน ภายในเทิร์นเดียว เครื่องมือแบบอ่านอย่างเดียวที่เป็นอิสระทำงานพร้อมกันได้ ในระดับงาน ผู้บัญชาการยังแจกงานย่อยที่เป็นอิสระให้หลายเวิร์กเกอร์ทำพร้อมกันได้ด้วย (ดูส่วนที่ 3) การทำงานขนานในจุดที่ปลอดภัยคือกุญแจในการย่นเวลาจริงของ "งานระยะยาว" ให้อยู่ในระดับที่ยอมรับได้
• การให้เหตุผลและแก้งานระยะยาว วงรอบที่ทำงานต่อเนื่องได้หลายสิบเทิร์น จัดการบริบทของตัวเอง ฟื้นตัวจากข้อผิดพลาด และไม่ติดวนอยู่กับที่ นี่คือเส้นแบ่งระหว่าง "ทำงานซับซ้อนให้เสร็จ" กับ "ตอบคำถาม"

ทำให้พร้อมใช้งานจริงในเชิงวิศวกรรมอย่างไร

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

• หน้าต่างบริบทจริง + บีบอัดเมื่อถึง 80% เท่านั้น เอนจินอ่านขนาดหน้าต่างบริบทของแต่ละโมเดลที่ แท้จริง (รวมถึงโมเดลที่มีหน้าต่างบริบทล้านโทเคน) และเริ่มบีบอัดเมื่อใช้งานถึง 80% เท่านั้น แทนที่จะเผื่อมากเกินไปด้วยการเริ่มที่ 60% แล้วทิ้งบริบทที่มีประโยชน์ไป 40% นอกจากนี้ยังมีมาตรการป้องกัน "การบีบอัดที่ไม่ช่วยคืนพื้นที่": หากส่วนท้ายที่เก็บไว้เต็มหน้าต่างอยู่แล้ว เช่น มีผลอ่านไฟล์ขนาดใหญ่มากอยู่ในส่วนท้าย การบีบอัดก็คืนพื้นที่ไม่ได้ จึงเพียงบันทึกคำเตือนแล้วข้าม ไม่เรียกสรุปให้สิ้นเปลืองเปล่า ๆ ความสามารถของงานระยะยาวในการ "จำสิ่งที่เกิดขึ้นก่อนหน้า" ขึ้นอยู่กับเรื่องนี้ทั้งหมด

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

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

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

• การตรวจจับการวนซ้ำ เมื่อการเรียกเครื่องมือเดิมเกิดซ้ำติดกัน เอนจินจะเตือนก่อน (ครั้งที่ 3) แล้วบังคับหยุด (ครั้งที่ 5) รูปแบบการเรียกที่ต่างออกไปจะรีเซ็ตตัวนับ จึงไม่ตรวจผิดกับการเปลี่ยนแปลงที่สมเหตุสมผล เช่น การแบ่งหน้าหรือการตรวจสอบสถานะเป็นระยะ เมื่อโมเดลติดขัด มันจะไม่เผาโทเคนทิ้งอย่างเงียบ ๆ อีกต่อไป

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

มีรายละเอียดที่เกี่ยวกับ "ท้องถิ่น" มากข้อหนึ่งที่ควรกล่าวถึง: การประมาณโทเคนสำหรับข้อความภาษาจีนผสมอังกฤษ การประมาณแบบทั่วไปนับบทสนทนาภาษาจีนล้วนต่ำกว่าจริงสองถึงสามเท่า เอนจินแยกจัดการอักขระจีนและอังกฤษตามประเภทอักขระ ซึ่งทำให้เกณฑ์การบีบอัดเชื่อถือได้ นี่คือเรื่องแบบที่ SDK ทั่วไปไม่คิดเผื่อให้คุณ

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

2. ทำให้โมเดลพร้อมใช้งานเสมอ: ตัวครอบผู้ให้บริการหลายชั้น

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

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

การตัดสินใจของตัวสลับก็ระมัดระวัง โดยใช้เส้นแบ่งที่ อีเวนต์เนื้อหาแรก:

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

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

ในด้าน "รายชื่อ" ผู้ให้บริการ การปรับโครงสร้างรวมแหล่งที่มาสามประเภทไว้ภายใต้ชั้นนามธรรมเดียวกัน:

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

สำหรับชั้นที่อยู่เหนือขึ้นไป ทั้งหมดนี้ปรากฏเป็นเพียงคู่ที่คงที่หนึ่งคู่ (provider, model) — การสลับ ช่วงพัก และการปรับเชื่อมภายนอกทั้งหมดซ่อนอยู่ภายในชั้นอะแดปเตอร์

3. ใช้แชตกลุ่มประสานงาน: จากแผน DAG แบบตายตัวสู่ผู้บัญชาการที่ร่วมอยู่ในวงรอบ

นี่คือส่วนที่ต้อง "ปรับวิธีคิดใหม่" มากที่สุดของการปรับโครงสร้าง

รูปแบบเดิมคือ การวางแผนแบบตายตัว: โมเดลสร้างแผน/DAG ก่อน แล้วตัวดำเนินการทำงานตามกราฟ รูปแบบใหม่รื้อกราฟนั้นออกทั้งหมดแล้วแทนที่ด้วย การประสานงานแชตกลุ่มแบบปรับเปลี่ยนได้ โดยมีผู้บัญชาการร่วมอยู่ในวงรอบ.

แนวคิดเปรียบเทียบคือ ห้องแชตกลุ่ม:

• ตัว Commander เป็นเจ้าภาพของห้อง ไม่ใช่มิดเดิลแวร์ที่มองไม่เห็น;
• เอเจนต์เวิร์กเกอร์ เป็นสมาชิกหลักที่เท่าเทียมกันในห้อง;
• ปฏิสัมพันธ์ทั้งหมดเป็นข้อความแบบอะซิงโครนัสที่เข้าคิวผ่าน บัสข้อความเพียงตัวเดียว (ไม่มีเส้นทางส่วนตัวสำหรับการแจกงานขนาน)

"การแจกงาน" ของผู้บัญชาการไม่ใช่ @somebody ที่เขียนในข้อความทั่วไป — การที่ LLM เขียน @AgentA ในเนื้อความเป็นเพียงมาร์กดาวน์จากข้อมูลฝึกและเชื่อถือไม่ได้ สัญญาณแจกงานที่แท้จริงคือ การเรียกเครื่องมือแบบมีโครงสร้าง, และหลังปรับโครงสร้างก็รวมเหลือการกระทำสามแบบที่มีความหมายชัดเจน:

• dispatch_to — ส่งเอเจนต์ไปทำงานจนเสร็จแล้วส่งผลกลับ โดยผู้บัญชาการสังเคราะห์ผล งานอิสระหลายงานสามารถกระจายไปทำพร้อมกันได้
• run_worker — งานย่อยที่ผู้บัญชาการรับผิดชอบเอง โดยส่งผลกลับแบบซิงโครนัส เวิร์กเกอร์นิรนามเป็น "มือ" ของผู้บัญชาการ (ผู้ใช้มองไม่เห็น) ส่วนเวิร์กเกอร์ที่มีชื่อเป็นผู้เชี่ยวชาญที่มองเห็นได้
• hand_off_to — ส่งต่อ การสนทนา ให้ เอเจนต์ ผู้บัญชาการถอนตัวออก และเอเจนต์ตอบผู้ใช้โดยตรงโดยไม่มีการสังเคราะห์ซ้ำในเทิร์นนี้

ทำไมจึงเป็นแชตกลุ่ม แทนตัวประสานงานหรือต้นไม้เอเจนต์ย่อย

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

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

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

สิ่งใหม่ในรุ่นนี้: การส่งต่อแบบโต้ตอบ

ส่วนใหม่ล่าสุดในแนวทางนี้คือ การส่งต่อเอเจนต์แบบโต้ตอบ.

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

ทางแก้คือ สิทธิ์ตอบที่เซิร์ฟเวอร์เป็นผู้กำหนด + ผู้รับที่โมเดลตัดสินใจ:

• สิทธิ์ตอบกลายเป็นฟิลด์สถานะถาวรที่เก็บข้ามการโหลดใหม่ และอาศัยอีเวนต์เปลี่ยนสถานะที่มีอยู่เพื่อ ซิงค์อัตโนมัติ ไปยังทุกฝั่ง โดยไม่ต้องมีอีเวนต์ประเภทใหม่
• หลังผู้บัญชาการใช้ hand_off_to เพื่อมอบสิทธิ์ตอบให้เอเจนต์แบบโต้ตอบ ข้อความถัดไปของผู้ใช้ที่ "ไม่มี@" จะส่ง ตรงไปยังเอเจนต์นั้น, จนกว่าเอเจนต์จะคืนสิทธิ์เองหรือผู้ใช้ระบุถึงผู้บัญชาการอีกครั้ง
• เอเจนต์คืนการควบคุมด้วยเครื่องหมาย <handback /> ; การแยกวิเคราะห์ตรวจสอบอย่างเคร่งครัดว่าตรงกันจริง (เพื่อไม่ให้ <handback ที่หลุดมาอยู่ในข้อความทั่วไปถูกอ่านผิดว่าเป็นการส่งต่อ)
• หากยังมีรายการงานที่ไม่เสร็จเมื่อคืนสิทธิ์ ผู้บัญชาการจะรับช่วงจากบัญชีงานแล้วทำต่อ

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

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

4. จากแค็ตตาล็อกแบบปิดสู่โฮสต์แบบเปิด

หากแกนหลักสามข้อแรกว่าด้วยการสร้างรากฐานให้มั่นคง ข้อนี้ก็ว่าด้วยการเปิดประตูหน้าต่างทุกบานให้กว้าง — เปลี่ยน Orkas จากแค็ตตาล็อกแบบปิดให้เป็นโฮสต์แบบเปิด — พร้อมรักษาขอบเขตความปลอดภัยโดยไม่ถอยแม้แต่นิดเดียว

การปรับโครงสร้างครั้งนี้ได้รื้อจุดคอขวดแบบ “ปิด” หลายแห่งอย่างเป็นระบบ:

• แพ็กเกจภายนอก ผู้ใช้ระบุที่อยู่รีโพซิทอรี แล้ว Orkas จะโฮสต์ไว้ในเครื่อง โดยโคลนลงในโฟลเดอร์ตามต้นฉบับทุกประการ — ไม่ปรับรูปแบบ ไม่เขียนใหม่ และไม่ซิงก์ขึ้นคลาวด์เด็ดขาด (เพราะมีไดเรกทอรีของส่วนพึ่งพาจากบุคคลที่สามอยู่ภายใน) เครื่องมือบรรทัดคำสั่งแบบแยกเดี่ยวจะดูแลวงจรการติดตั้ง/อัปเดต/เริ่ม-หยุด สแกนว่าแพ็กเกจนั้นมี “รูปแบบทักษะ” (มีไฟล์คำอธิบายทักษะ) หรือ “รูปแบบ CLI” (มีจุดเรียกใช้ที่รันได้) แล้วบันทึกเมทาดาทาลงในทะเบียน นอกไดเรกทอรีแพ็กเกจ (เพื่อให้การดึงอัปเดตในอนาคตไม่เกิดข้อขัดแย้ง) การติดตั้งส่วนพึ่งพาจะผ่านการยืนยันสองขั้นตอนแบบ “ถามครั้งเดียวแล้วจำไว้” ส่วนจุดเรียกใช้ที่รันได้จะได้รับการสร้าง shim และเพิ่มลงใน PATH ของเครื่องมือ bash เพื่อให้โมเดลเรียก CLI ของบุคคลที่สามเหล่านี้ได้โดยตรง

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

• การใช้ทักษะส่วนกลางร่วมกัน Orkas อ่านจากไดเรกทอรีทักษะส่วนกลางที่เครื่องมือเอเจนต์อื่นบนเครื่องของผู้ใช้ดูแลอยู่แล้วโดยตรง ทำให้ใช้งานร่วมกันได้ในระดับทักษะ — ทักษะที่ผู้ใช้สะสมไว้ในที่หนึ่งก็ใช้ใน Orkas ได้ด้วย การที่ผู้ใช้นำทักษะไปวางในไดเรกทอรีเหล่านั้นถือเป็นการอนุญาตในตัว จึงเปิดใช้งานโดยค่าเริ่มต้นและยังมีสวิตช์หลักให้ปิดได้ คำอธิบายทักษะจากบุคคลที่สามเหล่านี้เป็นช่องทางแทรกคำสั่งโจมตีที่ไม่น่าเชื่อถือ จึงต้องผ่านตัวโหลด “ระดับเปิด” มองเห็นได้เฉพาะผู้บัญชาการ และ โครงสร้างระบบทำให้ไม่สามารถเข้าสู่รายการทักษะที่อนุญาตของเอเจนต์ได้.

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

• สะพานเชื่อมย้อนกลับ: ให้เอเจนต์ภายนอกในเครื่องรับรู้ Orkas ได้เช่นกัน นี่คือส่วนที่น่าสนใจที่สุด ก่อนหน้านี้เครื่องมือเอเจนต์ภายนอกที่อยู่บนเครื่องของผู้ใช้เป็นเหมือนกล่องดำสำหรับ Orkas แต่ตอนนี้เมื่อ Orkas ส่งงานให้เครื่องมือเหล่านั้น จะใส่ช่องทางสะพานเชื่อมให้พวกมันสามารถ ย้อนกลับมา แสดงรายการ/อ่าน/รันทักษะของ Orkas เรียกตัวเชื่อมต่อ และค้นหาฐานความรู้ได้ สะพานเชื่อมทำงานผ่านช่องทางสื่อสารระหว่างกระบวนการในเครื่อง (ไม่เปิดพอร์ตเครือข่าย) โดยยืนยันตัวตนด้วยข้อมูลรับรองแบบใช้ครั้งเดียวที่ไม่ซ้ำกันในแต่ละรอบการทำงาน และถูกทำลายทันทีที่รอบนั้นสิ้นสุด การเรียกตัวเชื่อมต่อทุกครั้งที่มีผลกระทบต่อภายนอกต้องผ่านกล่องโต้ตอบยืนยันจากผู้ใช้ — ไม่ใช่การคาดเดาว่าอ่านหรือเขียนจากชื่อเครื่องมือ (ซึ่งมักปล่อยผ่านหลวมเกินไป) แต่ยืนยันหนึ่งครั้งต่อคู่ (เอเจนต์, ตัวเชื่อมต่อ) พร้อมตัวเลือก “อนุญาตเสมอ”

• แนวทางเขียนโค้ดสำหรับงานเฉพาะทางที่พบไม่บ่อย แผนผังการตัดสินใจของผู้บัญชาการเพิ่มแขนงใหม่: เมื่อไม่มีเอเจนต์/ทักษะ/ตัวเชื่อมต่อที่ตรงกับงาน ให้ ประเมินการแก้ปัญหาโดยตรงด้วย bash ร่วมกับสคริปต์สั้น ๆ, ลงมือทำในเทิร์นนี้ ตรวจสอบผลลัพธ์ และอาจเสนอให้สกัดออกมาเป็นทักษะที่กำหนดเอง ความสามารถนี้มาพร้อมการรัน bash เบื้องหลัง (งานยาวจะแยกออกจากเทิร์นปัจจุบันและบันทึกล็อกลงไฟล์) และไดเรกทอรีที่ผู้ใช้ให้สิทธิ์

เปิดกว้าง แต่ไม่ปล่อยปละ

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

• การดำเนินการกับไฟล์ต้องผ่านแซนด์บ็อกซ์เส้นทางเสมอ (พื้นที่ทำงาน + ไฟล์แนบปัจจุบัน + ไดเรกทอรีที่ผู้ใช้ให้สิทธิ์ไว้อย่างชัดเจน) ส่วนไดเรกทอรีข้อมูลรับรอง ไดเรกทอรีระบบ และไดเรกทอรีของ Orkas เองนั้น ไม่สามารถให้สิทธิ์ได้;
• bash ที่อันตราย (การลักลอบส่งข้อมูลออก การลบแบบทำลายล้าง การยกระดับสิทธิ์ เส้นทางที่มีข้อมูลอ่อนไหว) จะเรียกการยืนยันสิทธิ์ โดยแบ่งตัวเลือกเป็น “เฉพาะครั้งนี้ / สำหรับรอบการทำงานนี้ / ปฏิเสธ” และล็อกจะบันทึกเฉพาะหมวดหมู่กับความยาว — ไม่บันทึกข้อความคำสั่งเด็ดขาด;
• การติดตั้งแพ็กเกจภายนอก จะปิดกั้นเพื่อความปลอดภัยและปฏิเสธโดยสิ้นเชิง หากแพ็กเกจมี symlink อยู่ภายใน (เพื่อป้องกันการใช้ symlink อ่านไฟล์อ่อนไหวนอกแซนด์บ็อกซ์เข้ามาในขอบเขต) และแหล่งที่มาของการโคลนถูกจำกัดด้วยรายการโปรโตคอลที่อนุญาต;
• การตั้งค่าการรับส่งข้อมูลและข้อมูลลับทั้งหมดที่มีข้อมูลรับรองจะถูกเข้ารหัสขณะจัดเก็บ และข้อมูลรับรองของสะพานเชื่อมจะแยกตามแต่ละรอบการทำงาน;
• รุ่นแจกจ่ายแบบโอเพนซอร์ส / โฮสต์จะตัดความสามารถที่สงวนไว้สำหรับโฮสต์ออกตามกฎการตัดทอน

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

5. ฉลาดขึ้นข้ามเซสชัน: ความจำและการพัฒนาตนเอง

การยกเครื่องรากฐานครั้งนี้ยังสร้างระบบย่อยสองระบบที่ “ยิ่งใช้ เอเจนต์ยิ่งฉลาด” ขึ้นใหม่ โดยทั้งคู่ยึดหลักวินัยทางวิศวกรรมเดียวกัน — ปิดโดยค่าเริ่มต้น มีขอบเขต และตรวจสอบได้.

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

การพัฒนาตนเอง คือคลังทักษะส่วนตัวของเอเจนต์ (จัดเก็บแยกจากคลังทักษะที่ใช้ร่วมกันของแพลตฟอร์ม) ร่วมกับชั้นการทบทวนกระบวนการคิดของตนเอง เอนจินตัดสินใจว่าจะทบทวนหรือไม่ด้วยชุด สัญญาณถ่วงน้ำหนัก: การแก้ไขจากผู้ใช้ (น้ำหนักสูงสุด) การฟื้นตัวจากข้อผิดพลาดที่ไม่เล็กน้อย ความซับซ้อนของงาน จุดอ่อนที่ทราบอยู่แล้วถูกกระตุ้นหรือเอาชนะได้ ทักษะที่ใช้ไม่ได้ผล... การทบทวนจะเกิดขึ้นก็ต่อเมื่อสัญญาณถ่วงน้ำหนักเกินเกณฑ์ที่กำหนด ตัวการทบทวนเองเป็น งานเบื้องหลังที่ทำเป็นระยะ (ประมาณหนึ่งรอบทุก 12 ชั่วโมง มีช่วงพักหลายชั่วโมง และกลไกสำรองในช่วงหลายวัน) ซึ่งใช้โมเดลขนาดเล็กราคาประหยัดอ่านสรุปกิจกรรมล่าสุด แล้วตัดสินใจว่าจะสร้าง/ปรับแก้ทักษะและอัปเดต “โปรไฟล์ความสามารถ” ของเอเจนต์หรือไม่

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

ปรัชญาวิศวกรรม: ความซับซ้อนที่มีเหตุผลรองรับ — อย่าลดทอนจนหายไป

ทีมทบทวนสถาปัตยกรรมหลายรอบระหว่างการปรับโครงสร้าง และมีข้อสรุปหนึ่งที่กลับมาซ้ำ ๆ จนควรหยิบออกมาเน้นโดยเฉพาะ: แยก “โครงสร้างที่พองโตเกินจำเป็น” ออกจาก “ความซับซ้อนที่มีเหตุผลรองรับ” และปรับเฉพาะอย่างแรก

• กลยุทธ์ผสานข้อมูลหลายแบบของเอนจินซิงก์ ลูปเอเจนต์ที่สร้างเอง ตัวห่อผู้ให้บริการหลายชั้น ขอบเขตการควบคุมระยะไกลผ่านมือถือ — สิ่งเหล่านี้ดูซับซ้อน แต่ทุกชั้นมีเหตุผลที่คุ้มค่า (ความสอดคล้องของข้อมูลหลายอุปกรณ์ในท้ายที่สุด การผสานรวมเชิงลึก การหมุนเวียนหลายคีย์ ขอบเขตปลายทางที่ผลิตภัณฑ์กำหนด) การฝืน “ทำให้ง่าย” มีแต่จะทำให้ข้อมูลสูญหายและแบ่งชั้นได้ไม่ชัดเจน
• สิ่งที่ควรปรับจริง ๆ คือ “โมดูลที่รวมทุกอย่างไว้ในตัว” และความซ้ำซ้อนเฉพาะจุด: แยกฟังก์ชันบริสุทธิ์ที่ไม่มีสถานะออกจากบัสแชตกลุ่มที่บวมโต (การประกอบพรอมป์ต์ เครื่องมือผู้บัญชาการ เทิร์น CLI) และรวมรูปแบบ “กล่องโต้ตอบยืนยัน” ที่ทำซ้ำหลายครั้งให้เป็นคอมโพเนนต์ร่วมเพียงตัวเดียว

สิ่งที่รองรับการตัดสินใจเช่นนี้คือหลักวินัยที่เข้มงวดซึ่งเขียนไว้ในเอกสารข้อกำหนดของโครงการ: ขอบเขต (กระบวนการเดียว ใช้ IPC เป็นช่องทางเดียว โหลดรันไทม์ได้แบบไดนามิกเท่านั้น) การแบ่งชั้น (ทิศทางการพึ่งพาของแต่ละชั้น) แหล่งข้อมูลจริงเพียงแห่งเดียว (หมวดหมู่ การจัดประเภทข้อมูลเทเลเมทรี โดเมน) และการบังคับ “ตรวจสอบพรอมป์ต์” ในทุกคอมมิตที่เกี่ยวข้องกับพรอมป์ต์ สิ่งที่ทำให้ยกเครื่องรากฐานได้โดยไม่พังทลายไม่ใช่การออกแบบอันชาญฉลาดใด ๆ แต่คือการรักษาหลักที่ต้องคงเดิมเหล่านี้อย่างต่อเนื่อง

บทส่งท้าย

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

• รันไทม์ภายในกระบวนการแบบเอนจิน/อะแดปเตอร์สองชั้น ที่นำจุดแข็งของเอเจนต์เขียนโค้ดมาครบชุด — การดำเนินการกับไฟล์ การค้นหาในเครื่อง เครื่องมือระบบ ผู้ทำงานหลายตัวแบบขนาน การแก้ปัญหาระยะยาว — มาสู่เดสก์ท็อปโดยตรง และทำให้ทุกความสามารถพร้อมใช้งานจริง;
• ชั้นโมเดลหลายระดับที่รักษาการสนทนาให้ดำเนินต่อได้มากที่สุดท่ามกลางความผันผวนของคีย์/ผู้ให้บริการ/เครือข่าย;
• การประสานงานหลายเอเจนต์ในรูปแบบแชตกลุ่มที่มีผู้บัญชาการอยู่ในวง เปลี่ยนจาก “การวางแผนตายตัว” เป็น “การตัดสินใจแบบไดนามิก” และทำให้การส่งต่องานระหว่างเอเจนต์รู้สึกเป็นธรรมชาติเป็นครั้งแรก;
• ระบบนิเวศที่เปลี่ยนจากแค็ตตาล็อกแบบปิดเป็นโฮสต์แบบเปิด เปิดใช้ทั้งแพ็กเกจภายนอก ทักษะส่วนกลาง MCP ที่กำหนดเอง และสะพานเชื่อมย้อนกลับ — ขณะที่จุดควบคุมการเริ่มกระบวนการไม่ขยับแม้แต่นิดเดียว;
• พร้อมความจำและการพัฒนาตนเองที่ปิดโดยค่าเริ่มต้น มีขอบเขต และตรวจสอบได้

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