AgentOps คือกรอบแนวคิด (Framework) ของ "การออกแบบองค์กรและโครงสร้างพื้นฐานการดำเนินงาน" เพื่อให้ AI Agent สามารถทำงานได้อย่างเสถียร

ในขณะที่ DevOps คือ "การดำเนินงานเพื่อปล่อยโค้ดอย่างปลอดภัย" และ MLOps คือ "กลไกการดำเนินงานโมเดลให้เสถียร" แต่ AgentOps จะจัดการเรื่อง "องค์กรและกลไกที่ดำเนินการกับ Agent หลายตัวที่ทำงานแบบอัตโนมัติอย่างต่อเนื่อง โดยเน้น 3 แกนหลัก ได้แก่ คุณภาพ ต้นทุน และการปฏิบัติตามกฎระเบียบ (Compliance)" แม้จะดูเหมือนเป็นส่วนต่อขยายของ LLMOps ที่เกิดขึ้นจากการมาถึงของ LLM แต่ทันทีที่มีเงื่อนไขว่า Agent สามารถ "เรียกใช้เครื่องมือได้ด้วยตนเอง" ขอบเขตของการออกแบบการดำเนินงานจะเปลี่ยนจากเพียงแค่ไปป์ไลน์การอนุมาน (Inference Pipeline) ไปสู่ "กระบวนการทางธุรกิจโดยตรง"

คู่มือฉบับนี้จัดทำขึ้นสำหรับผู้รับผิดชอบด้าน DX หรือฝ่ายสารสนเทศ (IT) ของบริษัทขนาดกลาง เพื่อสรุปองค์ประกอบของ AgentOps การบูรณาการเข้ากับการดำเนินงานที่มีอยู่ และขั้นตอนการนำไปใช้งาน เมื่ออ่านจบ คุณจะสามารถจัดทำตารางบทบาทหน้าที่ว่า "ใคร ทำอะไร และใช้ SLI/SLO ใดในการวัดผล" รวมถึงสามารถตัดสินใจลำดับความสำคัญเพื่อนำ Agent ในช่วงนำร่อง (Pilot) ไปสู่การใช้งานจริงได้

AgentOps หมายถึงแนวคิดและโครงสร้างพื้นฐานในการจัดการ AI Agent หลายตัวให้เป็น "ภาระงานปฏิบัติการตามมาตรฐานขององค์กร" (Organizational Operational Workloads) ซึ่งไม่ใช่เพียงแค่การนำเครื่องมือมาใช้งานเท่านั้น แต่หัวใจสำคัญคือการเตรียมความพร้อมขององค์กรผ่านการออกแบบความเป็นเจ้าของ (Ownership) ตัวชี้วัดเชิงสังเกตการณ์ (Observability) และการแทรกแซงโดยมนุษย์ (Human-in-the-loop)

ในส่วนนี้ เราจะสรุปความแตกต่างระหว่าง AgentOps กับการปฏิบัติการที่มีอยู่เดิม (DevOps / MLOps / LLMOps) รวมถึงเหตุผลที่การปฏิบัติการแบบเอเจนต์ก่อให้เกิดความท้าทายใหม่ๆ การทำความเข้าใจว่า "ต้องเพิ่มอะไรเข้าไปในการปฏิบัติการเดิมที่มีอยู่" จะเป็นจุดเริ่มต้นที่ชัดเจนในการวางแผนการนำไปใช้งานจริง

เปรียบเทียบขอบเขตความสนใจระหว่าง Ops แบบดั้งเดิมและ AgentOps ดังนี้

สิ่งที่ทำให้ AgentOps ใหม่คือการเพิ่มสมมติฐานที่ว่า "LLM สามารถเรียกใช้เครื่องมือได้โดยอัตโนมัติ" ในส่วนของ LLMOps นั้น ความสนใจหลักอยู่ที่ "คุณภาพและความเร็วของการสร้างข้อความ" แต่สำหรับเอเจนต์นั้น สามารถเขียนข้อมูลลงในฐานข้อมูลภายในบริษัท, โอนเงินผ่าน API ภายนอก หรือลบไฟล์ได้ เนื่องจาก การกระทำที่มีผลข้างเคียงเกิดขึ้นเป็นปกติ การดำเนินงานหลังการปรับใช้ (Deployment) จึงไม่เพียงพอแค่การเฝ้าระวังค่าความหน่วง (Latency) เท่านั้น

