งาน AI Agent นาน ๆ ควรมีบันทึกไหม?

สิ่งที่น่ากังวลที่สุดในงาน AI ที่ใช้เวลานานไม่จำเป็นต้องเป็นความล้มเหลว แต่คือ ความเงียบ

คนอาจทำงานบ้าน ไปซื้อของ กินข้าว แล้วกลับมาเห็น AI ยังขึ้นว่า “กำลังทำงาน” ซึ่งมีได้สองกรณีที่ต่างกันมาก:

1. มันกำลังรันชุดทดสอบขนาดใหญ่อย่างจริงจัง
2. มันค้างไปหลายชั่วโมงแล้ว

ตัวหมุนโหลดแยกสองกรณีนี้ไม่ได้ และการไม่มี commit ก็ไม่ได้แปลว่าหยุด เพราะการทดสอบ การค้นคว้า การเปรียบเทียบ การสร้างผลลัพธ์ หรือการรอระบบภายนอกอาจไม่มี artefact ใหม่อยู่พักใหญ่ได้ตามปกติ ^[1]

ดังนั้น AI ที่ทำงานยาวจึงต้องมีสิ่งหนึ่งนอกจากความฉลาด นั่นคือ observability หรือความสามารถในการมองเห็นสถานะ

1. ข้อสรุป――ถ้างานอาจกินเวลานาน ควรเปิดเผยว่า “ตอนนี้อยู่ตรงไหน”

Agent ที่ทำงานยาวไม่ควรรายงานเฉพาะตอนจบ สถานะระหว่างทางก็ควรอ่านได้ ^[1]

ไม่จำเป็นต้องบอกทุกนาทีว่า “ยังมีชีวิตอยู่” แต่ควรตอบได้ว่า:

• ตอนนี้กำลังทำอะไร
• อะไรเสร็จแล้ว
• อะไรยังเหลือ
• กำลังทดสอบหรือไม่
• มี blocker หรือไม่
• ยืนยันการทำงานล่าสุดเมื่อไร
• มีการเปลี่ยนแปลงจริงล่าสุดเมื่อไร

ตัวอย่างการตั้งค่าเชิงปฏิบัติแบบหนึ่งคือ หากไม่มีผลลัพธ์ที่มองเห็นประมาณ 10 นาที ให้ update Heartbeat และถ้า Heartbeat เก่ากว่า 20 นาที ให้ตีความเป็น STALE_UNKNOWN ไม่ใช่ “หยุดแล้ว” ^[1]

ความเงียบควรหมายถึง “ยังไม่รู้” ก่อนจะหมายถึง “ล้มเหลว”

2. ทำไมดูแค่ประวัติ commit ถึงไม่พอ

Git commit เหมาะมากสำหรับเป็นหลักฐานของ การเปลี่ยนแปลงจริง แต่ไม่ดีพอถ้าจะใช้เป็นหลักฐานเดียวของ การยังทำงานอยู่ตอนนี้

Regression test หนึ่งชั่วโมงอาจทำงานปกติโดยไม่มี commit เลย ในทางกลับกัน การ commit ไฟล์ Heartbeat ไร้สาระทุก 10 นาทีทำให้ history รกโดยไม่ได้ช่วยมาก ^[1]

จึงควรแยก:

Heartbeat = สถานะปัจจุบัน Material change = หลักฐานว่า code, contract, artefact หรือการยืนยันเปลี่ยนจริง

เมื่อแยก lastHeartbeatAt กับ lastMaterialChangeAt เราจะเข้าใจสถานะแบบ “30 นาทีไม่มี commit แต่ 5 นาทีที่แล้ว Heartbeat ยังเป็น TESTING” ได้ทันที ^[1]

เป้าหมายไม่ใช่มี commit เยอะขึ้น แต่คือทำให้ความเงียบอ่านความหมายได้

3. อย่างน้อยควรบันทึกอะไรบ้าง?

สำหรับ run ยาว ข้อมูลเหล่านี้มีประโยชน์มาก ^[1]

• runId
• state: RUNNING / BLOCKED / COMPLETED / STALE_UNKNOWN เป็นต้น
• phase: READING / IMPLEMENTING / TESTING / VERIFYING เป็นต้น
• workingOn
• startedAt
• lastHeartbeatAt
• lastMaterialChangeAt
• branch / baseSha / headSha / PR
• completedMilestones / remainingMilestones
• blockers
• tests
• nextCheckpoint

เมื่อมีข้อมูลนี้ งานหกชั่วโมงจะไม่ใช่ “กล่องดำหกชั่วโมง” แต่จะอ่านได้ว่า:

IMPLEMENTING → TESTING → INTEGRATING → VERIFYING

กล่องดำที่ฉลาดมากก็ยังเป็นกล่องดำ และนานเข้า คนก็เริ่มกังวล

4. ช่วง testing ยิ่งต้องมี Heartbeat

การทดสอบนาน ๆ ดูจากข้างนอกแทบไม่ต่างจาก Agent ที่ค้าง

ก่อนเริ่มทดสอบยาว ควรบันทึก ^[1]

• phase = TESTING
• ชื่อชุดทดสอบ
• ขอบเขต
• ตัวเลขจริงอย่าง 84 / 127 หากมีจำนวนรวมตายตัว
• มี failure แล้วหรือยัง

