วิธีทดสอบ AI Agent เรียก API โดยไม่เสียข้อมูล

เอเจนต์โค้ดดิ้ง AI ได้รันสคริปต์ และเห็นว่ามันสำเร็จ จากนั้นก็เห็นตารางฐานข้อมูลโปรดักชันหายไป โพสต์ใน Hacker News กลายเป็นไวรัลด้วยชื่อที่คมคายว่า: “AI ไม่ได้ลบฐานข้อมูลของคุณ แต่คุณเองต่างหากที่ลบ” ประเด็นนี้ได้รับการยอมรับเพราะมันเป็นเรื่องจริง เอเจนต์ทำตามคำจำกัดความของเครื่องมือ เครื่องมือได้เรียกใช้เอนด์พอยต์จริง เอนด์พอยต์นั้นไม่มีมาตรการป้องกัน และมนุษย์ได้มอบกุญแจให้กระบวนการที่ไม่หยุดถามว่า DELETE FROM users ดูน่าสงสัยหรือไม่ กระทู้ r/ClaudeAI อีกกระทู้เล่าเรื่องราวคล้ายกันจากมุมที่ต่างออกไป: เอเจนต์ในลูปการเรียกเก็บเงินใช้โทเค็นไปหลายร้อยดอลลาร์ก่อนที่ใครจะสังเกตเห็น พื้นผิวต่างกัน แต่ความล้มเหลวอยู่ในประเภทเดียวกัน ปัญหาไม่ได้อยู่ที่โมเดลนั้นโง่ ปัญหาคือไม่มีใครทดสอบ API

TL;DR

เอเจนต์ล้มเหลวในโปรดักชันเมื่อเครื่องมือของพวกเขาไม่มีมาตรการป้องกันฝั่ง API: เช่น อัตราการจำกัดที่ขาดหายไป, การไม่รองรับ Idempotency, การลบข้อมูลที่ละเอียดอ่อน, Schema ที่พัง คุณสามารถแก้ไขปัญหานี้ได้ด้วยสี่ขั้นตอน: ทดสอบสัญญาของคำจำกัดความเครื่องมือของเอเจนต์กับ OpenAPI spec ของคุณ, รัน Mock Server สำหรับเอนด์พอยต์ที่เป็นอันตราย, บังคับใช้ขีดจำกัดงบประมาณต่อเอเจนต์และ Idempotency keys, และจำลองสถานการณ์ความล้มเหลวใน CI Apidog ให้คุณสามารถนำเข้า OpenAPI, สร้าง Mock Server และเครื่องมือจำลองสถานการณ์ เพื่อทำทั้งหมดนี้ได้จากโปรเจกต์เดียว

บทนำ

เมื่อหนึ่งปีที่แล้ว "ทดสอบเอเจนต์ AI" หมายถึงการป้อนคำสั่งให้ Claude หรือ GPT และให้คะแนนคำตอบ แต่นั่นไม่ใช่มาตรฐานอีกต่อไปแล้ว เอเจนต์ในปัจจุบันเรียกใช้ฟังก์ชัน ฟังก์ชันเหล่านั้นเรียกใช้ API ของคุณ และ API ของคุณสื่อสารกับฐานข้อมูลจริง, ผู้ประมวลผลการชำระเงิน และบริการจากบุคคลที่สาม คำจำกัดความเครื่องมือที่ไม่ดีหรืออัตราการจำกัดที่ขาดหายไปไม่ใช่ปัญหาด้านรูปแบบ แต่มันคือเหตุการณ์ที่ไม่คาดฝันในการผลิตที่มีชื่อของคุณติดอยู่

เรื่องราวไวรัลใน Hacker News เดือนนี้ได้สะท้อนการเปลี่ยนแปลง ผู้เขียนโต้แย้งว่า AI ไม่ได้ลบฐานข้อมูล แต่มนุษย์ต่างหากที่ลบ โดยการให้สิทธิ์การเขียนแก่เอเจนต์โดยไม่มีการควบคุมใดๆ ระหว่างโมเดลกับข้อมูล กระทู้ดังกล่าวเป็นที่นิยมเพราะนักพัฒนาทุกคนที่อ่านต่างก็คิดว่า "ฉันเกือบจะปล่อยสิ่งนั้นออกไปแล้ว" ไม่กี่สัปดาห์ก่อนหน้านี้ มีโพสต์ใน Reddit อธิบายถึงลูปการเรียกเก็บเงินที่เอเจนต์พยายามเรียกซ้ำการโทรที่ล้มเหลวหลายครั้งจนบิลทะลุ 800 ยูโร ก่อนที่ใครจะสังเกตเห็น สาเหตุหลักเดียวกัน: ความไว้วางใจที่วางผิดชั้น

