บทที่ 17 · มุมมองมืออาชีพ · The Cockpit & the Fleet

Cockpit & Fleet — มืออาชีพสร้าง agent ที่ดีอย่างไร

ผู้ช่วยจัดการแล็บเป็นแค่ หนึ่งใน fleet — มีที่ปรึกษานักศึกษา, OBE/หลักสูตร, ฟีดแบ็กงาน — ทั้งหมดอยู่บน harness ร่วมกัน และมี cockpit (แผงควบคุมที่กำกับทุก agent โดย ไม่ใช้ AI เลย) บทเรียนมืออาชีพ: “ดี” = เลือก tradeoff ให้เหมาะบริบท ไม่ใช่ทำครบทุกมิติ

พูดแบบเข้าใจง่าย

harness คือ ชั้นการให้เหตุผลที่ยึดทับ fleet ของแอป deterministic ที่มีอยู่แล้ว — ไม่ใช่ตัวแทนที่ แต่ละแอปทำงานได้โดยไม่มี LLM (เป็นแหล่งความจริง เป็นผู้เขียนเพียงผู้เดียว) harness เติมเข้าไปแค่ 4 อย่าง: ลูป · context ที่จำกัดขอบเขต · memory เบา ๆ · การ verify → ได้ agent ที่ ให้คำแนะนำ อ่านเป็นหลัก มีคนอยู่ในลูป ที่ “ร่างให้” ในขณะที่มนุษย์เป็นคน “ลงมือ” ในแอป

และ cockpit ที่เติม “ศูนย์ LLM” แต่กลับสำคัญที่สุด — มัน คัด manifest (ลูกบิดพฤติกรรมของ fleet), อนุมัติ การเขียนที่ย้อนไม่ได้, มองเห็น trace, และ กำกับ+ประเมิน ทั้งหมดนี้คือ control plane ที่ไม่มี AI สักตัว

หัวใจของ Part 5: พอเอาดีไซน์ไปยึดกับโค้ดจริง ผลพลิก — ของที่ถูกเสนอว่าเป็น “งานของ agent” มีเพียง ~3–4 อย่างที่ LLM คุ้มจริง ราว 70% คือ SQL view, dashboard, tool federation ตายตัว หรือ report จาก template LLM คุ้มเฉพาะ การสังเคราะห์ / สร้างภาษา / ตัดสินเชิงคุณภาพเหนือข้อความอิสระ — และพิสูจน์ขั้น deterministic ก่อนเสมอ

ในระบบของเรา — 5 ระบบ: LLM คุ้มตรงไหน อะไรอยู่ deterministic

ระบบ	LLM คุ้มจริง	อยู่ deterministic
1 · แล็บ & อาคาร	ร่าง SAR ภาษาไทยสำหรับ ABET + จัดอันดับช่องว่าง	หาช่วงห้องว่าง = เลขคณิตเซ็ต → code tool
2 · ที่ปรึกษานักศึกษา	สังเคราะห์ข้ามจอ + “ทำไม PLO5 ต่ำ”	GPA/หน่วยกิตที่ตัววางแผนคำนวณอยู่แล้ว (agent อ่าน ไม่คำนวณใหม่)
3 · หลักสูตร/OBE	อ่าน Bloom ของ free-text CLO/LLO + ร่าง TQF3 (มี gate)	ตัวเลข attainment/alignment = SQL views
4 · ฟีดแบ็กงาน	สังเคราะห์ “ติดขัดหรือช้า” + ร่างคอมเมนต์	สถานะ monitor, CSV, รายการคำถาม = SQL ล้วน
5 · cockpit	ไม่มี — ศูนย์ LLM	ทั้ง control plane

วินัยสำคัญ: ทันทีที่มีคนเสนอ “LLM auto-approver” หรือ “สรุป trace ด้วย AI” ใน cockpit — cockpit ก็กลายเป็น agent ตัวที่สองที่ไม่มีใครกำกับบนเส้นทางการเขียน ซึ่งต้องห้าม สิ่งที่ควรสร้างจริงคือ คิวอนุมัติแบบอ่านอย่างเดียว ที่รวม gate การปล่อยเกรด/ส่ง TQF3/sync ไว้ที่เดียว — เพิ่มศูนย์ LLM เพิ่มศูนย์อำนาจ

ทำพลาด vs ทำถูก

⚠️ แย่ · ใส่ LLM ลงใน cockpit

auto-approver / trace summarizer