ปัจจัยกระตุ้นที่สังเกตได้สำหรับการเปลี่ยนผ่านมี 3 ประการ ได้แก่ (1) เมื่อเอเจนต์เริ่มดำเนินการที่มีผลข้างเคียงต่อ API ภายนอก (2) เมื่อมีการกำหนดค่าให้เอเจนต์หลายตัวเข้าถึงข้อมูลเดียวกันพร้อมกัน และ (3) เมื่อมี "พรอมต์ที่มาจากแหล่งข้อมูล" นอกเหนือจากอินพุตของผู้ใช้เข้ามาเกี่ยวข้อง เมื่อปัจจัยเหล่านี้ครบถ้วน การดำเนินงานในรูปแบบส่วนขยายของ LLMOps จะเริ่มล้มเหลว

คุณสมบัติการ "ตัดสินใจอย่างอิสระ" (Autonomous decision-making) ของเอเจนต์ นำมาซึ่งความท้าทายใหม่ 3 ประการในการปฏิบัติงาน:

• ความเป็นปกติของความไม่แน่นอน (Non-determinism): แม้จะเป็นอินพุตเดียวกัน แต่ลำดับหรือการเลือกใช้เครื่องมืออาจเปลี่ยนไป ทำให้ความสามารถในการทำซ้ำ (Reproducibility) ลดลง การแก้ไขบั๊กจะทำได้ยากขึ้น และจำเป็นต้องใช้วิธี "รันซ้ำ N ครั้งด้วยอินพุตเดิม" เพื่อแยกแยะสาเหตุของปัญหา
• ความยากในการคาดการณ์ความผันผวนของต้นทุน: การใช้โทเค็นต่อหนึ่งงานจะแปรผันอย่างมากตาม "จำนวนขั้นตอนการคิด" เนื่องจากต้นทุนของฟังก์ชันเดียวกันอาจพุ่งสูงขึ้นหลายเท่าตัวตามอินพุตของผู้ใช้ การบริหารงบประมาณที่ดูเพียง "ค่าเฉลี่ย" จึงมักจะล้มเหลว
• ความคลุมเครือของขอบเขตความรับผิดชอบ: หากการตัดสินใจของเอเจนต์เกิดความผิดพลาด แต่ไม่มีการกำหนดว่าใครจะเป็นผู้รับผิดชอบ (ทีมผู้ให้บริการ / แผนกที่ใช้งาน / ฝ่ายบริหาร) การแก้ไขปัญหาจะหยุดชะงักลง แม้แต่ขั้นตอนการรายงานอุบัติการณ์ก็จะต้องเริ่มจากการถกเถียงว่า "ทีมใดจะเป็นผู้เปิดเคส"

ปัญหาเหล่านี้ไม่สามารถแก้ไขได้ด้วยเครื่องมือเพียงอย่างเดียว แต่จำเป็นต้อง ใช้กฎระเบียบและบทบาทหน้าที่ขององค์กรในการรองรับ นี่คือเหตุผลที่ AgentOps ครอบคลุมถึง "การออกแบบองค์กร" หากปัญหาทั้ง 3 ประการนี้ปรากฏขึ้นในหน้างาน การกำหนดเส้นทางการยกระดับปัญหา (Escalation path) และการระบุเจ้าของความรับผิดชอบ (Owner) ให้ชัดเจนก่อนการเลือกใช้เครื่องมือ จะช่วยให้เห็นผลลัพธ์ได้รวดเร็วกว่า

การใช้งานเอเจนต์เพียง 1 ตัวต่อ 1 วัตถุประสงค์อาจใช้ภาระงานเพียงเล็กน้อย แต่ทันทีที่จำนวนเพิ่มขึ้น ภาระในการดำเนินงานจะพุ่งสูงขึ้นแบบทวีคูณ เสียงสะท้อนจากหน้างานที่ว่า "Pilot ประสบความสำเร็จ แต่ไปติดขัดตอนขยายผล" คือสิ่งที่ผลักดันให้เกิดความสนใจใน AgentOps

ในส่วนนี้ เราจะมาแยกย่อยปรากฏการณ์ "ติดขัดตอนขยายผล" และสรุปว่าเหตุใดการออกแบบการดำเนินงานแบบเดิมจึงไม่สามารถรองรับปัญหาดังกล่าวได้

ลูปของ "การคิด → การเรียกใช้เครื่องมือ → ผลลัพธ์" ซึ่งสามารถติดตามได้ในเอเจนต์เดี่ยว เมื่อมีการทำงานร่วมกันของเอเจนต์หลายตัว จะเกิด ปัญหาการดำเนินงานเฉพาะของระบบหลายเอเจนต์ (Multi-agent) ขึ้น เช่น:

• เอเจนต์ตัวไหน เรียกใช้เครื่องมืออะไร และตามลำดับใด
• เมื่อเกิดความล้มเหลวระหว่างทาง จะสามารถเริ่มดำเนินการใหม่จากจุดไหนได้อย่างปลอดภัย
• ความขัดแย้งที่เกิดขึ้นจากการทำงานพร้อมกัน (เช่น เอเจนต์ 2 ตัวอัปเดตเรกคอร์ดเดียวกัน)
• บริบทสูญหายไประหว่างการส่งต่องานระหว่างเอเจนต์หรือไม่

การที่เฟรมเวิร์กอย่าง Mastra หรือ LangGraph มุ่งไปในทิศทางของ "การอธิบายสถานะของเอเจนต์ในรูปแบบเวิร์กโฟลว์" ก็เป็นความพยายามที่จะนำความสามารถในการติดตามกลับคืนมา เพื่อป้องกันสถานะที่ "ไม่รู้ว่าเกิดอะไรขึ้น" จำเป็นต้องบันทึกอินพุต เอาต์พุต และเหตุผลในการตัดสินใจของเอเจนต์แต่ละตัวไว้ในรูปแบบล็อกที่มีโครงสร้าง และรักษาให้เวิร์กโฟลว์แต่ละหน่วยอยู่ในสถานะที่สามารถเล่นซ้ำ (Replay) ได้

การทำงานแบบอัตโนมัติโดยใช้ MCP ที่กล่าวถึงใน คู่มือการใช้งาน AI Agent ภาษาลาว ก็จะเผชิญกับปัญหาการดำเนินงานเดียวกันในขั้นตอนการนำไปใช้งานจริง แม้ว่ารูปแบบการนำไปใช้งานจะพร้อมแล้ว แต่หากโครงสร้างพื้นฐานในการดำเนินงานตามไม่ทัน ก็จะตกอยู่ในสถานการณ์ที่ "ทำงานได้ แต่หยุดไม่ได้"

สรุป 3 ฟังก์ชันที่จำเป็นสำหรับการดำเนินงาน Agent (Agent Operation)

แม้ฟังก์ชันทั้ง 3 นี้จะสามารถนำไปใช้งานแยกกันได้ แต่การออกแบบให้ อ้างอิงถึงกันและกัน จะช่วยลดภาระในการดำเนินงานได้ ตัวอย่างเช่น การตัดสินใจว่าต้องใช้ HITL หรือไม่จาก Audit Log, การบังคับใช้ HITL เมื่อค่าใช้จ่ายเกินกำหนด หรือการรวมบันทึกการอนุมัติของ HITL เข้ากับ Audit Log เป็นต้น

โดยเฉพาะอย่างยิ่งในเรื่อง Cost Management นั้น ไม่ใช่เรื่องแปลกที่ ตัวเลขขนาดเล็กที่เห็นในขั้นตอน Pilot จะพุ่งสูงขึ้นอย่างมากเมื่อนำไปใช้งานจริง (Production) ซึ่งสาเหตุหลักแบ่งออกเป็น 3 ประการ ได้แก่ (a) จำนวนผู้ใช้เพิ่มขึ้น, (b) จำนวนขั้นตอนการอนุมาน (Inference steps) ต่อหนึ่งงานเพิ่มขึ้น และ (c) Prompt มีขนาดใหญ่ขึ้นจากการทำ Long-context RAG ดังนั้น ก่อนที่จะเริ่มนำเครื่องมือมาใช้ จำเป็นต้องกำหนดหน่วยการวัดต้นทุนและเกณฑ์การแจ้งเตือน (Alert threshold) ไว้ล่วงหน้า การตกลงนโยบายการดำเนินงานไว้ก่อนว่าจะให้หยุดการทำงานของ Agent โดยอัตโนมัติ หรือเปลี่ยนไปใช้การอนุมัติผ่าน HITL เมื่อเกินเกณฑ์ที่กำหนด จะช่วยให้หน้างานตัดสินใจได้รวดเร็วยิ่งขึ้น

AgentOps ประกอบด้วย 5 องค์ประกอบ ได้แก่ (1) Agent Registry, (2) การสังเกตการณ์ (SLI/SLO และต้นทุน), (3) HITL และการยกระดับปัญหา (Escalation), (4) ลูปการประเมินผล (Evaluation Loop) และ (5) นโยบายการกำกับดูแล (Governance Policy) ในส่วนนี้จะเจาะลึก 3 องค์ประกอบแรกที่มีความสำคัญเป็นพิเศษ

