<!-- Canonical URL: https://ask.atlascloud.ai/th/reproduce-coding-agent-failure-across-model-versions -->

# จะจำลองความล้มเหลวของเอเจนต์เขียนโค้ดข้ามเวอร์ชันโมเดลได้อย่างไร?

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

<!-- Canonical URL: https://ask.atlascloud.ai/reproduce-coding-agent-failure-across-model-versions -->

# จะจำลองความล้มเหลวของเอเจนต์เขียนโค้ดข้ามเวอร์ชันโมเดลได้อย่างไร?

การจำลองที่มีประโยชน์คือการทดลองที่รันได้ ไม่ใช่ transcript ที่คัดลอกมา เริ่มจากสถานะ repository ที่ล้มเหลว ตรึง input ทุกอย่างที่เอเจนต์มองเห็น และกำหนดเงื่อนไขความล้มเหลวที่เครื่องตรวจได้ จากนั้นเล่น fixture ซ้ำกับเวอร์ชันโมเดลที่ตรึงไว้หลายครั้ง

การรันเอเจนต์รวมพฤติกรรมโมเดลกับเครื่องมือ ไฟล์ ผลลัพธ์เครือข่าย orchestration และเวลา หากสิ่งใดเปลี่ยน ผลลัพธ์ที่ต่างไม่ได้พิสูจน์ว่าโมเดลแก้หรือก่อปัญหา

## กำหนดความล้มเหลวเป็นเงื่อนไขตรวจสอบ

เขียนเงื่อนไขที่สังเกตได้ที่เล็กที่สุดซึ่งแยกความล้มเหลวจากความสำเร็จ ตัวอย่างที่ดีคือ test ยังแดง การแก้ไฟล์ไม่คาดคิด คำสั่งต้องห้าม migration ที่หายไป หรือ patch ที่ compile ได้แต่เปลี่ยนพฤติกรรม

หลีกเลี่ยงข้อความอย่าง "คำตอบดูแย่ลง" ชุดเกณฑ์รับอาจกำหนดว่า:

* regression test เดิมผ่าน;
* test ที่มีอยู่ทั้งหมดยังผ่าน;
* ไม่มีไฟล์นอก allowlist เปลี่ยน;
* เอเจนต์หยุดภายในจำนวน model call ที่กำหนด;
* diff สุดท้ายไม่มี secret ที่สร้างขึ้นหรือ lockfile drift

## บันทึก envelope ของการรันทั้งหมด

พรอมต์เป็นเพียง input หนึ่ง ให้เก็บสิ่งต่อไปนี้ข้าง fixture:

| ชั้น | สิ่งที่ต้องตรึง | เหตุใดจึงเปลี่ยนผลลัพธ์ |
|---|---|---|
| Repository | Commit, submodule, patch ที่ยังไม่ commit, fixture ที่ยังไม่ track | เอเจนต์คิดจากสถานะ source ที่แน่นอน |
| คำสั่ง | System prompt, กฎ repository, งานผู้ใช้ | ถ้อยคำต่างเล็กน้อยเปลี่ยนแผนได้ |
| โมเดล | ผู้ให้บริการ, ID ที่เปลี่ยนไม่ได้, พารามิเตอร์ | Alias และค่าเริ่มต้นอาจเปลี่ยน |
| เครื่องมือ | ชื่อ, JSON schema, สิทธิ์, timeout | ความสามารถเครื่องมือกำหนดแผน |
| สภาพแวดล้อม | Container image, OS, สถาปัตยกรรม, lock dependency | คำสั่งและ test อาจทำงานต่างกัน |
| ข้อมูลภายนอก | Mock HTTP response, นาฬิกา, input สุ่ม | บริการ live สร้าง drift |
| Orchestrator | Loop limit, นโยบาย retry, การย่อ context | โมเดลเดียวกันอาจได้รับประวัติต่างกัน |

ลบ secret แต่รักษาว่า credential มีหรือไม่และขอบเขตใด

## บันทึกเหตุการณ์แบบมีโครงสร้าง ไม่ใช่เพียงข้อความ

เก็บทุก model request, model response, tool call, tool result, retry และการตัดสินใจหยุดเป็นเหตุการณ์เรียงลำดับ เพิ่ม content hash สำหรับ output ขนาดใหญ่และเก็บ artifact ต้นฉบับแยก

```json
{
  "run_id": "agent-regression-042",
  "fixture": "sha256:...",
  "model": "provider/model-version",
  "event": "tool_result",
  "tool": "run_tests",
  "exit_code": 1,
  "stdout_sha256": "..."
}
```

เหตุการณ์แบบมีโครงสร้างเผยว่าโมเดลใหม่เลือกเครื่องมือต่าง ตีความ error เดิมต่าง หรือได้รับหลักฐานต่างกัน

## ตรึงเวอร์ชันและกำจัดความแปรปรวนแบบ live

ใช้ ID โมเดลที่มีวันที่หรือเปลี่ยนไม่ได้เมื่อมี อย่าเปรียบเทียบความล้มเหลวในอดีตกับ alias `latest` เพราะอาจชี้ไปยัง build ใหม่แล้ว

