ภาพประกอบสร้างด้วย AI แสดงการส่งคำขอจากฝ่ายขายให้คลังตรวจ ไม่ใช่ภาพระบบหรือโครงการของลูกค้า
ผู้ช่วยฝ่ายขายขอให้ผู้ช่วยคลังสินค้าเช็กของให้ลูกค้า แล้วส่งคำตอบกลับว่า "ดำเนินการแล้ว" ฝ่ายขายยังต้องรู้ว่าตรวจยอดเสร็จแล้ว จองสินค้าแล้ว หรือแค่รับคำขอไว้ หากแต่ละฝ่ายเข้าใจคนละอย่าง ลูกค้าอาจได้คำยืนยันทั้งที่ยังไม่มีใครรับผิดชอบการส่งของ
เมื่อ AI เริ่มส่งงานหากัน คำถามจึงขยายจากความแม่นของคำตอบไปสู่ความรับผิดชอบตลอดทาง ใครเป็นคนขอ ผู้ช่วยแต่ละตัวมีสิทธิ์ทำอะไร และหลักฐานใดยืนยันว่าผลที่ส่งกลับหมายถึงสิ่งเดียวกับที่ฝ่ายรับเข้าใจ
ตอนที่ 1 แยกเรื่องโปรโตคอล มาตรฐาน และโอเพนซอร์ส ตอนที่ 2 ชวนตกลงความหมายของข้อมูล ERP และตอนที่ 3 ดูแลวิธีทำงานผ่าน Agent Skills ตอนสุดท้ายจะนำเรื่องเหล่านี้มาวางโครงการทดลองที่มีขอบเขต วัดประโยชน์ได้ และหยุดได้เมื่อหลักฐานไม่พอ
เมื่อไรงานหนึ่งชิ้นต้องใช้ผู้ช่วยหลายฝ่าย
ถ้างานทั้งหมดอยู่ในแอปพลิเคชันเดียว ใช้ข้อมูลชุดเดียว และมีเจ้าของกระบวนการเดียว การเพิ่มผู้ช่วยอีกตัวอาจเพิ่มเพียงจุดส่งต่อที่ต้องดูแล ควรเริ่มจากวิธีที่ทีมตรวจและแก้ปัญหาได้ง่ายก่อน
กรณีที่น่าประเมินการส่งงานข้ามผู้ช่วยมากขึ้น คือแต่ละฝ่ายมีระบบหรือผู้รับผิดชอบของตนเอง เช่น ฝ่ายขายขอตรวจสถานะจากคลัง โดยคลังยังเป็นผู้กำหนดวิธีตรวจและสิทธิ์เข้าถึงข้อมูล ไม่จำเป็นต้องเปิดเครื่องมือภายในทั้งหมดให้ฝ่ายขายเรียกเอง
เอกสาร A2A อธิบายการสื่อสารและร่วมงานระหว่างเอเจนต์ที่เป็นอิสระจากกัน ขณะที่ MCP ใช้เชื่อมเอเจนต์กับเครื่องมือและทรัพยากร ทั้งสองอาจใช้ร่วมกันในระบบหนึ่งได้ เอกสาร A2A and MCP การเลือกใช้ควรเกิดจากขอบเขตงานจริง ไม่ใช่เงื่อนไขว่าทุกโครงการต้องมีครบทุกมาตรฐาน
สิ่งที่ควรตกลงก่อนส่งคำขอแรก
A2A มีโครงสร้างสำหรับอธิบายเอเจนต์ผ่าน Agent Card ส่งข้อความ ติดตามงาน และส่งผลลัพธ์ แต่สิทธิ์อนุญาตหลังยืนยันตัวตนยังอิงนโยบายของผู้ให้บริการเอเจนต์นั้น A2A Specification ส่วนการยืนยันตัวตน สิทธิ์ และวงจรงาน บริษัทจึงต้องตกลงความหมายของงานและขอบเขตข้อมูลคู่กับส่วนเชื่อมต่อ
สำหรับโครงการเริ่มต้น ควรเขียนข้อตกลงให้คนขายและคนคลังอ่านร่วมกันได้ก่อน โดยระบุคำขอที่รับ ข้อมูลที่จำเป็น ผลลัพธ์ที่ต้องตอบ ผู้รับผิดชอบ และเหตุให้ส่งกลับมาถามคน หากยังตกลงไม่ได้ว่า "ตรวจเสร็จ" ต้องมีข้อมูลอะไร การเลือกโปรโตคอลยังแก้ความกำกวมนั้นไม่ได้
ในฝั่งสิทธิ์ ควรแยกผู้ขอ ผู้ช่วยที่ส่งคำขอ และผู้ช่วยที่ลงมืออ่านระบบให้ตามได้ ผู้ช่วยคลังไม่ควรรับคำขอที่เกินสิทธิ์ของงานเพียงเพราะผู้ช่วยฝ่ายขายติดต่อถึง การส่งงานให้ผู้ช่วยอีกตัวก็ไม่ควรทำให้อำนาจของคำขอเพิ่มขึ้นโดยไม่มีการอนุญาตที่ตรวจได้ ข้อนี้เป็นหลักออกแบบที่โครงการต้องบังคับใช้และทดสอบ
อย่ากำหนดเพียงกรณีสำเร็จ ต้องตกลงเรื่องเวลารอ ข้อมูลไม่ครบ ผลตอบกลับซ้ำ และคำขอที่ถูกยกเลิกด้วย โดยเฉพาะงานที่เริ่มทำรายการใน ERP แล้ว บริษัทต้องกำหนดว่าจะตรวจผลและแก้รายการอย่างไร การได้รับสถานะยกเลิกของงานไม่ควรถูกตีความเองว่ารายการธุรกิจถูกย้อนกลับแล้ว
ตัวอย่างสมมติของฝ่ายขายที่ขอข้อมูลจากคลัง
สมมติผู้จัดจำหน่ายแห่งหนึ่งทดลองกับคำถามจำนวนสินค้าพร้อมจัดสรรในคลังเดียว ให้เจ้าหน้าที่ฝ่ายขายเริ่มคำขอผ่านผู้ช่วยฝ่ายขาย แล้วส่งงานให้ผู้ช่วยคลังตรวจใน ERP เป้าหมายของรอบนี้คือทำร่างคำตอบให้เจ้าหน้าที่ตรวจ ยังไม่จองของ ไม่สร้างคำสั่งขาย และไม่ส่งข้อความถึงลูกค้าโดยอัตโนมัติ ตัวอย่างนี้เป็นข้อเสนอสมมติ ไม่ใช่ระบบที่ Enersys ส่งมอบหรือผลทดลองจริง
เจ้าหน้าที่ระบุรหัสสินค้า คลัง จำนวน และวันที่ต้องการ ผู้ช่วยฝ่ายขายส่งเฉพาะข้อมูลที่ผู้ช่วยคลังต้องใช้พร้อมเลขอ้างอิงคำขอ ผู้ช่วยคลังอ่านข้อมูลผ่านเครื่องมือที่จำกัดขอบเขต ใช้วิธีตรวจที่เจ้าของคลังรับรอง แล้วส่งกลับจำนวนที่ตรวจได้ เวลาอ้างอิง เงื่อนไขที่ยังต้องตรวจ และหลักฐานที่ผู้มีสิทธิ์เปิดดูได้
เจ้าหน้าที่ฝ่ายขายอ่านร่างคำตอบและตรวจหลักฐานก่อนสื่อสารกับลูกค้า หัวหน้าคลังรับผิดชอบนิยามของจำนวนพร้อมจัดสรร ส่วนผู้ดูแลโครงการตรวจว่าผู้ช่วยสองฝ่ายส่งข้อมูลและรักษาขอบเขตตามที่ตกลงไว้หรือไม่ บทบาทเหล่านี้ยังจำเป็นแม้ข้อความจะส่งผ่านโปรโตคอลมาตรฐาน
ข้อยกเว้นของตัวอย่างคือ ผู้ช่วยคลังอ่านยอดจองไม่สำเร็จและหมดเวลารอ ผู้ช่วยฝ่ายขายต้องบอกว่าคำขอยังตรวจไม่ครบ พร้อมให้เจ้าหน้าที่กลับไปตรวจตามขั้นตอนเดิม หากผลเก่ามาถึงภายหลัง ระบบทดลองต้องแยกได้ว่าเป็นผลของคำขอเดิม และให้คนพิจารณาว่ายังใช้ได้หรือควรตรวจใหม่ ไม่ส่งคำยืนยันซ้ำโดยอัตโนมัติ
หลักฐานหนึ่งงานควรตามจากคำขอของคน ผ่านงานที่ส่งต่อ ไปถึงข้อมูลอ้างอิงและร่างคำตอบได้ บันทึกข้อปฏิเสธสิทธิ์ เหตุส่งให้คนตรวจ และรุ่นของวิธีทำงานที่ใช้ด้วย โดยไม่เก็บข้อมูลลับเกินจำเป็น ข้อกำหนด A2A มีคำแนะนำเรื่องบันทึกเหตุการณ์ด้านความปลอดภัยและร่องรอยงานที่อ่อนไหว พร้อมข้อกำหนดปกป้องข้อมูลในบันทึก A2A Specification ส่วนแนวทางความปลอดภัย
ประวัติงานในโปรโตคอลยังไม่ใช่หลักฐานตรวจสอบกระบวนการธุรกิจทั้งหมด บริษัทต้องเลือกเองว่าจะเก็บหลักฐานละเอียดเพียงใด ใครเปิดดูได้ และนานเท่าไร การเก็บข้อความทั้งหมดโดยไม่มีขอบเขตอาจเพิ่มภาระและเปิดเผยข้อมูลเกินกว่าที่ผู้ตรวจต้องใช้ ส่วนการมีเพียงข้อความว่า "สำเร็จ" ก็ไม่พอให้หาสาเหตุเมื่อคำตอบผิด
วัดตั้งแต่คนเริ่มถามจนได้คำตอบที่ใช้ได้
ก่อนเปิดทดลอง ให้เลือกงานเดิมที่เทียบกันได้และเก็บเวลาตั้งแต่ฝ่ายขายเริ่มถามจนได้คำตอบที่ใช้ได้จริง รวมเวลารอคลังและเวลาแก้คำตอบด้วย ถ้าวัดเฉพาะช่วงที่ AI สร้างข้อความ เราอาจเห็นระบบเร็วขึ้นทั้งที่คนยังรอเท่าเดิม
ข้อเสนอหนึ่งคือทดลองกับงานที่เข้าเกณฑ์ 20 งานแรกในคลังเดียว โดยถือจำนวนนี้เป็นขอบเขตเก็บข้อมูลเบื้องต้น ไม่ใช่หลักฐานทางสถิติหรือมาตรฐานความพร้อมใช้งานจริง บันทึกงานที่ถูกตัดออกและเหตุผล เพื่อไม่เลือกเฉพาะกรณีที่ดูดี
คนตรวจควรนับคำตอบที่ต้องแก้ข้อมูล การส่งต่อให้คนเพราะข้อมูลขาด และเวลาที่ใช้ตรวจหลักฐานแยกกัน การส่งให้คนในกรณีที่กติกากำหนดให้หยุดเป็นพฤติกรรมที่ต้องการ จึงไม่ควรนับรวมเป็นความผิดพลาดของ AI ส่วนคำตอบที่ดูสมบูรณ์แต่ใช้ยอดผิดต้องบันทึกเป็นข้อผิดพลาด แม้ไม่มีใครกดแจ้งปัญหา
ก่อนเริ่ม ทีมต้องกำหนดเกณฑ์เดินหน้าจากความเสี่ยงและต้นทุนของกิจการ เช่น เวลารวมต่อคำตอบลดลงตามเป้าหมายที่ตกลงกัน ภาระตรวจงานรับได้ และไม่พบการอ่านข้อมูลนอกขอบเขตในการทดสอบที่กำหนด ผลที่ไม่พบเหตุในกลุ่มทดลองยังใช้รับรองว่าไม่มีความเสี่ยงในงานอื่นไม่ได้
หากพบการข้ามสิทธิ์ หรือหาเอกสารที่รองรับคำตอบสำคัญไม่ได้ ควรพักขอบเขตนั้นและให้คนทำตามวิธีเดิมก่อน การหยุดต้องมีผู้รับผิดชอบและวิธีปิดสิทธิ์ที่ทดสอบแล้ว เมื่อแก้สาเหตุจึงนำกรณีเดิมกลับมาทดสอบซ้ำ เกณฑ์เหล่านี้เป็นข้อเสนอบริหารโครงการ ไม่ใช่ใบรับรองจากการรองรับ A2A
โครงการเล็กที่ทำให้ตัดสินใจขั้นถัดไปได้
ผลของรอบแรกอาจเป็นการเดินหน้ากับงานเดิม แก้นิยามข้อมูล หรือหยุดเพราะคนตรวจใช้เวลามากกว่าวิธีเดิม ทุกทางเลือกมีคุณค่าเมื่อมีหลักฐานพอให้ตัดสินใจ การเพิ่มจำนวนผู้ช่วยหรือเปิดสิทธิ์ทำรายการควรตามผลตรวจ ไม่จำเป็นต้องเป็นเป้าหมายของรอบถัดไปเสมอ
ก่อนเริ่มประชุมโครงการครั้งหน้า ลองเขียนประโยคเดียวให้ครบว่า "ให้ผู้ช่วยของฝ่ายใดขอข้อมูลอะไรจากฝ่ายใด โดยใครตรวจผล และหยุดเมื่อเกิดอะไร" ถ้ายังเขียนไม่ได้ ให้ใช้เวลาประชุมกับประโยคนี้ก่อนเลือกเครื่องมือ
จุดจบของบทความทั้งสี่ตอนคือจุดเริ่มของงานเล็กที่ตรวจได้ เมื่อเลือกงาน นิยามข้อมูล ผู้ดูแลวิธีทำงาน และผู้รับผิดชอบการส่งต่อได้แล้ว บริษัทก็มีขอบเขตที่พร้อมนำไปประเมินกับทีมธุรกิจและทีมระบบโดยไม่ต้องเริ่มจากคำสัญญาว่า AI จะทำแทนทุกฝ่าย
กลับไปที่คำถามในตอนที่ 1 โปรโตคอลเปิดและโอเพนซอร์สช่วยให้แต่ละฝ่ายมีทางเลือกในการเชื่อมต่อและดูแลระบบ แต่ประวัติของอินเทอร์เน็ตเป็นเพียงบทเรียนเปรียบเทียบ ไม่ใช่หลักประกันว่า AI จะพัฒนาไปในทางเดียวกัน สิ่งที่บริษัทพิสูจน์ได้ตอนนี้คือ งานหนึ่งชิ้นส่งต่อได้ตามข้อตกลงจริงหรือไม่
