ทำไม AI agent ต้อง "มองเห็นตอนรันจริง" และ observability ต้องอยู่ใน harness ไม่ได้มีเพียงเพิ่มทีหลัง

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

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

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

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

• Observability (ความสามารถในการสังเกต): ความสามารถเข้าใจสถานะภายในของระบบ จากสัญญาณภายนอกที่มันปล่อยออกมา
• Sprint Contract (สัญญาสปรินต์): ข้อตกลงสั้นๆ ที่ตกลงกันก่อนเขียนโค้ด ระบุขอบเขตงาน เกณฑ์ตรวจสอบ และสิ่งที่ยกเว้น
• Evaluator Rubric (เกณฑ์การให้คะแนน): ตารางคะแนนที่เปลี่ยน "ดีไหม" จากความรู้สึก เป็นหลักฐานที่วัดได้

ถ้าให้อุปมา: observability คือ "กล้องวงจรปิด" ของระบบ agent, ถ้าไม่มีกล้อง เวลางานพัง คุณก็เดาเอาเองว่ามันพังตอนไหน

ปัญหา: agent ทำงาน 20 นาที แล้วตอบไม่ได้ว่า "เกิดอะไรขึ้น"

คุณสั่ง agent ทำ feature มันรัน 20 นาที, แตะไฟล์เป็นกอง, แล้วบอก "เสร็จแล้ว แต่มี test พัง 2 ตัว" คุณถามว่าทำไม, "ไม่แน่ใจ อาจเป็น timing issue" คุณถามว่ามันเปลี่ยน critical path อะไรบ้าง, "เดี๋ยวขอดูโค้ด..."

นี่ไม่ใช่ปัญหาความสามารถของ agent แต่มันคือ การขาด observability ของ harness, พอ agent ทำงานโดยมองไม่เห็นสถานะ runtime จริง ทุกการตัดสินใจของมันก็คือการเดา

ต้นทุนที่แท้จริงของการไม่มี observability (4 ด้าน)

1. แยก "ถูก" กับ "ดูเหมือนถูก" ไม่ออก

ฟังก์ชันดูถูกต้องใน code review, syntax ถูก, ตรรกะสมเหตุสมผล แต่ตอน runtime เงื่อนไข boundary case ให้ผลลัพธ์ผิดกับ input เฉพาะ

code review แสดง "เขียนอะไร", runtime tracing แสดง "รันอะไรจริง", คุณต้องมีทั้งสอง

2. การประเมินกลายเป็น "ไสยศาสตร์"

ไม่มี scoring rubric และ acceptance criteria, ผู้ประเมิน (มนุษย์หรือ agent) ต้องพึ่งสมมติฐานลอยๆ, output เดียวกันได้คะแนนต่างกันสุดขั้วจากผู้ประเมินแต่ละคน คุณภาพกลายเป็นเรื่องที่ทำซ้ำไม่ได้ [1]

3. การ retry กลายเป็น "เดาสุ่ม"

พอ agent ไม่รู้ว่าทำไมมันถึง fail, ทิศทางการ retry ก็สุ่ม, มันอาจทุบไปผิดทาง, แก้โค้ดที่ไม่เกี่ยวข้อง, มองข้าม root cause จริง, ทุก retry ที่สุ่ม เผา token และเวลา

4. หน้าผาแห่งการส่งต่อ

เมื่องานค้างถูกส่งต่อให้ session ถัดไป, การไม่มี observability หมายความว่า session ใหม่ต้องวินิจฉัยสถานะระบบจากศูนย์ Anthropic สังเกตว่า redundant diagnosis นี้กิน 30-50% ของเวลาทั้ง session [1]

ตัวอย่างจริง: dark mode ที่ใช้เวลา 3 เท่า

Harness ใช้ workflow "planner-generator-evaluator" ทำงาน "เพิ่ม dark mode ให้แอป":

ไม่มี observability: planner เขียนคำอธิบายคลุมเครือ, generator ทำตามความคลุมเครือ แต่ผลไม่ตรงกับความคาดหวังลอยๆ, evaluator reject ตามมาตรฐานลอยๆ ของตัวเอง แต่บอกไม่ได้ว่าผิดตรงไหน, แค่ "มันรู้สึกไม่ใช่" generator retry สุ่มกับเหตุผล reject ที่คลุมเครือ วน 3-4 รอบ 45 นาที ได้ผลลัพธ์ที่พอรับได้

มี observability เต็ม: planner เขียน sprint contract ระบุ component ที่ต้องแก้, เกณฑ์ตรวจสอบแต่ละตัว, และข้อยกเว้น (เช่น ไม่แตะ print style) generator ทำตาม contract, runtime observability บันทึกการโหลด style แต่ละ component, evaluator ให้คะแนนมิติต่อมิติพร้อมอ้างหลักฐานเฉพาะ: "button contrast ไม่พอ (WCAG AA 4.5:1, วัดได้ 2.1:1)" รอบเดียวได้ผลลัพธ์คุณภาพสูงใน 15 นาที

ต่างกัน 3 เท่า ตัวแปรเดียวคือ observability

Observability มี 2 ชั้น (ทั้งคู่จำเป็น)

ตามกรอบ Observability Engineering ของ Charity Majors [2]:

Runtime Observability, "ระบบทำอะไร"

สัญญาณระดับระบบ: logs, traces, process events, health checks, ตอบคำถาม "ระบบทำอะไรไป"

Process Observability, "ทำไมยอมรับการเปลี่ยนแปลงนี้"