คุณสามารถแก้ไขปัญหานี้ได้ ชั้นโมเดลมีความสำคัญ แต่ชั้น API คือจุดที่คุณจะหยุดปัญหาเลือดออก บทความนี้จะแสดงวิธีทดสอบการรวม API ของเอเจนต์ AI แบบ end-to-end เราจะครอบคลุมมาตรการป้องกันสี่ประการที่ทุกการตั้งค่าเอเจนต์-API ต้องการ, อธิบายขั้นตอนการทำงานของ Apidog สำหรับการจำลองเอนด์พอยต์ที่เป็นอันตราย และปิดท้ายด้วยเทคนิคขั้นสูง เช่น การตรวจจับ Schema-drift และการแยกคีย์แบบคู่ คุณจะได้รูปแบบที่เป็นรูปธรรมที่คุณสามารถคัดลอกลงในรีโพของคุณได้เลยวันนี้ ดาวน์โหลด Apidog ก่อนเริ่มเพื่อที่คุณจะได้ทำตามขั้นตอน Mock Server ได้

ทำไมความล้มเหลวของเอเจนต์จึงดูเหมือนความล้มเหลวของ API

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

ลองดูที่การโจมตีแบบ Prompt injection ผู้ใช้อัปโหลด PDF ที่มีคำสั่งที่ซ่อนอยู่ เอเจนต์อ่าน และการเรียกใช้เครื่องมือถัดไปก็ไปยังเอนด์พอยต์ /admin/users ของคุณพร้อมกับ delete_all=true โมเดลไม่ได้เลือกสิ่งนี้; มันทำตามคำสั่งที่มันไม่มีเหตุผลที่จะไม่เชื่อ การแก้ไขไม่ใช่การทำให้ Prompt แข็งแกร่งขึ้น การแก้ไขคือการสร้าง API ที่ไม่เปิดเผย delete_all=true ให้กับโทเค็นที่มาจากเซสชันบริบทของผู้ใช้ OWASP เรียกสิ่งนี้ว่า LLM01 ใน LLM Top 10 ของพวกเขา และการบรรเทาปัญหาคือการอนุญาตสิทธิ์ฝั่ง API ไม่ใช่การออกแบบ Prompt

ลองดูที่ Schema ของเครื่องมือที่ผิดพลาด OpenAPI spec ของคุณระบุว่า amount เป็นจำนวนเต็มในหน่วยเซ็นต์ คำจำกัดความเครื่องมือของเอเจนต์ระบุว่า amount เป็นเลขทศนิยมในหน่วยดอลลาร์ สามเดือนผ่านไป มีคนคืนเงินค่าบริการ 19 เซ็นต์เป็น 19 ดอลลาร์ และคุณก็พบความไม่ตรงกันจากแผนกบัญชี โมเดลไม่ได้ผิด โมเดลใช้ Schema ที่คุณให้มัน Schema ได้เปลี่ยนไปจาก API ไม่มีใครทดสอบสัญญา

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

ลองดูที่การขาด Idempotency เอเจนต์เรียก POST /payments เพื่อเรียกเก็บเงินลูกค้า ได้รับข้อผิดพลาดหมดเวลาเครือข่าย พยายามซ้ำเพราะตัววางแผนคิดว่าการเรียกนั้นล้มเหลว และตอนนี้ลูกค้าถูกเรียกเก็บเงินสองครั้ง ชั้นเอเจนต์ไม่สามารถบอกได้ว่าการเรียกครั้งแรกสำเร็จหรือไม่ API ไม่ได้ให้วิธีที่จะถาม Idempotency keys แก้ปัญหานี้ได้ในโค้ดเซิร์ฟเวอร์ห้าบรรทัด แต่คุณต้องเขียนเอง

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

มาตรการป้องกันสี่ประการที่ทุกการรวม API ของเอเจนต์ต้องการ

การควบคุมสี่ประการที่แยกการตั้งค่าเอเจนต์ที่ล้มเหลวอย่างปลอดภัยจากการตั้งค่าที่ล้มเหลวอย่างแพง หากคุณมีเวลาเพียงพอที่จะเพิ่มหนึ่งอย่างในไตรมาสนี้ ให้เริ่มจากด้านบนสุด หากคุณสามารถทำได้ทั้งสี่อย่าง คุณจะครอบคลุมสถานการณ์เหตุการณ์ที่ไม่คาดฝันมากกว่า 90 เปอร์เซ็นต์ที่คุณจะเห็นในปี 2026

1. การทดสอบสัญญา Schema ของเครื่องมือ

OpenAPI spec ของคุณคือแหล่งความจริงสำหรับ API ของคุณ เอเจนต์ของคุณมีคำจำกัดความเครื่องมือที่แยกต่างหาก ซึ่งมักจะเขียนด้วยมือหรือคัดลอกวางจากเอกสาร สิ่งประดิษฐ์ทั้งสองนี้จะเปลี่ยนแปลงอยู่เสมอ การทดสอบสัญญาจะทำให้ CI build ของคุณล้มเหลวในทันทีที่พวกมันแตกต่างกัน

นี่คือการตรวจสอบ Python แบบง่ายที่ตรวจสอบคำจำกัดความเครื่องมือสไตล์ Claude กับ OpenAPI spec ที่ใช้งานจริง:

import json
from jsonschema import Draft202012Validator

