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

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

ลองใช้ Apidog วันนี้

💡 หากคุณกำลังเปิดใช้งานเอเจนต์อัตโนมัติที่เรียก API ของคุณ บทความนี้คือ checklist สำหรับทำให้ปลอดภัยขึ้น: จำลองเอนด์พอยต์ภายนอกระหว่างพัฒนา, แยกการทำงานอันตรายออกจากโปรดักชัน, เขียน contract test ให้ schema ของเครื่องมือ, ตั้งงบประมาณต่อเอเจนต์ และซ้อม failure mode ก่อนเกิดจริง เราจะใช้ Apidog เป็นโครงสร้างทดสอบ เพราะรองรับ OpenAPI, สร้าง Mock Server ได้โดยไม่ต้องเขียน glue code และรัน scenario test ที่ตรงกับลำดับ tool calls ของเอเจนต์ได้ชัดเจน

TL;DR

เอเจนต์ล้มเหลวในโปรดักชันเมื่อ API ไม่มีมาตรการป้องกัน เช่น rate limit หายไป, ไม่มี idempotency, เปิดให้ลบข้อมูลสำคัญ, หรือ schema ของเครื่องมือไม่ตรงกับ OpenAPI spec วิธีลดความเสี่ยงมี 4 ขั้นตอน:

1. ทดสอบ contract ระหว่าง tool schema กับ OpenAPI
2. ใช้ Mock Server สำหรับเอนด์พอยต์ที่เปลี่ยนข้อมูลหรือมีผลกระทบจริง
3. บังคับใช้ Idempotency key และ soft delete
4. ตั้ง budget limit ต่อเอเจนต์ แล้วรัน failure scenario ใน CI

Apidog ช่วยนำเข้า OpenAPI, สร้าง Mock Server และรัน scenario test ได้ในโปรเจกต์เดียว

บทนำ

เมื่อก่อน “ทดสอบเอเจนต์ AI” หมายถึงส่ง prompt ให้ Claude หรือ GPT แล้วให้คะแนนคำตอบ แต่ตอนนี้เอเจนต์ไม่ได้แค่ตอบข้อความ มันเรียก function, function เรียก API, และ API เชื่อมกับฐานข้อมูลจริง, payment processor และ third-party service จริง

ดังนั้น tool definition ที่ผิด หรือ API ที่ไม่มี rate limit ไม่ใช่ปัญหาด้าน prompt อีกต่อไป แต่มันคือ incident ในโปรดักชัน

เหตุการณ์ไวรัลใน Hacker News สะท้อนจุดนี้ชัดเจน: AI ไม่ได้ลบฐานข้อมูลโดยตรง แต่มนุษย์มอบ write permission ให้เอเจนต์โดยไม่มีชั้นควบคุมระหว่างโมเดลกับข้อมูล อีกกรณีใน Reddit คือ billing loop ที่เอเจนต์ retry ซ้ำจนบิลทะลุ 800 ยูโร สาเหตุหลักเหมือนกัน: วางความไว้วางใจผิดชั้น

ทางแก้คือทดสอบชั้น API ให้เหมือนเป็นพื้นผิวหลักของความเสี่ยง บทความนี้จะพาไล่ตั้งแต่ guardrail ที่ควรมี, การใช้ Apidog mock เอนด์พอยต์อันตราย, การทำ contract test, ไปจนถึงเทคนิคอย่าง schema drift detection และ key isolation

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

ถ้าอ่าน postmortem ของเอเจนต์ล้มเหลวมากพอ จะเห็น pattern เดียวกัน: โมเดลไม่ใช่ตัวละครหลัก API ต่างหากที่เป็นจุดที่เสียหายจริง

Prompt injection กลายเป็น API authorization failure

ตัวอย่าง:

1. ผู้ใช้อัปโหลด PDF ที่มีคำสั่งซ่อนอยู่
2. เอเจนต์อ่าน PDF
3. tool call ถัดไปยิงไปที่ /admin/users พร้อม delete_all=true