มองเห็น artifact การตัดสินใจของ harness: plans, scoring rubrics, acceptance criteria, ตอบคำถาม "ทำไมการเปลี่ยนแปลงนี้ควรถูกยอมรับ"

ทำไม agent แก้เองไม่ได้ (แค่ให้ print log)

คุณอาจคิดว่า "ให้ agent print log เองก็จบแล้ว" แต่ปัญหา:

1. Agent ไม่รู้ว่ามันไม่รู้อะไร, มันไม่ record สัญญาณที่มันไม่รู้ตัวว่าจำเป็น
2. Format log ไม่สอดคล้อง, session ต่างใช้ format ต่าง วิเคราะห์เป็นระบบไม่ได้
3. Process observability แก้ด้วย logging ไม่ได้, sprint contract และ rubric เป็น artifact โครงสร้างที่ต้อง harness สนับสนุน

วิธีสร้าง observability (4 วิธี)

1. เก็บ runtime signal เข้า harness (ไม่พึ่ง agent print เอง)

• Application lifecycle: startup, ready, running, shutdown
• Feature path execution: entry, checkpoint, exit ของ critical path
• Data flow: ข้อมูลไหลระหว่าง component
• Resource utilization: การใช้ทรัพยากรผิดปกติ (memory โตเรื่อยๆ)
• Errors: context เต็ม ไม่ได้มีเพียง error message

2. ใช้ Sprint Contract

ก่อนเริ่มงาน generator กับ evaluator ตกลง contract กันก่อน:

# Sprint Contract: Dark Mode Support

## Scope
- Modify the theme toggle component
- Update global CSS variables
- Add dark mode tests

## Verification Standards
- Visual regression tests pass for each component
- Main flow end-to-end tests pass
- No flash of unstyled content (FOUC)

## Exclusions
- Not handling print styles
- Not handling third-party component dark mode

3. ใช้ Evaluator Rubric

เปลี่ยน "ดีไหม" เป็นคะแนนที่วัดได้:

มิติ	A	B	C	D
Code correctness	All tests pass	Main flow passes	Partial	Build fails
Architecture compliance	Fully compliant	Minor deviations	Obvious deviations	Serious violations
Test coverage	Main + edge cases	Main flow only	Only skeleton	No tests

4. ใช้ OpenTelemetry เป็นมาตรฐาน

สร้าง trace ต่อ harness session, span ต่อ task, sub-span ต่อ verification step, ข้อมูล observability จะต่อกับ toolchain มาตรฐาน (Jaeger, Zipkin) ได้ทันที [3]

ข้อมูลจริง: Three-Agent Architecture ของ Anthropic

มีนาคม 2026 Anthropic รันงาน "สร้าง browser-based DAW" ด้วย 3 agent แยกบทบาท:

Agent & Phase	เวลา	ค่าใช้จ่าย
Planner	4.7 นาที	$0.46
Build round 1	2 ชม. 7 นาที	$71.08
QA round 1	8.8 นาที	$3.24
Build round 2	1 ชม. 2 นาที	$36.89
QA round 2	6.8 นาที	$3.09
Build round 3	10.9 นาที	$5.88
QA round 3	9.6 นาที	$4.06
รวม	3 ชม. 50 นาที	$124.70

แต่ละ agent มีบทบาทชัดใน observability [1]: Planner ขยาย requirement เป็น spec, Generator ทำทีละ feature ตาม sprint contract, Evaluator ใช้ Playwright MCP คลิกทดสอบเหมือน user จริง ให้คะแนน 4 มิติ (product depth, functionality, visual design, code quality) พร้อม hard threshold

ตัวอย่าง feedback จาก QA รอบ 1: "นี่คือแอปที่สวยและมี AI integration ดี แต่ core DAW feature หลายอย่างเป็นแค่ presentation: clips ลากไม่ได้, ไม่มี instrument UI panel, ไม่มี visual effects editor", นี่ไม่ใช่ edge case แต่มันคือ interaction หลักที่ทำให้ DAW ใช้งานได้

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

ผมมองว่านี่คือ "เส้นเลือด" ของ harness engineering: ถ้ามองไม่เห็น ก็แก้ไม่ได้, ถ้าแก้ไม่ได้ ก็เดา, ถ้าเดา ก็พัง

เพราะข้อมูลชัดเจน: การไม่มี observability ทำให้แยก "ถูก" กับ "ดูเหมือนถูก" ไม่ออก, ทำให้ประเมินเป็นไสยศาสตร์, ทำให้ retry เป็นการเดาสุ่ม, และกิน 30-50% ของเวลาทั้ง session ไปกับ redundant diagnosis

ถ้าคุณทำได้แค่ 2 อย่างนี้, เก็บ runtime signal เข้า harness + ใช้ sprint contract, agent ของคุณจะเลิกทำงานแบบ "มองไม่เห็น" และเริ่มทำงานแบบ "มีหลักฐาน"

ตอนนี้คุณเห็น agent ทำงาน "แบบมองไม่เห็น" บ่อยแค่ไหนครับ? แล้วคุณมี observability ใน harness (trace, log, health check) หรือยัง? คอมเมนต์เล่าให้ฟังได้ครับ

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

[1] Anthropic. "Harness design for long-running application development". 2026. https://www.anthropic.com/engineering/harness-design-long-running-apps

[2] Majors et al. "Observability Engineering". 2022. https://www.honeycomb.io/blog/observability-engineering-book

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

---

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