AI Agent แก้บั๊กอัตโนมัติ: สร้างตัวที่หาสาเหตุให้เจอก่อนแก้

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

ทีม DeepSeek Harness เปิดตัวไอเดียนี้ต่อผู้ชมจำนวนมากเมื่อวันที่ 1 พฤศจิกายน 2026 ผ่านบทความเรื่องการออกแบบ super-agent คู่มือนี้จะเปลี่ยนแนวคิดนั้นให้เป็น pipeline ที่คุณสร้างได้ภายในสัปดาห์นี้ โดยการรีโปรดิวส์จะเขียนเป็น API test ที่เอเจนต์ของคุณสร้างและรันจาก terminal เอง

ทำไมคำสั่ง “เอเจนต์ แก้นี่ให้หน่อย” จึงล้มเหลวถ้าไม่มี repro

ถ้าสั่งให้ coding agent แก้บั๊กจากรายงาน คุณมักจะได้ diff ที่ดูมั่นใจกลับมา แต่คุณจะบอกไม่ได้เลยว่ามันแก้บั๊กของคุณ บั๊กที่มันจินตนาการขึ้นเอง หรือไม่ได้แก้อะไรเลย

ถ้าไม่มีขั้นตอนรีโปรดิวส์ สามอย่างนี้มักผิดพลาด:

• เอเจนต์เดาสาเหตุ มันเลือกบรรทัดที่น่าจะเป็นสาเหตุที่สุดจากข้อความ error แล้วแก้มัน
• คำว่า “แก้แล้ว” ไม่มีนิยามชัดเจน หลักฐานเดียวคือสรุปของเอเจนต์เอง
• Regression หลุดรั่วเข้ามา การแพตช์ validator ที่ใช้ร่วมกันอาจแก้ endpoint หนึ่งตัวแต่ทำให้อีกสี่ตัวพัง

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

ที่มาของแนวคิด “รีโปรดิวส์และแก้แบบเงียบๆ”

ในบทความ “Exploring Super-agent Design” ทีม DeepSeek Harness อธิบายนโยบายจากกลุ่มผู้ใช้ของพวกเขาเอง: เมื่อมีคนรายงานบั๊ก เอเจนต์จะพยายามรีโปรดิวส์มันในเบื้องหลัง และจะส่งเสียงเฉพาะเมื่อมี fix ที่ยืนยันแล้วและเรียบง่าย ไม่เช่นนั้นจะไม่พูดอะไรเลย

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

ข้อควรระวังหนึ่ง: บทความอธิบายสถาปัตยกรรม ไม่ใช่ฟีเจอร์ของ DeepSeek Harness ที่เปิดใช้งานจริง บางส่วนอยู่ใน prototype plugin ชื่อ dsh-superagent-prototype ซึ่งผู้เขียนระบุว่าไม่ใช่ผลิตภัณฑ์ทางการของ DeepSeek สำหรับภาพรวมของ router และ worker ดูได้ที่ วิธีสร้าง super-agent

Pipeline ของเอเจนต์แก้บั๊ก 5 ขั้นตอน

เอเจนต์ที่แก้บั๊กเองได้จะวนลูปแบบเดียวกันทุกครั้ง โดยมีประตูตรวจสอบ 2 จุด:

1. Intake: เก็บรายงาน request ที่ล้มเหลว และ response ที่ได้รับ
2. Reproduce: เขียนเทสต์ที่ล้มเหลวด้วยเหตุผลตามที่รายงาน ไม่มีเทสต์ที่ล้มเหลว ก็ไม่มีการแก้
3. Fix: แพตช์โค้ดบน branch หรือ worktree ที่แยกออกมา
4. Re-run: เทสต์ใหม่ต้องผ่าน และชุดเทสต์เดิมก็ต้องผ่านด้วย
5. Deliver: เปิด pull request พร้อมหลักฐาน หรือเงียบไว้

