วิธีใช้ Apidog CLI บน DeepSeek Harness

DeepSeek Harness เป็นวงจรการทำงานที่เอเจนต์อ่านเวิร์กสเปซ แก้ไขไฟล์ รันคำสั่งผ่านเครื่องมือ bash และตัดสินใจขั้นตอนถัดไปจากเอาต์พุตของคำสั่ง แล้วเหตุใดการทดสอบ API จึงไม่อยู่ในวงจรเดียวกัน? หากการทดสอบอยู่แค่ใน GUI ของ Apidog และต้องรอให้คนจำได้ว่าต้องคลิก เอเจนต์จะไม่สามารถใช้ผลทดสอบเพื่อตรวจสอบงานของตัวเองได้

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

วิธีเพิ่มการทดสอบ API เข้าไปในวงจรนี้คือกำหนดค่าให้เอเจนต์เรียก Apidog CLI โดยตรง apidog-cli เป็นแพ็กเกจ npm ที่รันสถานการณ์ทดสอบจาก Apidog ผ่านเทอร์มินัลได้ เมื่อติดตั้ง CLI แล้วและ DeepSeek Harness รับรู้คำสั่ง เอเจนต์จะรันสถานการณ์ Apidog ได้เหมือนรัน unit test: เรียกคำสั่ง อ่าน exit code และแก้โค้ดเมื่อผลลัพธ์ล้มเหลว

ข้อดีคือช่วยลดการใช้ context ของเอเจนต์ แทนที่เอเจนต์จะอ่าน handler และพยายามอนุมานว่า response ถูกต้องหรือไม่ในทุกครั้ง มันสามารถรันคำสั่งเดียวและรับผลจริงกลับมาได้ทันที CLI สรุปคำถามว่า “API ถูกต้องหรือไม่?” ให้เป็น exit code พร้อมรายละเอียด assertion ที่ล้มเหลว เพื่อให้เอเจนต์ใช้ context ไปกับการแก้ไขโค้ดแทน

บทความนี้เน้นส่วนที่เกี่ยวข้องกับ DeepSeek Harness โดยเฉพาะ: ไฟล์คำสั่งที่ harness โหลด เครื่องมือ bash รัน apidog run อย่างไร และวิธีตรวจสอบว่าเอเจนต์รันการทดสอบจริง หากยังไม่ได้ติดตั้ง CLI ให้ทำขั้นตอนนั้นก่อนที่ วิธีติดตั้ง Apidog CLI ด้วยเอเจนต์โค้ด AI บทความนี้สมมติว่าคำสั่งต่อไปนี้ทำงานแล้ว:

apidog --version

และเครื่องของคุณได้รับการยืนยันตัวตนกับ Apidog แล้ว

DeepSeek Harness ที่เรากำลังพูดถึง

DeepSeek Harness หรือ dsh บนบรรทัดคำสั่ง เป็น agent harness แบบโอเพนซอร์สที่ DeepSeek เปิดตัวเมื่อวันที่ 13 สิงหาคม 2026 พร้อม V4-Pro บน API โปรเจกต์ได้รับอนุญาตภายใต้ MIT และอยู่ที่ github.com/deepseek-ai/deepseek-harness

เริ่มใช้งาน web UI ในเครื่องได้ด้วยคำสั่ง:

npx @deepseek-ai/dsh web

จากนั้นเปิด http://127.0.0.1:3080 เลือกเวิร์กสเปซของโปรเจกต์ แล้วเอเจนต์จะสามารถอ่านและแก้ไขไฟล์ รันคำสั่ง และขออนุมัติก่อนดำเนินการตามนโยบายสิทธิ์ที่ใช้งานอยู่

มีข้อควรทราบ 2 ข้อก่อนตั้งค่า:

1. DeepSeek Harness เป็น developer preview ดังนั้นชื่อไฟล์และคีย์คอนฟิกอาจเปลี่ยนได้ ตรวจสอบกับ เอกสารของ repo หากการตั้งค่าไม่ทำงาน
2. ระบบใช้สถาปัตยกรรมปลั๊กอินบน Cordis ดังนั้นการโหลดคำสั่งโปรเจกต์และพฤติกรรมของเครื่องมือขึ้นอยู่กับปลั๊กอินที่ติดตั้ง

สำหรับภาพรวมเพิ่มเติม ดู DeepSeek Harness คืออะไร และ DeepSeek Harness vs Claude Code