ลูปการประเมินผลหมายถึง "กลไกในการวัดคุณภาพของเอเจนต์อย่างต่อเนื่อง" ส่วนนโยบายการกำกับดูแลหมายถึงกฎระเบียบที่กำหนดว่า "เอเจนต์ใดสามารถจัดการข้อมูลประเภทใดได้บ้าง" การดำเนินการในส่วนนี้จะมีประสิทธิภาพมากกว่าหากเริ่มทำหลังจากที่ 3 องค์ประกอบแรกมีความพร้อมแล้ว หากพยายามทำทั้ง 5 องค์ประกอบพร้อมกันตั้งแต่ต้น อาจทำให้โครงการนำร่องสิ้นสุดลงโดยที่รากฐานยังไม่มั่นคง

เมื่อจำนวนเอเจนต์เกิน 5 ตัวขึ้นไป จะเริ่มเกิดความไม่ชัดเจนว่า "เอเจนต์ตัวไหนอยู่ที่ไหน และใครเป็นผู้รับผิดชอบ" ดังนั้น Registry ควรมีข้อมูลขั้นต่ำดังนี้:

• Agent ID และวัตถุประสงค์การใช้งาน (เช่น ฝ่ายบริการลูกค้า / การประมวลผลทางบัญชี / สนับสนุนการขาย …)
• เจ้าของ (Business Owner) และ ผู้รับผิดชอบด้านเทคนิค (Developer)
• รายการ MCP / เครื่องมือที่ใช้งาน
• หมวดหมู่ข้อมูลที่เข้าถึงได้ และการจำแนกประเภท PII
• เวอร์ชันและประวัติการเปลี่ยนแปลง
• วันที่คาดว่าจะเลิกใช้งาน (ถ้ามี)

แม้จะใช้ Wiki ภายในองค์กรหรือ Notion ก็ได้ แต่หากไม่มีกฎการดำเนินงานที่ว่า "หากมีการเปลี่ยนแปลง ต้องอัปเดตที่นี่เสมอ" ก็จะเกิดสถานการณ์ที่พบเอเจนต์ที่ไม่มีอยู่จริงในขณะทำ Inventory ได้ เนื่องจากภาระในการดูแล Registry ให้ "เป็นข้อมูลปัจจุบันอยู่เสมอ" นั้นไม่ใช่เรื่องเล็ก การสร้างกลไกที่อัปเดตอัตโนมัติจาก Deployment Pipeline (เช่น อัปเดตผ่าน PR เมื่อมีการรัน CI) ตั้งแต่เริ่มต้น จึงช่วยป้องกันไม่ให้ระบบกลายเป็นเพียงสิ่งที่ทำไว้แต่ไม่ได้ใช้งานจริง (Dead system) ได้ง่ายกว่า

ใน AgentOps สำหรับ SLI (Service Level Indicator) ต้องมองต่างจาก Web service ทั่วไปที่เน้น Latency หรือ Error rate อย่างน้อยควรติดตาม 4 ตัวชี้วัดต่อไปนี้

• อัตราความสำเร็จของงาน: สัดส่วนงานที่ทำสำเร็จได้โดยไม่ต้องให้ HITL (Human-in-the-loop) เข้าแทรกแซง
• จำนวนการเรียกใช้เครื่องมือเฉลี่ย: จำนวนครั้งที่เรียกใช้เครื่องมือต่อหนึ่งงาน หากเพิ่มขึ้นมากอาจเป็นสัญญาณว่าเอเจนต์กำลังวนคิดหรือเลือกวิธีไม่ชัดเจน
• ต้นทุนโทเค็นต่องาน: ผลรวมของ Input, Output และ Cache
• อัตราการ Escalation: สัดส่วนงานที่ถูกส่งต่อไปยัง HITL

SLO หรือเป้าหมายไม่ควรกำหนดเข้มตั้งแต่แรก ควรวัดจริงในช่วง Pilot ก่อน ตัวอย่างเช่น หากตั้งเป้า "อัตราความสำเร็จ 90% ขึ้นไป" ตั้งแต่วันแรก ทีมการดำเนินงานอาจพยายามทำให้ตัวเลขดูดีจนมองไม่เห็นประเด็นที่ควรปรับปรุง หากช่วง Pilot ทำได้ราว 70% การเริ่ม SLO ที่ 75% แล้วค่อยยกระดับเป็นขั้นๆ จะช่วยให้เกิดรอบการปรับปรุงที่สมจริงกว่า

รูปแบบที่ควรหลีกเลี่ยงคือการใช้ Error rate เพียงตัวเดียวเป็น SLI เพราะเอเจนต์อาจไม่เกิด Error แต่ยังล้มเหลวได้ เช่น วนคิดจนใช้ต้นทุนเกินจำเป็น หรือทำงานถูกขั้นตอนแต่ผลลัพธ์ไม่ตรงกับความคาดหวังของผู้ใช้ การดูอัตราความสำเร็จร่วมกับจำนวนการเรียกใช้เครื่องมือเฉลี่ยจะช่วยจับสัญญาณคุณภาพถดถอยได้เร็วขึ้น

