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

นี่คือความหมายที่น่าสนใจของคำโปรย “Everything is a Plugin” ใน DeepSeek Harness หรือ dsh โครงการโอเพนซอร์สจาก DeepSeek AI ตัวมันเป็น agent harness—โครงที่ทำให้โมเดลเข้าใจสภาพแวดล้อม ใช้เครื่องมือ และทำงานต่อเนื่อง—แต่เลือกย้ายความสามารถแทบทั้งหมดออกจากแกนระบบ

ผลที่ตามมาไม่ใช่แค่มีปลั๊กอินให้ติดเพิ่ม ทีมสามารถมอง harness เป็นชุดชิ้นส่วนที่ประกอบ เปลี่ยน และทดลองได้ โดยไม่ต้องเริ่มจากการ fork แกนหลักทุกครั้ง ขณะเดียวกัน โครงการยังอยู่ในสถานะ developer preview จึงควรอ่านสถาปัตยกรรมนี้เป็นพื้นที่ทดลองที่น่าจับตา ไม่ใช่คำรับรองว่าพร้อมเป็นฐาน production แล้ว

Cordis kernel ทำหน้าที่เป็นแกน แต่ไม่ทำตัวเป็น Agent

หัวใจของโครงสร้างนี้คือ Cordis kernel ซึ่งรับผิดชอบวงจรชีวิตของปลั๊กอิน ได้แก่ การโหลด การถอด และการจัดการ dependency ระหว่างกัน สิ่งที่มันจงใจไม่มีคือความสามารถเฉพาะของ agent

โมเดล เครื่องมือ สกิล เซสชัน แซนด์บ็อกซ์ สตอเรจ ลูปการทำงาน ตัวจัดตาราง และ UI ล้วนเข้ามาในรูปปลั๊กอิน แต่ละชิ้นทำงานร่วมกันผ่านบริการและอีเวนต์ของ Cordis เส้นแบ่งนี้ทำให้ “core” กับ “ความสามารถที่ผู้ใช้สัมผัส” เป็นคนละชั้นอย่างชัดเจน

สำหรับทีมที่สร้าง coding agent หรือ internal agent ความต่างอยู่ที่จุดควบคุม หากเครื่องมือหรือระบบเซสชันผูกแน่นกับ core การเปลี่ยนส่วนหนึ่งอาจพาให้ต้องแตะโค้ดหลายชั้น แต่ในแนวทางของ dsh จุดประกอบย้ายมาอยู่ที่ปลั๊กอินและ configuration มากขึ้น DeepSeek ระบุว่านักพัฒนาสามารถเลือก เปลี่ยน หรือขยายความสามารถที่ชั้น configuration ได้โดยไม่ต้องแก้ซอร์สของ DeepSeek Harness

นี่ไม่ได้แปลว่าทุกปลั๊กอินจะสลับแทนกันได้โดยไม่มีต้นทุน Dependency, interface และพฤติกรรมระหว่างชิ้นส่วนยังเป็นเรื่องที่ทีมต้องตรวจสอบ ประโยชน์ของสถาปัตยกรรมคือมันทำให้ขอบเขตของการเปลี่ยนแปลงชัดขึ้น และเปิดจุดต่อยอดไว้ตั้งแต่ต้น

“เปิดให้เกิด ecosystem” ไม่เท่ากับ “ecosystem โตแล้ว”

เมื่อโมเดล เครื่องมือ ระบบจัดเก็บ และ UI ต่างมีขอบเขตแบบปลั๊กอิน ผู้พัฒนาภายนอกย่อมมีตำแหน่งให้สร้างของต่อได้หลายระดับ Repository ยังแนะนำให้ผู้เผยแพร่ปลั๊กอินใส่ topic dsh-plugin เพื่อให้ค้นพบโครงการได้ง่ายขึ้น ขณะที่ DeepSeek เชิญชวนให้นักพัฒนาร่วมสำรวจโครงสร้างพื้นฐานที่เปิดซอร์ส ใช้ซ้ำได้ และประกอบได้

