นี่คือซีรีส์ 10 ตอนที่บอกเล่าว่า Apidog พัฒนา Apidog CLI ซึ่งเป็นเครื่องมือบรรทัดคำสั่งสำหรับการทดสอบ API และการจัดการวงจรชีวิต API ได้อย่างไร โปรดอ่านตามลำดับหรือข้ามไปยังโพสต์ที่คุณสนใจได้เลย:
| หัวข้อ | จุดเน้น | |
|---|---|---|
| 1 | เราสร้างเครื่องมือ MCP 126 ตัว แต่ไม่ใช่ทางออกที่ดีที่สุดสำหรับ Agent | การค้นพบปัญหา |
| 2 | ทำไมเราถึงพัฒนา Apidog CLI ตัวใหม่เอี่ยม | การพัฒนาสถาปัตยกรรม |
| 3 | กฎทอง: CLI สร้างข้อเท็จจริง, Model ทำงานบนข้อเท็จจริง | ปรัชญาหลัก |
| 4 | agentHints: การสอน CLI ให้สื่อสารกับ Agent |
เอาต์พุตที่มีโครงสร้าง |
| 5 | SKILL: การส่งมอบประสบการณ์การทำงานในรูปแบบโค้ด | ประสบการณ์การทำงาน |
| 6 | ตัวเลขไม่โกหก: การเรียกใช้เครื่องมือลดลง 30%, โทเค็นลดลง 25% | ผลลัพธ์เชิงปริมาณ |
| 7 | จาก PRD สู่ Testing Loop: เวิร์กโฟลว์ Agent ที่สมบูรณ์ด้วย Apidog CLI | บทช่วยสอนเชิงปฏิบัติ |
| 8 | ทำไมความเข้ากันได้กับ CI/CD จึงเป็นสิ่งที่ไม่สามารถต่อรองได้สำหรับเครื่องมือ Agent | มุมมองของ DevOps |
| 9 | AI Branch: การเปลี่ยนแปลงโปรเจกต์ที่ปลอดภัยยิ่งขึ้นด้วย AI Agents | เลเยอร์ความปลอดภัย |
| 10 | Spec-First เป็นเรื่องของเมื่อวาน ยินดีต้อนรับสู่ Skill-First | วิสัยทัศน์และอนาคต |
เราเปรียบเทียบ MCP กับ CLI + SKILL ในงานของผู้ใช้ทั่วไป ผลลัพธ์ที่ได้: การเรียกใช้เครื่องมือลดลง การสิ้นเปลืองโทเค็นน้อยลง การกู้คืนข้อผิดพลาดที่ดีขึ้น—และข้อมูลอธิบายว่าทำไมถึงเป็นเช่นนั้น
คำถามที่สำคัญ
ปรัชญาและหลักการออกแบบทั้งหมดที่เราได้แบ่งปันไปนั้นใช้งานได้จริงหรือไม่?
เราได้เปรียบเทียบงานของผู้ใช้ทั่วไปหลายอย่างภายในองค์กรโดยใช้ทั้งสองแนวทาง:
| ประเภทงาน | คำอธิบาย |
|---|---|
| เพิ่มเคสทดสอบ + การยืนยัน | สร้างเคสทดสอบสำหรับ Endpoint, รันการทดสอบ |
| ดูแลสถานการณ์การทดสอบ | อัปเดตสถานการณ์หลายขั้นตอนที่ซับซ้อน |
| นำเข้า/ยืนยันสินทรัพย์โปรเจกต์ | นำเข้าข้อมูล ยืนยันโครงสร้าง รันการทดสอบ |
ผลลัพธ์ที่ได้ไม่ใช่แค่การปรับปรุงตามความรู้สึกเท่านั้น แต่เป็นการ ลดลงที่วัดผลได้
งานที่ 1: เพิ่มเคสทดสอบตาม Endpoint
คำขอของผู้ใช้:
"เพิ่มการทดสอบสำหรับ Endpoint นี้และรันการยืนยัน"
เส้นทาง MCP
| ขั้นตอน | สิ่งที่เกิดขึ้น |
|---|---|
| การค้นหาเครื่องมือ | Agent ค้นหาในรายการเครื่องมือ |
| การเลือกเครื่องมือ | การเลือกเครื่องมือที่ถูกต้องหลายรอบ |
| การค้นพบฟิลด์ | Agent อ่านสคีมาของเครื่องมือ |
| การเดาฟิลด์ | Agent เดาฟิลด์ที่จำเป็น |
| ความพยายามในการเขียน | Agent เรียกใช้เครื่องมือสร้าง |
| การตอบสนองข้อผิดพลาด | เซิร์ฟเวอร์ปฏิเสธ (ฟิลด์ผิด/ขาดสิ่งที่จำเป็น) |
| ลองใหม่ | Agent ปรับเปลี่ยน ลองอีกครั้ง |
| ลองใหม่อีกครั้ง | ทำซ้ำจนกว่าจะสำเร็จ |
| รันการทดสอบ | Agent ค้นหาเครื่องมือรัน, ดำเนินการ |
รูปแบบทั่วไป:
ค้นหาเครื่องมือ → เลือกเครื่องมือ → อ่านสคีมา → เดาฟิลด์ → เขียน → ข้อผิดพลาด → ลองใหม่ → เขียน → ข้อผิดพลาด → ลองใหม่ → สำเร็จ → ค้นหาเครื่องมือรัน → รันเส้นทาง CLI + SKILL
| ขั้นตอน | สิ่งที่เกิดขึ้น |
|---|---|
| คำแนะนำ SKILL | SKILL ระบุประเภทงาน, ให้เวิร์กโฟลว์ |
| อ่าน Endpoint | CLI อ่านข้อเท็จจริงของ Endpoint |
| สร้างเคสทดสอบ | Agent สร้างตามข้อมูล Endpoint จริง |
| ตรวจสอบในเครื่อง | cli-schema ตรวจสอบก่อนเขียน |
| เขียน | CLI สร้างเคสทดสอบ |
| อ่านกลับ | CLI คืนค่าโครงสร้างที่สร้างขึ้น + agentHints |
| รันการทดสอบ | agentHints แนะนำให้รัน, Agent ทำตาม |
รูปแบบทั่วไป:
SKILL แนะนำ → อ่าน Endpoint → สร้าง → ตรวจสอบ → เขียน → อ่านกลับ → รันผลลัพธ์
| ตัวชี้วัด | เส้นทาง MCP | CLI + SKILL | การปรับปรุง |
|---|---|---|---|
| ขั้นตอนการเรียกใช้เครื่องมือ | ~15-20 | ~10-12 | ↓ ~30% |
| โทเค็นจากคำอธิบาย | โหลด ~50,000 | โหลด ~2,000 | ↓ ~96% |
| โทเค็นจากการลองใหม่ | สิ้นเปลือง ~5,000+ | สิ้นเปลือง ~500 | ↓ ~90% |
| การสิ้นเปลืองโทเค็นทั้งหมด | ~55,000 | ~2,500 | ↓ ~25% |
ขั้นตอนการเรียกใช้เครื่องมือลดลงประมาณ 30% การใช้โทเค็นจากคำอธิบายเครื่องมือที่ไม่ถูกต้องและการลองใหม่เนื่องจากข้อผิดพลาดลดลงประมาณ 25%
งานที่ 2: การเขียนที่มีโครงสร้าง (Processor, Assertion, Extractor)
คำขอของผู้ใช้:
"เพิ่มการยืนยันหลังการดำเนินการและการดึงตัวแปรไปยังเคสทดสอบนี้"
เส้นทาง MCP
| ขั้นตอน | สิ่งที่เกิดขึ้น |
|---|---|
| เดาชื่อฟิลด์ | Agent ไม่ทราบชื่อที่แน่นอน |
| เดาค่านับ | Agent เดาตัวเปรียบเทียบ, ประเภท |
| ความพยายามในการเขียน | เซิร์ฟเวอร์ปฏิเสธค่าที่ไม่ถูกต้อง |
| ลองใหม่ผ่านเครือข่าย | ไป-กลับสำหรับแต่ละข้อผิดพลาด |
| ความพยายามหลายครั้ง | ลองใหม่ 3-5 ครั้งเป็นเรื่องปกติ |
ข้อผิดพลาดทั่วไป:
| การเดาที่ผิด | ค่าที่ถูกต้อง | จำนวนครั้งที่ลองใหม่ |
|---|---|---|
comparator: "contains" |
comparator: "include" |
1-2 |
type: "global" |
type: "globals" |
1-2 |
subject: "responseBody" |
subject: "responseJson" |
1-2 |
แต่ละข้อผิดพลาด = 1 การเดินทางไป-กลับผ่านเครือข่าย + การตอบสนอง + การประมวลผลของ Agent
เส้นทาง CLI + SKILL
| ขั้นตอน | สิ่งที่เกิดขึ้น |
|---|---|
| อ่านเคสทดสอบ | CLI ได้โครงสร้างจริง |
| สร้างส่วนเพิ่มเติม | Agent สร้างตามรูปแบบจริง |
| ตรวจสอบในเครื่อง | cli-schema ตรวจจับข้อผิดพลาดก่อนเครือข่าย |
| แก้ไขในเครื่อง | Agent ปรับเปลี่ยนตามผลลัพธ์การตรวจสอบ |
| ตรวจสอบซ้ำ | ยืนยันการแก้ไข |
| เขียน | การเขียนที่ถูกต้องเท่านั้นที่จะส่งไปยังเซิร์ฟเวอร์ |
ข้อผิดพลาดทั้งหมดถูกตรวจจับในเครื่อง ไม่มีการลองใหม่ผ่านเครือข่ายสำหรับข้อผิดพลาดของฟิลด์
ผลลัพธ์
| ตัวชี้วัด | เส้นทาง MCP | CLI + SKILL | การปรับปรุง |
|---|---|---|---|
| การลองใหม่ผ่านเครือข่ายจากข้อผิดพลาดโครงสร้าง | 3-5 | 0 | ↓ ~100% |
| โทเค็นจากข้อผิดพลาดในการตอบสนอง | ~2,000 | ~0 | ↓ ~100% |
| การเรียกซ้ำทั้งหมด | ~5 | ~1 | ↓ ~40% |
การเรียกซ้ำจากข้อผิดพลาดเชิงโครงสร้างลดลงประมาณ 40%
งานที่ 3: การดำเนินงานต่อเนื่องหลังการสร้าง
คำขอของผู้ใช้:
"สร้างสถานการณ์การทดสอบด้วย Endpoint เหล่านี้"
เส้นทาง MCP
| ขั้นตอน | สิ่งที่เกิดขึ้น |
|---|---|
| สร้างสถานการณ์ | Agent เรียกใช้เครื่องมือสร้าง |
| การตอบสนองสำเร็จ | Agent เห็น "สร้างแล้ว" |
| ดำเนินการเขียนต่อ | Agent อัปเดต/เพิ่มสิ่งอื่นทันที |
| ข้ามการอ่านกลับ | Agent ไม่อ่านโครงสร้างจริง |
| เขียนตามข้อสันนิษฐาน | Agent เขียนด้วย ID/โครงสร้างที่เดา |
| ข้อผิดพลาดหรือไม่สมบูรณ์ | ผลลัพธ์ไม่ตรงกับความคาดหวัง |
ปัญหา: ความเฉื่อยในการดำเนินการ
Model มักจะดำเนินการต่อโดยตรงหลังจากสำเร็จ โดยข้ามขั้นตอนการอ่านกลับ
เส้นทาง CLI + SKILL
| ขั้นตอน | สิ่งที่เกิดขึ้น |
|---|---|
| สร้างสถานการณ์ | CLI สร้างสถานการณ์ |
| สำเร็จ + agentHints | CLI คืนค่าความสำเร็จ + คำแนะนำขั้นตอนถัดไป |
agentHints: "อ่านกลับก่อน" |
Agent เห็นคำแนะนำ |
| ทำตามคำแนะนำ | Agent อ่านกลับ |
| ทำงานกับโครงสร้างจริง | Agent ดำเนินการด้วยข้อมูลที่ถูกต้อง |
agentHints แนะนำให้อ่านกลับอย่างชัดเจน Agent ทำตาม
ผลลัพธ์
| ตัวชี้วัด | เส้นทาง MCP | CLI + SKILL | การปรับปรุง |
|---|---|---|---|
| สัดส่วนที่อ่านกลับก่อนดำเนินการต่อ | ~20% | ~85% | ↑ ~425% |
| การลองใหม่จากข้อผิดพลาดจากการข้ามโดยตรง | ~3-5 | ~0-1 | ↓ ~21% |
สัดส่วนของ Agent ที่อ่านกลับ ตรวจสอบ และรันการยืนยันล่วงหน้าเพิ่มขึ้นอย่างมีนัยสำคัญ ข้อผิดพลาดที่เกิดจากการข้ามไปยังขั้นตอนถัดไปโดยตรงลดลงประมาณ 21%
สรุป: แหล่งที่มาของการประหยัด
| แหล่งที่มาของการประหยัด | คำอธิบาย |
|---|---|
| การค้นพบเครื่องมือ | คำสั่ง CLI มีชื่อที่ชัดเจน; SKILL เป็นแนวทางในการเลือก |
| การตรวจสอบสคีมา | การตรวจสอบในเครื่องตรวจจับข้อผิดพลาดก่อนการเรียกผ่านเครือข่าย |
| การกู้คืนข้อผิดพลาด | agentHints ให้คำแนะนำที่นำไปปฏิบัติได้จริง ไม่ใช่แค่ "ล้มเหลว" |
| คำแนะนำการอ่านกลับ | ป้องกันการเขียนที่อิงตามข้อสันนิษฐาน |
| ลำดับเวิร์กโฟลว์ | SKILL ลดจุดตัดสินใจ |
การวิเคราะห์ต้นทุนที่แท้จริง
ข้อมูลเชิงลึกที่สำคัญ:
การเปิดใช้งานผลิตภัณฑ์โดย Agent ไม่ได้เกี่ยวกับเครื่องมือที่ยิ่งเยอะยิ่งดี
สิ่งที่ Model ใช้ไปจริง ๆ:
| ประเภทต้นทุน | ภาระ MCP | ภาระ CLI + SKILL |
|---|---|---|
| บริบท | คำอธิบายเครื่องมือ, สคีมา | SKILL ที่เน้นงานเท่านั้น |
| ความสนใจ | การเลือกจากเครื่องมือหลายตัว | การทำตามเวิร์กโฟลว์ที่มีคำแนะนำ |
| การเลือกเส้นทาง | การเดาลำดับ | ลำดับที่กำหนดโดย SKILL |
| ต้นทุนโทเค็นของผู้ใช้ | การลองใหม่, การเรียกที่ล้มเหลว | การเขียนที่ผ่านการตรวจสอบ, การเรียกที่น้อยลง |
หลังจากจำนวนเครื่องมือเพิ่มขึ้น สิ่งที่ Model ใช้ไปจริง ๆ ไม่ใช่ความสามารถในการเรียก API แต่เป็นการแลกเปลี่ยนระหว่างบริบท ความสนใจ การเลือกเส้นทาง และต้นทุนโทเค็นของผู้ใช้
หลักการทางวิศวกรรม
เป้าหมาย:
ย้ายต้นทุนเหล่านี้ออกจากบริบทของ Model และกลับไปยังตำแหน่งที่ระบบวิศวกรรมสามารถรับได้
| ต้นทุน | ตำแหน่ง MCP | ตำแหน่ง CLI + SKILL |
|---|---|---|
| การค้นพบเครื่องมือ | Model ต้องค้นหา | SKILL ให้มา |
| การตรวจสอบฟิลด์ | Model ต้องรู้ | cli-schema ตรวจสอบ |
| คำแนะนำขั้นตอนถัดไป | Model ต้องตัดสินใจ | agentHints แนะนำ |
| ความหมายของผลิตภัณฑ์ | Model ต้องเข้าใจ | CLI จัดการ |
ระบบวิศวกรรมซับซ้อนขึ้น Model มุ่งเน้นไปที่การสร้างและการตัดสิน
ตัวเลขเหล่านี้หมายถึงอะไร
ตัวเลขเหล่านี้อธิบายปัญหาที่เฉพาะเจาะจงมากขึ้น:
| ข้อมูลเชิงลึก | นัยยะ |
|---|---|
| การเรียกใช้เครื่องมือลดลง 30% | ความซับซ้อนย้ายจากการค้นพบไปสู่คำแนะนำ |
| โทเค็นที่สิ้นเปลืองลดลง 25% | ตรวจจับข้อผิดพลาดก่อนเครือข่าย |
| การลองใหม่เชิงโครงสร้างลดลง 40% | กลไกการตรวจสอบทำงาน |
| ข้อผิดพลาดจากการข้ามลดลง 21% | agentHints ป้องกันการดำเนินการต่อแบบสุ่มสี่สุ่มห้า |
CLI + SKILL ไม่ใช่แค่ความสง่างามทางสถาปัตยกรรม แต่เป็นประสิทธิภาพที่วัดผลได้
ต่อไปคืออะไร
เมื่อเราได้ยืนยันแนวทางด้วยตัวเลขแล้ว ลองมาดูกันว่ามันทำงานอย่างไรในทางปฏิบัติ
ในตอนที่ 7 จาก PRD สู่ Testing Loop: เวิร์กโฟลว์ Agent ที่สมบูรณ์ เราจะพาคุณไปดูตัวอย่างจริง—ทีมงานมี PRD "การคืนเงินคำสั่งซื้อ" และ Agent ใช้ CLI + SKILL เพื่อสร้าง OpenAPI, สร้างการทดสอบ, ตรวจสอบ และยืนยัน
ประเด็นสำคัญ
- ขั้นตอนการเรียกใช้เครื่องมือลดลงประมาณ 30%
- การสิ้นเปลืองโทเค็นจากคำอธิบายและการลองใหม่ลดลงประมาณ 25%
- การลองใหม่จากข้อผิดพลาดโครงสร้างลดลงประมาณ 40%
- ข้อผิดพลาดจากการข้ามขั้นตอนการอ่านกลับลดลงประมาณ 21%
- การประหยัดมาจาก: การค้นพบแบบมีคำแนะนำ, การตรวจสอบในเครื่อง, คำแนะนำที่นำไปปฏิบัติได้
- ความซับซ้อนย้ายจากบริบทไปยังระบบวิศวกรรม
ดาวน์โหลด Apidog เพื่อ ออกแบบ, จำลอง, ทดสอบ, และ จัดทำเอกสาร API ในพื้นที่ทำงานเดียว เรียนรู้เพิ่มเติมเกี่ยวกับ Apidog CLI สำหรับการทดสอบ API ด้วยบรรทัดคำสั่ง, การทำงานอัตโนมัติของ CI, และเวิร์กโฟลว์ AI Agent