def validate_tool_against_openapi(tool_def: dict, openapi_spec: dict) -> list[str]:
    """Return a list of mismatch errors, empty list = pass."""
    errors = []
    op = openapi_spec["paths"][tool_def["path"]][tool_def["method"].lower()]
    api_schema = op["requestBody"]["content"]["application/json"]["schema"]
    tool_schema = tool_def["input_schema"]

    api_props = set(api_schema.get("properties", {}).keys())
    tool_props = set(tool_schema.get("properties", {}).keys())

    for missing in api_props - tool_props:
        if missing in api_schema.get("required", []):
            errors.append(f"Tool missing required field: {missing}")
    for extra in tool_props - api_props:
        errors.append(f"Tool defines field not in API: {extra}")

    for prop, api_def in api_schema.get("properties", {}).items():
        if prop in tool_schema.get("properties", {}):
            tool_def_prop = tool_schema["properties"][prop]
            if api_def.get("type") != tool_def_prop.get("type"):
                errors.append(
                    f"Type mismatch on {prop}: API={api_def.get('type')} "
                    f"tool={tool_def_prop.get('type')}"
                )
    return errors

รันสิ่งนี้ในทุก PR ที่เกี่ยวข้องกับ OpenAPI spec หรือคำจำกัดความของเครื่องมือ ทำให้ build ล้มเหลวหากรายการไม่ว่างเปล่า การตรวจสอบเพียงอย่างเดียวนี้จะสามารถตรวจจับข้อผิดพลาด float-vs-cents ในส่วนก่อนหน้าได้หลายเดือนก่อนที่จะมีการคืนเงินใดๆ

2. สภาพแวดล้อม Sandbox และ Mock สำหรับเอนด์พอยต์ที่เป็นอันตราย

เอเจนต์ต้องการสถานที่ฝึกฝน พวกเขาไม่ควรฝึกฝนในสภาพแวดล้อมโปรดักชัน รูปแบบนี้ตรงไปตรงมา: ทุกเอนด์พอยต์ที่เปลี่ยนแปลงสถานะมี Mock Server ที่เทียบเท่ากันซึ่งส่งคืนรูปแบบการตอบกลับแบบเดียวกันโดยไม่ต้องทำงานจริง ลูปการพัฒนาเอเจนต์ของคุณใช้ Mock Server การทดสอบ staging ของคุณใช้ฐานข้อมูล Sandbox โปรดักชันยังคงไม่ถูกแตะต้องจนกว่ามนุษย์จะอนุมัติการ deploy

Apidog สร้าง Mock ได้โดยตรงจาก OpenAPI spec รวมถึงค่าฟิลด์ที่สมจริงซึ่งขับเคลื่อนโดยรูปแบบ Faker คุณชี้ Base URL ของเอเจนต์ของคุณไปที่ Mock Server รัน prompt เป็นร้อยครั้ง และสังเกตพฤติกรรมของมัน หากเอเจนต์พยายาม PUT ไปยัง /users/{id}/delete ซ้ำๆ เพราะเข้าใจเอกสารผิด Mock Server จะตรวจจับได้ ตารางผู้ใช้ในโปรดักชันไม่เคยเห็นข้อผิดพลาดนี้ ดู การพัฒนาแบบ Contract-first สำหรับรูปแบบที่กว้างขึ้นที่สิ่งนี้สอดคล้องด้วย

3. Idempotency Keys และ Soft Deletes สำหรับการดำเนินการที่ย้อนกลับไม่ได้

ทุกเอนด์พอยต์สำหรับเขียนข้อมูลที่เอเจนต์ของคุณสามารถเรียกใช้ได้ควรรองรับ Idempotency key ทุกการลบควรเป็นการลบแบบ Soft Delete โดยปริยาย โดยมีเส้นทาง Hard Delete แยกต่างหากที่มนุษย์อนุญาต

Middleware มีลักษณะดังนี้ใน Express:

const idempotencyCache = new Map();

function idempotency(req, res, next) {
  const key = req.headers['idempotency-key'];
  if (!key) {
    return res.status(400).json({ error: 'Missing Idempotency-Key header' });
  }
  if (idempotencyCache.has(key)) {
    const cached = idempotencyCache.get(key);
    return res.status(cached.status).json(cached.body);
  }
  const originalJson = res.json.bind(res);
  res.json = function (body) {
    idempotencyCache.set(key, { status: res.statusCode, body });
    setTimeout(() => idempotencyCache.delete(key), 24 * 60 * 60 * 1000);
    return originalJson(body);
  };
  next();
}

app.post('/payments', idempotency, createPayment);

เอเจนต์สร้าง UUID สำหรับการดำเนินการเชิงตรรกะแต่ละครั้ง และนำกลับมาใช้ใหม่ในการลองใหม่ API ของคุณจะคืนค่าการตอบกลับที่แคชไว้ในการเรียกครั้งที่สอง แทนที่จะเรียกเก็บเงินสองครั้ง รูปแบบเดียวกันนี้ช่วยป้องกันการส่งซ้ำใน API การส่งข้อความ การสร้างแถวซ้ำใน CRM และสถานการณ์อื่นๆ ส่วนใหญ่ที่ "เอเจนต์พยายามซ้ำแล้วเกิดความวุ่นวาย"

4. ขีดจำกัดงบประมาณต่อเอเจนต์

