เหตุผลที่เราพัฒนา Apidog CLI + SKILL โฉมใหม่

นี่คือบทความ 10 ตอนที่แบ่งปันว่า Apidog พัฒนา Apidog CLI ซึ่งเป็นเครื่องมือบรรทัดคำสั่งสำหรับการทดสอบ API และการจัดการวงจรชีวิต API ได้อย่างไร โปรดอ่านตามลำดับหรือข้ามไปยังโพสต์ใดก็ได้ที่คุณสนใจ:

เราสร้าง CLI + SKILL เพื่อจัดการในสิ่งที่ MCP ไม่ได้ปรับให้เหมาะสม: เวิร์กโฟลว์ที่ซับซ้อนพร้อมเกตการตรวจสอบและความสามารถในการดำเนินการที่มีโครงสร้าง

MCP ยังคงตอบสนองวัตถุประสงค์ของมันต่อไป

ก่อนที่เราจะเจาะลึก CLI + SKILL ขอชี้แจงก่อนว่า: Apidog MCP ยังคงใช้งานได้และได้รับการดูแลรักษาอยู่

MCP ให้การเชื่อมต่อเครื่องมือที่เป็นมาตรฐานตามโปรโตคอล ซึ่งมีประโยชน์สำหรับ:

• การดำเนินการที่เรียบง่ายและกำหนดไว้อย่างชัดเจน
• ผู้ใช้ที่ชอบเวิร์กโฟลว์ที่ใช้ MCP
• การรวมระบบนิเวศเข้ากับไคลเอนต์ที่รองรับ MCP

เราไม่ได้แทนที่ MCP เราสร้าง CLI + SKILL เพื่อเสริมการทำงานของมัน

สิ่งที่เราค้นพบคือ MCP มีความเป็นเลิศในการเชื่อมต่อเครื่องมือ แต่สำหรับเวิร์กโฟลว์ R&D ที่ซับซ้อน ซึ่งเป็นกระบวนการหลายขั้นตอนที่มีการตรวจสอบ การอ่านข้อมูลย้อนกลับ และการยืนยัน Agent จะได้รับประโยชน์จากกระบวนการทางวิศวกรรมที่สามารถดำเนินการได้ นั่นคือจุดที่ CLI + SKILL เข้ามามีบทบาท

ลองคิดดูแบบนี้:

CLI แบบเก่า: การรันการทดสอบในขั้นตอนสุดท้าย

Apidog CLI เป็นจุดเริ่มต้นบรรทัดคำสั่งสำหรับการรันการทดสอบ API มานานแล้ว

apidog run --project <projectId> --test-scenario <scenarioId> --environment <environmentId>

รากฐานนั้นยังคงมีความสำคัญ ทีมต้องการวิธีที่เชื่อถือได้เพื่อ:

• รันการทดสอบ API จากเทอร์มินัล
• สร้างรายงานใน CI Pipelines
• รักษา Quality Gates ภายในเวิร์กโฟลว์อัตโนมัติ

แต่ CLI แบบเก่าเน้นที่ การดำเนินการทดสอบ เป็นหลัก โดยจะปรากฏใกล้ ขั้นตอนสุดท้ายของเวิร์กโฟลว์:

การออกแบบ → การจัดทำเอกสาร → การจำลอง → การดีบัก → การทดสอบ → [CLI รันการทดสอบ]

CLI เป็นขั้นตอนสุดท้าย—หลังจากที่ทุกอย่างเสร็จสิ้นแล้ว

ข้อกำหนดใหม่: Agent ต้องการมากขึ้น

การพัฒนา API กำลังเปลี่ยนแปลงไป

AI Agent กำลังเข้ามามีส่วนร่วมใน:

สำหรับเวิร์กโฟลว์เหล่านี้ CLI ไม่สามารถเป็นเพียงขั้นตอนสุดท้ายที่รันการทดสอบที่มีอยู่แล้วได้

