ถ้าคุณได้ติดตามวงจรการเปลี่ยนชื่อ Moltbot → Clawdbot → OpenClaw คุณอาจจะกำลังถามคำถามในทางปฏิบัติแบบเดียวกับคนอื่น ๆ:
"ฉันต้องจ่ายค่าอะไรบ้าง และต้องใช้คีย์อะไรบ้างเพื่อให้ OpenClaw ทำงานได้อย่างน่าเชื่อถือ?"
คู่มือนี้จะให้คำตอบทางเทคนิคแก่คุณ ไม่ใช่ข้อความทางการตลาด เราจะอธิบายรายละเอียดโดยแบ่งตามสถาปัตยกรรม, ขอบเขตคุณสมบัติ, รูปแบบค่าใช้จ่าย และความเสี่ยงในการดำเนินงาน
คำตอบสั้นๆ
OpenClaw มักจะเป็น ตัวจัดการ (orchestrator) ไม่ใช่โมเดลเดียวที่โฮสต์อยู่ ในการตั้งค่าส่วนใหญ่ คุณต้องมี:
- คีย์ API ของผู้ให้บริการ LLM อย่างน้อยหนึ่งรายการ (สำหรับการให้เหตุผล/แชท/การใช้เครื่องมือ)
- คีย์ของผู้ให้บริการ embedding เสริม (หากคุณใช้หน่วยความจำเชิงความหมาย/การดึงข้อมูล)
- คีย์ reranker เสริม (หาก RAG stack ของคุณใช้ reranking)
- คีย์ API สำหรับเว็บ/การค้นหาเสริม (สำหรับเครื่องมือการท่องเว็บ)
- คีย์สำหรับเสียงเสริม (STT/TTS สำหรับเวิร์กโฟลว์เสียง)
- คีย์สำหรับการตรวจสอบเสริม (LangSmith, Helicone, OpenTelemetry backend ฯลฯ)
- การสมัครสมาชิกคลาวด์/รันไทม์ เฉพาะในกรณีที่คุณปรับใช้โครงสร้างพื้นฐานที่มีการจัดการ (เช่น DigitalOcean droplets, ฐานข้อมูลที่มีการจัดการ, ที่เก็บอ็อบเจกต์)
คุณ ไม่ จำเป็นต้องมีทั้งหมดนี้เสมอไป
การติดตั้งขั้นต่ำสามารถทำงานได้ด้วยคีย์ LLM เดียวและการจัดเก็บข้อมูลในเครื่อง
ทำไมเรื่องนี้ถึงสร้างความสับสนในชุมชน OpenClaw
โพสต์ในชุมชนเกี่ยวกับ OpenClaw (heartbeats, ความวุ่นวายในการเปลี่ยนชื่อ, บทช่วยสอนการผลิต, sandboxing) สะท้อนความจริงหลักประการหนึ่ง:
- ผู้คนติดตั้ง OpenClaw โดยคาดหวังว่าเป็น SaaS แบบรวมศูนย์
- แต่ OpenClaw มักจะทำหน้าที่เหมือน control plane สำหรับบริการภายนอกหลายรายการ
ดังนั้น "รอยเท้าการสมัครสมาชิก" ของคุณจึงขึ้นอยู่กับคุณสมบัติที่คุณเปิดใช้งาน
โมเดลทางความคิดที่เป็นประโยชน์:
- แกนหลักของ OpenClaw: การกำหนดเส้นทาง, การจัดการเครื่องมือ, การจำลองหน่วยความจำ, ลูปเอเจนต์
- ผู้ให้บริการของคุณ: โมเดล, เวกเตอร์, การค้นหา, การวัดและส่งข้อมูลทางไกล, ที่เก็บข้อมูล
- โครงสร้างพื้นฐานของคุณ: การประมวลผล + ความลับ + เครือข่าย + การคงอยู่ของข้อมูล
ตารางข้อมูลรับรอง: คุณสมบัติ → คีย์/การสมัครสมาชิก
| ความสามารถของ OpenClaw | โดยทั่วไปที่จำเป็น | ตัวอย่างทั่วไป |
|---|---|---|
| การแชท/การให้เหตุผล | คีย์ LLM API | OpenAI, Anthropic, Groq, local gateway |
| เอเจนต์ที่เรียกใช้เครื่องมือ | คีย์ LLM ที่รองรับเครื่องมือ/ฟังก์ชัน | เช่นเดียวกับข้างต้น |
| หน่วยความจำเชิงความหมายระยะยาว | คีย์ Embedding + ข้อมูลรับรอง Vector DB | OpenAI/Cohere embeddings + Pinecone/Weaviate/pgvector |
| เครื่องมือค้นหา/เรียกดู | คีย์ Search API | Tavily, SerpAPI, custom crawler backend |
| การดำเนินการโค้ด / sandbox | โทเค็นบริการ Sandbox | รันไทม์คอนเทนเนอร์ที่โฮสต์เอง, เครื่องมือ sandbox ที่ปลอดภัย |
| อินพุต/เอาต์พุตเสียง | คีย์ STT/TTS | Deepgram, ElevenLabs, API เสียงบนคลาวด์ |
| การติดตาม/การตรวจสอบ | โทเค็น Observability | LangSmith, Helicone, OTLP collector auth |
| คุณสมบัติสำหรับทีม | การสมัครสมาชิก OpenClaw/องค์กรแบบโฮสต์ (ถ้ามี) | ที่นั่งสำหรับโปรเจกต์/องค์กร, control plane แบบโฮสต์ |
หากคุณต้องการเพียงแค่ "แชท + เครื่องมือพื้นฐาน" คีย์โมเดลเดียวก็เพียงพอแล้ว
การตั้งค่าที่ใช้งานได้จริงแบบขั้นต่ำ
1) การเริ่มต้นการพัฒนาในเครื่อง (ต้นทุนต่ำที่สุด)
- 1 คีย์ LLM
- SQLite/Postgres ในเครื่อง
- ไม่มี embeddings, ไม่มี reranker
- ไม่มีการติดตามแบบโฮสต์
ใช้สิ่งนี้เพื่อตรวจสอบตรรกะการจัดการและการทำงานของ prompt
2) การเตรียมการสำหรับ RAG
- คีย์ LLM
- คีย์ Embedding
- ข้อมูลรับรอง Vector DB
- คีย์ reranker เสริม
- คีย์ Search API เสริม
ใช้สิ่งนี้สำหรับการทดสอบคุณภาพบนปริมาณงานที่เน้นการดึงข้อมูล
3) สแต็กเอเจนต์สำหรับการผลิต
- คีย์ LLM หลัก + สำรอง
- ข้อมูลรับรอง Embedding + Vector DB
- คีย์ค้นหา/เรียกดู
- โทเค็น Observability
- โทเค็น/รันไทม์การดำเนินการ Sandbox
- การสมัครสมาชิกโครงสร้างพื้นฐานคลาวด์ (การประมวลผล, DB, ที่เก็บอ็อบเจกต์, ความลับ)
ใช้สิ่งนี้เมื่อเวลาทำงานและความปลอดภัยมีความสำคัญ
การแลกเปลี่ยนทางสถาปัตยกรรมที่ขับเคลื่อนจำนวนการสมัครสมาชิก
การแลกเปลี่ยน 1: ผู้ให้บริการรายเดียวเทียบกับการกำหนดเส้นทางจากหลายผู้ให้บริการ
- ผู้ให้บริการรายเดียว: การตรวจสอบสิทธิ์ที่ง่ายกว่า, การเรียกเก็บเงินที่ง่ายกว่า
- หลายผู้ให้บริการ: ความยืดหยุ่นที่ดีกว่าและการทำกำไรจากราคาที่แตกต่างกัน, ความซับซ้อนในการจัดการคีย์มากขึ้น
หากคุณใช้การสลับโมเดลในกรณีที่เกิดข้อผิดพลาด (เช่น โมเดลพรีเมียมสำหรับงานที่ซับซ้อน, โมเดลที่ถูกกว่าสำหรับ heartbeats) คุณอาจจะต้องดูแลคีย์หลายรายการ
การแลกเปลี่ยน 2: Vector DB แบบโฮสต์เทียบกับ pgvector ที่โฮสต์เอง
- Vector DB แบบโฮสต์: เปิดใช้งานได้รวดเร็ว, มีค่าใช้จ่ายเพิ่มเติมและโทเค็น API
- pgvector ที่โฮสต์เอง: ใช้คีย์ผู้ขายน้อยลง, มีค่าใช้จ่ายในการดำเนินงานสูงขึ้น
การแลกเปลี่ยน 3: Observability ที่มีการจัดการเทียบกับบันทึก DIY
- การติดตามแบบมีการจัดการ: วิเคราะห์สาเหตุหลักได้เร็วขึ้น, มีโทเค็น/ค่าใช้จ่ายเพิ่มเติม
- DIY: ต้นทุนโดยตรงต่ำกว่า, ใช้เวลาในการแก้ไขข้อผิดพลาดสูงขึ้น
ในระบบเอเจนต์ เวลาในการแก้ไขข้อผิดพลาดมักจะเป็นศูนย์ต้นทุนที่ซ่อนอยู่ อย่าเพิ่งลดความสำคัญส่วนนี้เร็วเกินไป
รูปแบบการควบคุมต้นทุน: "ตรวจสอบราคาถูกก่อน, ใช้โมเดลเมื่อจำเป็นเท่านั้น"
รูปแบบหนึ่งที่พูดคุยกันในชุมชนคือ heartbeat gating: ตรวจสอบต้นทุนต่ำก่อนการเรียกใช้โมเดลที่มีราคาแพง
การใช้งานจริง:
- ตรวจสอบความใหม่/สถานะด้วยการตรวจสอบแบบกำหนดค่าได้
- ใช้กฎเกณฑ์ป้องกัน
- เรียกใช้โมเดลในระดับที่ถูกกว่า
- ยกระดับไปใช้โมเดลพรีเมียมเฉพาะเมื่อความเชื่อมั่นลดลง
สิ่งนี้จะเปลี่ยนกลยุทธ์คีย์ของคุณโดยตรง:
- เก็บคีย์/โปรเจกต์แยกกันสำหรับแต่ละระดับ
- กำหนดขีดจำกัดงบประมาณสำหรับผู้ให้บริการแต่ละราย
- กำหนดเส้นทางตามประเภทเจตนาและคะแนนความเชื่อมั่น
รูปแบบตัวแปรสภาพแวดล้อมที่แนะนำ
ใช้ตัวแปรที่ชัดเจนและมีขอบเขตเพื่อความสะดวกในการหมุนเวียนคีย์และการตอบสนองต่อเหตุการณ์
การกำหนดเส้นทางโมเดลหลัก
OPENCLAW_LLM_PRIMARY_PROVIDER=openai OPENCLAW_LLM_PRIMARY_KEY=... OPENCLAW_LLM_FALLBACK_PROVIDER=anthropic OPENCLAW_LLM_FALLBACK_KEY=...การดึงข้อมูล
OPENCLAW_EMBED_PROVIDER=openai OPENCLAW_EMBED_KEY=... VECTOR_DB_URL=... VECTOR_DB_API_KEY=...เครื่องมือ
SEARCH_API_KEY=... SANDBOX_API_TOKEN=...การตรวจสอบ
LANGSMITH_API_KEY=... OTEL_EXPORTER_OTLP_ENDPOINT=... OTEL_EXPORTER_OTLP_HEADERS=authorization=Bearer ...ความปลอดภัย
OPENCLAW_ENCRYPTION_KEY=...เคล็ดลับ:
- ห้ามใช้คีย์เดียวกันซ้ำกันในสภาพแวดล้อม dev/staging/prod
- หมุนเวียนคีย์อย่างน้อยทุกไตรมาส
- จำกัดสิทธิ์ของโทเค็นให้มีน้อยที่สุด
- คั่นหน้าแดชบอร์ดอัตราการจำกัดของผู้ให้บริการแต่ละรายไว้
ความปลอดภัยและ Sandboxing: การสมัครสมาชิกที่คุณจะเสียใจที่ไม่ได้ใช้
หากเอเจนต์ OpenClaw ของคุณดำเนินการโค้ด, ท่องเว็บ, หรือใช้เครื่องมือเกี่ยวกับระบบไฟล์/เครือข่าย ควรมีเลเยอร์ sandbox การที่ชุมชนให้ความสำคัญกับ sandboxes ที่ปลอดภัยนั้นมีเหตุผล
อย่างน้อยที่สุด:
- การควบคุมการส่งข้อมูลออกทางเครือข่าย
- สภาพแวดล้อมการดำเนินการชั่วคราว
- โควต้าทรัพยากร (CPU, หน่วยความจำ, รันไทม์)
- นโยบายอนุญาต/ปฏิเสธคำสั่ง
- ข้อจำกัดการเมานต์ไฟล์
สิ่งนี้อาจนำไปสู่บริการ/โทเค็นเพิ่มเติม แต่ช่วยลดความเสี่ยงหายนะ
การทดสอบการตั้งค่าคีย์ของคุณด้วย Apidog
เมื่อคุณเชื่อมต่อคีย์แล้ว คุณจะต้องมีการตรวจสอบ API ที่ทำซ้ำได้ นี่คือจุดที่ Apidog เข้ามามีบทบาทอย่างเป็นธรรมชาติ
ใช้ Apidog เพื่อ:
- กำหนด API เกตเวย์ OpenClaw ของคุณในสเปก OpenAPI
- เรียกใช้ การทดสอบอัตโนมัติ ข้ามสภาพแวดล้อม (dev/staging/prod)
- เพิ่ม การยืนยันด้วยภาพ สำหรับโครงสร้างการตอบกลับ, เอาต์พุตเครื่องมือ, และข้อมูลข้อผิดพลาด
- จำลองความล้มเหลวของผู้ให้บริการด้วย smart mock เพื่อทดสอบตรรกะการสลับ
- เผยแพร่ เอกสารเชิงโต้ตอบ สำหรับทีมภายในของคุณ
หากคุณกำลังพัฒนาอย่างรวดเร็ว สิ่งนี้จะช่วยป้องกันคีย์/การกำหนดค่าที่ไม่ตรงกันไม่ให้ทำให้ระบบการผลิตล้มเหลวโดยไม่รู้ตัว
ตัวอย่างกรณีทดสอบที่คุณควรอัตโนมัติ
- เส้นทางคีย์หายไป: ตรวจสอบการจัดการข้อผิดพลาด 401/500 และข้อความแสดงข้อผิดพลาดที่ชัดเจน
- เส้นทางจำกัดอัตรา: จำลองข้อผิดพลาด 429 ของผู้ให้บริการและยืนยันการกำหนดเส้นทางสำรอง
- เส้นทางป้องกันงบประมาณ: ปฏิเสธการใช้งานโมเดลราคาแพงเมื่อถึงขีดจำกัด
- เส้นทางปฏิเสธ Sandbox: ตรวจสอบให้แน่ใจว่าการเรียกใช้เครื่องมือที่ถูกบล็อกล้มเหลวอย่างปลอดภัย
- เส้นทางการเสื่อมสภาพของ RAG: การหยุดทำงานของ embedding/vector ควรลดประสิทธิภาพลงอย่างนุ่มนวล
ใน Apidog คุณสามารถจัดกลุ่มสิ่งเหล่านี้เป็นชุดสถานการณ์และเรียกใช้ในการผสานรวม/ส่งมอบอย่างต่อเนื่อง (CI/CD) เป็นเกตการเผยแพร่
รายการตรวจสอบการแก้ไขข้อผิดพลาดเมื่อ "OpenClaw มีปัญหา"
การหยุดทำงานส่วนใหญ่เกิดจากข้อมูลรับรองหรือโควต้า ไม่ใช่ข้อผิดพลาดในการจัดการ
ตรวจสอบตามลำดับนี้:
- การมีอยู่ของคีย์: ตัวแปรสภาพแวดล้อมถูกโหลดในคอนเทนเนอร์รันไทม์หรือไม่?
- ขอบเขตของคีย์: โทเค็นมีสิทธิ์เข้าถึงปลายทางโมเดลที่ต้องการหรือไม่?
- การจำกัดอัตรา/โควต้า: แดชบอร์ดของผู้ให้บริการแสดงการจำกัดหรือไม่?
- ภูมิภาคปลายทางไม่ถูกต้อง: โมเดล/คีย์เชื่อมโยงกับภูมิภาคอื่นหรือไม่?
- เวลาคลาดเคลื่อน / เฮดเดอร์การตรวจสอบสิทธิ์: คำขอที่ลงชื่อล้มเหลวเนื่องจากการคลาดเคลื่อนของเวลาหรือไม่?
- Fallback ถูกปิดใช้งาน: การพิมพ์ผิดในการกำหนดค่าทำให้ไม่สามารถใช้ผู้ให้บริการสำรองได้หรือไม่?
- Vector index ไม่ตรงกัน: โมเดล embedding เปลี่ยนไปแต่ index ไม่ได้ถูกสร้างใหม่หรือไม่?
เพิ่มรหัสข้อผิดพลาดที่มีโครงสร้างในเกตเวย์ของคุณเพื่อให้บันทึกสามารถแยกแยะข้อผิดพลาดในการตรวจสอบสิทธิ์, โควต้า, การกำหนดเส้นทาง, และเครื่องมือได้
กรอบการตัดสินใจ: สิ่งที่คุณต้องการจริงๆ ในวันนี้
ใช้ตารางนี้อย่างรวดเร็ว:
- การทดลองส่วนตัว/ในเครื่อง → คีย์ LLM หนึ่งรายการ
- ผู้ช่วยความรู้พร้อมเอกสาร → LLM + embeddings + vector DB
- ผู้ช่วยที่รู้จักเว็บ → เพิ่มคีย์การค้นหา
- เอเจนต์เสียง → เพิ่มคีย์ STT/TTS
- ระบบการผลิตสำหรับทีม → เพิ่ม observability + sandbox + การสลับผู้ให้บริการหลายรายในกรณีที่เกิดข้อผิดพลาด
หลีกเลี่ยงการขยายผู้ให้บริการโดยไม่จำเป็น เพิ่มการสมัครสมาชิกเมื่อคุณสมบัติเปิดใช้งานและได้รับการทดสอบแล้วเท่านั้น
ข้อผิดพลาดที่พบบ่อย
การซื้อการสมัครสมาชิกทั้งหมดล่วงหน้า
- นำไปสู่ความซับซ้อนและค่าใช้จ่ายที่ไม่ได้ใช้ประโยชน์
การใช้คีย์เดียวในทุกสภาพแวดล้อม
- ทำให้การควบคุมเหตุการณ์เป็นเรื่องยากลำบาก
ไม่มีกลยุทธ์โมเดลสำรอง
- การหยุดทำงานของผู้ให้บริการรายเดียวกลายเป็นการหยุดทำงานของแอปพลิเคชัน
การข้ามการติดตาม
- คุณไม่สามารถปรับปรุงสิ่งที่คุณไม่สามารถสังเกตได้
ไม่มีการทดสอบสัญญาบนเกตเวย์ของคุณ
- การเปลี่ยนแปลง schema โดยไม่แจ้งให้ทราบจะทำให้ไคลเอ็นต์ใช้งานไม่ได้
คำตอบสุดท้าย
สำหรับนักพัฒนาส่วนใหญ่ สิ่งที่จำเป็นขั้นต่ำในการรัน OpenClaw คือ:
- คีย์ LLM API หนึ่งรายการ
สำหรับทีมการผลิตส่วนใหญ่ เกณฑ์มาตรฐานที่เป็นจริงคือ:
- คีย์ LLM หลัก + สำรอง
- ข้อมูลรับรอง Embedding + Vector DB
- คีย์การค้นหาเสริม (หากจำเป็นสำหรับการเรียกดู/ปรับปรุง RAG)
- โทเค็น Observability
- การควบคุม Sandbox/รันไทม์
- การสมัครสมาชิกคลาวด์สำหรับโครงสร้างพื้นฐานการปรับใช้
ปฏิบัติต่อ OpenClaw เหมือนเป็นเลเยอร์การจัดการ กลยุทธ์คีย์ของคุณควรสะท้อนสถาปัตยกรรมของคุณ ไม่ใช่กระแสที่ได้รับความนิยม