การออกแบบ HITL คือการหาจุดกึ่งกลางระหว่าง "การให้มนุษย์ตรวจสอบทุกคำขอ" กับ "การปล่อยให้เป็นหน้าที่ของ Agent ทั้งหมด" โดยสามารถแบ่งรูปแบบการใช้งานได้เป็น 3 ประเภท ดังนี้:

• HITL ที่จำเป็นตลอดเวลา (Always-on HITL): สำหรับงานด้านการโอนเงิน, การทำสัญญา, การตัดสินใจทางกฎหมาย, และการเผยแพร่ข้อมูลสู่ภายนอก (ในกรณีที่ผลกระทบจากความผิดพลาดไม่สามารถย้อนกลับได้)
• HITL ตามเกณฑ์ที่กำหนด (Threshold-based HITL): เช่น คะแนนความเชื่อมั่น (Confidence Score) < N, ยอดเงิน > N เยน, หรือจำนวนไฟล์ที่ถูกลบ > N ไฟล์
• HITL แบบสุ่มตรวจ (Sampling HITL): เป็นการอนุมัติโดยอัตโนมัติ แต่จะสุ่มตรวจโดยมนุษย์ในสัดส่วนที่กำหนด (เพื่อเฝ้าระวังคุณภาพอย่างต่อเนื่อง)

การนำทั้ง 3 รูปแบบมาใช้ร่วมกันใน Agent เดียวกันถือเป็นแนวทางที่ใช้งานได้จริง ตัวอย่างเช่น "Agent สำหรับเบิกจ่ายค่าใช้จ่าย" อาจออกแบบให้รายการที่เกิน 100,000 เยนต้องผ่าน HITL ตลอดเวลา, รายการที่ต่ำกว่า 10,000 เยนให้ดำเนินการอัตโนมัติ, และรายการที่อยู่ในช่วงกลางให้สุ่มตรวจโดยมนุษย์ 5%

สำหรับการส่งต่อเรื่อง (Escalation) ควรเตรียมช่องทางไว้ 3 กลุ่ม ได้แก่ "ทีมผู้ตรวจสอบเฉพาะทาง (Dedicated Reviewer Team)", "เจ้าของฝ่ายงาน (Business Owner)" และ "ทีมความปลอดภัย (Security Team)" เพื่อให้สามารถส่งงานไปยังผู้ที่เหมาะสมในแต่ละด้านได้ นอกจากนี้ การกำหนด SLA สำหรับเวลาในการตอบกลับของผู้ตรวจสอบจะช่วยป้องกันไม่ให้การรอ HITL กลายเป็นคอขวดของกระบวนการทำงานทั้งหมด และช่วยให้การออกแบบการตั้งค่า Timeout ของฝั่ง Agent ทำได้ง่ายขึ้นอีกด้วย

ความเข้าใจผิดที่พบบ่อยที่สุดคือการมองว่า AgentOps เป็นสิ่งที่ "สามารถนำมาใช้งานได้เพียงแค่ซื้อเครื่องมือเฉพาะทางมาติดตั้ง" แต่ในความเป็นจริงแล้ว ภาระงานส่วนใหญ่คือการจัดเตรียมบทบาทหน้าที่และการตัดสินใจภายในองค์กร ส่วนเครื่องมือเป็นเพียงองค์ประกอบหนึ่งที่เข้ามาสนับสนุนเท่านั้น

ในที่นี้ เราจะหยิบยกความเข้าใจผิดที่พบบ่อย 2 ประการขึ้นมาอธิบาย เพื่อสรุปให้เห็นอย่างชัดเจนว่าเหตุใดสิ่งเหล่านี้จึงกลายเป็นอุปสรรคที่ทำให้การขับเคลื่อนองค์กรหยุดชะงัก

จากการที่เครื่องมือ AgentOps แบบ SaaS ทยอยออกมาอย่างต่อเนื่อง ทำให้เกิดความเข้าใจว่า "เพียงนำเครื่องมือสังเกตการณ์มาใช้ก็จะทำ AgentOps ได้" เครื่องมือสังเกตการณ์มีประโยชน์จริง แต่เครื่องมือเพียงอย่างเดียวไม่สามารถแก้ส่วนที่ต้องอาศัยการตัดสินใจของมนุษย์ได้ เช่น

