DeepSeek เปิดตัวต้นแบบ Super-agent สำหรับจัดการงานเขียนโค้ดหลายงานพร้อมกัน

เอเจนต์เขียนโค้ดที่ออกแบบมาเพื่อจัดการหลายงานพร้อมกัน

ทีม Harness ของ DeepSeek เผยแพร่การออกแบบ Super-agent เมื่อวันที่ 31 ตุลาคม 2026 พร้อมต้นแบบงานวิจัยภายใต้สัญญาอนุญาต MIT ซึ่งเปลี่ยนคำขอที่เกี่ยวข้องกับคลัง GitHub ให้เป็นเซสชันเขียนโค้ดแยกกัน เป้าหมายคือเปิดทางให้หลายงานเดินหน้าไปพร้อมกัน ขณะที่นักพัฒนาใช้เวลาสลับไปมาระหว่างบทสนทนาและตรวจสอบความคืบหน้าน้อยลง

การทดลองเบื้องต้นของทีมใช้ข้อความจำลองประมาณ 300 ข้อความ ซึ่งมีคำขอทำงานราว 20 รายการ Super-agent ทำงานเสร็จครึ่งหนึ่งภายใน 12.4 นาที และทำเสร็จ 95% ภายใน 15.7 นาที ส่วนระบบเปรียบเทียบที่ใช้เซสชันหลักหนึ่งเซสชันและเข้าถึงเอเจนต์ผู้ช่วยได้ ใช้เวลา 29.5 นาทีจึงทำงานได้ถึงระดับ 95% ภายใต้คำสั่งที่เป็นกลาง

คลังต้นแบบสาธารณะของ DeepSeek ซึ่งใช้ชื่อ dsh-superagent-prototype นำเสนอเวอร์ชันเผยแพร่ที่มีขอบเขตแคบและใช้งานได้จริงกว่า นั่นคือเอเจนต์เขียนโค้ดเชิงรุกสำหรับคลัง GitHub หนึ่งแห่ง ซึ่งจัดทำเป็นชุดสำหรับ DeepSeek Harness โดยจะรับฟังข้อมูลจาก GitHub และ Feishu หากเปิดใช้ จากนั้นสร้างรายการงานเมื่อผู้มีสิทธิ์ร้องขอ และตอบกลับในบทสนทนาต้นทาง ซึ่งอาจรวมถึงการเสนอ pull request เพื่อปรับแก้โค้ด

README ยังระบุคำเตือนอย่างชัดเจนว่า โค้ดที่เผยแพร่แตกต่างจากระบบภายในและบางส่วนของบทความอธิบายการออกแบบ ฟีเจอร์ที่เสนอไว้บางอย่างยังเป็นงานในอนาคต และ DeepSeek ระบุว่าเวอร์ชันนี้เป็นโค้ดวิจัย ไม่ใช่ผลิตภัณฑ์ที่เสร็จสมบูรณ์

ทีม DeepSeek Harness ซึ่งดูแลต้นแบบนี้ ระบุสถานะไว้ใน README ว่า:

ต้นแบบงานวิจัยสำหรับใช้อ้างอิงเท่านั้น ไม่ใช่ผลิตภัณฑ์อย่างเป็นทางการของ DeepSeek

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

เหตุใด DeepSeek จึงต้องการซ่อนการจัดการเซสชัน

การออกแบบของ DeepSeek เริ่มจากข้อสังเกตในการทำงานของทีมเองว่า โดยทั่วไปคนเราติดตามเซสชันเอเจนต์ที่กำลังทำงานได้พร้อมกันเพียงสามถึงห้าเซสชัน แต่ละเซสชันมีประวัติการสนทนาของตนเอง นักพัฒนาจึงต้องจำว่างานแต่ละชิ้นอยู่ที่ใด และเอเจนต์แต่ละตัวได้รับคำสั่งอะไรไปบ้าง

