DEV Community

Cover image for DeepSeek Harness (dsh) คืออะไร? เจาะลึกคู่แข่งโค้ดโอเพ่นซอร์สของ Claude
Thanawat Wongchai
Thanawat Wongchai

Posted on Originally published at apidog.com

DeepSeek Harness (dsh) คืออะไร? เจาะลึกคู่แข่งโค้ดโอเพ่นซอร์สของ Claude

DeepSeek เปิดตัว DeepSeek Harness (dsh) เมื่อวันที่ 13 สิงหาคม 2026 ซึ่งไม่ใช่โมเดล แต่เป็นเครื่องมือสำหรับรันโมเดลให้ทำงานเป็น coding agent ได้จริง โดยมีวงจรเซสชัน การเรียกใช้เครื่องมือ การตรวจสอบสิทธิ์ และ Web UI ในเครื่อง เปิดตัวพร้อม DeepSeek V4-Pro บน API ในวันเดียวกัน และ VentureBeat มองว่าเป็นคู่แข่งโอเพนซอร์สของ Claude Code

ลองใช้ Apidog วันนี้

ชุมชนตอบรับอย่างรวดเร็ว: ณ วันที่ 20 สิงหาคม repository deepseek-harness มีดาวประมาณ 169,000 ดวงและ 18,100 forks ภายในหนึ่งสัปดาห์ สิ่งที่นักพัฒนาสนใจไม่ใช่แค่ตัวโมเดล แต่คือ agent harness ที่ตรวจสอบโค้ด แก้ไขพฤติกรรม และใช้ร่วมกับหลายโมเดลได้

DeepSeek Harness คืออะไร

โมเดลมีหน้าที่ทำนายโทเค็น ส่วน harness จัดการทุกอย่างที่ทำให้โมเดลลงมือทำงานได้ เช่น

  • โมเดลเห็นบริบทและไฟล์ใดบ้าง
  • agent เรียกเครื่องมือใดได้
  • การเขียนไฟล์และรัน shell command ต้องอนุมัติอย่างไร
  • เซสชันหลายขั้นตอนถูกเก็บและเล่นซ้ำอย่างไร

Claude Code, Codex CLI และ Gemini CLI ก็เป็น harness เช่นกัน แต่ห่อหุ้มโมเดลของผู้ให้บริการแต่ละรายไว้ หากต้องการเปรียบเทียบ Claude Code กับ Codex CLI ดูได้ที่ Claude Code vs Codex CLI

สิ่งที่กำหนดตำแหน่งของ DeepSeek Harness มี 3 ข้อ:

  • เป็นทางการ — เป็นโปรเจกต์จาก DeepSeek AI โดยตรง
  • โอเพนซอร์ส — ใช้ใบอนุญาต MIT และมีรายการ dependency ของบุคคลที่สามใน THIRD_PARTY_NOTICES
  • เป็น developer preview — README ระบุชัดว่าจะมี breaking changes ดังนั้นอย่าผูก workflow สำหรับ production เข้ากับ API หรือปลั๊กอินโดยไม่มีแผนรับมือการเปลี่ยนเวอร์ชัน

dsh เปิดตัวพร้อม DeepSeek V4-Pro จึงเหมาะสำหรับทีมที่ต้องการทดลองทั้ง model และ agent runtime พร้อมกัน หากต้องการเริ่มจาก API ของโมเดล ดู คู่มือ DeepSeek V4-Pro API สำหรับ endpoints, model IDs และตัวอย่าง request

สถาปัตยกรรม: ทุกอย่างเป็นปลั๊กอิน

Harness ทั่วไปมักเป็นแบบ monolithic: agent loop, model client, tools และ session storage อยู่ในแอปเดียวกัน ปรับ config ได้บ้าง แต่เปลี่ยนส่วนประกอบหลักได้จำกัด

DeepSeek Harness ใช้แนวคิด “ทุกอย่างเป็นปลั๊กอิน” บนเฟรมเวิร์ก Cordis ซึ่งอธิบายการออกแบบไว้ในเอกสาร A Programming Paradigm for Spatiotemporal Composability ในทางปฏิบัติ หมายความว่าส่วนประกอบหลักต่อไปนี้สามารถสลับหรือขยายได้:

  • Model adapters — เปลี่ยน backend ของ LLM ได้ผ่านปลั๊กอิน
  • Tool registry — เพิ่มหรือเปลี่ยนชุดเครื่องมือ เช่น file editing, shell และ search
  • Session persistence — เลือกวิธีบันทึกหรือ replay เซสชัน
  • Agent loop — แทนที่วงจรตัดสินใจ → ลงมือทำ → สังเกตผลได้

