‘Viktor AI’ พนักงาน AI ที่อาศัยอยู่ใน Slack ไม่มี Web App ไม่ต้องสลับหน้าจอ ทำงานได้แทบทุกบทบาทในบริษัท

คลื่นของ AI Agent ในปี 2026 กำลังขยับจากการเป็น "เครื่องมือเสริม" ที่เปิดหน้าต่างใหม่ขึ้นมาคุยทีละครั้ง ไปสู่การเป็น "พนักงานเต็มตัว" ที่ใช้ชีวิตอยู่ในเครื่องมือเดียวกับทีม และจำ Context ของทั้งบริษัทได้พร้อมกัน หนึ่งในผู้เล่นที่เปิดประเด็นนี้ได้ชัดเจนที่สุดคือ Viktor สตาร์ทอัพที่ออกแบบ AI ให้ไม่มี Web App เป็นของตัวเองเลยสักหน้า แต่อาศัยอยู่ใน Slack ของทีมคุณแทน เชื่อมต่อกับเครื่องมือกว่า 3,000 ตัว และทำงานได้ตั้งแต่เขียนโค้ดไปจนถึงปรับงบโฆษณา Meta Ads ในบทสนทนาเดียว

Fryderyk Wiatrowski ผู้ร่วมก่อตั้ง Viktor ได้ขึ้นเวที Open/Closed Track เพื่อเล่าเส้นทางตั้งแต่ยุค Web Agent ในปี 2023 จนมาถึง Company Agent ในวันนี้ ทั้งเหตุผลที่เลือก Slack เป็นบ้าน บทเรียนจากการ A/B Test ระหว่าง Claude Opus 4.6 กับ GPT 5.4 เคสลูกค้าที่ Personal Gmail รั่วทั้งบริษัท และสามเสาหลักที่ทีมไหนก็ตามที่อยากสร้าง AI Coworker ของตัวเองควรรู้

Fryderyk เปิดเวทีด้วยการสารภาพว่าตัวเขาเองก็คาดไม่ถึง Viktor เปิดตัวเมื่อเดือนกุมภาพันธ์ 2026 ในฐานะการทดลองที่ไม่ได้คาดหวังว่าจะโต แต่กลับเจอ Product-Market Fit ทันที มีผู้ใช้งานทั่วโลกพุ่งเร็วจนทีมตามไม่ทัน นี่คือเรื่องราวเบื้องหลังของ AI Employee ที่ Fryderyk บอกว่าไม่ใช่เครื่องมือ แต่คือ "การจ้างพนักงาน" คนใหม่เข้าทีม

Viktor ทำหน้าที่เป็นพนักงาน AI ที่อาศัยอยู่ในที่เดียวกับทีมคุณคือ Slack ไม่มี Web App แยกต่างหากให้ต้องเปิด เหมือนเพื่อนร่วมทีมคนหนึ่งที่เข้าร่วมการสนทนาใน Threads และ Channels ได้โดยตรง จุดที่ Fryderyk ย้ำคือ Viktor เชื่อมต่อกับเครื่องมือกว่า 3,000 ตัวที่บริษัทใช้งานอยู่ และถ้ายังไม่มี Integration ที่ต้องการ Viktor สามารถสร้าง Connection ของตัวเองขึ้นมาได้ ทำให้มันมี Context แบบแนวขวางทั่วทั้งบริษัท ต่างจากพนักงานมนุษย์ที่มักรู้เฉพาะทางตามบทบาทของตน เขายกตัวอย่างว่า CMO ที่เข้าถึง Codebase ได้ย่อมทำงานได้ดีขึ้น และนี่คือสิ่งที่ Viktor มอบให้ในระดับ PhD ครอบคลุมทุกฝ่ายของบริษัท

เส้นทางจาก Jace.ai สู่ Viktor

ภารกิจของทีมเริ่มต้นในปี 2023 หลัง ChatGPT เปิดตัวไม่นาน ตอนนั้นยังไม่มี Tool Calling ที่เสถียร โมเดลสร้างโค้ดยังไม่เก่งเท่าวันนี้ ทีมจึงเลือกเดินทางสาย Browser Agent ในชื่อ Jace.ai โดยใช้วิธีถ่ายภาพ DOM ของหน้าเว็บ ย่อข้อมูลแบบไม่สูญเสียข้อมูล (Lossless) แล้วให้โมเดลตัดสินใจขั้นถัดไป เช่น พิมพ์อะไรในช่องค้นหา หรือคลิกปุ่มเข้าสู่ระบบ

