ฉันสร้างระบบปฏิบัติการ AI ทำงานร่วมกัน 5 บทบาทด้วย OpenClaw: เจาะลึกทางเทคนิคแบบเต็มรูปแบบ

ฉันใช้เวลานานมากในการเปลี่ยน OpenClaw จากผู้ช่วยคนเดียวให้เป็นระบบปฏิบัติการแบบร่วมมือที่มีหลายบทบาท มันไม่ใช่แค่ "เปิดบอทสองสามตัวมาแชทแยกกัน" เท่านั้น

บทบาท AI 5 บทบาท แชร์เกตเวย์เดียว ทำงานบนช่องคู่ Discord และ Telegram มีการแบ่งงานกันชัดเจน การกำหนดเส้นทาง การแยกหน่วยความจำ และกฎการทำงานร่วมกัน สามารถทำงานแบบผลัดกันเหมือนทีม

ในบทความนี้ ฉันจะแจกแจงกระบวนการสร้างทั้งหมด การตัดสินใจออกแบบในแต่ละชั้น การกำหนดค่าเฉพาะ และปัญหาที่ฉันเจอ

ถ้าคุณกำลังใช้ OpenClaw อยู่หรือสนใจ "วิธีทำให้ AI หลายตัวทำงานร่วมกันได้จริง" บทความนี้น่าจะช่วยคุณหลีกเลี่ยงทางอ้อมมากมาย

สรุปก่อนเลย: นี่ไม่ใช่ "หลายบอท" แต่มันคือ OS แบบหลาย Agent ภายใต้ Gateway เดียว

เวลาหลายคนได้ยิน "บทบาท AI 5 บทบาท" ปฏิกิริยาแรกคือ: คุณกำลังรันบอทอิสระ 5 ตัวใช่ไหม?

ใช่ แต่ก็ไม่ใช่

สถาปัตยกรรมของฉันเป็นแบบนี้:

• 1 โพรเซส Gateway ที่รวมการเข้าถึงช่องทางและการกำหนดเส้นทาง
• 5 Agent อิสระ: Commander, Strategist, Engineer, Creator, Thinker
• แต่ละ Agent มีพื้นที่ทำงานอิสระของตัวเอง (บุคลิกภาพ กฎ หน่วยความจำ และเซสชันแยกจากกันทั้งหมด)
• รันช่องคู่ Discord + Telegram พร้อมกัน (สามารถรันได้หลายแพลตฟอร์ม แต่ฉันใช้แค่ Discord) ใช้ bindings เพื่อกระจายข้อความอย่างแม่นยำ
• แชทส่วนตัวและแชทกลุ่มใช้กลไกที่แตกต่างกันโดยสิ้นเชิง

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

OpenClaw เองเป็นเฟรมเวิร์กผู้ช่วย AI ส่วนตัวแบบโอเพนซอร์สที่รองรับหลายแพลตฟอร์ม (Discord, Telegram, WhatsApp ฯลฯ) และหลายโมเดล (Claude, GPT, Gemini ฯลฯ) พร้อมข้อมูลที่จัดเก็บในเครื่องทั้งหมด

ความสามารถหลาย Agent คือเหตุผลหลักที่ฉันเลือกมัน—รองรับพื้นที่ทำงานอิสระหลาย Agent + การกำหนดเส้นทาง bindings ซึ่งทำให้ฉันสามารถสร้างระบบการทำงานร่วมกันที่แท้จริงบนนั้นได้

1. สถาปัตยกรรมโดยรวม: Gateway เดียว + หลาย Agent + หลายพื้นที่ทำงาน + หลายช่องทาง

ก่อนอื่น มาพูดถึงการตัดสินใจทางสถาปัตยกรรมระดับล่างกันก่อน

1) โฮสติ้งแบบรวมผ่าน Gateway เดียว

ตอนนี้ฉันมีโพรเซส OpenClaw Gateway ตัวเดียวที่รับผิดชอบความสามารถทั้งหมด—การเข้าถึงข้อความ การกำหนดเส้นทาง การจัดการเซสชัน การเรียกใช้เครื่องมือ การจัดทำดัชนีหน่วยความจำ และการจัดการสถานะ ทั้งหมดอยู่ใน Gateway เดียว

ทำไมไม่รันชุดบริการสำหรับแต่ละบทบาท? สามเหตุผล:

• การบำรุงรักษาแบบรวมศูนย์: ต้องดูแล Gateway แค่ตัวเดียว ไม่ต้องรันบริการอิสระสำหรับแต่ละบทบาท
• การกำหนดค่าแบบรวมศูนย์: ไฟล์คอนฟิกหลักเดียวจัดการกลยุทธ์ทั่วโลก และการตรวจสอบ/แก้ไขปัญหาก็รวมศูนย์เช่นกัน
• พื้นฐานสำหรับการทำงานร่วมกัน: เพื่อให้บทบาทต่างๆ ทำงานร่วมกันได้ พวกเขาต้องอยู่ในรันไทม์เดียวกันเพื่อการสื่อสารที่มีประสิทธิภาพ

2) 5 Agent แบบขนาน ไม่ใช่ 5 บอทที่หลวมๆ

บทบาทคงที่ 5 บทบาทของฉัน:

• Commander (ผู้บัญชาการ): การรับรู้สถานการณ์ทั่วโลก การแบ่งย่อยงาน การมอบหมาย การแก้ไข และการปิดงาน
• Strategist (นักยุทธศาสตร์): การวิเคราะห์เชิงกลยุทธ์ การประเมินข้อเสนอ และการพยากรณ์ความเสี่ยง
• Engineer (วิศวกร): การดำเนินการทางเทคนิค การเขียนโค้ด และการบำรุงรักษาระบบ
• Creator (ผู้สร้าง): การสร้างเนื้อหา การปรับปรุงการแสดงออก และผลลัพธ์ภายนอก
• Thinker (นักคิด): การตรวจสอบความรู้ การควบคุมคุณภาพ และการตรวจสอบการปฏิบัติตาม

แต่ละ Agent มีพื้นที่ทำงานของตัวเอง เช่น workspace-engineer, workspace-junshi ฯลฯ ไฟล์บุคลิกภาพ ไฟล์กฎ ไฟล์หน่วยความจำ และทรัพย์สินสคริปต์ล้วนเป็นอิสระและไม่ปนเปื้อนกัน

3) การเข้าถึงแบบ Dual-Stack หลายช่องทาง: Discord + Telegram

Gateway เดียวกันเชื่อมต่อกับทั้ง Discord และ Telegram แต่ละบทบาทมีการผูกมัดระดับ accountId บนทั้งสองช่องทาง แน่นอน คุณสามารถใช้ไฟล์คอนฟิกเดียวกันนี้เพื่อรวมแพลตฟอร์มเพิ่มเติม เช่น Lark, WeChat ฯลฯ

นี่ไม่ใช่ "การปรับใช้ซ้ำข้ามแพลตฟอร์ม" แต่เป็น "คลัสเตอร์สมองเดียวกัน ชั้นการเข้าถึงที่แตกต่างกัน" ฉันกำหนดให้ Discord เป็นสนามรบหลักในการทำงานร่วมกัน

ถ้าคุณต้องการให้หลาย Agent ทำงานร่วมกันและทำงานร่วมกันภายในกลุ่ม ให้เลือก Discord แค่แพลตฟอร์มเดียวก็พอ แพลตฟอร์มอื่นไม่สมบูรณ์แบบ ฉันลองมาแล้ว!!!

2. ชั้นการกำหนดเส้นทาง: Bindings จับคู่ "บัญชี" กับ "บทบาท"

นี่คือตรรกะเริ่มต้นของทั้งระบบ

ฉันกำหนดกลยุทธ์การผูกมัดที่ชัดเจนสำหรับช่องทางคู่: channel + accountId -> agentId

โดยเฉพาะ:

• discord + zongzhihui -> zongzhihui
• discord + engineer -> engineer
• telegram + creator -> creator
• ... รวมทั้งหมด 10 การแมป (5 บทบาท × 2 ช่องทาง)

ทำไมต้องทำแบบนี้?

เพราะระบบตัดสินใจว่า "ใครควรจัดการข้อความนี้" ที่ชั้นเริ่มต้น แทนที่จะปล่อยให้ Agent ทั้งหมดได้ยินแล้วแย่งกันตอบ ถ้าขั้นตอนนี้ทำไม่ดี การทำงานร่วมกันที่ตามมาทั้งหมดจะวุ่นวาย

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

3. การแยกเซสชัน: ทำไมแชทส่วนตัวไม่ปนกัน และแชทกลุ่มไม่ยุ่งเหยิง

นี่คือหนึ่งในจุดทางวิศวกรรมที่สำคัญที่สุดในระบบของฉัน

การกำหนดค่าหลัก: session.dmScope = per-account-channel-peer

พารามิเตอร์นี้หมายถึง: บริบทแชทส่วนตัวถูกแยกตามสามมิติ: "บัญชี + ช่องทาง + ผู้ใช้ปลายทาง"