ขั้นตอนที่ 1: เพิ่มคำสั่ง Apidog CLI ลงใน AGENTS.md

DeepSeek Harness โหลดคำสั่งเวิร์กสเปซผ่านปลั๊กอิน @deepseek-ai/dsh-agent-instructions ตามซอร์สโค้ดของปลั๊กอินและแคตตาล็อกการกำหนดค่า ตัวโหลดจะค้นหาไฟล์จากไดเรกทอรีทำงานของเซสชันขึ้นไปจนถึง project root ที่ระบุด้วย .git

ไฟล์ที่เกี่ยวข้องมีลำดับการใช้งานดังนี้:

• AGENTS.md เป็นไฟล์หลัก
• CLAUDE.md ใช้เป็น fallback
• AGENTS.local.md และ CLAUDE.local.md เป็น local overlay ที่โหลดหลังไฟล์หลัก
• $DSH_HOME/AGENTS.md เป็นคำสั่งส่วนกลางของผู้ใช้ โดยค่าเริ่มต้นคือ ~/.dsh/AGENTS.md
• ไฟล์ที่ใหญ่กว่า 1 MiB จะถูกละเว้น

หาก repo มี AGENTS.md สำหรับ Codex หรือ CLAUDE.md สำหรับ Claude Code อยู่แล้ว DeepSeek Harness สามารถนำไปใช้ได้ทันที เพิ่มบล็อกนี้ลงในไฟล์ดังกล่าว:

## การทดสอบ API ด้วย Apidog CLI
- หากต้องการทดสอบ API ให้รันสถานการณ์ Apidog ไม่ต้องคลิกผ่าน GUI
- คำสั่ง: apidog run -t <scenario_id> -e <env_id> -r cli
- รหัสการออก 0 หมายถึงการยืนยันทั้งหมดผ่าน รหัสที่ไม่ใช่ 0 หมายถึงความล้มเหลว; ให้อ่านรายงานและแก้ไขโค้ด
- เครื่องได้รับการยืนยันตัวตนแล้ว ห้ามเพิ่มแฟล็ก --access-token และห้ามใส่โทเค็นในไฟล์นี้

ให้เก็บ ID ของสถานการณ์ทดสอบไว้ในไฟล์กฎของ repo แทนการพิมพ์ในแชตของ session เพราะคำสั่งในแชตจะหายไปเมื่อ session จบลง แต่ AGENTS.md จะถูกโหลดใน session ใหม่และใช้ร่วมกันได้กับสมาชิกทีมที่ clone repo เดียวกัน

หากทำงานหลายโปรเจกต์ ให้เก็บกฎทั่วไปใน ~/.dsh/AGENTS.md เช่น:

ตรวจสอบการเปลี่ยนแปลง API ด้วยคำสั่ง apidog run ของโปรเจกต์เสมอ

จากนั้นเก็บ scenario_id และ env_id จริงไว้ใน AGENTS.md ของแต่ละ repo

ขั้นตอนที่ 2: คัดลอกคำสั่งจาก Apidog

ไม่ต้องเดา ID ของสถานการณ์หรือ environment

1. เปิดสถานการณ์ทดสอบใน Apidog
2. ไปที่แท็บ CI/CD
3. คัดลอกคำสั่งที่ Apidog สร้างให้

ตัวอย่าง:

apidog run -t 123456 -e 789012 -r cli

ความหมายของแฟล็ก:

• -t คือ ID ของสถานการณ์ทดสอบ
• -e คือ ID ของ environment
• -r cli เลือก reporter แบบ CLI เพื่อพิมพ์ผลลัพธ์ในเทอร์มินัล

วางคำสั่งจริงที่ได้จาก Apidog ลงใน AGENTS.md เพื่อให้เอเจนต์ใช้ ID ที่ถูกต้อง แทนการสร้างหรือเดา ID เอง

ขั้นตอนที่ 3: ให้เอเจนต์รันการทดสอบ

เปิด dsh web UI และเลือกเวิร์กสเปซของโปรเจกต์ เมื่อ AGENTS.md ถูกโหลดแล้ว เอเจนต์จะรับรู้ว่าต้องใช้ Apidog CLI สำหรับตรวจสอบ API

หลังแก้ไข endpoint, handler หรือ business logic ที่เกี่ยวข้องกับ API ให้สั่งเอเจนต์ เช่น:

รันสถานการณ์ทดสอบ Apidog และบอกรหัสการออกให้ฉันทราบ