โมเดลไม่ได้ “ตั้งใจร้าย” แต่มันทำตาม input ที่ไม่มีเหตุผลให้ไม่เชื่อ การแก้ไม่ใช่แค่ทำ prompt ให้แข็งแรงขึ้น แต่ต้องทำให้ API ไม่เปิด delete_all=true ให้ token ที่มาจาก user-context session

OWASP จัดเรื่องนี้อยู่ในกลุ่ม LLM01 ของ LLM Top 10 และ mitigation ที่สำคัญคือ authorization ฝั่ง API

Tool schema drift ทำให้ข้อมูลผิดหน่วย

OpenAPI ระบุว่า amount เป็น integer หน่วยเซ็นต์ แต่ tool definition ของเอเจนต์ระบุว่า amount เป็น decimal หน่วยดอลลาร์

ผ่านไปสามเดือน มีคน refund 19 เซ็นต์ แต่ระบบทำเป็น 19 ดอลลาร์ โมเดลไม่ได้ผิด มันใช้ schema ที่คุณให้มัน ปัญหาคือ schema drift และไม่มี contract test

ไม่มี rate limit ทำให้ retry loop แพงมาก

เอเจนต์ retry เอนด์พอยต์อีเมลหลายพันครั้งในสองนาที เพราะ planner ยังมองว่า task “ยังไม่สำเร็จ” ทุก retry มีต้นทุนจริง สร้าง queue จริง และอาจทำให้ provider flag account ของคุณ

โมเดลไม่ได้มีเจตนาร้าย แต่มันทำงานกับ API ที่ไม่มีเพดาน

ไม่มี idempotency ทำให้เกิด double charge

เอเจนต์เรียก POST /payments แล้วเจอ network timeout จากนั้น retry เพราะคิดว่าการเรียกล้มเหลว แต่ request แรกอาจสำเร็จไปแล้ว ผลคือ customer ถูก charge สองครั้ง

ชั้นเอเจนต์ไม่รู้ว่า call แรกสำเร็จหรือไม่ API ต้องรองรับ Idempotency key เพื่อให้ retry ปลอดภัย

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

ถ้าคุณมีเวลาทำได้เพียงบางอย่าง ให้เริ่มจากรายการแรก แล้วค่อยเพิ่มรายการถัดไป แต่ถ้าทำครบทั้งสี่อย่าง คุณจะครอบคลุม failure mode ส่วนใหญ่ของ agent-API integration ได้ดีมาก

1. ทดสอบ contract ของ tool schema

OpenAPI spec คือแหล่งความจริงของ API ส่วนเอเจนต์มักมี tool definition แยกต่างหาก ซึ่งอาจถูกเขียนมือหรือ copy จากเอกสาร สองไฟล์นี้ drift ได้ง่าย

ทำให้ CI fail ทันทีเมื่อ schema ไม่ตรงกัน

ตัวอย่าง Python สำหรับตรวจ tool definition แบบ Claude-style กับ 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

ใช้งานใน CI:

python scripts/check_tool_contracts.py

หลักการคือ:

• ทุก PR ที่แก้ OpenAPI ต้องรัน test นี้
• ทุก PR ที่แก้ tool definition ต้องรัน test นี้
• ถ้ามี mismatch ให้ build fail ไม่ใช่แค่ warning

การตรวจนี้ช่วยจับปัญหาเช่น integer cents vs decimal dollars ก่อนเกิด incident จริง

2. ใช้ Sandbox และ Mock Server สำหรับเอนด์พอยต์อันตราย

เอเจนต์ต้องมีที่ให้ “ฝึก” แต่ที่นั้นไม่ควรเป็นโปรดักชัน

รูปแบบที่ควรใช้:

• ทุก POST, PUT, PATCH, DELETE มี mock response
• development ใช้ Mock Server
• staging ใช้ sandbox database
• production ใช้เฉพาะเมื่อผ่าน approval และ guardrail แล้ว