ทำไมเลือกแบบนี้?

• ถ้าคนเดียวกันติดต่อบทบาทเดียวกันผ่าน Discord และ Telegram บริบทจะไม่ปนกัน
• ถ้าผู้ใช้ต่างกันติดต่อบทบาทเดียวกัน บริบทจะถูกแยกออกจากกันโดยสิ้นเชิง
• ในสถานการณ์หลาย Agent + หลายบัญชี ความเสี่ยงของ "การพูดข้าม" จะลดลง

กล่าวอีกนัยหนึ่ง ฉันไม่ได้แค่สร้าง "หลายบทบาท" ฉันยังทำ "วิศวกรรมกลยุทธ์การแยกบริบท" ด้วย

หลายคนสร้างระบบหลาย Agent ที่บทบาทถูกแบ่งแยกอย่างชัดเจน แต่การจัดการบริบทกลับยุ่งเหยิง—เนื้อหาแชทส่วนตัวของผู้ใช้ A ไปลงในคำตอบของผู้ใช้ B หรือหน่วยความจำการสนทนาบน Discord ปนเปื้อนบริบทของ Telegram

per-account-channel-peer คือกลยุทธ์การแยกที่ OpenClaw แนะนำสำหรับสถานการณ์หลายบัญชี และจากการทดสอบของฉัน มันคือตัวเลือกที่เสถียรที่สุดจริงๆ

4. การ Orchestration แชทกลุ่ม: การทำงานร่วมกันที่ขับเคลื่อนด้วยกฎ ไม่ใช่การแชทอิสระ

ส่วนนี้น่าสนใจที่สุดและมีปัญหามากที่สุด

กลยุทธ์หลัก: Commander ฟังทั่วโลก + บทบาทอื่นๆ ถูกเรียกใช้โดย @

กลยุทธ์แชทกลุ่มของฉันในฝั่ง Discord เป็นดังนี้:

Commander: requireMention = false (ฟังทั่วโลก)

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

บทบาทอื่นๆ อีก 4 บทบาท: `requireMention = true` (ถูกเรียกใช้โดย @)

• จะดำเนินการก็ต่อเมื่อถูก @ อย่างชัดเจนเท่านั้น
• ลดสัญญาณรบกวนและหลีกเลี่ยงการพูดทับกัน

แต่ละบทบาทถูกกำหนดค่าด้วย `mentionPatterns`

