- องค์กรวิศวกรรมชั้นนำอย่าง Stripe, Ramp และ Coinbase ต่างพัฒนาโค้ดดิ้งเอเจนต์ภายในองค์กรของตนเองอย่างอิสระ แต่กลับมาบรรจบกันที่ แพตเทิร์นสถาปัตยกรรมที่คล้ายกัน และ Open SWE คือเฟรมเวิร์กที่นำสิ่งนี้มาทำเป็นโอเพนซอร์ส
- สร้างอยู่บน Deep Agents และ LangGraph พร้อมคอมโพเนนต์หลัก เช่น cloud sandbox แบบแยกขาด, ชุดเครื่องมือที่คัดสรรมาแล้ว, การ orchestration ของ sub-agent และการเชื่อมเข้ากับ workflow ของนักพัฒนา
- สร้างด้วยแนวทาง composition โดยไม่ต้อง fork เอเจนต์เดิม ทำให้คงไว้ได้ทั้งการอัปเกรดเฟรมเวิร์กพื้นฐานและการปรับแต่งเฉพาะองค์กรไปพร้อมกัน
- คอมโพเนนต์หลักทั้งหมดเป็นแบบ pluggable ไม่ว่าจะเป็นผู้ให้บริการ sandbox, โมเดล, เครื่องมือ, ทริกเกอร์, system prompt หรือ middleware
- มอบ จุดเริ่มต้นที่อิงแพตเทิร์นซึ่งผ่านการพิสูจน์ใน production แล้ว ให้กับทีมที่กำลังพิจารณานำโค้ดดิ้งเอเจนต์ภายในองค์กรมาใช้ ภายใต้ไลเซนส์ MIT
แพตเทิร์นร่วมที่พบจากการ deploy ใน production
- โค้ดดิ้งเอเจนต์อย่าง Minions ของ Stripe, Inspect ของ Ramp และ Cloudbot ของ Coinbase แม้ถูกพัฒนาแยกกัน ก็ยังมาบรรจบที่ การตัดสินใจด้านสถาปัตยกรรมที่คล้ายกัน
- สภาพแวดล้อมการรันแบบแยกขาด: แต่ละงานรันใน cloud sandbox เฉพาะของตัวเอง พร้อมสิทธิ์เต็มภายในขอบเขตที่เข้มงวด ช่วยแยกผลกระทบจากความผิดพลาดต่อระบบ production และยังรันคำสั่งได้โดยไม่ต้องมี approval prompt ทุกครั้ง
- ชุดเครื่องมือที่คัดสรรมาแล้ว: ตามข้อมูลจากทีมวิศวกรรมของ Stripe เอเจนต์เข้าถึงเครื่องมือได้ราว 500 รายการ แต่ไม่ได้เกิดจากการสะสมไปเรื่อย ๆ หากเป็นการคัดเลือกและดูแลอย่างตั้งใจ ปริมาณเครื่องมือจึงสำคัญน้อยกว่า การคัดสรร
- เรียกใช้งานผ่าน Slack เป็นหลัก: ทั้งสามระบบรวม Slack เป็นอินเทอร์เฟซหลัก เพื่อให้นักพัฒนาใช้งานได้ใน workflow การสื่อสารเดิมโดยไม่ต้องสลับบริบทไปแอปใหม่
- มีบริบทครบตั้งแต่เริ่มต้น: ดึงบริบททั้งหมดจาก Linear issue, Slack thread และ GitHub PR มาให้ก่อนเริ่มงาน เพื่อลด overhead ในการค้นหาความต้องการผ่านการเรียกใช้เครื่องมือ
- การ orchestration ของ sub-agent: แยกงานซับซ้อนออกเป็นส่วนย่อย แล้วมอบหมายให้ child agent เฉพาะทางที่มีบริบทแยกขาดและหน้าที่ชัดเจน
สถาปัตยกรรมของ Open SWE
-
1. Agent harness: composition บน Deep Agents
- แทนที่จะ fork เอเจนต์ที่มีอยู่หรือสร้างใหม่จากศูนย์ Open SWE ใช้วิธี compose บนเฟรมเวิร์ก Deep Agents คล้ายกับแนวทางที่ทีม Ramp ใช้สร้าง Inspect บน OpenCode
- ข้อดีของ composition มีสองข้อ:
- เส้นทางการอัปเกรด: เมื่อ Deep Agents พัฒนาขึ้น (เช่น การจัดการบริบทที่ดีขึ้น การวางแผนมีประสิทธิภาพขึ้น การใช้โทเค็นเหมาะสมขึ้น) ก็รับการปรับปรุงเหล่านั้นมาใช้ได้โดยไม่ต้องสร้างส่วนปรับแต่งใหม่ทั้งหมด
- การปรับแต่งโดยไม่ต้อง fork: สามารถเก็บเครื่องมือ, prompt และ workflow เฉพาะองค์กรไว้เป็น การตั้งค่า แทนการแก้ไข logic แกนกลางของเอเจนต์
- โครงสร้างพื้นฐานที่ Deep Agents มีให้: การวางแผนในตัวผ่าน
write_todos, การจัดการบริบทแบบอิงไฟล์, การ spawn sub-agent แบบ native ผ่านเครื่องมือ task, และ middleware hook สำหรับ orchestration แบบ deterministic
-
2. Sandbox: สภาพแวดล้อม cloud แบบแยกขาด
- แต่ละงานรันใน cloud sandbox แบบแยกขาดของตัวเอง เป็นสภาพแวดล้อม Linux ระยะไกลที่เข้าถึง shell ได้เต็มรูปแบบ
- clone repository แล้วให้สิทธิ์เต็มแก่เอเจนต์ โดยข้อผิดพลาดจะถูกจำกัดอยู่ภายในสภาพแวดล้อมนั้น
- ผู้ให้บริการ sandbox ที่รองรับโดยค่าเริ่มต้น: Modal, Daytona, Runloop, LangSmith และยังสามารถสร้าง sandbox backend ของตัวเองได้
- พฤติกรรมหลัก:
- ให้ persistent sandbox แยกตามแต่ละเธรดสนทนา และนำกลับมาใช้ซ้ำในข้อความถัดไป
- หาก sandbox ไม่สามารถเข้าถึงได้ จะสร้างขึ้นใหม่โดยอัตโนมัติ
- หลายงานสามารถ รันแบบขนาน โดยแต่ละงานมี sandbox ของตัวเอง
-
3. เครื่องมือ: เน้นการคัดสรร ไม่ใช่การสะสม
- Open SWE มาพร้อมชุดเครื่องมือที่โฟกัสชัดเจน และเครื่องมือในตัวของ Deep Agents (
read_file, write_file, edit_file, ls, glob, grep, write_todos, task)
- ชุดเครื่องมือขนาดเล็กที่ผ่านการคัดสรรช่วยให้ทดสอบ, ดูแลรักษา และให้เหตุผลได้ง่ายกว่า ส่วนเครื่องมือเพิ่มเติมขององค์กร (internal API, ระบบ deploy แบบกำหนดเอง, test framework เฉพาะทาง) สามารถ เพิ่มเข้าไปอย่างชัดเจน ได้
-
4. Context engineering: AGENTS.md + source context
- รวบรวมบริบทจากสองแหล่ง:
- ไฟล์ AGENTS.md: หากมีอยู่ที่ root ของ repository จะถูกอ่านจาก sandbox และฉีดเข้าไปใน system prompt เพื่อเข้ารหัส convention, ข้อกำหนดการทดสอบ, การตัดสินใจด้านสถาปัตยกรรม และแพตเทิร์นเฉพาะทีม
- source context: รวมข้อมูลเต็มของ Linear issue (ชื่อเรื่อง, คำอธิบาย, คอมเมนต์) หรือประวัติ Slack thread แล้วส่งให้ก่อนเริ่มเอเจนต์ เพื่อให้ได้บริบทของงานนั้นทันทีโดยไม่ต้องเรียกเครื่องมือเพิ่ม
- เป็นแนวทาง สองชั้น ที่ผสานความรู้ระดับทั้ง repository กับข้อมูลเฉพาะของแต่ละงานอย่างสมดุล
-
5. Orchestration: sub-agent + middleware
- ผสานสองกลไกเข้าด้วยกัน:
- sub-agent: spawn child agent ผ่านเครื่องมือ
task โดย main agent สามารถมอบหมายงานย่อยอิสระให้ sub-agent ที่แยกบริบท, มี middleware stack, todo list และงานกับไฟล์ของตัวเอง
- middleware: deterministic hook ที่ทำงานรอบ ๆ agent loop
check_message_queue_before_model: ฉีดข้อความติดตามที่เข้ามาระหว่างการทำงานของเอเจนต์ (เช่น Linear comment, Slack message) ก่อนการเรียกโมเดลครั้งถัดไป ทำให้ผู้ใช้ส่งข้อมูลเพิ่มได้ระหว่างที่เอเจนต์กำลังทำงานopen_pr_if_needed: หากเอเจนต์ทำ PR ไม่สำเร็จ ระบบจะสร้าง commit และ PR อัตโนมัติเป็น ตาข่ายนิรภัยToolErrorMiddleware: ดักจับและจัดการข้อผิดพลาดของเครื่องมืออย่างเหมาะสม
- การแยก orchestration แบบ agentic (ขับเคลื่อนด้วยโมเดล) ออกจากแบบ deterministic (ขับเคลื่อนด้วย middleware) ช่วยสร้าง สมดุลระหว่างความเชื่อถือได้และความยืดหยุ่น
-
6. การเรียกใช้งาน: Slack, Linear, GitHub
- Slack: mention บอทในเธรด ใช้ไวยากรณ์
repo:owner/name เพื่อระบุ repository ที่ต้องการทำงาน เอเจนต์จะตอบกลับด้วยการอัปเดตสถานะและลิงก์ PR ในเธรดเดียวกัน
- Linear: คอมเมนต์
@openswe ใน issue เอเจนต์จะอ่านบริบททั้งหมดของ issue, ยืนยันด้วย 👀 แล้วโพสต์ผลลัพธ์เป็นคอมเมนต์
- GitHub: ใส่แท็ก
@openswe ในคอมเมนต์ของ PR ที่เอเจนต์สร้างขึ้น เพื่อจัดการ feedback จากการรีวิว และ push การแก้ไขเข้า branch เดิม
- การเรียกใช้งานแต่ละแบบจะสร้าง thread ID แบบ deterministic เพื่อให้ข้อความติดตามใน issue หรือ thread เดิมถูกส่งต่อไปยังเอเจนต์ตัวเดิมที่กำลังรันอยู่
-
7. การตรวจสอบ: ใช้ prompt เป็นหลัก + ตาข่ายนิรภัย
- สั่งให้เอเจนต์รัน linter, formatter และ test ก่อน commit
- middleware
open_pr_if_needed ทำหน้าที่เป็น backstop: หากเอเจนต์จบงานโดยไม่ได้เปิด PR, middleware จะจัดการให้อัตโนมัติ
- สามารถขยายด้วย middleware เพิ่มเติม สำหรับ deterministic CI check, การตรวจสอบภาพ และ review gate ได้
ทำไมถึงใช้ Deep Agents
- การจัดการบริบท: งานเขียนโค้ดระยะยาวสร้างข้อมูลขั้นกลางจำนวนมาก (เนื้อหาไฟล์, ผลลัพธ์คำสั่ง, ผลการค้นหา) ซึ่งถูก offload ไปเก็บเป็นหน่วยความจำแบบอิงไฟล์ แทนการคงทุกอย่างไว้ในประวัติการสนทนา ช่วย ป้องกัน context overflow ได้ดีใน codebase ขนาดใหญ่
- องค์ประกอบพื้นฐานด้านการวางแผน: เครื่องมือ
write_todos ในตัวช่วยจัดโครงสร้างการแตกงานซับซ้อน, ติดตามความคืบหน้า และปรับแผนตามข้อมูลใหม่ มีประโยชน์อย่างยิ่งกับ งานหลายขั้นตอนที่กินเวลานาน
- การแยกขาดของ sub-agent: เมื่อ main agent spawn child agent ผ่านเครื่องมือ
task จะให้บริบทที่แยกจากกัน ทำให้ประวัติการสนทนาของงานย่อยต่าง ๆ ไม่ปนกัน และช่วยให้ การให้เหตุผลชัดเจนขึ้น ในงานที่ซับซ้อน
- middleware hook: สามารถฉีด logic แบบ deterministic เข้าไปในจุดเฉพาะของ agent loop ใช้สร้าง พฤติกรรมที่ต้องทำงานได้อย่างเสถียร เช่น การฉีดข้อความหรือการสร้าง PR อัตโนมัติ
- เส้นทางการอัปเกรด: เนื่องจาก Deep Agents ถูกพัฒนาอย่างต่อเนื่องในฐานะไลบรารีอิสระ การปรับปรุงด้าน context compression, prompt caching, ประสิทธิภาพการวางแผน และ orchestration ของ sub-agent จึงสามารถสะท้อนมายัง Open SWE ได้โดยไม่ต้องสร้างส่วนปรับแต่งใหม่
การปรับแต่งตามองค์กร
- Open SWE ถูกออกแบบให้เป็น ฐานที่ปรับแต่งได้ ไม่ใช่ผลิตภัณฑ์สำเร็จรูป โดยคอมโพเนนต์หลักทั้งหมดเป็นแบบ pluggable:
- ผู้ให้บริการ sandbox: สลับระหว่าง Modal, Daytona, Runloop, LangSmith ได้ และยังสร้าง sandbox backend เองให้ตรงกับข้อกำหนดของโครงสร้างพื้นฐานภายในได้
- โมเดล: ใช้ได้กับผู้ให้บริการ LLM ทุกราย ค่าเริ่มต้นคือ Claude Opus 4 และกำหนดโมเดลต่างกันตามแต่ละ subtask ได้
- เครื่องมือ: เพิ่มเครื่องมือสำหรับ internal API, ระบบ deploy, test framework และ monitoring platform ภายในได้ รวมถึงเอาเครื่องมือที่ไม่จำเป็นออกได้
- ทริกเกอร์: ปรับ logic การเชื่อมกับ Slack, Linear, GitHub หรือเพิ่มพื้นผิวทริกเกอร์ใหม่ เช่น อีเมล, webhook หรือ custom UI
- system prompt: ปรับแต่ง prompt เริ่มต้นและ logic การสะท้อนไฟล์ AGENTS.md เพื่อเพิ่มแนวทาง, ข้อจำกัด และ convention เฉพาะองค์กรได้
- middleware: เพิ่ม middleware hook ของตนเองสำหรับการตรวจสอบ, approval gate, logging และ safety check ได้
เปรียบเทียบกับระบบภายใน
- เมื่อเทียบกับข้อมูลสาธารณะและระบบภายในของ Stripe, Ramp และ Coinbase จะพบว่า แพตเทิร์นแกนกลางมีความคล้ายกัน
- ความแตกต่างอยู่ที่รายละเอียดการติดตั้งใช้งาน, การเชื่อมต่อภายใน และเครื่องมือเฉพาะองค์กร ซึ่งเป็นความต่างที่คาดได้เมื่อนำเฟรมเวิร์กไปปรับใช้ในสภาพแวดล้อมที่ต่างกัน
เริ่มต้นใช้งาน
2 ความคิดเห็น
ดูเหมือนว่าคนส่วนใหญ่ก็คิดคล้ายๆ กันนะ.. เป็นยุคจ้านกว๋อของจริงเลย
ตอนนี้ทุกคนกำลังสร้างโค้ดดิ้งเอเจนต์ภายในองค์กรกันอยู่แล้ว เลยทำเฟรมเวิร์กสำหรับสิ่งนั้นออกมาเสียเลย ทุกคนเร็วกันจริงๆ
แทนที่จะต้องใช้ตัวนี้โดยเฉพาะ การได้ดูแพตเทิร์นของหลายบริษัทที่อ้างอิงกันภายในก็น่าจะเป็นประโยชน์เหมือนกัน