แนวทางนี้เหมาะเมื่อทีมต้องการทดลอง เช่น

  1. ใช้โมเดลต่างกันตามประเภทงาน
  2. จำกัดเครื่องมือสำหรับ repository ที่มีความเสี่ยง
  3. เปลี่ยนกลยุทธ์จัดการ context
  4. เพิ่ม approval policy ที่เข้มงวดขึ้น

ข้อแลกเปลี่ยนคือพื้นที่ที่อาจพังมีมากขึ้น โดยเฉพาะในช่วง developer preview ปลั๊กอินหรือ config อาจใช้ไม่ได้หลังอัปเดตเวอร์ชัน จึงควร pin เวอร์ชันและทดสอบใน sandbox ก่อน

เริ่มต้นอย่างรวดเร็ว

รัน Web UI ในเครื่องด้วยคำสั่งเดียว:

npx @deepseek-ai/dsh web
Enter fullscreen mode Exit fullscreen mode

คำสั่งนี้เปิด UI ที่:

http://127.0.0.1:3080
Enter fullscreen mode Exit fullscreen mode

หากไม่ต้องการให้เปิดเบราว์เซอร์อัตโนมัติ:

npx @deepseek-ai/dsh web --no-open
Enter fullscreen mode Exit fullscreen mode

หากต้องการ build จาก source:

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

ตั้งค่า workflow แรก

หลังเปิด UI ให้ทำตามลำดับนี้

  1. ตั้งค่า DeepSeek API key

กำหนด key ในหน้า Settings โดย credentials จะถูกเก็บใน:

   $DSH_HOME/.credentials.yaml
Enter fullscreen mode Exit fullscreen mode

ไฟล์ config หลักจะเก็บเพียง reference ไปยัง credentials

  1. เลือก workspace

คลิก Choose workspace แล้วเลือกไดเรกทอรีโปรเจกต์ที่ต้องการให้ agent ทำงานด้วย

ขั้นตอนนี้จำเป็น เพราะ dsh ต้องรู้ขอบเขตไฟล์ที่อนุญาตให้เข้าถึงก่อนเริ่ม session

  1. ส่งงานและอนุมัติการกระทำ

เมื่อ agent ต้องเขียนไฟล์หรือรัน shell command UI จะแสดง prompt ตาม permission policy ที่ใช้งานอยู่ อย่าอนุมัติโดยไม่ตรวจสอบ diff และคำสั่ง โดยเฉพาะเมื่อทำงานกับ repository สำคัญ

ใช้ profile และ headless mode

dsh web เป็น shorthand ของ:

dsh --profile web
Enter fullscreen mode Exit fullscreen mode

แต่ละ profile อยู่ใน:

$DSH_HOME/profiles/<name>
Enter fullscreen mode Exit fullscreen mode

สำหรับ automation หรือ CI ให้ใช้ headless mode:

dsh --profile headless "ตรวจสอบ test ที่ล้มเหลวและเสนอการแก้ไข"
Enter fullscreen mode Exit fullscreen mode

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

คำสั่งที่มีประโยชน์เพิ่มเติม:

# แสดง config ที่ประกอบแล้ว
dsh --dump-config

# แสดง config ค่าเริ่มต้น
dsh --dump-default-config

# จัดการปลั๊กอินของ profile
dsh plugin
Enter fullscreen mode Exit fullscreen mode

ดูรายการ CLI ฉบับเต็มได้ที่ CLI README

รองรับโมเดลอะไรบ้าง

DeepSeek เป็นค่าเริ่มต้น และ V4-Pro คือโมเดลหลักที่เปิดตัวพร้อม harness

หากกำลังประเมินค่าใช้จ่าย DeepSeek ได้ทำให้ส่วนลดช่วงนอกเวลาทำการเป็นแบบถาวร ดูรายละเอียดได้ใน บทความลดราคา DeepSeek V4-Pro และเอกสาร API อย่างเป็นทางการที่ api-docs.deepseek.com

อย่างไรก็ตาม dsh ไม่ได้จำกัดเฉพาะโมเดล DeepSeek เพราะ model adapter เป็นปลั๊กอิน โดยมี 2 แนวทางหลัก