เอเจนต์จะใช้เครื่องมือ bash เพื่อรันคำสั่งในไฟล์กฎ

เข้าใจพฤติกรรมของ bash tool

ตามแคตตาล็อกเครื่องมือ เครื่องมือ bash ของ dsh เริ่มคำสั่งแต่ละครั้งใน fresh shell ซึ่งหมายความว่า:

• ไม่มี directory state ที่คงอยู่ระหว่างคำสั่ง
• ไม่มี environment variable ที่ตั้งไว้จากคำสั่งก่อนหน้า
• ไม่มี shell function ที่คงอยู่
• โดยปกติคำสั่งจะรันจาก session workspace เว้นแต่ระบุ workdir

ดังนั้นรูปแบบนี้จะไม่ทำงานตามที่คาดหวังหากแยกเป็นหลายครั้ง:

cd services/api

apidog run -t 123456 -e 789012 -r cli

ให้ใช้คำสั่งบรรทัดเดียวแทน หากจำเป็นต้องรันในไดเรกทอรีย่อย:

cd services/api && apidog run -t 123456 -e 789012 -r cli

หรือส่งค่า workdir ผ่านเครื่องมือ bash หาก harness build ที่ใช้งานรองรับ

เมื่อคำสั่งล้มเหลว dsh จะแสดงผลลัพธ์ในรูปแบบ:

[exit code: 1]

แม้เอาต์พุตยาวจะถูกตัดทอน สถานะผ่าน/ล้มเหลวจาก exit code ยังตรวจสอบได้ชัดเจน

คำสั่งอาจทำงานภายใต้ file sandbox ด้วย หากถูกบล็อก จะปรากฏเป็นการปฏิเสธตามนโยบาย ไม่ใช่ command failure การรันแบบ -r cli มักไม่เขียนไฟล์จึงมีโอกาสเจอปัญหาน้อยกว่า HTML reporter ที่เขียนรายงานลงดิสก์

หาก web UI ขออนุมัติก่อนรัน apidog run ให้อนุมัติคำสั่งตามนโยบายที่ใช้งานอยู่ โดยเฉพาะเมื่อรันกับ staging ที่ควบคุมได้

ขั้นตอนที่ 4: อ่านรายงานและแก้ไขจาก assertion ที่ล้มเหลว

เมื่อรันด้วย -r cli เอเจนต์จะเห็นรายละเอียดผลทดสอบในเทอร์มินัล เช่น:

• request ที่ถูกเรียก
• assertion ที่ตรวจสอบ
• status code ที่คาดหวังและค่าจริง
• field ที่หายไปหรือมีค่าไม่ตรงตามสัญญา

ตัวอย่างปัญหาที่เอเจนต์สามารถใช้แก้โค้ดได้ทันที:

• คาดหวัง 200 แต่ได้รับ 500
• response ไม่มีฟิลด์ total
• รหัสสกุลเงินไม่ตรงกับค่าที่คาดหวัง

หากต้องการรายงานที่เปิดในเบราว์เซอร์หรือส่งต่อให้ทีม เพิ่ม HTML reporter:

apidog run -t 123456 -e 789012 -r cli,html

ตัว reporter html จะเขียนรายงานไปที่:

./apidog-reports

ควรเก็บ cli ไว้เสมอ เพื่อให้เอเจนต์ยังอ่านผลลัพธ์แบบ inline และตัดสินใจขั้นตอนถัดไปได้

วงจรแก้ไข-ทดสอบ-แก้ไขแบบครบวงจร

สมมติว่าเอเจนต์กำลังแก้ไข checkout handler

หากไม่มี CLI วงจรอาจจบที่ “โค้ดดูถูกต้อง” แต่เมื่อเพิ่มคำสั่ง Apidog ลงใน AGENTS.md วงจรจะเป็นดังนี้:

1. เอเจนต์แก้ไข handler
2. เอเจนต์รันคำสั่ง:

   apidog run -t 123456 -e 789012 -r cli

1. เอเจนต์อ่านผลลัพธ์
2. หาก exit code เป็น 0 เอเจนต์ดำเนินงานต่อ
3. หากได้รับ [exit code: 1] เอเจนต์ระบุ assertion ที่ล้มเหลว
4. เอเจนต์แก้ไข handler แล้วรันซ้ำ

