วิธีสร้าง ClawAI
บริการที่สามารถปรับใช้ได้อย่างอิสระ 18 บริการ โดยแต่ละบริการมีฐานข้อมูลของตัวเอง และประสานงานผ่านแกนหลักที่ขับเคลื่อนด้วยเหตุการณ์การตอบสนองจะสตรีมในขณะที่ถูกสร้างขึ้น และทุกเลเยอร์จะได้รับการปกป้องด้วยตัวมันเอง
ตรวจสอบครั้งล่าสุด 2026-07-27
วิธีสร้าง ClawAI
ClawAI เป็นบริการที่สามารถปรับใช้ได้อย่างอิสระจำนวน 18 บริการหลังพร็อกซีย้อนกลับเดียวการตรวจสอบสิทธิ์ การแชท การกำหนดเส้นทาง ตัวเชื่อมต่อ หน่วยความจำ ไฟล์ การค้นคว้า พื้นที่ทำงาน การสร้างรูปภาพ การส่งออกเอกสาร การเรียกเก็บเงิน การตรวจสอบ และการบันทึกการทำงานแต่ละครั้งเป็นกระบวนการของตนเองด้วยฐานข้อมูลของตัวเองเว็บแอปเข้าถึงทั้งหมดผ่านพื้นผิว API เดียว
เหตุผลก็คือการกักขังผู้ให้บริการที่ช้า การแปลงไฟล์ที่ค้าง หรือการส่งออกที่ล้มเหลว จะไม่สามารถหยุดการสนทนาได้ เนื่องจากผู้ให้บริการไม่มีการแบ่งปันกระบวนการ ไม่มีพูลการเชื่อมต่อ และไม่มีฐานข้อมูลแต่ละบริการได้รับการปรับใช้ ปรับขนาด และย้อนกลับได้ด้วยตัวเอง
- 18
- บริการที่ปรับใช้ได้อย่างอิสระ
- หนึ่งรายการต่อบริการ
- ไม่มีฐานข้อมูลที่ใช้ร่วมกันเลยทีเดียว
- HTTP + เหตุการณ์
- การโทรแบบซิงโครนัสบวกกับบัสเหตุการณ์แบบอะซิงโครนัส
- จุดเริ่มต้นหนึ่ง
- Reverse proxy เดียวที่อยู่ด้านหน้าทุกสิ่ง
บริการต่างๆ
ไม่ใช่ทุกบริการจะน่าสนใจจากภายนอกสิ่งเหล่านี้คือคำขอเดียวที่มีแนวโน้มจะสัมผัส โดยคร่าวๆ ตามลำดับที่คำขอจะสัมผัส
- การรับรองความถูกต้องPostgreSQL
- บัญชี เซสชัน การออกโทเค็นและการรีเฟรชการหมุนเวียน บทบาทและชุดสิทธิ์
- แชทPostgreSQL
- การสนทนาและข้อความ การประกอบบริบท การดำเนินการสตรีมมิ่ง และการจัดการหลายรูปแบบ
- การกำหนดเส้นทางPostgreSQL
- แยกประเภทแต่ละข้อความ ใช้โหมดที่ใช้งานอยู่และนโยบายใดๆ และบันทึกการตัดสินใจพร้อมกับห่วงโซ่ทางเลือก
- ขั้วต่อPostgreSQL
- ข้อมูลประจำตัวของผู้ให้บริการ แค็ตตาล็อกโมเดล ธงความสามารถ และการตรวจสุขภาพอย่างต่อเนื่อง
- หน่วยความจำและบริบทPostgreSQL + pgvector
- เรกคอร์ดหน่วยความจำ คิวคำแนะนำ แพ็กบริบทและเวอร์ชัน และการดึงความหมาย
- ไฟล์PostgreSQL
- การอัปโหลด การสแกนความปลอดภัย การแยกข้อความ OCR การแยกส่วนและการเก็บรักษา
- วิจัยPostgreSQL
- การค้นหาเว็บ การดึงข้อมูลหน้า และการรวบรวมหลักฐานเพื่อหาคำตอบพร้อมแหล่งที่มา
- พื้นที่ทำงานPostgreSQL
- การเชื่อมต่อ OAuth กับเครื่องมือของบุคคลที่สาม 12 รายการ เว็บฮุค การซิงค์ตามกำหนดเวลา และการค้นหาข้ามเครื่องมือ
- การสร้างภาพPostgreSQL
- คำขอรูปภาพ อะแดปเตอร์ของผู้ให้บริการ และความคืบหน้าต่อขั้นตอนขณะเรนเดอร์รูปภาพ
- การสร้างเอกสารPostgreSQL
- แสดงผลคำตอบเป็น PDF, DOCX, CSV, HTML, Markdown, TXT และ JSON
- การเรียกเก็บเงินPostgreSQL
- แผน การสมัครสมาชิก ราคาตามเวอร์ชัน ใบแจ้งหนี้ และการบังคับใช้เบี้ยเลี้ยง
- การตรวจสอบMongoDB
- บันทึกที่ไม่เปลี่ยนรูปว่าใครทำอะไร บวกกับบัญชีแยกประเภทการใช้งาน ทุกตัวเลขค่าเผื่อได้รับมาจาก
- การบันทึกMongoDB
- บันทึกที่มีโครงสร้างจากทุกบริการและจากเบราว์เซอร์ เก็บไว้ในหน้าต่างแบบเลื่อน
แต่ละบริการตั้งชื่อฐานข้อมูลที่เป็นเจ้าของไม่มีสิ่งอื่นใดที่เชื่อมต่อกับมัน — บริการที่ต้องการข้อมูลของผู้อื่นจะขอมันผ่าน HTTP หรือตอบสนองต่อเหตุการณ์
หนึ่งฐานข้อมูลต่อบริการ
ทุกบริการมีฐานข้อมูลเดียวและเป็นสิ่งเดียวที่เชื่อมต่อกับฐานข้อมูลนั้นไม่มีสคีมาที่ใช้ร่วมกัน ไม่มีการเข้าร่วมบริการข้าม และไม่มีฐานข้อมูลการรายงานที่อ่านตารางของทุกคนอย่างเงียบๆ
ค่าใช้จ่ายคือคำถามบางข้อต้องใช้การโทรสองครั้งแทนที่จะเข้าร่วมเพียงครั้งเดียวข้อดีคือการเปลี่ยนแปลงสคีมาในการเรียกเก็บเงินไม่สามารถทำให้การแชทหยุดชะงัก และการสืบค้นแบบควบคุมไม่ได้ในการบันทึกจะไม่ทำให้พูลการเชื่อมต่อที่การสนทนาของคุณขึ้นอยู่กับหมดไป
- ไม่มีการสืบค้นข้ามฐานข้อมูล
- บริการจะอ่านตารางของตัวเองและไม่มีใครอ่านตารางอื่นอีกข้อมูลจากที่อื่นมาถึงผ่านการเรียก API หรือเหตุการณ์
- สคีมาเป็นแบบส่วนตัว
- บริการสามารถเปลี่ยนตารางของตัวเองโดยไม่ต้องประสานงานกับใครเลย เนื่องจากไม่มีผู้บริโภคภายนอกขึ้นอยู่กับรูปร่างของพวกเขา
- การย้ายข้อมูลดำเนินการต่อบริการ
- แต่ละบริการจะย้ายฐานข้อมูลของตนเองเมื่อเริ่มต้นระบบไม่มีการโยกย้ายระดับโลกที่ทุกคนต้องรอ
- ความล้มเหลวยังคงอยู่ในท้องถิ่น
- ฐานข้อมูลที่ช้าหรือไม่พร้อมใช้งานจะลดความสามารถหนึ่งรายการแทนที่จะเป็นทั้งผลิตภัณฑ์
ชีวิตของหนึ่งคำขอ
จะเกิดอะไรขึ้นระหว่างการกดส่งกับการอ่านคำตอบ
คำขอได้รับการรับรองความถูกต้องแล้ว
Reverse Proxy จะส่งผ่านไปยังแชท ซึ่งจะตรวจสอบโทเค็นการเข้าถึงและการอนุญาตที่แนบมากับบทบาทของคุณ
มีการตรวจสอบเบี้ยเลี้ยงแล้ว
การเรียกเก็บเงินเป็นการยืนยันว่าแผนของคุณอนุญาตโมเดลที่คุณขอ และเบี้ยเลี้ยงรายวันและรายเดือนของคุณยังมีที่ว่างอยู่
ข้อความจะถูกจัดเก็บและประกาศ
แชทเขียนข้อความลงในฐานข้อมูลของตัวเองและเผยแพร่กิจกรรมการกำหนดเส้นทางกำลังฟังอยู่
การกำหนดเส้นทางเลือกรูปแบบ
ข้อความจะถูกจัดประเภท ใช้โหมดและนโยบายที่ใช้งานอยู่ ปรึกษาสถานภาพของตัวเชื่อมต่อ และการตัดสินใจด้วยห่วงโซ่ทางเลือกจะถูกบันทึก
มีการรวบรวมบริบท
แชทจะถามหน่วยความจำสำหรับบันทึกที่เกี่ยวข้องและแพ็ครายการ และไฟล์สำหรับชิ้นส่วนที่เกี่ยวข้อง จากนั้นจึงรวมเข้ากับพรอมต์ภายในงบประมาณโทเค็น
โมเดลถูกเรียกและสตรีม
แชทโทรหาผู้ให้บริการและส่งต่อขั้นตอน ข้อความ เหตุผล และตัวชี้วัดไปยังเบราว์เซอร์ของคุณผ่านเหตุการณ์ที่เซิร์ฟเวอร์ส่งเมื่อมาถึง
ผลลัพธ์ยังคงอยู่
คำตอบ การตัดสินใจกำหนดเส้นทาง จำนวนโทเค็น และการรับบริบทจะถูกเขียนไว้ด้วยกัน
มีการบันทึกการใช้งานและการตรวจสอบ
การเรียกเก็บเงินจะวัดค่าใช้จ่ายเทียบกับค่าใช้จ่ายของคุณและบันทึกการตรวจสอบเหตุการณ์การแยกหน่วยความจำก็ทำงานที่นี่เช่นกัน
ขั้นตอนที่ 1 ถึง 7 เป็นแบบซิงโครนัส — คุณรอก่อนขั้นตอนที่ 8 และการแยกหน่วยความจำจะเกิดขึ้นหลังจากที่คำตอบปรากฏบนหน้าจอของคุณแล้ว ดังนั้นจึงไม่เพิ่มเวลาแฝงให้กับสิ่งที่คุณพบ
รถบัสจัดงาน
งานที่ไม่จำเป็นต้องทำให้เสร็จก่อนที่คุณจะเห็นคำตอบจะถูกเผยแพร่เป็นกิจกรรมในการแลกเปลี่ยนหัวข้อ RabbitMQ และจัดการโดยบริการใดก็ตามที่สนใจการวัดการใช้งาน บันทึกการตรวจสอบ และการแยกหน่วยความจำ ล้วนทำงานในลักษณะนี้
กิจกรรมเป็นเหตุผลที่แชทไม่จำเป็นต้องรู้ว่ามีการตรวจสอบอยู่แชทระบุสิ่งที่เกิดขึ้นสิ่งใดก็ตามที่ต้องตอบสนองให้สมัครสมาชิกการเพิ่มผู้บริโภคไม่จำเป็นต้องเปลี่ยนแปลงผู้จัดพิมพ์
- การแลกเปลี่ยนหัวข้อ
- ผู้จัดพิมพ์จะพูดถึงสิ่งที่เกิดขึ้น ไม่ใช่ว่าใครควรได้ยินผู้บริโภคผูกพันกับรูปแบบที่พวกเขาใส่ใจ
- ลองอีกครั้งโดยมีการถอยกลับ
- ตัวจัดการที่ล้มเหลวจะถูกลองใหม่สามครั้งโดยมีความล่าช้าเพิ่มขึ้น ซึ่งจะดูดซับความล้มเหลวชั่วคราวที่ประกอบขึ้นเป็นส่วนใหญ่
- คิวจดหมายตาย
- ข้อความที่ยังคงล้มเหลวหลังจากลองใหม่แล้วจะไปที่คิวจดหมายที่ไม่ทำงาน แทนที่จะถูกทิ้งหรือบล็อกทุกสิ่งที่อยู่ด้านหลัง
- ตัวจัดการแบบไร้อำนาจ
- ผู้จัดการทนต่อเหตุการณ์เดียวกันที่มาถึงสองครั้ง เพราะการส่งมอบอย่างน้อยหนึ่งครั้งรับประกันว่าในที่สุดจะมีการส่งมอบ
- ทุกอย่างสามารถตรวจสอบได้
- การตรวจสอบจะสมัครรับทุกกิจกรรมในโดเมน ดังนั้นบันทึกสิ่งที่เกิดขึ้นจึงไม่ขึ้นอยู่กับแต่ละบริการที่จำเขียนไว้
สตรีมมิ่ง
คำตอบมาถึงเหตุการณ์ที่เซิร์ฟเวอร์ส่ง ไม่ใช่การสำรวจการเชื่อมต่อจะเปิดขึ้นเมื่อคุณส่งข้อความและดำเนินการทุกอย่างจนกว่าคำตอบจะเสร็จสิ้นหรือยกเลิก
การบัฟเฟอร์ถูกปิดใช้งานตั้งแต่ต้นจนจบ — ที่พร็อกซีและในทุกบริการบนเส้นทาง — เนื่องจากสตรีมที่ถูกบัฟเฟอร์เป็นเพียงการตอบสนองที่ช้าและมีขั้นตอนเพิ่มเติม
ช่องทางเดียวกันนี้ประกอบด้วยการสร้างข้อความ ความคืบหน้าในการสร้างภาพ และการวิจัยที่ใช้เวลานาน ดังนั้นอินเทอร์เฟซจึงมีวิธีเดียวในการแสดงงานระหว่างการบินแทนที่จะเป็นสามวิธี
- การเปลี่ยนแปลงขั้นตอน
- เข้าคิว กำหนดเส้นทาง รวบรวมบริบท การเรียกโมเดล เสร็จสิ้น — ดังนั้นการหยุดชั่วคราวจึงมีเหตุผลที่ชัดเจนเสมอ
- เดลต้าเนื้อหา
- ข้อความคำตอบในขณะที่โมเดลสร้างโทเค็นทีละโทเค็น
- เดลต้าการใช้เหตุผล
- สำหรับโมเดลที่เปิดเผยความคิดของตน กระแสการให้เหตุผลจะถูกส่งแยกจากคำตอบและแสดงผลแยกกันด้วย
- ตัวชี้วัดเมตริก
- โทเค็นจนถึงตอนนี้ โทเค็นต่อวินาที เวลาที่โทเค็นแรก และเวลาจริงไปที่ไหน เช่น โหลดโมเดล การประเมินหรือการสร้างทันที
- เหตุการณ์เทอร์มินัล
- สรุปการใช้งานขั้นสุดท้าย หรือข้อผิดพลาดหรือการยกเลิกที่ชัดเจนกระแสน้ำไม่เคยหยุดนิ่ง
อะไรเก็บอะไร.
ร้านค้าสี่ประเภท แต่ละประเภทใช้สำหรับสิ่งที่ดี
- PostgreSQL
- ระบบบันทึกสำหรับบัญชี การสนทนา การตัดสินใจเส้นทาง หน่วยความจำ ไฟล์ การเชื่อมต่อ และการเรียกเก็บเงิน — หนึ่งฐานข้อมูลต่อบริการ
- pgvector
- การค้นหาความคล้ายคลึงกันของเวกเตอร์ภายใน PostgreSQL ใช้เพื่อดึงความทรงจำที่เกี่ยวข้องและรายการแพ็กบริบทโดยไม่ต้องใช้ฐานข้อมูลเวกเตอร์แยกต่างหาก
- MongoDB
- กิจกรรมการตรวจสอบ บัญชีแยกประเภทการใช้งาน และบันทึกที่มีโครงสร้าง: ข้อมูลต่อท้ายในปริมาณมากเท่านั้นพร้อมหน้าต่างการเก็บรักษาแบบม้วน
- Redis
- การแคช ตัวนับขีดจำกัดอัตรา และสถานะการประสานงานระยะสั้นไม่มีอะไรที่สำคัญถูกเก็บไว้ที่นี่เท่านั้น
กลไกการรักษาความปลอดภัย
การควบคุมคอนกรีตที่มีอยู่ในผลิตภัณฑ์ไม่มีการอ้างสิทธิ์ในการรับรอง — ดูหมายเหตุในตอนท้าย
- เข้าถึงและรีเฟรชโทเค็น
- โทเค็นการเข้าถึงอายุสั้นพร้อมการหมุนเวียนการรีเฟรชการใช้โทเค็นที่หมุนเวียนซ้ำจะทำให้เซสชันใช้งานไม่ได้
- การแฮชรหัสผ่าน
- Argon2 พร้อมเกลือต่อผู้ใช้รหัสผ่านจะไม่ถูกจัดเก็บหรือบันทึกในรูปแบบที่สามารถกู้คืนได้
- การควบคุมการเข้าถึงตามบทบาท
- บทบาทมีชุดสิทธิ์ที่ชัดเจน ซึ่งบังคับใช้โดยเจ้าหน้าที่รักษาความปลอดภัยในทุกจุดสิ้นสุดของทุกบริการ ไม่ใช่แค่ในอินเทอร์เฟซเท่านั้น
- ข้อมูลรับรองที่เข้ารหัส
- ข้อมูลลับของผู้ให้บริการและตัวเชื่อมต่อจะถูกเข้ารหัสเมื่อไม่ได้ใช้งานด้วย AES-256-GCM และจะไม่ส่งคืนโดย API
- การตรวจสอบสคีมา
- เนื้อหาคำขอทั้งหมดได้รับการตรวจสอบเทียบกับ Zod schema ที่มีความยาวและขอบเขตขนาดที่ชัดเจนก่อนที่จะถึงตรรกะใดๆ
- การจำกัดอัตรา
- การควบคุมปริมาณต่อบัญชีในทุกบริการ ดังนั้นไคลเอ็นต์หนึ่งรายจึงไม่สามารถหมดความจุสำหรับคนอื่นๆ ได้
- ส่วนหัวการรักษาความปลอดภัย
- นโยบายการรักษาความปลอดภัยของเนื้อหาที่เข้มงวดพร้อม noces, HSTS และส่วนหัวเสริมมาตรฐานในทุกการตอบกลับ
- TLS ทุกที่
- TLS จากเบราว์เซอร์ไปจนถึง Edge และอีกครั้งในทุก ๆ การกระโดดภายใน พร้อมการตรวจสอบใบรับรองระหว่างบริการ
- บันทึกการแก้ไข
- โทเค็น รหัสผ่าน คีย์ API และส่วนหัวการอนุญาตจะถูกถอดออกก่อนที่จะเขียนสิ่งใดลงในบันทึก
ปัจจุบัน ClawAI ไม่มีการรับรองความปลอดภัยจากบุคคลที่สาม ไม่ใช่ SOC 2 ไม่ใช่ ISO 27001 ไม่ใช่ HIPAAเราอธิบายกลไกข้างต้นแทนที่จะบอกเป็นนัยถึงการรับรองที่เราไม่ได้รับองค์กรที่มีข้อกำหนดอย่างเป็นทางการควรยกระดับพวกเขาร่วมกับเราเพื่อให้สามารถกำหนดขอบเขตเป็นส่วนหนึ่งของการมีส่วนร่วมได้
ความสามารถในการสังเกต
ทุกบริการจะส่งสัญญาณเดียวกันในรูปแบบเดียวกัน และทั้งหมดจะไปถึงจุดที่น่าสงสัยผู้ดำเนินการตอบว่า "เกิดอะไรขึ้นกับคำขอนี้" ไม่ควรต้องเปิดไฟล์บันทึกสิบแปดไฟล์
- บันทึกที่มีโครงสร้าง
- JSON บันทึกจากทุกบริการและจากเบราว์เซอร์ จัดส่งผ่านบัสเหตุการณ์และเก็บไว้ในหน้าต่างแบบเลื่อน
- ขอความสัมพันธ์
- รหัสคำขอจะถูกสร้างขึ้นในเบราว์เซอร์และดำเนินการผ่านทุก ๆ บริการ ดังนั้นตัวระบุตัวเดียวจึงสร้างเส้นทางทั้งหมดใหม่
- กิจกรรมการตรวจสอบ
- บันทึกแยกต่างหากของการดำเนินการที่เกี่ยวข้องกับความปลอดภัยและธุรกิจที่ไม่เปลี่ยนรูป โดยแยกออกจากบันทึกการปฏิบัติงาน
- บัญชีแยกประเภทการใช้งาน
- การโทรแบบมิเตอร์ทุกครั้งจะถูกเขียนเป็นรายการบัญชีแยกประเภทตัวเลขค่าเผื่อได้มาจากบัญชีแยกประเภท ไม่ใช่จากตัวนับที่อาจลอยไป
- การรวมกลุ่มด้านสุขภาพ
- บริการเฉพาะจะสำรวจบริการอื่นๆ ทั้งหมดและรายงานมุมมองแบบรวมของสิ่งที่กำลังเกิดขึ้น
เมื่อบางสิ่งบางอย่างล้มเหลว
ผู้ให้บริการโมเดลมีการหยุดทำงาน การจำกัดอัตรา และวันที่ช้าแพลตฟอร์มนี้ถูกสร้างขึ้นเพื่อดูดซับพวกมันแทนที่จะส่งต่อให้คุณในฐานะสปินเนอร์ที่ไม่เคยแก้ไข
- โซ่ทางเลือก
- การตัดสินใจเกี่ยวกับเส้นทางทุกครั้งจะมีรายการทางเลือกอื่นตามลำดับหากโมเดลที่เลือกล้มเหลว ระบบจะพยายามครั้งถัดไปโดยอัตโนมัติและการบันทึกการทดแทน
- การหลีกเลี่ยงด้านสุขภาพ
- ตัวเชื่อมต่อจะได้รับการตรวจสอบสภาพอย่างต่อเนื่อง และผู้ให้บริการที่ล้มเหลวจะถูกข้ามโดยเราเตอร์จนกว่าจะกู้คืนได้
- ลองใหม่อย่างปลอดภัย
- ตัวจัดการเหตุการณ์ยอมรับการจัดส่งซ้ำ ดังนั้นการลองใหม่จะแก้ไขความล้มเหลวแทนที่จะเรียกเก็บเงินจากคุณสองครั้ง
- ข้อผิดพลาดสามารถมองเห็นได้
- เมื่อทุกตัวเลือกล้มเหลว ข้อผิดพลาดที่ชัดเจนจะถูกเขียนลงในการสนทนาและกดสตรีมลงไม่มีความล้มเหลวแบบเงียบๆ ที่ทำให้อินเทอร์เฟซรออยู่
- รัศมีการระเบิด
- กระบวนการที่แยกจากกันและฐานข้อมูลที่แยกจากกันหมายถึงความล้มเหลวทำให้ความสามารถหนึ่งรายการลดลงการสร้างภาพไม่ทำงานไม่ได้หยุดคุณสนทนา
สถาปัตยกรรมเดียวกันภายในเครือข่ายของคุณ
ทุกอย่างในหน้านี้อธิบายถึงบริการที่โฮสต์ แต่สถาปัตยกรรมไม่ได้เชื่อมโยงกับบริการดังกล่าวสามารถปรับใช้บริการ 18 รายการเดียวกัน บัสเหตุการณ์เดียวกัน และโมเดลข้อมูลเดียวกันภายในเครือข่ายขององค์กรได้
ในการกำหนดค่าดังกล่าว ผู้ให้บริการโมเดลภายนอกจะถูกแทนที่ด้วยโมเดล Open Weight ที่ให้บริการบน GPU ของคุณเอง ดังนั้นจึงไม่มีการแจ้ง เอกสาร หรือการสนทนาออกจากโครงสร้างพื้นฐานของคุณเป็นการมีส่วนร่วมที่มีขอบเขตมากกว่าแผนที่คุณสามารถซื้อได้ — เรากำหนดขนาดกับทีมของคุณ
เห็นมันวิ่ง.
วิธีที่เร็วที่สุดในการตัดสินสถาปัตยกรรมคือการใช้สิ่งที่สร้างขึ้นแผนแบบฟรีใช้เวลาสักครู่ในการตั้งค่า