Apidog สร้าง mock จาก OpenAPI spec ได้โดยตรง รวมถึง mock field ที่สมจริงตาม schema คุณสามารถชี้ base URL ของเอเจนต์ไปที่ Mock Server แล้วรัน prompt หลายร้อยครั้งเพื่อดู behavior โดยไม่แตะข้อมูลจริง

ตัวอย่าง config:

AGENT_API_BASE_URL=https://mock.apidog.com/m1/your-project-id

ถ้าเอเจนต์พยายามเรียก PUT /users/{id}/delete ซ้ำเพราะเข้าใจเอกสารผิด Mock Server จะเผยปัญหานี้โดยไม่ทำให้ user table จริงเสียหาย

ดูแนวทางเพิ่มเติมใน การพัฒนาแบบ Contract-first

3. ใช้ Idempotency key และ Soft delete

ทุก write endpoint ที่เอเจนต์เรียกได้ควรรองรับ Idempotency key และทุก delete ควรเป็น soft delete โดย default ส่วน hard delete ควรแยก endpoint และต้องมี human approval

ตัวอย่าง Express middleware:

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 ต่อ logical operation แล้วใช้ key เดิมเมื่อ retry:

const idempotencyKey = crypto.randomUUID();

await fetch(`${baseUrl}/payments`, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Idempotency-Key": idempotencyKey
  },
  body: JSON.stringify({
    customer_id: "cus_123",
    amount: 1900
  })
});

ผลคือ retry ครั้งที่สองจะได้ response เดิม ไม่สร้าง payment ซ้ำ

รูปแบบนี้ใช้ได้กับ:

• payment
• email sending
• notification
• CRM row creation
• ticket update
• workflow trigger

4. ตั้ง Budget limit ต่อเอเจนต์

ทุกเอเจนต์ควรมีงบประมาณ:

• token budget
• request budget
• money budget
• time budget
• tool-call depth budget

เมื่อหมดงบ เอเจนต์ต้องหยุด ไม่มี exception เหตุการณ์ billing loop เกิดขึ้นเพราะไม่มีเพดานสำหรับ loop ที่ผิดพลาด

ตัวอย่าง policy:

Budget	Limit ตัวอย่าง
Tokens ต่อ session	50,000
API calls ต่อนาที	30
ค่าใช้จ่ายสะสม	500 เซ็นต์
Tool-call depth	10 nested calls

เมื่อเกิน limit ให้ API gateway คืนค่า:

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-Budget-Exceeded: api_calls_per_minute
Content-Type: application/json

{
  "error": "Budget exceeded",
  "limit": "api_calls_per_minute",
  "action": "escalate_to_human"
}

เอเจนต์ควรหยุด, log เหตุการณ์ และส่งต่อให้มนุษย์แทนการ retry ต่อ

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

ต่อไปคือ workflow ที่นำไปใช้ได้จริงใน Apidog โดยคุณต้องมี:

• OpenAPI spec ของ API ที่เอเจนต์เรียก
• tool definition ของเอเจนต์
• รายการ scenario ที่เอเจนต์ควรทำได้

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

เปิด Apidog, สร้างโปรเจกต์ใหม่ แล้ว import OpenAPI 3.x

Apidog จะ parse:

• paths
• request schema
• response schema
• examples
• endpoint structure

ถ้า API ยังไม่มี OpenAPI spec ให้เริ่มทำก่อน เพราะ agent reliability ต้องมี single source of truth ที่ทั้งมนุษย์, test และเอเจนต์อ่านร่วมกัน

อ่านเพิ่ม: เวิร์กโฟลว์ API แบบ Design-first

ขั้นตอนที่ 2: กำหนด Mock response สำหรับ endpoint ที่เปลี่ยนข้อมูล

หา endpoint ทั้งหมดที่เปลี่ยน state:

• POST
• PUT
• PATCH
• DELETE