นอกจากนี้ยังต้องให้ Agent มีวิธีที่เสถียรในการ:

• อ่านสินทรัพย์ API (Endpoints, Schemas, Environments)
• สร้างหรืออัปเดตสินทรัพย์การทดสอบ (Test Cases, Test Scenarios)
• ตรวจสอบความถูกต้องของการเปลี่ยนแปลงที่มีโครงสร้างก่อนการเขียน
• เขียนกลับไปยังโปรเจกต์
• ตรวจสอบผลลัพธ์

การขยายตัวอย่างเป็นระบบ ไม่ใช่การเพิ่มเติมทีละน้อย

Apidog CLI ใหม่ไม่ได้เป็นเพียงการเพิ่มคำสั่งไม่กี่อย่างให้กับ CLI แบบเก่าเท่านั้น

เป็นการแนะนำความสามารถหลักของ Apidog เข้าสู่ CLI อย่างเป็นระบบ ทำให้เป็นเลเยอร์เวิร์กโฟลว์สำหรับนักพัฒนา สคริปต์ และ AI Agent

ขอบเขตทางสถาปัตยกรรมเบื้องหลังได้เปลี่ยนไปอย่างมาก

MCP VS CLI: การเปรียบเทียบสายโซ่การดำเนินการ

มาเปรียบเทียบสายโซ่การดำเนินการทั่วไปสำหรับเวิร์กโฟลว์ที่ซับซ้อนกัน

เส้นทาง MCP (ดีสำหรับการเชื่อมต่อเครื่องมือ)

เริ่มต้นเซสชัน MCP
        ↓
โหลดรายการเครื่องมือ + คำอธิบายเครื่องมือ
        ↓
Agent เลือกเครื่องมือ
        ↓
ค้นหาเครื่องมือเพิ่มเติม (listOpenApiEndpoints)
        ↓
รับ Schema (getOpenApiDetails)
        ↓
ดำเนินการเรียกใช้ HTTP (executeOpenApi)

จุดแข็งของ MCP: โปรโตคอลที่เป็นมาตรฐานสำหรับการเชื่อมต่อเครื่องมือเข้ากับ Agent

ตำแหน่งของความซับซ้อน: ความซับซ้อนส่วนใหญ่อยู่ในบริบทของโมเดลและขั้นตอนการเลือกเครื่องมือ Agent จำเป็นต้องเข้าใจ:

• รายการเครื่องมือ
• คำอธิบายเครื่องมือ
• Input Schemas
• ลำดับการเรียกใช้
• โครงสร้างผลลัพธ์

เหมาะสำหรับ: การดำเนินการที่เรียบง่ายพร้อมการจับคู่เครื่องมือกับงานที่ชัดเจน

จุดที่ท้าทาย: เวิร์กโฟลว์ที่ซับซ้อนซึ่ง Agent ต้องประสานงานเครื่องมือหลายตัว ทำความเข้าใจความหมายของผลิตภัณฑ์ และจัดการการตรวจสอบ

เส้นทาง CLI + SKILL (ดีกว่าสำหรับเวิร์กโฟลว์ที่ซับซ้อน)

SKILL ประเมินประเภทงาน
        ↓
CLI ดำเนินการคำสั่งเชิงความหมายของผลิตภัณฑ์
        ↓
cli-schema ตรวจสอบโครงสร้าง
        ↓
agentHints ให้คำแนะนำขั้นตอนต่อไป
        ↓
วนซ้ำการยืนยัน (รับการอ่านข้อมูลย้อนกลับ หรือ apidog run)

จุดแข็งของ CLI + SKILL: กระจายความซับซ้อนไปยังระบบวิศวกรรม

ตำแหน่งของความซับซ้อน:

• SKILL: ระเบียบวิธีและแนวทางเวิร์กโฟลว์
• CLI: การดำเนินการเชิงความหมายของผลิตภัณฑ์
• cli-schema: การตรวจสอบก่อนการเขียน
• agentHints: การนำทางหลังการดำเนินการ

