จะวัดผล agent skill ที่เรียก API จริงได้อย่างไรโดยไม่เผาเงินและไม่ทำข้อมูลจริงพัง — Microsoft เสนอให้เอา Dev Proxy มาคั่น

วันที่ 17 กรกฎาคม 2026 Waldek Mastykarz (Principal Developer Advocate ของ Microsoft) เผยแพร่บทความที่ตอบคำถามซึ่งคนเขียน agent skill เจอกันเกือบทุกคนแต่ไม่ค่อยมีใครเขียนถึงตรง ๆ ว่า จะ eval skill ที่ต้องเรียก API จริงได้อย่างไร โดยไม่ต้องจ่ายค่า API ทุกรอบและไม่ทำข้อมูล production เละ

คำตอบของเขาคือเครื่องมือที่มีอยู่แล้วและไม่ได้ถูกสร้างมาเพื่องานนี้โดยเฉพาะ — Dev Proxy — ซึ่งเป็น API simulator แบบ command line โอเพนซอร์สและใช้ฟรี

ทำไม eval ที่ยิง API จริงถึงพัง

บทความแยกปัญหาออกเป็นสามข้อที่ต่างกันชัดเจน และข้อที่สามคือข้อที่ร้ายที่สุด:

1. ค่าใช้จ่าย — eval ที่ดีต้องรันหลายรอบ (บทความชุดเดียวกันแนะนำอย่างน้อย 5 รอบต่อสถานการณ์) ทุกรอบคือเงินที่จ่ายให้ API ปลายทาง
2. การเขียนทับข้อมูลจริง — skill ที่ทำ PATCH หรือ DELETE ได้ แปลว่า eval ของมันก็ทำได้เหมือนกัน และมันจะทำจริง
3. ผลลัพธ์ไม่นิ่ง — ถ้าระบบอื่นไปแก้ข้อมูลใน API ที่ใช้ทดสอบร่วมกัน ผลรันวันนี้กับพรุ่งนี้จะไม่เท่ากัน ทั้งที่ skill ไม่ได้เปลี่ยนเลยแม้แต่บรรทัดเดียว

ข้อสามคือหัวใจ เพราะ eval มีไว้เพื่อวัดว่า การแก้ skill ทำให้ดีขึ้นหรือแย่ลง ถ้าตัวเลขแกว่งด้วยเหตุผลที่ไม่เกี่ยวกับ skill การวัดนั้นก็ไร้ความหมาย

ทำไม “ก็เขียน mock server สิ” ถึงไม่ใช่คำตอบที่ดี

ทางออกที่คนคิดถึงก่อนคือเขียน mock server ขึ้นมาเอง บทความไม่ได้บอกว่าทำไม่ได้ แต่ชี้จุดอ่อนสองชั้น

ชั้นแรกคือภาระงาน — “You need to handle multiple endpoints, support filtering and pagination, return realistic payloads, respond correctly to PATCH and DELETE semantics” คือคุณกำลังจะเขียนและดูแลเซิร์ฟเวอร์อีกตัวที่ไม่มีวันได้ ship

ชั้นที่สองแหลมคมกว่ามาก: การใช้ mock server แปลว่าคุณต้อง แก้ URL ใน skill จาก endpoint จริงไปเป็น localhost ซึ่งหมายความว่า skill ที่คุณกำลังวัดผล ไม่ใช่ skill ตัวเดียวกับที่จะใช้จริง บทความสรุปประโยคนี้ได้คมมาก — “You’ve introduced a variable into the very thing you’re trying to measure”

Dev Proxy: ให้ skill เรียก URL เดิมต่อไป แล้วดักตอบแทน

Dev Proxy แก้ปัญหาชั้นที่สองด้วยการทำงานที่ชั้นเครือข่ายแทนที่จะแก้ที่โค้ด มันดักทราฟฟิก HTTP ที่ออกจากเอเจนต์แล้วตอบกลับเองในเครื่อง — “Dev Proxy intercepts HTTP traffic from your agent and responds locally, without any server to build or maintain”

ผลคือสิ่งที่บทความเรียกว่า transparent emulation: “Your skill keeps calling the real URLs and doesn’t know or care that a proxy is answering instead of the real server” — skill ที่ถูกวัดผลจึงเป็นไฟล์เดียวกับที่จะ deploy จริง ไม่มี config พิเศษสำหรับโหมดทดสอบ

การตั้งค่าเป็น JSON ล้วน ประกาศ base URL, ไฟล์ข้อมูลตั้งต้น และ action ที่รองรับ:

{
  "baseUrl": "https://api.contoso.com/products",
  "dataFile": "products-data.json",
  "actions": [
    { "action": "getAll" },
    { "action": "getOne", "url": "/{product-id}", "query": "$.[?(@.ProductID == {product-id})]" },
    { "action": "merge",  "url": "/{product-id}", "query": "$.[?(@.ProductID == {product-id})]" },
    { "action": "delete", "url": "/{product-id}", "query": "$.[?(@.ProductID == {product-id})]" }
  ]
}

จุดที่ควรสังเกตคือมี merge และ delete อยู่ในนั้นด้วย — แปลว่า การทดสอบเส้นทางที่เขียนข้อมูลกลายเป็นเรื่องที่ทำได้อย่างสบายใจ เพราะอย่างที่บทความระบุ “The data resets on every run. No production records harmed, no API costs” ข้อมูลถูกรีเซ็ตกลับสู่สถานะตั้งต้นทุกรอบ ซึ่งแก้ปัญหาข้อ 3 (ความไม่นิ่ง) ไปพร้อมกันโดยอัตโนมัติ

บทความนี้เป็นภาคต่อของ “Building AX evals that actually work” (15 ก.ค. 2026) ซึ่งเป็นตอนจบของซีรีส์เรื่อง Agent Experience — ตอนนั้นว่าด้วยการออกแบบเกณฑ์ให้วัดได้จริง เช่นเขียนว่า “All API calls to external services are wrapped in try-catch blocks” แทนที่จะเขียนลอย ๆ ว่า “proper error handling” ส่วนตอนนี้คือการทำให้ สภาพแวดล้อม ของ eval นิ่งพอที่เกณฑ์เหล่านั้นจะมีความหมาย

มุมมอง AI Curator

สิ่งที่น่าสนใจที่สุดของบทความนี้ไม่ใช่ Dev Proxy แต่คือ สัญญาณว่าการเขียน agent skill กำลังเดินเข้าสู่ยุคที่มีวินัยทางวิศวกรรม

ปี 2025 ถึงต้นปี 2026 การทำ skill คือการเขียน markdown แล้วลองดูว่าเอเจนต์ทำถูกไหม — วัดผลด้วยสายตา เชื่อด้วยความรู้สึก การที่ Microsoft ลงแรงเขียนซีรีส์แปดตอนเรื่อง eval และมาจบที่ “จะแยกตัวแปรรบกวนออกจากการวัดอย่างไร” บอกเราว่า skill กำลังถูกปฏิบัติเหมือนซอฟต์แวร์ที่มี regression suite ไม่ใช่ prompt ที่แก้ไปเรื่อย ๆ ตามอารมณ์

และข้อสังเกตที่ผมคิดว่าสำคัญกว่านั้น: ทางออกที่เขาเลือกไม่ใช่เครื่องมือ AI Dev Proxy ถูกสร้างมาตั้งแต่ก่อนยุคเอเจนต์เพื่อทดสอบความทนทานของแอปต่อ API ที่พัง มันมาแก้ปัญหาของ agent skill ได้ดีเพราะปัญหานี้ ไม่ใช่ปัญหา AI แต่เป็นปัญหา test isolation แบบคลาสสิก ที่วงการซอฟต์แวร์แก้มาสามสิบปีแล้ว บทเรียนคือทีมที่มีวินัยเรื่องการทดสอบอยู่แล้วจะได้เปรียบในการสร้างเอเจนต์ที่เชื่อถือได้ มากกว่าทีมที่เก่ง prompt แต่ไม่เคยเขียนเทสต์

สำหรับทีมไทย นี่คือจุดที่ประหยัดเงินได้จริงและควรทำก่อนอย่างอื่น ต้นทุนเรียก API ต่อรอบอาจดูเล็กเมื่อคิดเป็นบาท แต่ eval ที่มีความหมายต้องรันหลายรอบต่อสถานการณ์ คูณด้วยจำนวน skill คูณด้วยทุกครั้งที่แก้ — และเมื่อ CI เริ่มรัน eval อัตโนมัติทุก PR ตัวเลขนั้นจะโตแบบที่ไม่มีใครตั้งงบไว้ การเอา proxy มาคั่นตั้งแต่วันแรกจึงถูกกว่ามาก ทั้งในแง่เงินและในแง่ความเสี่ยงที่ eval ตัวหนึ่งจะเผลอ DELETE ข้อมูลลูกค้าจริงตอนตีสอง

แหล่งข่าว

• How to test agent skills without hitting real APIs — Microsoft Developer Blog (17 ก.ค. 2026)
• Building AX evals that actually work — Microsoft Developer Blog (15 ก.ค. 2026)
• What is Dev Proxy? — Microsoft Learn
• Simulate a CRUD API — Dev Proxy docs