Jace.ai เคยขึ้นเป็นเอเจนต์ระดับแถวหน้าของวงการบน WebArena ซึ่งเป็นชุดทดสอบ (Benchmark) Web Agent ที่ได้รับความนิยมสูงสุด แต่ Fryderyk ยอมรับว่าทำเป็นโปรดักต์ใช้งานจริงได้ยาก เพราะตอนนั้นโมเดลทำงานได้แค่ 3 ถึง 5 ขั้นอย่างน่าเชื่อถือ ที่ความน่าเชื่อถือ 60% และความผิดพลาดจะทบกันไปเรื่อย ๆ จากนั้นเมื่อ Claude Sonnet 3.5 เปิดตัว Jace ก็แปลงร่างเป็น Email Agent ที่ทำงานในวงจร Agent Loop เมื่อมีอีเมลเข้ามา สามารถตอบกลับด้วยร่างอีเมล หรือเรียก Tool Call เพื่อทำงานต่อ เช่น คืนเงินให้ลูกค้าโดยอัตโนมัติ (มีระบบขออนุมัติ (Approval Gate) กั้นได้)

จนกระทั่งกุมภาพันธ์ 2026 Viktor ถือกำเนิดขึ้น โดยตั้งโจทย์ใหม่ว่าจะสร้าง Company Agent ไม่ใช่ Personal Agent อย่าง Open Interpreter

Company Agent ต่างจาก Personal Agent อย่างไร

Fryderyk ระบุว่า Company Agent ต้องอยู่ในที่ที่ทีมทำงาน รับ Context ของทั้งบริษัท และที่สำคัญคือใช้ระบบสิทธิ์แบบใช้ร่วมกัน เพียงคนเดียวในบริษัทเชื่อม Integration เข้ามา Viktor จะสืบทอด Permission นั้นและทีมทั้งหมดเข้าถึงได้ทันที ไม่ต้องให้ทุกคนตั้งค่าซ้ำ 100 ครั้ง

แต่การกระโดดจากผู้ใช้คนเดียวไปสู่ผู้ใช้หลายร้อยคนสร้างความท้าทายใหม่หลายข้อ ข้อแรกคือเรื่องหน่วยความจำ (Memory) ที่ Open Interpreter เคยกังวลว่าจะรกในระยะยาว เมื่อมาอยู่บนสถาปัตยกรรมเดียวกันสำหรับ 100 คน หน่วยความจำก็เต็มเร็วขึ้น 100 เท่า ซึ่งทีมต้องลงทุนแก้ปัญหานี้โดยตรง อีกข้อคือลำดับชั้นของ Slack ที่มีหลาย Channel และพนักงานในแต่ละแผนกอาจให้คำสั่งที่ขัดแย้งกัน Viktor ต้องไม่ปล่อย Context จาก Growth Channel หรือ Executive Channel หลุดไปยังฝ่าย Engineering หรือ Support และเมื่อพนักงานคนหนึ่ง DM มาด้วยปัญหาส่วนตัว Viktor ก็ต้องรู้ว่าควรดึง Context จากไหน

ทำไมต้องเป็น Slack

ทีมเลือก Slack เป็นหน้าจอใช้งานหลัก (Interface) ด้วยเหตุผลหลักสองข้อ ข้อแรกคือต้องการให้ Viktor รู้สึกเหมือนพนักงานจริง ๆ ซึ่งไม่มีใครคุยกับเพื่อนร่วมงานผ่าน Web App ข้อสองคือเรื่องความหน่วงในการตอบกลับ (Latency) เมื่อ Agent ที่มีความสามารถสูงต้องทำงานยาก งานนั้นอาจกินเวลา 10 นาทีโดยธรรมชาติ ถ้าให้ผู้ใช้รอบน Web App หลังจากสลับ Context มาแล้วก็จะรู้สึกหงุดหงิด เพราะเราเคยชินกับ ChatGPT ที่ตอบใน 30 วินาที แต่ใน Slack การที่เพื่อนร่วมทีมตอบกลับใน 10 นาทีถือว่าเร็วมาก ไม่มีใครเคยสร้างแอปให้คุณได้ภายใน 10 นาที การรับรู้เรื่องเวลาจึงเปลี่ยนไปทั้งหมด

อย่างไรก็ตาม Slack ก็มีข้อจำกัดที่ Web App ไม่มี เพราะ Slack มีโหมดการปฏิสัมพันธ์หลายแบบ ทั้งการ DM, Public Channel, Threads, การกดอีโมจิตอบกลับ และการแก้ไขข้อความ ทุกอย่างต้องเป็น Input ของ Agent และต้องนำมาเรียงร้อยให้กลายเป็น Context แบบเรียงเส้นตรง Fryderyk ยกตัวอย่างว่าเวลาคน DM กัน แล้วเปิด Thread หนึ่ง พอผ่านไปสักพักก็มักจะลืม Thread เดิมแล้วเริ่ม DM ใหม่ มนุษย์ยังจำ Context เก่าได้ แต่ Agent จะมองเป็นงานใหม่ทันที Viktor จึงต้องย้อนไปดูข้อความก่อนหน้าและลากเข้ามาในบทสนทนาปัจจุบันเสมอ