Harness คือซอฟต์แวร์ที่ทำงานประกอบกับโมเดล AI เพื่อจัดการเครื่องมือ ไฟล์ บทสนทนา และการประมวลผล โมเดลใช้เหตุผลกับงาน ส่วน Harness กำหนดว่างานจะไปถึงโมเดลอย่างไรและการทำงานจะดำเนินไปแบบใด Super-agent ย้ายความรับผิดชอบในการประสานงานหลายงานไปไว้ในซอฟต์แวร์ส่วนนี้มากขึ้น

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

การเปิดตัวครั้งนี้ต่อยอดจากการทดลองของ DeepSeek เมื่อวันที่ 3 ตุลาคมเรื่องความเข้ากันได้กับส่วนขยาย Claude Code ใน Harness v0.2.1-alpha.1 การอัปเดตครั้งนั้นทดสอบตัวเชื่อมสำหรับส่วนขยาย ส่วน Super-agent สำรวจวิธีที่ Harness เองจะประสานงานที่ดำเนินต่อเนื่องได้อย่างไร โดยให้เครดิต Yujia Qiao ในฐานะผู้พัฒนาระบบและเขียนบทความอธิบายการออกแบบ พร้อมระบุชื่ออีก 15 คนในฐานะผู้ร่วมทบทวนและอภิปราย

Router หนึ่งตัวประสานงาน Worker หลายตัวลงมือทำ

Super-agent แบ่งความรับผิดชอบระหว่าง Router ที่ทำงานประจำกับ Worker แยกกัน Router รับการโต้ตอบจากผู้ใช้ ดูแลข้อมูลที่ใช้ร่วมกันระหว่างงาน และมอบหมายงาน โดยไม่ลงมือเขียนโค้ดเอง เพื่อให้ยังทำหน้าที่ประสานงานได้ขณะที่เซสชันอื่นกำลังยุ่ง

Worker รับผิดชอบงานแต่ละชิ้น โดยแต่ละตัวมีบริบทการสนทนาและเครื่องมือดำเนินงานของตนเอง จึงสามารถตรวจสอบบั๊ก ตอบความคิดเห็นในการรีวิวโค้ด และแก้ไขฟีเจอร์ไปพร้อมกันได้ Worker ส่งผลลัพธ์กลับไปยัง Router ซึ่งเป็นผู้สื่อสารกับคน แทนที่จะปล่อยให้หลายเซสชันตอบกลับอย่างอิสระ

DeepSeek ระบุว่าโมเดลขนาดเล็กกว่ามักรับหน้าที่กำหนดเส้นทางงานได้ ส่วนโมเดลที่มีความสามารถสูงกว่าจะทำงานที่ส่งผลต่อคุณภาพโค้ด Worker ยังสร้างเอเจนต์ผู้ช่วยสำหรับงานที่ซับซ้อนได้ด้วย Router จัดการความสัมพันธ์ระหว่างงาน แทนที่จะวางแผนทุกขั้นตอนภายในแต่ละงาน

ต้นแบบกำหนดเซสชันและไดเรกทอรีแยกให้แต่ละรายการงาน โดยเปิดงานพร้อมกันได้ไม่เกินจำนวนที่ตั้งค่าไว้ ผู้ดูแลระบบจึงควบคุมปริมาณงานที่เริ่มพร้อมกันได้ ประวัติการสนทนาที่แยกจากกันช่วยลดโอกาสที่รายละเอียดของงานหนึ่งจะเบียดข้อมูลของอีกงานออกไป ขณะที่ Router ยังคงรักษาภาพรวมร่วมกันไว้

เปลี่ยนข้อความเป็นงานโดยไม่ขัดจังหวะอยู่ตลอด

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

DeepSeek กรองเหตุการณ์เป็นสองขั้นตอน ขั้นแรกใช้กฎของโปรแกรมตรวจสอบเรื่องต่าง ๆ เช่น แหล่งที่มา กลุ่ม และผู้ใช้ที่ได้รับอนุญาต จากนั้นโมเดลจะประเมินรายการที่เหลือโดยอาศัยบริบทและนโยบายที่เขียนไว้ วิธีนี้ช่วยลดการเรียกใช้โมเดลกับข้อความทั่วไปที่ไม่ต้องดำเนินการ

