DeepSeek Super-Agent: คืออะไร ทำงานอย่างไร และยังมีสิ่งใดที่ยังขาดหายไป4 min read
Reading Time: 3 minutesเปิดตัวแทนการเขียนโค้ดสามรายการพร้อมกันแล้วคุณจะรู้สึกถึงปัญหา คนหนึ่งกำลังรอการตัดสินใจ คนหนึ่งเสร็จเมื่อยี่สิบนาทีที่แล้ว และคุณลืมไปแล้วว่าอันไหนมีการแก้ไขการตรวจสอบสิทธิ์ ทีม Harness ของ DeepSeek ระบุไว้ว่า จากประสบการณ์แล้ว บุคคลสามารถติดตามเซสชันของตัวแทนที่ทำงานอยู่ได้เพียงสามถึงห้าเซสชันในแต่ละครั้ง เมื่อผ่านจุดนั้นโมเดลจะไม่ใช่ปัญหาคอขวดอีกต่อไป คุณคือ.
เมื่อวันที่ 31 ตุลาคม 2026 ทีมงานได้เผยแพร่บทความการออกแบบสำหรับสิ่งที่เรียกว่า Super-agent และเปิดต้นแบบที่ชื่อว่า dsh-superagent เป็นตัวแทนการเขียนโค้ดเชิงรุกสำหรับที่เก็บ GitHub หนึ่งแห่ง เซสชันเราเตอร์ที่มีอายุยาวนานหนึ่งเซสชันจะพูดคุยกับผู้คนและแจกงาน และทุกคำขอที่ได้รับการยอมรับจะได้รับเซสชันของผู้ปฏิบัติงานของตัวเองซึ่งลงท้ายด้วยคำขอดึงหรือคำถาม พื้นที่เก็บข้อมูลทะลุ 12,000 ดวงในเวลาประมาณสองวัน README ตรงไปตรงมาว่านี่คือโค้ดการวิจัยและไม่ใช่ผลิตภัณฑ์ DeepSeek อย่างเป็นทางการ
คู่มือนี้มีไว้สำหรับวิศวกรและหัวหน้าทีมที่ต้องการทราบว่าต้นแบบทำอะไรได้บ้าง การออกแบบเราเตอร์และผู้ปฏิบัติงานทำงานอย่างไร ตัวเลขเกณฑ์มาตรฐานทำอะไรและไม่ได้พิสูจน์ และสิ่งที่ต้องตรวจสอบก่อนชี้ไปที่พื้นที่เก็บข้อมูลจริง
หมายเหตุหนึ่งรายการก่อนรายละเอียด คำตอบของพนักงานในการ “แก้ไขข้อบกพร่องนี้” คือการดึงคำขอ และ GitHub ก็เป็นแนวทางที่ดีสำหรับสิ่งนั้น สิ่งที่ตัวแทนที่เหลือสร้างขึ้นรอบๆ โค้ดนั้นยากที่จะวาง: การเขียนสาเหตุที่แท้จริง สรุปการทดสอบ ตารางเปรียบเทียบที่ผู้ตรวจสอบถามAgentGrid.ioเป็นพื้นที่ทำงานที่ใช้ร่วมกันซึ่งผู้คนและตัวแทน AI สร้าง แก้ไข และแบ่งปันเอกสาร แอพ และไฟล์ด้วยเวอร์ชันสด การระบุแหล่งที่มา และประวัติเดียว เรากลับมาที่จุดที่มันใกล้จะถึงจุดสิ้นสุด
DeepSeek Super-Agent คืออะไร
มีสองสิ่งปรากฏขึ้นพร้อมกัน บทความแรกเป็นบทความเกี่ยวกับการออกแบบขนาดยาว “การสำรวจการออกแบบเอเจนต์ขั้นสูง: สู่ระบบเอเจนต์ที่เป็นอิสระมากขึ้น” ทีมงาน Harness เขียนเป็นภาษาจีนและโพสต์เวอร์ชันภาษาอังกฤษที่แปลด้วยเครื่องบน X เมื่อวันที่ 1 พฤศจิกายน มีผู้เข้าชมมากกว่า 2.2 ล้านครั้ง อันที่สองคือรหัส:deepseek-ai/dsh-superagent-ต้นแบบซึ่งเผยแพร่ภายใต้ใบอนุญาต MIT
สำรวจการออกแบบเอเจนต์ขั้นสูง: สู่ระบบเอเจนต์ที่เป็นอิสระมากขึ้น
– สายรัด DeepSeek (@DeepSeekHarness)1 พฤศจิกายน 2026
มันไม่ใช่รุ่นใหม่ dsh-superagent เป็นชุดรวมสำหรับชุดสายไฟ DeepSeek, ชุดควบคุมตัวแทนโอเพ่นซอร์สของ DeepSeek ซึ่งบริษัทอธิบายไว้ในการแสดงตัวอย่างต่อสาธารณะทั่วโลก บันเดิลจะเฝ้าดูที่เก็บ GitHub หนึ่งรายการ และหากคุณเปิดไว้ การสนทนา Feishu จะเกิดขึ้น เมื่อมีคนในรายการที่อนุญาตขอให้ตัวแทนทำงาน ระบบจะเปิดรายการงาน รันงานในเซสชันและไดเร็กทอรีของตนเอง และตอบในการสนทนาต้นฉบับ แผงเว็บจะแสดงเฉพาะสิ่งที่บุคคลต้องการเท่านั้น
ชื่อง่ายกว่าที่คิด Cui Tianyi จากแผนกผลิตภัณฑ์ของ DeepSeek และหนึ่งในผู้ตรวจสอบขั้นสุดท้ายของบทความ อธิบายในโพสต์ของ Zhihu ว่า “super” มีความหมายเหมือนกับตัวยกและตัวห้อย Super-agent จะเพิ่มเลเยอร์เหนือเอเจนต์ที่ทำงาน ซึ่งตรงกันข้ามกับเอเจนต์ย่อยซึ่งจะเพิ่มเลเยอร์ลงไปด้านล่าง ไม่ใช่การกล่าวอ้างว่ามีสติปัญญาที่เหนือกว่า
README เปิดขึ้นพร้อมคำเตือนที่ควรค่าแก่การอ่านทั้งหมด: “ต้นแบบการวิจัยเพื่อการอ้างอิงเท่านั้น ไม่ใช่ผลิตภัณฑ์ DeepSeek อย่างเป็นทางการ” กล่าวเพิ่มเติมว่าวิศวกรรมส่วนใหญ่ทำโดยตัวแทนการเขียนโค้ด โค้ดอาจมีจุดบกพร่อง และการออกแบบบางส่วนในบทความนี้เป็นแนวทางสำหรับการทำงานในอนาคตและไม่ได้นำไปใช้
| ได้อย่างรวดเร็ว | dsh-superagent-ต้นแบบ |
|---|---|
| มันคืออะไร | เอเจนต์การเขียนโค้ดเชิงรุกสำหรับที่เก็บ GitHub หนึ่งชุด บรรจุเป็นชุด DeepSeek Harness |
| สถานะ | ต้นแบบการวิจัย “ไม่ใช่ซอฟต์แวร์ที่พร้อมสำหรับการผลิต” ตาม README |
| ใบอนุญาต | เอ็มไอที |
| ภาษา | TypeScript |
| ฟัง | ปัญหาของ GitHub คำขอดึง ความคิดเห็น และ CI การสนทนา Feishu เป็นทางเลือก |
| สร้างแล้ว | 31 ตุลาคม 2569 มีดาวมากกว่า 12,000 ดวงและส้อม 1,200 อันภายในวันที่ 2 พฤศจิกายน |
| วิธีการตั้งค่า | ขอให้ตัวแทนเขียนโค้ดของคุณอ่าน SETUP.md และตั้งค่าร่วมกับคุณ |
DeepSeek ดรอปอีก: dsh-superagent
เฟรมเวิร์กตัวแทนที่ทำงานผ่านปัญหา GitHub ของ repo และการประชาสัมพันธ์กับตัวแทนจำนวนมากพร้อมกัน ซึ่งออกแบบมาเพื่อดึงความสนใจจากมนุษย์ให้น้อยที่สุดเท่าที่จะเป็นไปได้ ในขณะเดียวกันก็มอบมูลค่าให้มากที่สุดเท่าที่จะเป็นไปได้
– เลอันโดร ฟอน แวร์รา (@lvwerra)31 ตุลาคม 2026
เหตุใด DeepSeek จึงบอกว่าปัญหาคอขวดเป็นที่สนใจของมนุษย์
บทความนี้เริ่มต้นจากการสังเกตง่ายๆ ในปีที่ผ่านมา Coding Agent ทำได้ดีพอที่จะทำให้งานเดียวถูกจำกัดโดยโมเดล แต่เมื่อคุณทำงานหลายอย่างพร้อมกัน ขีดจำกัดจะย้ายมาที่คุณ แต่ละเซสชั่นจะถูกแยกออกจากกัน ดังนั้นคุณจึงสลับไปมาระหว่างเซสชั่นต่างๆ ด้วยมือและติดตามสิ่งที่แต่ละคนรู้ การใส่ CLI, MCP หรือตัวเชื่อมต่อการแชทลงในเซสชันภายในเครื่องเดียวจะทำให้เครื่องได้ยินเกี่ยวกับเหตุการณ์ใหม่ แต่ยังคงบล็อกคำสั่งยาว ผสมบริบทจากงานที่แตกต่างกัน และหยุดเมื่อแล็ปท็อปของคุณเข้าสู่โหมดสลีป
คำตอบของ DeepSeek คือการหยุดถือว่าเซสชันเป็นหน่วยที่คุณจัดการ โดยจะระบุคุณลักษณะสี่ประการที่ Super-agent ควรมี:
- ต่อเนื่อง.คุณพูดคุยกับมันในที่ที่คุณทำงานอยู่แล้ว เช่น แชทหรือความคิดเห็น GitHub และมันจะทำงานเหมือนกับตัวแทนคนเดียว หากคุณขอแผน A ในการแชทและสลับไปใช้แผน B ในความคิดเห็นคำขอดึง มันจะเป็นไปตามนั้น
- มีประสิทธิผลมันรันงานที่ซับซ้อนหลายงานพร้อมกันและรับคำสั่งถัดไปก่อนที่งานสุดท้ายจะเสร็จสิ้น
- เชิงรุกมันเฝ้าดูเหตุการณ์ ดำเนินการกับสิ่งที่ควรค่าแก่การจัดการ และอยู่อย่างเงียบๆ
- ถาวรโดยจะออนไลน์อยู่และกู้คืนจากความล้มเหลวโดยที่คุณไม่ต้องรีสตาร์ท
ผู้เขียนยืนยันว่าไม่มี ReAct loop ใดที่สามารถส่งทั้งสี่ได้ ดังนั้นคุณสมบัติจึงต้องมาจากสถาปัตยกรรมรอบๆ โมเดล นั่นคือหัวข้อที่แท้จริงของบทความ และผู้อธิบายด้วยภาพด้านล่างนี้ซึ่งแบ่งปันโดย Hesam เป็นวิธีที่รวดเร็วในการดูการออกแบบทั้งหมดในหน้าเดียว
นี่คือภาพอธิบายบทความของ DeepSeek เกี่ยวกับ Super-Agent:https://t.co/bByKYDoq6h pic.twitter.com/BhzbBh3NrP
– ℏεsam (@Hesamation)1 พฤศจิกายน 2026
การออกแบบเราเตอร์และผู้ปฏิบัติงานทำงานอย่างไร
ลองนึกถึงผู้จัดการฝ่ายวิศวกรรมที่ดีที่ไม่เคยเขียนโค้ดระหว่างการทำงาน ที่เราเตอร์เป็นเซสชันที่ยาวนานซึ่งได้รับทุกข้อความจากทุกช่องทาง มันไม่ได้ทำงาน โดยจะตัดสินใจว่าจะขอข้อความอะไร ส่งมอบงานใหม่ให้กับพนักงาน และเขียนทุกคำตอบถึงผู้ที่เกี่ยวข้อง บทความบอกว่าสามารถทำงานได้โดยไม่ต้องใช้เครื่องมือเชลล์เลย และรุ่นที่เบากว่าและเร็วกว่าก็เพียงพอแล้ว
กคนงานเป็นเซสชันแยกต่างหากที่มีบริบทที่แยกออกมาและชุดเครื่องมือครบชุดสำหรับงานเดียว คนงานไม่เคยพูดคุยกับผู้คนโดยตรง พวกเขารายงานสถานะไปยังเราเตอร์ ซึ่งจะตอบกลับเป็นเสียงเดียว ในต้นแบบ ตั๋วแต่ละใบจะได้รับเซสชันและไดเร็กทอรีของตัวเอง ซึ่งโดยทั่วไปแล้วจะเป็นเวิร์กทรี git และจำนวนผู้ปฏิบัติงานจะถูกจำกัดไว้ ค่าเริ่มต้นคือครั้งละ 3 ช่อง ปรับได้ตั้งแต่ 1 ถึง 16 ช่อง โดยมีช่องพิเศษ 1 ช่องที่ว่างเพื่อให้ข้อความของบุคคลสามารถผ่านได้ตลอดเวลา
รายละเอียดสองประการทำให้เป็นมากกว่าคิวงาน
การติดตามผลจะข้ามเราเตอร์เมื่อผู้ปฏิบัติงานเป็นเจ้าของคำขอดึงหรือเธรดการสนทนาแล้ว ผู้ปฏิบัติงานจะสมัครรับเธรดนั้น ความคิดเห็นในภายหลังจะตรงไปที่มัน โดยไม่มีการเรียกโมเดลเพิ่มเติมที่เราเตอร์ หากความคิดเห็นเกี่ยวกับสิ่งอื่น พนักงานจะส่งคืน
ระเบิดได้รับการแบทช์ทริกเกอร์ที่มาถึงระหว่างรุ่นหนึ่งจะเข้าคิวและถูกฉีดเข้าด้วยกันในการเรียกครั้งถัดไป ผู้เขียนวัดผลและเราดูตัวเลขด้านล่าง