ปัจจุบัน Viktor ใช้ Claude Opus 4.6 เป็นโมเดลหลัก ทีมเคยลอง A/B Test กับ GPT 5.4 ซึ่งทำ Tool Calling และการสร้างโค้ดได้ยอดเยี่ยม แถมราคาถูกกว่า แต่ผู้ใช้กลับเดือดและเรียกร้องให้กลับมาใช้ Opus ด้วยเหตุผลเรื่องบุคลิก (Personality) Fryderyk บอกว่า Opus มีความกวน ๆ นิดหน่อย ไม่แน่ใจว่าเป็นเพราะทีมที่ออกแบบ Anthropic หรือสถาปัตยกรรมของ Viktor เอง แต่ผลลัพธ์คือผู้ใช้รักโทนเสียงนี้

Proactivity และเส้นบาง ๆ ระหว่างความช่วยเหลือกับความน่ารำคาญ

จุดเด่นอีกอย่างของ Viktor คือสามารถเสนอกระบวนการอัตโนมัติ (Workflow) ได้ด้วยตัวเอง สมมุติทีม Growth กำลังคุยกันเรื่องผล A/B Test และตัดสินใจเลือกตัวเลือกหนึ่ง Viktor ที่ต่อกับ PostHog (หรือเครื่องมือวิเคราะห์ข้อมูลอื่น) จะเข้าไปตรวจสอบให้ทันที และมีหลายครั้งที่ Viktor พบว่าผลทดสอบไม่มีนัยสำคัญทางสถิติ แล้วรันการคำนวณกลับมาเตือนทีม

แต่ความเชิงรุกนี้กลายเป็นปัญหากับฝ่ายความปลอดภัยทันที ถ้า Viktor ถูกเพิ่มเข้า Workspace แล้วเริ่ม DM ทุกคนหรือกระโดดเข้า Thread ทันทีในวันแรก ฝ่ายความปลอดภัยจะเดือดจัดแน่นอน บทเรียนของทีมคือต้องค่อย ๆ สร้างความไว้วางใจกับผู้ใช้กลุ่มแรก ก่อนค่อยปล่อยใช้งานในวงกว้าง

เคสตัวอย่าง Personal Gmail กับการแยก Integration

Fryderyk เล่าเคสจากลูกค้ารายหนึ่งซึ่งเป็นแบรนด์อีคอมเมิร์ซรายใหญ่ในสหรัฐ ผู้ดูแลทีมเชื่อม Viktor เข้า Workspace แต่ Integration แรกที่เลือกใส่เป็น Team Integration กลับเป็น Gmail ส่วนตัวของผู้ดูแลคนนั้นเอง ผลคือทีมทั้งหมดสามารถถาม Viktor เกี่ยวกับอีเมลส่วนตัวของเขาได้ จนเจ้าตัวต้องส่งข้อความมาต่อว่า

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

สามเสาหลักของ AI Coworker ที่ดี

Fryderyk สรุปสูตรของการสร้าง AI Coworker ที่ใช้งานได้จริงไว้สามข้อ ข้อแรกคือต้องช่วยให้งานเสร็จจริง ซึ่งวันนี้ทำได้ไม่ยากเพราะโมเดลเก่งพอ เชื่อม Integrations ผ่าน Pipedream ก็ใช้งานได้ดี ข้อสองคือต้องรู้จักบริษัท มี Context จาก Slack และใช้มันให้เป็น ซึ่งกระบวนการขออนุมัติจาก Slack นั้นยากและน่าเบื่อ แต่หลีกเลี่ยงไม่ได้ ข้อสามคือต้องเป็นมิตร Viktor ต้อง ชอบทีม และทีมต้องชอบ Viktor ด้วย ซึ่งเป็นเรื่องของโทนเสียงและบุคลิก

ในช่วงปิดท้าย Fryderyk ย้อนกลับไปอ้างถึง Gottfried Leibniz นักประดิษฐ์แคลคูลัสจากศตวรรษที่ 17 ผู้เคยฝันถึงการให้เครื่องจักรทำงานคำนวณแทนมนุษย์ พร้อมยกคำกล่าวว่า "It is unworthy of excellent men to lose hours like slaves in the labor of calculation... Let us leave that to machines." (เป็นเรื่องไม่คู่ควรกับผู้ปราดเปรื่อง ที่จะต้องเสียเวลาเป็นชั่วโมง ๆ เยี่ยงทาส ไปกับงานคำนวณ... จงปล่อยให้เครื่องจักรทำสิ่งนั้นแทน) แล้วบอกว่าวันนี้เราอยู่ในจังหวะประวัติศาสตร์ที่ Automate งานทางความคิด (Cognitive Task) ทั้งหมดได้ ไม่ใช่แค่การคำนวณอีกต่อไป

ที่มา: Viktor AI Talk โดย Fryderyk Wiatrowski ผู้ร่วมก่อตั้ง Viktor