• ตัวอย่างเช่น วิศวกรสามารถถูกเรียกใช้โดย @Engineer หรือ [@engineer](https://x.com/@engineer)
• ทำให้การเรียกใช้ในกลุ่มมีความเสถียรและคาดเดาได้มากขึ้น

สาระสำคัญของการรวมกันนี้คืออะไร?

• Commander "มองเห็นภาพใหญ่" เหมือน PM ในทีม
• บทบาทเฉพาะทาง "ถูกเรียกใช้ตามความจำเป็น" เหมือนผู้เชี่ยวชาญในตำแหน่งต่างๆ
• การพูดในกลุ่มเปลี่ยนจาก "รูปแบบอิสระ" เป็น "การส่งต่อที่ควบคุมได้"

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

5. Discord vs Telegram: ทำไม Discord ถึงเป็นสนามรบหลัก

พูดอย่างเคร่งครัด ไม่ใช่แค่ "มีแค่ Discord ที่ทำงานร่วมกันได้" แต่มันคือภายใต้การกำหนดค่าปัจจุบันของฉัน Discord เหมาะสมที่สุดสำหรับการ orchestration การทำงานร่วมกันแบบหลายบทบาทในที่สาธารณะ

เหตุผลเฉพาะ:

1. ฉันกำหนดค่าบัญชีแบบขนาน 5 บัญชีบน Discord + กลไก @ การทำงานร่วมกันที่ชัดเจน
2. ข้อมูลประจำตัวของบทบาท ห่วงโซ่การสนทนา และกระบวนการส่งต่อสามารถมองเห็นได้ทั้งหมด—ดูเหมือนการอภิปรายของทีม
3. กลยุทธ์ของ Commander ฟังทั่วโลก + ประตูการกล่าวถึงของบทบาทอื่นๆ ใช้งานง่ายกว่าในสถานการณ์แชทกลุ่ม
4. ตอนนี้ฉันตั้งค่า groupPolicy ของ Discord เป็น open ซึ่งให้ความยืดหยุ่นสูงกว่า

ในฝั่ง Telegram กลยุทธ์ของฉัน傾向ไปทาง allowlist + mention gate ซึ่งถูกจำกัดและปลอดภัยกว่า เหมาะสำหรับ "ช่องทางการผลิตที่ควบคุม"

ดังนั้นสรุปคือ: Discord คือเวทีสำหรับการทำงานร่วมกัน

6. ชั้นการกำหนดค่า + ชั้น Prompt: การกำกับดูแลแบบ Dual-Track

นี่คือความแตกต่างที่ใหญ่ที่สุดระหว่างระบบนี้กับ "แค่เล่นๆ"

ฉันไม่พึ่งพาแค่การกำหนดค่า หรือแค่ Prompts ฉันใช้สองแทร็กที่ทับซ้อนกัน

A. แทร็กการกำหนดค่า (การควบคุมระดับแพลตฟอร์ม)

สิ่งเหล่านี้คือการกำหนดค่าที่แข็งที่ระดับแพลตฟอร์ม OpenClaw:

• channel policy: groupPolicy, dmPolicy ควบคุมกลยุทธ์พื้นฐานสำหรับแชทกลุ่มและแชทส่วนตัว
• requireMention: ใครต้องถูก @ โดยค่าเริ่มต้นเพื่อตอบกลับ
• bindings: การแมปเส้นทางข้อความ
• dmScope: ความละเอียดในการแยกเซสชัน
• ขีดจำกัดการ ping-pong agentToAgent: ฉันตั้งค่านี้เป็น 0 เพื่อระงับการโต้ตอบที่ไม่มีความหมายระหว่าง Agent โดยตรง

อันสุดท้ายสำคัญมาก—ถ้าคุณไม่จำกัดการ ping-pong ระหว่าง Agent คุณจะเห็น AI สองตัวในกลุ่มพูดจาสุภาพ ยืนยันซึ่งกันและกัน และวนซ้ำไม่รู้จบ การตั้งค่าเป็น 0 จะบอกระบบว่า: Agent ไม่ควร ping กันโดยอัตโนมัติ

B. แทร็กกฎ (การควบคุมระดับพฤติกรรม)

สิ่งเหล่านี้คือไฟล์กฎที่ฉันเขียนในแต่ละพื้นที่ทำงาน:

• SOUL.md: ไฟล์จิตวิญญาณของบทบาท—บุคลิกภาพ น้ำเสียง ความรับผิดชอบ และระดับคุณภาพขั้นต่ำของผลลัพธ์
• AGENTS.md: คู่มือการปฏิบัติงาน—กระบวนการตรวจสอบการทำงานร่วมกัน บรรทัดฐานการอ่าน/เขียนหน่วยความจำ และกลยุทธ์การโหลดแบบขี้เกียจ
• ROLE-COLLAB-RULES.md: ขอบเขตการทำงานร่วมกันเฉพาะบทบาทและเส้นสีแดง
• TEAM-RULEBOOK.md: กฎที่แข็ง統一ของทีม (แชร์โดยทุกบทบาท)
• TEAM-DIRECTORY.md: ตารางการแมปบทบาทกับ ID จริง เพื่อป้องกันการ @ ผิดคน

ผลของการทับซ้อนสองแทร็กนี้คือ: ชั้นแพลตฟอร์มจำกัดการไหล + ชั้นพฤติกรรมเพิ่มข้อจำกัด

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

7. ระบบไฟล์พื้นที่ทำงาน: "สำนักงานอิสระ" ของแต่ละบทบาท

โครงสร้างไฟล์ของแต่ละพื้นที่ทำงานโดยพื้นฐานแล้วสอดคล้องกัน ซึ่งเป็นสิ่งสำคัญ—มันแสดงให้เห็นว่าฉันกำลังทำมาตรฐาน ไม่ใช่แค่กองไฟล์แบบสุ่มสำหรับแต่ละบทบาท

โครงสร้างไฟล์มาตรฐาน

8. ระบบหน่วยความจำ: การโหลดแบบขี้เกียจ + การแบ่งชั้น + การเก็บถาวร

การจัดการหน่วยความจำเป็นส่วนที่ถูกมองข้ามมากที่สุดแต่มีปัญหามากที่สุดในระบบหลาย Agent

กลยุทธ์ของฉันไม่ใช่ "จำให้มากที่สุด" แต่เป็นการแบ่งชั้นที่ชัดเจน:

1) บันทึกระยะสั้น (หน่วยความจำรายวัน)

• บันทึกกระบวนการงานของวันนั้น เศษบริบท และการตัดสินใจเฉพาะหน้างาน
• ไฟล์ถูกตั้งชื่อตามวันที่ สร้างไทม์ไลน์ตามธรรมชาติ