1. ใช้ provider ที่มีใน catalog

มี provider ในตัวสำหรับ:

  • Anthropic
  • OpenAI
  • Amazon Bedrock
  • Google Vertex
  • Azure

แต่ละ provider มีรูปแบบจัดการ credentials ของตัวเอง

2. เพิ่ม OpenAI-compatible endpoint

คุณสามารถเพิ่ม endpoint ที่เข้ากันได้กับ OpenAI ลงใน:

$DSH_HOME/settings.yaml
Enter fullscreen mode Exit fullscreen mode

โดยระบุ base URL, environment variable สำหรับ API key และรายการโมเดล วิธีนี้ใช้ได้กับทั้ง cloud API, gateway ภายใน และ runtime ที่รันในเครื่อง

แต่ละ session จะบันทึกโมเดลที่ใช้ตั้งต้นไว้ ทำให้สลับโมเดลระหว่างโปรเจกต์ได้โดยไม่ทำให้ประวัติเซสชันสับสน

ดูรูปแบบ config ได้ใน คู่มือ providers หรือดูตัวอย่าง YAML สำหรับ custom endpoint ใน วิธีรันโมเดลใดๆ ใน DeepSeek Harness

ระบบนิเวศปลั๊กอิน

ค้นหาปลั๊กอินผ่าน GitHub topic dsh-plugin และติดตามการพูดคุยผ่าน GitHub Discussions หรือ Discord

ภายในหนึ่งสัปดาห์หลังเปิดตัว มีความต้องการหลัก 3 กลุ่ม

  • Desktop wrappers — เช่น deepseek-harness-desktop ที่ใช้ Tauri และ dsh_desktop สำหรับ Windows ซึ่งห่อ Web UI เป็น native app

    โปรเจกต์เหล่านี้เป็นของชุมชน ไม่ใช่ DeepSeek โดยตรง จึงต้องตรวจสอบ source code ก่อนให้สิทธิ์เข้าถึง API keys

  • Capability plugins — เช่น dsh-context และ dsh-vision-router สำหรับขยาย context หรือ routing ของเซสชัน

    ควรตรวจสอบ dependency และ permission ของปลั๊กอินเช่นเดียวกับแพ็กเกจ third-party อื่น

  • MCP support — ณ เวลาที่เขียน dsh core ยังไม่มี MCP แบบ native

    มีปลั๊กอินชุมชนชื่อ dsh-mcp-manager ที่เพิ่มการตั้งค่า MCP server ทั้ง remote HTTP และ local stdio รวมถึง OAuth, static token และเครื่องมือในรูปแบบ:

  mcp__<name>__*
Enter fullscreen mode Exit fullscreen mode

การตั้งค่า server รายโปรเจกต์อยู่ในไดเรกทอรี .dsh ของ workspace

จุดสำคัญคือ dsh ไม่ได้ “รองรับ MCP แบบ native” ใน core ณ ตอนนี้ แต่สามารถใช้ MCP ผ่านปลั๊กอินของชุมชนได้

ใช้กับ workflow API อย่างไร

Coding agent จะสร้างโค้ดตามสิ่งที่มันเข้าใจจาก codebase, เอกสาร และ specification ที่เข้าถึงได้ หาก API implementation ไม่ตรงกับ spec agent อาจสร้าง integration บนสัญญาที่ผิด และปัญหาจะไปปรากฏตอน runtime

แนวทางที่ใช้งานได้จริงคือ ตรวจสอบ API surface ก่อนให้ agent แก้โค้ด:

  1. นำเข้าหรือออกแบบ OpenAPI specification
  2. ทดสอบ endpoint จริงเทียบกับ specification
  3. สร้าง mock server จาก spec
  4. ให้ agent พัฒนากับ response ที่เสถียรและตรวจสอบแล้ว

Apidog ช่วยครอบคลุม workflow นี้ ตั้งแต่จัดการ OpenAPI, ทดสอบ endpoint และเปิด mock server เพื่อให้ agent อ้างอิง contract ที่ถูกต้อง แม้ backend จะยังเปลี่ยนแปลงอยู่

หากต้องการให้ dsh เข้าถึง API specification ผ่าน MCP ให้ใช้ Apidog MCP Server ร่วมกับปลั๊กอิน dsh-mcp-manager:

  1. ติดตั้ง dsh-mcp-manager
  2. ลงทะเบียน Apidog MCP Server
  3. กำหนดสิทธิ์และ credentials ที่จำเป็น
  4. ให้ agent query specification จริง แทนการเดาจากโค้ดเก่า