ผลคือการตรวจสอบ API contract กลายเป็นส่วนหนึ่งของวงจรเดียวกับการรัน unit test แทนที่จะพึ่งการอนุมานจากโค้ดเพียงอย่างเดียว

สถานการณ์ทดสอบใน Apidog เก็บพฤติกรรมที่ API ควรมีอยู่แล้ว เอเจนต์จึงไม่จำเป็นต้องอ่าน route และ handler ทุกไฟล์ซ้ำเพื่อตรวจสอบความถูกต้องของ API

รูปแบบการแบ่งงานคือ:

• dsh เขียนและแก้ไขโค้ด
• Apidog CLI ตรวจสอบพฤติกรรม API
• ทีมสร้างและดูแลสถานการณ์ทดสอบใน Apidog

ตรวจสอบว่า dsh รันการทดสอบจริงหรือไม่

อย่าเชื่อเพียงข้อความสรุปของเอเจนต์ โดยเฉพาะเมื่อใช้ harness เวอร์ชัน developer preview ให้ตรวจสอบ 3 จุดต่อไปนี้

1. ตรวจสอบ tool call ใน web UI

ดู session ใน dsh web UI และค้นหาการเรียกใช้ bash ที่มีคำสั่งจริง:

apidog run ...

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

สั่งให้เอเจนต์รันใหม่และแสดง raw output:

รัน apidog run อีกครั้ง และแสดงเอาต์พุตดิบทั้งหมดพร้อม exit code

2. ตรวจสอบ exit code

ถามเอเจนต์โดยตรง:

รหัสการออกของคำสั่ง apidog run คืออะไร?

ให้ยึดค่า [exit code: N] จากผลเครื่องมือเป็นหลัก:

• 0 หมายถึงการทดสอบผ่าน
• ค่าอื่นที่ไม่ใช่ 0 หมายถึงคำสั่งหรือ assertion ล้มเหลว

หากเอเจนต์สรุปว่า “การทดสอบผ่าน” แต่ผลลัพธ์แสดง exit code ที่ไม่ใช่ 0 ให้เชื่อ exit code

3. ตรวจสอบว่าใช้ scenario และ environment ที่ถูกต้อง

ข้อผิดพลาด scenario not found มักเกิดจาก ID ไม่ถูกต้องหรือเอเจนต์เดา ID เอง

ตรวจสอบค่าต่อไปนี้กับคำสั่งในแท็บ CI/CD ของ Apidog:

-t <scenario_id>
-e <env_id>

แหล่งข้อมูลที่ควรเชื่อถือคือคำสั่งใน AGENTS.md และคำสั่งที่ Apidog สร้างจากแท็บ CI/CD

ทางเลือกเสริม: เพิ่ม Apidog MCP server เพื่อให้เอเจนต์อ่านสเปค

Apidog CLI เหมาะสำหรับการตรวจสอบผ่านสถานการณ์ทดสอบ หากต้องการให้เอเจนต์อ่านสเปค API ระหว่างเขียนโค้ด จะเป็นกรณีใช้งานของ MCP

ณ ปลายเดือนสิงหาคม 2026 การรองรับ MCP ยังไม่มีเอกสารใน README หรือคู่มือผู้ใช้หลักของ DeepSeek Harness อย่างไรก็ตาม มี community plugin ชื่อ hyqhyq3/dsh-mcp-manager ที่ค้นหาได้ผ่าน GitHub topic dsh-plugin

ปลั๊กอินนี้มีความสามารถดังนี้:

• เพิ่มหน้า MCP ใน Settings
• รองรับ remote HTTP server และ local stdio server
• ลงทะเบียนเครื่องมือเป็น mcp__<name>__*
• อ่านคอนฟิกต่อโปรเจกต์จาก:

  <workspace>/.dsh/dshmm/mcp.json

คุณสามารถเชื่อมต่อ Apidog MCP server เพื่อเปิดเผย API specification ผ่าน MCP ทำให้เอเจนต์ตรวจสอบ schema ของ endpoint ก่อนเขียน handler ได้

อย่างไรก็ตาม การใช้ community plugin ร่วมกับ host ที่ยังเป็น developer preview มีความเสี่ยงจาก breaking changes ให้มอง MCP เป็นชั้นเสริม ส่วน CLI เป็นเส้นทางหลักที่เรียบง่ายกว่า เพราะต้องใช้เพียง shell และคำสั่ง apidog run

ข้อควรระวังในเวอร์ชันพรีวิว และทิศทางในอนาคต

