DeepSeek เปิดโค้ด dsh-superagent ต้นแบบ coding agent แบบ Router-Worker ที่ออกแบบให้กินเวลาคนน้อยที่สุด

ทีม DeepSeek Harness เปิด repo dsh-superagent-prototype เมื่อ 31 ต.ค. ภายใต้สัญญาอนุญาต MIT และตามด้วยบทความ Exploring Super-agent Design เมื่อ 1 พ.ย. ภายในสองวัน repo ได้กว่า 7,100 ดาว แม้จะมีเพียงคอมมิตเดียว

แนวคิดหลักคือ คอขวดของ coding agent ย้ายจากความสามารถของโมเดลไปที่ความสนใจของคน ทีมระบุว่าโดยทั่วไปคนตามงานที่กำลังรันได้พร้อมกันเพียง 3–5 session จึงอยากเลิกให้คนจัดการ session เอง แล้วให้มี agent ตัวเดียวที่อยู่ในที่ทำงานจริง ทั้ง GitHub และแชต

สถานะ: README ระบุชัดว่าเป็น research prototype เพื่อการอ้างอิง ไม่ใช่ผลิตภัณฑ์ทางการ และไม่เหมือนเวอร์ชันภายในหรือทุกอย่างที่บทความเล่า บางส่วนเป็นทิศทางในอนาคต

สถาปัตยกรรม Router-Worker

ตัวโปรแกรมเป็น bundle ของ DeepSeek Harness ดูแลหนึ่ง repo บน github.com และรับงานจาก GitHub กับ Feishu ได้

• Router (main Session): long-lived session ที่รับเหตุการณ์ทั้งหมด ตัดสินว่าจะรับงานไหม แต่ไม่ลงมือเขียนโค้ดเอง
• Worker (Executor): แต่ละ Ticket ได้ session และไดเรกทอรีของตัวเอง ทำงานขนานกันตามจำนวน slot ที่ตั้งไว้ โดยกันไว้หนึ่ง slot สำหรับข้อความจากคน งานใหม่จึงไม่บังคนที่จะคุยกับงานเดิม
• Pass-through: ข้อความใน Thread ของงานไหนจะไหลตรงไปยัง Worker เจ้าของงานนั้น ไม่ต้องผ่าน Router ทุกครั้ง
• Shell ไม่บล็อก: คำสั่ง foreground ที่เกิน 5 วินาทีจะถูกย้ายไปเป็น background job เพื่อให้ Worker รับข้อความใหม่ได้ระหว่างรอ

บทความยังเล่าการแยก compute, state และ environment ออกจากกัน รวมถึง Watchdog ที่เป็น agent แยกต่างหากคอยกู้ระบบ นี่คือแนวคิดระดับระบบ ไม่ได้แปลว่าทุกส่วนอยู่ในโค้ดที่เปิดมา

ตัวเลขจากการทดลอง

ทีมจำลอง 300 ข้อความ มีงานจริงราว 20 งาน ทำซ้ำ 5 รอบ และ ใช้เครื่องมือที่แค่กินเวลาแทนการเขียนโค้ดจริง ผลจึงวัดเฉพาะการจัดตารางงาน และทีมเองบอกว่าเป็นเพียงข้อมูลบ่งชี้

ดีไซน์	ผลที่รายงาน
Super-agent	p50 12.4 นาที, p95 15.7 นาที
Single session + prompt กลาง ๆ	ไม่เรียก subagent เลยทั้ง 5 รอบ, p95 29.5 นาที
Single session + prompt เน้น delegate	delegate 4 ใน 5 รอบ และยังช้ากว่า Super-agent
Super-agent ไม่มี pass-through	เวลาใกล้เคียง แต่ cache-read เพิ่มจาก 23.2M เป็น 31.8M tokens

ประเด็นที่น่าสนใจคือ ดีไซน์นี้ใช้ cache-read token มากกว่า single session จึงเป็นการแลก token กับเวลาที่สั้นและนิ่งกว่า ไม่ใช่การลดค่าใช้จ่าย

ก่อนจะลองใช้

• ต้องมี DSH, Node.js 22.19+ หรือ 24+, pnpm, tmux และ GitHub CLI 2.48+ ส่วนการติดตั้งออกแบบให้สั่ง coding agent อ่าน SETUP.md แล้วทำตาม
• Worker และ Router รันด้วย danger-full-access ในฐานะ OS user ของผู้ดูแล อ่าน home directory ได้ เอกสารแนะนำให้ใช้ OS account แยกที่มีเฉพาะ credential ของ agent
• ควรใช้บัญชี GitHub แยกสำหรับ agent และเริ่มจาก allowlist สั้น ๆ
• โหมด proactive ค่าเริ่มต้นคือ observe ซึ่งบันทึกว่า “ถ้าเปิดจะรับงานนี้” แต่ไม่ลงมือ ควรดูผลก่อนเปลี่ยนเป็น auto
• เอกสารระบุว่า host เป็นคนบังคับสิทธิ์ ข้อความหรือคอมเมนต์เป็นเพียงข้อมูลนำเข้า แก้ permission ไม่ได้ แต่ prompt injection จากเนื้อหาในคอมเมนต์ยังเป็นความเสี่ยงของ agent ทุกตัว จึงควรเลี่ยงการเปิดให้ทุกคนสั่งงานบน repo สาธารณะ

มุมมอง AI Curator

ส่วนที่มีค่าที่สุดของงานนี้ไม่ใช่โค้ด แต่เป็นการตั้งโจทย์ว่า “ความสนใจของคน” เป็นทรัพยากรหลัก ผลทดลองที่บอกว่าโมเดลไม่เรียก subagent เลยทั้ง 5 รอบเมื่อใช้ prompt กลาง ๆ ควรทำให้ทีมที่สร้าง agent คิดใหม่ เพราะการ delegate ที่ฝากไว้กับดุลยพินิจของโมเดลนั้นไม่นิ่ง การบังคับที่ระดับสถาปัตยกรรมจึงเชื่อถือได้กว่าการเขียน prompt ให้ยาวขึ้น

ปรัชญาในเอกสารก็น่าหยิบไปใช้ เช่น agent พูดเมื่อคนต้องตัดสินใจหรือมีผลลัพธ์เท่านั้น เรื่องนี้ง่ายกว่าการต่อโมเดลใหม่ และน่าจะลดเสียงบ่นเรื่อง agent ส่งแจ้งเตือนจนทีมเลิกอ่าน

ทีมไทยที่อยากลองควรรอเวอร์ชันที่นิ่งกว่า หรือแยกเครื่องทดลองจริงจัง โค้ดเพิ่งปล่อยมาและเปิดสิทธิ์เต็ม ขณะที่เอกสารมีตำราเพิ่ม Source ใหม่ ถ้าทีมของคุณคุยงานบน LINE หรือ Slack ก็น่าจะเขียนต่อเองได้ แต่ควรตั้งคำถามด้วยว่าการแลก token กับความเร็วคุ้มไหมถ้าไม่ได้ใช้โมเดลราคาถูกแบบ DeepSeek เพราะตัวเลข cache-read ระดับหลายสิบล้านต่อรอบจะแพงขึ้นมากเมื่อเปลี่ยนไปใช้โมเดลราคาสูง

แหล่งข่าว

• GitHub: deepseek-ai/dsh-superagent-prototype
• เอกสาร Philosophy ของ dsh-superagent
• เอกสาร Deployment และการแยกสิทธิ์
• หน้า DeepSeek Harness