ขั้นตอนที่ 1: รับรายงานบั๊กเข้าสู่ระบบ

เอเจนต์ของคุณรีโปรดิวส์คำว่า “checkout พังอีกแล้ว” ไม่ได้หรอก ให้ขั้นตอน intake มีรูปแบบตายตัว:

ถ้าข้อมูลไม่ครบ เอเจนต์จะถามหนึ่งครั้งหรือดึง request จาก logs มาแทน Error body ที่เป็นไปตาม RFC 9457 problem details จะช่วยได้ เพราะ error type จะมารับในรูปแบบที่คาดการณ์ได้

ขั้นตอนที่ 2: รีโปรดิวส์บั๊กเป็น API test ที่ล้มเหลว

นี่คือประตูตรวจสอบสำคัญ เอเจนต์จะเปลี่ยนข้อมูลจาก intake ให้เป็น test case ที่มี assertion สองข้อ คือ status code ที่คาดหวัง และฟิลด์ที่ response ควรมี แล้วรันกับสภาพแวดล้อมจริง ผลลัพธ์ที่เป็นไปได้มีสามแบบ:

• ล้มเหลวด้วยเหตุผลตามที่รายงาน คุณมี repro แล้ว ไปต่อ
• ผ่าน บั๊กรีโปรดิวส์ตามคำอธิบายไม่ได้ บันทึก log แล้วหยุด
• ล้มเหลวด้วยเหตุผลอื่น (auth error, ข้อมูลขาดหาย, timeout) นั่นคือ repro ที่พัง ไม่ใช่บั๊กที่ยืนยันแล้ว หยุดเลย

มีแค่กรณีแรกที่ปลดล็อกการแก้ไข นั่นคือความหมายจริงของคำว่า “เงียบๆ”: อีกสองกรณีจะสร้างแค่ log entry สำหรับคนที่ตรวจ queue ไม่ใช่ข้อความในแชทของผู้ใช้

เขียน repro เป็น API test ไม่ใช่ unit test: เอเจนต์จะยิงไปที่ interface เดียวกับที่ผู้ใช้ใช้ ทำให้รีโปรดิวส์บั๊กอื่นขึ้นมาโดยบังเอิญไม่ได้

ขั้นตอนที่ 3: แก้โค้ดบน branch ที่แยกออกมา

เมื่อ repro ขึ้นสถานะแดงแล้ว worker จะได้สำเนาโค้ดของตัวเอง git worktree คือทางเลือกที่เบาที่สุด: working directory ที่สองบน branch ใหม่ ทำให้การแก้ไขของเอเจนต์ไม่แตะ checkout ของคุณเลย รัน service จากมัน แล้วชี้ test environment ไปที่นั่น

ให้ยึดข้อจำกัดสองข้อไว้แน่นหนา Fix ต้องเล็ก: ตั้งลิมิต เช่น 3 ไฟล์หรือ 50 บรรทัดที่เปลี่ยน และถือว่าอะไรที่ใหญ่กว่านั้นคือรายงานส่งต่อให้มนุษย์ และต้องเป้าหมายที่ repro เท่านั้น: ห้าม refactor เปลี่ยนชื่อ หรือจัดระเบียบโค้ด เพราะการเปลี่ยนแปลงเพิ่มทุกอย่างคือสิ่งที่ reviewer ต้องตรวจเพิ่ม

ขั้นตอนที่ 4: รัน repro และชุดเทสต์ทั้งหมดซ้ำ

ประตูตรวจสอบที่สองมีสองส่วน ประการแรก เอเจนต์รัน test case เดิมจากขั้นตอนที่ 2 ซ้ำโดยไม่แก้ไข และมันต้องผ่าน ถ้าเอเจนต์แก้ assertion เพื่อให้ผ่าน fix นั้นถือว่าล้มเหลว pipeline ของคุณจะจับจุดนี้ได้ด้วยการ diff ไฟล์เทสต์ก่อนและหลัง

