5 ปลั๊กอิน DeepSeek Harness ที่ควรติดตั้งบน VPS

ปลั๊กอิน DeepSeek Harness ใดบ้างที่ควรติดตั้ง

ปลั๊กอิน DeepSeek Harness คือโค้ดจากภายนอกที่ทำงานภายในเอเจนต์ของคุณ โดยใช้สิทธิ์ของเอเจนต์และรันบนเครื่องที่คุณเป็นผู้จ่ายค่าเช่า รายการจากชุมชนมีมากกว่า 20 หมวดหมู่และมีรายการให้เลือกกว่าหนึ่งพันรายการ สำหรับการใช้งานบน virtual private server (VPS) ที่เช่ามา คุณจำเป็นต้องมี 5 รายการดังนี้: dsh-budget สำหรับจำกัดค่าใช้จ่าย, dsh-permission-rules สำหรับควบคุมการเข้าถึงเครื่องมือ, dsh-defend สำหรับสแกนการฉีดโค้ด (injection) และข้อมูลลับ (secret), dsh-memory สำหรับเก็บข้อมูลที่คงอยู่ยาวนานกว่าเซสชัน และ dsh-web-lan-access ซึ่งควรติดตั้งหลังจากที่คุณตัดสินใจได้แล้วว่าจะใช้วิธีการยืนยันตัวตนแบบใด

Harness คือ dsh ซึ่งเป็น agent harness แบบโอเพนซอร์สของ DeepSeek ที่ออกแบบมาให้ทุกอย่างเป็นปลั๊กอิน ไฟล์ README ของตัวมันเองระบุว่าเป็นรุ่น developer preview และแจ้งเตือนไว้ว่า THERE WILL BE COMPATIBILITY-BREAKING CHANGES ข้อเท็จจริงนี้เป็นตัวกำหนดทุกทางเลือกด้านล่างนี้ ให้ตรึงเวอร์ชันของปลั๊กอินที่คุณติดตั้งไว้ เตรียมใจว่าการอัปเกรดอาจทำให้ปลั๊กอินใช้งานไม่ได้ และจำกัดจำนวนปลั๊กอินให้เหลือน้อยที่สุดเท่าที่คุณจะสามารถตรวจสอบโค้ดทั้งหมดได้ด้วยตนเอง หากคุณยังไม่ได้เริ่มใช้งาน harness ให้เริ่มต้นที่ การติดตั้ง DeepSeek Harness บน VPS แล้วค่อยกลับมาที่นี่ หากส่วนประกอบที่ปลั๊กอินเหล่านี้เข้าไปเชื่อมต่อ ไม่ว่าจะเป็น agent loop, เครื่องมือ, หรือหน่วยความจำ ยังคงเป็นเรื่องที่ไม่ชัดเจนสำหรับคุณ ให้ ศึกษาพื้นฐานให้เข้าใจก่อน เพราะทุกทางเลือกด้านล่างนี้จะตัดสินใจได้ง่ายขึ้นเมื่อคุณเข้าใจการทำงานของแต่ละเลเยอร์แล้ว

วิธีการติดตั้งปลั๊กอินของ dsh และตำแหน่งที่เก็บไฟล์คอนฟิก

dsh ประกอบร่างขึ้นจากปลั๊กอิน Cordis ดังนั้นอินสแตนซ์ที่กำลังทำงานอยู่จึงเป็นโครงสร้างแบบต้นไม้ของปลั๊กอินมากกว่าจะเป็นโปรแกรมเดี่ยว โปรไฟล์คือการรวมกลุ่มของปลั๊กอินเหล่านั้นโดยมีการตั้งชื่อไว้ เทมเพลตทั้งสองคือ web และ headless โดย $DSH_HOME จะใช้ค่าเริ่มต้นที่ ~/.dsh และโปรไฟล์จะถูกเก็บไว้ที่ $DSH_HOME/profiles/<name>/ ซึ่งภายในจะมี package.json ของตัวเอง, ไฟล์ manifest dsh.profile และ cordis.patch.yml

dsh plugin --profile web list
dsh plugin --profile web add dsh-budget
dsh plugin --profile web remove dsh-budget

รูปแบบแหล่งที่มาที่รองรับมี 4 รูปแบบ ได้แก่ ชื่อแพ็กเกจ npm แบบปกติ, ชื่อแบบ scoped เช่น @towzai/dsh-memory, การอ้างอิงจาก GitHub เช่น github:PerryLink/dsh-budget#main และพาธในเครื่องที่ขึ้นต้นด้วย link: หรือ ./ แนะนำให้ใช้รูปแบบ GitHub เพราะคุณสามารถแทนที่ #main ด้วย commit hash เพื่อให้มั่นใจว่าจะได้รับโค้ดชุดเดิมเสมอในเดือนถัดไป

dsh plugin --profile web add "github:PerryLink/dsh-budget#461d478"