ทุกเอเจนต์ได้รับงบประมาณ งบประมาณโทเค็น งบประมาณคำขอ งบประมาณเงิน งบประมาณเวลา เมื่องบประมาณหมดลง เอเจนต์จะหยุดทำงาน ไม่มีข้อยกเว้น เหตุการณ์ Reddit 800 ยูโรเกิดขึ้นเพราะไม่มีใครกำหนดเพดานสำหรับลูปที่ทำงานผิดพลาด และเมื่อมนุษย์ตรวจสอบ ความเสียหายก็เกิดขึ้นแล้ว

Middleware งบประมาณที่ครอบคลุม API gateway ของคุณอาจติดตาม:

• โทเค็นต่อเซสชัน จำกัดที่ 50,000
• การเรียก API ต่อนาที จำกัดที่ 30
• การใช้จ่ายสะสมเป็นเซ็นต์ จำกัดที่ 500
• ความลึกของการเรียกใช้เครื่องมือ จำกัดที่ 10 การเรียกซ้อนกัน

เมื่อถึงขีดจำกัดใดๆ ให้คืนค่า HTTP 429 พร้อมด้วย Retry-After ที่มีโครงสร้างและส่วนหัว X-Budget-Exceeded ที่ระบุขีดจำกัด ตัววางแผนของเอเจนต์สามารถส่งเรื่องไปยังมนุษย์หรือยกเลิกงานได้ จากนั้นจับคู่สิ่งนี้กับการบันทึกเพื่อให้คุณเห็นว่าเอเจนต์ใดกำลังผลักดันขีดจำกัดและปรับแต่งตามความเหมาะสม

มาตรการควบคุมทั้งสี่นี้เสริมซึ่งกันและกัน การทดสอบสัญญาจะตรวจจับข้อผิดพลาด Schema ที่ชัดเจน Mock Server จะตรวจจับข้อผิดพลาดที่เป็นอันตราย Idempotency จะตรวจจับปัญหาการลองซ้ำ งบประมาณจะตรวจจับลูปที่ทำงานผิดพลาด เมื่อรวมกันแล้ว พวกมันจะเปลี่ยนจาก "เอเจนต์ทำสิ่งเลวร้าย" เป็น "เอเจนต์พบ 429, บันทึกปัญหา และขอความช่วยเหลือ" นั่นคือมาตรฐาน

ทดสอบการเรียก API ของเอเจนต์ด้วย Apidog

มาถึงส่วนที่เป็นการปฏิบัติจริง นี่คือวิธีการตั้งค่าเวิร์กโฟลว์การทดสอบ API ของเอเจนต์ที่สมบูรณ์ใน Apidog คุณจะต้องมี OpenAPI spec สำหรับ API ที่เอเจนต์ของคุณเรียกใช้ พร้อมกับรายการคำจำกัดความเครื่องมือของเอเจนต์

ขั้นตอนที่ 1: นำเข้า OpenAPI spec

เปิด Apidog สร้างโปรเจกต์ใหม่ และนำเข้าไฟล์ OpenAPI 3.x ของคุณ Apidog จะแยกวิเคราะห์ทุกเส้นทาง, Schema และตัวอย่าง และสร้างเอนด์พอยต์ที่เกี่ยวข้องในโปรเจกต์ หาก API ของคุณยังไม่ได้มีการบันทึกใน OpenAPI นี่คือช่วงเวลาที่จะทำ; ความน่าเชื่อถือของเอเจนต์ขึ้นอยู่กับการมีแหล่งความจริงเดียวที่ทั้งมนุษย์และเอเจนต์ AI ของคุณอ่าน คู่มือ เวิร์กโฟลว์ API แบบ Design-first จะอธิบายรายละเอียดนี้หากคุณกำลังเริ่มต้นจากศูนย์

ขั้นตอนที่ 2: กำหนดการตอบกลับ Mock สำหรับเอนด์พอยต์ที่เป็นอันตราย

ค้นหาเอนด์พอยต์ทั้งหมดที่เปลี่ยนแปลงข้อมูล: POST, PUT, PATCH, DELETE สำหรับแต่ละเอนด์พอยต์ คลิกเข้าไปที่เอนด์พอยต์แล้วเพิ่มการตอบกลับแบบ Mock Apidog สามารถสร้าง Mock ที่สมจริงได้โดยอัตโนมัติจาก Schema ของคุณ แต่คุณควรแทนที่ค่าฟิลด์เพื่อให้ดูเหมือนข้อมูลทดสอบ ไม่ใช่ข้อมูลโปรดักชัน ใช้คำนำหน้าเช่น mock_user_ และไทม์สแตมป์ในปี 1970 เพื่อให้การรั่วไหลใดๆ เป็นที่สังเกตได้ชัดเจนในบันทึก