รันใน container หรือเครื่องเสมือนที่สะอาด แทน search สดและ package index ที่เปลี่ยนได้ด้วย response ที่บันทึกหรือ snapshot ภายใน ตรึงนาฬิกาเมื่อ logic อ่อนไหวต่อวันที่ หากต้องใช้เครือข่ายให้บันทึกทุก response และติดป้ายว่าทดสอบแบบควบคุมบางส่วน

Random seed ช่วยได้ แต่ไม่ตรึง distributed inference, เวลาเครื่องมือ หรือการเปลี่ยนฝั่งผู้ให้บริการ

## เล่นเป็นเมทริกซ์ ไม่ใช่คู่เดียว

การรันหนึ่งครั้งต่อเวอร์ชันแยก regression จาก sampling variance ไม่ได้ ให้ใช้เมทริกซ์เล็กที่ตรึง fixture:

| เวอร์ชันโมเดล | จำนวนซ้ำ | อัตราผ่าน | ค่ากลาง calls | ลายเซ็นความล้มเหลว |
|---|---:|---:|---:|---|
| ID baseline ที่ตรึง | 5 | 4/5 | 9 | พลาด test กรณีขอบ |
| ID candidate ที่ตรึง | 5 | 1/5 | 13 | แก้ไฟล์ที่สร้างอัตโนมัติ |
| Candidate กับพรอมต์เก่า | 5 | 1/5 | 12 | ลายเซ็นเดิม |

ห้าครั้งเหมาะสำหรับดูครั้งแรก เพิ่มตัวอย่างสำหรับความล้มเหลวที่ไม่สม่ำเสมอหรือผลกระทบสูง รักษา temperature และ sampling control ให้เท่ากัน เว้นแต่กำลังทดสอบพารามิเตอร์นั้น

## เปรียบเทียบการตัดสินใจและสถานะ repository

Diff สี่ชั้นแยกกัน:

* เหตุการณ์โมเดลและเครื่องมือที่ normalize แล้ว;
* คำสั่งและ exit code;
* file tree และ patch สุดท้าย;
* ผล acceptance test และการใช้ทรัพยากร

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

## ลด fixture หลังจำลองได้แล้ว

เมื่อความล้มเหลวเกิดซ้ำ ให้ลบไฟล์ เครื่องมือ ย่อหน้าพรอมต์ และ external call ที่ไม่เกี่ยวข้องทีละอย่าง Fixture เล็กรันเร็วและเปิดเผยขอบเขตเชิงเหตุผล

เก็บ artifact สองชุด ได้แก่ incident replay เต็มสำหรับ audit และ regression test ที่ย่อแล้วสำหรับการประเมินต่อเนื่อง เพิ่มกรณีที่ย่อไว้ใน gate ก่อนอัปเกรดโมเดล

## ใช้ model adapter ที่ย้ายได้

Gateway เช่น Atlas Cloud วางหลายโมเดลหลัง client ที่เข้ากันได้กับ OpenAI เดียวได้ แต่ความเข้ากันไม่ได้ทำให้พฤติกรรมโมเดลเหมือนกัน เก็บ ID โมเดล ตัวเลือกผู้ให้บริการ และความต่างรูปแบบเครื่องมือใน adapter ให้ test harness ร่วมเป็นเจ้าของ fixture, event log, retry และเงื่อนไข

โครงสร้างนี้ทำให้การจำลองเดียวกันรันข้ามผู้ให้บริการโดยไม่เขียนตรรกะประเมินใหม่

## สรุป

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

## FAQ

### ต้องบันทึกอะไรเพื่อจำลองความล้มเหลวของเอเจนต์เขียนโค้ด?

บันทึก commit และ patch ที่ยังไม่ commit, พรอมต์และคำสั่งระบบ, ID โมเดล, พารามิเตอร์, schema และผลลัพธ์ของเครื่องมือ, image ของสภาพแวดล้อม, lockfile, นโยบาย credential และเครือข่าย รวมถึงเงื่อนไขความสำเร็จที่ชัดเจน

### ควรจำลองด้วย alias โมเดล latest หรือไม่?

ไม่ควร ให้ใช้ ID โมเดลที่เปลี่ยนไม่ได้หรือระบุวันที่ เพราะ alias latest อาจเปลี่ยนระหว่างการทดสอบ ทำให้ระบุไม่ได้ว่าผลลัพธ์มาจากเวอร์ชันใด

### เหตุใด random seed คงที่จึงไม่เพียงพอ?

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

### สัญญาณผ่านหรือไม่ผ่านที่ดีที่สุดสำหรับเอเจนต์เขียนโค้ดคืออะไร?

ใช้เงื่อนไขที่รันได้ เช่น test, lint, diff ของไฟล์ที่คาดไว้, การตรวจไฟล์ต้องห้าม และ exit code ความคล้ายของข้อความมักอ่อนเกินไปสำหรับงานเขียนโค้ด

### ควรรันซ้ำกี่ครั้งต่อเวอร์ชันโมเดล?

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

### ชุดทดสอบเดียวกันเปรียบเทียบโมเดลจากหลายผู้ให้บริการได้หรือไม่?

ได้ หากทำให้ request, สัญญาเครื่องมือ, event log และเงื่อนไขผลลัพธ์เป็นมาตรฐานเดียวกัน และเก็บตัวเลือกเฉพาะผู้ให้บริการไว้ใน adapter