เลเยอร์ต่างๆ จะถูกนำมาใช้ตามลำดับที่กำหนดไว้: เริ่มจากแต่ละ bundle ตามลำดับที่ระบุในโปรไฟล์, ตามด้วย cordis.patch.yml ของโปรไฟล์, ต่อด้วย cordis.patch.yml ในระดับโฮม และปิดท้ายด้วย --patch overlay ใดๆ ลำดับมีความสำคัญเนื่องจากเลเยอร์ที่อยู่ถัดไปสามารถกำหนดค่าใหม่หรือยกเลิกสิ่งที่เลเยอร์ก่อนหน้าตั้งค่าไว้ได้ ดังนั้นเมื่อปลั๊กอินดูเหมือนติดตั้งแล้วแต่ไม่ทำงาน ให้เปิดไฟล์ cordis.patch.yml ของโปรไฟล์แล้วตรวจสอบสองจุด: ตรวจสอบว่ามีบล็อก insert อยู่จริง และไม่มีเลเยอร์ที่อยู่ถัดไปสั่งปิดการทำงานของมันไว้

ณ วันที่ 17 สิงหาคม 2026 แพ็กเกจ npm @deepseek-ai/dsh อยู่ที่เวอร์ชัน 0.1.0-rc.7 ในขณะที่ปลั๊กอินทุกตัวด้านล่างประกาศความเข้ากันได้กับ 0.1.0-rc.5 ถึง 0.1.0-rc.6 ช่องว่างดังกล่าวเป็นเรื่องปกติในระบบนิเวศนี้ และเป็นสาเหตุทั่วไปที่ทำให้ปลั๊กอินหยุดโหลด: ตัว harness มีการพัฒนาเร็วกว่าปลั๊กอินที่อยู่รอบๆ ให้ทำการอัปเกรด harness อย่างตั้งใจ จากนั้นจึงทดสอบปลั๊กอินทีละตัว

ตรวจสอบปลั๊กอินก่อนให้ความไว้วางใจ

ปลั๊กอิน dsh ไม่ได้ถูกแยกส่วน (sandboxed) ออกจากตัว harness มันจะโหลดเข้าสู่ Cordis tree เดียวกัน ในกระบวนการ (process) เดียวกัน ภายใต้ผู้ใช้งานระบบปฏิบัติการเดียวกัน โดยสามารถเข้าถึงข้อมูลประจำตัวของโมเดล (model credentials) และ working tree เดียวกันได้ การติดตั้งปลั๊กอินจึงใกล้เคียงกับการรันสคริปต์ของผู้อื่นด้วย sudo มากกว่าการเพิ่มส่วนขยายของเบราว์เซอร์ นี่เป็นประเด็นความไว้วางใจเดียวกันกับที่ ปลั๊กอินของ Claude Code ก่อให้เกิด และคำตอบก็คือสิ่งเดียวกัน: ให้อ่านโค้ดก่อน หรือไม่ก็อย่าติดตั้งมัน

มี 4 สิ่งที่ต้องตรวจสอบตามลำดับดังนี้:

• จุดเชื่อมต่อ (extension points) ที่ปลั๊กอินเรียกใช้ tools/pre-execute หมายความว่าปลั๊กอินเห็นการเรียกใช้เครื่องมือทุกครั้งและสามารถบล็อกได้ agent/pre-step หมายความว่าปลั๊กอินเห็นข้อความของคุณ webServer.tapIndex หมายความว่าปลั๊กอินเขียนหน้าเว็บที่ส่งไปยังเบราว์เซอร์ของคุณใหม่ ปลั๊กอินที่ไม่ได้เรียกใช้จุดเชื่อมต่อเหล่านี้เลยแทบจะทำอะไรไม่ได้เลย แต่ปลั๊กอินที่เรียกใช้ทั้งหมดนั้น คือ ขอบเขตความปลอดภัยของคุณ
• ปลั๊กอินมีการเชื่อมต่อเครือข่ายหรือไม่ ให้ค้นหาในซอร์สโค้ดสำหรับ fetch, http และชื่อโฮสต์ใดๆ ที่ถูกกำหนดค่าไว้ตายตัว (hard-coded) เครื่องมือวัดค่าใช้จ่ายที่ส่งข้อมูลกลับไปยังเซิร์ฟเวอร์ภายนอก (phones home) กำลังส่งรูปแบบการใช้งานของคุณไปยังที่อื่น
• ปลั๊กอินอ่านข้อมูลประจำตัวหรือไม่ สิ่งใดก็ตามที่แตะต้อง credentials.* หรือคีย์ของผู้ให้บริการ (provider key) จำเป็นต้องมีเหตุผลระบุไว้ใน README
• ใบอนุญาตและวันที่คอมมิตล่าสุด ปลั๊กอินที่ไม่มีใบอนุญาตและไม่ได้ถูกแตะต้องมานานหลายเดือน ในระบบนิเวศที่มีการเปลี่ยนแปลงทุกสัปดาห์ ถือเป็นความเสี่ยง

