Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
นี่คือ คู่มือผู้ร่วมพัฒนา สำหรับนักพัฒนาแกนหลักของ OpenClaw หากคุณกำลัง
สร้าง Plugin ภายนอก ให้ดู การสร้าง plugins
แทน สำหรับเอกสารอ้างอิงสถาปัตยกรรมเชิงลึก (โมเดลความสามารถ, ความเป็นเจ้าของ,
ไปป์ไลน์การโหลด, ตัวช่วยรันไทม์) ให้ดู รายละเอียดภายในของ Plugin
- plugin = ขอบเขตความเป็นเจ้าของ
- capability = สัญญาแกนหลักที่ใช้ร่วมกัน
เมื่อใดควรสร้างความสามารถ
สร้างความสามารถใหม่เมื่อ ทั้งหมด ต่อไปนี้เป็นจริง:- มีผู้ขายมากกว่าหนึ่งรายที่อาจนำไปใช้งานได้อย่างสมเหตุสมผล
- ช่องทาง เครื่องมือ หรือ Plugin ฟีเจอร์ควรใช้งานโดยไม่ต้องสนใจผู้ขาย
- แกนหลักจำเป็นต้องเป็นเจ้าของพฤติกรรม fallback, นโยบาย, config หรือการส่งมอบ
ลำดับมาตรฐาน
- กำหนดสัญญาแกนหลักแบบมีชนิด
- เพิ่มการลงทะเบียน Plugin สำหรับสัญญานั้น
- เพิ่มตัวช่วยรันไทม์ที่ใช้ร่วมกัน
- เชื่อม Plugin ผู้ขายจริงหนึ่งตัวเพื่อเป็นหลักฐาน
- ย้ายผู้ใช้งานฟีเจอร์/ช่องทางไปใช้ตัวช่วยรันไทม์
- เพิ่มการทดสอบสัญญา
- จัดทำเอกสาร config ที่ผู้ปฏิบัติงานเห็นและโมเดลความเป็นเจ้าของ
อะไรอยู่ที่ไหน
แกนหลัก:- ชนิด request/response
- รีจิสทรีผู้ให้บริการ + การ resolve
- พฤติกรรม fallback
- สคีมา config พร้อมเมทาดาทาเอกสาร
title/descriptionที่เผยแพร่ต่อบน nested object, wildcard, array-item และ composition nodes - พื้นผิวตัวช่วยรันไทม์
- การเรียก API ของผู้ขาย
- การจัดการ auth ของผู้ขาย
- การ normalize request เฉพาะผู้ขาย
- การลงทะเบียน implementation ของความสามารถ
- เรียก
api.runtime.*หรือตัวช่วยplugin-sdk/*-runtimeที่ตรงกัน - ห้ามเรียก implementation ของผู้ขายโดยตรง
รอยต่อของผู้ให้บริการและ harness
ใช้ provider hooks เมื่อพฤติกรรมเป็นของสัญญาผู้ให้บริการโมเดล ไม่ใช่ลูปเอเจนต์ทั่วไป ตัวอย่างรวมถึงพารามิเตอร์ request เฉพาะผู้ให้บริการหลังเลือก transport, การตั้งค่า auth-profile, prompt overlays และการกำหนดเส้นทาง fallback ต่อเนื่องหลัง model/profile failover ใช้ agent harness hooks เมื่อพฤติกรรมเป็นของรันไทม์ที่กำลังดำเนินการ turn Harness สามารถจัดประเภทผลลัพธ์ความพยายามที่สำเร็จแต่ใช้งานไม่ได้ เช่น คำตอบว่าง, มีแต่ reasoning หรือมีแต่ planning เพื่อให้นโยบาย fallback ของโมเดลชั้นนอกตัดสินใจ retry ได้ รักษารอยต่อทั้งสองให้แคบ:- แกนหลักเป็นเจ้าของนโยบาย retry/fallback
- Plugin ผู้ให้บริการเป็นเจ้าของคำแนะนำ request/auth/routing เฉพาะผู้ให้บริการ
- Plugin harness เป็นเจ้าของการจัดประเภทความพยายามเฉพาะรันไทม์
- Plugin ของบุคคลที่สามส่งคืนคำแนะนำ ไม่ใช่การแก้ไขสถานะแกนหลักโดยตรง
เช็กลิสต์ไฟล์
สำหรับความสามารถใหม่ คาดว่าจะต้องแตะพื้นที่เหล่านี้:src/<capability>/types.tssrc/<capability>/...registry/runtime.tssrc/plugins/types.tssrc/plugins/registry.tssrc/plugins/captured-registration.tssrc/plugins/contracts/registry.tssrc/plugins/runtime/types-core.tssrc/plugins/runtime/index.tssrc/plugin-sdk/<capability>.tssrc/plugin-sdk/<capability>-runtime.ts- แพ็กเกจ Plugin ที่ bundled หนึ่งรายการขึ้นไป
- Config, เอกสาร, การทดสอบ
ตัวอย่างที่ทำครบแล้ว: การสร้างภาพ
การสร้างภาพทำตามรูปแบบมาตรฐาน:- แกนหลักกำหนด
ImageGenerationProvider - แกนหลักเปิดเผย
registerImageGenerationProvider(...) - แกนหลักเปิดเผย
runtime.imageGeneration.generate(...) - Plugin
openai,google,falและminimaxลงทะเบียน implementation ที่มีผู้ขายรองรับ - ผู้ขายในอนาคตลงทะเบียนสัญญาเดียวกันได้โดยไม่ต้องเปลี่ยนช่องทาง/เครื่องมือ
agents.defaults.imageModelวิเคราะห์ภาพagents.defaults.imageGenerationModelสร้างภาพ
เช็กลิสต์การตรวจทาน
ก่อนส่งความสามารถใหม่ ให้ตรวจสอบว่า:- ไม่มีช่องทาง/เครื่องมือใด import โค้ดผู้ขายโดยตรง
- ตัวช่วยรันไทม์คือเส้นทางที่ใช้ร่วมกัน
- มีการทดสอบสัญญาอย่างน้อยหนึ่งรายการที่ยืนยันความเป็นเจ้าของแบบ bundled
- เอกสาร config ระบุชื่อโมเดล/คีย์ config ใหม่
- เอกสาร Plugin อธิบายขอบเขตความเป็นเจ้าของ
ที่เกี่ยวข้อง
- รายละเอียดภายในของ Plugin — โมเดลความสามารถ, ความเป็นเจ้าของ, ไปป์ไลน์การโหลด, ตัวช่วยรันไทม์
- การสร้าง plugins — บทแนะนำ Plugin แรก
- ภาพรวม SDK — เอกสารอ้างอิง import map และ API การลงทะเบียน
- การสร้าง Skills — พื้นผิวสำหรับผู้ร่วมพัฒนาที่ใช้คู่กัน