เหตุการณ์ที่เกี่ยวข้องกันจะถูกรวมเป็น Thread เช่น ความคิดเห็นใต้ pull request เดียวกันหรือหัวข้อแชตเดียวกัน เมื่อ Worker รับงานแล้ว ก็จะสมัครติดตาม Thread นั้น ความคิดเห็นและผลทดสอบที่ตามมาจึงส่งตรงไปยัง Worker ได้ โดยไม่ต้องให้ Router มอบหมายซ้ำ

การสมัครติดตามอาจทับซ้อนกันได้ Worker หลายตัวที่ทำงานกับ pull request เดียวกันสามารถรับข้อมูลอัปเดตชุดเดียวกัน ทำให้สังเกตเห็นการเปลี่ยนแปลงที่กระทบงานของตน Worker ยังติดตาม Thread ที่เกี่ยวข้องหลายรายการได้ หรือส่งเหตุการณ์กลับไปยัง Router หากอยู่นอกขอบเขตงานที่ได้รับ

ลงมือก่อน แต่พูดเมื่อมีประโยชน์เท่านั้น

DeepSeek ระบุว่า Super-agent ภายในทำงานต่อเนื่องอยู่แล้ว ทั้งจำลองและแก้ไขปัญหา ตอบสนองต่อการรีวิวโค้ด และช่วยพัฒนา Harness เอง มีกฎเป็นลายลักษณ์อักษรที่อนุญาตให้เอเจนต์ตรวจสอบบั๊กที่มีการกล่าวถึงในแชตกลุ่มได้ แม้ไม่มีใครแท็กเอเจนต์โดยตรง

กฎดังกล่าวกำหนดให้เริ่มจากการตรวจสอบอย่างเงียบ ๆ เอเจนต์จะพยายามจำลองปัญหาที่รายงานและหาวิธีแก้ไขที่เรียบง่าย ก่อนนำเสนอผลลัพธ์ที่เป็นประโยชน์ ตัวอย่างหนึ่งเกิดขึ้นเมื่อนักพัฒนากำลังคุยกันเรื่องปัญหาที่เครื่องหมายตัวหนอนแสดงผลเป็นขีดฆ่า ขณะที่เอเจนต์ได้เปิด pull request พร้อมแนวทางแก้ไขไว้แล้ว

ทีม Harness อธิบายหลักการทำงานไว้ใน README ว่า:

ใช้ความสนใจจากมนุษย์ให้น้อยที่สุด และมอบคุณค่าให้มากที่สุด

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

เก็บบริบทเก่าและคำสั่งใหม่ให้พร้อมใช้งาน

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

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

Chain of Recall เชื่อมโยงข้อมูลอ้างอิงเหล่านั้น เหตุการณ์ Thread และเซสชัน Worker จะได้รับตัวระบุที่ไม่ซ้ำกัน ทำให้เอเจนต์ย้อนจากข้อความปัจจุบันไปยังการสนทนา จากนั้นไปยัง Worker ที่เกี่ยวข้องและการรีวิวโค้ดอีกรายการได้ เป้าหมายคือดึงงานเก่ากลับมาได้แม้อยู่คนละช่องทาง โดยไม่ต้องโหลดประวัติทั้งหมดซ้ำไปซ้ำมา

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

ทีมระบุว่ากลไกนี้นำมาใช้ใน DeepSeek Harness แล้ว แต่ไม่ได้เปิดใช้เป็นค่าเริ่มต้น กฎการสื่อสารยังแตกต่างกันตามช่องทางด้วย โดยการออกแบบจำกัดคำตอบข้อความโต้ตอบทันทีไว้ที่ 100 คำต่อครั้ง ขณะที่ pull request และเอกสารจะได้รับคำอธิบายการเปลี่ยนแปลงและการตรวจสอบที่มีโครงสร้างมากกว่า