ประการที่สอง ชุดเทสต์เดิมต้องยังเขียวอยู่ Fix ที่ทำให้หนึ่งเทสต์เขียวแต่สามเทสต์แดง ต้องกลับไปขั้นตอนที่ 3 กำหนดเวลาจำกัดของลูปนี้ เช่น 3 ครั้งหรือ 20 นาที แล้วหยุดและบันทึกว่าลองอะไรไปแล้ว นี่คือจุดที่ watchdog พิสูจน์คุณค่า: มันสามารถฆ่า worker ที่แก้บรรทัดเดิมซ้ำๆ หรือหลงไปแก้ไฟล์ที่ repro ไม่เคยแตะ

ขั้นตอนที่ 5: ส่งมอบเฉพาะ fix ที่ยืนยันแล้วและเรียบง่าย

เมื่อทั้งสองประตูเขียวขจี เอเจนต์จะเปิด pull request พร้อมหลักฐาน ไม่ใช่เรื่องเล่า: รายงาน, ผลรันที่ล้มเหลว, diff และผลรันที่ผ่านพร้อมผลชุดเทสต์ มนุษย์จะเป็นผู้รีวิวและ merge Protected branches ทำให้ token ของเอเจนต์ push branch ได้แต่ merge เข้า main ไม่ได้เด็ดขาด ถ้าประตูใดล้มเหลว ผู้รายงานจะไม่ได้ยินอะไรเลย เอเจนต์เขียน log หนึ่งบรรทัดแล้วไปต่อ

แนวรั้วความปลอดภัยสำหรับเอเจนต์ AI ที่แก้บั๊กเองได้

ตั้งรั้วเหล่านี้ก่อนรันแบบไม่มีคนดูแลครั้งแรก:

Credentials สำคัญที่สุด: repro จะยิง API จริง ดังนั้นให้ใช้ staging หรือข้อมูล local ที่ seed ไว้

ให้ coding agent ของคุณสร้าง repro ด้วย Apidog CLI

ขั้นตอนที่ 2 คือหัวใจของ pipeline และก็คือสิ่งที่ Apidog CLI ถูกสร้างมาเพื่อ coding agent ของคุณ (Claude Code, Codex, Cursor หรือ OpenCode) จะเขียน test case เป็น JSON สร้างมันใน Apidog project ของคุณและรันจาก terminal ส่วนคุณเขียน prompt เดียวเท่านั้น

ตั้งค่าครั้งเดียว:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

แล้วส่งรายงานบั๊กและ prompt นี้ให้เอเจนต์ของคุณ:

Here is a bug report for POST /orders in Apidog project <projectId>.
Turn it into an Apidog test case that fails today: assert status 201
and that $.id exists. Run it against staging and confirm it fails for
the reported reason. If it does, fix the handler on a new worktree
branch until the same test passes, run the endpoint's other cases, and
open a PR with both JSON reports. If it doesn't reproduce, stop and log why.

เอเจนต์ไม่ได้สร้าง payload จากความจำ มันจะอ่าน schema ค้นหาหมวดหมู่ validate ไฟล์ของตัวเอง แล้วจึงสร้าง case:

apidog cli-schema get test-case-create
apidog test-case category --project <projectId>
apidog cli-schema validate test-case-create --file repro-orders.json
apidog test-case create --project <projectId> --file repro-orders.json

ไฟล์ที่มันเขียนจะหน้าตาแบบนี้ (ID มาจาก project ของคุณ):