จากนั้นให้ติดตั้งโดยระบุ commit แทนการระบุ branch และอ่านบล็อกการแทรก (insert block) ที่ตัวติดตั้งเขียนลงใน cordis.patch.yml บล็อกนั้นจะระบุ id ของปลั๊กอินและการกำหนดค่าที่ปลั๊กอินลงทะเบียนไว้ ซึ่งเป็นคำอธิบายที่ตรงไปตรงมาและสั้นที่สุดของสิ่งที่คุณเพิ่งเพิ่มเข้าไป ให้เก็บคีย์ของผู้ให้บริการไว้ให้ห่างจากการเข้าถึงของปลั๊กอินในส่วนที่ harness อนุญาตให้ทำได้ ตามแนวทางของ การเก็บความลับให้ห่างจาก AI agents

dsh-budget: ฉันจะหยุดไม่ให้อเจนตใช้จ่ายเงินตลอดทั้งคืนได้อย่างไร?

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

dsh plugin --profile web add "github:PerryLink/dsh-budget#461d478"

ค่าเริ่มต้นที่ให้มานั้นค่อนข้างสูง: 10 USD ต่อเซสชัน, 50 ต่อวัน และ 500 ต่อเดือน ค่าเหล่านี้เหมาะสำหรับทีมที่มีงบประมาณสนับสนุน แต่สำหรับเซิร์ฟเวอร์ส่วนตัว ค่าเหล่านี้สูงเกินไปจนอาจทำให้ลูปที่ทำงานผิดพลาดใช้จ่ายจนหมดก่อนที่เพดานจะทำงาน ดังนั้นควรปรับลดค่าเหล่านี้ตั้งแต่วันแรก

[
  {
    "label": "Per session",
    "plugin_default_usd": 10,
    "suggested_start_usd": 2
  },
  {
    "label": "Per day",
    "plugin_default_usd": 50,
    "suggested_start_usd": 5
  },
  {
    "label": "Per month",
    "plugin_default_usd": 500,
    "suggested_start_usd": 40
  }
]

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

- id: budget
  config:
    budgets:
      session: 2
      daily: 5
      monthly: 40
    warnRatio: 0.8
    overLimit: block

การตั้งค่าที่เปลี่ยนพฤติกรรมของเครื่องคือ overLimit ค่าเริ่มต้นคือ alert ซึ่งจะแสดงคำเตือนแต่ยังคงให้ใช้จ่ายต่อไป ดังนั้นเมื่อติดตั้งครั้งแรกปลั๊กอินนี้จึงทำหน้าที่เป็นเพียงแดชบอร์ดเท่านั้น ให้ตั้งค่าเป็น block แล้วระบบจะปฏิเสธการเรียกใช้โมเดลเพิ่มเติมทันทีเมื่อถึงเพดานที่กำหนด ซึ่งหมายความว่างานที่ค้างคืนจะหยุดทำงานแทนที่จะเรียกเก็บเงินไปจนถึงเช้า degrade คือโหมดที่สาม: ระบบจะสลับไปใช้โมเดลที่ราคาถูกกว่าจากแผนผัง degradation ซึ่งเหมาะสมเมื่อต้องการให้งานเสร็จสิ้นแต่ไม่จำเป็นต้องใช้โมเดลที่ดีที่สุดของคุณ warnRatio มีค่าเริ่มต้นเป็น 0.8 ดังนั้นคุณจะได้รับแจ้งเตือนเมื่อถึง 80 เปอร์เซ็นต์ของเพดานงบประมาณ

มีข้อจำกัดที่ต้องคำนึงถึงสองประการ ประการแรก ค่าใช้จ่ายถูกคำนวณจากราคาที่คุณระบุ: prices จะว่างเปล่าโดยค่าเริ่มต้น และ defaultPrice จะใช้ค่าสำรองที่ 1.0 USD ต่อล้านโทเค็นขาเข้า และ 3.0 ต่อล้านโทเค็นขาออก ให้กรอกตัวเลขจริงสำหรับโมเดลของคุณ มิฉะนั้นแดชบอร์ดจะเป็นเพียงการคาดเดาที่ดูเหมือนการวัดผล ประการที่สอง ปลั๊กอินจะรวบรวมข้อมูลในกระบวนการที่กำลังทำงานจากสตรีมเหตุการณ์ของเซสชัน ดังนั้นยอดรวมจะถูกรีเซ็ตเมื่อมีการรีสตาร์ท harness หากเกิด crash loop หรือมี supervisor ที่คอยรีสตาร์ท dsh เพดานรายวันก็จะถูกรีเซ็ตไปด้วย ให้ถือว่า dsh-budget เป็นเพียงเครื่องป้องกันงานของคุณเอง และควรกำหนดวงเงินใช้จ่ายที่บัญชีผู้ให้บริการไว้เป็นเพดานที่แท้จริง ซึ่งเป็นประเด็นที่กว้างกว่าใน การควบคุมค่าใช้จ่ายของ AI agent บน VPS