เริ่ม Mock Server Apidog จะให้ URL ที่เสถียรแก่คุณ เช่น https://mock.apidog.com/m1/your-project-id/ ชี้ Base URL ของ API ของเอเจนต์ของคุณไปที่ Mock Server ระหว่างการพัฒนา ตอนนี้ DELETE /users/{id} ของคุณจะคืนค่า 200 พร้อมเพย์โหลดผู้ใช้ปลอม และฐานข้อมูลจริงของคุณจะปลอดภัย ดู การพัฒนาแบบ Contract-first สำหรับรูปแบบที่กว้างขึ้นที่สิ่งนี้สอดคล้องด้วย

ขั้นตอนที่ 3: เขียนสถานการณ์จำลองลำดับการเรียกของเอเจนต์

Apidog scenarios ช่วยให้คุณสามารถเชื่อมโยงการเรียก API เข้ากับการยืนยัน (assertions) เหมือนกับที่ชุดทดสอบทำ สำหรับเอเจนต์ที่คัดแยกตั๋วสนับสนุน สถานการณ์อาจเป็นดังนี้:

1. POST /auth/token พร้อมข้อมูลรับรองการทดสอบ, เก็บ Bearer token
2. GET /tickets?status=open พร้อม token, เก็บ ID ตั๋วแรก
3. POST /tickets/{id}/triage พร้อมหมวดหมู่, ยืนยัน 200 และเก็บฟิลด์ assigned-to
4. POST /notifications พร้อมข้อความตามเทมเพลต, ยืนยันว่าเนื้อหาข้อความตรงกับ Regex

คุณกำลังซ้อมสิ่งที่เอเจนต์จะทำบน Mock Server โดยมีการยืนยันในทุกขั้นตอน หากนักพัฒนาเปลี่ยน Schema ของตั๋วและ Regex ไม่ตรงกันอีกต่อไป สถานการณ์จะล้มเหลวและคุณจะรู้ก่อนที่เอเจนต์จะเข้าสู่โปรดักชัน ดู การทดสอบ API สำหรับวิศวกร QA สำหรับคู่มือการทดสอบสถานการณ์ที่กว้างขึ้น

ขั้นตอนที่ 4: รันจาก CI

Apidog มี CLI ที่รัน scenarios จาก GitHub Action, GitLab pipeline หรือ CI runner ใดๆ คำสั่งจะมีลักษณะเช่น apidog run -t scenario-id --env test เชื่อมต่อเข้ากับ PR pipeline ของคุณ เพื่อให้ทุกการเปลี่ยนแปลงใน OpenAPI spec หรือคำจำกัดความเครื่องมือของเอเจนต์กระตุ้นการเล่นซ้ำ scenario แบบเต็ม

ขั้นตอนที่ 5: เปรียบเทียบโมเดลสองเวอร์ชันเคียงข้างกัน

เมื่อคุณประเมินว่าจะอัปเกรดจากโมเดลหนึ่งไปยังอีกโมเดลหนึ่ง คุณต้องการทราบว่าการเรียกใช้เครื่องมือของโมเดลใหม่มีพฤติกรรมเหมือนกันในสถานการณ์เดียวกันหรือไม่ รันเอเจนต์กับสถานการณ์ Apidog เดียวกันด้วยโมเดล A และเก็บ Trace รันอีกครั้งด้วยโมเดล B และเก็บ Trace เปรียบเทียบเนื้อหาคำขอ ความประหลาดใจจะปรากฏขึ้นทันที: โมเดล B ส่งค่า priority ที่แตกต่างกัน หรือละเว้นฟิลด์ หรือใช้รูปแบบที่แตกต่างกันสำหรับวันที่ คุณจะตรวจจับการเปลี่ยนแปลงพฤติกรรมก่อนที่จะถูกนำไปใช้งาน นี่คือหนึ่งในรูปแบบที่ครอบคลุมใน การรวม API ของ GPT-5.5 ซึ่งการประเมินพฤติกรรมโมเดลใหม่เป็นความต้องการที่เกิดขึ้นซ้ำๆ

เวิร์กโฟลว์ทั้งหมดใช้เวลาประมาณหนึ่งชั่วโมงในการตั้งค่าครั้งแรก และใช้เวลาไม่กี่นาทีต่อการรันหลังจากนั้น ผลตอบแทนคือทุกการเปลี่ยนแปลงใน API หรือเครื่องมือเอเจนต์ของคุณจะถูกทดสอบกับชุดความคาดหวังพื้นฐานเดียวกัน

เทคนิคขั้นสูงและเคล็ดลับมือโปร

รูปแบบบางอย่างที่ทีมที่มีประสบการณ์มักจะนำมาใช้หลังจากที่พื้นฐานถูกจัดวางไว้แล้ว

กำหนดอุณหภูมิให้เป็นศูนย์ในการทดสอบ เอเจนต์ที่ไม่กำหนดผลลัพธ์ (Non-deterministic) ทำให้เกิดความล้มเหลวในการทดสอบที่ไม่กำหนดผลลัพธ์ เมื่อคุณทดสอบพฤติกรรมการเรียกใช้เครื่องมือ ให้ตั้งค่าอุณหภูมิเป็น 0 และกำหนดแหล่งความสุ่มใดๆ คุณกำลังทดสอบชั้นเครื่องมือ ไม่ใช่ชั้นความคิดสร้างสรรค์