อย่าใช้เปอร์เซ็นต์เดา ๆ เช่น “เสร็จ 82%” สำหรับงานออกแบบหรือ debugging เพราะไม่มีใครรู้จริงว่า 18% ที่เหลือคืออะไร

เปอร์เซ็นต์มีความหมายเมื่อส่วนหารตายตัวเท่านั้น:

• 84 / 127 tests
• 3 / 5 acceptance gates

“implementation เสร็จ 82%” คือเวอร์ชัน AI ของคำว่า “ใกล้ถึงแล้ว” จากคนที่อาจยังไม่ออกจากบ้าน

5. อ่านคำถาม “หยุดหรือยัง?” แบบเป็นขั้น

ตัวอย่าง policy เชิงปฏิบัติสามารถแบ่งอายุ Heartbeat ได้ดังนี้ ^[1]

อายุ Heartbeat	การตีความ
0–10 นาที	CURRENT
10–20 นาที	HEARTBEAT_OVERDUE
มากกว่า 20 นาที	STALE_UNKNOWN

STALE_UNKNOWN ไม่ใช่ FAILED

จากนั้นตรวจตามลำดับ:

1. บันทึกความคืบหน้าปัจจุบัน
2. Check / Status
3. branch / PR
4. commit ล่าสุด
5. ค่อยอนุมานเป็นอย่างสุดท้าย

ถ้า Heartbeat เก่าแต่หลังจากนั้นมี PR หรือ commit ใหม่ มักแปลว่า Agent ยังทำงานต่อ เพียงลืม update สถานะ

AI ก็มีเหตุการณ์แบบ ทำงานเสร็จแต่ลืมกรอก timesheet ได้เหมือนกัน

6. สิ่งที่ไม่ควรทำในการจัดการความคืบหน้า

อย่า commit Heartbeat-only ลง main

จะทำให้ history รก เพิ่ม conflict และอาจ trigger CI/deploy โดยไม่จำเป็น ใช้ surface ที่แก้ทับได้ เช่น Issue comment, Check, Status หรือพื้นที่ ops ที่ไม่ใช่ production ดีกว่า ^[1]

อย่าสร้าง comment ใหม่ทุก Heartbeat

หนึ่ง run ต่อหนึ่ง record ที่แก้ไขได้อ่านง่ายกว่า ถ้ามี comment ใหม่ทุก 10 นาที สุดท้ายการดูความคืบหน้าจะกลายเป็นงานโบราณคดี ^[1]

อย่าตีความความเงียบเป็น failure ทันที

ถ้าเพียง Heartbeat เก่า ให้ใช้ STALE_UNKNOWN และใช้สถานะ failure เมื่อมีหลักฐานยืนยันจริง ^[1]

อย่าเขียน secret ลง log

ห้าม API key, token, password, private URL, raw private chat, ข้อมูลส่วนบุคคล หรือไฟล์ลับ ^[1]

อย่าหยุดงานที่ปลอดภัยเพียงเพราะช่อง observability พัง

ถ้า progress API ใช้ไม่ได้ ให้ fallback ไป sink อื่น และทำงานอิสระที่ปลอดภัยต่อไป ^[1]

7. Template ใช้งานจริง

State: RUNNING
Phase: TESTING

Run ID: agent-20260916-long-task
Started: 10:00
Last heartbeat: 14:05
Last material change: 13:42

Branch: feat/long-task
Head SHA: abc1234
PR: #123

Working on:
- regression tests

Completed:
- runtime implementation
- contract update

Remaining:
- regression completion
- merge verification
- production readback

Blockers:
- none

Tests:
- 84 / 127 passed so far
- no failure observed

Next checkpoint:
- finish regression, then integration

เพียงเท่านี้ “มันหยุดหรือยัง?” ก็เปลี่ยนเป็น “โอเค กำลังทดสอบอยู่”

จุดประสงค์ของการแสดงความคืบหน้าไม่ใช่เพื่อเร่ง AI แต่เพื่อป้องกันไม่ให้คน restart, interrupt หรือส่งคำสั่งซ้ำเพราะไม่รู้สถานะ

8. สรุป――ออกแบบ “ความฉลาด” และ “การมองเห็นสถานะ” แยกจากกัน

สำหรับ AI ที่ทำงานยาว ต้องแยกให้ชัดว่า ^[1]

• ไม่มี commit ≠ หยุด
• มี Heartbeat ≠ มีความคืบหน้าจริง
• Heartbeat เก่า ≠ ล้มเหลว
• blocker หนึ่งจุด ≠ ทั้งระบบหยุด
• เงียบระหว่าง test ≠ หลับ

ถ้า AI ทำงานได้หกชั่วโมง คนไม่ควรต้องเฝ้าจอหกชั่วโมง

การออกแบบที่ดีกว่าคือ กลับมาดูเมื่อไรก็รู้ทันทีว่าตอนนี้อยู่ขั้นไหน

Agent ระยะยาวในอุดมคติไม่ใช่ Agent ที่พูดตลอดเวลา

มันทำงานเงียบ ๆ แต่พอเปิดดู เรารู้ทันทีว่ามันไปถึงไหนแล้ว

---

เอกสารอ้างอิง (1 รายการ)

1. docs/article-pipeline/agent-work-observability.md — internal operational design for long-running AI progress observability, heartbeat cadence, stale classification, testing visibility, privacy, concurrency, and terminal conditions. Updated 2026-09-15