ในการใช้งานประจำวัน คุณสามารถใช้ /budget เพื่อดูภาพรวม, /budget models เพื่อดูรายละเอียดแยกตามโมเดล และ /budget unblock <scope> เพื่อปลดล็อกเมื่อคุณตัดสินใจที่จะดำเนินการต่อ

กฎการอนุญาต dsh: การเรียกใช้เครื่องมือใดที่ไม่ควรทำงาน?

dsh-permission-rules จะวางกฎแบบประกาศไว้บน tools/pre-execute waterfall ดังนั้นกฎจะถูกประเมินก่อนที่เครื่องมือจะทำงาน โดยมี 3 การกระทำ คือ allow ซึ่งอนุญาตให้การเรียกผ่านไปได้, deny ซึ่งบล็อกการเรียกและส่งคืนเหตุผลที่โมเดลสามารถอ่านได้ และ ask ซึ่งส่งต่อการเรียกไปยังช่องทางการอนุมัติอย่างเป็นทางการ

dsh plugin --profile web add "github:PerryLink/dsh-permission-rules#b30b4fb"

กฎต่างๆ จะอยู่ใน .dsh/rules.yaml โดยอ้างอิงจากไดเรกทอรีทำงานของเซสชัน พร้อมด้วย fallbackPath ส่วนกลาง และ searchUp ทางเลือกเพื่อไล่ระดับขึ้นไปยังรูทของระบบไฟล์ การจับคู่ครอบคลุมถึง glob ของชื่อเครื่องมือ, glob ของคีย์และค่าพารามิเตอร์, glob ของพาธที่สัมพันธ์กับพื้นที่ทำงาน, ตัวเลือกเอเจนต์ เช่น main หรือ subagent และเป้าหมายเครือข่าย

rules:
  - match: { tools: [bash], params: { command: "rm -rf*" } }
    action: deny
    reason: "No recursive deletes"
  - match: { tools: [edit, write], paths: ["**/.env*", "**/secrets/**"] }
    action: ask
    reason: "Secret files need confirmation"
  - match: { tools: ["mcp__*"] }
    action: ask
    reason: "MCP tools need confirmation"

การประเมินจะใช้หลักการ "การจับคู่แรกที่พบถือเป็นที่สิ้นสุด" ดังนั้น allow แบบกว้างที่อยู่ด้านบนจะยกเลิกกฎที่แคบกว่าทั้งหมดที่อยู่ด้านล่างโดยอัตโนมัติ ควรเขียนกฎการปฏิเสธไว้ก่อนและกฎการอนุญาตไว้ทีหลัง glob ของชื่อเครื่องมือจะครอบคลุมถึง mcp__* ซึ่งเป็นวิธีที่คุณใช้ควบคุมเครื่องมือที่มาจากเซิร์ฟเวอร์ Model Context Protocol (MCP) แทนที่จะมาจากตัว harness เอง และนั่นเป็นเรื่องสำคัญทันทีที่คุณเริ่มใช้งาน เซิร์ฟเวอร์ MCP บน VPS

พฤติกรรมหนึ่งที่ต้องวางแผนคือ ask จำเป็นต้องมีผู้ตอบรับ ในโปรไฟล์ headless อาจไม่มีใครเฝ้าดูอยู่ ดังนั้นกฎ ask อาจทำให้การทำงานค้างไว้จนกว่าจะมีคนมาดำเนินการ ให้ใช้ deny สำหรับสิ่งที่คุณจะไม่มีวันอนุมัติ ให้เก็บ ask ไว้สำหรับโปรไฟล์ที่คุณใช้งานอยู่ และหากคุณต้องการให้การอนุมัติทำงานได้โดยไม่ต้องมีคนเฝ้า คุณจำเป็นต้องมีเส้นทางการตอบรับที่แท้จริง ซึ่งเป็นหัวข้อของ การควบคุมการกระทำของ AI agent ด้วยการอนุมัติ

dsh-defend: แล้วเรื่อง prompt injection และข้อมูลลับรั่วไหลล่ะ?

dsh-defend จะสแกนที่จุดสามจุด ได้แก่ ข้อความขาเข้าที่ agent/pre-step, อาร์กิวเมนต์ของเครื่องมือที่ tools/pre-execute ซึ่งรวมถึงระบบป้องกันการลบข้อมูลแบบทำลายล้าง และผลลัพธ์จากเครื่องมือที่ tools/post-execute จุดสุดท้ายนี้เป็นจุดที่น่าสนใจที่สุด เพราะเป็นจุดที่เนื้อหาซึ่งดึงมาจากหน้าเว็บจะถูกตรวจสอบก่อนที่โมเดลจะดำเนินการใดๆ กับมัน

