สรุปรวม · The Fleet at a Glance

Fleet Gallery — 5 ระบบบน harness เดียวกัน เทียบกันทีละมิติ

ตลอดคอร์สเราสะสม Harness Scorecard ทีละมิติ และพบ fleet ของ 5 ระบบจริงทีละบท แต่ยังไม่เคยเห็นมัน วางเรียงกันทั้งหมดในที่เดียว หน้านี้คือภาพรวมนั้น — สเก็ตช์ harness ของแต่ละระบบ และ scorecard 5 ระบบ × 6 มิติ เพื่อให้เห็นบทเรียนมืออาชีพชัด ๆ ด้วยตา: “ดี” = เลือก tradeoff ถูก ไม่ใช่ max ทุกมิติ

นี่คือ payoff ที่ประกอบจากของเดิม ไม่ใช่ของใหม่ ทุกค่าด้านล่างมาจากบทที่ผ่านมา (โดยเฉพาะ บท 17 ที่ให้ภาพรวมแบบ aggregate) — หน้านี้แค่ กางออกเป็นรายระบบ เพื่อให้เปรียบเทียบกันได้ · ตัวอย่าง capstone ที่ทำเสร็จของระบบ “ฟีดแบ็กงาน” ดูได้ที่ บท 20

fabric ที่ทั้ง fleet ใช้ร่วมกัน

ห้าระบบไม่ได้ต่างคนต่างสร้าง harness — มันแชร์ โครงร่วมชุดเดียว ความเหมือนหลายช่องในตารางข้างล่างจึงเป็น เพราะมิตินั้นเป็น คุณสมบัติของ fabric ร่วม ไม่ใช่ของแต่ละระบบ:

ประตูเดียวMCP gateway + manifest คัดสรร (ลูกบิดพฤติกรรม)
→
เครื่องยนต์เดียวorchestrator ตัวเดียว (เดสก์ท็อป + LINE)
→
แหล่งความจริงเดียวPostgres ภายใน · agent ไม่เคยเขียนระบบที่เป็นแหล่งความจริง
→
cockpit เดียวคนคัด/อนุมัติ/มองเห็น/กำกับ — ศูนย์ LLM

สเก็ตช์ harness ของแต่ละระบบ

หนึ่งการ์ดต่อหนึ่งระบบ — อ่านได้ใน 10 วินาที: อยู่ขั้นไหนของบันได · LLM คุ้มตรงไหน · อะไรอยู่ deterministic · คนกั้นตรงไหน

ระบบ 1 · แล็บ & อาคาร
ที่ปรึกษา ABET + หาห้องว่าง
บันได: ส่วนใหญ่ขั้น 0 — หาช่วงห้องว่าง = เลขคณิตเซ็ต (tool ตายตัว); LLM 1 loop เฉพาะงานร่าง
LLM คุ้ม: ร่างเรื่องเล่าหลักฐาน ABET ภาษาไทย + จัดอันดับช่องว่างก่อนตรวจเยี่ยม
deterministic: หาห้องว่าง (ความจุ/ชนคาบ/วันหยุด) + การจองค้ำด้วยกติกา “ห้ามทับ” ของฐานข้อมูล
คนกั้น: agent ร่าง + ยื่นลิงก์ให้คลิก · คนเป็นคนจอง/ยืนยัน
ระบบ 2 · ที่ปรึกษานักศึกษา
วิเคราะห์ความก้าวหน้าสู่จบ
บันได: ขั้นต่ำ — รายการ tool แบน ~6 ตัว ไม่มี planner-head
LLM คุ้ม: สังเคราะห์ข้ามจอ + เทรซ “ทำไม PLO5 ต่ำ” + ร้อยเป็นคำแนะนำภาษาไทย
deterministic: GPAX/หน่วยกิต + การแยก GPA-vs-เครดิตที่ตัววางแผนคำนวณอยู่แล้ว (agent อ่าน ไม่คำนวณใหม่) · นับ cohort = SQL
คนกั้น: อ่านอย่างเดียว ไม่มี write · กำแพง “รายคน ↔ ภาพรวม cohort” แข็ง (ไม่ไล่ชื่อรายคน)
ระบบ 3 · หลักสูตร / OBE
จัดแนว CLO→PLO + ร่าง TQF3
บันได: หนักสุด — ~70% ควรเป็น SQL views (ที่ยัง “ไม่ได้สร้าง”); LLM เฉพาะอ่าน Bloom + ร่าง
LLM คุ้ม: อ่านระดับ Bloom ของ CLO/LLO ที่เป็น free-text + ร่างการจัดแนว + เสนอแก้ TQF3 ขั้นต่ำ
deterministic: ตัวเลข attainment/alignment = SQL views
คนกั้น: เป็น integration เดียวใน fleet ที่ “เขียนออก” จริง (ส่ง TQF3) → ทุก write คนต้องกด, one-shot one-OK
⚠️ ระวัง: ชั้นคะแนนจริงยัง “ว่าง” — ห้ามให้เล่า attainment จากข้อมูลที่ไม่มี (จะแต่งตัวเลข)
ระบบ 4 · ฟีดแบ็กงาน
อ่านงานแล็บ: ติดจริง vs แค่ช้า
บันได: ขั้นต่ำ — เรียกครั้งเดียวตามสั่ง; มอนิเตอร์/คะแนน/CSV/รายการคำถาม = SQL ล้วน
LLM คุ้ม: แยก “ติดจริง (งานสับสน) vs แค่ช้า (งานถูก)” จากเนื้องาน + ร่างคอมเมนต์เชิงกระบวนการ
deterministic: สถานะการ์ดสี/สาย/คะแนน/CSV/รายการคำถามนิรนาม
คนกั้น: อ่านอย่างเดียว · คอมเมนต์เขียนผ่านระบบเดิมหลังอาจารย์อนุมัติ · ไม่มีให้คะแนน/ติดธง · คำถามถอดชื่อ
ระบบ 5 · cockpit (แผงควบคุม)
control plane ของทั้ง fleet
บันได: ศูนย์ LLM — ทั้ง control plane เป็น deterministic
LLM คุ้ม: ไม่มีเลย (และต้องไม่ใส่)
deterministic: ทั้งหมด — คัด manifest · อนุมัติการเขียนที่ย้อนไม่ได้ · มองเห็น trace · กำกับ
คนกั้น: cockpit คือ ด่านคนของทั้ง fleet — “เติมศูนย์ LLM แต่ load-bearing ที่สุด”

