Skip to content
← ทุกบท

บท 05

Archetype ของ repository

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

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

repository เดี่ยว

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

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

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

orchestrator hub

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

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

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

agent workspace

archetype ที่สาม เพิ่มใน v2.2 อธิบายสิ่งที่เป็น workspace ก่อนที่จะเป็น repository: บ้านที่มีอายุยาวนานของเอเจนต์อัตโนมัติ OpenClaw workspace ไดเรกทอรีบริการ Hermes ไดเรกทอรีข้อมูลของ personal-assistant daemon persistent volume ของ cloud agent — แต่ละอย่างมีแผนที่ต้องดำเนินการ เครื่องมือที่ต้องใช้ และหน่วยความจำที่ต้องรักษา แต่อาจไม่มีโค้ดเบสที่ต้องส่งมอบ

ข้อคิดเห็นสำคัญคือ harness คือ workspace ไม่ใช่ repository โดยเฉพาะ องค์ประกอบทุกอย่างที่ DWP ติดตั้งใน repository — AGENTS.md, docs/, .agents/, .dwp/ — มีสิ่งเทียบเท่าโดยตรงใน workspace พื้นผิวของระเบียบวิธีจับคู่ได้อย่างสะอาด: ไฟล์ standing-context แทนที่ AGENTS.md ที่รากของ repo ไดเรกทอรี skill ของแพลตฟอร์มแทนที่ .agents/ และโฟลเดอร์ .dwp/ ที่รากของ workspace ไม่เปลี่ยนแปลง สิ่งที่เปลี่ยนคือบทบาทของ git ใน repository git log พกสถานะและทำให้แผน resume ได้ข้ามเซสชัน ใน workspace ที่ไม่มี git state.json ทำหน้าที่นั้น — ซึ่งเป็นเหตุผลที่ชั้นสถานะที่เครื่องอ่านได้ required สำหรับ agent workspace

ผลตอบแทนในทางปฏิบัติคือแผนแบบไม่มีผู้ดูแลข้ามคืน บนแพลตฟอร์มประเภท OpenClaw heartbeat หรือรอบ cron ตื่นเอเจนต์ รัน DWP resume protocol ดำเนินงาน atomic ถัดไป อัปเดต state.json และ yield แผน — ไม่ใช่เซสชัน — คือหน่วยของความต่อเนื่อง แผนหลายวันรอดจากการรีสตาร์ต การสลับโมเดล และขอบเขตของ session เพราะทุกสิ่งที่รอบถัดไปต้องการอยู่ในไฟล์ของแผน: เป้าหมาย ความคืบหน้าที่ทำเครื่องหมายแล้ว บันทึก gate และ checkpoint ที่แม่นยำภายในงานปัจจุบัน

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

  • ไดเรกทอรีทำงานของแพลตฟอร์มเอเจนต์อัตโนมัติ
  • AGENTS.md, .agents/ และ .dwp/ ที่รากของ workspace
  • Git เป็น recommended ไม่ใช่ required
  • state.json required เมื่อไม่มี git และสำหรับการรันแบบไม่มีผู้ดูแลใด ๆ
  • แผนโดยทั่วไปรันแบบไม่มีผู้ดูแล ขับเคลื่อนด้วย heartbeat หรือ cron ที่กำหนดเวลา

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

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

เอเจนต์ควรมองหาสัญญาณ agent workspace ก่อน: ไฟล์เอกลักษณ์แพลตฟอร์ม (เช่น SOUL.md หรือ HEARTBEAT.md ของ OpenClaw) ไม่มี application stack หลัก และเนื้อหาที่เป็นสถานะของเอเจนต์เองเป็นส่วนใหญ่ หากสัญญาณเหล่านั้นไม่มี มันมองหาสัญญาณ orchestrator: git repository ที่ซ้อนกันหลายตัวหรือ submodule, registry หรือ manifest ของ repository ที่ถูกจัดการ หรือการกำหนดค่าที่ชี้ไปยัง repository ภายนอก ในกรณีที่ไม่มีทั้งสอง มันถือว่าเป้าหมายเป็น repository เดี่ยว — ค่าเริ่มต้นที่ปลอดภัย เพราะการขยายขอบเขตแผนเกินขีดจำกัดที่ไม่มีอยู่จริงนั้นแย่กว่าการทำงานภายในขีดจำกัดเดียวที่มีอยู่จริง

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

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

ด้าน เดี่ยว Orchestrator Agent workspace
ขอบเขต repository นี้ repository หลายตัว workspace และแผนของมัน
การออนบอร์ด โครงสร้าง repository registry ของ hub ไฟล์แพลตฟอร์ม + ข้อตกลง workspace
เป้าหมายแผน ไฟล์ในเครื่อง แผนลูก repository ในเครื่องหรือภายนอก
สถานะ .dwp/ ในเครื่อง .dwp/ ข้าม repository .dwp/ + state.json (required ไม่มี git)

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

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