dsh plugin --profile web add "github:PerryLink/dsh-defend#7ba3427"

ค่าเริ่มต้นจะเน้นความระมัดระวังมากกว่าความเข้มงวด โดย detection.injectionAction, detection.jailbreakAction และ detection.secretAction จะถูกตั้งค่าเป็น ask ทั้งหมด ในขณะที่ detection.secretBlockCritical ถูกตั้งค่าเป็น true ดังนั้นข้อมูลลับที่สำคัญจะถูกบล็อกเสมอไม่ว่าการตั้งค่าอื่นจะเป็นอย่างไร สำหรับเครื่องที่ไม่มีผู้ดูแล ให้เปลี่ยนการดำเนินการที่คุณให้ความสำคัญเป็น block เพราะ ask ในสถานการณ์ที่ไม่มีใครให้สอบถามนั้นไม่ใช่การตัดสินใจที่เหมาะสม

การออกแบบระบบตรวจสอบ (audit) ถือว่าทำได้ดี defend/detection จะบันทึกเหตุการณ์โดยระบุรหัสกฎ, ตระกูล, หมวดหมู่, ระดับความรุนแรง, การตัดสินใจ และข้อเท็จจริงในการสแกน โดยจะไม่บันทึกข้อความที่ตรวจพบจริง ส่วนข้อมูลลับจะถูกบันทึกตามประเภทเท่านั้น ดังนั้นการเปิดใช้งาน audit log จึงไม่เป็นการสร้างสำเนาของข้อมูลรับรองที่คุณพยายามปกป้องขึ้นมาอีกชุดหนึ่ง

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

dsh-memory: เอเจนต์จำอะไรได้บ้างในวันพรุ่งนี้?

มีปลั๊กอินสองตัวที่ใช้ชื่อว่า dsh-memory ซึ่งควรทราบก่อนที่คุณจะพิมพ์คำสั่งติดตั้ง ให้ติดตั้งโดยระบุแหล่งที่มาให้ชัดเจนเพื่อให้ได้ตัวที่คุณต้องการใช้งาน

ตัวที่ผมแนะนำสำหรับเซิร์ฟเวอร์ขนาดเล็กคือรุ่น SQLite ซึ่งลงทะเบียนเป็น memory โดยเก็บข้อมูลไว้ในไฟล์เดียวที่ $DSH_HOME/memory/memory.db ซึ่งใช้ร่วมกันระหว่างโปรไฟล์ และเปิดใช้งาน memory_write, memory_search และ memory_forget การค้นหาจะเป็นแบบใช้คำสำคัญ (keyword-based) บนข้อความและแท็กที่จัดเก็บไว้ โดยไม่มีบริการ embedding, ไม่ต้องใช้ API key และไม่มีกระบวนการทำงานเบื้องหลังเพิ่มเติม

dsh plugin --profile web add "github:ben7am1n/dsh-memory#def7c6a"

การตั้งค่าที่คุณต้องปรับแต่งมีเพียงเล็กน้อย ได้แก่ path สำหรับไฟล์ฐานข้อมูล, promptRecentCount (ค่าเริ่มต้นคือ 10) สำหรับจำนวนหน่วยความจำที่ไม่ได้ปักหมุดที่จะถูกแทรกเข้าไป และ promptMaxChars (ค่าเริ่มต้นคือ 2000) สำหรับงบประมาณในการเรนเดอร์ ทั้งนี้ปลั๊กอินนี้ต้องอาศัย node:sqlite ซึ่ง Node 22 และ 24 ยังคงระบุว่าเป็นฟีเจอร์ทดลอง ดังนั้นการอัปเกรด Node จึงเป็นสิ่งที่ควรทดสอบก่อนใช้งานจริง ไม่ควรคาดเดาเอาเอง

นี่คือสิ่งที่หน่วยความจำส่งผลต่อเครื่องของคุณ: หน่วยความจำที่ถูกแทรกจะเข้าไปอยู่ใน system prompt ในทุกรอบการสนทนา งบประมาณ 2000 ตัวอักษรหมายถึงการเพิ่ม input tokens อีกหลายร้อยตัวในทุกคำขออย่างต่อเนื่อง ซึ่งส่งผลต่อค่าใช้จ่ายของคุณโดยตรง และเป็นเหตุผลว่าทำไม dsh-budget จึงควรติดตั้งบนเครื่องก่อน dsh-memory ควรจำกัดขนาด promptMaxChars ให้เหมาะสมและหมั่นลบข้อมูลด้วย memory_forget แทนที่จะปล่อยให้ไฟล์ขยายขนาดขึ้นเรื่อยๆ