• จะตัดสินว่า SLI ระดับใดเป็นระดับที่ยอมรับไม่ได้
• ใครเป็นผู้จัดการเคสที่ถูกส่งต่อไปยัง HITL (Human-in-the-loop)
• เมื่อเกิดแจ้งเตือนเรื่องต้นทุนเกิน ใครมีอำนาจปรับเพิ่มเพดานงบประมาณ
• เมื่อเกิดเหตุการณ์ผิดปกติ ใครมีอำนาจหยุดการทำงานของเอเจนต์

หากแดชบอร์ดมีเพียงแจ้งเตือนสีแดงเรียงอยู่ แต่ไม่มีใครดำเนินการ นั่นคือความล้มเหลวแบบแบบทั่วไปของการเริ่มจากเครื่องมือก่อน ควรกำหนดเส้นทางการ Escalation และตารางอำนาจตัดสินใจควบคู่ไปกับการนำเครื่องมือมาใช้ อย่างน้อยควรสรุปให้ได้ในหนึ่งหน้าว่า "ใคร ดูอะไร ใช้เกณฑ์เท่าไร และต้องแจ้งใคร" แล้วให้หน่วยงานที่เกี่ยวข้องเห็นชอบก่อนจัดซื้อเครื่องมือ นี่คือเส้นทางที่สั้นที่สุดในทางปฏิบัติ

บางครั้งอาจมีการประกาศทั้งภายในและภายนอกองค์กรว่า "เราได้ติดตั้ง AI Agent ไปแล้ว 50 ตัว" แต่ จำนวนตัวเลขไม่ได้ทำหน้าที่เป็นตัวชี้วัดแทน (Proxy metric) ที่ดีนัก บางกรณี 10 ตัวก็เพียงพอแล้ว หรือบางกรณีที่ใช้งานจริงเพียง 3 ตัวก็ไม่ใช่เรื่องแปลก นอกจากนี้ยังพบปรากฏการณ์ที่ว่าจาก 50 ตัวที่ติดตั้งไปนั้น มีจำนวนที่ใช้งานจริงต่อเดือน (Monthly Active) ไม่ถึง 10 ตัว

ตัวชี้วัดแทน (Proxy metric) ที่มีประสิทธิภาพ ได้แก่:

• การลดลงของเวลาทำงานจริง (วัดเป็นรายแผนก)
• แนวโน้มของจำนวน HITL (Human-in-the-loop) (หากลดลงหมายถึงความชำนาญที่เพิ่มขึ้น หากเพิ่มขึ้นหมายถึงการบุกเบิกกรณีการใช้งานใหม่ๆ)
• ความพึงพอใจของผู้ใช้ (NPS หรืออัตราการใช้งานต่อเนื่อง)
• ROI (เวลาที่ลดลง × ค่าแรง - ต้นทุนการดำเนินงาน)

จำนวน Agent อาจมีความหมายในการจัดสรรงบประมาณและการวางแผนบุคลากร แต่หากนำมาใช้เป็น KPI โดยตรง จะติดกับดักที่ทำให้ "การเพิ่มจำนวนกลายเป็นเป้าหมายหลักเสียเอง" จึงควรเลือกใช้ให้เหมาะสมในเอกสารนำเสนอภายในองค์กร การรายงานต่อผู้บริหารควรเน้นไปที่ "การลดเวลาทำงาน" เป็นหลัก และใช้จำนวน Agent เป็นเพียงข้อมูลอ้างอิงประกอบเท่านั้น ซึ่งจะช่วยป้องกันความเข้าใจผิดในวัตถุประสงค์ได้ดีกว่า

การนำ AgentOps มาใช้จริง ควรเริ่มจาก "การมอบหมายงานให้ SRE / DevOps ทีมเดิม 1 คน แล้วค่อยๆ แยกบทบาทออกมาทีละน้อย" วิธีการจัดตั้งหน่วยงานเฉพาะทางขึ้นมาใหม่มักจะล้มเหลวในหลายกรณี เนื่องจากปัญหาด้านการจัดหาบุคลากรและความขัดแย้งกับทีมที่มีอยู่เดิม

ในที่นี้ จะขอสรุปขั้นตอนการนำไปใช้จริงโดยอ้างอิงจากบริษัทขนาดกลาง (ที่มีทีม IT 5-30 คน) โดยแบ่งออกเป็น 2 มุมมอง ดังนี้

ทีม SRE / DevOps ที่มีอยู่เดิมนั้นมีระบบโครงสร้างพื้นฐานด้านการสังเกตการณ์ (Observability), กระบวนการรับมือเหตุการณ์ (Incident Response), และการหมุนเวียนเวร (On-call rotation) อยู่แล้ว การขยายสิ่งเหล่านี้ไปใช้กับ AI Agent จึงเป็นเส้นทางที่สั้นที่สุด โดยมีรายละเอียดดังนี้:

1. มอบหมายให้มี "ผู้รับผิดชอบ AI Workload" 1 คนภายในทีม SRE / DevOps และกำหนดขอบเขตความรับผิดชอบในการดูแล Agent ให้ชัดเจน
2. นำ MCP / Agent log เข้าสู่ระบบ SIEM / เครื่องมือสังเกตการณ์ที่มีอยู่ (รูปแบบ JSON Lines จะจัดการได้ง่ายที่สุด)
3. เพิ่มบท "ความผิดปกติของ AI" ลงใน Runbook สำหรับรับมือเหตุการณ์ที่มีอยู่เดิม โดยระบุขั้นตอนการหยุดทำงาน การรีสตาร์ท และการย้อนกลับ (Rollback) ให้ชัดเจน
4. รวมเข้ากับระบบ On-call เดิม (แต่ในช่วงสองสามเดือนแรก ให้เรียกเฉพาะผู้รับผิดชอบ AI เท่านั้น และค่อยขยายไปยังสมาชิกคนอื่นหลังจากสั่งสมความรู้แล้ว)
5. แบ่งปันสัดส่วนการใช้งาน AI Workload และจำนวนเหตุการณ์ขัดข้องในการประชุม SRE โดยรวมทุกครึ่งปี

ประเด็นสำคัญคือการไม่จัดตั้ง "แผนก AI โดยเฉพาะ" ขึ้นมาใหม่ โดยใช้ แนวคิดเดียวกับการนำ AI Assistant มาใช้ภายในองค์กร เพื่อรักษาความต่อเนื่องของการดำเนินงานในขณะที่ขยายขอบเขตออกไป การพิจารณาจัดตั้งแผนกเฉพาะทางควรทำเมื่อองค์กรมีขนาดใหญ่ขึ้นและ AI Workload มีสัดส่วนเกิน 30% ของงาน SRE ทั้งหมด ซึ่งจะมีความเหมาะสมในแง่ของทรัพยากรบุคคลมากกว่า

บทบาทที่จำเป็นสำหรับองค์กรขนาดกลางสามารถสรุปได้เป็น 3 บทบาทหลัก ดังนี้

สามารถเริ่มต้นโดยให้บุคคลเดียวรับหน้าที่ควบทั้ง 3 บทบาทได้ แต่ควรหลีกเลี่ยงโครงสร้างที่ "โอนเนอร์รับหน้าที่ดูแลการปฏิบัติการด้วย" เนื่องจากหากมุมมองด้านธุรกิจและมุมมองด้านการปฏิบัติการทางเทคนิคไปรวมอยู่ที่บุคคลเดียวกัน จะทำให้เกิดความไม่สมดุลระหว่าง KPI และการแจ้งเตือน โดยเฉพาะอย่างยิ่งมักเกิดปรากฏการณ์ที่ฝ่ายธุรกิจยอมลดมาตรฐาน SLO เพื่อให้ได้ผลลัพธ์ตามเป้าหมาย หรือมองข้ามการใช้จ่ายที่เกินงบประมาณโดยอ้างว่า "จำเป็นต่อธุรกิจ" การแบ่งแยกบทบาทเพื่อให้เกิดการตรวจสอบซึ่งกันและกันจะช่วยให้การปฏิบัติงานมีความเสถียรในระยะยาว

---

ในบรรดาคำถามที่พบบ่อยที่สุดจากการนำ AgentOps ไปใช้งานจริง มีหัวข้อสำคัญหนึ่งหัวข้อที่ไม่ได้ระบุไว้โดยละเอียดในคู่มือฉบับนี้ โดยจะขออธิบายโดยเน้นไปที่รูปแบบความล้มเหลวที่มักเกิดขึ้นเมื่อมีการนำไปใช้งานจริง (Production Deployment)

Q. เหตุใดการการดำเนินงานเอเจนต์ที่ราบรื่นในช่วง Pilot จึงล้มเหลวเมื่อเข้าสู่การใช้งานจริง?

รูปแบบความล้มเหลวสามารถจัดได้เป็น 3 ประเภทหลัก