อีกจุดหนึ่งที่ตรงกันข้าม บทความนี้ทำให้สิ่งนี้แตกต่างจากทีมตัวแทน ในทีมตัวแทน ลีดจะแบ่งงานที่ซับซ้อนหนึ่งงานออกเป็นขั้นตอนและประสานงานบทบาทที่ทำงานอยู่ ซึ่งเป็นภาระการให้เหตุผลจำนวนมาก เราเตอร์ Super-agent จะมอบหมายงานอิสระเท่านั้นและติดตามว่างานเหล่านั้นเกี่ยวข้องกันในระดับสูงอย่างไร มันไม่สลายตัวงานเอง
ทำอย่างไรเมื่อไม่มีใครถาม?
นี่คือจุดที่ปรัชญาของโครงการนำไปใช้ได้จริง เอกสารฉบับแรกในพื้นที่เก็บข้อมูลระบุหลักการไว้ในบรรทัดเดียว: ให้ความสนใจของมนุษย์ให้น้อยที่สุดเท่าที่จะเป็นไปได้ และให้คุณค่ามากที่สุด ทุกข้อความที่ตัวแทนส่งต้องเสียความสนใจจากเพื่อนร่วมงาน ดังนั้นจึงพูดเฉพาะเมื่อบุคคลต้องดำเนินการหรือสามารถใช้ผลลัพธ์ได้ และจะดำเนินการเฉพาะเมื่อถูกถามหรือเมื่อกฎที่ทีมเขียนอนุญาตเท่านั้น
ประตูที่บังคับใช้นี้เป็นโค้ดธรรมดา ไม่ใช่แบบจำลอง จะตรวจสอบว่าใครเป็นผู้ถามกับรายชื่อที่อนุญาตของทีม และบันทึกว่าคำขอมีความเข้มแข็งเพียงใด:
| ความแข็งแกร่ง | ตัวอย่างจากเอกสาร | เกิดอะไรขึ้น |
|---|---|---|
| ชัดเจน | บุคคลในรายชื่อที่อนุญาตกล่าวถึงตัวแทน หรือติดตามกระทู้ที่มีตั๋วอยู่แล้ว | ตัวแทนรับงานทุกโหมด |
| สรุป | บอทในรายการบอทของแหล่งที่มา หรือการติดตามผลของบุคคลที่ไม่อยู่ในรายการ ข้อความที่ไม่ได้ระบุที่อยู่ซึ่งทีมเลือกรับ | ประเมินตามกฎเกณฑ์ของทีมที่เขียนไว้ ในโหมดการสังเกตเริ่มต้น จะถูกบันทึกเป็น “จะยอมรับ” เท่านั้น |
| ไม่รับเข้า | บอทอื่นๆ อะไรก็ตามที่ตารางการรับเข้าไม่สนใจ | ดรอปก่อนเรียกรุ่นใดๆ |
โหมดสังเกตนั้นเป็นส่วนที่ฉันชอบมากที่สุด เจ้าหน้าที่เริ่มต้นด้วยการบันทึกสิ่งที่จะทำ เพื่อให้ทีมสามารถอ่านบันทึกเหล่านั้นบนแท็บประเมิน และขยายสิทธิ์อนุญาตเฉพาะเมื่อเห็นว่าถูกต้องเท่านั้น ข้อความ ความคิดเห็น และเอกสารที่ยกมาถือเป็นข้อมูลประกอบการตัดสินใจ พวกเขาไม่สามารถเปลี่ยนแปลงสิ่งที่ตัวแทนสามารถทำได้
บทความการออกแบบแสดงให้เห็นว่าการทำงานเชิงรุกในทางปฏิบัติเป็นอย่างไร ในกลุ่มผู้ใช้ DeepSeek Harness ภายใน ทีมงานได้กำหนดค่านโยบาย “ทำซ้ำและแก้ไขแบบเงียบๆ” เมื่อมีคนรายงานปัญหาหรือหารือเกี่ยวกับการเปลี่ยนแปลงที่เสนอ ตัวแทนจะพยายามทำซ้ำและค้นหาวิธีแก้ไขในเบื้องหลัง และจะให้ผลลัพธ์หลังจากที่ยืนยันปัญหาและพบวิธีแก้ไขง่ายๆ แล้วเท่านั้น ไม่งั้นมันก็เงียบไป บทความนี้ยังให้กฎที่ชัดเจนสำหรับช่องแชทที่ผู้เขียนบอกว่าพวกเขาตรวจสอบแล้ว: จำกัดแต่ละคำตอบไว้ที่ 100 คำ ในทางตรงกันข้าม ใน GitHub คำขอดึงควรมีความหนาแน่น โดยมีพื้นหลังของปัญหา คำอธิบายการเปลี่ยนแปลง และผลการตรวจสอบ
ตามค่าเริ่มต้น ทุกข้อความ GitHub ที่เจ้าหน้าที่โพสต์จะเริ่มต้นด้วยบรรทัด “นี่คือโดยตัวแทนอัตโนมัติ ไม่ใช่มนุษย์” ทีมสามารถแก้ไขได้พร้อมกับข้อความแจ้งที่เหลือ
ตัวเลขมาตรฐานยังคงอยู่หรือไม่?
บทความนี้มีการทดลองเล็กๆ น้อยๆ และผู้เขียนระมัดระวังที่จะเรียกว่าเป็นการบ่งชี้เท่านั้น การออกแบบสี่แบบวิ่งเคียงข้างกันในสตรีมของการแชทเป็นกลุ่มและข้อความ CI: ประมาณ 300 ข้อความต่อการเรียกใช้ ประมาณ 20 ข้อความเป็นคำขอทำงานจริง และห้าการรันต่อครั้ง งานเขียนโค้ดถูกจำลองโดยเครื่องมือที่กินเวลา ดังนั้นการทดสอบจึงวัดการกำหนดเวลาและการประสานงาน ไม่ใช่คุณภาพของโค้ดของใครก็ตาม
| การออกแบบ | เวลาเสร็จงาน p50 / p95 (นาที) | โทเค็นการอ่านแคชต่อการรัน |
|---|---|---|
| ตัวแทนซุปเปอร์ | 12.4 / 15.7 | 23.2M |
| Super-agent ที่ไม่มีการส่งผ่าน | 12.6 / 15.5 | 31.8ล |
| เซสชันเดียวพร้อมเครื่องมือตัวแทนย่อย พร้อมท์เป็นกลาง | 20.4 / 29.5 | 6.1ล้าน |
| เซสชันเดียวพร้อมเครื่องมือตัวแทนย่อย พร้อมท์การมอบหมาย | 13.8 / 29.0 | 10.8M |
อ่านตารางสองครั้ง เพราะพาดหัวข่าวไม่ใช่เนื้อหาทั้งหมด การออกแบบเราเตอร์ลดเวลาในการดำเนินการ p95 ลงเหลือประมาณครึ่งหนึ่งของเซสชันเดียว แต่ใช้โทเค็นการอ่านแคชประมาณสองถึงสี่เท่า และแถวที่น่าสนใจที่สุดคือแถวที่สอง: การลบทางลัดการส่งผ่านไม่ได้ทำให้งานเสร็จเร็วขึ้นหรือช้าลง เพียงแต่ทำให้เราเตอร์ตัดสินใจได้มากขึ้นประมาณ 30 เปอร์เซ็นต์ และเผาผลาญโทเค็นมากขึ้น 37 เปอร์เซ็นต์
การอ่านของฉันคือการค้นพบที่แท้จริงอยู่ในแถวเซสชันเดียว ด้วยการแจ้งเตือนที่เป็นกลาง โมเดลจะไม่เรียกตัวแทนย่อยในการรันใดๆ ในห้าครั้ง มันทำงานได้ด้วยตัวเอง ข้อความใหม่ๆ เข้ามารบกวน และงานที่ช้าที่สุดใช้เวลา 29.5 นาที ด้วยพรอมต์ที่บอกให้มอบหมาย มอบหมายให้ดำเนินการสี่ในห้ารอบ และในการดำเนินการที่เหลือ แบบจำลองตัดสินงานว่า “เล็ก” และดำเนินการด้วยตัวมันเอง เซสชันเดียวขึ้นอยู่กับอารมณ์ของโมเดล เราเตอร์ที่ไม่ได้รับอนุญาตให้รันโค้ดไม่สามารถทำผิดพลาดได้
การทดสอบความเครียดแยกต่างหากบนเราเตอร์เพียงอย่างเดียวทำให้อัตราการมาถึงของเหตุการณ์ที่คุ้มค่าต่อการตัดสินใจจากประมาณ 1 เป็นประมาณ 40 ต่อนาที ชุดงานโดยเฉลี่ยเพิ่มขึ้นจาก 1.0 เป็น 2.8 เหตุการณ์ เวลาต่อคำขอเพิ่มขึ้นเพียง 2.5 เป็น 3.9 วินาที และเวลาตัดจำหน่ายต่อการตัดสินใจลดลงจาก 6.4 เป็น 1.6 วินาที ยิ่งมีเหตุการณ์สะสมมากขึ้น แต่ละกิจกรรมก็จะยิ่งถูกลง ไปจนถึงขีดจำกัดที่ผู้เขียนกล่าวว่าขึ้นอยู่กับความยาวของบริบทและจำนวนเหตุการณ์ที่แบบจำลองสามารถจัดการได้อย่างแม่นยำในคราวเดียว
DeepSeek เพิ่งเปิดซอร์สต้นแบบ Super-agent เซสชันเราเตอร์หนึ่งจะพูดคุยกับผู้คนและแจกงาน และพนักงานที่แยกออกมาจะรันงานควบคู่ไปกับเหตุการณ์ GitHub ในการทดสอบของพวกเขาเอง เวลาเสร็จสิ้น p95 ลดลงจาก 29.5 เป็น 15.7 นาที เมื่อเทียบกับเซสชันเดียวที่ใช้ตัวแทนย่อย
วาฬเปิดแหล่งที่มาอีกครั้งpic.twitter.com/mS4sRbHmyx
– อ้วน (@kimmonismus)1 พฤศจิกายน 2026
นี่เป็นผลลัพธ์ที่รายงานด้วยตนเองเกี่ยวกับงานสังเคราะห์ พวกเขาแสดงให้เห็นว่าแนวคิดเรื่องการจัดตารางเวลานั้นดี พวกเขาไม่ได้แสดงว่าต้นแบบแก้ไขข้อบกพร่องของคุณได้เร็วขึ้น
คนใกล้ชิดกับโครงการพูดถึงขีดจำกัดของมันว่าอย่างไร?
ไม่นานหลังจากการเปิดตัว Cui Tianyi จากแผนกผลิตภัณฑ์ของ DeepSeek และเป็นหนึ่งในผู้ตรวจสอบขั้นสุดท้ายของบทความการออกแบบ ได้เขียนขึ้นมาว่าเขามองการออกแบบนี้อย่างไร การวางกรอบของเขามีประโยชน์เพราะมันดูเรียบง่าย เขาตั้งชื่อการแลกเปลี่ยนจากส่วนกลางว่ามีความต่อเนื่องระหว่างงานกับปริมาณงาน
ในขีดจำกัด การตรวจสอบจะเป็นไปโดยตรง ต้นแบบใช้เพียงส่วนหนึ่งของการออกแบบที่เสนอเท่านั้น จากการตรวจสอบของเขา DeepSeek Harness ไม่มีหน่วยความจำระยะยาวในตัวตลอดเซสชัน และระบบได้รับการตรวจสอบเฉพาะในสภาพแวดล้อมขนาดเล็กและเชื่อถือได้ภายในบริษัทเท่านั้น ส่วนปัญหาแบบเปิดของบทความนี้แสดงรายการการปรับขนาดเราเตอร์ หน่วยความจำในช่วงหลายเดือน การทำงานโดยไม่มีเซสชัน ขอบเขตบริบทระหว่างเอเจนต์ และวิธีที่เอเจนต์ที่แยกออกมาควรพูดคุยกัน และความปลอดภัย
คุณควรตรวจสอบอะไรบ้างก่อนใช้งาน?
เอกสารประกอบมีความตรงไปตรงมามากกว่าโพสต์เปิดตัวส่วนใหญ่ และถือว่าคำเตือนเป็นไปตามข้อกำหนด
- คนงานสามารถเข้าถึงได้อย่างกว้างขวางทั้งการตั้งค่าสิทธิ์ล่วงหน้าสำหรับเราเตอร์และพนักงานทำงานด้วย
danger-full-accessในฐานะผู้ใช้ OS ของโอเปอเรเตอร์ Wrappers ของบัญชีเลือกข้อมูลรับรอง GitHub ที่ตัวแทนใช้ แต่เอกสารระบุว่าเป็นค่าเริ่มต้นและไม่ใช่ขอบเขตด้านความปลอดภัย เนื่องจากผู้ปฏิบัติงานยังคงสามารถเรียกใช้โปรแกรมตามเส้นทางที่แน่นอนหรืออ่านโฮมไดเร็กตอรี่ของคุณได้ คำแนะนำคือบัญชีระบบปฏิบัติการเฉพาะซึ่งเก็บเฉพาะข้อมูลประจำตัวของตัวแทนเท่านั้น - ข้อมูลที่ไม่น่าเชื่อถือคือคำถามเพื่อความปลอดภัยแบบเปิดบทความนี้เตือนว่าหากการแจ้งล่วงหน้าหรือการบุกรุกเซิร์ฟเวอร์ส่งผลกระทบต่อ Cloud Agent Loop อุปกรณ์ที่เชื่อมต่อทุกเครื่องก็สามารถเข้าถึงได้ และข้อมูลรับรองที่เข้าสู่บริบทของโมเดลอาจรั่วไหลได้
- มนุษย์ผสานกันโดยค่าเริ่มต้นตัวแทนไม่เคยเปิดใช้งานการรวมอัตโนมัติภายใต้บัญชีของตนเอง การรวมอัตโนมัติจำเป็นต้องมี CLI ของบัญชีที่สองที่มีชื่ออยู่ในข้อความแจ้งข้อกำหนดในการจัดส่ง และคำแนะนำเริ่มต้นจะอนุญาตเฉพาะคำขอดึงข้อมูลขนาดเล็กที่ได้รับอนุมัติภายใต้บรรทัดที่เปลี่ยนแปลง 200 บรรทัดเท่านั้น
- มันถูกสร้างขึ้นรอบ ๆ ที่เก็บข้อมูลเดียวการตั้งค่าแต่ละรายการจะเฝ้าดูพื้นที่เก็บข้อมูล GitHub เดียว และ Feishu ซึ่งเป็นเครื่องมือแชทในที่ทำงานที่ใช้กันทั่วไปในจีน ก็เป็นแหล่งข้อมูลชั้นหนึ่งอีกแหล่งหนึ่ง
- คุณต้องมีสายรัด DeepSeek และผู้ให้บริการรุ่นรายการการตั้งค่า Node.js 22.19 หรือใหม่กว่า, pnpm, git 2.32 หรือใหม่กว่า, tmux, Python 3.8 หรือใหม่กว่า และ GitHub CLI 2.48 หรือใหม่กว่า การกำหนดค่าผู้ให้บริการโมเดลเป็นขั้นตอนของผู้ดำเนินการ
- เสียงรบกวนเป็นค่าใช้จ่ายเอกสารปรัชญากล่าวว่าอย่าใช้ตัวแทนเพื่อสร้างปริมาณ คำขอดึงจำนวนมากและข้อความออกอากาศทำให้ทีมของคุณเสียค่าใช้จ่ายมากกว่าที่พวกเขาให้ได้
คุณจะลองใช้งานโดยไม่เสี่ยงกับพื้นที่เก็บข้อมูลหลักของคุณอย่างไร
การตั้งค่ามีหลายขั้นตอน ดังนั้นโปรเจ็กต์จะขอให้คุณให้ตัวแทนการเขียนโค้ดดำเนินการกับคุณ จากข้อมูลของ README เอเจนต์จะถามคำถามสั้นๆ ทีละคำถาม แสดงแผนทั้งหมดหนึ่งครั้ง จากนั้นจึงติดตั้งและกำหนดค่าทุกอย่าง การวิ่งครั้งแรกด้วยความระมัดระวังมีลักษณะดังนี้:
- เลือกพื้นที่เก็บข้อมูลแบบใช้แล้วทิ้งและบัญชีผู้ใช้เครื่องหรือระบบปฏิบัติการเฉพาะ อย่าใช้การเข้าสู่ระบบของคุณเอง
- สร้างบัญชี GitHub แยกต่างหากสำหรับตัวแทนทุกอย่างที่เขียนจะปรากฏภายใต้ชื่อนั้น
- เปิดพื้นที่เก็บข้อมูลในเอเจนต์การเขียนโค้ดของคุณแล้ววางข้อความแจ้งด้านล่างตอบคำถามทีละข้อ
- เก็บรายการที่อนุญาตไว้กับตัวเองและออกจากโหมดยอมรับในการสังเกต
- ขอสิ่งเล็กๆ น้อยๆจากบัญชีที่ได้รับอนุญาตแสดงความคิดเห็น
@<agent login> <request>ในประเด็นหนึ่ง ตั๋วควรปรากฏบนภาพรวมของแผงภายในเวลาประมาณหนึ่งนาที - อ่านแท็บประเมินผลเป็นเวลาหนึ่งสัปดาห์ขยายรายการหรือเปลี่ยนเป็นอัตโนมัติเฉพาะเมื่อบันทึก “จะยอมรับ” ดูถูกต้องเท่านั้น
เอกสารปรัชญาของโครงการให้กฎสี่ข้อแก่ผู้ปฏิบัติงานที่ควรค่าแก่การทำซ้ำ: เริ่มให้แคบลง ปรับแต่งเพื่อให้มีเสียงรบกวนน้อยลง อย่าใช้ตัวแทนเพื่อสร้างระดับเสียง และเป็นเจ้าของสิ่งที่กล่าวไว้ในชื่อของคุณ
งานตัวแทนที่เหลือจะไปไหนดี?
สมมติว่าพนักงานใช้เวลาหนึ่งชั่วโมงในการทดสอบการรวมระบบที่ไม่สม่ำเสมอ คำขอดึงคือการแก้ไข แต่การสืบสวนเบื้องหลัง ซึ่งการทดสอบล้มเหลว ซึ่งสมมุติฐานว่าตัดออกไป สิ่งที่ตารางเวลาแสดงให้เห็น ไม่อยู่ในคำอธิบายของการประชาสัมพันธ์ และนั่นคือสิ่งที่ผู้วิจารณ์ต้องการท้าทายอย่างแท้จริง หากสิ่งนั้นเกิดขึ้นเฉพาะในการตอบกลับแชทเท่านั้น เจ้าหน้าที่หรือเพื่อนร่วมทีมคนต่อไปจะเริ่มต้นใหม่ทั้งหมด
AgentGrid.ioถูกสร้างขึ้นสำหรับแฮนด์ออฟนั้น มนุษย์และเจ้าหน้าที่ AI ทำงานในเอกสาร แอป และไฟล์ที่ใช้งานจริงเดียวกัน โดยมีที่อยู่ที่เสถียรแห่งเดียว การเข้าถึงที่ควบคุมได้ และประวัติเวอร์ชัน เอกสารของ AgentGrid.io อธิบายการเชื่อมต่อเอเจนต์ที่มีความสามารถคำสั่งโดยการรันnpx @animaapp/cli@latest login. เจ้าหน้าที่อนุมัติชื่อ ทีม และสิ่งที่ตัวแทนสามารถทำได้ เช่น อ่าน เขียน แบ่งปัน หรือเผยแพร่ หลังจากนั้นการเปลี่ยนแปลงของตัวแทนจะปรากฏในประวัติภายใต้ชื่อของตนเอง ต้นแบบไม่มีการผสานรวม AgentGrid.io ในตัว ดังนั้นให้ถือว่านี่เป็นรูปแบบที่จะลองใช้กับผู้ปฏิบัติงาน ไม่ใช่คุณลักษณะที่บันทึกไว้
ในทางปฏิบัติ ผู้ปฏิบัติงานเขียนการสอบสวนเป็นไฟล์ Markdown ผู้ตรวจสอบแสดงความคิดเห็นในแถวของตาราง ผู้ช่วยอีกคนกระชับข้อมูลสรุป และคำขอดึงลิงก์ไปยังเวอร์ชันปัจจุบันหนึ่งเวอร์ชันแทนที่จะเป็นสำเนาที่วางสามชุด
หากต้องการลองพิจารณาอีกหลายๆ คนโดยใช้ตัวแทนเดียวกัน โปรดดูคำแนะนำของเราGrok Bot ทีมบอท. และหากคุณสงสัยว่ามีอะไรอยู่ภายใต้ตัวแทนที่โฮสต์อยู่ คำแนะนำของเราClaude Managed Agentsดูสมองและมือเดียวกันในเวอร์ชันของ Anthropic แยก ซึ่งบทความของ DeepSeek อ้างอิง
เมื่อใดที่คุณควรใช้ dsh-superagent และเมื่อใดควรใช้อย่างอื่น?
- ใช้ dsh-superagentเพื่อเรียนรู้จากการออกแบบที่จริงจังและบันทึกไว้ เพื่อทำการทดลองที่มีอยู่ในพื้นที่เก็บข้อมูลที่มีความเสี่ยงต่ำ หรือยืมแนวคิดต่างๆ เช่น เราเตอร์ที่ไม่เคยรันโค้ด ตั๋วที่มีขอบเขตระบุไว้ โหมดสังเกตก่อนโหมดอัตโนมัติ
- ใช้ตัวแทนการเข้ารหัสแบบโต้ตอบเดียวเมื่อคุณทำงานทีละงานและต้องการนำทางทีละขั้นตอน Super-agent ถูกสร้างขึ้นเพื่อสถานการณ์ตรงกันข้าม
- ใช้ AgentGrid.ioเมื่อเอาต์พุตเป็นเอกสาร รายงาน หรือแอปที่บุคคลและตัวแทนหลายคนจำเป็นต้องตรวจสอบ แก้ไข และเผยแพร่ ไม่ว่าตัวแทนคนใดจะผลิตออกมาก็ตาม
คำถามที่พบบ่อย
DeepSeek Super-Agent คืออะไร?
เป็นงานวิจัยต้นแบบชื่อ dsh-superagent ซึ่งเผยแพร่โดยทีมงาน Harness ของ DeepSeek เมื่อวันที่ 31 ตุลาคม 2026 ภายใต้ใบอนุญาต MIT เป็นตัวแทนการเขียนโค้ดเชิงรุกสำหรับที่เก็บ GitHub หนึ่งแห่ง เซสชันเราเตอร์ที่มีอายุการใช้งานยาวนานจะรับคำขอและมอบหมายคำขอที่ได้รับการยอมรับแต่ละรายการให้กับเซสชันของผู้ปฏิบัติงานของตนเอง ซึ่งจะตอบในการสนทนาดั้งเดิม ซึ่งโดยปกติจะเป็นคำขอแบบดึง
DeepSeek Super-Agent เป็นผลิตภัณฑ์ DeepSeek อย่างเป็นทางการหรือไม่
ไม่ README เรียกสิ่งนี้ว่าต้นแบบการวิจัยสำหรับการอ้างอิงเท่านั้น ไม่ใช่ผลิตภัณฑ์ DeepSeek อย่างเป็นทางการ และบอกให้ตรวจสอบและปรับใช้ก่อนที่จะใช้ในสภาพแวดล้อมของคุณเอง นอกจากนี้ยังไม่เหมือนกับเวอร์ชันภายในหรือการใช้งานตามที่บทความการออกแบบอธิบาย
Super-agent แตกต่างจากตัวแทนย่อยอย่างไร?
ตัวแทนย่อยจะเพิ่มเลเยอร์ด้านล่างตัวแทนที่ทำงาน Super-agent จะเพิ่มเลเยอร์ไว้ด้านบน ในการออกแบบนี้ เราเตอร์ตั้งอยู่เหนือพนักงานจำนวนมาก พูดคุยกับผู้คน และมอบหมายงาน ในขณะที่พนักงานแต่ละคนจัดการงานเดียวโดยแยกจากกัน ชื่อนี้เป็นเรื่องเกี่ยวกับตำแหน่ง ไม่ใช่การกล่าวอ้างถึงความฉลาดที่มากขึ้น
ต้องใช้ Feishu หรือเฉพาะ GitHub เท่านั้น
GitHub เพียงอย่างเดียวก็เพียงพอแล้ว Feishu เป็นแหล่งที่สองที่เป็นทางเลือก และเอกสารระบุว่าการตั้งค่า Feishu ล้มเหลวจะปิดใช้งานเฉพาะแหล่งที่มา Feishu เท่านั้น
การรันบนพื้นที่เก็บข้อมูลของบริษัทปลอดภัยหรือไม่
ไม่เหมือนที่เป็นอยู่ เอกสารระบุว่าผู้ปฏิบัติงานทำงานโดยมีสิทธิ์เข้าถึงแบบเต็มในฐานะผู้ใช้ระบบปฏิบัติการของผู้ปฏิบัติงาน และบัญชี Wrapper ไม่ใช่ขอบเขตการแยกตัว พวกเขาแนะนำบัญชีระบบปฏิบัติการเฉพาะ บัญชีตัวแทนเฉพาะบน GitHub รายการที่อนุญาตสั้นๆ และโหมดสังเกตในขณะที่คุณเรียนรู้ว่าตัวแทนทำงานอย่างไร
เร็วกว่าเซสชันการเข้ารหัสเอเจนต์เดียวหรือไม่
ในการทดสอบจำลองของผู้เขียนเอง การออกแบบเราเตอร์เสร็จสิ้นงานที่ช้าที่สุดใน 15.7 นาที เทียบกับ 29.5 นาทีสำหรับเซสชันเดียวด้วยเครื่องมือตัวแทนย่อย โดยใช้โทเค็นมากขึ้น การทดสอบใช้การเขียนโค้ดจำลองและการรัน 5 ครั้งต่อการออกแบบ ดังนั้นจึงแสดงให้เห็นถึงประโยชน์ของการจัดกำหนดการ ไม่ใช่คุณภาพของโค้ด

Figma
Adobe XD