จากสามองค์ประกอบนี้—สถาปัตยกรรมที่มีจุดต่อขยาย, ช่องทางค้นพบ และคำเชิญให้ร่วมพัฒนา—จึงพอสรุปได้ว่า DeepSeek Harness เปิดทางให้ ecosystem หรือระบบนิเวศปลั๊กอินเริ่มก่อตัวได้ทันที

แต่ยังข้ามไปสรุปไม่ได้ว่าระบบนิเวศนั้นเติบโตหรือแข็งแรงแล้ว ภาพหน้าตั้งค่าข้างต้นบอกเพียงว่า UI แสดงรายการปลั๊กอิน 132 รายการ ณ เวลาจับภาพ แหล่งข้อมูลไม่ได้แจกแจงว่ามีกี่รายการที่มาจากชุมชน มีคุณภาพหรือความปลอดภัยระดับใด หรือถูกใช้งานจริงมากน้อยแค่ไหน อีกทั้ง core plugins และ API พื้นฐานยังอยู่ระหว่างปรับปรุง

ถ้าทีมกำลังประเมิน platform คำถามที่ควรถามจึงไม่ใช่แค่ “มีปลั๊กอินกี่ตัว” แต่ควรลงไปดูว่า:

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

สี่โหมดคือตัวอย่างของการประกอบ ไม่ใช่อันดับความเก่ง

หน้าแนะนำ DeepSeek Harness แสดงโหมดการทำงานสี่แบบ แต่ละแบบสะท้อนว่าชุดความสามารถต่างกันสามารถประกอบเป็นประสบการณ์คนละแบบได้

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

มุมนี้ช่วยแยกคำสามคำออกจากกันได้ชัดขึ้น: architecture คือการแยกทุกส่วนเป็นปลั๊กอิน, mode หรือ preset คือชุดส่วนประกอบที่เลือกมาสร้างประสบการณ์หนึ่งแบบ และ ecosystem คือผู้สร้าง ปลั๊กอิน และช่องทางค้นพบที่เติบโตบนจุดต่อเหล่านั้น ทั้งสามชั้นเกี่ยวข้องกัน แต่ไม่ใช่สิ่งเดียวกัน

Session log ทำให้ตามรอยได้ แต่ยังไม่ตอบนโยบายข้อมูล

ระบบ agent มักวิเคราะห์ยากตรงที่ผลลัพธ์สุดท้ายบอกไม่ครบว่าโมเดลเห็นอะไร เรียกเครื่องมือใด หรือมี context ใดแทรกระหว่างทาง ตามเอกสารของ DeepSeek Harness, session log แบบ append-only บันทึก system prompt, chain of thought, การเรียกเครื่องมือและผลลัพธ์, การจัดตาราง sub-agent ตลอดจน context injection ในแต่ละครั้ง

Trajectory view นำข้อมูลเหล่านี้มาแสดงตามแหล่งที่มา ภาพตัวอย่างแยกช่วง Input, Model และ Tools พร้อมรายละเอียดของ tool เช่น payload, result, schema และ timing DeepSeek ยังระบุว่าการกู้คืน การแตกแขนง การค้นคืน และการเล่นซ้ำอาศัย event stream เดียวกัน

สิ่งนี้ให้พื้นฐานสำหรับตามรอยพฤติกรรมของ agent แต่ยังไม่ควรถูกตีความว่าแก้โจทย์ governance ครบแล้ว แหล่งข้อมูลอธิบายชนิดข้อมูลที่บันทึก ทว่าไม่ได้ระบุนโยบาย retention, access control, privacy หรือการปกป้องข้อมูล หากจะทดลองกับข้อมูลองค์กร ทีมต้องหาคำตอบเรื่องผู้เข้าถึง ระยะเวลาเก็บ การลบ และตำแหน่งจัดเก็บเพิ่มเติมเอง

ลอง Web UI ได้ด้วยคำสั่งเดียว

เมื่อติดตั้ง Node.js แล้ว เริ่ม Web UI จากแพ็กเกจ npm ได้ดังนี้

