แอดมินหน้างานต้องจำขั้นตอนต่างกันทุกแผนก ควรแยก Agent ตามงานหรือรวมเป็นตัวเดียว

ร้านค้าออนไลน์แห่งหนึ่งให้ Agent ตัวเดียวรับผิดชอบทั้งตอบคำถามลูกค้าก่อนซื้อ ดูแลปัญหาหลังการขาย และช่วยทีมภายในตรวจสต๊อกสินค้า ทั้งสามงานนี้ใช้ Agent ตัวเดียวกันที่มี tool และ prompt เดียวกันทั้งหมด ผลที่เกิดขึ้นคือบางครั้ง Agent ตอบลูกค้าด้วยน้ำเสียงเป็นทางการเกินไปเหมือนตอบทีมภายใน และบางครั้งให้ข้อมูลสต๊อกที่ควรเป็นความลับภายในกับลูกค้าที่ถามอ้อม ๆ

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

บทความนี้จะพาดูว่า Custom Agents คืออะไรจริง ๆ ต่างจากการมี Skill หลายชุดในตัวเดียวอย่างไร และมีเกณฑ์อะไรบ้างที่ช่วยตัดสินใจว่าเมื่อไรควรแยก Agent ตามงานหรือตาม Workflow แทนที่จะรวมไว้ตัวเดียว

Custom Agents คืออะไร ในความหมายที่ใช้แยกจาก Agent เริ่มต้น

Custom Agent คือการกำหนดค่า Agent ขึ้นใหม่ที่มีบทบาท ขอบเขตงาน tool ที่เข้าถึงได้ และบางครั้งโมเดลที่ใช้ แตกต่างจาก Agent เริ่มต้นของระบบ แทนที่จะใช้ตัวเดียวที่ทำได้ทุกอย่างแบบกว้าง ๆ การสร้าง Custom Agent คือการตัดขอบเขตให้แคบลงและชัดเจนขึ้นสำหรับงานเฉพาะทางหนึ่ง

ตัวอย่างที่เห็นภาพชัดคือแทนที่จะมี Agent ตัวเดียวที่ทำทั้งตอบลูกค้าและตรวจสต๊อก ทีมสามารถสร้าง Custom Agent สองตัวแยกกัน ตัวหนึ่งชื่อ 'ผู้ช่วยลูกค้า' มีขอบเขตแค่ตอบคำถามก่อนและหลังการขาย เข้าถึง tool เฉพาะที่เกี่ยวกับข้อมูลสินค้าและ Order อีกตัวชื่อ 'ผู้ช่วยคลัง' มีขอบเขตแค่ช่วยทีมภายในตรวจสต๊อก เข้าถึง tool ที่เกี่ยวกับข้อมูลคลังสินค้าโดยเฉพาะ ทั้งสองตัวไม่จำเป็นต้องรู้เรื่องของกันและกันเลย

ความต่างสำคัญระหว่าง Custom Agent กับการมี Skill หลายชุดในตัวเดียวคือ Skill เป็นความรู้ที่ถูกโหลดเข้ามาชั่วคราวตามบริบทของบทสนทนาเดียวกัน ในขณะที่ Custom Agent คือการแยกตัวตนทั้งหมดออกจากกัน มี context บทสนทนาของตัวเอง และมักมีสิทธิ์เข้าถึง tool ที่ต่างกันตั้งแต่ระดับ configuration ไม่ใช่แค่โหลดความรู้ต่างกันชั่วคราวในบทสนทนาเดียว

แยก Agent ตาม Domain หรือตาม Workflow แบบไหนเหมาะกับทีมแบบไหน

การแยกตาม Domain คือแบ่ง Agent ตามสายงานหรือเนื้อหาที่รับผิดชอบ เช่น Agent ฝ่ายขาย Agent ฝ่ายบัญชี Agent ฝ่ายเทคนิค วิธีนี้เหมาะกับองค์กรที่แต่ละแผนกมีความรู้เฉพาะทางลึกและไม่ค่อยเกี่ยวข้องกัน เพราะแต่ละ Agent จะสะสมความรู้และ tool เฉพาะทางของแผนกตัวเองได้ลึกโดยไม่ปนกับแผนกอื่น

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

ทีมขนาดเล็กที่ยังไม่มีความซับซ้อนมากมักเหมาะกับการแยกตาม Domain มากกว่า เพราะจำนวน Agent ที่ต้องดูแลน้อยกว่าและตรงกับโครงสร้างทีมที่มีอยู่แล้ว ส่วนทีมที่มีกระบวนการอนุมัติหลายขั้นตอนซับซ้อน เช่น กระบวนการอนุมัติสินเชื่อหรือกระบวนการ QA หลายรอบ มักเหมาะกับการแยกตาม Workflow มากกว่า เพราะช่วยให้ตรวจสอบได้ว่าแต่ละขั้นตอนทำอะไรและใครรับผิดชอบส่วนไหน

มุมของแอดมินหน้างาน เมื่อต้องสลับบทบาทในแชทเดียวกันทั้งวัน

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

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

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

แบ่ง Context ร่วมกันหรือแยกขาดจากกัน เลือกอย่างไรให้เหมาะกับงาน

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

การแยก context ขาดจากกันสนิทปลอดภัยกว่าในแง่ข้อมูล แต่ต้องออกแบบกลไกส่งต่อข้อมูลที่จำเป็นระหว่าง Agent อย่างรอบคอบ เช่น เมื่อ Agent ผู้ช่วยลูกค้าต้องการถามสต๊อกจาก Agent ผู้ช่วยคลัง ควรส่งเฉพาะคำถามที่จำเป็น ไม่ใช่ส่งบทสนทนาทั้งหมดของลูกค้าไปให้ Agent ฝั่งคลังเห็นทั้งหมด