เหมาะสำหรับ: เวิร์กโฟลว์แบบหลายขั้นตอน, การดำเนินการที่เน้นการตรวจสอบ, การทดสอบที่ขับเคลื่อนโดย Agent

ความแตกต่างที่สำคัญ: ความซับซ้อนอยู่ที่ใด

ความแตกต่างระหว่างสองแนวทางนี้คือ ตำแหน่งของความซับซ้อน

ใน MCP โมเดลต้องรับผิดชอบ:

• ควรใช้เครื่องมือใด
• คำอธิบายเครื่องมือกล่าวว่าอย่างไร
• ฟิลด์ใดที่จำเป็น
• ควรปฏิบัติตามลำดับใด
• โครงสร้างผลลัพธ์หมายถึงอะไร

สิ่งนี้ใช้ได้เมื่อการจับคู่จากงานไปยังเครื่องมือเป็นไปอย่างตรงไปตรงมา

ใน CLI + SKILL ระบบวิศวกรรมจะรับผิดชอบ:

• นี่เป็นประเภทงานใด (SKILL)
• คำสั่งใดที่ต้องดำเนินการ (CLI)
• โครงสร้างใดที่ถูกต้อง (cli-schema)
• สิ่งที่ต้องทำต่อไป (agentHints)

สิ่งนี้ทำงานได้ดีกว่าเมื่อเวิร์กโฟลว์มีเกตการตรวจสอบ, ข้อกำหนดในการอ่านข้อมูลย้อนกลับ และลูปการยืนยัน

ตัวอย่างเวิร์กโฟลว์ทั่วไป

นี่คือตัวอย่างที่เป็นรูปธรรมของเวิร์กโฟลว์ CLI + SKILL:

# ขั้นตอนที่ 1: อ่านข้อเท็จจริง
apidog endpoint get <endpointId> --project <projectId>

# ขั้นตอนที่ 2: ตรวจสอบก่อนการเขียน
apidog cli-schema validate test-case-create --file ./test-case-create.json

# ขั้นตอนที่ 3: ดำเนินการยืนยัน
apidog run --project <projectId> --out-dir ./apidog-reports

คำสั่งทั้งสามนี้แสดงถึง การดำเนินการทางวิศวกรรมสามอย่าง:

เส้นทาง Agent สำหรับเวิร์กโฟลว์ที่ซับซับซ้อน

สำหรับเวิร์กโฟลว์ที่ซับซ้อนและมีหลายขั้นตอน เส้นทางของ Agent จะได้รับประโยชน์จากโครงสร้าง CLI + SKILL

เส้นทาง MCP สำหรับเวิร์กโฟลว์ที่ซับซ้อน

"เลือกเครื่องมือ → ทำความเข้าใจ Schemas → ประสานงานลำดับ → จัดการข้อผิดพลาด"

Agent จะ:

• เลือกเครื่องมือที่เหมาะสมจากหลายตัวเลือก
• ทำความเข้าใจคำอธิบายเครื่องมือและ Schemas
• ประสานงานลำดับที่ถูกต้อง
• จัดการข้อผิดพลาดผ่านการลองใหม่

สิ่งนี้สามารถใช้ได้ แต่ต้องใช้การให้เหตุผลของโมเดลอย่างมากสำหรับแต่ละจุดตัดสินใจ

เส้นทาง CLI + SKILL สำหรับเวิร์กโฟลว์ที่ซับซ้อน

"อ่านข้อเท็จจริง → สร้างการเปลี่ยนแปลง → ตรวจสอบโครงสร้าง → เขียน → ดำเนินการยืนยัน"

Agent จะ:

• อ่านข้อเท็จจริงที่มีอยู่ก่อน (โดยมี SKILL เป็นตัวนำ)
• สร้างการเปลี่ยนแปลงโดยอิงจากข้อเท็จจริง
• ตรวจสอบโครงสร้างในเครื่อง (cli-schema)
• เขียนลงในโปรเจกต์
• ดำเนินการยืนยัน (agentHints นำทางขั้นตอนต่อไป)

ระบบวิศวกรรมจัดการการตรวจสอบ, คำแนะนำ และการยืนยัน—ซึ่งช่วยลดภาระการให้เหตุผลของโมเดล

ทั้งสองเส้นทางสามารถทำงานให้สำเร็จได้ CLI + SKILL ช่วยลดความซับซ้อนในขั้นตอนบริบทของโมเดล

สิ่งที่ CLI ครอบคลุมในตอนนี้

ด้วยการอัปเกรด CLI ครอบคลุมทรัพยากรหลักของ Apidog มากขึ้นดังนี้:

สิ่งนี้เปลี่ยนบทบาทของ Apidog CLI

มันไม่ใช่แค่เพียงวิธีในการรันการทดสอบหลังจากทุกอย่างเสร็จสิ้นแล้ว

ตอนนี้มันสามารถเข้ามามีส่วนร่วมในวงจรการพัฒนาได้เร็วขึ้น—ในจุดที่ Agent ต้องการ:

• ทำความเข้าใจโปรเจกต์
• สร้างหรืออัปเดตสินทรัพย์การทดสอบ
• ตรวจสอบการเปลี่ยนแปลง
• ดำเนินการยืนยัน

สรุปสถาปัตยกรรม

ทั้งสองอย่างมีให้ใช้งาน เลือกตามงานของคุณ

อะไรจะเกิดขึ้นต่อไป

ตอนนี้เราได้สรุปแล้วว่า CLI + SKILL เสริมการทำงานของ MCP ได้อย่างไร คำถามต่อไปคือ:

หลักการสำคัญที่ทำให้ CLI + SKILL มีประสิทธิภาพสำหรับเวิร์กโฟลว์ที่ซับซ้อนคืออะไร?

ในตอนที่ 3 กฎทอง: CLI สร้างข้อเท็จจริง, โมเดลดำเนินการตามข้อเท็จจริง เราจะสำรวจปรัชญาการออกแบบที่เป็นแนวทางในการตัดสินใจทุกอย่างของ CLI + SKILL—เริ่มต้นด้วย cli-schema validate ซึ่งเป็นเกตควบคุมคุณภาพที่ตรวจจับข้อผิดพลาดก่อนที่จะกลายเป็นการเขียนที่ล้มเหลว

ประเด็นสำคัญ

• MCP ยังคงทำงานได้ดี—ใช้สำหรับการดำเนินการที่เรียบง่ายและการรวมระบบนิเวศ MCP
• CLI + SKILL เสริมการทำงานของ MCP—ดีกว่าสำหรับเวิร์กโฟลว์ที่ซับซ้อนพร้อมการตรวจสอบ
• ความแตกต่างที่สำคัญคือตำแหน่งของความซับซ้อน: บริบทของโมเดล vs. ระบบวิศวกรรม
• CLI + SKILL ลดภาระการให้เหตุผลของโมเดลผ่านการตรวจสอบ, คำแนะนำ, การยืนยัน
• CLI ตอนนี้ครอบคลุมโปรเจกต์, API, สภาพแวดล้อม, Test Cases, Test Scenarios และอื่นๆ
• มีทั้งสองแนวทางให้เลือก—เลือกตามความซับซ้อนของงาน

ดาวน์โหลด Apidog เพื่อออกแบบ, จำลอง, ทดสอบ และ จัดทำเอกสาร API ในพื้นที่ทำงานเดียว เรียนรู้เพิ่มเติมเกี่ยวกับ Apidog CLI สำหรับการทดสอบ API ด้วยบรรทัดคำสั่ง, ระบบอัตโนมัติ CI และเวิร์กโฟลว์ AI Agent