จากนั้นสร้าง mock response ให้แต่ละ endpoint ใน Apidog

คำแนะนำเชิงปฏิบัติ:

• ใช้ข้อมูลที่ดูเป็น test data ชัดเจน
• prefix ด้วย mock_
• ใช้ timestamp ที่สังเกตง่าย เช่นปี 1970
• อย่าใช้ production-like identifier จริง
• อย่า mock response ที่ทำให้ทีมเข้าใจผิดว่าเป็นข้อมูลจริง

ตัวอย่าง mock payload:

{
  "id": "mock_user_123",
  "email": "[e-mail]",
  "deleted_at": "1970-01-01T00:00:00Z",
  "status": "soft_deleted"
}

เมื่อเริ่ม Mock Server แล้ว Apidog จะให้ URL เช่น:

https://mock.apidog.com/m1/your-project-id/

ตั้งค่าเอเจนต์ให้ใช้ URL นี้ระหว่าง development:

AGENT_API_BASE_URL=https://mock.apidog.com/m1/your-project-id/

ตอนนี้ DELETE /users/{id} จะคืน response ปลอม และฐานข้อมูลจริงไม่ถูกแตะ

ดูแนวทางเพิ่มเติมใน การพัฒนาแบบ Contract-first

ขั้นตอนที่ 3: เขียน Scenario ตามลำดับ tool calls ของเอเจนต์

Apidog scenarios ช่วยเชื่อม API calls หลายขั้นตอนพร้อม assertions ได้เหมือน integration test

ตัวอย่าง scenario สำหรับเอเจนต์คัดแยก support ticket:

1. POST /auth/token ด้วย test credentials แล้วเก็บ Bearer token
2. GET /tickets?status=open พร้อม token แล้วเก็บ ticket ID แรก
3. POST /tickets/{id}/triage พร้อม category แล้ว assert 200
4. เก็บค่า assigned_to
5. POST /notifications พร้อมข้อความตาม template
6. assert ว่า message ตรงกับ regex ที่กำหนด

ตัวอย่าง assertion ที่ควรมี:

status == 200
response.assigned_to != null
response.category in ["billing", "bug", "account", "feature_request"]
response.message matches /^Ticket #[0-9]+ assigned to .+$/

ถ้ามี developer เปลี่ยน ticket schema แล้วเอเจนต์ส่ง payload ไม่ตรง scenario จะ fail ก่อนถึงโปรดักชัน

อ่านเพิ่ม: การทดสอบ API สำหรับวิศวกร QA

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

เชื่อม scenario เข้ากับ CI เพื่อให้ทุก PR ที่กระทบ API หรือ tool definition ต้องผ่าน test

คำสั่งลักษณะนี้:

apidog run -t scenario-id --env test

ตัวอย่าง GitHub Actions:

name: Agent API Contract Tests

on:
  pull_request:
    paths:
      - "openapi/**"
      - "agents/**"
      - "tools/**"

jobs:
  test-agent-api:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Run schema contract checks
        run: python scripts/check_tool_contracts.py

      - name: Run Apidog scenarios
        run: apidog run -t ${{ secrets.APIDOG_SCENARIO_ID }} --env test

เป้าหมายคือทำให้ schema drift และ behavior drift ถูกจับใน PR ไม่ใช่ใน production logs

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

เมื่อจะอัปเกรดจากโมเดล A ไปโมเดล B อย่าดูแค่ response text ให้เทียบ tool-call trace ด้วย

วิธีทำ:

1. รัน agent ด้วยโมเดล A กับ Apidog scenario เดิม
2. เก็บ trace ของ tool calls และ request bodies
3. รัน agent ด้วยโมเดล B
4. เปรียบเทียบ request payload, endpoint order, retry behavior และ field format

สิ่งที่มักเจอ:

• โมเดลใหม่ส่ง priority ต่างจากเดิม
• ละเว้น required field
• ส่ง date format คนละแบบ
• เรียก endpoint ซ้ำ
• retry aggressive กว่าเดิม

อ่านเพิ่ม: การรวม API ของ GPT-5.5

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

ตั้ง temperature เป็น 0 ใน test

ถ้าคุณกำลังทดสอบ tool behavior ให้ลด nondeterminism:

{
  "temperature": 0
}

คุณไม่ได้ทดสอบความคิดสร้างสรรค์ของโมเดล แต่กำลังทดสอบว่า agent เรียก API ถูกต้องหรือไม่

บันทึก tool-call trace ทุกครั้ง

ทุก test run ควรบันทึก:

• endpoint
• method
• request body
• response status
• retry count
• idempotency key
• latency
• budget usage

แล้ว diff กับ baseline เดิม ถ้าเอเจนต์เริ่มเรียก /users สองครั้งแทนที่จะเป็นหนึ่งครั้ง คุณควรรู้ทันที

อย่าให้ production credential กับเอเจนต์โดยตรง

เอเจนต์ควรใช้ service account ที่จำกัด scope เท่านั้น

ห้าม:

PROD_DATABASE_URL=postgres://...
STRIPE_SECRET_KEY=sk_live_...

ในไฟล์ .env ที่เอเจนต์อ่านได้

แนวทางที่ดีกว่า:

• ใช้ proxy สำหรับ production calls
• ใช้ short-lived token
• sign request ฝั่ง server
• จำกัด endpoint ที่ agent token เรียกได้

แยก read key และ write key

งานของเอเจนต์ส่วนใหญ่เป็น read-heavy ดังนั้นให้ใช้ read-only key เป็น default

agent_read_key  -> GET เท่านั้น
agent_write_key -> POST/PUT/PATCH ที่ผ่าน approval แล้ว

การแยก key ช่วยลด blast radius หากเอเจนต์ถูก prompt injection หรือ tool call ผิด

ใช้ HTTP 423 Locked สำหรับ action ที่ต้องมี human approval

ถ้าเอเจนต์พยายามทำ action ที่ต้องรอมนุษย์ อย่าใช้ 403 เพราะสื่อว่า “ทำไม่ได้” ให้ใช้ 423 Locked เพื่อสื่อว่า “ยังทำไม่ได้จนกว่าจะ confirm”

HTTP/1.1 423 Locked
Content-Type: application/json

{
  "error": "Human confirmation required",
  "confirmation_url": "https://app.example.com/approvals/req_123"
}

planner ของเอเจนต์สามารถแสดง URL ให้มนุษย์และหยุดรอได้อย่างชัดเจน

Fail closed เมื่อเจอ schema drift

ถ้า tool definition ไม่ตรงกับ OpenAPI spec ให้ build fail ทันที อย่าทำเป็น warning ค่าใช้จ่ายของ build ที่ fail บ่อยขึ้นเล็กน้อยต่ำกว่า incident ในโปรดักชันมาก

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

• hardcode Mock URL ลงใน prompt ให้ใช้ environment variable
• ข้าม idempotency เพราะ endpoint “เล็ก”
• log full request body ใน production จน PII หลุดเข้า observability stack
• ให้เอเจนต์เข้าถึง database โดยตรง
• เชื่อ confidence score ของเอเจนต์ว่าแปลว่าปลอดภัย
• ใช้ production API key ใน local agent run
• ลืมทดสอบ retry และ timeout behavior

ถ้าเอเจนต์เรียกหลาย microservices ที่ไม่ได้อยู่หลัง gateway เดียวกัน ดู รูปแบบการทดสอบ Microservices

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