พอให้ AI “อนุมัติแทน” หรือ “สรุป trace” cockpit ก็กลายเป็น agent ตัวที่สองบนเส้นทางการเขียนที่ไม่มีใครกำกับ — ผิดหลักการพื้นฐาน: agent ไม่เขียนระบบที่เป็นแหล่งความจริง

⚠️ แย่ · harness ที่ไม่มีใครเรียกใช้

over-engineering ที่แพงที่สุด

สร้างชั้น LLM หรู ๆ ที่ผู้ใช้จริงไม่เคยกด — เผาเวลาและความเชื่อมั่นไปกับของที่ query ทำแทนได้

✅ ดี · ขั้น deterministic ก่อน แล้วเติม LLM เฉพาะจุด

cockpit ศูนย์ LLM + advisory agent

ส่ง view/tool ตายตัวก่อน เฝ้าดู trace สักเทอม แล้วค่อยเติม LLM เฉพาะจุดที่คน ชนกำแพงที่ query ทำไม่ได้ซ้ำ ๆ agent เป็นที่ปรึกษา อ่านเป็นหลัก คนเป็นผู้ลงมือ

ลองเอง — LLM คุ้มตรงไหนใน fleet

กิจกรรม · คลิกจัดลงถัง

Where does the LLM earn it?

จัดความสามารถจริงจาก 5 ระบบลง “LLM คุ้มจริง” หรือ “ปล่อยให้เป็น deterministic” แล้วดูว่าทำไมราว 70% ไม่ใช่งานของ agent

คลิกเลือกการ์ด แล้วคลิกถัง → ตรวจ

Fleet Scorecard ที่ซื่อสัตย์

รวมคะแนนจากทุกบท นี่คือ “ลายเซ็น” ของระบบเรา — และมันไม่ได้เก่งทุกด้าน (และนั่นโอเค):

มิติ	fleet ของเรา
การคัดสรร tool / permissions	✅ แข็งมาก
grounding / verify จากของจริง	✅ แข็ง
security (ลด trifecta)	✅ ดี (แต่ยังตัดไม่ครบ)
เลือกขั้นบันได (ไม่ over-engineer)	✅ แข็ง
observability	⚠️ อ่อน (log แบน)
agent evaluation	⚠️ อ่อน (ยังไม่มี)

🗂️ อยากเห็นคอลัมน์นี้ แยกราย 5 ระบบ (พร้อมสเก็ตช์ harness ของแต่ละตัว) — ดูที่ Fleet Gallery หน้าสรุปรวมท้ายคอร์ส

“ดี” ไม่ใช่การ max ทุกมิติ — ระบบที่ออกแบบดีเลือก tradeoff ให้เหมาะกับบริบท (ผู้ดูแลคนเดียว, อ่านเป็นหลัก, ความเสี่ยงต่ำ-กลาง) จุดอ่อน observability/evals เป็นสิ่งที่เรา ค้นพบอย่างซื่อสัตย์ ไม่ใช่ปกปิด — และเป็นรายการถัดไปที่ควรลงมือ

มองไปข้างหน้า — เมื่อ “มือ” ออกจากจอ ทั้งหมดนี้คือ fleet วันนี้ที่ “มือ” ยังเป็นซอฟต์แวร์ ส่วนที่ 6 มองพรมแดนถัดไป: เมื่อมือกลายเป็นหุ่นยนต์จริง และ ความสัมพันธ์ระหว่างคนกับ agent ที่ต้องปรับให้พอดี

สรุปบทที่ 17

harness = ชั้นเหตุผลที่ ยึดทับ fleet ของแอป deterministic ไม่ใช่ตัวแทนที่ — เติมแค่ 4 อย่าง (ลูป·context·memory·verify)
~70% ของ “งาน agent” จริง ๆ ไม่ใช่ agent — LLM คุ้มเฉพาะสังเคราะห์/ภาษา/ตัดสินเชิงคุณภาพ
cockpit = control plane ศูนย์ LLM ที่ load-bearing ที่สุด — อย่าใส่ AI ลงไป
“ดี” = เลือก tradeoff ให้เหมาะบริบท — ระบบเราแข็งเรื่องคัดสรร/grounding/security อ่อนเรื่อง observability/evals

📋 build-your-harness checklist · บรรทัดที่ 16 “วาง harness เป็นชั้น advisory บน fleet ที่มีอยู่ · cockpit ศูนย์ LLM เป็นคนคัด/อนุมัติ/มองเห็น/กำกับ · เลือก tradeoff ให้เหมาะบริบท”