npx @deepseek-ai/dsh web

ค่าเริ่มต้นให้บริการที่ http://127.0.0.1:3080 ส่วนแพ็กเกจ @deepseek-ai/dsh อธิบายตัวเองว่าเป็น CLI สำหรับ boot profile, จัดการปลั๊กอิน และเป็น alias สำหรับ browser UI เวอร์ชันที่หน้า npm ในแหล่งข้อมูลแสดงคือ 0.1.0-rc.6 ซึ่งเป็นข้อมูล ณ หน้านั้น ไม่ใช่การยืนยันเวอร์ชันล่าสุดในอนาคต

หากต้องการรันจากซอร์ส ลำดับพื้นฐานใน repository คือ:

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

โครงการใช้สัญญาอนุญาต MIT และรวมการเปิดเผยไลเซนส์ของ dependency ภายนอกไว้ใน THIRD_PARTY_NOTICES.md หากสร้างปลั๊กอินแล้วต้องการให้คนอื่นค้นพบ สามารถเพิ่ม topic dsh-plugin ใน repository ของปลั๊กอินได้ ส่วนข้อเสนอแนะและ bug report ส่งผ่าน GitHub Discussions และมีชุมชน DeepSeek Harness บน Discord

ก่อนเลือกเป็นฐาน ให้ทดลองรอยต่อที่ทีมจะพึ่งจริง

DeepSeek Harness น่าสนใจเพราะเปลี่ยนคำถามจาก “agent ตัวนี้มีฟีเจอร์อะไร” เป็น “ทีมต้องการประกอบ agent จากความสามารถใด และอยากควบคุมรอยต่อส่วนไหน” หากต้องการเพียงทดลองแนวคิด เริ่ม Web UI แล้วสำรวจโหมดและ Trajectory view ก็พอให้เห็นภาพ แต่ถ้ากำลังพิจารณาเป็นฐานของงานจริง ควรทดลองให้ชนกับสมมติฐานของทีมโดยตรง:

1. เลือกหนึ่งความสามารถที่มีโอกาสเปลี่ยนในอนาคต เช่น โมเดล สตอเรจ หรือแซนด์บ็อกซ์ แล้วตรวจว่าการสลับผ่าน configuration แตะส่วนใดบ้าง
2. สร้างปลั๊กอินขนาดเล็กหนึ่งตัวเพื่อดู API, dependency และวงจรโหลด–ถอดจากของจริง
3. รันงานตัวอย่างในโหมดที่ตรงกับรูปแบบงาน แล้วใช้ Trajectory view ตรวจว่าข้อมูลพอสำหรับวิเคราะห์ปัญหาหรือไม่
4. ทบทวนข้อมูลที่ session log เก็บ เทียบกับข้อกำหนดด้านข้อมูลของทีม โดยอย่าสมมตินโยบายที่เอกสารยังไม่ได้ระบุ
5. ประเมินต้นทุนในการรองรับการเปลี่ยนแปลง เพราะสถานะ developer preview หมายถึง API และความเข้ากันได้อาจเปลี่ยนจนโค้ดเดิมใช้ต่อไม่ได้

คำว่า “ทุกอย่างเป็นปลั๊กอิน” จึงมีน้ำหนักมากกว่าคำโปรย มันคือการเลือกวาง core ให้จัดการความสัมพันธ์ของชิ้นส่วน แทนการยึดความสามารถของ agent ไว้กับแกนเดียว โครงสร้างนี้เปิดพื้นที่ให้คนอื่นประกอบและต่อยอดได้ตั้งแต่ต้น แต่คุณค่าที่ทีมจะได้รับจริงยังขึ้นอยู่กับความมั่นคงของรอยต่อ คุณภาพของปลั๊กอิน และต้นทุนที่ยอมรับได้ในช่วง developer preview

ที่มา: DeepSeek Harness บน GitHub, DeepSeek Harness Developer Preview และ แพ็กเกจ @deepseek-ai/dsh บน npm