แนวทาง	เวลาตั้งค่า	จุดแข็ง	จุดอ่อน	เหมาะสำหรับ
การทดสอบยูนิตที่สร้างเอง	ต่ำ	ควบคุมได้เต็มที่, ไม่ผูก vendor	บำรุงรักษาสูง, drift จาก API จริงได้ง่าย	โปรเจกต์เล็ก, ทีมเดี่ยว
LangSmith / LangGraph eval harness	ปานกลาง	มี trace replay, metric ฝั่งโมเดล	เน้น agent layer มากกว่า API layer	ทีม AI ที่เน้น eval
Postman + Postbot	ปานกลาง	UI คุ้นเคย, template เยอะ	mock server เป็นส่วนเสริมแบบจ่ายเงิน, scenario syntax ล้าสมัย	ทีมที่ใช้ Postman อยู่แล้ว
Apidog scenarios + mocks	ปานกลาง	รองรับ OpenAPI, mock, CLI สำหรับ CI	brand awareness น้อยกว่า Postman	ทีมที่ต้องการ design, mock และ test ในเครื่องมือเดียว

สรุปเชิงปฏิบัติ:

• ถ้าใช้ LangSmith อยู่แล้ว ให้ใช้ต่อสำหรับ prompt/model eval แล้วเพิ่ม API test layer แยก
• ถ้าเจอข้อจำกัดของ Postman mock หรือ pricing ให้พิจารณา Apidog เป็นทางเลือก
• ถ้าเริ่มใหม่ ให้เลือกเครื่องมือที่จัดการ OpenAPI, mock และ scenario ได้ในโปรเจกต์เดียว

หลายทีมใช้คู่กัน: LangSmith สำหรับ prompt-level eval และ Apidog สำหรับ API contract กับ scenario replay ซึ่งเหมาะเพราะเครื่องมือสองตัวนี้ทดสอบคนละเลเยอร์

กรณีศึกษาในโลกจริง

เอเจนต์อัปเดตแถวฐานข้อมูลโปรดักชัน

ทีม Customer Success สร้างเอเจนต์ที่อัปเดต account fields จาก support tickets ก่อนเปิดตัว พวกเขา:

• บังคับ Idempotency key ทุก write endpoint
• รัน scenario 200 ครั้งใน Apidog กับ sandbox database
• ตรวจ enum validation กับ OpenAPI

ผลคือ simulation จับได้สองกรณีที่เอเจนต์พยายามตั้ง subscription_status เป็น string ที่ไม่อยู่ใน enum ทีมเพิ่ม schema validation แล้วเปิดใช้งานโดยไม่มี incident

เอเจนต์เรียก API การชำระเงิน

ทีม fintech ที่สร้าง refund agent ตั้ง policy ดังนี้:

• refund สูงสุด 5 ครั้งต่อ session
• สูงสุด 50 ดอลลาร์ต่อ refund
• ทุก call ต้องใช้ Idempotency key
• รัน ชุดทดสอบสัญญา กับ OpenAPI ของ Stripe ทุก PR

หลังใช้งานหกเดือน พวกเขาประมวลผล refund 12,000 รายการโดยไม่มี double charge

เอเจนต์คัดแยก GitHub issues

ทีมแพลตฟอร์มสร้าง issue triage agent โดยได้แรงบันดาลใจจาก Clawsweeper

พวกเขา:

• mock GitHub API ใน Apidog
• รัน 50 scenario ที่ครอบคลุม edge cases
• ทดสอบ deleted issue, missing label และ malformed user input

ก่อนเปิดตัวพบ bug 3 จุด ปัจจุบันเอเจนต์ช่วย triage repo สาธารณะที่มี issue เปิดอยู่ 5,000 รายการ

สรุป

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

Checklist ที่ควรทำทันที:

• treat tool schema เป็น contract
• รัน contract test ใน CI
• mock endpoint อันตรายทุกตัว
• ใช้ Idempotency key ทุก write endpoint
• ใช้ soft delete เป็น default
• ตั้ง budget limit ต่อเอเจนต์
• replay scenario ทุก PR ที่กระทบ API หรือ tool definition
• แยก read/write keys
• อย่าให้ production credential กับเอเจนต์โดยตรง