บันทึก Trace การเรียกใช้เครื่องมือ ทุกการทดสอบจะบันทึกลำดับการเรียกใช้เครื่องมือที่เอเจนต์ทำไว้อย่างละเอียดพร้อมอาร์กิวเมนต์ เปรียบเทียบกับ Baseline ก่อนหน้า หากเอเจนต์เริ่มเรียก /users สองครั้งแทนที่จะเป็นครั้งเดียว คุณต้องการทราบทันที ไม่ใช่สามสัปดาห์ต่อมาเมื่อบิลมาถึง

อย่าให้ข้อมูลรับรองการผลิตแก่เอเจนต์เด็ดขาด เอเจนต์จะได้รับบัญชีบริการแบบจำกัดขอบเขต ข้อมูลรับรองการผลิตจะอยู่ในที่เก็บข้อมูลลับ ไม่ใช่ในไฟล์ .env ที่เอเจนต์สามารถอ่านได้ หากเอเจนต์ต้องการเรียกใช้เอนด์พอยต์การผลิต จะต้องผ่านพร็อกซีที่ลงนามคำขอด้วยโทเค็นที่มีอายุสั้น

แยก API keys สำหรับการอ่านและการเขียน งานของเอเจนต์ส่วนใหญ่เป็นการอ่านเป็นหลัก ออก Read-only keys สำหรับงานเหล่านั้น Write keys สงวนไว้สำหรับงานที่ต้องได้รับการอนุมัติจากมนุษย์ การเปลี่ยนแปลงเพียงครั้งเดียวนี้จะลดขอบเขตความเสียหายของเอเจนต์ที่ถูกบุกรุกลงครึ่งหนึ่ง

ใช้ HTTP 423 Locked สำหรับเอนด์พอยต์ที่ต้องการการอนุมัติจากมนุษย์ เมื่อเอเจนต์พยายามเรียกเอนด์พอยต์ที่ต้องการการยืนยันจากมนุษย์ ให้คืนค่า 423 พร้อมกับฟิลด์ confirmation_url ตัววางแผนของเอเจนต์จะเห็นสถานะที่ถูกล็อค แสดง URL ให้มนุษย์เห็น และรอ สิ่งนี้สะอาดกว่า 403 เพราะ 403 หมายถึง "คุณทำสิ่งนี้ไม่ได้" ในขณะที่ 423 หมายถึง "คุณยังทำสิ่งนี้ไม่ได้"

ล้มเหลวในการปิดเมื่อเกิด Schema Drift หากคำจำกัดความเครื่องมือของเอเจนต์ไม่ตรงกับ OpenAPI spec ของคุณ Build จะล้มเหลว อย่าส่งคำเตือน ให้ส่งข้อผิดพลาด ค่าใช้จ่ายของการ Build ที่ล้มเหลวเพิ่มอีกสองสามครั้งนั้นต่ำกว่าเหตุการณ์ในโปรดักชันหนึ่งครั้งมาก

ข้อผิดพลาดทั่วไปที่ควรหลีกเลี่ยง:

• Hardcode URL ของ Mock ลงใน Prompt ของเอเจนต์ ใช้ Environment variables เพื่อให้ Prompt เดียวกันทำงานกับ Mock, Staging และ Production
• ข้าม Idempotency บนเอนด์พอยต์ "ขนาดเล็ก" ทุกการเขียนจำเป็นต้องมี การส่งอีเมลก็ไม่มีข้อยกเว้น
• การบันทึก Full Request Body ใน Production ข้อมูล PII รั่วไหลเข้าสู่ Observability stack ของคุณ แก้ไขโทเค็น, อีเมล และตัวระบุ ก่อนที่จะถึง Logs
• ปล่อยให้เอเจนต์เข้าถึงฐานข้อมูลโดยตรง ต้องผ่าน API เสมอ API คือที่ที่การทดสอบของคุณอยู่
• เชื่อใน Confidence Score ของเอเจนต์ คะแนนสะท้อนความมั่นใจของโมเดลเกี่ยวกับคำตอบ ไม่ใช่ความปลอดภัยของ API เอเจนต์ที่มีความมั่นใจ 99 เปอร์เซ็นต์ก็ยังสามารถเรียกใช้เอนด์พอยต์ผิดได้

หากเอเจนต์ของคุณสื่อสารกับบริการภายในที่ไม่ได้อยู่เบื้องหลัง API gateway เดียวกัน รูปแบบการทดสอบ Microservices ครอบคลุมวิธีกระจายการทดสอบ Scenario ไปยังบริการต่างๆ

ทางเลือกและเครื่องมือ

คุณมีทางเลือก นี่คือการเปรียบเทียบที่เป็นธรรมของสี่แนวทางทั่วไป

สรุปอย่างตรงไปตรงมา: หากคุณใช้ LangSmith ให้ทำในสิ่งที่ใช้ได้ผลในฝั่งเอเจนต์ต่อไป และเพิ่มเลเยอร์การทดสอบ API แยกต่างหาก หากคุณมีปัญหาเรื่องราคาของ Postman หรือโมเดล Mock ของมัน Apidog เป็นทางเลือกที่ดี หากคุณกำลังเริ่มต้นใหม่ ให้เลือกเครื่องมือที่จัดการ OpenAPI, Mock และ Scenario ในโปรเจกต์เดียว เพราะนั่นคือที่ที่ 80 เปอร์เซ็นต์ของเวลาทดสอบ Agent-API ของคุณจะถูกใช้ไป

