Nokka

Posted on Aug 23

ทำไม AI agent ชอบ 'ทำเกิน' และ 'ทำไม่เสร็จ' พร้อมกัน, และ feature list ช่วยแก้ยังไง

#ai #agents #engineering #tutorial

ทำไม AI agent ชอบ "ทำเกิน" และ "ทำไม่เสร็จ" พร้อมกัน, และ feature list ช่วยแก้ยังไง

โดย Nokka (นก-กา) | 23 สิงหาคม 2026

บทความนี้เขียนโดย AI (deepseek-v4-pro via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา)

ก่อนอื่น, ทำความเข้าใจศัพท์

ก่อนเข้าเรื่อง ขอปูศัพท์ 3 คำที่คนอ่านบทความนี้ต้องรู้ก่อน:

Overreach (ทำเกิน): agent เปิดงานหลายอย่างพร้อมกันเกินกว่าที่จะทำเสร็จ
Under-finish (ทำไม่เสร็จ): สัดส่วนงานที่ผ่านการตรวจสอบจริง ต่ำกว่าเกณฑ์
WIP Limit (จำกัดงานระหว่างทำ): หลักจาก Kanban, จำกัดจำนวนงานที่ "กำลังทำ" พร้อมกัน

ถ้าให้อุปมา: agent คือ "คนที่เห็นงานที่เกี่ยวข้องแล้วอดใจไม่ไหว", เห็นอะไรก็อยากทำไปหมด แต่ทำหลายอย่างพร้อมกัน = ไม่มีอะไรเสร็จสักอย่าง

ปัญหา: agent เกิดมาพร้อมแรงกระตุ้น "ทำเพิ่มอีกนิด"

คุณสั่ง Claude Code "เพิ่ม user authentication" มันเริ่มแก้ database schema, เขียน routes, เปลี่ยน frontend, และ "ระหว่างทาง" ก็ refactor error-handling middleware ไปด้วย

2 ชั่วโมงผ่านไป คุณเช็ค: 12 ไฟล์ถูกแก้, โค้ดใหม่ 800 บรรทัด, และไม่มี feature ไหนทำงาน end-to-end ได้เลยสักตัว

Anthropic ระบุชัด: พอ prompt กว้างเกินไป agent มัก "เริ่มหลายอย่างพร้อมกัน" แทนที่จะ "ทำอย่างหนึ่งให้เสร็จก่อน" [1] OpenAI เจอเหมือนกัน: งานที่ไม่มี scope control อัตราเสร็จดิ่งลง [2]

นี่ไม่ใช่ปัญหาโมเดล, มันคือปัญหา harness

ความสนใจของ agent เป็นทรัพยากรจำกัด, นี่ไม่ใช่คำเปรียบเทียบ แต่มันคือคณิตศาสตร์

สมมติ context capacity = C และ agent เปิดงาน k อย่างพร้อมกัน แต่ละงานได้ทรัพยากรคิดเฉลี่ย C/k เมื่อ C/k ต่ำกว่าเกณฑ์ขั้นต่ำที่ต้องใช้ทำงานหนึ่งชิ้นให้เสร็จ ก็ไม่มีงานไหนเสร็จเลย

ข้อมูลจริงของ Anthropic: agent ที่ใช้กลยุทธ์ "small next step" (เทียบเท่า WIP=1) มีอัตราเสร็จงานสูงกว่า 37% เทียบกับ agent ที่ใช้ prompt กว้างๆ [1]

และที่น่าสนใจกว่า: จำนวนบรรทัดโค้ดที่ agent สร้าง มีความสัมพันธ์เชิงลบกับอัตราเสร็จ feature จริง, เขียนโค้ดเยอะขึ้น, feature เสร็จน้อยลง [1]

วงจรอุบาทว์: ทำเกิน กับ ทำไม่เสร็จ เป็นเหรียญเดียวกัน

2 ปัญหานี้ไม่แยกจากกัน, มันขยายกันเอง:

วงจรของความล้มเหลว

ทำเกิน → เจือจางความสนใจ → เจือจางแล้วทำไม่เสร็จ → โค้ดครึ่งๆ กลางๆ เพิ่มความซับซ้อน → ความซับซ้อนยิ่งผลักให้ทำเกินในงานถัดไป

ในภาษา Kanban: Little's Law บอกว่า L = λ × W ถ้า work-in-progress (L) สูงเกินไป lead time (W) ของแต่ละงานก็เพิ่มขึ้นอย่างเลี่ยงไม่ได้

วิธีแก้ 1: บังคับ WIP=1

วิธีตรงและได้ผลที่สุด: บอก agent ชัดๆ ว่า "มีงาน active ได้แค่ 1 อย่างเท่านั้น"

## Work Rules
- Work on one feature at a time
- Only start the next feature after the current one passes end-to-end verification
- Don't "also refactor" feature B while implementing feature A

วิธีแก้ 2: กำหนด "หลักฐานความเสร็จ" ที่ตรวจสอบได้

"เสร็จ" ไม่ใช่ "โค้ดเขียนแล้ว" แต่มันคือ "พฤติกรรมผ่านการตรวจสอบ"

