ปิดแล็ปท็อปเมื่อไร เอเจนต์ก็หยุดทำงาน จนถึงไม่นานมานี้ AI เอเจนต์ส่วนใหญ่ก็เป็นแบบนี้: เอเจนต์ในเทอร์มินัลคือโปรเซสที่รันบนคอมพิวเตอร์ของคุณ และหยุดไปพร้อมกับเครื่อง AI เอเจนต์อัตโนมัติรุ่นใหม่ทำงานต่างออกไป พวกมันมีคอมพิวเตอร์ของตัวเองบนคลาวด์ มีหน่วยความจำและนิสัยของตัวเอง สิ่งที่ปลุกพวกมันคืออีเมลหรือข้อความจากเพื่อนร่วมงาน พวกมันทำงานตอนกลางคืน และจะทักคุณก็ต่อเมื่อมีเรื่องจะบอกจริง ๆ ในโลกภาษาอังกฤษเรียกเอเจนต์แบบนี้ว่า always-on หรือ “เปิดอยู่ตลอดเวลา”
Lee Robinson เล่าว่าข้างในพวกมันทำงานอย่างไรในวิชา CS146S “The Modern Software Developer” ของ Stanford คลิปเลกเชอร์ขึ้น YouTube เมื่อ 11 ตุลาคม Robinson มาจาก Cursor บริษัทที่ SpaceX ตกลงซื้อเมื่อเดือนมิถุนายนด้วยเงิน 60,000 ล้านดอลลาร์ และตอนนี้เขาทำ Grok Bot อยู่ที่ SpaceX ซึ่งเป็นแอปที่ “บอต” AI ทำงานบนคอมพิวเตอร์บนคลาวด์ระหว่างที่คุณทำเรื่องของตัวเอง นี่ไม่ใช่โฆษณาผลิตภัณฑ์ แต่เป็นการแกะสถาปัตยกรรม: AI เอเจนต์แบบนี้ทำงานอย่างไร ประกอบขึ้นจากชิ้นส่วนอะไร และเทคนิคทางวิศวกรรมอะไรที่ทำให้มันเชื่อถือได้ ประหยัด และไม่น่ารำคาญ เขาบอกเองว่าบางเรื่องที่เล่ายังอยู่ระหว่างพัฒนา ผมสรุปประเด็นหลักไว้ด้านล่าง
สี่ยุคของการทำงานกับ AI
Robinson แบ่งประวัติศาสตร์ช่วงหลังออกเป็นสี่ยุค ยุคแรกคือก๊อปโค้ดจาก ChatGPT มาวางในเอดิเตอร์เอง ฟังดูเหมือนเรื่องเมื่อหลายสิบปีก่อน แต่จริง ๆ แค่ไม่กี่ปีเท่านั้น
ในยุคที่สอง โมเดลเริ่มแก้ไฟล์และรันคำสั่งในเทอร์มินัลเอง ข้างในเป็นลูปง่าย ๆ: โมเดลเรียกเครื่องมือ ดูผลลัพธ์ แล้วตัดสินใจว่าจะทำอะไรต่อ โปรแกรมที่ครอบโมเดลไว้ คอยหมุนลูปนี้ ส่งข้อความให้โมเดล ให้เครื่องมือกับมัน และรันคำสั่ง เรียกว่า harness และในบทความนี้ก็จะใช้คำนี้ไปตลอด
ในยุคที่สาม เอเจนต์มีแอปแยกของตัวเอง คนเริ่มรันพร้อมกันทีละหลายตัว บางตัวรันบนคลาวด์ แต่คอขวดยังเป็นคน: ทุกคำสั่งในเทอร์มินัลต้องให้คนกดยืนยันเอง
ยุคที่สี่คือ always-on เอเจนต์มีคอมพิวเตอร์และหน่วยความจำของตัวเอง เรียนรู้สกิลใหม่ระหว่างทำงาน และไม่หยุดเมื่อคุณเข้านอน
วิธีคุยกับเอเจนต์ก็เปลี่ยนไป เมื่อก่อนคุณสั่งงานแล้วรอ และต้องกด “อนุญาต” หรือ “ปฏิเสธ” ทุกคำสั่ง ตอนนี้ปรับทิศเอเจนต์ระหว่างทางได้: “ดูเธรดนี้หน่อย” แล้วอีกวินาทีต่อมา “อ้อ ทำวันพฤหัสนะ” โมเดลรุ่นก่อนจะสับสนกับแบบนี้ แต่รุ่นปัจจุบันเข้าใจว่าข้อความที่สองขยายความข้อความแรก
แทนที่การกดยืนยันเองก็มีการรีวิวอัตโนมัติ: โมเดลอีกตัวตรวจคำสั่งก่อนรัน Robinson มั่นใจว่าถ้าจัดการเทียบแบบปิดตา โมเดลตรวจจะรอบคอบกว่าคนในกรณีส่วนใหญ่ เพราะหลังจากอนุมัติไปร้อยคำสั่ง คนจะล้าและกด “ใช่” โดยไม่ดู โมเดลฉลาดขึ้น ส่วนอินเทอร์เฟซก็เรียบง่ายขึ้น: การทำงานกับเอเจนต์เหลือแค่การแชท เหมือนคุยกับเพื่อนร่วมงานในแอปแชท ทุกคนแชทเป็น และ Robinson มองว่านี่คือเหตุผลหลักที่ผลิตภัณฑ์แบบนี้กำลังได้รับความนิยมอย่างรวดเร็ว
หกเรื่องที่โมเดลทำได้แล้ว
always-on เอเจนต์เกิดขึ้นได้เพราะตัวโมเดลเองเปลี่ยนไปหลายด้าน Robinson ยกมาหกข้อ
- ทำตามคำสั่งได้นาน ถ้าบีบอัดบทสนทนาอย่างถูกวิธี โมเดลทำงานได้มั่นคงเป็นชั่วโมงและเป็นวันโดยไม่หลุด
- มอบหมายงานได้ เอเจนต์หลักแบ่งงานบางส่วนให้ผู้ช่วยที่เรียกว่าซับเอเจนต์ แล้วรับผลลัพธ์กลับมา
- เรียกเครื่องมือได้อย่างเชื่อถือได้ สองสามปีก่อน โมเดลยังสับสนกับการเรียกเครื่องมือและแต่งเรื่องขึ้นมาตลอด Robinson มองว่า ปัญหาการหลอน (hallucination) ส่วนใหญ่แก้ได้แล้ว นี่เป็นการประเมินของเขาเอง ในเลกเชอร์ไม่มีตัวเลขยืนยัน
- ทำงานกับเครื่องมือทรงพลังได้ ไม่ใช่แค่คำสั่งและไฟล์ แต่ได้ทั้งคอมพิวเตอร์ Linux ทั้งเครื่อง การอัดคลิปเดโม และ computer use คือความสามารถคลิกบนหน้าจอแบบคน แปลว่าเอเจนต์ทำงานกับเว็บไซต์และบริการจำนวนมากที่ไม่มี API หรือ MCP server ได้ ซึ่งสองอย่างนี้คือช่องทางที่โปรแกรมมักใช้เชื่อมต่อกับบริการโดยตรง Robinson ถึงกับพูดว่าได้กับทุกบริการแบบนี้ แต่ในทางปฏิบัติยังติดเรื่องการล็อกอิน แคปช่า ข้อจำกัดของเว็บไซต์ และบั๊กของอินเทอร์เฟซ
- เก็บความรู้ไว้ในไฟล์ โมเดลค้นไฟล์ด้วยคำสั่ง Linux ธรรมดาได้เก่งมาก หน่วยความจำของเอเจนต์จึงเป็นแค่ไฟล์ข้อความ
- เรียนรู้จากตัวอย่าง สาธิตให้บอตดูว่างานหนึ่งทำอย่างไร แล้วมันจะเปลี่ยนสิ่งนั้นเป็นสกิล โน้ต หรือรูทีน เพื่อทำซ้ำเองในครั้งต่อไป
สกิลคือไฟล์คำแนะนำในรูปแบบ Markdown ว่าจะทำงานหนึ่ง ๆ ให้ดีได้อย่างไร ตอนนี้มีทั้งระบบนิเวศเกิดขึ้นรอบ ๆ สกิลแล้ว และใน Grok Bot ก็มีปลั๊กอิน ซึ่งเป็นชุดสกิลและการเชื่อมต่อกับบริการแบบสำเร็จรูป รูทีนคือพรอมต์ที่ตั้งเวลาไว้ คล้ายงาน cron ข้อสรุปของ Robinson คือ เอเจนต์ไม่ต้องการองค์ประกอบพิเศษอะไร ทุกอย่างลงเอยที่คอมพิวเตอร์ธรรมดา: ไฟล์ คำสั่ง และเบราว์เซอร์
สถาปัตยกรรม AI เอเจนต์: ทริกเกอร์ เซิร์ฟเวอร์ คอมพิวเตอร์
ผังของเอเจนต์อัตโนมัติในแบบของ Robinson มีสามส่วน ด้านซ้ายคือทริกเกอร์ หรือสิ่งที่ปลุกเอเจนต์ ตรงกลางคือเซิร์ฟเวอร์ที่ลูปของเอเจนต์ทำงานอยู่ ด้านขวาคือคอมพิวเตอร์ที่เอเจนต์ลงมือทำงานจริง: ไฟล์ คำสั่ง เบราว์เซอร์
เอเจนต์หลับจนกว่าจะมีคนเรียก
“เปิดอยู่ตลอดเวลา” ไม่ได้แปลว่า “รันอยู่ตลอดเวลา” ตอนว่าง ทั้งเซิร์ฟเวอร์ของเอเจนต์และคอมพิวเตอร์ของมันหลับอยู่ เมื่อมีข้อความเข้ามา เซิร์ฟเวอร์จะโหลดสถานะของเอเจนต์ขึ้นมา เมื่อต้องใช้เบราว์เซอร์ คอมพิวเตอร์ก็ตื่น พองานเสร็จ ทั้งสองก็กลับไปหลับ ส่วนบทสนทนา หน่วยความจำ และรูทีนจะถูกเก็บลงฐานข้อมูล การเปิดคอมพิวเตอร์ค้างไว้ให้ผู้ใช้ทุกคนนั้นแพง และคอมพิวเตอร์ทั้งโลกก็มีไม่พอสำหรับทุกคนด้วย
สิ่งที่ปลุกเอเจนต์ได้ไม่ได้มีแค่เจ้าของ: ข้อความใน Slack อีเมล สายโทรเข้า หรือการประชุมก็ปลุกได้ Robinson เล่าว่าที่ SpaceX พนักงานเริ่มส่งบอตไปเข้าประชุมที่ตัวเองไปไม่ทันแล้ว บอตจะฟังและกลับมาพร้อมสรุป งานเบื้องหลังของเอเจนต์เองที่รันมาหลายชั่วโมงและเพิ่งเสร็จก็ปลุกมันได้เช่นกัน
สัญญาณทั้งหมดผ่านตัวจัดเส้นทาง (router) มันตัดรายการซ้ำ ตัดสินว่าจะใส่เหตุการณ์ลงในบทสนทนาไหน และถามคำถามสำคัญที่สุด: ควรรบกวนคนหรือเปล่า เพื่อนร่วมงานที่เดินมาหาทุกครั้งหลังทำขั้นเล็ก ๆ เสร็จนั้นน่ารำคาญ ปกติรายงานวันละครั้งก็พอ แล้วแต่งาน
คอมพิวเตอร์ของตัวเองบนคลาวด์
คอมพิวเตอร์ของเอเจนต์คือเวอร์ชวลแมชีนบน Firecracker ซึ่งเป็นเทคโนโลยีโอเพนซอร์สของ Amazon สำหรับเวอร์ชวลแมชีนน้ำหนักเบา สถานะของเครื่องแบบนี้บันทึกเป็นสแนปช็อตได้ง่าย ปิดเครื่อง แล้วค่อยเปิดต่อจากจุดเดิมได้ ในเครื่องมีไฟล์ของเอเจนต์ มีเทอร์มินัลและ Chrome คุณเชื่อมต่อเข้าไปดูว่าเอเจนต์กำลังทำอะไร และยึดการควบคุมมาเองก็ได้ ในเอกสารของ Grok Bot เรียกฟีเจอร์นี้ว่า Take over: บอตติดอยู่ที่ฟอร์มล็อกอินของเว็บไซต์ คุณล็อกอินเอง แล้วคืนการควบคุมให้มัน
คำสั่งของเอเจนต์ไม่ได้รันบนแล็ปท็อปของคุณ แต่รันบนเครื่องบนคลาวด์ ถ้ามีบอตห้าหรือสิบตัว แต่ละตัวอาจมีหน้าจอพร้อมเบราว์เซอร์ของตัวเอง แต่นี่ไม่ใช่กำแพงกั้นระหว่างพวกมัน: ตามเอกสารของ Grok Bot บอตในบัญชีเดียวกันใช้คอมพิวเตอร์ร่วมกัน และเซสชันล็อกอินในเบราว์เซอร์ที่บอตตัวหนึ่งใช้ไว้ บอตตัวอื่นก็ใช้ต่อได้
ทำไมสมองของเอเจนต์อยู่บนเซิร์ฟเวอร์
ลูปของเอเจนต์ไม่ได้รันบนเวอร์ชวลแมชีน แต่รันบนเซิร์ฟเวอร์ นี่คือหลักเก่า “ไคลเอนต์บาง เซิร์ฟเวอร์หนา” และมีข้อดีสามข้อ ตรรกะของเอเจนต์อัปเดตบนเซิร์ฟเวอร์ได้ทันทีโดยไม่ต้องออกแอปเวอร์ชันใหม่ใน App Store งานหนักอย่างการถอดเสียงหรือการสร้างภาพรันบนเซิร์ฟเวอร์ได้เร็วกว่าบนโทรศัพท์ และวงการนี้ก็รู้วิธีขยายเซิร์ฟเวอร์รับโหลดที่พุ่งขึ้นมานานแล้ว
แต่ที่สำคัญที่สุดคือความเป็นอิสระต่อกัน ถ้าลูปอยู่บนเวอร์ชวลแมชีน ก็จะปิดเครื่องไม่ได้โดยไม่ฆ่าเอเจนต์ไปด้วย แต่เมื่อแยกกันแบบนี้ ก็สร้างเครื่องใหม่ได้ทุกเมื่อ เช่น เพื่ออุดช่องโหว่ใน Linux แบบเร่งด่วน และเอเจนต์จะไม่รู้สึกว่ามีช่วงหยุดทำงานเลย
ทำไมเซิร์ฟเวอร์ล่มแล้วงานไม่หาย
สมมติเอเจนต์กำลังทำงานสามขั้น และเซิร์ฟเวอร์ล่มตอนขั้นที่สาม ถ้าใช้คิวงานธรรมดา หลังรีสตาร์ททั้งสามขั้นจะเริ่มใหม่ตั้งแต่ต้น โปรเซสที่ทนต่อการล่ม (durable workflow) จะเก็บผลของขั้นที่เสร็จแล้ว และหลังล่มก็ทำต่อจากขั้นที่สาม Grok Bot ใช้ Temporal ซึ่งเป็นโอเพนซอร์ส จะได้ไม่ต้องเขียนกลไกที่ซับซ้อนนี้เองตั้งแต่ศูนย์ มีข้อแม้ข้อเดียว: ขั้นที่ขาดกลางคันอาจถูกรันซ้ำ ดังนั้นตามที่สไลด์ในเลกเชอร์ระบุ แต่ละขั้นจะเขียนให้รันซ้ำแล้วไม่เกิดความเสียหาย เช่น การป้องกันการส่งอีเมลซ้ำสองครั้ง นักพัฒนาต้องใส่ไว้เอง
ข้อความที่เข้ามามีลำดับความสำคัญต่างกัน ถ้าเจ้าของพิมพ์มาว่า “เปลี่ยนวันนัดประชุม” เอเจนต์จะหยุดขั้นที่ทำอยู่ เพราะข้อความจากเจ้าของสำคัญกว่าทุกอย่าง ข้อความจากแชทกลุ่ม เธรดใน Slack และรูทีนเบื้องหลังจะไปต่อท้ายคิว และถ้ามีหลายข้อความเข้ามาติด ๆ กัน เอเจนต์จะรวมเป็นเทิร์นเดียว
harness ของเอเจนต์: เครื่องมือเดียวสำหรับทุกไคลเอนต์
สิ่งที่ทำให้ harness ของ Grok Bot ต่างจากผลิตภัณฑ์คล้าย ๆ กันคือรายละเอียดเดียว: ระหว่างแอปกับเซิร์ฟเวอร์มีเครื่องมืออยู่ตัวเดียวพอดี คือ “ส่งข้อความหาผู้ใช้” งานหนักทั้งหมดอยู่บนเซิร์ฟเวอร์: คำสั่ง ไฟล์ การเรียกเอเจนต์บนคลาวด์ การอัดหน้าจอ แอปแค่รับส่งข้อความกับเซิร์ฟเวอร์ ไคลเอนต์ใหม่ไม่ว่าจะเป็นมือถือ เดสก์ท็อป อีเมล หรือ Slack จึงเชื่อมต่อได้โดยไม่ต้องรื้อทำใหม่
แต่แอปตัดสินเองว่าจะแสดงคำตอบอย่างไร Robinson ยกตัวอย่าง ถ้าเอเจนต์ต้องล็อกอินเข้าบริการ แอปอาจแสดงฟอร์มล็อกอินและเชื่อมกับตัวจัดการรหัสผ่านอย่าง 1Password ถ้าต้องจ่ายเงิน ก็เรียกบริการชำระเงิน เช่น Stripe Link หรือ X Money ถ้าเป็นการกระทำที่ย้อนกลับไม่ได้ เช่น อีเมลหรือข้อความใน Slack ก็แสดงดราฟต์ให้แก้และอนุมัติได้ และบางครั้งเอเจนต์ไม่ต้องตอบเลย แค่กดอีโมจิรีแอ็กชันก็พอ
เครื่องมือตามต้องการ
โมเดลมี context window คือทุกอย่างที่มันเห็นอยู่ตอนนี้: คำสั่ง บทสนทนา ผลของงาน ขนาดของมันมีจำกัดและนับเป็น token ซึ่งเป็นชิ้นส่วนของคำที่ผู้ให้บริการใช้คิดเงิน เครื่องมือทุกตัวที่เชื่อมไว้กินที่ใน context window: ชื่อ คำอธิบาย และสคีมาพารามิเตอร์ ลองเชื่อมคอนเนกเตอร์ Google Drive, Gmail และ YouTube ดู แล้วพื้นที่ส่วนไม่น้อยของ context window ก็ถูกใช้ไปตั้งแต่ยังไม่เริ่มคุย
ด้วยเหตุนี้ harness ยอดนิยมจึงไม่ได้ให้โมเดลเห็นคำอธิบายเครื่องมือทั้งหมดตั้งแต่แรก แต่ค่อย ๆ ให้เมื่อจำเป็น ฝั่ง Anthropic ใช้ tool search tool หรือเครื่องมือค้นหาเครื่องมือทำหน้าที่นี้: มันหาเครื่องมือที่เหมาะ แล้วใส่คำอธิบายเข้าไปในบริบทเมื่อต้องใช้ Hermes Agent ก็จัดการกับสกิลในแบบคล้ายกัน: ในพรอมต์มีแค่รายชื่อ ส่วนเนื้อหาเต็มเอเจนต์จะเปิดดูเมื่อต้องใช้สกิลนั้น
บันไดจากถูกไปแพง
หลักทั่วไปคือลองวิธีที่ถูกที่สุดและเชื่อถือได้ที่สุดก่อน แล้วค่อยไต่ขึ้นไป:
- สิ่งที่เอเจนต์รู้อยู่แล้วจากบทสนทนา
- ปลั๊กอิน, MCP server หรือ API เช่น ข้อมูลธนาคารผ่าน Plaid
- ค้นหาในอินเทอร์เน็ต เช่น ผลการแข่งขันเมื่อวาน
- เบราว์เซอร์บนคอมพิวเตอร์ของตัวเอง
- เดสก์ท็อปทั้งหมด: สคริปต์ คำสั่ง การบิลด์อะไรสักอย่างบนเครื่อง Linux
- ถามคน ก็ต่อเมื่อไม่มีวิธีไหนได้ผลเลย
เพื่อนร่วมงานที่ดีก็ทำแบบนี้: ไม่มาถามจุกจิกทุกเรื่อง แต่ลองทำเองก่อน
บันไดคล้าย ๆ กันใช้ตอนที่เอเจนต์ทำงานกับเว็บไซต์ในเบราว์เซอร์ สกรีนช็อตมีราคาแพง ถูกกว่าคืออ่าน HTML ของหน้า และถูกกว่านั้นอีกคือ accessibility tree ซึ่งเป็นรายการปุ่ม ลิงก์ และช่องกรอกแบบย่อ ที่ใช้หาได้ง่ายว่าต้องกดตรงไหน ถ้ายังไม่ได้ผล เช่น มีหน้าต่าง modal เด้งขึ้นมา เอเจนต์จะดูภาพหน้าจอแล้วคลิกตามพิกเซลแบบคน ขั้นสุดท้ายคือกลับไปหาคนอีกครั้ง: รหัสยืนยันตัวตนสองชั้นหรือแคปช่า
หัวหน้าและผู้ช่วย
เอเจนต์หลักทำงานเหมือนหัวหน้า: ถือรายการงาน แจกงานให้ผู้ช่วยที่เป็นซับเอเจนต์ ตรวจงาน ส่งข้อความหา และสั่งหยุดได้ บทสนทนาของตัวมันเองต้องสั้นที่สุดเท่าที่ทำได้ ผู้ช่วยเริ่มงานในบริบทใหม่ที่ยังว่างอยู่ รันคำสั่งเป็นร้อย ส่วนเอเจนต์หลักได้รับแค่คำตอบ งานร่างทั้งหมดจึงไม่ไปรกบริบทของมัน บทสนทนาหลักจึงโตช้าลง และเอเจนต์ชนเพดาน context window น้อยลง บริบทที่ไม่มีที่สิ้นสุดไม่มีอยู่จริง แต่ด้วยเทคนิคแบบนี้ ผลิตภัณฑ์ก็ทำให้รู้สึกได้ว่ามันพอสำหรับงานยาวแค่ไหนก็ได้
ผู้ช่วยแต่ละตัวก็เป็น durable workflow เหมือนกัน ถ้าผู้ช่วยที่ทำวิดีโอล่มหรือหน่วยความจำหมด มันจะรีสตาร์ทและกู้งานคืนจากสถานะที่บันทึกไว้ Robinson ยอมรับว่าทั้งผังนี้ลอกมาจากวิธีขยายทีมวิศวกรที่ทำงานยากในแบบอุดมคติ
จากประสบการณ์ของทีม เขาเพิ่มบทเรียนอีกหลายข้อ ไม่ควรเพิ่มหรือถอดเครื่องมือกลางเทิร์น เพราะจะทำให้แคชพัง ซึ่งจะเล่าด้านล่าง คำอธิบายและสคีมาของเครื่องมือควรตัดให้สั้น เพราะทุกคำในนั้นต้องจ่ายเงินในทุกคำขอ ให้เอเจนต์มีเครื่องมือตัวเดียวคือเทอร์มินัลก็ได้ และมันจะทำได้แทบทุกอย่าง แต่ถ้าโมเดลใช้เวลา 90% ไปกับการรันคำสั่งเพื่อทำงานอย่างใดอย่างหนึ่ง ก็คุ้มกว่าที่จะทำเครื่องมือแยกให้งานนั้น ทั้งถูกกว่าและเข้าใจง่ายกว่าสำหรับคนที่ต้องมาไล่ดูงานของเอเจนต์ และอีกข้อ: ข้อความ error ควรเขียนให้คนอ่าน คือบอกว่าอะไรพังและต้องทำอะไรต่อ มันช่วยเอเจนต์ได้เหมือนกับที่ช่วยคน
ความปลอดภัยของ AI เอเจนต์: อีเมลไม่ใช่คำสั่ง
เอเจนต์ที่ทำงานเองเป็นสัปดาห์ต้องไว้ใจได้ และ Robinson ไล่เรียงว่าควรมีอะไรบ้าง โมเดลอีกตัวตรวจคำสั่งของเอเจนต์ แม้จะรันบนเครื่องที่แยกขาดแล้วก็ตาม อีเมลในกล่องจดหมายอาจเป็นฟิชชิง webhook ซึ่งเป็นการแจ้งเตือนอัตโนมัติจากบริการอื่นอาจเป็นของปลอม และข้อมูลแบบนี้ห้ามทำตามเหมือนเป็นคำสั่งจากเจ้าของ นี่คือ prompt injection และ Robinson บอกว่าวงการยังต้องทำอีกมากในเรื่องนี้ การกระทำที่ย้อนกลับไม่ได้ เช่น การส่งอีเมล ควรให้คนเห็นชอบก่อน ส่วนรหัสผ่านและข้อมูลการชำระเงินไม่ควรให้เข้าไปอยู่ในบทสนทนากับโมเดลเลย ผลิตภัณฑ์จะมีกลไกแยกไว้สำหรับเรื่องนี้
นี่คือคำแนะนำ ไม่ใช่การรับประกันที่ติดมากับเอเจนต์ทุกตัว: อะไรเปิดอยู่บ้างขึ้นกับผลิตภัณฑ์และการตั้งค่าของมัน กฎชุดเดียวกันสำหรับเอเจนต์ส่วนตัวเราเคยแกะไว้ในบทความเรื่องการป้องกันเอเจนต์ในแชทกลุ่ม
ทำไม AI เอเจนต์ถึงแพง: แคชพรอมต์ชี้ขาดทุกอย่าง
Robinson บอกว่าสำหรับเขา context engineering กับ harness engineering แทบเป็นเรื่องเดียวกัน นี่เป็นการพูดเกินจริง: จากด้านบนจะเห็นว่า harness ยังรวมถึงเครื่องมือ การจัดเส้นทาง การกู้คืนหลังล่ม และความปลอดภัย แต่การจัดการบริบทก็เป็นหนึ่งในงานหลักของมัน: ยิ่งเอเจนต์ใช้บริบทน้อย ก็ยิ่งถูกและฉลาดขึ้น
กุญแจสำคัญคือแคชพรอมต์ ทุกเทิร์น เอเจนต์จะส่งบทสนทนาทั้งหมดให้โมเดลใหม่ บวกข้อความใหม่หนึ่งข้อความ ถ้าส่วนต้นของคำขอไม่เปลี่ยน ผู้ให้บริการจะดึงจากแคช และ token ที่แคชไว้ถูกกว่าหลายเท่า ด้วยเหตุนี้ system prompt และคำอธิบายเครื่องมือจึงถูกคงไว้ไม่เปลี่ยน และต้องจ่ายราคาเต็มแค่ส่วนท้ายที่เพิ่งเพิ่มมา ถ้ามีอะไรในส่วนต้นของคำขอเปลี่ยน แคชจะใช้ได้แค่ถึงจุดนั้น ส่วนทุกอย่างหลังจากนั้นจ่ายราคาเต็ม แคชยังหมดอายุเองได้ด้วยถ้าเอเจนต์เงียบไปนาน Robinson เสนอให้มองว่าการพลาดแคชแบบไม่คาดคิดเป็นเหมือนบั๊ก: ให้หาว่าอะไรทำให้ส่วนต้นของคำขอที่ควรนิ่งเปลี่ยนไป เงื่อนไขการแคชที่แน่ชัดของแต่ละผู้ให้บริการไม่เหมือนกัน
เขานึกถึงเดือนมกราคม 2569 ตอนที่ OpenClaw ดังพลุแตก และคนแห่กันรันมันบนแพ็กเกจสมาชิกของผู้ให้บริการโมเดล เอเจนต์ทำงานตลอด 24 ชั่วโมง ตอนนั้น harness ยังไม่รู้วิธีถนอมแคช พลาดแคชกันบ่อย และต้องแก้กันหลายรอบ
เทคนิคประหยัดที่ Robinson ไล่เรียงมา:
- เอาต์พุตยาว ๆ ของคำสั่งไม่ใส่ในบริบท แต่บันทึกเป็นไฟล์ แล้วเอเจนต์จะอ่านเฉพาะส่วนที่ต้องการเอง
- สกรีนช็อตและงานหนักอื่น ๆ ส่งให้ผู้ช่วยทำ จะได้ไม่ทำให้บริบทของเอเจนต์หลักบวม
- ลบสิ่งที่ไม่จำเป็นออกจากบริบทเป็นประจำ ทั้งเพื่อลดค่าใช้จ่ายและเพื่อให้โมเดลนึกถึงเรื่องสำคัญได้ดีขึ้น
- คงลำดับส่วนต่าง ๆ ของพรอมต์ไว้ตายตัว: ถ้าทีมทดสอบ system prompt ชิ้นใหม่กับผู้ใช้บางส่วน ชิ้นนั้นต้องไม่ดันส่วนอื่นให้เลื่อน ไม่อย่างนั้นแคชจะหลุดสำหรับทุกคน
- อุ่นแคชไว้ล่วงหน้า: คุณเปิดแชทและเริ่มพิมพ์ เซิร์ฟเวอร์ก็เตรียมพรอมต์ไว้แล้ว เหมือนเบราว์เซอร์ที่โหลดหน้าเว็บล่วงหน้าตอนคุณเอาเมาส์ไปชี้ลิงก์
เทคนิคที่ฉลาดที่สุดคือบีบอัดบทสนทนาตอนที่แคชยังอุ่นอยู่ ไม่ช้าก็เร็ว บทสนทนายาว ๆ จะชนเพดาน context window เช่นที่ 200,000 token และต้องย่อเหลือสรุปสั้น ๆ การบีบอัดทุกแบบทำให้รายละเอียดหาย และอัลกอริทึมที่ดีสำหรับเรื่องนี้เป็นโจทย์ระดับวิทยานิพนธ์ แต่เลือกจังหวะให้ฉลาดได้ สมมติว่าบทสนทนากับบอตสะสมไปถึง 100,000 token แล้วคุณเดินออกไป แคชของผู้ให้บริการอยู่ได้ไม่นาน ตั้งแต่ไม่กี่นาทีถึงหนึ่งชั่วโมง ระหว่างที่แคชยังไม่เย็น การบีบอัดบทสนทนามีราคาถูก และ Grok Bot ทำทันทีโดยไม่รอให้คุณกลับมา อีกครึ่งชั่วโมงต่อมา คุณจะคุยต่อจากสรุปที่กระชับแล้ว และทุกข้อความใหม่ก็ถูกลง ส่วนเอเจนต์เผา token ไปแบบไม่รู้ตัวที่ไหนอีกบ้าง เรารวบรวมไว้ในเช็กลิสต์ประหยัด token
หน่วยความจำของ AI เอเจนต์: สามชั้นและไฟล์
เอเจนต์ควรจำอะไร และอะไรลืมได้? Robinson แบ่งหน่วยความจำเป็นชั้น ๆ ข้อเท็จจริงสำคัญเกี่ยวกับผู้ใช้จะถูกใส่ในทุกคำขอ: ถ้าใครชอบพิมพ์ด้วยตัวพิมพ์เล็ก ทุกคำตอบก็ต้องเป็นแบบนั้น ไม่อย่างนั้นข้อความเดียวที่มีตัวพิมพ์ใหญ่ก็จะดูแปลก บันทึกบทสนทนาที่ผ่านมาเก็บแยกตามวัน เหมือนเพื่อนร่วมงานที่จดว่าวันนี้ทำอะไรไปบ้าง: ถามว่า “สัปดาห์ที่แล้วฉันทำอะไรไปบ้าง?” แล้วเอเจนต์จะหาคำตอบเจอ โน้ตร่างช่วยในงานที่ทำอยู่และไม่ได้ออกแบบมาให้เก็บนาน: มันอาจมีประโยชน์แค่ครึ่งชั่วโมงหรือหนึ่งชั่วโมงข้างหน้า ที่เหลือทั้งหมดอยู่ในไฟล์ และเอเจนต์หาสิ่งที่ต้องการด้วยการค้นหา
ข้อเท็จจริงสำคัญต้องถูกทบทวนอยู่ตลอด: อะไรสำคัญวันนี้ก็เก็บไว้ อะไรไม่เกี่ยวแล้วก็เอาออก เหมือน garbage collector ในการเขียนโปรแกรม สมองก็ทำงานแบบนี้: ตอนนี้คุณไม่ได้คิดถึงฟุตบอลแมตช์หนึ่งที่เคยดู ทั้งที่ยังจำมันได้
Hermes Agent ก็ทำคล้ายกัน: โน้ตถาวรอยู่ใน system prompt ทั้งหมด คลังบทสนทนาที่ผ่านมาเข้าถึงได้ด้วยการค้นหา และสกิลจะโหลดเมื่อต้องใช้ รายละเอียดอยู่ในบทความแกะหน่วยความจำของ Hermes Agent
ฟลายวีล: โมเดลเรียนรู้จากความผิดพลาดของผลิตภัณฑ์
การเทรนโมเดลมีสามขั้น ขั้นแรกคือ pre-training: โมเดลอ่านข้อความมหาศาลและได้ความเข้าใจโลกแบบกว้าง ๆ ต่อมาคือการเทรนเพิ่มด้วยตัวอย่าง (SFT, supervised fine-tuning): ใช้บทสนทนาตัวอย่างสอนให้มันทำตัวเป็นผู้ช่วยหรือเอเจนต์ และสุดท้ายคือการเรียนรู้แบบเสริมกำลัง (RL, reinforcement learning) ซึ่งคล้ายการฝึกเล่นเกมที่โมเดลเรียนรู้วิธีชนะ สำหรับ always-on เอเจนต์ ในขั้น SFT จะสอนโมเดลว่าต้องทำงานภายใน harness ตัวนั้น ๆ อย่างไร และมีเครื่องมืออะไรบ้าง ในขั้น RL จะสอนให้ทำตามคำสั่ง เลือกสกิลที่ใช่จากหลายร้อยตัว และเลื่อนเคอร์เซอร์ไปคลิกให้ตรงจุด
วิธีให้บริการโมเดลก็สำคัญ เอเจนต์หลักที่คุณแชทด้วยต้องตอบทันที ส่วนผู้ช่วยที่ทำงานนาน ๆ อยู่เบื้องหลัง ความต่างระหว่างสิบกับสิบสองนาทีไม่สำคัญแล้ว ตรงนี้จึงประหยัดได้
ทีมปรับปรุงผลิตภัณฑ์เป็นสองรอบ รอบสั้นคือทุกวัน: เอเจนต์ทำพลาด ความผิดพลาดนั้นกลายเป็นโจทย์ทดสอบ (eval) ทีมแก้ harness พรอมต์ หรือวิธีที่โมเดลให้บริการบนเซิร์ฟเวอร์ ตรวจการแก้กับโจทย์นั้น แล้วปล่อยขึ้นจริง รอบยาวคือเดือนละครั้งหรือทุกไม่กี่เดือน: โมเดลใหม่เรียนรู้จากความผิดพลาดที่สะสมไว้ ทำผลได้ดีกว่าในการทดสอบชุดเดิม แล้วถูกนำมาใช้ในผลิตภัณฑ์
โมเดลใหม่ก็เปิดทางให้สถานการณ์การใช้งานใหม่ ๆ ตัวอย่างเช่น ข้อมูลว่าบอตทำตัวอย่างไรในแชทกลุ่มแทบไม่มีเลย เพราะพฤติกรรมนี้เพิ่งเริ่มก่อตัว Robinson พูดถึง Moltbook โซเชียลเน็ตเวิร์กสำหรับ AI เอเจนต์ เพื่อเตือนว่าการที่เอเจนต์จำนวนมากคุยกันเองอาจออกนอกลู่นอกทางได้ จึงต้องสอนโมเดลเรื่องนี้
“ลบผลิตภัณฑ์ทิ้ง”
หลักการที่ Robinson นำมาจาก Cursor สู่ SpaceX ฟังดูเหมือนยั่วยุ: “ลบผลิตภัณฑ์ทิ้ง” โมเดลวันนี้คือโมเดลที่แย่ที่สุดเท่าที่เราจะมี แปลว่าอีกครึ่งปี อินเทอร์เฟซอาจต้องสร้างใหม่หมด เกือบทุกอย่างที่เขาเล่า ถ้าพูดเมื่อครึ่งปีก่อนก็คงฟังต่างไปแล้ว กลยุทธ์จึงตามมาจากตรงนี้: สร้างเผื่อโมเดลรุ่นถัดไป และทำให้น้อยที่สุดเท่าที่ทำได้ คืออินเทอร์เฟซเรียบง่ายที่โมเดลใช้คิดและลงมือแทนคุณ
อีกครึ่งปีถึงหนึ่งปีจะเป็นอย่างไร
Robinson วางเดิมพันสำหรับ 6–12 เดือนข้างหน้าไว้แบบนี้ เอเจนต์จะทำงานไม่ใช่แค่เป็นชั่วโมงหรือเป็นวัน แต่เป็นสัปดาห์และเป็นเดือน โมเดลจะนึกถึงบทสนทนาเก่าได้ดีขึ้น ผ่านกราฟ ไฟล์ หรือวิธีอื่น งานวิจัยกำลังไปหลายทิศทาง เพื่อนร่วมงานดิจิทัลจะเริ่มได้เครื่องมือชุดเดียวกับที่พนักงานใหม่ได้ตอนออนบอร์ดดิ้ง ซึ่งบริษัทต่าง ๆ เพิ่งเริ่มคุ้นกับเรื่องนี้ หลายคนจะคุยกับเอเจนต์ด้วยเสียงไปเลย อาจผ่านแกดเจ็ตอย่างที่ OpenAI กับ Jony Ive กำลังทำอยู่ ส่วนเอเจนต์เองจะเรียนรู้ที่จะเปลี่ยนประสบการณ์เป็นสกิลและคำแนะนำ และบริษัทจะเริ่มเขียนกระบวนการของตัวเองให้เอเจนต์อ่านได้
โจทย์ที่ยังเปิดอยู่ก็มีไม่น้อย จะทดสอบเอเจนต์ที่ทำงานเป็นเดือนอย่างไร ในเมื่อโมเดลใหม่ออกทุกเดือน? จะป้องกัน harness อย่างไรไม่ให้คนร้ายยึดเอเจนต์ไปได้? เมื่อไรเอเจนต์ควรเงียบ และเมื่อไรควรทักก่อน? “เห็นว่าเมื่อวานคุณขาดเรียนคาบหนึ่ง นี่คือคลิปและสรุป” แบบนี้คือความใส่ใจหรือความจุ้นจ้าน? Robinson ยอมรับตรง ๆ ว่ายังไม่มีสมดุลที่สมบูรณ์แบบ และอีกเดิมพันที่ปลอดภัย: อีกหนึ่งปี ทั้งโลกจะใช้ token มากขึ้นอีกมาก การประหยัดในทุกขั้นจึงจะยิ่งสำคัญขึ้น
ช่วงท้ายมีข้อคิดเรื่องตลาด มีคนบอกว่าแอป AI ทุกตัวเหมือนกันหมด: แถบข้าง แชท เอเจนต์ Robinson เล่าต่อคำตอบของ Alex จาก OpenRouter: ในปี 2548 ทุกคนก็ทำ “อย่างเดียวกัน” เหมือนกัน คือเซิร์ฟเวอร์ ฐานข้อมูล ฟอร์มสร้างและลบข้อมูล มันก็แค่บรรทัดฐานใหม่ ผลิตภัณฑ์ทุกตัวถ้าไม่มีส่วนที่เป็นเอเจนต์ของตัวเอง ก็จะกลายเป็นแหล่งข้อมูลให้เอเจนต์ของคนอื่น และชิ้นส่วนทุกชิ้นของ always-on เอเจนต์ ไม่ว่าจะเป็น durable workflow แซนด์บ็อกซ์ คอมพิวเตอร์บนคลาวด์ หน่วยความจำ สกิล การเชื่อมต่อกับบริการ เสียง การชำระเงิน การยืนยันตัวตน การตรวจคุณภาพ และ observability ล้วนเป็นตลาดของตัวเอง ที่มีสตาร์ทอัพอยู่แล้วตลาดละยี่สิบราย
Robinson แนะนำนักศึกษาให้เข้าใจสถาปัตยกรรมของระบบและอ่านโค้ดที่เอเจนต์เขียน เพราะผลของการตัดสินใจเชิงสถาปัตยกรรมจะยิ่งทวีขึ้นตามเวลา และให้ลองสร้าง harness ของเอเจนต์เอง และทำความเข้าใจว่าโมเดลภาษาทำงานอย่างไร แบบเดียวกับที่นักพัฒนาเว็บควรเข้าใจฐานข้อมูล
รายละเอียดจากสไลด์
นี่คือการตั้งค่าของ Grok Bot ไม่ใช่มาตรฐานกลางของเอเจนต์ทุกตัว แต่ช่วยให้เห็นชัดว่าระบบแบบนี้ประกอบขึ้นจริงอย่างไร
คอมพิวเตอร์ เวอร์ชวลแมชีน Firecracker หนึ่งเครื่องต่อผู้ใช้หนึ่งคน ข้างในเป็น Debian ไม่กี่นาทีหลังกิจกรรมล่าสุด เครื่องจะเข้าโหมดหลับ (แต่ไม่มีวันหลับกลางเทิร์น): ไฟล์ถูกส่งไปเก็บในคลาวด์สตอเรจ หน่วยความจำและดิสก์ถูกบันทึกเป็นสแนปช็อต และเครื่องหยุดทำงาน พอมีการเรียกเครื่องมือครั้งถัดไป สแนปช็อตจะถูกกู้คืน ส่วนการล็อกอินเข้าบริการและโปรแกรมที่ติดตั้งไว้ยังอยู่ครบ
หน่วยความจำ โปรไฟล์คือข้อเท็จจริงเกี่ยวกับผู้ใช้ไม่เกิน 100 ข้อ รวมไม่เกิน 4,000 ตัวอักษร และอยู่ในพรอมต์เสมอ จากบันทึกรายวัน รายการล่าสุดที่เกี่ยวข้องที่สุด 30 รายการจะถูกใส่ในพรอมต์ โน้ตจางหายเร็ว ส่วนที่เหลือเอเจนต์หาด้วยการค้นในหน่วยความจำ หลังทุกเทิร์นจะมีรอบแยกที่เพิ่มข้อเท็จจริงใหม่และแทนที่ของเก่า โดยมันลบได้เฉพาะข้อเท็จจริงที่ถูกแสดงให้มันเห็นเท่านั้น ข้อเท็จจริงสำคัญจะถูกดันขึ้น ของเก่าจะค่อย ๆ ถูกดันลง ข้อเท็จจริงเกี่ยวกับคุณใช้ร่วมกันในบอตทุกตัวของคุณ แต่แต่ละตัวเขียนลงไฟล์ของตัวเอง และมีการบอกโมเดลไว้ตรง ๆ ว่าหน่วยความจำคือข้อมูล ไม่ใช่คำสั่ง
ความปลอดภัย โมเดลอีกตัวตรวจการกระทำที่เสี่ยงก่อนรัน ถ้ามันระงับการกระทำนั้น คุณจะได้รับคำขอให้ยืนยัน และถ้าคุณไม่ตอบภายใน 15 วินาที การกระทำนั้นจะถูกปฏิเสธ ข้อความจากอีเมลและ webhook ถูกทำเครื่องหมายว่าไม่น่าเชื่อถือ บอตจะไม่ส่งข้อความหาคนอื่นจนกว่าคุณจะขอ และรูทีนใหม่ต้องได้รับความยินยอมจากคุณ รหัสผ่านอยู่ในตัวแปรสภาพแวดล้อมและไม่ไปถึงโมเดล ส่วนการกระทำบนแล็ปท็อปของคุณต้องได้รับอนุญาต
การบีบอัด หลังเทิร์นใหญ่ คือพรอมต์เกิน 100,000 token ผ่านไปราว 10 นาที แคชยังอุ่นอยู่ และตอนนั้นเองที่จะเขียนสรุป ถ้างานเบื้องหลังจะปลุกเอเจนต์ในอีกไม่นานอยู่แล้ว ก็ข้ามการบีบอัดไป ข้อความล่าสุดไม่กี่ข้อความที่เอเจนต์ส่งถึงคุณจะถูกเก็บไว้ตามตัวอักษร และถ้าเทิร์นยาวเกินไป ก็บีบอัดบทสนทนากลางทางได้
แคชและเครื่องมือ จนกว่าจะถึงการบีบอัดครั้งถัดไป เครื่องมือ system prompt และข้อความแรกจะไม่เปลี่ยนแม้แต่ตัวอักษรเดียว ถ้าการอัปเดตบริการทำให้คำอธิบายเครื่องมือเปลี่ยน บทสนทนาที่กำลังดำเนินอยู่จะได้รับโน้ตสั้น ๆ แทนข้อความใหม่ทั้งชุด เครื่องมือที่ใช้ไม่ได้จะไม่ถูกถอดออก แต่จะคืน error ที่อ่านเข้าใจ คำอธิบายและสคีมาของเครื่องมือแต่ละตัวยาวไม่เกิน 4,000 ตัวอักษร และอีกกฎหนึ่งสำหรับบันไดวิธีการ: ถ้าคอนเนกเตอร์ไปยังบริการพัง เอเจนต์ต้องไม่หาทางอ้อมผ่านเบราว์เซอร์ แต่ต้องบอกเรื่องนี้แล้วถาม
วิธีสร้าง AI เอเจนต์ส่วนตัวได้ตั้งแต่ตอนนี้
Grok Bot เป็นผลิตภัณฑ์แบบปิด มาพร้อมแพ็กเกจสมาชิกแบบเสียเงินของ SuperGrok และ Cursor แต่ชิ้นส่วนหลายชิ้นจากเลกเชอร์มีอยู่ในเครื่องมือโอเพนซอร์สด้วย เอเจนต์ส่วนตัวของผมรันบน Hermes Agent บนเซิร์ฟเวอร์เช่า ผมคุยกับมันผ่าน Telegram และเทคนิคจากเลกเชอร์หลายอย่างมันก็มีแล้ว:
- รูทีนคืองาน cron ส่วนมันพังแบบเงียบ ๆ ได้อย่างไรและจะป้องกันอย่างไร ผมเล่าไว้ในบทความเรื่อง hermes-cron
- สกิลก็คือคำแนะนำใน Markdown แบบเดียวกัน จะหาได้ที่ไหนและตรวจอย่างไร อยู่ในบทความรวมสกิลและปลั๊กอินสำหรับ Hermes
- การเก็บกวาดหน่วยความจำทุกคืนของเอเจนต์ผมทำโดยปลั๊กอิน hermes-dreaming และตั้งแต่เวอร์ชัน 3.3 ผู้ตัดสินบนคลาวด์ ก็ตรวจซ้ำการยืนยันข้อเท็จจริงของมันได้
- จะเริ่มจากตรงไหน ให้เริ่มจากคู่มือติดตั้ง Hermes และเชื่อมต่อกับ Telegram
และกฎสามข้อจากเลกเชอร์ที่ควรใช้กับเอเจนต์ทุกตัวตั้งแต่วันนี้ ทุกอย่างที่ย้อนกลับไม่ได้ ทั้งอีเมล การจ่ายเงิน การโพสต์ เอเจนต์เตรียมเป็นดราฟต์ แล้วคุณเป็นคนส่ง อีเมลและข้อความจากคนอื่นคือข้อมูล ไม่ใช่คำสั่ง และอย่าเรียกร้องให้เอเจนต์รายงานทุกขั้น: เพื่อนร่วมงานที่ดีจะทักมาเมื่อมีเรื่องจะบอก
คำถามที่พบบ่อย
AI เอเจนต์อัตโนมัติคืออะไร อธิบายแบบง่าย ๆ?
คือ AI เอเจนต์ที่ทำงานต่อได้โดยไม่ต้องเปิดหน้าแชทค้างไว้: มันเริ่มงานตามเวลาที่ตั้งไว้และตามเหตุการณ์ เช่น อีเมล ข้อความ หรือการประชุม และตัดสินใจเองว่าจะทักคุณเมื่อไร ปกติแล้วเอเจนต์แบบนี้อยู่บนเซิร์ฟเวอร์ และในสถาปัตยกรรมที่ Robinson แกะให้ดู มันยังมีหน่วยความจำและคอมพิวเตอร์บนคลาวด์ด้วย ภาษาอังกฤษเรียกเอเจนต์แบบนี้ว่า always-on
AI เอเจนต์ต่างจากแชทบอตอย่างไร?
แชทบอตตอบคำถาม ส่วน AI เอเจนต์ทำงานให้เสร็จ: มันเรียกเครื่องมือเอง ทั้งคำสั่ง เบราว์เซอร์ อีเมล และบริการต่าง ๆ ดูผลลัพธ์ แล้วตัดสินใจว่าจะทำอะไรต่อ เอเจนต์ในเทอร์มินัล ซึ่งเป็นวิธีที่คนมักรัน Claude Code หรือ Codex ทำงานเป็นโปรเซสบนคอมพิวเตอร์ของคุณ: แล็ปท็อปหลับเมื่อไร งานก็หยุด เอเจนต์อัตโนมัติต้องมีสภาพแวดล้อมที่ทำงานได้โดยไม่มีคุณ: ทนต่อการล่มและการรีสตาร์ท และสิ่งที่ปลุกเอเจนต์ได้ก็ไม่ได้มีแค่ข้อความจากคุณ
Grok Bot คืออะไรและใครใช้ได้บ้าง?
คือแอปของ SpaceXAI และ Cursor เปิดเบต้าเมื่อ 11 สิงหาคม 2569 คุณสั่งงานบอตผ่านแชทหรือด้วยเสียง แล้วมันจะทำงานบนคอมพิวเตอร์บนคลาวด์ที่มีเบราว์เซอร์และเทอร์มินัล ตามข้อมูลของ xAI ณ วันที่ 26 สิงหาคม Grok Bot รวมอยู่ในแพ็กเกจ SuperGrok, SuperGrok Plus, SuperGrok Heavy, Cursor Pro, Pro+, Ultra และ Cursor Teams ส่วนการใช้งานระดับองค์กรขนาดใหญ่เปิดให้ลงชื่อรอไว้ ล็อกอินผ่านบัญชี Cursor
ทำไมเอเจนต์ต้องมีซับเอเจนต์?
เพื่อไม่ให้รายละเอียดของงานย่อยแต่ละงานกินบริบทของเอเจนต์หลัก ผู้ช่วยทำงานหนักในบริบทใหม่ของตัวเอง แล้วส่งกลับมาแค่ผลลัพธ์ เอเจนต์หลักจึงทำงานได้นานขึ้นโดยไม่ต้องบีบอัดและไม่เสียรายละเอียด
ทำไม AI เอเจนต์อัตโนมัติถึงอาจแพง?
ทุกเทิร์น เอเจนต์ส่งบทสนทนาทั้งหมดให้โมเดลใหม่ ถ้าส่วนต้นของคำขอเปลี่ยน แคชจะไม่ทำงาน และต้องจ่ายราคาเต็มสำหรับบริบททั้งหมด สิ่งที่ช่วยได้คือ system prompt ที่ไม่เปลี่ยน คำอธิบายเครื่องมือที่สั้น การเก็บผลลัพธ์ยาว ๆ ไว้ในไฟล์แทนบริบท ซับเอเจนต์สำหรับงานหนัก และการบีบอัดบทสนทนาในจังหวะที่เหมาะ
ให้ AI เอเจนต์เข้าถึงอีเมลปลอดภัยไหม?
ควรเริ่มจากให้อ่านและเตรียมดราฟต์ ถ้าผลิตภัณฑ์มีฟีเจอร์ให้โมเดลอีกตัวตรวจการกระทำของเอเจนต์ ให้เปิดใช้ และให้ส่งอีเมลได้เฉพาะหลังจากคุณยืนยันแล้วเท่านั้น เอเจนต์ต้องถือว่าอีเมลขาเข้าเป็นข้อมูล ไม่ใช่คำสั่ง: Robinson บอกว่าวงการยังป้องกัน prompt injection ได้ไม่สมบูรณ์ ระบบป้องกันเหล่านี้มีอยู่และเปิดอยู่แค่ไหน ขึ้นกับเอเจนต์แต่ละตัวและการตั้งค่าของมัน