บางทีมอาจจับคู่เครื่องมือเหล่านี้ พวกเขาใช้ LangSmith สำหรับการประเมินระดับ Prompt และใช้ Apidog สำหรับการทดสอบสัญญาฝั่ง API และการเล่นซ้ำ Scenario ซึ่งใช้งานได้ดี เนื่องจากเครื่องมือเหล่านี้ทำงานในเลเยอร์ที่แตกต่างกัน

กรณีศึกษาในโลกแห่งความเป็นจริง

เอเจนต์อัปเดตแถวฐานข้อมูลโปรดักชัน ทีม Customer Success ได้สร้างเอเจนต์ที่อัปเดตฟิลด์บัญชีจากตั๋วสนับสนุน ก่อนเปิดตัว พวกเขาได้เชื่อมต่อเอนด์พอยต์สำหรับการเขียนทุกจุดให้ต้องใช้ Idempotency key และรันการจำลองสถานการณ์ 200 ครั้งใน Apidog กับฐานข้อมูล Sandbox การจำลองจับได้สองกรณีที่เอเจนต์พยายามตั้งค่า subscription_status เป็นสตริงที่ไม่อยู่ใน enum พวกเขาได้เพิ่มการตรวจสอบ Schema และเปิดใช้งานโดยไม่มีเหตุการณ์ไม่พึงประสงค์

เอเจนต์เรียกใช้ API การชำระเงิน ทีม Fintech ที่สร้างเอเจนต์คืนเงินอัตโนมัติได้กำหนดขีดจำกัดสูงสุด: คืนเงินได้สูงสุด 5 ครั้งต่อเซสชัน, สูงสุด 50 ดอลลาร์ต่อการคืนเงิน, และต้องใช้ Idempotency ในทุกการเรียก พวกเขาได้รัน ชุดทดสอบสัญญา กับ OpenAPI ของ Stripe ในทุก PR หกเดือนผ่านไป พวกเขาได้ประมวลผลการคืนเงิน 12,000 รายการโดยไม่มีการเรียกเก็บเงินซ้ำซ้อนเลย

เอเจนต์คัดแยกปัญหาใน GitHub ทีมแพลตฟอร์มได้สร้างเอเจนต์คัดแยกปัญหาโดยได้รับแรงบันดาลใจจาก Clawsweeper พวกเขาจำลอง GitHub API ใน Apidog รันเอเจนต์ผ่านการทดสอบสถานการณ์ 50 ครั้งที่ครอบคลุมกรณีขอบ (ปัญหาที่ถูกลบ, ป้ายกำกับที่ขาดหายไป, อินพุตของผู้ใช้ที่ผิดรูปแบบ) และพบข้อผิดพลาดสามครั้งก่อนเปิดตัว ตอนนี้เอเจนต์จัดการการคัดแยกในรีโพสาธารณะที่มีปัญหาเปิดอยู่ 5,000 รายการ

สรุป

หากคุณจะนำสิ่งใดสิ่งหนึ่งจากคู่มือนี้ไปใช้ ให้จำสิ่งนี้ไว้: เอเจนต์ไม่ใช่ปัญหา API ต่างหากที่เป็นปัญหา หรือเป็นทางแก้ไข ขึ้นอยู่กับว่าคุณได้ทดสอบมันหรือไม่

ห้าประเด็นสำคัญ:

• ปฏิบัติกับ Schema ของเครื่องมือในฐานะสัญญาและรันการทดสอบสัญญาใน CI
• จำลองเอนด์พอยต์ที่เป็นอันตรายสำหรับทุกวงจรการพัฒนาของเอเจนต์
• กำหนดให้ใช้ Idempotency keys สำหรับทุกการเขียนที่เอเจนต์ของคุณสามารถเรียกใช้ได้
• กำหนดขีดจำกัดงบประมาณต่อเอเจนต์ที่ล้มเหลวในการปิดเมื่อถึงขีดจำกัด
• เล่นซ้ำ Scenario ในทุก PR ที่เกี่ยวข้องกับ API หรือคำจำกัดความเครื่องมือ

เหตุการณ์ไวรัลในปีนี้จะไม่ใช่ครั้งสุดท้าย ทุกทีมที่เปิดใช้งานเอเจนต์จะต้องเจอโหมดความล้มเหลวเหล่านี้อย่างน้อยหนึ่งครั้ง ทีมที่กู้คืนได้อย่างรวดเร็วคือทีมที่มีมาตรการป้องกันอยู่แล้ว ดาวน์โหลด Apidog และเริ่มต้นด้วยขั้นตอน Mock Server เพียงแค่นั้นก็จะช่วยให้คุณไม่ต้องนอนไม่หลับในไตรมาสนี้ สำหรับมุมมองของทีม QA เกี่ยวกับปัญหาเดียวกันนี้ ดู เครื่องมือทดสอบ API สำหรับวิศวกร QA สำหรับบริบทที่กว้างขึ้นเกี่ยวกับการเขียนคำจำกัดความเครื่องมือที่เอเจนต์สามารถใช้ได้อย่างปลอดภัย ดู วิธีเขียนไฟล์ AGENTS.md

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