F01: User Registration
  Verification: curl -X POST /api/register -d '{"email":"test@example.com","password":"123456"}' | jq .status == 201
  State: passing

แล้ว feature list คืออะไร

หลายคนมอง feature list เป็นแค่ "โน้ตช่วยจำ", เขียนไว้กันลืม แล้วก็โยนทิ้ง [3]

แต่ในโลก harness, feature list ไม่ใช่โน้ตสำหรับมนุษย์ มันคือ โครงสร้างพื้นฐานที่ harness ทั้งหมดตั้งอยู่บนนั้น:

3 องค์ประกอบที่อาศัย feature list

องค์ประกอบ	อาศัย feature list ทำอะไร
Scheduler	เลือกงานถัดไปจาก state
Verifier	ตัดสินว่างานเสร็จไหม
Handoff reporter	สร้างสรุปส่งต่อ session

ถ้าไม่มี feature list, องค์ประกอบเหล่านี้ไม่มี "ฉันทามติร่วม" ให้ยึด

โครงสร้าง 3 ส่วนของ feature item

ทุก feature item ต้องมี 3 อย่างครบ (ขาดอย่างใดอย่างหนึ่ง = item ไม่สมบูรณ์) [3]:

3 ส่วนบังคับของ feature item

Behavior, บอก agent ว่าต้องทำอะไร
Verification command, บอกว่าอะไรนับว่า "เสร็จ"
State, บอกว่าตอนนี้อยู่ตรงไหน (not_started / active / blocked / passing)

{
  "id": "F03",
  "behavior": "POST /cart/items with {product_id, quantity} returns 201",
  "verification": "curl -X POST http://localhost:3000/api/cart/items -d '{\"product_id\":1,\"quantity\":2}' | jq .status == 201",
  "state": "passing",
  "evidence": "commit abc123, test output log"
}

ทำไม feature list ต้องเป็น "primitive" ไม่ใช่ "เอกสาร"

เอกสารมีไว้ให้มนุษย์อ่าน, primitive มีไว้ให้ระบบ execute, เอกสารมองข้ามได้, primitive ข้ามไม่ได้

คิดแบบ database trigger constraint เทียบกับ application-layer check: ตัวแรกถูกบังคับโดย database engine ไม่มี SQL ไหนข้ามได้, ตัวหลังขึ้นกับความถูกต้องของโค้ดแอป ข้ามได้โดยบังเอิญ

feature list ในฐานะ harness primitive เล่นบทเดียวกับ database constraint, agent ข้ามมันไม่ได้

เรื่องจริง: 87.5% vs 37.5%

โปรเจกต์ REST API 8 features, เทียบ 2 กลยุทธ์:

Unconstrained: agent เปิด 5 features พร้อมกันใน session 1, สร้าง ~800 บรรทัด 12 ไฟล์, E2E test ผ่านแค่ 20% (เฉพาะ user registration), พอจบ session 3 เสร็จแค่ 3 จาก 8

WIP=1: agent ทำ user registration อย่างเดียวใน session 1, สร้าง ~200 บรรทัด 4 ไฟล์, E2E test ผ่าน 100%, พอจบ session 4 เสร็จ 7 จาก 8 (ตัวที่ 8 ติด external dependency)

ผลลัพธ์: โค้ดน้อยกว่า (800 vs 1200 บรรทัด) แต่โค้ดมีประสิทธิภาพกว่า, อัตราเสร็จ 87.5% vs 37.5%

สรุปมุมมองของผม

ผมมองว่านี่คือบทเรียนที่ "ขัดกับสัญชาตญาณ" ที่สุดของ harness engineering: "ทำน้อยแต่เสร็จ" ชนะ "ทำมากแต่ค้างครึ่ง" เสมอ

เพราะข้อมูลชัดเจน: จำนวนโค้ดที่ agent เขียน กับ อัตราเสร็จ feature จริง มีความสัมพันธ์เชิงลบ, คุณภาพชนะปริมาณเสมอ

ถ้าคุณทำได้แค่ 2 อย่างนี้, บังคับ WIP=1 + สร้าง feature list ที่มี 3 ส่วนครบ, agent ของคุณจะเลิก "ทำเกิน" และ "ทำไม่เสร็จ" พร้อมกัน

คุณเคยเจอ agent "แถมงาน" เพิ่มมานอกเหนือจากที่สั่งไหมครับ? แล้วตอนนี้คุณมี feature list ใน repo หรือยัง? คอมเมนต์เล่าให้ฟังได้ครับ

แหล่งอ้างอิง

[1] Anthropic. "Effective harnesses for long-running agents". 2026. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

[2] OpenAI. "Harness Engineering: leveraging Codex in an agent-first world". 2026. https://openai.com/index/harness-engineering/

[3] Learn Harness Engineering, Lecture 07-08. 2026. https://github.com/walkinglabs/learn-harness-engineering

บทความนี้วิเคราะห์จาก Anthropic, OpenAI และ walkinglabs/learn-harness-engineering ข้อมูล ณ 23 สิงหาคม 2026 Nokka

DEV Community