• ต้นทุนล้มเหลว: ต้นทุนที่คำนวณจากปริมาณการใช้งานในช่วง Pilot มักพองตัวอย่างมากเมื่อเจอภาระงานจริง ไม่ใช่แค่จำนวนผู้ใช้ที่เพิ่มขึ้น แต่จำนวนขั้นตอนการคิดต่อหนึ่งงานก็มักเพิ่มขึ้นด้วย เพราะงานที่ซับซ้อนกว่าจะถูกมอบให้เอเจนต์มากขึ้น ก่อน Production ควรประเมินต้นทุนช่วง Peak กำหนดเกณฑ์แจ้งเตือน และออกแบบการหยุดอัตโนมัติหรือการส่งต่อไปยัง HITL (Human-in-the-Loop) เมื่อเกินเพดานไว้ล่วงหน้า
• การตรวจสอบล้มเหลว: Log สำหรับ Audit ที่ไม่ได้เก็บในช่วง Pilot อาจกลายเป็นข้อกำหนดจำเป็นเมื่อใช้งานจริง เช่น PDPA หรือ Internal control หากมาออกแบบย้อนหลังจะสูญเสียข้อมูลในอดีต จึงควรรวมข้อกำหนด Audit ไว้ใน Structured log ตั้งแต่ต้น โดยเฉพาะการสนทนาที่มี PII ต้องกำหนดกฎ Masking ไว้ล่วงหน้า
• HITL ล้มเหลว: สิ่งที่ผู้ดูแลอนุมัติเป็นรายเคสในช่วง Pilot อาจเพิ่มจำนวนจน Reviewer รับไม่ทันเมื่อใช้งานจริง ต้องออกแบบ Threshold และ Sampling rate ของ HITL ใหม่ตามภาระ Production พร้อมกำหนด SLA และจำนวน Reviewer ที่ต้องใช้ การขาด Reviewer เป็นสาเหตุล้มเหลวที่พบบ่อยมาก จึงควรวางแผนกำลังคนตั้งแต่เนิ่นๆ

การย้ายจาก Pilot ไป Production ไม่ใช่การขยายของเดิมให้ใหญ่ขึ้น แต่ควรมองเป็นขั้นตอนการออกแบบใหม่ภายใต้ภาระงานจริง เรื่องการแบ่งงานระหว่างคนกับ AI ดูเพิ่มเติมได้จาก คู่มือ Hybrid BPO

AgentOps คือกรอบการทำงานสำหรับการจัดการ AI Agent ในฐานะ "ภาระงานปฏิบัติการระดับองค์กร (Organizational Production Workload)" ไม่ใช่เพียงแค่การ "นำเครื่องมือมาใช้" เท่านั้น

ลำดับความสำคัญในการนำไปใช้มี 3 ขั้นตอน ดังนี้:

• Step 1: ทำการสำรวจสถานะปัจจุบันและระบุความเป็นเจ้าของให้ชัดเจนด้วย Agent Registry
• Step 2: กำหนดตัวชี้วัด SLI / SLO และตัวชี้วัดด้านต้นทุนอย่างน้อย 4 รายการ พร้อมบูรณาการการสังเกตการณ์ (Observability) เข้ากับทีม SRE / DevOps ที่มีอยู่เดิม
• Step 3: ตกลงเกณฑ์ HITL (Human-in-the-loop) และเส้นทางการยกระดับปัญหา (Escalation Path) ร่วมกับเจ้าของหน่วยงานธุรกิจ

การจัดเตรียม บทบาทและอำนาจการตัดสินใจ สำคัญกว่าการจัดตั้งทีมเฉพาะกิจหรือการจัดหาเครื่องมือเฉพาะทาง นี่เป็นสิ่งที่จำเป็นเหมือนกันในการทำให้การใช้งานจริงประสบความสำเร็จ ไม่ว่าจะเป็นการ นำ AI Assistant มาใช้ภายในองค์กร หรือ การพัฒนา Agent ภาษาลาว การมอง AgentOps ในฐานะทฤษฎีการกำกับดูแลการปฏิบัติงานในยุค AI มากกว่าจะเป็นเรื่องของเทคนิคเพียงอย่างเดียว จะช่วยให้เกิดการสร้างข้อตกลงในหน้างานได้ง่ายขึ้น

หากอ่านคู่มือที่เกี่ยวข้องประกอบ ได้แก่ AI Assistant ภายในองค์กร, คู่มือ Hybrid BPO และ ความรู้เบื้องต้นเกี่ยวกับโปรโตคอล MCP จะช่วยให้เห็นจุดเชื่อมต่อระหว่าง AgentOps กับการปฏิบัติงานที่มีอยู่เดิมได้อย่างชัดเจนยิ่งขึ้น ก้าวต่อไปที่เป็นรูปธรรมเพื่อไม่ให้หยุดอยู่แค่ทฤษฎีคือ "การเลือก Agent ของบริษัทมา 1 ตัว แล้วลองทำแผ่นสรุปข้อมูล (Inventory Sheet) ตามองค์ประกอบ 5 ประการของคู่มือนี้ดู"