อีกทางเลือกหนึ่งคือรุ่นที่เก็บหน่วยความจำไว้ในไฟล์ YAML และใช้การค้นหาแบบ embedding พร้อมการแทรก prompt อัตโนมัติ ซึ่งติดตั้งด้วย dsh plugin --profile web add github:towzai/dsh-memory รุ่นนี้จำเป็นต้องมีอินสแตนซ์ ollama ในเครื่องและโมเดล embedding โดยใช้ qwen3-embedding:0.6b เป็นค่าเริ่มต้น ซึ่งสามารถแทนที่ได้ด้วย DSH_MEMORY_EMBED_MODEL การเรียกคืนข้อมูลเชิงความหมาย (semantic recall) ทำได้ดีกว่าการใช้คำสำคัญ แต่ก็หมายถึงการต้องรันบริการที่สองและโหลดน้ำหนักโมเดลไว้บนเซิร์ฟเวอร์เดียวกัน ซึ่งสำหรับแผนบริการขนาดเล็กถือเป็นการดึง RAM ไปจากงานหลักที่คุณเช่าเซิร์ฟเวอร์มาทำ ให้เลือกใช้รุ่นนี้เมื่อคุณมี RAM เหลือเฟือเท่านั้น ข้อแลกเปลี่ยนทั่วไประหว่างคุณภาพการเรียกคืนข้อมูลและทรัพยากรที่ใช้ถูกอธิบายไว้ใน หน่วยความจำในเครื่องสำหรับเอเจนต์

dsh-web-lan-access: เว็บ UI ควรฟังการเชื่อมต่อภายนอก loopback หรือไม่?

npx @deepseek-ai/dsh web ให้บริการอินเทอร์เฟซบน 127.0.0.1:3080 เบราว์เซอร์จะเปิดเผย crypto.randomUUID() เฉพาะในบริบทที่ปลอดภัยเท่านั้น ดังนั้นการโหลดหน้าเว็บเดียวกันผ่าน HTTP ธรรมดาจากเครื่องอื่นจึงล้มเหลว dsh-web-lan-access แก้ไขปัญหานี้โดยใช้ webServer.tapIndex เพื่อแทรก polyfill ขนาดเล็ก และเปลี่ยนการผูก (binding) ของเซิร์ฟเวอร์ไปที่ 0.0.0.0

โปรดอ่านคำเตือนของเครื่องมือก่อนติดตั้ง การผูกที่ 0.0.0.0 จะทำให้ agent เข้าถึงได้โดยไม่ต้องมีการยืนยันตัวตนจากทุกคนที่อยู่ในเครือข่ายท้องถิ่น (LAN) เดียวกัน และหากเป็นเซิร์ฟเวอร์ที่มี IP สาธารณะ นั่นหมายถึงทุกคนบนอินเทอร์เน็ต เมธอดที่มีความละเอียดอ่อนจำนวนหนึ่ง (settings.*, credentials.*, llm.discoverModels) จะถูกตรึงไว้ที่ loopback และส่งคืนค่า 403 หากเรียกจากแหล่งที่มาภายนอก ซึ่งช่วยจำกัดความเสียหายได้ แต่วิธีนี้ไม่ได้ป้องกันปัญหาทั้งหมด เนื่องจากพื้นผิวการเรียกใช้เครื่องมือยังคงเปิดกว้างสำหรับทุกคนที่พบพอร์ตดังกล่าว

โดยส่วนใหญ่แล้ว คุณไม่จำเป็นต้องใช้ปลั๊กอินนี้เลย ให้ใช้วิธี forward พอร์ตผ่าน SSH แทน

ssh -N -L 3080:127.0.0.1:3080 you@your-server

จากนั้นเปิด http://127.0.0.1:3080 ในเบราว์เซอร์บนเครื่องของคุณ ตัว harness จะยังคงฟังการเชื่อมต่อเฉพาะบน loopback เท่านั้น จึงไม่มีข้อมูลใดถูกเปิดเผย และเนื่องจากเบราว์เซอร์ถือว่า 127.0.0.1 เป็นแหล่งที่มาที่ปลอดภัย crypto.randomUUID() จึงใช้งานได้โดยไม่ต้องใช้ polyfill คำสั่งเดียวจบ ไม่ต้องใช้ปลั๊กอิน และไม่เพิ่มช่องโหว่ใหม่