เหตุการณ์ไวรัลของปีนี้จะไม่ใช่ครั้งสุดท้าย ทุกทีมที่เปิดใช้เอเจนต์จะเจอ failure mode เหล่านี้อย่างน้อยหนึ่งครั้ง ทีมที่ฟื้นตัวได้เร็วคือทีมที่มี guardrail อยู่แล้ว

เริ่มจาก ดาวน์โหลด Apidog แล้วตั้ง Mock Server สำหรับ endpoint ที่เปลี่ยนข้อมูลก่อน แค่นี้ก็ลดความเสี่ยงได้ทันที

อ่านต่อ:

• เครื่องมือทดสอบ API สำหรับวิศวกร QA
• วิธีเขียนไฟล์ AGENTS.md

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

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

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

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

การทดสอบเอเจนต์ตรวจว่าโมเดลเลือก tool ถูกหรือไม่ และส่ง argument ถูกหรือไม่ ส่วนการทดสอบ API ตรวจว่า endpoint ทำงานถูกเมื่อถูกเรียก ทั้งสองชั้นต้องทดสอบแยกกัน เพราะเอเจนต์ที่ดีแต่ API เสียก็ยังให้ผลลัพธ์เสีย และ API ที่ดีแต่เอเจนต์เรียกผิดก็ยังเกิด incident ได้

จำเป็นต้องมี Idempotency key ทุก endpoint หรือไม่?

จำเป็นสำหรับทุก write endpoint ส่วน read endpoint เป็น idempotent โดยธรรมชาติ เอเจนต์จะ retry เสมอเมื่อเจอ timeout หรือ 5xx ดังนั้น write endpoint ต้องรองรับ Idempotency key เพื่อกัน duplicate rows, duplicate emails หรือ double charge

จะป้องกัน prompt injection ไม่ให้กระตุ้น API call อันตรายได้อย่างไร?

อย่าพึ่ง prompt layer อย่างเดียว API ต้อง enforce authorization ตาม user context เดิม ถ้า user session ไม่มีสิทธิ์เรียก /admin/delete-all-users เอเจนต์ที่ทำงานในนาม user นั้นก็ต้องไม่มีสิทธิ์เช่นกัน ไม่ว่า prompt จะสั่งอะไร

ใช้ Apidog กับ Claude หรือ GPT โดยตรงได้ไหม?

คุณสามารถชี้ tool definition ของเอเจนต์ไปที่ Apidog mock URL ระหว่าง test ได้ การสลับระหว่าง mock, staging และ production ควรทำผ่าน environment variable เช่น:

AGENT_API_BASE_URL=https://mock.apidog.com/m1/your-project-id

เมื่อพร้อมทดสอบ staging หรือ production ให้เปลี่ยนค่า variable ไม่ต้องแก้ prompt หรือ tool schema

Budget limit ที่เหมาะสมสำหรับเอเจนต์คือเท่าไร?

เริ่มเข้มก่อน แล้วค่อยปรับด้วยข้อมูล ตัวอย่าง initial limit:

• 50,000 tokens ต่อ session
• 30 API calls ต่อนาที
• 5 ดอลลาร์ต่อ task
• tool-call depth ไม่เกิน 10

สังเกต metric สองสัปดาห์ เพิ่ม limit ที่ชนเพราะงานจริง และลด limit ที่ไม่เคยใช้ เป้าหมายคือจับ loop ที่ผิดปกติให้เร็วโดยไม่ขัดงานปกติ

จะตรวจจับ schema drift ระหว่าง tool definition กับ API ได้อย่างไร?

รัน schema diff ใน CI ทุก PR โดยเปรียบเทียบ JSON schema ของ tool definition กับ OpenAPI request body schema ของ endpoint เดียวกัน ถ้า mismatch ให้ build fail โค้ด Python ในส่วน contract test ด้านบนสามารถนำไปวางใน repo แล้วเชื่อมกับ GitHub Actions ได้ทันที