ประสานงานบนคลาวด์ ทำงานบนคอมพิวเตอร์ในเครื่อง

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

รูปแบบนี้รองรับ Bring Your Own Machine หรือ BYOM นักพัฒนาสามารถเชื่อมต่อคอมพิวเตอร์เดิมที่มีคลังโค้ด เครื่องมือ และการเปลี่ยนแปลงที่ยังทำไม่เสร็จ แทนการย้ายทุกอย่างไปยังสภาพแวดล้อมระยะไกลใหม่ การประสานงานบนคลาวด์ยังดำเนินต่อได้เมื่อคอมพิวเตอร์เครื่องนั้นตัดการเชื่อมต่อ ส่วนงานที่ต้องใช้เครื่องดังกล่าวจะรอจนกว่าอุปกรณ์จะกลับมาออนไลน์

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

DeepSeek นำเสนอองค์ประกอบเหล่านี้ในฐานะส่วนหนึ่งของการสำรวจสถาปัตยกรรมในภาพรวม README เตือนว่าชุดโค้ดสาธารณะและการนำไปใช้ภายในแตกต่างกัน นักพัฒนาจึงควรตรวจสอบโค้ดที่เผยแพร่ก่อนพึ่งพาฟีเจอร์การออกแบบใดเป็นการเฉพาะ

การทดลองวัดผลอะไรบ้าง

DeepSeek ทดลองการตั้งค่าแต่ละแบบซ้ำห้าครั้ง โดยเปรียบเทียบ Super-agent กับเวอร์ชันที่ไม่มีการส่งเหตุการณ์ตรง และการตั้งค่าสองแบบของเซสชันเดียวที่มีเอเจนต์ผู้ช่วย ภาระงานใช้ข้อความสังเคราะห์และเครื่องมือจำลองงานเขียนโค้ดที่ใช้เวลานาน โดยย่อช่วงห่างระหว่างข้อความและระยะเวลาทำงานเหลือหนึ่งในสี่

ค่ามัธยฐาน 12.4 นาทีหมายความว่าทำงานเสร็จครึ่งหนึ่งภายในเวลานั้น ส่วนเปอร์เซ็นไทล์ที่ 95 ที่ 15.7 นาทีหมายความว่าทำงานเสร็จ 95% ภายในเวลานั้น เมื่อเทียบกับเปอร์เซ็นไทล์ที่ 95 ซึ่งอยู่ที่ 29.5 นาทีของเซสชันเดียวภายใต้คำสั่งที่เป็นกลาง Super-agent ลดเวลาส่วนนี้ลง 13.8 นาที หรือราว 47%

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

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

การประสานงานที่เร็วขึ้นใช้โทเค็นแคชมากขึ้น

การทำงานพร้อมกันของ Super-agent มาพร้อมกับการใช้ข้อมูลนำเข้าที่แคชไว้มากขึ้น โดยอ่านโทเค็นที่แคชไว้ 23.23 ล้านโทเค็น เทียบกับ 6.05 ล้านและ 10.82 ล้านโทเค็นของการตั้งค่าเซสชันเดียวสองแบบ โทเค็นคือหน่วยข้อความขนาดเล็กที่โมเดลประมวลผล ส่วนการอ่านจากแคชคือการนำข้อมูลนำเข้าที่เก็บไว้จากคำขอก่อนหน้ากลับมาใช้

การนำการส่งเหตุการณ์โดยตรงออกทำให้จำนวนโทเค็นที่อ่านจากแคชเพิ่มจาก 23.23 ล้านเป็น 31.77 ล้าน หรือราว 37% และเพิ่มการตัดสินใจของ Router ประมาณ 30% ดังนั้น การส่งงานติดตามผลตรงไปยัง Worker ที่ได้รับมอบหมายจึงช่วยลดภาระการประสานงานภายใต้การออกแบบที่ทำงานพร้อมกัน