ให้ติดตั้งปลั๊กอินเฉพาะเมื่อการทำ forward ไม่สามารถตอบโจทย์ได้ เช่น เมื่อโทรศัพท์ที่อยู่ในเครือข่ายเดียวกันจำเป็นต้องเข้าถึง UI หากคุณจำเป็นต้องติดตั้ง ให้ผูกไว้หลังอินเทอร์เฟซเครือข่ายส่วนตัว (private network interface) รักษา firewall rule ที่อนุญาตเฉพาะอินเทอร์เฟซนั้น และระบุชื่อที่คุณจะใช้ภายใต้ trustedHosts ในรายการ web-runtime สำหรับการเข้าถึงแบบหลายผู้ใช้อย่างแท้จริง ให้ใช้ dsh-passwords ซึ่งจะเพิ่มสิทธิ์ระดับผู้ใช้ย่อย (subuser), โควตา token รายชั่วโมงและโควตาเวลาใช้งานรายวันสำหรับผู้ใช้ย่อยแต่ละคน, การจัดการ certificate TLS (transport layer security) อัตโนมัติผ่าน Let's Encrypt และบันทึกการตรวจสอบ (audit log) ที่เข้ารหัส ให้พิจารณาว่ามันเป็นแพลตฟอร์มมากกว่าปลั๊กอิน เพราะมันต้องการพอร์ต 80 และ 443 มาพร้อมกับตัวติดตั้งของตัวเอง และวิธีติดตั้งด่วนที่ระบุในเอกสารคือการ pipe shell script จากเครือข่ายลงสู่ bash โดยตรง แนะนำให้ใช้ npm install -g dsh-passwords ตามด้วย dsh-passwords install เพื่อให้โค้ดถูกบันทึกลงบนดิสก์ ซึ่งคุณสามารถอ่านตรวจสอบได้ก่อนที่จะรันจริง

วิธีการลบปลั๊กอินอย่างหมดจด

การถอนการติดตั้งมีสองขั้นตอน แต่ผู้ใช้มักข้ามขั้นตอนที่สองไป

dsh plugin --profile web remove dsh-budget
dsh plugin --profile web list

list ไม่ควรแสดงปลั๊กอินนั้นอีกต่อไป จากนั้นให้เปิด $DSH_HOME/profiles/web/cordis.patch.yml แล้วลบ block การแทรกที่เหลืออยู่ซึ่งระบุชื่อปลั๊กอินนั้นทิ้ง เนื่องจากรายการดังกล่าวคือสิ่งที่โหลดปลั๊กอินเข้าสู่ tree ให้รีสตาร์ท harness เพื่อให้ระบบสร้าง tree ขึ้นใหม่ เพราะปลั๊กอินที่โหลดไปแล้วจะยังคงทำงานอยู่จนกว่าคุณจะรีสตาร์ท สุดท้าย โปรดจำไว้ว่าข้อมูลจะยังคงอยู่แม้ตัวโค้ดจะถูกลบไปแล้ว $DSH_HOME/memory/memory.db และ .dsh/rules.yaml จะยังคงอยู่หลังการถอนการติดตั้ง ให้คุณลบไฟล์เหล่านี้ด้วยตนเองหากเป้าหมายของคุณคือการลบข้อมูลทั้งหมดออกไป

สิ่งที่ฉันอ่านและช่วงเวลาที่อ่าน

การอ้างอิงทุกรายการที่นี่คือ commit ไม่ใช่ branch เนื่องจาก main จะเป็นโค้ดที่ต่างออกไปเมื่อคุณอ่านบทความนี้ ฉันอ่านเนื้อหาทั้งหมดเมื่อวันที่ 17 สิงหาคม 2026 และตัว harness เองอยู่ที่ 0.1.0-rc.7 บน npm ในวันนั้น

โปรดตรวจสอบเลข pin เหล่านั้นอีกครั้งก่อนที่คุณจะคัดลอกคำสั่งไปใช้ ในระบบนิเวศที่เป็น developer-preview เลขเวอร์ชันที่ระบุวันที่กำกับไว้เป็นสิ่งเดียวที่มีความหมายชัดเจน

FAQ

ควรติดตั้งปลั๊กอิน DeepSeek Harness ตัวใดบ้างเป็นอันดับแรกบน VPS?

ให้ติดตั้ง dsh-budget และ dsh-permission-rules ก่อนสิ่งอื่นใด การกำหนดงบประมาณด้วย overLimit: block จะช่วยป้องกันไม่ให้การรันงานแบบอัตโนมัติใช้ทรัพยากรจนหมดทั้งคืน และไฟล์ .dsh/rules.yaml จะช่วยป้องกันการเรียกใช้เครื่องมือที่คุณไม่เคยอนุมัติ ให้เพิ่ม dsh-defend เมื่อเอเจนต์เริ่มอ่านข้อมูลจากเว็บสาธารณะ และเพิ่ม dsh-memory เมื่อคุณพบว่าตนเองต้องคัดลอกบริบทเดิมซ้ำๆ ในทุกเซสชัน สำหรับธีมและสถานะต่างๆ ให้ข้ามไปก่อน เพราะเป็นการเพิ่มโค้ดที่รันด้วยสิทธิ์ของเอเจนต์โดยไม่ได้เปลี่ยนการทำงานของเครื่อง