{
  "name": "Repro: POST /orders with null coupon returns 500",
  "apiDetailId": 123456,
  "categoryId": 1,
  "method": "post",
  "path": "/orders",
  "parameters": {},
  "commonParameters": {},
  "requestBody": {
    "type": "application/json",
    "data": "{\"items\":[{\"sku\":\"A-100\",\"qty\":1}],\"coupon\":null}"
  },
  "postProcessors": [
    { "type": "assertion", "defaultEnable": true, "enable": true,
      "data": { "name": "status is 201", "subject": "httpCode", "comparison": "equal", "path": "", "value": "201" } },
    { "type": "assertion", "defaultEnable": true, "enable": true,
      "data": { "name": "order id exists", "subject": "responseJson", "comparison": "exists", "path": "$.id" } }
  ]
}

จากนั้นคือการรันแบบแดงที่พิสูจน์ว่ามีบั๊ก:

apidog run --test-case <caseId> --project <projectId> -e <stagingEnvId> -r cli,json --out-file repro-before

CLI reporter จะแสดง assertion ของ status ล้มเหลวบน 500 และ repro-before.json จะถูกเก็บไว้ใน apidog-reports/ หลังจากแก้แล้ว เอเจนต์รันคำสั่งเดิมเป๊ะด้วย --out-file repro-after และทั้งสอง assertion จะผ่าน ไฟล์สองตัวนี้คือหลักฐานใน pull request สำหรับขั้นตอนที่ 4 มันจะรันทุก case บน endpoint นั้นเพื่อให้ fix ไม่ทำเพื่อนบ้านพังไปเงียบๆ:

apidog test-case run --project <projectId> --endpoint <endpointId> -e <stagingEnvId> -r cli,json

เพิ่ม --upload-report เพื่อแสดงผลรันในแอป Apidog หลัง merge แล้ว repro case จะยังอยู่ใน project ของคุณในฐานะ regression test และคำสั่ง apidog run เดิมด้วย -r junit ก็ลงไปใน CI ได้เลย ตามที่แสดงใน การรัน Apidog CLI ใน CI/CD pipeline สำหรับการตั้งค่าเพิ่มเติม ดู Apidog CLI agent workflow และ Apidog CLI ใน Claude Code Apidog Free รองรับผู้ใช้ได้ถึง 4 คน คุณจึงลองวนทั้งลูปนี้ได้โดยไม่ต้องจ่ายเงิน

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

เอเจนต์ AI แก้บั๊กได้จริงโดยไม่ต้องมีมนุษย์หรือ?

มันสามารถรีโปรดิวส์ แพตช์ และพิสูจน์บั๊กง่ายๆ จำนวนมากได้ด้วยตัวเอง แต่ไม่ควร merge เอง ให้มนุษย์เป็นคน merge เสมอ และใช้ branch protection บังคับให้เป็นเช่นนั้น

จะทำอย่างไรถ้าเอเจนต์รีโปรดิวส์บั๊กไม่ได้?

มันจะหยุดและบันทึกว่าลองอะไรไปแล้ว บั๊กที่รีโปรดิวส์ไม่ได้คือ fix ที่ยืนยันไม่ได้ การแพตช์ใดๆ จึงเป็นแค่การเดา จากนั้นมนุษย์จะเพิ่มรายละเอียดให้รายงานหรือปิดมัน

จะป้องกันเอเจนต์ไม่ให้แก้เทสต์เพื่อให้ผ่านได้อย่างไร?

เก็บสำเนาหรือ hash ของ test case ตอนที่มันล้มเหลวครั้งแรก แล้วเทียบกันก่อนยอมรับ fix เก็บไฟล์เทสต์ไว้นอกพาธที่ worker มีสิทธิ์แก้

ต้องมี DeepSeek Harness เพื่อสร้างสิ่งนี้หรือ?

ไม่จำเป็น บทความอธิบายเพียงการออกแบบ และ prototype plugin ของมันไม่ใช่ผลิตภัณฑ์ทางการของ DeepSeek coding agent ตัวไหนที่รัน shell commands ได้ก็ใช้ได้หมด รวมถึง Claude Code ใน GitHub Actions ดู DeepSeek Harness คืออะไร ถ้าอยากลองใช้บนมัน