OpenClaw + Claude Code/Codex:打造个人开发Agent Swarm
OpenClaw + Claude Code/Codex:打造个人开发Agent Swarm
สวัสดีครับ ทุกคน ผมคือ鲁工。
เมื่อไม่นานมานี้ ผมได้เห็นทวีตหนึ่งใน X ซึ่งดึงดูดความสนใจของผมทันที นักพัฒนาที่ชื่อว่า Elvis กล่าวว่า ตอนนี้เขาไม่ใช้ Claude Code และ Codex โดยตรงแล้ว แต่เปลี่ยนมาใช้ OpenClaw เป็นชั้นการจัดการ เพื่อให้ AI ที่ชื่อว่า Zoe จัดการกับกลุ่ม Agent ของ Claude Code และ Codex ทั้งหมด
ข้อมูลในทวีตนี้ก็น่าตื่นเต้นมาก มีการเข้าชม 4.9 ล้านครั้ง กดไลค์ 11,000 ครั้ง และแชร์ 1,800 ครั้ง
เราเขียน Vibe Coding มานานกว่า 4 เดือนแล้ว Claude Code เป็นเครื่องมือหลักเสมอ ผมเคยเขียนเกี่ยวกับการทำงานร่วมกันของหลาย Agent และสถาปัตยกรรมหลาย Agent ใน VSCode มาบ้าง
แต่เมื่อเห็นวิธีการของ Elvis ผมต้องบอกว่าเขาเป็นมืออาชีพจริงๆ คนคนเดียว ใช้ระบบการจัดการชุดเดียว ส่งโค้ดเฉลี่ยวันละ 50 ครั้ง วันหนึ่งส่งโค้ดถึง 94 ครั้ง ยังรับโทรศัพท์จากลูกค้า 3 สาย โดยไม่เปิดโปรแกรมแก้ไขเลย
นี่ไม่ใช่การทำงานของทีมพัฒนาที่มีคนเดียวเหรอ?
วันนี้บทความนี้จะมาวิเคราะห์ว่า เขาทำได้อย่างไร
OpenClaw ทุกคนคงไม่แปลกใจ
เจ้ากุ้งล็อบสเตอร์ตัวนี้ตั้งแต่ก่อนปีใหม่จนถึงตอนนี้ ยังคงได้รับความนิยมอย่างมาก กล่าวโดยสรุปคือเป็นกรอบงาน AI Agent แบบโอเพนซอร์ส ขณะนี้มีมากกว่า 240,000 ดาวใน GitHub และเมื่อสองวันที่ผ่านมาได้แซง React ขึ้นเป็นโปรเจกต์โอเพนซอร์สที่มีการเติบโตของดาวเร็วที่สุดในประวัติศาสตร์ GitHub
ผู้ก่อตั้ง Peter Steinberger เป็นนักพัฒนาจากออสเตรีย ก่อนหน้านี้เขาเคยก่อตั้ง PSPDFKit (บริษัท B2B ที่ทำกรอบงาน PDF) และในปี 2021 ได้รับการลงทุน 100 ล้านยูโรจาก Insight Partners ในเดือนกุมภาพันธ์ปีนี้ Peter ประกาศเข้าร่วม OpenAI และโครงการ OpenClaw ได้ถูกส่งต่อให้มูลนิธิโอเพนซอร์สดูแล
OpenClaw ไม่ได้ถูกออกแบบมาเป็นแชทบอท แต่เป็น AI Agent runtime ที่ทำงานบนอุปกรณ์ของคุณ มันมีสี่ส่วนหลัก: Gateway (เกตเวย์ เชื่อมต่อกับแพลตฟอร์มข้อความมากกว่า 50 แห่ง), Agent (เอนจินการอนุมาน), Skills (ปลั๊กอินมากกว่า 5,400 ตัว), Memory (ระบบความจำ)
แต่วิธีที่ Elvis ใช้ OpenClaw นั้นค่อนข้างพิเศษ เขาใช้มันเป็นชั้นการจัดการ โดยเฉพาะเพื่อจัดการกับ Agent การเขียนโค้ดของ Claude Code และ Codex ไม่ได้ใช้เป็นผู้ช่วยทั่วไป
แนวคิดนี้จริงๆ แล้วไม่ธรรมดา
ทำไมถึงต้องมีชั้นการจัดการ?
Elvis ได้กล่าวถึงมุมมองที่สำคัญในทวีตว่า: หน้าต่างบริบทเป็นเกมที่ไม่มีผู้ชนะ
ถ้าคุณใส่โค้ดเข้าไป คุณจะไม่มีพื้นที่สำหรับบริบททางธุรกิจ ถ้าคุณใส่ประวัติลูกค้าและบันทึกการประชุม คุณจะไม่มีพื้นที่สำหรับคลังโค้ด แม้ว่า AI จะเก่งแค่ไหน มันก็ไม่สามารถเก็บข้อมูลที่แตกต่างกันสองประเภทนี้ได้ในเวลาเดียวกัน
ดังนั้นเขาจึงแบ่งระบบออกเป็นสองชั้น
ชั้นบนคือ OpenClaw orchestrator Zoe ซึ่งควบคุมบริบททางธุรกิจทั้งหมด รวมถึงข้อมูลลูกค้า บันทึกการประชุม การตัดสินใจในอดีต ว่าได้ลองแผนไหนไปบ้าง และแผนไหนล้มเหลว ข้อมูลเหล่านี้ทั้งหมดอยู่ในคลังบันทึก Obsidian ของ Elvis และ Zoe สามารถอ่านได้โดยตรง
ชั้นล่างคือ Agent การเขียนโค้ดของ Claude Code และ Codex ซึ่งพวกเขาเพียงแค่ดูโค้ดและเขียนโค้ดเท่านั้น เมื่อ Agent แต่ละตัวเริ่มทำงาน Zoe จะเขียน prompt ที่แม่นยำให้กับมันตามบริบททางธุรกิจ บอกมันว่าต้องทำอะไร พื้นหลังคืออะไร และลูกค้าต้องการอะไร
กล่าวโดยสรุปคือ: orchestrator รับผิดชอบในการเข้าใจความต้องการ ส่วน Agent การเขียนโค้ดรับผิดชอบในการทำงาน ทำในสิ่งที่แต่ละคนถนัด
สถาปัตยกรรมนี้มีความคล้ายคลึงกับระบบภายใน Minions ที่ Stripe เพิ่งเปิดเผยไปเมื่อไม่นานมานี้ Minions ของ Stripe ก็เป็นการออกแบบ Agent การเขียนโค้ดแบบขนานพร้อมชั้นการจัดการแบบรวมศูนย์ ซึ่งสามารถรวม PR ที่เขียนโดย AI ได้มากกว่า 1,000 รายการต่อสัปดาห์ Elvis กล่าวว่าเขาได้สร้างสถาปัตยกรรมที่คล้ายกันโดยบังเอิญ เพียงแต่ทำงานบน Mac mini ของเขาเอง
กรณีศึกษาจริงของการทำงาน
Elvis ได้ใช้กรณีศึกษาจริงในทวีตเพื่ออธิบายการทำงานทั้งหมดของเขา ผมจะสรุปขั้นตอนหลักๆ ให้ฟังเขาได้รับโทรศัพท์จากลูกค้า ลูกค้าต้องการนำการตั้งค่าที่มีอยู่ในทีมมาใช้ซ้ำ หลังจากการสนทนา เขาได้พูดคุยกับ Zoe เกี่ยวกับความต้องการนี้ เนื่องจากบันทึกการประชุมทั้งหมดจะถูกซิงค์โดยอัตโนมัติไปยัง Obsidian Zoe จึงรู้แล้วว่าลูกค้าพูดอะไร ไม่จำเป็นต้องให้ Elvis อธิบายเพิ่มเติม พวกเขาได้กำหนดขอบเขตของฟังก์ชันร่วมกัน และแผนสุดท้ายคือการสร้างระบบเทมเพลต
จากนั้น Zoe ได้ทำสามสิ่งโดยอัตโนมัติ: เติมเงินให้ลูกค้าเพื่อปลดล็อกบริการ (เธอมีสิทธิ์ API ผู้ดูแลระบบ) ดึงการตั้งค่าที่มีอยู่ของลูกค้าจากฐานข้อมูลการผลิต (สิทธิ์อ่านอย่างเดียว รหัส Agent จะไม่มีสิทธิ์นี้ตลอดไป) และสร้าง Codex Agent ที่มี prompt รายละเอียดซึ่งมีบริบททางธุรกิจที่ครบถ้วน
แต่ละ Agent มี worktree (สาขาแยก) และเซสชัน tmux ของตัวเอง คำสั่งเริ่มต้นประมาณนี้:
# สร้าง worktree + สร้าง agent git worktree add ../feat-custom-templates -b feat/custom-templates origin/main cd ../feat-custom-templates && pnpm install tmux new-session -d -s "codex-templates" \ -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \ "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high หลังจากที่ Agent เริ่มทำงาน จะมีงานที่ตั้งเวลาเพื่อตรวจสอบทุก 10 นาที แต่จะไม่ถาม Agent โดยตรง (เพราะจะใช้ token มากเกินไป) แต่จะรันสคริปต์ Shell ที่กำหนดเพื่อตรวจสอบว่าเซสชัน tmux ยังมีชีวิตอยู่หรือไม่ มีการสร้าง PR หรือไม่ และ CI ผ่านหรือไม่
หาก CI ล้มเหลว จะมีการรีสตาร์ท Agent โดยอัตโนมัติ สูงสุด 3 ครั้ง จะมีการแจ้งเตือนเฉพาะเมื่อจำเป็นต้องมีการแทรกแซงจากมนุษย์
หลังจากที่ Agent ทำงานเสร็จ จะสร้าง PR โดยอัตโนมัติ แต่การสร้าง PR ยังไม่ถือว่าจบ Elvis ได้กำหนดมาตรฐานการเสร็จสิ้น: การสร้าง PR การซิงค์สาขาไปยัง main (ไม่มีความขัดแย้งในการรวม) CI ผ่านทั้งหมด การตรวจสอบโค้ดจาก AI โมเดลสามตัวผ่านทั้งหมด และหากมีการเปลี่ยนแปลง UI จะต้องแนบภาพหน้าจอ
การตรวจสอบโค้ดโดย AI โมเดลสามตัว
การตรวจสอบโค้ดโดย AI โมเดลสามตัวดูเหมือนจะมีความเสถียร พูดคุยเกี่ยวกับความคิดเห็นของเขาเกี่ยวกับโมเดลทั้งสามนี้ก็น่าสนใจ
Codex Reviewer เขาให้คะแนนสูงสุด กล่าวว่าในการตรวจสอบกรณีขอบและข้อผิดพลาดทางตรรกะนั้นทำได้อย่างละเอียดมาก อัตราการรายงานผิดพลาดต่ำมาก
Gemini Code Assist Reviewer ฟรี เขาบอกว่ามีประโยชน์มาก สามารถค้นพบปัญหาด้านความปลอดภัยและความสามารถในการขยายที่โมเดลอื่นๆ พลาดไป และยังสามารถให้แนวทางการแก้ไขที่เฉพาะเจาะจงได้
Claude Code Reviewer คำพูดของเขาคือ "แทบจะไม่มีประโยชน์" เขาบอกว่ามันระมัดระวังเกินไป เต็มไปด้วยคำแนะนำเช่น "พิจารณาเพิ่ม..." ซึ่งส่วนใหญ่เป็นการออกแบบเกินความจำเป็น เว้นแต่จะถูกทำเครื่องหมายว่าเป็นปัญหาสำคัญ มิฉะนั้นเขาจะข้ามไปเลย
เมื่อฉันเห็นส่วนนี้รู้สึกประหลาดใจ ในฐานะผู้ใช้ Claude Code อย่างหนัก ฉันก็เคยพบว่ามันระมัดระวังเกินไปในการตรวจสอบโค้ด แต่การบอกว่าแทบจะไม่มีประโยชน์นั้นก็เกินไปหน่อย อย่างไรก็ตาม นี่ก็แสดงให้เห็นว่าการตรวจสอบข้ามโมเดลหลายๆ โมเดลนั้นมีคุณค่า ความลำเอียงของโมเดลที่แตกต่างกันนั้นสามารถชดเชยกันได้
หลังจากการตรวจสอบทั้งหมดผ่านแล้ว Elvis จึงจะได้รับการแจ้งเตือนทาง Telegram ถึงจุดนี้ เขาจะดูเฉพาะภาพหน้าจอเพื่อยืนยันว่าการเปลี่ยนแปลง UI ถูกต้อง หลาย PR เขาจะไม่ดูโค้ดและรวมเลย เขาบอกว่าการตรวจสอบด้วยตนเองใช้เวลาเพียง 5 ถึง 10 นาที
ความกระตือรือร้นของ Zoe
Zoe ไม่ใช่แค่ผู้ดำเนินการ สิ่งที่น่าสนใจกว่ากระบวนการทำงานคือความกระตือรือร้นของ Zoe
Elvis กล่าวว่า Zoe จะไม่รอให้มีการมอบหมายงาน แต่จะหางานทำด้วยตัวเอง ในตอนเช้าจะสแกนบันทึกข้อผิดพลาดของ Sentry พบข้อผิดพลาดใหม่ 4 รายการ และสร้าง Agent 4 ตัวเพื่อแก้ไข หลังจากประชุมจะสแกนบันทึกการประชุมและทำเครื่องหมายความต้องการฟังก์ชัน 3 รายการที่ลูกค้าได้กล่าวถึง จากนั้นจะเริ่ม Codex Agent 3 ตัวโดยอัตโนมัติ ในตอนเย็นจะสแกนบันทึก Git และเริ่ม Claude Code เพื่ออัปเดต changelog และเอกสารของลูกค้า
เมื่อ Elvis ออกไปเดินเล่นและกลับมา เขาก็พบข้อความหนึ่งใน Telegram: PR 7 รายการพร้อมแล้ว 3 ฟังก์ชันใหม่ 4 การแก้ไขข้อบกพร่อง นี่ไม่ใช่ผลลัพธ์ที่เขาหวังว่าจะสร้างทีมพัฒนาของ OPC ที่มีคนเพียงคนเดียวหรือ?เมื่อเอเจนต์ล้มเหลว วิธีการจัดการของโซอี้ก็มีความซับซ้อนกว่าการลองใหม่อย่างง่ายมาก มันจะรวมการวิเคราะห์บริบททางธุรกิจเพื่อตรวจสอบสาเหตุของความล้มเหลว บริบทของเอเจนต์ล้มเหลว? มันจะลดขอบเขตให้เอเจนต์มุ่งเน้นไปที่ไฟล์สามไฟล์เท่านั้น ทิศทางของเอเจนต์ผิดพลาด? มันจะทำการแก้ไขและบอกเอเจนต์ว่าลูกค้าต้องการ X ไม่ใช่ Y พร้อมกับคำพูดที่แท้จริงจากการประชุม
เมื่อเวลาผ่านไป โซอี้ยังจะสะสมประสบการณ์ จำได้ว่าโครงสร้างพรอมต์ใดมีประสิทธิภาพดีสำหรับงานประเภทใด เพื่อให้สามารถเขียนพรอมต์ที่แม่นยำยิ่งขึ้นในครั้งถัดไป
แนวคิดนี้จริงๆ แล้วเป็นเวอร์ชันอัปเกรดของ Ralph Loop หลักการหลักของ Ralph Loop คือการดึงบริบท สร้างผลลัพธ์ ประเมินผล และบันทึกประสบการณ์ในลักษณะวนรอบ แต่การใช้งานส่วนใหญ่จะมีพรอมต์ที่ตายตัวในแต่ละรอบ Elvish มีระบบที่แตกต่างกัน ทุกครั้งที่ลองใหม่ โซอี้จะปรับพรอมต์ตามสาเหตุของความล้มเหลวอย่างมีพลศาสตร์ และยังมีบริบททางธุรกิจที่สมบูรณ์
ค่าใช้จ่ายและฮาร์ดแวร์
ในด้านค่าใช้จ่าย ข้อมูลที่ Elvish เปิดเผยคือ Claude ใช้ประมาณ 100 ดอลลาร์ต่อเดือน และ Codex ใช้ประมาณ 90 ดอลลาร์ต่อเดือน เขายังกล่าวว่า สามารถเริ่มต้นจาก 20 ดอลลาร์เพื่อทดลองได้
ค่าใช้จ่ายนี้เมื่อเปรียบเทียบกับการจ้างนักพัฒนาก็ถูกมาก แต่ถ้าพิจารณาว่าคุณยังต้องทำการตัดสินใจผลิตภัณฑ์ การสื่อสารกับลูกค้า และการตรวจสอบโค้ด มันจึงเหมือนกับเครื่องขยายประสิทธิภาพที่ช่วยให้คุณประหยัดเวลาในการเขียนโค้ดและการทดสอบซึ่งเป็นขั้นตอนที่ซ้ำซากที่สุด
ในด้านฮาร์ดแวร์ Elvish กล่าวว่าข้อจำกัดที่ใหญ่ที่สุดในปัจจุบันคือ RAM เอเจนต์แต่ละตัวต้องการ worktree ที่แยกจากกัน โดยแต่ละ worktree จะมี node_modules ของตัวเอง เอเจนต์แต่ละตัวต้องทำการสร้าง ตรวจสอบประเภท และทดสอบ หากมีเอเจนต์ 5 ตัวทำงานพร้อมกันก็หมายความว่ามีคอมไพเลอร์ TypeScript 5 ตัว ตัวทดสอบ 5 ตัว และชุดการพึ่งพา 5 ชุด
Mac mini 16GB ของเขาสามารถทำงานพร้อมกันได้สูงสุด 4 ถึง 5 เอเจนต์ หากมากกว่านั้นจะเริ่มมีการแลกเปลี่ยนหน่วยความจำ ดังนั้นเขาจึงซื้อ Mac Studio M4 Max ที่มี RAM 128GB (3500 ดอลลาร์) เพื่อรองรับการทำงานของเอเจนต์มากขึ้น
สรุปและปัญหาจริง
พูดตามตรง ระบบของ Elvish ทำให้ฉันรู้สึกประทับใจมาก ฉันเคยคิดว่า OpenClaw เป็นแค่ของเล่น ในการสร้างประสิทธิภาพ ฉันพึ่งพา Claude Code ที่แยกต่างหากเป็นหลัก บางครั้งใช้ worktree เพื่อทำงานขนาน แต่ยังไม่ถึงระดับการจัดระเบียบแบบนี้ หลังจากอ่านทวีตของเขา ฉันรู้สึกว่าขีดจำกัดของการเขียนโปรแกรม AI ได้ถูกยกระดับขึ้นอีก
ฉันกำลังตามแนวคิดของเขา เตรียมใช้ OpenClaw สร้างทีมพัฒนาที่ทำงานอัตโนมัติทั้งหมด ดังนั้นในเร็วๆ นี้เราจะมีบทความเกี่ยวกับการปฏิบัติของ OpenClaw หลายบทความ
มีปัญหาจริงบางอย่างที่ต้องเตือนทุกคน
ระบบนี้มีเงื่อนไขว่าคุณต้องมีผลิตภัณฑ์ที่ชัดเจน ความต้องการของลูกค้าที่ชัดเจน และสายการผลิต CI/CD ที่สมบูรณ์ Elvish กำลังทำผลิตภัณฑ์ B2B SaaS ที่แท้จริง มีลูกค้า มีรายได้ และมีสภาพแวดล้อมการผลิต หากคุณยังอยู่ในขั้นตอนการเขียน Demo หรือการเรียนรู้ ROI ของสถาปัตยกรรมนี้อาจไม่คุ้มค่า
นอกจากนี้ ปัญหาด้านความปลอดภัยของ OpenClaw ในปัจจุบันก็ต้องให้ความสนใจ ตามข้อมูลที่เปิดเผย มี CVE ที่มีความเสี่ยงสูงหลายรายการถูกเปิดเผย และยังมีปลั๊กอินชุมชนที่เป็นอันตราย 341 รายการที่ถูกค้นพบว่ามีการขโมยข้อมูล เมื่อทำการติดตั้ง OpenClaw ต้องทำการแยกและควบคุมสิทธิ์ให้ดี นี่คือเหตุผลที่ฉันยังไม่ได้ติดตั้ง OpenClaw บนเครื่องหลักของฉัน
อีกจุดหนึ่ง Elvish ในทวีตของเขาให้คะแนนการตรวจสอบโค้ดของ Claude Code ค่อนข้างต่ำ แต่เมื่อเร็วๆ นี้ Claude Code เพิ่งเปิดตัวฟังก์ชัน Agent Teams (การทำงานร่วมกันของหลายเอเจนต์ที่ติดตั้งในระบบ) และ Anthropic ก็เริ่มมุ่งไปในทิศทางนี้
อย่างไรก็ตาม หากไม่พูดถึงรายละเอียดเหล่านี้ แนวคิดของ Elvish ในการสร้างชั้นการจัดระเบียบและชั้นการดำเนินการนั้นน่าสนใจจริงๆ เกมที่เป็นศูนย์รวมของบริบทนั้นเป็นข้อจำกัดที่มีอยู่จริง การใช้สถาปัตยกรรมแบบชั้นเพื่อแก้ไขปัญหานี้ ทำให้ AI ต่างๆ ทำหน้าที่ของตนเอง ฉันคิดว่านี่เป็นทิศทางที่ถูกต้อง
เพื่อนๆ ที่สนใจในหัวข้อนี้ สามารถไปดูทวีตต้นฉบับของ Elvish ได้โดยตรง ข้อมูลหนาแน่นมาก:...