หลักที่ใช้ตัดสินใจได้จริงคือถ้าข้อมูลสองฝั่งมีระดับความอ่อนไหวต่างกัน เช่น ข้อมูลลูกค้ากับข้อมูลภายในของธุรกิจ ควรแยก context ขาดจากกันเสมอ ต่อให้เพิ่มความซับซ้อนของกลไกส่งต่อข้อมูลก็ตาม เพราะความเสี่ยงข้อมูลรั่วสำคัญกว่าความสะดวกในการส่งต่องาน

ทีมที่เริ่มต้นด้วยการให้ Agent ทุกตัวเห็น context ร่วมกันหมดมักพบว่าในภายหลังต้องมานั่งไล่แยกทีหลังอยู่ดี เมื่อธุรกิจเติบโตขึ้นและเริ่มมีข้อกำหนดเรื่องการเข้าถึงข้อมูลที่ชัดเจนขึ้น เช่น ทีมกฎหมายเริ่มถามว่าใครเห็นข้อมูลอะไรบ้าง การวางโครงสร้างแยก context ตั้งแต่ตอนที่ยังมี Agent ไม่กี่ตัวจึงมักคุ้มค่ากว่าการรอให้ระบบใหญ่ขึ้นแล้วค่อยมาแก้ทีหลัง

ตารางเปรียบเทียบ Agent ตัวเดียวกับ Custom Agent หลายตัว

ตารางนี้สรุปจุดที่ควรพิจารณาเมื่อต้องตัดสินใจว่าจะใช้ Agent ตัวเดียวพร้อม Skill หลายชุด หรือแยกเป็น Custom Agent หลายตัว:

สถานการณ์ที่ยังไม่ควรแยก Custom Agent ทั้งที่ดูเหมือนควรทำ

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

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

ทำแบบนี้แล้วพัง เพราะ… ข้อผิดพลาดที่เจอบ่อยตอนแยก Custom Agent

• แยก Agent มากเกินไปตั้งแต่แรกทั้งที่งานยังไม่ซับซ้อนพอ — ทำแบบนี้แล้วพัง เพราะต้องดูแล configuration หลายชุดโดยไม่ได้ประโยชน์ด้านความสม่ำเสมอที่ชัดเจนคุ้มค่ากับภาระที่เพิ่มขึ้น
• ให้ Agent ทุกตัวเห็น context เดียวกันหมดเพื่อความสะดวก — ทำแบบนี้แล้วพัง เพราะข้อมูลที่ควรเป็นความลับภายในอาจหลุดไปให้ Agent ที่คุยกับลูกค้าเห็นโดยไม่ตั้งใจ
• ไม่กำหนดกลไกส่งต่องานระหว่าง Agent ให้ชัดเจน — ทำแบบนี้แล้วพัง เพราะเมื่อ Agent ตัวหนึ่งต้องการข้อมูลจากอีกตัว จะไม่รู้ว่าควรส่งคำขออย่างไรและรอผลลัพธ์แบบไหน ทำให้เกิดคำตอบที่ค้างหรือขัดแย้งกัน
• ตั้งชื่อและบทบาทของ Custom Agent คลุมเครือจนซ้อนทับกัน — ทำแบบนี้แล้วพัง เพราะระบบหรือคนดูแลเองก็แยกไม่ออกว่าเรื่องไหนควรเป็นหน้าที่ของ Agent ตัวไหน เหมือนปัญหา MCP tool ที่ทำงานคาบเกี่ยวกัน

สรุป

Custom Agents ไม่ใช่สิ่งที่ทุกทีมต้องมีตั้งแต่วันแรก แต่เป็นทางแก้ที่เหมาะกับทีมที่เริ่มเห็นปัญหา Agent ตัวเดียวสับสนบทบาทหรือขั้นตอนไม่สม่ำเสมอ การแยกตาม Domain หรือ Workflow ต้องเลือกให้ตรงกับโครงสร้างงานจริง ไม่ใช่แยกเพราะรู้สึกว่าดูเป็นระบบมากกว่า

จุดที่ต้องระวังมากที่สุดเมื่อแยก Custom Agent คือการจัดการ context ระหว่างแต่ละตัว ถ้าให้เห็นข้อมูลกันหมดจะสะดวกแต่เสี่ยงข้อมูลรั่ว ถ้าแยกขาดสนิทจะปลอดภัยกว่าแต่ต้องออกแบบกลไกส่งต่องานให้รอบคอบ

• Custom Agent คือ Agent แยกที่มีบทบาท ขอบเขตงาน และ tool ของตัวเอง ต่างจาก Skill ที่โหลดความรู้ชั่วคราวในตัวเดียว
• แยกตาม Domain เหมาะกับทีมที่แผนกไม่เกี่ยวข้องกันมาก แยกตาม Workflow เหมาะกับกระบวนการที่มีขั้นตอนชัดเจน
• จำกัดขอบเขต context และสิทธิ์ tool ของแต่ละ Agent ให้แคบตามบทบาท ลดความเสี่ยงข้อมูลปนกัน
• อย่าแยก Custom Agent ก่อนที่ปัญหาจริงจะเกิด เพราะเพิ่มภาระดูแล configuration โดยไม่จำเป็น

คำถามที่พบบ่อย