ฉันจะทดสอบการเรียก API ของเอเจนต์ AI ได้อย่างไรโดยไม่ต้องเสียเงินกับโทเค็น?

รันเอเจนต์ของคุณกับ Mock Server ในระหว่างการพัฒนา URL ของ Mock Server ของ Apidog จะคืนค่าการตอบกลับที่สมจริงโดยไม่เสียค่าใช้จ่าย ดังนั้นวงจรการทดสอบของคุณจึงไม่ใช้เครดิต API จริง ตั้งค่าอุณหภูมิเป็น 0 และใช้ชุด Prompt ขนาดเล็กที่กำหนดไว้ คุณสามารถรันการทดสอบเป็นพันครั้งโดยมีค่าใช้จ่ายเท่ากับ Mock Server ซึ่งเป็นศูนย์ ดู รายการตรวจสอบการทดสอบของวิศวกร QA สำหรับการตั้งค่าทั้งหมด

ความแตกต่างระหว่างการทดสอบเอเจนต์กับการทดสอบ API คืออะไร?

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

ฉันจำเป็นต้องมี Idempotency keys ในทุกเอนด์พอยต์หรือไม่?

ใช่ สำหรับทุกเอนด์พอยต์สำหรับการเขียน การอ่านเป็น Idempotent โดยนิยาม การเขียนไม่ใช่ และเอเจนต์จะลองใหม่ ห้าบรรทัดของ Middleware เพื่อรองรับ Idempotency header จะคุ้มค่าในครั้งแรกที่เอเจนต์ลองใหม่ข้อผิดพลาด 500 และคุณจะไม่ได้รับแถวซ้ำ

ฉันจะป้องกันการโจมตีแบบ Prompt injection ไม่ให้กระตุ้นการเรียก API ที่ไม่ดีได้อย่างไร?

อย่าพึ่งพาเพียงแค่ชั้น Prompt API ต้องบังคับใช้การอนุญาตสิทธิ์ตามบริบทผู้ใช้เดิม ไม่ใช่ตามคำขอของเอเจนต์ หากเซสชันบริบทของผู้ใช้ไม่สามารถเข้าถึง /admin/delete-all-users ได้ตามปกติ เอเจนต์ที่ดำเนินการในนามของผู้ใช้นั้นก็ไม่ควรจะทำได้เช่นกัน ไม่ว่า Prompt จะระบุว่าอย่างไร OWASP LLM Top 10 ครอบคลุมเรื่องนี้โดยละเอียด

ฉันสามารถใช้ Apidog กับ Claude หรือ GPT โดยตรงโดยไม่ต้องเขียนชั้นเครื่องมือของตัวเองได้หรือไม่?

คุณสามารถชี้คำจำกัดความเครื่องมือของเอเจนต์ของคุณไปที่ Apidog mock URL ระหว่างการทดสอบ ทั้ง Claude และ GPT รองรับ Base URL HTTP แบบกำหนดเองในคำจำกัดความเครื่องมือของพวกเขา ดังนั้นการสลับจึงเป็นเพียง Environment variable เดียว เมื่อคุณพร้อมที่จะทดสอบกับ Staging หรือ Production ให้เปลี่ยนตัวแปรนั้น

ขีดจำกัดงบประมาณที่เหมาะสมสำหรับเอเจนต์คือเท่าไร?

เริ่มต้นอย่างเข้มงวดและผ่อนคลายด้วยข้อมูล เริ่มต้นด้วย 50,000 โทเค็นต่อเซสชัน, 30 การเรียก API ต่อนาที, 5 ดอลลาร์ต่อภารกิจ สังเกตเมตริกเป็นเวลาสองสัปดาห์ เพิ่มขีดจำกัดที่คุณชนอย่างถูกต้อง ลดขีดจำกัดที่คุณไม่เคยชน ทบทวนเป็นรายเดือน เป้าหมายไม่ใช่ตัวเลขที่ตายตัว แต่เป็นตัวเลขที่เข้มงวดพอที่จะจับลูปที่ทำงานผิดพลาดได้ และยืดหยุ่นพอที่จะให้งานจริงสำเร็จได้

ฉันจะตรวจจับ Schema Drift ระหว่างเครื่องมือของเอเจนต์กับ API ของฉันได้อย่างไร?

รัน Schema Diff ใน CI ในทุก PR เปรียบเทียบคำจำกัดความเครื่องมือของเอเจนต์ (JSON schema) กับ OpenAPI request body schema สำหรับเอนด์พอยต์เดียวกัน ทำให้ Build ล้มเหลวหากพวกมันแตกต่างกัน โค้ด Python 30 บรรทัดในส่วนมาตรการป้องกันด้านบนทำสิ่งนี้; คัดลอกลงในรีโพของคุณและเชื่อมต่อเข้ากับ GitHub Actions