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) เมื่อมี "Prompt ที่มาจากแหล่งข้อมูล" อื่นที่ไม่ใช่จากผู้ใช้งานเข้ามาเกี่ยวข้อง เมื่อปัจจัยเหล่านี้ครบถ้วน การดำเนินงานในรูปแบบเดิมของ 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) ได้ง่ายกว่า

SLI（Service Level Indicator）の AgentOps では、Web サービスのレイテンシやエラー率とは異なる観点が必要となる。最低限確認すべき 4 つの指標を挙げる。

• タスク成功率: HITL（Human-in-the-loop）の介入なしでタスクを完遂できた割合
• 平均ツール呼び出し回数: 1 タスクあたり何回ツールを呼び出しているか（増加は思考の迷走を示すシグナル）
• トークンコスト / タスク: 入力 + 出力 + キャッシュ消費の合計
• エスカレーション率: HITL にエスカレーションされた割合

SLO（目標値）は最初から厳しく設定せず、パイロット期間で実測してから決定する。例えば「タスク成功率 90% 以上」を最初から掲げると、運用側が成果を取り繕う方向に動きがちで、本来注視すべき改善点が見えなくなる。パイロットで 70% 程度の成功率であれば、SLO は 75% から始めて段階的に引き上げるほうが、組織として現実的な改善サイクルを回せる。

アンチパターンとして避けたいのは「エラー率だけを SLI にする」設計である。エージェントはエラーが発生しなくても、「無駄な思考ループでコストだけを消費する」「正しく動作したが結果がユーザーの期待と異なる」といった失敗のしかたが多く、エラー率だけでは拾いきれない。タスク成功率と平均ツール呼び出し回数を組み合わせることで、品質劣化の予兆を早期に把握できるようになる。

การออกแบบ 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 ประการขึ้นมาอธิบาย เพื่อสรุปให้เห็นอย่างชัดเจนว่าเหตุใดสิ่งเหล่านี้จึงกลายเป็นอุปสรรคที่ทำให้การขับเคลื่อนองค์กรหยุดชะงัก

SaaS 型の AgentOps ツールが相次いで登場した結果、「観測ツールを導入すれば AgentOps が実現できる」という認識が広がっている。観測ツールは確かに有用だが、それだけでは以下のような人間の判断が必要な部分を解決できない。

• どの SLI を「許容できないレベル」と判断するか
• HITL（Human-in-the-loop）に上がった案件を誰が捌くか
• コスト超過アラートが出たとき、誰が予算上限を引き上げるか
• インシデント発生時に誰がエージェントを停止する権限を持つか

ダッシュボードに赤いアラートが並ぶだけで何も動かないというのは、観測ツール先行の典型的な失敗である。ツール導入と並行して、エスカレーションパスと意思決定権限の表を整備するのが先決だ。最低限「誰が・何を見て・どの閾値で・誰に連絡するか」を 1 ページにまとめ、関係部署で合意してから観測ツールを発注するのが、結果として最短のルートになる。

บางครั้งอาจมีการประกาศทั้งภายในและภายนอกองค์กรว่า "เราได้ติดตั้ง 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 ส่วนหลัก ดังนี้:

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

---

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

Q. なぜパイロット運用では順調だったエージェント運用が、本番展開で破綻してしまうのですか？

破綻パターンは大きく 3 つに整理できます。

• コスト破綻: パイロットの利用量で計算したコストが、本番の負荷で大きく膨らみます。ユーザー数増加だけでなく、1 タスクあたりの思考ステップ数も増える傾向にあります（複雑なケースをエージェントに任せるようになるため）。本番化前に想定ピーク時のコスト試算とアラート閾値を必ず作成し、超過時の自動停止または HITL（Human-in-the-Loop）への切り替えを設計しておく必要があります。
• 監査破綻: パイロットでは取得していなかった監査ログが、本番化時に「PDPA / 内部統制で必要」と判明します。後付けでログを整備すると過去データを失うため、監査要件は最初から想定して構造化ログの設計に組み込みます。特に PII を含むやり取りは、マスキングルールも事前に決めておく必要があります。
• HITL 破綻: パイロットでは管理者が個別に承認していたものが、本番化で件数が膨らみレビュアーが追いつかなくなります。HITL のしきい値やサンプリング率を本番想定で設計し直し、レビュアーの SLA と必要人数を見積もります。レビュアー不足は最も多い破綻原因であるため、人員計画は早めに着手すべきです。

パイロットから本番への移行は「同じものを大きくする」のではなく、「本番想定の負荷で再設計する」段階として扱うのが安全です。Hybrid BPO のガイド で論じた人と AI の役割分担も、規模の変化に応じて見直しが必要です。具体的には、パイロット時は「AI が 8 割・人間が 2 割」だった分担が、本番化で「AI が 6 割・人間が 4 割」に動くことがよくあります。これは品質の問題ではなく、HITL を含む人間の介入領域が広がる現象として捉えるべきです。

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 ประการของคู่มือนี้ดู"