Skip to content
← ทุกบท

บท 05

Archetype ของ repository

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

DWP รู้จัก archetype สองแบบ repository ส่วนใหญ่เป็นแบบแรก แบบที่สองมีไว้สำหรับทีมที่ประสานงาน repository หลายตัว

repository เดี่ยว

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

ลักษณะเฉพาะ:

  • โค้ดเบสเดียวที่เป็นเอกภาพ
  • แผนแก้ไขไฟล์ใน repository นี้
  • พื้นที่ทำงาน .dwp/ อยู่ที่รากของ repository

orchestrator hub

กรณีการประสานงาน: repository ที่มีหน้าที่จัดการ repository อื่น ๆ ที่นี่หน่วยของงานไม่ใช่ไฟล์แต่เป็น repository ลูก ดังนั้นแผนอาจแตกออกเป็นแผนลูกใน sub-repository และการออนบอร์ดอ่าน registry ของ repository ที่ถูกจัดการของ hub แทนที่จะอ่านโค้ดเบสเดียว เอเจนต์ให้เหตุผลเกี่ยวกับขอบเขตและการส่งต่อ — repository ใดเป็นเจ้าของงานใด และสถานะของทั้งหมดคงความสอดคล้องอย่างไร

ลักษณะเฉพาะ:

  • ประสานงาน sub-repository หลายตัว
  • แผนอาจมอบหมายไปยังแผนลูก
  • ดูแล registry ของ repository ที่ถูกจัดการ
  • พื้นที่ทำงาน .dwp/ ที่รากของ hub ติดตามสถานะข้าม repository

หลักการจำแนกประเภท

ทั้งสอง archetype มีลักษณะแตกต่างกันบนดิสก์ และเอเจนต์ตัดสินใจระหว่างสองแบบจากสัญญาณที่สามารถยืนยันได้ — ไม่ใช่จากป้ายกำกับที่ถูกบอก แผนภูมิการตัดสินใจด้านล่างแสดงเส้นทาง โดยสรุป: ถือว่า repository เป็น orchestrator hub เฉพาะเมื่อหลักฐานต้องการเท่านั้น และถือเป็น repository เดี่ยวในกรณีอื่น

เอเจนต์ควรจำแนก repository ว่าเป็น orchestrator hub เมื่อพบ git repository ที่ซ้อนกันหลายตัวหรือ submodule, registry หรือ manifest ของ repository ที่ถูกจัดการ หรือการกำหนดค่าที่ชี้ไปยัง repository ภายนอก ในกรณีที่ไม่มีสัญญาณเหล่านั้น มันจะถือว่า repository เป็น repository เดี่ยว ซึ่งเป็นค่าเริ่มต้นที่ปลอดภัย เพราะการขยายขอบเขตแผนเกินขีดจำกัดที่ไม่มีอยู่จริงนั้นแย่กว่าการทำงานภายในขีดจำกัดเดียวที่มีอยู่จริง

การออนบอร์ดแตกต่างกันอย่างไร

archetype ไม่ใช่แค่ป้ายกำกับตกแต่ง มันเปลี่ยนสิ่งที่เอเจนต์อ่าน สิ่งที่แผนอาจแตะต้อง และที่ที่สถานะถูกบันทึก

ด้าน เดี่ยว Orchestrator
ขอบเขต repository นี้ repository หลายตัว
การออนบอร์ด โครงสร้าง repository registry ของ hub
เป้าหมายแผน ไฟล์ในเครื่อง แผนลูก
สถานะ .dwp/ ในเครื่อง .dwp/ ข้าม repository

ผลในทางปฏิบัติคือ เอเจนต์ของ repository เดี่ยวให้เหตุผลเกี่ยวกับโค้ดเบสเดียวตั้งแต่ต้นจนจบ ในขณะที่เอเจนต์ orchestrator ให้เหตุผลเกี่ยวกับการประสานงาน — repository ลูกใดเป็นเจ้าของงานใด และสถานะข้าม repository คงความสอดคล้องอย่างไร

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