Harness Scorecard — 5 ระบบ × 6 มิติ

นี่คือ scorecard ที่คอร์สสะสมมา กางเต็มทั้ง fleet · อ่านสัญลักษณ์: ✅ แข็ง · ◐ พอใช้/มีเงื่อนไข · ⚠️ อ่อน-ต้องระวัง · — ไม่เกี่ยว (n/a)

ระบบ คัดสรร tool / permissions grounding / verify security (ลด trifecta) เลือกขั้นบันได observability agent eval
1 · แล็บ & อาคาร ✅ ✅ โค้ดคำนวณ + อ้างหลักฐาน ◐ notes จริง แต่ตัด exfil แล้ว ✅ ⚠️ ⚠️
2 · ที่ปรึกษานักศึกษา ✅ ✅ ดึงสดทุกเทิร์น ไม่เดาเกรด ✅ ตัด 2 ขา ✅ ⚠️ ⚠️ ออกแบบไว้มากสุด ยังไม่ครบ
3 · หลักสูตร / OBE ✅ ◐ วินัยดี แต่ชั้นคะแนนว่าง ⚠️ มี write จริง + เอกสารแนบภายนอก ไม่น่าเชื่อถือ ◐ ~70% ควรเป็น views ที่ยังไม่สร้าง ⚠️ ⚠️
4 · ฟีดแบ็กงาน ✅ ✅ อ้างเนื้องาน · ตอบ “ไม่มีรูปแบบ” ได้ ◐ free-text จากนักศึกษา ไม่น่าเชื่อถือ · ตัด exfil · ถอดชื่อ ✅ ⚠️ ◐ fixture (เมล็ดพันธุ์) + แผนใช้อัตรา approve/edit — ยังไม่ใช่ eval เต็ม
5 · cockpit ✅✅ เป็นชั้นคัดเอง — ✅ เป็นด่านอนุมัติ ✅✅ ศูนย์ LLM = restraint สูงสุด ◐ มี trace แต่ log ยังแบน —

อ่าน scorecard นี้ยังไง — บทเรียนมืออาชีพ

ลองกวาดตาตามแนวตั้งและแนวนอน คุณจะเห็น 3 อย่างที่ตัวเลขเดี่ยว ๆ บอกไม่ได้:

✅ แข็งเหมือนกันทั้ง fleet
คัดสรร · grounding · restraint
คอลัมน์ “คัดสรร tool/permissions” และ “เลือกขั้นบันได” เขียวเกือบหมด เพราะมาจาก fabric ร่วม (manifest คัดสรร + วินัย deny-by-default + อ่านเป็นหลัก) — นี่คือ ลายเซ็นความแข็งของระบบเรา
⚠️ อ่อนเหมือนกันทั้ง fleet
observability & agent eval
สองคอลัมน์ขวาสุดแดง/เหลืองเกือบทั้งแถว — log ยัง “แบน” (ไม่มี span/parent/intent) และ ยังไม่มี agent eval จริง · นี่คือจุดอ่อนที่เรา ค้นพบอย่างซื่อสัตย์ ไม่ใช่ปกปิด และคือ “งานถัดไป”
◐ ที่ต่างกันจริง = ที่ต้องโฟกัส
ระบบ 3 (OBE) คือตัวที่หนักสุด
OBE เป็นระบบเดียวที่ เขียนออกจริง (เสี่ยง security สูงสุด), ชั้นคะแนนยังว่าง (grounding ติดล็อก) และ ~70% ควรเป็น views ที่ยังไม่ได้สร้าง (บันไดหนัก) — scorecard ชี้ชัดว่าควรลงแรงตรงไหนก่อน
หัวใจของหน้านี้ ระบบที่ออกแบบ “ดี” ที่สุดใน fleet คือ cockpit ที่ใส่ศูนย์ LLM — มันชนะเพราะ เลือกไม่ใช้ AI ในที่ที่ AI ไม่คุ้ม ไม่ใช่เพราะทำครบทุกมิติ · “ดี” จึงแปลว่า เลือก tradeoff ให้เหมาะบริบท (ผู้ดูแลคนเดียว · อ่านเป็นหลัก · ความเสี่ยงต่ำ-กลาง) ไม่ใช่ไล่ทำทุกช่องให้เขียว

สรุป Fleet Gallery

← ก่อนหน้า
20 — Capstone
หมายเหตุข้อมูล: สเก็ตช์และ scorecard สรุปจากดีไซน์ Part V ที่ยึดกับซอร์สจริงของระบบเรา (ผ่านการตรวจเชิงปฏิปักษ์) เล่าเป็น พฤติกรรม/การไหล ตามหลักของคอร์ส — ไม่มีโค้ด/พาธ · สัญลักษณ์ ✅/◐/⚠️ เป็นการประเมินเชิงออกแบบ ไม่ใช่ตัวเลขที่วัดเป๊ะ · ตัวเลข “~70%” เป็นข้อสรุปเชิงออกแบบ