ปลั๊กอิน dsh ถูกแยกส่วน (sandbox) ออกจากตัว harness หรือไม่?

ไม่ ปลั๊กอินจะโหลดเข้าสู่ Cordis tree เดียวกับตัว harness ในกระบวนการ (process) เดียวกัน ภายใต้ผู้ใช้ระบบปฏิบัติการเดียวกัน ด้วย credential ของโมเดลชุดเดียวกัน และทำงานใน working tree เดียวกัน ปลั๊กอินที่เชื่อมต่อกับ tools/pre-execute สามารถมองเห็นและบล็อกการเรียกใช้เครื่องมือทุกอย่างได้ ส่วนปลั๊กอินที่เชื่อมต่อกับ agent/pre-step จะสามารถอ่านข้อความของคุณได้ ดังนั้นโปรดอ่านซอร์สโค้ด ตรวจสอบใบอนุญาตและวันที่คอมมิตล่าสุด และติดตั้งโดยระบุ commit แทนการระบุ branch เพื่อป้องกันไม่ให้โค้ดถูกเปลี่ยนแปลงโดยที่คุณไม่ทราบ

dsh-budget จะหยุดการทำงานของเอเจนต์จริงหรือไม่ หรือแค่แจ้งเตือน?

ขึ้นอยู่กับ overLimit ค่าเริ่มต้นคือ alert ซึ่งจะแจ้งเตือนที่ warnRatio และยังคงมีการใช้งานต่อไป ส่วน block จะปฏิเสธการเรียกใช้โมเดลเพิ่มเติมเมื่อถึงขีดจำกัด และ /budget unblock <scope> จะปลดล็อกเมื่อคุณเลือกที่จะดำเนินการต่อ ส่วน degrade จะเปลี่ยนไปใช้โมเดลที่ราคาถูกกว่าจากแผนผัง degradation มีข้อจำกัดหนึ่งที่สำคัญคือ ยอดรวมจะถูกคำนวณในกระบวนการที่กำลังรันอยู่จาก session event stream ดังนั้นการรีสตาร์ท harness จะเป็นการรีเซ็ตค่าเหล่านี้ และการวนลูปรีสตาร์ทอาจทำให้ขีดจำกัดรายวันใช้งานไม่ได้ผล ควรตั้งค่าขีดจำกัดการใช้จ่ายที่บัญชีผู้ให้บริการไว้เป็นเพดานที่แท้จริง

ฉันจะลบปลั๊กอิน dsh ออกอย่างสมบูรณ์ได้อย่างไร?

ให้รัน dsh plugin --profile web remove <package-name> ยืนยันด้วย dsh plugin --profile web list จากนั้นเปิด $DSH_HOME/profiles/web/cordis.patch.yml แล้วลบ insert block ที่เหลืออยู่ของปลั๊กอินนั้นออก เพราะรายการดังกล่าวคือสิ่งที่โหลดปลั๊กอินขึ้นมา จากนั้นให้รีสตาร์ท harness เพื่อให้ปลั๊กอิน tree ถูกสร้างใหม่ ข้อมูลที่เขียนโดยปลั๊กอินจะยังคงอยู่ในดิสก์ โดยทั้ง $DSH_HOME/memory/memory.db และ .dsh/rules.yaml จะยังคงอยู่หลังการถอนการติดตั้งจนกว่าคุณจะลบด้วยตนเอง

การเปิดเผย dsh web UI ผ่านเครือข่ายมีความปลอดภัยหรือไม่?

ไม่ปลอดภัยหากทำโดยลำพัง dsh web จะฟังคำสั่งที่ 127.0.0.1:3080 และ dsh-web-lan-access จะเปลี่ยนการผูกพอร์ตนั้นไปยัง 0.0.0.0 ใน README ของตัวโปรแกรมระบุว่าการทำเช่นนี้จะทำให้เอเจนต์สามารถเข้าถึงได้โดยไม่มีการตรวจสอบสิทธิ์จากใครก็ตามที่อยู่ในเครือข่ายเดียวกัน และหากเป็น IP สาธารณะ นั่นหมายถึงทุกคนบนอินเทอร์เน็ต วิธีการบางอย่าง (settings.*, credentials.*, llm.discoverModels) จะถูกตรึงไว้ที่ loopback และส่งค่า 403 กลับเมื่อมีการเข้าถึงจากระยะไกล ซึ่งช่วยลดความเสียหายแต่ไม่ได้ป้องกันทั้งหมด ควรใช้ SSH port forward, ssh -N -L 3080:127.0.0.1:3080 you@your-server หรือนำพอร์ตไปไว้หลัง private network interface ร่วมกับกฎไฟร์วอลล์ และเพิ่มการตรวจสอบสิทธิ์ที่แท้จริงก่อนที่จะอนุญาตให้เข้าถึงจากภายนอกได้