การรวมชุดคำขอช่วยให้ Router รับมือกับปริมาณงานที่สูงขึ้น เมื่ออัตราการมาถึงของเหตุการณ์เพิ่มจากประมาณหนึ่งเป็น 40 รายการต่อนาที ขนาดชุดเฉลี่ยเพิ่มจาก 1.0 เป็น 2.8 และระยะเวลาของคำขอเพิ่มจาก 2.5 เป็น 3.9 วินาที เวลาประมวลผลอนุมานที่รายงานต่อการตัดสินใจของ Router ลดจาก 6.4 เหลือ 1.6 วินาที

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

สิทธิ์ในเครื่องทำให้ความปลอดภัยเป็นประเด็นสำคัญ

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

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

DeepSeek ระบุว่าความปลอดภัยและความเป็นส่วนตัว การขยายขนาดของ Router ความทรงจำระยะยาว และการสื่อสารระหว่างอินสแตนซ์ของเอเจนต์ยังเป็นประเด็นที่ต้องพัฒนาต่อ README ขอให้ผู้ใช้ตรวจสอบและดัดแปลงโค้ด พร้อมเตือนว่าอาจยังมีบั๊กและแนวปฏิบัติทางวิศวกรรมที่ไม่สม่ำเสมอ งานวิศวกรรมส่วนใหญ่ยังทำโดยเอเจนต์เขียนโค้ดด้วย

การเปิดตัวได้รับความสนใจอย่างรวดเร็ว รวมถึงโพสต์จาก Leandro von Werra หัวหน้าฝ่ายวิจัยของ Hugging Face เหตุการณ์ต่อไปนี้แสดงให้เห็นว่าต้นแบบแพร่กระจายเร็วเพียงใด:

• 31 ตุลาคม 2026 เวลา 09:32 UTC: สร้างคลัง GitHub
• 31 ตุลาคม: ทีม Harness เผยแพร่บทความอธิบายการออกแบบ และเมื่อถึงเวลา 22:10 UTC คลังมีดาว 2,046 ดวงและ fork 172 รายการ
• 1 พฤศจิกายน เวลา 04:20 UTC: คลังมีดาวถึง 3,433 ดวง

สำหรับทีมวิศวกรรม การตัดสินใจเฉพาะหน้าอยู่ที่ว่าจะตรวจสอบและดัดแปลงระบบประสานงานทดลองนี้หรือไม่ จุดดึงดูดคือโอกาสจัดการงานได้มากขึ้นโดยมีการขัดจังหวะน้อยลง ส่วนสิ่งที่ต้องทำประกอบด้วยการตรวจสอบโค้ด การกำหนดสิทธิ์ และการตัดสินใจว่าการดำเนินการใดต้องให้คนเข้ามาเกี่ยวข้อง

ประเด็นสำคัญ

• DeepSeek เผยแพร่ต้นแบบงานวิจัยภายใต้สัญญาอนุญาต MIT สำหรับงานเขียนโค้ดในคลัง GitHub หนึ่งแห่ง พร้อมตัวเลือกเชื่อมต่อ Feishu
• Router ทำหน้าที่ประสานงาน ขณะที่ Worker แยกกันดำเนินงานพร้อมกัน
• ระบบภายในสามารถตรวจสอบบั๊กที่มีผู้รายงานได้ตามกฎที่เขียนไว้ แม้ไม่มีใครแท็กเอเจนต์โดยตรง
• การทดสอบสังเคราะห์มีเวลาทำงานเสร็จค่ามัธยฐาน 12.4 นาที และเปอร์เซ็นไทล์ที่ 95 อยู่ที่ 15.7 นาที โดยใช้โทเค็นแคชมากกว่าทางเลือกแบบเซสชันเดียว
• Worker รันคำสั่งภายใต้บัญชีของผู้ดูแลโดยไม่ต้องขออนุมัติ ทำให้สิทธิ์และข้อมูลรับรองเป็นประเด็นสำคัญ
• โค้ดสาธารณะแตกต่างจากระบบภายใน และยังเป็นต้นแบบงานวิจัย ไม่ใช่ผลิตภัณฑ์อย่างเป็นทางการของ DeepSeek