คุณเริ่ม coding agent สามตัวทำงานสามงาน แล้วใช้เวลายี่สิบนาทีถัดมาสลับแท็บ terminal ไปมาเพื่อหาคำตอบเพียงข้อเดียว: ตัวไหนต้องการคุณตอนนี้? ตัวหนึ่งยังทำงานอยู่ อีกตัวกำลังรอ y/n ที่คุณไม่เคยเห็น ส่วนอีกตัวออกไปแบบเขียวตั้งแต่ชั่วโมงที่แล้วและสร้างสิ่งที่ผิดพลาดไปเงียบ ๆ ไม่มีอะไรบอกคุณเรื่องพวกนั้นเลย คุณต้องไปหามันเอง
ช่องว่างตรงนี้คือสิ่งที่ observability ของ coding agent ควรจะปิดให้ได้ observability ซึ่งยืมคำมาจากวิศวกรรมระบบ หมายถึงความสามารถในการเข้าใจว่ากระบวนการที่กำลังทำงานอยู่ทำอะไรอยู่ จากสัญญาณที่มันปล่อยออกมา โดยไม่ต้องเข้าไปเกาะติดกับมันโดยตรง (OpenTelemetry มีคู่มือปูพื้นฐานที่ดี) สำหรับ coding agent มาตรฐานคือ: คุณควรตอบคำถาม "เอเจนต์แต่ละตัวกำลังทำอะไร อะไรล้มเหลว และอะไรต้องให้มนุษย์จัดการ" ได้จากมุมมองที่แชร์ร่วมกัน ไม่ใช่จากการ tail session การตั้งค่าส่วนใหญ่ทำไม่ได้ พวกมันมีสถานะอยู่ที่ไหนสักแห่ง มี log อยู่ที่ไหนสักแห่ง แล้วก็เรียกสิ่งนั้นว่า observability ซึ่งมันไม่ใช่
บทความนี้จะพาผ่านสัญญาณสามอย่างที่ coding agent ปล่อยออกมาจริง ๆ สัญญาณความล้มเหลวแบบไหนที่คุ้มค่าจะต่อ alert และจุดที่ชั้น task ที่แชร์ร่วมกันอย่าง Sharkly เปลี่ยน output ดิบให้กลายเป็นสิ่งที่คุณลงมือทำได้ Sharkly อยู่เหนือเอเจนต์ที่คุณรันอยู่แล้ว คุณมี coding agent อยู่แล้ว และประเด็นตรงนี้คือการทำให้งานของพวกมันอ่านออกเมื่อมีมากกว่าหนึ่งตัว
สถานะ log และสัญญาณความล้มเหลวเป็นสามสิ่งที่แตกต่างกัน
สามคำนี้มักถูกใช้แทนกัน และความสับสนนี้คือรากเหง้าของระบบ monitoring ที่แย่ส่วนใหญ่ พวกมันตอบคำถามคนละแบบ
สถานะคือภาพรวมของสภาวะการรัน กำลังทำงาน กำลังรอ input เสร็จแล้ว หรือล้มเหลว มันเป็นฟิลด์เดียว อ่านง่าย และบอกคุณว่าการรันอยู่ตรงไหน ไม่ใช่ทำอะไรไปแล้ว สถานะไม่ใช่ observability มันเป็นข้อเท็จจริงที่เล็กที่สุดเกี่ยวกับการรันหนึ่งครั้ง
Log คือร่องรอยการทำงานดิบ ทุกการเรียก tool ทุกการแก้ไฟล์ และทุกการตอบกลับของโมเดล เรียงตามลำดับ Log บอกคุณว่าเกิดอะไรขึ้นหลังจากที่คุณรู้แล้วว่ามีบางอย่างผิดพลาด พวกมันจำเป็นอย่างยิ่งสำหรับการวิเคราะห์ย้อนหลัง (post-mortem) และไร้ประโยชน์ในฐานะสัญญาณสด เพราะไม่มีใครนั่งดู log ห้าอันที่เลื่อนไหลพร้อมกันได้ log ไม่ใช่สัญญาณจนกว่าจะมีอะไรสักอย่างสกัดความหมายออกมาจากมัน
สัญญาณความล้มเหลวคือ alert ที่ได้มาจากการประมวลผล พวกมันคือเงื่อนไขเฉพาะที่คุ้มค่าจะรบกวนคุณ: เอเจนต์ค้าง การรันขึ้นเขียวแต่ไปผิดทาง งบประมาณหมดกลางงาน สัญญาณความล้มเหลวคือสิ่งที่คุณต้องการจริง ๆ และมันคือชั้นที่ระบบที่สร้างเองเกือบทุกแบบข้ามไป เพราะการจะได้มันมาต้องประมวลผล log ให้กลายเป็น event ไม่ใช่แค่เก็บไว้
กับดักคือการหยุดอยู่ที่สองอย่างแรก สถานะบวก log ให้ความรู้สึกเหมือน observability เพราะคุณมีสภาวะและมีบันทึก แต่คำถามเดียวที่ขยายได้ นั่นคือ "เอเจนต์ตัวไหนของฉันต้องการฉัน?" อยู่ทั้งหมดในชั้นที่สาม
สัญญาณความล้มเหลวที่สำคัญจริง ๆ
observability ของ web service เฝ้าดูการ crash และ latency แต่ coding agent ล้มเหลวต่างออกไป และความล้มเหลวที่ทำให้คุณเสียเวลาทั้งบ่ายนั้นแทบไม่เคยเป็นแบบที่โผล่มาเป็นสถานะสีแดง นี่คือสัญญาณที่คุ้มค่าจะสกัดออกมา
| สัญญาณ | ความหมาย | ทำไมสถานะและ log ถึงมองไม่เห็น |
|---|---|---|
| การค้างแบบเงียบ | เอเจนต์กำลังรอ prompt หรือ secret ที่หายไป โดยไม่ผลิต output อะไรออกมา | สถานะยังคงอ่านว่า "running" ไม่มีอะไรส่งสัญญาณขึ้นมา |
| เขียวแต่ผิด | การรันออกสำเร็จแต่ทำสิ่งที่ผิด | สถานะคือ "done" มีแค่อ่าน diff เท่านั้นที่เปิดเผยได้ |
| ข้ามการตรวจสอบ | รายงานว่าเสร็จโดยไม่รัน typecheck, test หรือ build | Log มีการละเว้นนั้นอยู่ แต่ไม่มีใครอ่าน log ที่ผ่าน |
| งบประมาณหมด | โควตาโมเดลหรือเพดานการใช้จ่ายถูกชนกลางงาน | ความล้มเหลวโผล่มาเป็นการตอบกลับที่ถูกตัดทอน ไม่ใช่ alert |
| ความขัดแย้งที่แอบซ่อน | เอเจนต์สองตัวแก้ไฟล์เดียวกันใน worktree แยกกัน | ทั้งสองการรัน "done" การชนกันรออยู่ตอน merge |
| การวนแก้ซ้ำ | เอเจนต์แก้ ย้อนกลับ แล้วแก้ไฟล์เดิมซ้ำในลูป | แต่ละขั้นตอนดูปกติดีใน log |
รูปแบบที่เหมือนกันในทั้งหกอย่าง: ความล้มเหลวมองไม่เห็นในชั้นสถานะ และถูกฝังอยู่ในชั้น log "เขียวแต่ผิด" คือสิ่งที่คนประเมินต่ำที่สุด coding agent ที่ทำงานผิดอย่างมั่นใจนั้นดูเหมือนกับตัวที่ทำได้เป๊ะทุกประการ จนกระทั่งการ review ด้วยหลักฐานระดับ taskจับได้ observability ที่รายงานแค่ exit code จะรายงานความล้มเหลวนั้นว่าเป็นความสำเร็จ
สองอย่างในนี้เป็นเชิงโครงสร้างมากกว่าเชิงพฤติกรรม ความขัดแย้งที่แอบซ่อนคือเหตุผลที่งานขนานใน repo เดียวกันต้องมีworktree ที่แยกจากกันต่อ task เพื่อให้การทับซ้อนของไฟล์โผล่มาก่อนถึงตอน merge ไม่ใช่ระหว่างนั้น งบประมาณหมดคือเหตุผลที่การติดตามการใช้จ่ายข้ามเอเจนต์ควรอยู่ในมุมมองเดียวกับสถานะ การรันที่หยุดลงเงียบ ๆ เพราะโควตาหมดคือสัญญาณความล้มเหลว ไม่ใช่งานที่เสร็จสมบูรณ์
คุณต้องการ observability มากแค่ไหน ตามขนาดทีม
คุณไม่จำเป็นต้องมีสัญญาณทั้งหกในวันแรก ปริมาณ instrumentation ที่เหมาะสมจะปรับตามจำนวนเอเจนต์ที่รัน และจำนวนคนที่ต้องเห็นพวกมัน
| การตั้งค่า | สิ่งที่ควร instrument | จุดที่พัง |
|---|---|---|
| เอเจนต์หนึ่งตัว งานหนึ่งงาน | แค่สถานะ อ่าน log ถ้ามันล้มเหลว | ไม่มีปัญหา จนกว่าคุณจะเริ่มเอเจนต์ตัวที่สอง |
| เอเจนต์เดี่ยวหลายตัว | สถานะต่อการรัน บวกสัญญาณค้างและเขียวแต่ผิด | คุณอนุมานสภาวะจากความเงียบและพลาดการค้างไป |
| ทีมเล็ก repo แชร์ร่วมกัน | สัญญาณทั้งหก บวกสภาวะการ review ในมุมมองที่แชร์กัน | monitoring ของคุณอยู่บนแล็ปท็อปเครื่องเดียวที่ไม่มีใครเห็น |
| ทีมใหญ่ขึ้น repo เยอะ | ทั้งหมดข้างต้น บวกความเป็นเจ้าของต่อการรัน งบประมาณ และ audit trail | ไม่มีใครตอบได้ว่า "ใครรันอะไร" หนึ่งสัปดาห์ให้หลัง |
พูดกันตรง ๆ: นักพัฒนาคนเดียวที่รันเอเจนต์หนึ่งตัวบนงานที่ไม่เกี่ยวข้องกัน มี observability เท่าที่ต้องการครบแล้วใน terminal เดียว สมการจะเปลี่ยนทันทีที่เอเจนต์มีจำนวนมากกว่าจอของคุณ งานรันบนเครื่องที่คุณไม่ได้นั่งอยู่ หรือมีคนอื่นที่ต้องเห็นบอร์ดเดียวกัน เกินเส้นนั้นไป ฟิลด์สถานะและโฟลเดอร์ log ก็ไม่พออีกต่อไป
เมื่อ log ดิบและ runtime เดียวก็เพียงพอ
ให้โอกาสเครื่องมือ built-in ในเวอร์ชันที่ดีที่สุดของมัน เพราะสำหรับงานหลายอย่างพวกมันชนะ Claude Code และ Codex ต่างก็เก็บ session trace ที่อ่านได้ และสำหรับเอเจนต์เดียวบนงานเดียว trace นั้นก็คือ observability ของคุณ คุณเป็นคนเริ่มมัน คุณกำลังดูมันอยู่ คุณจะอ่าน log ถ้ามันหยุด การเพิ่มชั้นการจัดการเข้าไปตรงนั้นเป็น overhead ล้วน ๆ
ใช้ output ของ runtime เองเมื่อคุณรันเอเจนต์หนึ่งหรือสองตัว บนงานที่ไม่เกี่ยวข้องกัน และไม่มีการส่งต่อให้ใครอื่น หันมาใช้ชั้น observability ที่แชร์ร่วมกันเมื่อจำนวนการรันมากเกินความสนใจของคุณ เมื่อพวกมันรันอยู่ที่ไหนสักแห่งที่คุณ tail ไม่ได้ หรือเมื่อการ review ต้องกลายเป็นกิจกรรมของทีม ไม่ใช่เรื่องส่วนตัว เคสสุดท้ายนี่แหละคือตัวฆ่าเงียบ ๆ: เอเจนต์ห้าตัวเสร็จพร้อมกันไม่ใช่ชัยชนะ ถ้าการ review diff ของพวกมันเรียงกลับเข้าเป็นคิวของคนคนเดียว เอเจนต์เร็วขึ้น แต่คุณช้าลง นั่นก็เป็นปัญหา observability เหมือนกัน และไม่มี runtime ตัวไหนแก้ได้ เพราะสัญญาณที่สำคัญ นั่นคือ "การรันนี้เสร็จแล้วและรอการ review ของคุณ" อยู่ข้ามเอเจนต์ ไม่ได้อยู่ภายในตัวใดตัวหนึ่ง
Observability เมื่อผลลัพธ์กลับสู่ Task
ชั้น task เปลี่ยนหน่วยของ observability จาก "process ใน pane" เป็น "Task ที่มีสภาวะ" นี่คือการเปลี่ยนแปลงที่ Sharkly ถูกสร้างขึ้นมารองรับ และมันตอบโจทย์สัญญาณทั้งสามพร้อมกัน
การรันของเอเจนต์แต่ละครั้งผูกกับ Task หนึ่งงาน สถานะ ความคืบหน้า อุปสรรค และผลลัพธ์จะกลับเข้าสู่ไทม์ไลน์ของ Task นั้น แทนที่จะอยู่ใน log ที่มีแค่คุณที่เห็น สัญญาณความล้มเหลวโผล่ขึ้นในที่เดียว: การรันที่ต้องการมนุษย์จะตกเข้าสู่ Inbox คำถามจึงไม่ใช่ "มีอะไรเสร็จบ้างไหม?" อีกต่อไป แต่กลายเป็น "นี่คือสิ่งที่ต้องการการตัดสินใจของฉัน" เอเจนต์ค้นคว้า ลงมือ ทดสอบ และรายงาน ส่วนคนกำหนดทิศทาง ให้อำนาจ และรับผลลัพธ์ ระบบอัตโนมัติจะหยุด ณ จุดที่ต้องใช้ดุลยพินิจของทีม
เส้นแบ่งนี้สำคัญ เพราะมันง่ายที่จะเข้าใจผิด Sharkly ไม่ได้รันเอเจนต์หรือเขียนโค้ด Claude Code, Codex และ runtime อื่น ๆ ที่คุณใช้อยู่ยังคงเป็นตัวลงมือทำ Sharkly เพิ่มชั้น task ที่แชร์ร่วมกัน, Computer, บริบท และการ review เข้าไปรอบ ๆ พวกมัน เพื่อให้บริบท ความคืบหน้า อุปสรรค ผลลัพธ์ และการ review โดยมนุษย์มองเห็นได้ตั้งแต่คำขอจนถึงการปล่อย สำหรับภาพที่สมบูรณ์ขึ้นว่าบอร์ดที่แชร์ร่วมกันนั้นควรแสดงอะไร ดูที่ แดชบอร์ดของ AI coding agent ต้องการอะไรจริง ๆ และสำหรับมุมการติดตามแบบสด ดูที่ วิธีติดตาม coding agent ที่รันแบบขนาน
ถ้าคุณอยากใช้ coding agent หลายตัวต่อไป แทนที่จะผูกกับระบบนิเวศเดียว มุมมองที่แชร์ร่วมกันและให้ความสำคัญกับสัญญาณก่อนนี่แหละคือปัญหาที่ Sharkly ถูกออกแบบมาเพื่อแก้ คุณสามารถรัน coding agent ที่มีอยู่ผ่าน Sharkly และเก็บ runtime ทุกตัวที่คุณใช้อยู่ไว้ได้
คำถามที่พบบ่อย
observability ของ coding agent เหมือนกับ logging ไหม? ไม่ Logging เก็บว่าเกิดอะไรขึ้น observability คือความสามารถในการตอบว่าเอเจนต์แต่ละตัวกำลังทำอะไร อะไรล้มเหลว และอะไรต้องการคุณ โดยไม่ต้องอ่าน log พวกนั้นทีละอัน Log เป็นเพียง input หนึ่งของ observability ไม่ใช่ทั้งหมดของมัน
สัญญาณความล้มเหลวที่สำคัญที่สุดเพียงอย่างเดียวที่ควร instrument ก่อนคืออะไร? การค้างแบบเงียบ เอเจนต์ที่อ่านว่า "running" ขณะที่มันรอ prompt ที่คุณไม่เคยเห็นไปตลอดกาล คือวิธีที่งานขนานตายเงียบ ๆ บ่อยที่สุด ทำให้การรันที่ถูกบล็อกส่งสัญญาณขึ้นมาก่อนที่คุณจะไปไล่ตามอะไรที่หรูหรากว่านั้น
ฉันได้สิ่งนี้จาก output built-in ของ coding agent ได้ไหม? สำหรับเอเจนต์ตัวเดียว ได้ session trace ของ runtime เองก็เพียงพอ output built-in ไม่มีมุมมองข้ามเอเจนต์ จึงบอกคุณไม่ได้ว่าการรันห้าครั้งนั้นตัวไหนต้องการคุณ ซึ่งก็คือคำถามที่โผล่มาเมื่อคุณขยายเกินหนึ่งตัวพอดี