2) หน่วยความจำระยะยาว (MEMORY.md)

• สกัดความชอบที่มั่นคง การตัดสินใจระยะยาว ประสบการณ์ที่ใช้ซ้ำได้ และกฎที่แข็ง
• ไม่ใช่ทุกอย่างจะเข้าไป มีเพียงข้อมูลที่ตรวจสอบแล้วและมั่นคงเท่านั้นที่ถูกเขียน

3) หน่วยความจำระยะยาวของกลุ่ม (GROUP_MEMORY.md)

• เก็บเฉพาะข้อมูลที่ใช้ซ้ำได้และปลอดภัยจากกลุ่ม
• ไม่ผสมเนื้อหาแชทส่วนตัว นี่คือเส้นสีแดงด้านความเป็นส่วนตัว

4) การเก็บถาวรเย็น (archive)

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

5) กลไกการดึงข้อมูล (memory_search + memory_get)

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

คุณค่าหลักของการแบ่งชั้นนี้:

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

ฉันปฏิบัติต่องบประมาณบริบทเป็นปัญหาการจัดการทรัพยากร Token มีจำกัด ทุกความทรงจำที่ยัดเข้าไปจะกินพื้นที่ในการอนุมาน ดังนั้น ทุกบิตต้องคำนวณอย่างรอบคอบ

9. โหมดส่วนตัว vs โหมดกลุ่ม: สองกลยุทธ์สำหรับบทบาทเดียวกัน

นี่คือสิ่งที่หลายคนไม่คิด: บทบาทเดียวกันควรมีพฤติกรรมที่แตกต่างกันในแชทส่วนตัวและแชทกลุ่ม

ฉันแยกความแตกต่างระหว่างสองโหมดอย่างชัดเจนใน SOUL.md ของแต่ละบทบาท:

โหมดส่วนตัว:

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

โหมดกลุ่ม:

• ดำเนินการส่งต่อแบบเพิ่มทีละส่วนตามโปรโตคอลการทำงานร่วมกันของทีม
• แต่ละบทบาทรับผิดชอบเฉพาะสิ่งที่ตนถนัด
• Commander รับผิดชอบการเชื่อมโยงและการปิดงาน

เฉพาะเจาะจงสำหรับแต่ละบทบาท:

• Commander: โดยค่าเริ่มต้น เงียบและสังเกตในกลุ่ม จะแทรกแซงอย่างรุนแรงเมื่อจำเป็นเท่านั้น เพื่อหลีกเลี่ยงการพูดทับคนอื่น
• Engineer: ผลงานที่ส่งมอบต้องสามารถดำเนินการได้ ตรวจสอบได้ และย้อนกลับได้—ไม่ใช่แค่ให้ไอเดีย
• Strategist: ข้อสรุปต้องมาพร้อมสมมติฐานและเส้นทางการตรวจสอบ—ไม่ใช่แค่คิดออกมา
• Thinker: การตรวจสอบต้องให้การจัดลำดับความสำคัญของปัญหา + แผนการซ่อมแซม—ไม่ใช่แค่บอกว่า "มีปัญหา"
• Creator: การแสดงออกไม่สามารถเสียสละความถูกต้องและความสามารถในการดำเนินการ—ไม่ใช่แค่追求ความสวยงาม

นี่คือที่มาของ "บทบาทเดียวกันมีประสิทธิภาพแตกต่างกันในสถานการณ์ที่แตกต่างกัน" มันไม่พึ่งพาการตัดสินของโมเดลเอง แต่ถูกบอกอย่างชัดเจนผ่านไฟล์กฎ

คำพูดสุดท้าย

Multi-Agent ไม่ใช่แค่การเปิดบอทเพิ่มอีกสองสามตัว มันคือระบบวิศวกรรมทั้งหมด—ตั้งแต่การออกแบบสถาปัตยกรรม กลยุทธ์การกำหนดเส้นทาง การแยกเซสชัน การ orchestration การทำงานร่วมกัน การจัดการหน่วยความจำ และการกำกับดูแลกฎ ไปจนถึงการตรวจสอบอัตโนมัติ ทุกชั้นจำเป็นต้องได้รับการออกแบบอย่างรอบคอบ

OpenClaw ให้พื้นฐานที่ยอดเยี่ยม แต่ปริมาณวิศวกรรมจาก "รันได้" ไปจนถึง "รันได้ดี" นั้นมากกว่าที่คนส่วนใหญ่คิด

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