DeepSeek Harness เปลี่ยนแปลงอย่างรวดเร็ว รายละเอียดที่อาจเปลี่ยนได้มากที่สุด ได้แก่:

• ชื่อไฟล์ที่ปลั๊กอินคำสั่งค้นหา
• การรายงาน sandbox ของ bash tool
• พฤติกรรมของ MCP community plugin

แต่รูปแบบการทำงานยังใช้ได้กับ agent harness อื่น:

1. ประกาศคำสั่งตรวจสอบ API ไว้ในไฟล์กฎ
2. ใช้ CLI ที่คืน exit code ชัดเจน
3. ให้เอเจนต์อ่านผลลัพธ์และแก้โค้ดจากข้อผิดพลาดจริง

แนวทางเดียวกันนี้ใช้ได้ใน Claude Code และ harness อื่น ๆ เพราะเอเจนต์ทำงานได้ดีเมื่อมีผลลัพธ์คำสั่งที่ตรวจสอบได้ ไม่ใช่เมื่อถูกขอให้อนุมานว่าระบบทำงานถูกต้องหรือไม่

เริ่มต้นได้ตามลำดับนี้:

1. ดาวน์โหลด Apidog
2. สร้างสถานการณ์ทดสอบอย่างน้อยหนึ่งชุด
3. คัดลอกคำสั่ง apidog run จากแท็บ CI/CD
4. เพิ่มคำสั่งลงใน AGENTS.md
5. ให้ DeepSeek Harness รันการทดสอบทุกครั้งหลังแก้ไขโค้ด API

ครั้งต่อไปที่ DeepSeek Harness แก้ไข API ของคุณ มันจะสามารถตรวจสอบงานของตัวเองก่อนรายงานว่าเสร็จสิ้น

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

DeepSeek Harness อ่าน AGENTS.md โดยตรงหรือไม่?

ใช่ ปลั๊กอิน @deepseek-ai/dsh-agent-instructions จะโหลด AGENTS.md หรือใช้ CLAUDE.md เป็น fallback จาก project root และไดเรกทอรีเหนือ session working directory รวมถึง:

• AGENTS.local.md
• CLAUDE.local.md
• ~/.dsh/AGENTS.md

หากมี AGENTS.md สำหรับเอเจนต์อื่นอยู่แล้ว dsh สามารถใช้ไฟล์เดิมได้โดยไม่ต้องเปลี่ยนรูปแบบ

ฉันจำเป็นต้องมีแผน DeepSeek แบบชำระเงินเพื่อใช้ Apidog CLI ใน dsh หรือไม่?

ไม่ DeepSeek Harness เป็นโอเพนซอร์สภายใต้ MIT และรองรับการนำโมเดลของคุณเองมาใช้ ผู้ให้บริการที่รองรับครอบคลุม Anthropic, OpenAI, Bedrock, Vertex และ Azure รวมถึง custom gateway ผ่าน settings.yaml ตามที่อธิบายใน วิธีรันโมเดลใดๆ ใน DeepSeek Harness

Apidog CLI เป็นแพ็กเกจ npm ฟรี แต่ต้องมีสถานการณ์ทดสอบ Apidog และการยืนยันตัวตน ไม่ได้ผูกกับโมเดลเฉพาะ

ทำไมคำสั่งที่สองของเอเจนต์จึงลืมไดเรกทอรีที่คำสั่งแรกเปลี่ยนไป?

เครื่องมือ bash ของ dsh รันทุกคำสั่งใน fresh shell ดังนั้น cd ไม่คงอยู่ระหว่างการเรียกใช้

ใช้ workdir หากเครื่องมือรองรับ หรือรวมคำสั่งเป็นบรรทัดเดียว:

cd services/api && apidog run -t 123456 -e 789012 -r cli

dsh สามารถรันสถานการณ์โดยไม่ต้องถามฉันทุกครั้งได้หรือไม่?

ขึ้นอยู่กับนโยบายสิทธิ์ที่ใช้งานอยู่ web UI จะขออนุมัติก่อนการดำเนินการที่ต้องได้รับอนุญาตตามนโยบายนั้น

ตรวจสอบ Settings ของ build ที่ใช้งานเพื่อดูระดับสิทธิ์ที่ตั้งไว้ หากมี prompt สำหรับคำสั่ง apidog run กับ staging ให้พิจารณาอนุมัติตามนโยบายและแนวทางความปลอดภัยของทีมคุณ