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

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

สรุปย่อ

เอเจนต์ล้มเหลวในการทำงานจริงเมื่อเครื่องมือไม่มีระบบป้องกันฝั่ง API: ขาดการจำกัดอัตราการเรียกใช้ ไม่มี Idempotency การลบแบบ Hot delete สคีมาเสียหาย คุณแก้ไขปัญหานี้ได้ด้วยสี่วิธี: ทดสอบสัญญาของคำจำกัดความเครื่องมือของเอเจนต์กับ OpenAPI spec ของคุณ, รันเซิร์ฟเวอร์จำลองสำหรับปลายทางที่ก่อให้เกิดความเสียหาย, บังคับใช้ขีดจำกัดงบประมาณต่อเอเจนต์และ Idempotency keys, และจำลองสถานการณ์ความล้มเหลวซ้ำใน CI Apidog มอบการนำเข้า OpenAPI, mocks และ scenario runner ให้คุณดำเนินการทั้งหมดได้จากโปรเจกต์เดียว

บทนำ

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

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

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

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

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

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

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

ลองดูการจำกัดอัตราการเรียกใช้ที่ขาดหายไป เอเจนต์ในลูปการลองซ้ำถล่มปลายทางอีเมลธุรกรรมของคุณเป็นพันครั้งในสองนาที เพราะตัววางแผนของเอเจนต์ยังคงทำเครื่องหมายขั้นตอนว่า "ยังไม่สำเร็จ" การลองซ้ำแต่ละครั้งมีค่าใช้จ่าย การลองซ้ำแต่ละครั้งจะส่งอีเมลจริง By the time you wake up, your provider has flagged your account and your customers are getting spammed. โมเดลไม่ได้มีเจตนาร้าย โมเดลทำงานจากเครื่องมือที่ไม่มีขีดจำกัด

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

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

สี่หลักประกันที่การผสานรวม Agent-API ทุกตัวจำเป็นต้องมี

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

1. การทดสอบสัญญา Tool-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 ที่เทียบเท่ากันซึ่งส่งคืนรูปแบบการตอบสนองแบบเดียวกันโดยไม่ต้องทำงาน วงจรการพัฒนาเอเจนต์ของคุณใช้ Mock การทดสอบ Staging ของคุณใช้ฐานข้อมูล Sandbox โปรดักชันยังคงไม่ถูกแตะต้องจนกว่ามนุษย์จะอนุมัติการ Deploy

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

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

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

มิดเดิลแวร์จะมีลักษณะดังนี้ใน 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 ของคุณจะส่งคืนการตอบสนองที่แคชไว้ในการเรียกครั้งที่สองแทนที่จะเรียกเก็บเงินซ้ำ รูปแบบเดียวกันนี้ป้องกันการส่งซ้ำใน Messaging API การสร้างแถวซ้ำใน CRM และสถานการณ์อื่นๆ ส่วนใหญ่ที่ "เอเจนต์ลองใหม่แล้วตอนนี้เรามีปัญหา"

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

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

มิดเดิลแวร์งบประมาณที่ห่อหุ้ม API gateway ของคุณอาจติดตาม:

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

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

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

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

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

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

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

ขั้นตอนที่ 2: กำหนด Mock Responses สำหรับปลายทางที่ก่อให้เกิดความเสียหาย

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

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

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

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

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

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

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

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

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

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

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

เทคนิคขั้นสูงและเคล็ดลับจากผู้เชี่ยวชาญ

รูปแบบบางอย่างที่ทีมที่มีประสบการณ์มักใช้หลังจากที่ตั้งค่าพื้นฐานเสร็จสิ้นแล้ว

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

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

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

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

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

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

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

• Hardcoding URL ของ mock ใน prompt ของเอเจนต์ ใช้ตัวแปรสภาพแวดล้อมเพื่อให้ prompt เดียวกันทำงานกับ mock, staging และ prod
• ข้าม Idempotency บนปลายทาง "เล็กๆ" ทุกการเขียนจำเป็นต้องมีมัน การส่งอีเมลก็ไม่มีข้อยกเว้น
• การบันทึก Full Request Body ในระบบโปรดักชัน PII จะรั่วไหลไปยัง observability stack ของคุณ แก้ไขโทเค็น, อีเมล และตัวระบุ ก่อนที่จะถึงบันทึก
• ให้เอเจนต์เข้าถึงฐานข้อมูลโดยตรง ไปผ่าน API เสมอ API คือที่ที่การทดสอบของคุณอยู่
• การเชื่อถือคะแนนความมั่นใจของเอเจนต์ คะแนนสะท้อนความมั่นใจของโมเดลเกี่ยวกับคำตอบ ไม่ใช่ความปลอดภัยของ API เอเจนต์ที่มั่นใจ 99 เปอร์เซ็นต์ก็ยังสามารถเรียกปลายทางผิดได้

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

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

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

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

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

กรณีการใช้งานจริง

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

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

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

สรุป

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

ห้าข้อสรุปหลัก:

• ปฏิบัติต่อ Tool Schema เสมือนสัญญา และรัน Contract Test ใน CI
• จำลองปลายทางที่ก่อให้เกิดความเสียหายสำหรับทุก Agent Dev Loop
• บังคับใช้ Idempotency Keys ในทุกการเขียนที่เอเจนต์ของคุณสามารถเรียกใช้ได้
• ตั้งค่าขีดจำกัดงบประมาณต่อเอเจนต์ที่ล้มเหลวแบบปิดเมื่อถึงขีดจำกัด
• เล่นซ้ำสถานการณ์ในทุก PR ที่แก้ไข API หรือ Tool Definitions

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

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

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

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

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

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

ฉันจำเป็นต้องมี Idempotency keys บนทุกปลายทางหรือไม่?

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

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

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

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

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

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

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

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

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