สำหรับตัวอย่างการให้ agent เรียก API tests ผ่าน CLI ดู การใช้ Apidog CLI ใน DeepSeek Harness

หากต้องการเตรียม API ก่อนทดลอง agent ให้ ดาวน์โหลด Apidog แล้วนำเข้า specification ของโปรเจกต์ก่อน

ควรลองใช้ตอนนี้หรือรอก่อน

ควรลองใช้ตอนนี้ หากคุณ

  • ต้องการศึกษา implementation ของ agent harness จากโค้ดจริง
  • ต้องการสลับโมเดลตามงานหรือใช้โมเดลที่โฮสต์เอง
  • ต้องการสร้างปลั๊กอินในระบบนิเวศที่ยังใหม่
  • ใช้ DeepSeek API อยู่แล้วและต้องการ agent experience แบบ first-party สำหรับ V4-Pro

ควรรอก่อน หากคุณ

  • ต้องการเครื่องมือที่เสถียรสำหรับงานประจำวันหรือ production
  • ต้องผ่านกระบวนการ security review และต้องการ vendor support
  • ต้องการ UX และความสมบูรณ์ของ harness ที่ผ่านการใช้งานมานาน
  • ไม่สามารถรับความเสี่ยงจาก breaking changes ของ config หรือปลั๊กอินได้

แนวทางที่ปลอดภัยสำหรับนักพัฒนาส่วนใหญ่คือ ใช้ agent เดิมกับงาน production ต่อไป แล้วทดลอง dsh ใน side project หรือ repository ที่แยกออกมา เมื่อเข้าใจ behavior, permission model และปลั๊กอินที่ต้องใช้แล้ว ค่อยตัดสินใจนำไปใช้ใน workflow หลัก

หากต้องการเปรียบเทียบกับ Claude Code โดยตรง ดู DeepSeek Harness vs Claude Code

คำถามที่พบบ่อย

DeepSeek Harness ฟรีหรือไม่?

ตัว harness ฟรีและเป็นโอเพนซอร์สภายใต้ MIT license แต่โมเดลที่เรียกใช้ยังมีค่าใช้จ่ายตามผู้ให้บริการ API ที่ตั้งค่าไว้

หากใช้ model adapter กับโมเดลที่โฮสต์ในเครื่อง คุณอาจไม่ต้องจ่ายค่าการใช้งานต่อโทเค็น ดูการตั้งค่าได้ที่ วิธีรันโมเดลใดๆ ใน DeepSeek Harness

dsh ใช้ได้กับโมเดล DeepSeek เท่านั้นหรือไม่?

ไม่ใช่ DeepSeek เป็นค่าเริ่มต้น แต่ model adapter เป็นปลั๊กอิน dsh รองรับ provider ใน catalog เช่น Anthropic, OpenAI, Bedrock, Vertex และ Azure รวมถึง endpoint ที่เข้ากันได้กับ OpenAI ผ่าน settings.yaml

DeepSeek Harness ปลอดภัยสำหรับรันบน codebase หรือไม่?

ความปลอดภัยขึ้นอยู่กับ permission policy และการอนุมัติของคุณ dsh กำหนดให้เลือก workspace ก่อนเริ่ม session และจะแจ้งเตือนเมื่อมี action ที่ต้องอนุมัติ

อย่างไรก็ตาม dsh ยังเป็น developer preview และปลั๊กอินชุมชนเป็น third-party code ที่อาจเข้าถึง API keys ได้ ควรตรวจสอบปลั๊กอินก่อนติดตั้ง และเริ่มใช้งานกับ repository ที่ไม่สำคัญก่อน

Harness ต่างจากโมเดลอย่างไร?

โมเดลคือส่วนที่ให้เหตุผลและสร้างข้อความ ส่วน harness คือชั้นที่ทำให้โมเดลทำงานกับระบบจริงได้ เช่น:

  • จัดการ session
  • รวม context
  • เรียกใช้ tools
  • เข้าถึงไฟล์
  • รัน commands
  • ขออนุมัติการกระทำ

Agent สองตัวสามารถใช้โมเดลเดียวกันแต่ให้ผลต่างกันมาก หาก harness, tools, context policy และ permission model ต่างกัน

Top comments (0)